Xorg 6.9
David Nusinow
X.Org is planning on making a release of 6.9 and 7.0 in about a week.
I've been preparing packages for 6.9, the monolithic release, based off the
current Xorg packages. They've been sitting in experimental and they've
been fairly well tested judging by the bug reports we've gotten so far. The
packages that went in to experimental today are for RC3, which represent an
essentially code-complete version of what will be the final release. The
remainder should be documentation updates and modular build system updates.
As such, the current packages should represent what will be the final 6.9
release.
I realize that there's a lot of transitions going on right now, but I'd
like permission to upload 6.9 final to unstable upon release. Here are the
consequences of doing this that I'm currently aware of:
1) Render and Xrender both need updates, with an soversion bump. These
packages are basically ready, and have been in experimental for some
time, and with some small amount of polish they'll be ready to go.
2) The only lib to get an soversion change in xorg-x11 itself is libICE,
which has a minor soversion bump to allow it to be built modularly.
3) xlibs-dev goes away. I already wrote about this to -devel-announce,
and many packages have updated their build dependencies, including most
recently gtk. This will almost definitely be the most drastic of the
changes with this update, but it will also serve to pave the way for the
modular packages, which is currently my main focus of attention.
The majority of the packaging is the same as what's currently in unstable.
The majority of the builds will choke on the MANIFEST again, but now that I
know what I'm doing with respect to that system (which I didn't during the
original xorg uploads) I can get that fixed for the second revision of the
packages, provided the toolchains are working.
The benefit to allowing the update to go through will be to allow newer
driver revisions, numerous bugfixes, and it will also pave the way for the
modular packages, which I am attempting to finish in time for etch.
So if it's Ok to let this go through next week that'd be great news, and if
not I'd like to hear what I'll be waiting on so I can track how things
progress. Thanks!
- David Nusinow
--
To UNSUBSCRIBE, email to debian-rele...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Nusinow
> 3) xlibs-dev goes away. I already wrote about this to -devel-announce,
> and many packages have updated their build dependencies, including most
> recently gtk. This will almost definitely be the most drastic of the
> changes with this update, but it will also serve to pave the way for the
> modular packages, which is currently my main focus of attention.
On IRC request from Steve, attached is a list of packages, sorted by
maintainer, that still build-depend on xlibs-dev. It's rather large, but
I'd imagine that most of it will clear up once people start getting
FTBFS's.
- David Nusinow
Steve Langasek
> X.Org is planning on making a release of 6.9 and 7.0 in about a week.
> I've been preparing packages for 6.9, the monolithic release, based off the
> current Xorg packages. They've been sitting in experimental and they've
> been fairly well tested judging by the bug reports we've gotten so far. The
> packages that went in to experimental today are for RC3, which represent an
> essentially code-complete version of what will be the final release. The
> remainder should be documentation updates and modular build system updates.
> As such, the current packages should represent what will be the final 6.9
> release.
> I realize that there's a lot of transitions going on right now, but I'd
> like permission to upload 6.9 final to unstable upon release. Here are the
> consequences of doing this that I'm currently aware of:
> 1) Render and Xrender both need updates, with an soversion bump. These
> packages are basically ready, and have been in experimental for some
> time, and with some small amount of polish they'll be ready to go.
- render doesn't need an soversion bump, because it doesn't build a shared
library (at least in Debian).
- per your comments on IRC, upstream hasn't bumped sonames on xrender yet.
Are you sure that xrender actually needs an soname change, rather than
just a shlibs change? This libs has 328 reverse-dependencies in unstable;
it's likely that a number of these are spurious, but it would still make
for an inconvenient transition. Does the version currently in
experimental match the code you'll be uploading? If not, where can I
find the source to determine whether we're looking at a transition in the
near future?
> 2) The only lib to get an soversion change in xorg-x11 itself is libICE,
> which has a minor soversion bump to allow it to be built modularly.
Correction: as we discussed on IRC, this is a shlibs bump, not an soversion
change. An soversion change in libICE would really, *really* suck...
> 3) xlibs-dev goes away. I already wrote about this to -devel-announce,
> and many packages have updated their build dependencies, including most
> recently gtk. This will almost definitely be the most drastic of the
> changes with this update, but it will also serve to pave the way for the
> modular packages, which is currently my main focus of attention.
What time frame are we looking at for the upload? I think we should be
aggressively patching/NMUing for the xlibs-dev transition in advance of the
actual removal of xlibs-dev; this weekend's BSP would be a great time to
start...
> The majority of the packaging is the same as what's currently in unstable.
> The majority of the builds will choke on the MANIFEST again, but now that I
> know what I'm doing with respect to that system (which I didn't during the
> original xorg uploads) I can get that fixed for the second revision of the
> packages, provided the toolchains are working.
> The benefit to allowing the update to go through will be to allow newer
> driver revisions, numerous bugfixes, and it will also pave the way for the
> modular packages, which I am attempting to finish in time for etch.
> So if it's Ok to let this go through next week that'd be great news, and if
> not I'd like to hear what I'll be waiting on so I can track how things
> progress. Thanks!
I don't see anything that should block letting this in next week, at least
if libxrender turns out to be a shlibs change and not an soname change.
Let's let the rest of the release team comment as well, though.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
Daniel Kobras
> On IRC request from Steve, attached is a list of packages, sorted by
> maintainer, that still build-depend on xlibs-dev. It's rather large, but
> I'd imagine that most of it will clear up once people start getting
> FTBFS's.
This list includes packages that only declare an alternative build
dependency on xlibs-dev, and therefore looks a bit worse than the real
situation should be. Those should be removed from the attached list. But
to immediately spoil the good news, I've also included packages in
contrib and non-free, so in the end we should be about level.
Regards,
Daniel.
Steve Langasek
Anyone want to post a list on wiki.debian.org, *without* maintainer names
(which are really only relevant to... the maintainers), so that it can be
used as a potential TODO list for this weekend's BSP?
Cheers,
Alexander Schmehl
* Steve Langasek <vor...@debian.org> [051216 13:30]:
> Anyone want to post a list on wiki.debian.org, *without* maintainer names
> (which are really only relevant to... the maintainers), so that it can be
> used as a potential TODO list for this weekend's BSP?
Basicaly done at: http://wiki.debian.org/depends%3axlibs-dev
Just polishing it a bit...
Yours sincerely,
Alexander
--
http://learn.to/quote/
http://www.catb.org/~esr/faqs/smart-questions.html
Kevin B. McCarty
more binary packages that Depend: xlibs-dev. I've already removed
packages from the list that give it as an alternative (e.g. Depends:
libx11-dev | xlibs-dev).
I'll add this list to http://wiki.debian.org/DependsXlibsDev shortly.
Ryuichi Arafune <ara...@debian.org>
imagemagick
Thomas Bushnell, BSG <t...@debian.org>
gnome-libs
imlib
A. Maitland Bottoms <bot...@debian.org>
vtk
Martin Buck <mb...@debian.org>
xview
Guenter Geiger <gei...@debian.org>
ivtools
Debian QA Group <pack...@qa.debian.org>
ubit
Christian Hudon <chr...@debian.org>
icon
Aurelien Jarno <aur...@debian.org>
lineakd
Gerd Knorr <kra...@debian.org>
openmotif
Siggi Langauf <si...@debian.org>
xine-lib
Steve M. Robbins <s...@debian.org>
soqt
Jeff Teunissen <de...@debian.org>
libdockapp
Chris Waters <xt...@debian.org>
itcl3.0
itcl3.1
tk8.0
tk8.3
Florian M. Weps <f...@debian.org>
libooc-x11
Mathias Weyland <mat...@weyland.ch>
beep-media-player
regards,
--
Kevin B. McCarty <kmcc...@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
Russ Allbery
> On the same note, here is a list of source packages containing one or
> more binary packages that Depend: xlibs-dev. I've already removed
> packages from the list that give it as an alternative (e.g. Depends:
> libx11-dev | xlibs-dev).
> Debian QA Group <pack...@qa.debian.org>
> ubit
I can get this one today.
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>