Hi,
Cyril Brulebois <kibi@debian.org> (17/03/2010):
> Current situation:
> ==================
> * udev is ready in unstable.
> * X11 packages (server, drivers, libraries) are ready in unstable.
xorg-server (source for xserver-xorg-core-udeb) doesn't build on sparc
due to a relocation issue during the static link against
libnettle. I'm probably going to make this udeb [!sparc] in the next
revision, so that we can proceed without having to fix that for
now. Adding it back once it's done should be trivial, and should only
affect nettle in sid and xorg-server in both sid and testing. That
shouldn't harm/delay any other transition.
> * cairo, pango1.0, gtk+2.0, vte, gtk2-engines are ready in
> experimental [gnome 2.30 rc packages].
All of them are also in unstable now. Since some binaries for amd64
missed the dinstall run (vte, gtk2-engines), I pulled them in a local
repository, and then rebuilt cdebconf* and rootskel-gtk.
The resulting image built successfully and seems to run fine.
Also, no *directfb* packages in the udeb list.
> Right now, I spotted a few issues:
> * Missing version bump in Build-Depends, resulting in a dependency of
> libpango1.0-udeb → libcairo-directfb2-udeb. Should be trivial to
> fix.
> * An extra dependency in experimental: libcairo2-udeb → libstdc++6.
No longer an issue with the unstable packages, but it will have to be
looked into before the experimetal packages are uploaded to
unstable. I'll probably open a bug against cairo later on.
> Proposed plan:
> ==============
> (1)
> In order to get everyone ready, I'd suggest (kindly) asking
> pkg-gnome folks to upload their 2.28 packages to unstable; so that
> the remaining packages can be rebuilt against them. I think it'd be
> nice not to wait and get entangled in the gnome 2.30 transition,
> that's why I'd like to go with the 2.28 ones (which were working
> fine for me). It'd be nice to make sure there's no directfb stuff
> left in Depends, before it gets uploaded. ;)
Done, many thanks to Emilio!
> (2)
> Once that done, I'll rebuild the following d-i packages against them:
> * cdebconf
> * cdebconf-entropy
> * cdebconf-terminal
> * rootskel-gtk
Done. #574288 can be enhanced, but the initial version could be
sufficient as a first shot. It can be incrementally enhanced without
interfering with anything else anyway.
> (I'm going to file bugs against them in a few minutes anyway.)
Please note that the gtk+2.0 package that got uploaded wasn't 2.18.7-2
as was proposed in the patches I attached to those bugs, but 2.18.9-1
instead. Build-Depending on >= 2.18.7-2 works just fine anyway, but I
guess it'd be better to use accurate and real revisions.
> (3)
> If the resulting image boots fine, I'll be reporting here, and
> asking for those patches to be merged. If there are issues, I'll
> file bugs to fix those, and then report here, asking for those
> patches to be merged.
I didn't test it intensively, but it seems to work just fine.
> (4)
> If everything goes alright at this point, I think we should be able
> to migrate the whole set of packages to testing, so that further
> updates only require to migrate a few packages at a time.
How about merging the cdebconf{,-entropy,-terminal} and rootskel-gtk
patches, uploading those packages, while I'm uploading a new revision
of xorg-server disabling the udeb for sparc? If there are no surprises
from a buildd point of view, we should be able to ask for a push to
testing in a few days.
It'd be nice to quickly receive some comments from -boot@ so that we
can coordinate with pkg-gnome (they want to move their stuff from
experimental to unstable) and -release@ (I was tempted to put the
latter in Cc but let's just wait for some comments on this list first,
before adding some more load to their radar).
Mraw,
KiBi.
Attachment:
signature.asc
Description: Digital signature