Re: JPEG 8 transition
On Mon, Mar 15, 2010 at 01:03:19AM +0100, Julien Cristau wrote: > On Mon, Mar 15, 2010 at 00:29:45 +0100, Bill Allombert wrote: > > > On Sun, Feb 14, 2010 at 09:44:57PM +0100, Andreas Barth wrote: > > > * Sune Vuorela (nos...@vuorela.dk) [100214 21:32]: > > > I fear I need to agree with you. We should have libjpeg62 with > > > symbols, recompile every package build-depending on libjpeg*-dev after > > > that till the release, and then move to libjpeg8 (or whatever it is) > > > at the begining of the squeeze+1-cycle (and we can be sure nothing > > > breaks because of the symbols). > > > > Ok so I have experimented with a libjpeg62 source with versionned symbols, > > It works fine but for an annoying problem: > > > Bill, see . It doesn't > look like there's any way we can switch gtk and qt to libjpeg8 while > (non symbol versioned) libjpeg62 is mandated by LSB (unless we decide to > ignore the LSB). I do not think this is technically true. For example a program linked with Qt-linked-with-libjpeg62 should work fine when used with Qt-linked-with-libjpeg8 because LSB-mandated Qt interface does not export the raw libjpeg interface to the program. The same is true for gtk. However this would probably break some binary-only software that are not strictly LSB compliant. So I am considering the following transition plan: 1) We transition to libjpeg62+versioned-symbol (libjpeg62vs for short) for squeeze. This should not break the LSB except maybe for the warnings I mentionned above, but this is a minor issue. 2) We should be able to get other distributions to follow suite and the LSB to be updated to require libjpeg62vs. Since both forward and backward compatibility is preserved, and versioned symbols are technically superior, this should be possible. 3) Once some binary-only softwares have been rebuild against libjpeg62vs, then it should be safe to move to libjpeg8. Is there a better plan ? Cheers, -- Bill. Imagine a large red swirl here. signature.asc Description: Digital signature
Re: JPEG 8 transition
bill.allomb...@math.u-bordeaux1.fr wrote: >If you compile-time link a binary with libjpeg62 w/ versionned symbols, and try >to run-time link it with libjpeg62 w/o versionned symbols, then the dynamic >linker output a warning: > >cjpeg: /usr/lib/libjpeg.so.62: no version information available (required by >cjpeg) I had the same problem trying to fix a major fuckup of the libidn maintainer: he added versions to the symbols for no reason, so the shlibs file had to be bumped even if the ABI remained the same. I could not find a way to build the library in a way that it would provide the versioned symbols as aliases. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hnjvlg$ki...@posted-at.bofh.it
Re: JPEG 8 transition
On Mon, Mar 15, 2010 at 00:29:45 +0100, Bill Allombert wrote: > On Sun, Feb 14, 2010 at 09:44:57PM +0100, Andreas Barth wrote: > > * Sune Vuorela (nos...@vuorela.dk) [100214 21:32]: > > I fear I need to agree with you. We should have libjpeg62 with > > symbols, recompile every package build-depending on libjpeg*-dev after > > that till the release, and then move to libjpeg8 (or whatever it is) > > at the begining of the squeeze+1-cycle (and we can be sure nothing > > breaks because of the symbols). > > Ok so I have experimented with a libjpeg62 source with versionned symbols, > It works fine but for an annoying problem: > Bill, see . It doesn't look like there's any way we can switch gtk and qt to libjpeg8 while (non symbol versioned) libjpeg62 is mandated by LSB (unless we decide to ignore the LSB). Cheers, Julien signature.asc Description: Digital signature
Re: JPEG 8 transition
On Sun, Feb 14, 2010 at 09:44:57PM +0100, Andreas Barth wrote: > * Sune Vuorela (nos...@vuorela.dk) [100214 21:32]: > I fear I need to agree with you. We should have libjpeg62 with > symbols, recompile every package build-depending on libjpeg*-dev after > that till the release, and then move to libjpeg8 (or whatever it is) > at the begining of the squeeze+1-cycle (and we can be sure nothing > breaks because of the symbols). Ok so I have experimented with a libjpeg62 source with versionned symbols, It works fine but for an annoying problem: If you compile-time link a binary with libjpeg62 w/ versionned symbols, and try to run-time link it with libjpeg62 w/o versionned symbols, then the dynamic linker output a warning: cjpeg: /usr/lib/libjpeg.so.62: no version information available (required by cjpeg) Normally this should not be an issue for Debian, but this will cause problems for people wanting to build LSB package on Debian: when run on as non Debian LSB-compliant platform, the binaries will generate linker warning, which can cause problems. Maybe we will have to provide an extra package with the non-versionned libjpeg62. Cheers, -- Bill. Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100314232945.gb7...@yellowpig
Re: JPEG 8 transition
* Andreas Barth (a...@not.so.argh.org) [100214 21:45]: > In other words, please rollback libjpeg-dev to point again to > libjpeg62-dev, and add symbol versions to libjpeg62 (the second can > happen later, but as sooner it happens the better it is). After > libjpeg-dev points again to libjpeg62-dev, we need to binNMU all > affected programs. As more and more user complaints flowed in today (as kde* partially using libjpeg8 was installed tonight), the release team decided together with the kde team that we need to roll back that now. This means I already uploaded new versions that moved the -dev-Provides back to libjpeg62-dev. There are a couple of ideas floating around on d-rele...@l.d.o and on IRC how we can get that done better in the next try. Please let's work something out together which will actually work, and then do that. Cheers, Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100215103444.gp19...@mails.so.argh.org
Re: JPEG 8 transition
On 2010-02-14, Marc 'HE' Brockschmidt wrote: > I think we might even do this before releazing squeeze. Once we have > versioned symbols, the transition won't hurt as much. > > The current situation is quite problematic, as we can't foresee how many > package can break after partial upgrades. We know at least of one issue > when kdm loads both libjpeg62 and libjpeg8, but there will probably > dozens of other problems. I wrote a couple of lines yesterday on irc that no matter what we do that involves libjpeg8, it will break running lsb GUI apps. A lsb app is expected to be able to use system libraries of Qt or GTK and libjpeg62 and is built against a libjpeg without versioned symbols. The system libraries of GTK or Qt has plugins to pull in system libjpeg, which then will load libjpeg when the library's image routines is used for a jpeg image. If GTK or Qt is using libjpeg8 for jpeg handling, we have the disaster. The more I look into this, the more it looks like libjpeg is a library that can never ever change SONAME, until it from upstream side is symbol versioned *and* the versioned symbols is written into LSB. /Sune -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhni28d.nfa.nos...@sshway.ssh.pusling.com
Re: JPEG 8 transition
* Sune Vuorela (nos...@vuorela.dk) [100214 23:32]: > On 2010-02-14, Marc 'HE' Brockschmidt wrote: > > --=-=-= > > Content-Transfer-Encoding: quoted-printable > > > > Andreas Barth writes: > >> * Sune Vuorela (nos...@vuorela.dk) [100214 21:32]: > >>> I currently think roll-back, doing things properly, going ahead, is the > >>> way forward. > >> I fear I need to agree with you. We should have libjpeg62 with > >> symbols, recompile every package build-depending on libjpeg*-dev after > >> that till the release, and then move to libjpeg8 (or whatever it is) > >> at the begining of the squeeze+1-cycle (and we can be sure nothing > >> breaks because of the symbols). > > > > I think we might even do this before releazing squeeze. Once we have > > versioned symbols, the transition won't hurt as much. > > Except breaking partial upgrades We could conflict with the versions in lenny though. But that can be discussed after the current breakage has been fixed. Cheers, Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100215083439.go19...@mails.so.argh.org
Re: JPEG 8 transition
On 2010-02-14, Marc 'HE' Brockschmidt wrote: > --=-=-= > Content-Transfer-Encoding: quoted-printable > > Andreas Barth writes: >> * Sune Vuorela (nos...@vuorela.dk) [100214 21:32]: >>> I currently think roll-back, doing things properly, going ahead, is the >>> way forward. >> I fear I need to agree with you. We should have libjpeg62 with >> symbols, recompile every package build-depending on libjpeg*-dev after >> that till the release, and then move to libjpeg8 (or whatever it is) >> at the begining of the squeeze+1-cycle (and we can be sure nothing >> breaks because of the symbols). > > I think we might even do this before releazing squeeze. Once we have > versioned symbols, the transition won't hurt as much. Except breaking partial upgrades /Sune -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhngudn.nfa.nos...@sshway.ssh.pusling.com
Re: JPEG 8 transition
Andreas Barth writes: > * Sune Vuorela (nos...@vuorela.dk) [100214 21:32]: >> I currently think roll-back, doing things properly, going ahead, is the >> way forward. > I fear I need to agree with you. We should have libjpeg62 with > symbols, recompile every package build-depending on libjpeg*-dev after > that till the release, and then move to libjpeg8 (or whatever it is) > at the begining of the squeeze+1-cycle (and we can be sure nothing > breaks because of the symbols). I think we might even do this before releazing squeeze. Once we have versioned symbols, the transition won't hurt as much. The current situation is quite problematic, as we can't foresee how many package can break after partial upgrades. We know at least of one issue when kdm loads both libjpeg62 and libjpeg8, but there will probably dozens of other problems. > In other words, please rollback libjpeg-dev to point again to > libjpeg62-dev, and add symbol versions to libjpeg62 (the second can > happen later, but as sooner it happens the better it is). After > libjpeg-dev points again to libjpeg62-dev, we need to binNMU all > affected programs. ACK. Marc -- BOFH #202: kernel panic: write-only-memory (/dev/wom0) capacity exceeded. pgpuHyRaDgjed.pgp Description: PGP signature
Re: JPEG 8 transition
* Sune Vuorela (nos...@vuorela.dk) [100214 21:32]: > On 2010-02-14, Andreas Barth wrote: > >> So I will state it a last time: > >> I propose to upload the libjpeg6b source package that generate > >> libjpeg62 and libjpeg6b-dev (*not* libjpeg62-dev) and to upload > >> libjpeg8 source package that generate a libjpeg8-dev that provides > >> both libjpeg62-dev and libjpeg-dev. > >> Do the release team want me to do that ? > > > > We first want to have the crashes fixed. Which even might be an > > rollback. After we have found out what do do, we can continue > > discussing that. > As stated by Pierre several months ago, loading both into the same > process is a recipe for disaster. And it is going to be seen very much > in KDE when qt is rebuilt, but kde libraries isn't. > > libkhtml.so.5 links libjpeg. libkhtml is used in many places, including > most times when you want to render html. It is often used as a plugin > thru the kpart technology, meaning that it is available in most KDE > apps. > > libQtGui.so.4 is using libjpeg thru > /usr/lib/qt4/plugins/imageformats/libqjpeg.so to load jpg images > wherever needed, and it is happening in many places. > > AS long as both links the same libjpeg, everything is fine. Wehn they > use different libjpeg, hard to track down crashes. > > I currently think roll-back, doing things properly, going ahead, is the > way forward. I fear I need to agree with you. We should have libjpeg62 with symbols, recompile every package build-depending on libjpeg*-dev after that till the release, and then move to libjpeg8 (or whatever it is) at the begining of the squeeze+1-cycle (and we can be sure nothing breaks because of the symbols). If we don't roll-back, we need to have breaks from libjpeg8 to every package which links to libjpeg62. This is possible, but ugly, and would make the upgrade harder (and as Julien said "this is what symbol versions are for", so let's use them). In other words, please rollback libjpeg-dev to point again to libjpeg62-dev, and add symbol versions to libjpeg62 (the second can happen later, but as sooner it happens the better it is). After libjpeg-dev points again to libjpeg62-dev, we need to binNMU all affected programs. Cheers, Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214204457.gn19...@mails.so.argh.org
Re: JPEG 8 transition
On 2010-02-14, Andreas Barth wrote: >> So I will state it a last time: >> I propose to upload the libjpeg6b source package that generate >> libjpeg62 and libjpeg6b-dev (*not* libjpeg62-dev) and to upload >> libjpeg8 source package that generate a libjpeg8-dev that provides >> both libjpeg62-dev and libjpeg-dev. >> Do the release team want me to do that ? > > We first want to have the crashes fixed. Which even might be an > rollback. After we have found out what do do, we can continue > discussing that. As stated by Pierre several months ago, loading both into the same process is a recipe for disaster. And it is going to be seen very much in KDE when qt is rebuilt, but kde libraries isn't. libkhtml.so.5 links libjpeg. libkhtml is used in many places, including most times when you want to render html. It is often used as a plugin thru the kpart technology, meaning that it is available in most KDE apps. libQtGui.so.4 is using libjpeg thru /usr/lib/qt4/plugins/imageformats/libqjpeg.so to load jpg images wherever needed, and it is happening in many places. AS long as both links the same libjpeg, everything is fine. Wehn they use different libjpeg, hard to track down crashes. I currently think roll-back, doing things properly, going ahead, is the way forward. /Sune -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhngnd5.nfa.nos...@sshway.ssh.pusling.com
Re: JPEG 8 transition
On 2010-02-14, Andreas Barth wrote: >> So I will state it a last time: >> I propose to upload the libjpeg6b source package that generate >> libjpeg62 and libjpeg6b-dev (*not* libjpeg62-dev) and to upload >> libjpeg8 source package that generate a libjpeg8-dev that provides >> both libjpeg62-dev and libjpeg-dev. >> Do the release team want me to do that ? > > We first want to have the crashes fixed. Which even might be an > rollback. After we have found out what do do, we can continue > discussing that. I got a plan. The plan will fail dependening on the following question: Can apt figure out to upgrade a virtual package to a real package if needed? The major issue is: if libjpeg62 and libjpeg8 gets loaded into the same process, things will start crashing horribly. In order for things to not break horribly *both* libraries need to have versioned symbols. This plan involves 2 rebuildings of everything and a couple of sourceful uploads of both versions of libjpeg, and maybe sourceful uploads of packages requiring libjpeg8-dev either for running or building. The plan goes as follows: first upload of libjpeg6b * Add symbol versioning to libjpeg62 library * make libjpeg62 provide libjpeg62-versioned (name is up for discussion) * rename -dev package to libjpeg6b-dev and make it provide libjpeg62-dev and libjpeg-dev * make shlib file of libjpeg62 say libjpeg62-versioned unversioned and no mentioning of libjpeg62. first upload of libjpeg8, at the same time as first upload of libjpeg6b * add symbol versioning to libjpeg8 library * make -dev package not provide libjpeg-dev get libjpeg6b into testing very fast binNMU everything depending on libjpeg62 and let it migrate to testing *maybe* upload everything build-depending on libjpeg8-dev an replace it with a unversioned dependency|build-dependency. 2nd upload of libjpeg6b: * rename libjpeg62 to libjpeg62-versioned * make libjpeg62-versioned conflict with libjpeg62 Get this into testing. 3rd upload of libjpeg6b: * drop the libjpeg62-dev and libjpeg-dev provides from the -dev package 2nd upload of libjpeg8 (at the same time as 3rd upload of libjpeg6b) * make -dev package provide libjpeg62-dev and libjpeg-dev Let everything migrate to testing slowly binNMU things and let it trickle into testing at its own pace Teach people about libraries. victory. Any comments? > This is the worst (or one of the worst) transitions I've ever seen > since I joined Debian. there is definately room for improvement here. /Sune -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhng0th.nfa.nos...@sshway.ssh.pusling.com
Re: JPEG 8 transition
* Bill Allombert (bill.allomb...@math.u-bordeaux1.fr) [100214 13:22]: > On Sun, Feb 14, 2010 at 12:17:42PM +0100, Andreas Barth wrote: > > * Bill Allombert (bill.allomb...@math.u-bordeaux1.fr) [100214 10:19]: > > > The second step would be to fix packages that Build-Depend on > > > 'libjpeg62-dev' > > > to Build-Depend on 'libjpeg-dev' instead, but that might make theirs > > > build-dependencies unsatisfiable until they have been fixed. Again, > > > please do > > > not make them Build-Depend on 'libjpeg8-dev', or > > > 'libjpeg-dev|libjpeg62-dev' or > > > 'libjpeg-dev|libjpeg8-dev' or other combinaisons. > > > > Sorry, but that's *way* too messy. Why don't you answer the mails we > > send you before sending something out to d-d-a? This single action > > will delay the release of Squeeze for a couple of weeks. > > Which one ? I think I replied to every single mail from debian-release > that deserved an answer. Oh, any from last September like <20090920193000.gj26...@artemis.corp>. This would have told you why we get programs crashing for funny reasons if one of the libaries isn't versioned, and also how to do it properly. > > I'm totally annoyed by the lack of coordination, generating > > unnecessary work etc. > > So do I, in the other way. At least the email to d-d-a improved that, > and I do not think following its recommendation can make anything worse. You are only wasting everyones time, but I'm not going to argue about that. I would really appreciate if you coordinate with us, and take our recommendations serious. > So I will state it a last time: > I propose to upload the libjpeg6b source package that generate > libjpeg62 and libjpeg6b-dev (*not* libjpeg62-dev) and to upload > libjpeg8 source package that generate a libjpeg8-dev that provides > both libjpeg62-dev and libjpeg-dev. > Do the release team want me to do that ? We first want to have the crashes fixed. Which even might be an rollback. After we have found out what do do, we can continue discussing that. This is the worst (or one of the worst) transitions I've ever seen since I joined Debian. Cheers, Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214123330.gm19...@mails.so.argh.org
Re: JPEG 8 transition
On Sun, Feb 14, 2010 at 12:17:42PM +0100, Andreas Barth wrote: > * Bill Allombert (bill.allomb...@math.u-bordeaux1.fr) [100214 10:19]: > > The second step would be to fix packages that Build-Depend on > > 'libjpeg62-dev' > > to Build-Depend on 'libjpeg-dev' instead, but that might make theirs > > build-dependencies unsatisfiable until they have been fixed. Again, please > > do > > not make them Build-Depend on 'libjpeg8-dev', or > > 'libjpeg-dev|libjpeg62-dev' or > > 'libjpeg-dev|libjpeg8-dev' or other combinaisons. > > Sorry, but that's *way* too messy. Why don't you answer the mails we > send you before sending something out to d-d-a? This single action > will delay the release of Squeeze for a couple of weeks. Which one ? I think I replied to every single mail from debian-release that deserved an answer. > I'm totally annoyed by the lack of coordination, generating > unnecessary work etc. So do I, in the other way. At least the email to d-d-a improved that, and I do not think following its recommendation can make anything worse. > Can we please come to an plan how to fix that mess which doesn't > involve the upload of more than 200 source packages and ties them to > this transition? How about making (at least for the moment) > libjpeg62-dev an transition-only package to libjepg8-dev? That would > allow us to at least not block so many packages. (We can always at > a later moment change that back - or have lintian warnings that > build-depends on libjpeg62-dev should be dropped, or have an > libjpeg62real-dev, or whatever - but now we need to get the archive > and the testing migration operational again.) I proposed to do that on debian-release already, but this was rejected. So I will state it a last time: I propose to upload the libjpeg6b source package that generate libjpeg62 and libjpeg6b-dev (*not* libjpeg62-dev) and to upload libjpeg8 source package that generate a libjpeg8-dev that provides both libjpeg62-dev and libjpeg-dev. Do the release team want me to do that ? Cheers, -- Bill. Imagine a large red swirl here. signature.asc Description: Digital signature
Re: JPEG 8 transition
* Bill Allombert (bill.allomb...@math.u-bordeaux1.fr) [100214 10:19]: > The second step would be to fix packages that Build-Depend on 'libjpeg62-dev' > to Build-Depend on 'libjpeg-dev' instead, but that might make theirs > build-dependencies unsatisfiable until they have been fixed. Again, please do > not make them Build-Depend on 'libjpeg8-dev', or 'libjpeg-dev|libjpeg62-dev' > or > 'libjpeg-dev|libjpeg8-dev' or other combinaisons. Sorry, but that's *way* too messy. Why don't you answer the mails we send you before sending something out to d-d-a? This single action will delay the release of Squeeze for a couple of weeks. I'm totally annoyed by the lack of coordination, generating unnecessary work etc. Can we please come to an plan how to fix that mess which doesn't involve the upload of more than 200 source packages and ties them to this transition? How about making (at least for the moment) libjpeg62-dev an transition-only package to libjepg8-dev? That would allow us to at least not block so many packages. (We can always at a later moment change that back - or have lintian warnings that build-depends on libjpeg62-dev should be dropped, or have an libjpeg62real-dev, or whatever - but now we need to get the archive and the testing migration operational again.) In other words, unless you object, I'm planing to make the necessary changes. If you have another way that avoids 200+ uploads at this moment and glueing them all together that's fine, but do that fast. If you object otherwise, I'm going to put that to the tech ctte. Cheers, Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214111742.gl19...@mails.so.argh.org
