[pkg-synfig-devel] new upstream release, libetl-dev, synfig

[Fabian Fagerholm]

On Wed, 2006-03-01 at 14:22 +0800, Paul Wise wrote:
>      1. Upload the new etl -1 as etl-dev (avoid waiting on NEW so we get
>         the new version sooner)

Done, tagged in SVN.

>      2. Upload the new etl -2 as libetl-dev --> goes into NEW

What are the chances of optimizing away this binary package name change
as part of upstream folding etl into synfig?

Of course, it's gonna happen some day, but I think we should aim to have
synfig (the packaging) in good shape for etch. So if we would have to
wait, say, until July-August for the folding to happen, then I think
it's worth doing the name change. If etl is folded into synfig within
the next three months, however, then we still have plenty of time to
make another synfig upload with etl included and remove etl from the
archive.

I'm proceeding to the new synfig package with the assumption that etl
won't be folded in time (or at all) for our purposes. However, I'm going
to hold off a little on the name change for etl until I get your opinion
on the above. We can always reverse the dependency changes, but NEW
processing is expensive and should be avoided if possible.

>      3. Upload the new synfig, build-dep on etl-dev | libetl-dev (in
>         case synfig goes thru faster than etl)

libsynfig0-dev should probably depend on libetl-dev | etl-dev too,
during the name transition. I made that change, ran ./bootstrap (and
cleaned up the mess it produces :) and uploaded.

Btw, I think we should adopt the multi-person changelog format used by
many other packages, when it makes sense. Basically, it just means you
divide the changelog entries by name like this:

[Your Name]
* foo
* bar

[My Name]
* foo2
* bar2

The last changelog entry uses this format. Personally, I like to prefix
my changes with the filename(s) the change occurred in, for example
* debian/control: libsynfig0-dev now depends on libetl-dev | etl-dev
unless it's some general thing like running the ./bootstrap script,
updating to a new upstream version or it affects a large number of
files.

>      4. Wait until synfig is in (so that synfigstudio's build-deps are
>         in)
>      5. Upload synfigstudio, build-dep on etl-dev | libetl-dev (in case
>         synfig goes thru faster than etl)
>      6. Wait till synfigstudio and etl are in
>      7. Beer-o-clock!

Can't wait 'til we get to step 7! ;)

> I've updated svn and tested building so we are ready to commence at 1.
> Preparations for 3 and 5 are also done and tested. I did get one error
> on synfigstudio because it couldn't find libltdl, but I assume that was
> due to bad autotools stuff and would go away with a re-autotooling.

I ran bootstrap for synfigstudio, didn't have time to try building. I
didn't check the result very carefully yet, so there might be some
tweaking to do.

Do you know how to get a local package installed into the pbuilder
chroot? In this case, the synfig debs would need to be installed
somehow, since they're not in the archive yet. I ran out of time trying
to figure this out.

> So, re-autotool and upload away! Please don't forget to use this when
> building synfig: -v 0.61.04-1 (this will include all the changelog in
> the upload so the ITP gets closed).

Good point, just a minor detail: it has to be -v 0.61.04-0 because the
version comparison is >, not >=. Picky, I know ;)

> Damn, wish svn+ssh could use my ssh agent instead of prompting for
> passwords a thousand times on svn-upgrade. svn is passing the correct
> env vars to ssh, but no joy. Plain ssh uses the key fine tho. Any ideas?

I had the same problem, too, until just now. Checked permissions on .ssh
and .ssh/authorized_keys on svn.debian.org, nothing wrong there.
However, it seems that uploading your key to svn.debian.org isn't
enough; you need to upload it to alioth.debian.org. I guess it has
something to do with the way the chroots are arranged, or something.
Anyway, get your key into ~/.ssh/authorized_keys on alioth, permissions
set right (700 for .ssh, 600 for authorized_keys) and you should be able
to use the keys.

-- 
Fabian Fagerholm <fabbe at paniq.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/pkg-synfig-devel/attachments/20060304/a8e271dd/attachment.pgp