Bug#772183: unblock: libjpeg6b/1:6b2-2
On Mon, Mar 16, 2015 at 11:09:10PM +0100, Niels Thykier wrote: Hi Bill, Just to make it clear: * You seem to be making the case that we have lost the ability to produce (truly) LSB compliant binaries and the tech-ctte were not fully informed about the true scope of the consequences of their resolution. No I am not making this case, because again, the CTTE referal is unrelated to libjpeg62. The CTTE did not statue on the removal of libjpeg62 from stable, ans so did not have to consider this issue, or any other. * As it is, I currently consider this to be end of topic for me. Short of the tech-ctte reopening the case, I am /not/ expecting to reply to any further comments to this thread/topic. What I have been asking for is a rationale for removing a package that has been in stable for more than 15 years without any prior notice. So are you suggesting I request the CTTE to ask you to publish a rationale for the removal of libjpeg62 ? Cheers, Bill. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150319235242.ga31...@pari.math.u-bordeaux1.fr
Bug#772183: unblock: libjpeg6b/1:6b2-2
On 16/03/15 23:09, Niels Thykier wrote: - Mind you, as I understand Simon (in his response to my mail), we seem to already have lost that ability in 2007 when we stopped shipping glib2.12. Actually I understand his message to say the opposite. GLib 2.42 is API and ABI compatible with GLib 2.12, which means we are compatible with the LSB in that regard. Binaries that want to be LSB compatible need to limit themselves to the symbols from GLib 2.12 specified in the LSB. This is the same as for libjpeg-turbo. It is API and ABI compatible with libjpeg62. So software that was LSB compatible before will still be. So there should be problem with us only shipping libjpeg-turbo. Emilio -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5507e706.3040...@debian.org
Bug#772183: unblock: libjpeg6b/1:6b2-2
On 2015-03-17 09:34, Emilio Pozuelo Monfort wrote: On 16/03/15 23:09, Niels Thykier wrote: - Mind you, as I understand Simon (in his response to my mail), we seem to already have lost that ability in 2007 when we stopped shipping glib2.12. Actually I understand his message to say the opposite. GLib 2.42 is API and ABI compatible with GLib 2.12, which means we are compatible with the LSB in that regard. Binaries that want to be LSB compatible need to limit themselves to the symbols from GLib 2.12 specified in the LSB. This is the same as for libjpeg-turbo. It is API and ABI compatible with libjpeg62. So software that was LSB compatible before will still be. I suspect you misunderstand this part of the debate. We already concluded that libjpeg-turbo is ABI compliant with the LSB specs. I believe Bill's argument was that to build truly LSB compliant software, we would need to have the old version to ensure FTBFS to avoid accidental use of newer features. My argument is that given we do not have that hard limiter on GLib any more (it also have non-LSB symbols/APIs), we already lost this ability in general to ensure that a given piece of software compiled in Debian will be 100% LSB compliant by just relying on simple FTBFS as test mechanism. So there should be problem with us only shipping libjpeg-turbo. Emilio The above sentence seems to be missing a word, which makes it rather ambiguous. :) Though based on your arguments, I will assume you mean there should be /no/ problem with Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5507e96a.3070...@thykier.net
Bug#772183: unblock: libjpeg6b/1:6b2-2
Hi Bill, Just to make it clear: * You seem to be making the case that we have lost the ability to produce (truly) LSB compliant binaries and the tech-ctte were not fully informed about the true scope of the consequences of their resolution. - If you feel they were uninformed, then please bring this to the tech-ctte. - Mind you, as I understand Simon (in his response to my mail), we seem to already have lost that ability in 2007 when we stopped shipping glib2.12. * I am not convinced that you were uninformed of the consequences of the tech-ctte resolution, which included our intention. - I am ready to believe you when you say that you made assumptions regarding whether the removal would happen for the IJG implementation. However, I fail to see why your (until recently) unvoiced assumptions should suddenly undermine these decisions. * As it is, I currently consider this to be end of topic for me. Short of the tech-ctte reopening the case, I am /not/ expecting to reply to any further comments to this thread/topic. Yours truly, ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55075486.6050...@thykier.net
Bug#772183: unblock: libjpeg6b/1:6b2-2
Niels Thykier wrote: On 2015-03-14 14:12, Bill Allombert wrote: IJG libjpeg62 has been in Debian for more than 15 years. IJG libjpeg62 is still required for building LSB packages. Without it, jessie will not be usable for building LSB packages. You mean to say that [...] libjpeg62-turbo does not implement the [LSB 4.1 SPEC]? At least a quick search suggests that only Simon McVittie ever mentions LSB [in the CTTE bug]. Since my name has been mentioned... I did not intend my mention of the LSB in #717076 to be an assertion that we should specifically be shipping IJG libjpeg6b, only that there is some value in shipping a library compatible with the LSB subset of the libjpeg6b ABI. Drawing an analogy with another library specified by LSB, the LSB Desktop specification v4.1 calls for a library that is ABI-compatible with GLib 2.12. It does not call for GLib 2.12 specifically, which is just as well, because we haven't shipped that version since 2007 according to the glib2.0 changelog; instead, we ship a version that implements a superset of the specification, with considerably more symbols, which even deprecates (but, crucially, does not remove) many of the symbols required by the LSB. Non-LSB applications in Debian may depend on the new functionality of GLib 2.42 (with suitable dependencies) - indeed, as a GLib contributor I would argue that in many cases they *should* depend on the new functionality, which was added for a reason - but LSB applications must not. Similarly, as far as I am aware, libjpeg62-turbo implements a superset of the ABI of IJG libjpeg6b. Non-LSB applications like (Debian's build of) ioquake3 may rely on the extra functions, with suitable dependencies, but LSB applications must not. LSB compliance only requires that all correct LSB applications work: it does not require that applications developed on Debian cannot accidentally come to rely on non-LSB functionality. (I suspect the Steam Runtime (i.e. mostly the ABI of Ubuntu 12.04 LTS) might be a more commercially relevant baseline ABI than the LSB these days... but it's relatively easy to provide LSB interfaces, as long as we continue to ship obsolete libraries like Gtk 2, Qt 3, etc.) Regards, S -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/550576c5.5080...@debian.org
Bug#772183: unblock: libjpeg6b/1:6b2-2
On Sat, Mar 14, 2015 at 11:22:17AM +0100, Niels Thykier wrote: On 2015-02-23 17:49, Niels Thykier wrote: Control: tags -1 wontfix [...] As debated in #774737, we will only be shipping with one implementation of libjpeg, so I am afraid I will have to decline this request. Hello Niels, The release team has yet to provide a rationale for this decision. It is quite unprecedented for the release team to reject a package without providing a justification. IJG libjpeg62 has been in Debian for more than 15 years. IJG libjpeg62 is still required for building LSB packages. Without it, jessie will not be usable for building LSB packages. Cheers, Bill -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150314131238.ga29...@pari.math.u-bordeaux1.fr
Bug#772183: unblock: libjpeg6b/1:6b2-2
On Sat, Mar 14, 2015 at 04:58:37PM +0100, Niels Thykier wrote: On 2015-03-14 14:12, Bill Allombert wrote: On Sat, Mar 14, 2015 at 11:22:17AM +0100, Niels Thykier wrote: On 2015-02-23 17:49, Niels Thykier wrote: Control: tags -1 wontfix [...] As debated in #774737, we will only be shipping with one implementation of libjpeg, so I am afraid I will have to decline this request. Hello Niels, The release team has yet to provide a rationale for this decision. It is quite unprecedented for the release team to reject a package without providing a justification. Hi Bill, We (the RT and security team) have on numerous occasions chosen to only ship and support at most one implementation of a given interface/program/etc. It happens on a regular basis. Indeed, but this stay exceptional event and in all case so far some rationale were provided. This is not the case here. People ask me what happened and I cannot answer. IJG libjpeg62 has been in Debian for more than 15 years. IJG libjpeg62 is still required for building LSB packages. Without it, jessie will not be usable for building LSB packages. You mean to say that: 1. our lsb packages will FTBFS/be uninstallable in Jessie in the absence of libjpeg62? 2. libjpeg62-turbo does not implement the [LSB 4.1 SPEC]? No I do not mean any of these. libjpeg62-turbo can be used to execute LSB binaries. However to compile true LSB binaries (that can run on non libjpeg-turbo LSB system) still require IJG libjpeg62, because libjpeg-turbo pull in extra symbols. AFAICT, it cannot be 1) given that the lsb packages seems to depend on libjpeg62-turbo. So I am guessing you mean 2)? In which case, you seem to have failed to mention this to the tech-ctte when the issue was brought before them in [#717076]. At least a quick search suggests that only Simon McVittie ever mentions LSB. Though by all means, please prove me wrong if I missed it - I did not re-read the entire thread. If you indeed failed to mention it, then I suggest you ask the tech-ctte to reconsider their position. Our decision will remain unchanged unless the tech-ctte amends their decision. The question the CTTE was referred is unrelated to libjpeg62, and the CTTE did not ask for my input. Given its history, I never fancied there was actual plan to remove libjpeg62 from stable. Cheers, Bill. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150314173334.ga5...@pari.math.u-bordeaux1.fr
Bug#772183: unblock: libjpeg6b/1:6b2-2
On 2015-03-14 14:12, Bill Allombert wrote: On Sat, Mar 14, 2015 at 11:22:17AM +0100, Niels Thykier wrote: On 2015-02-23 17:49, Niels Thykier wrote: Control: tags -1 wontfix [...] As debated in #774737, we will only be shipping with one implementation of libjpeg, so I am afraid I will have to decline this request. Hello Niels, The release team has yet to provide a rationale for this decision. It is quite unprecedented for the release team to reject a package without providing a justification. Hi Bill, We (the RT and security team) have on numerous occasions chosen to only ship and support at most one implementation of a given interface/program/etc. It happens on a regular basis. IJG libjpeg62 has been in Debian for more than 15 years. IJG libjpeg62 is still required for building LSB packages. Without it, jessie will not be usable for building LSB packages. Cheers, Bill You mean to say that: 1. our lsb packages will FTBFS/be uninstallable in Jessie in the absence of libjpeg62? 2. libjpeg62-turbo does not implement the [LSB 4.1 SPEC]? AFAICT, it cannot be 1) given that the lsb packages seems to depend on libjpeg62-turbo. So I am guessing you mean 2)? In which case, you seem to have failed to mention this to the tech-ctte when the issue was brought before them in [#717076]. At least a quick search suggests that only Simon McVittie ever mentions LSB. Though by all means, please prove me wrong if I missed it - I did not re-read the entire thread. If you indeed failed to mention it, then I suggest you ask the tech-ctte to reconsider their position. Our decision will remain unchanged unless the tech-ctte amends their decision. Yours truly, ~Niels [LSB 4.1 SPEC]: http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic.html#LIBJPEG62 [#717076]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717076 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55045aad.5050...@thykier.net
Bug#772183: unblock: libjpeg6b/1:6b2-2
Control: tags -1 wontfix On 2014-12-05 23:47, Bill Allombert wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dera release team, Please unblock package libjpeg6b (and unstuck it from NEW). libjpeg6b binaries were hijacked by the libjpeg-turbo source package, but this have been resolved. So I made a new libjpeg6b upload so that the libjpeg6b binaries get rebuilt. However this caused libjpeg6b to be directed to the NEW queue, which is still there. So it missed the freeze deadline Given that libjpeg6b is in wheezy, and the package was fully expected to be released in jessie before it was hijacked, I would appreciate if you would unstuck it. unblock libjpeg6b/1:6b2-2 Thanks for your understanding, As debated in #774737, we will only be shipping with one implementation of libjpeg, so I am afraid I will have to decline this request. Yours truly, ~Niels -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54eb5a2d.5010...@thykier.net
Processed: Re: Bug#772183: unblock: libjpeg6b/1:6b2-2
Processing control commands: tags -1 wontfix Bug #772183 [release.debian.org] unblock: libjpeg6b/1:6b2-2 Added tag(s) wontfix. -- 772183: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=772183 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b772183.142471020124497.transcr...@bugs.debian.org
Bug#772183: unblock: libjpeg6b/1:6b2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dera release team, Please unblock package libjpeg6b (and unstuck it from NEW). libjpeg6b binaries were hijacked by the libjpeg-turbo source package, but this have been resolved. So I made a new libjpeg6b upload so that the libjpeg6b binaries get rebuilt. However this caused libjpeg6b to be directed to the NEW queue, which is still there. So it missed the freeze deadline Given that libjpeg6b is in wheezy, and the package was fully expected to be released in jessie before it was hijacked, I would appreciate if you would unstuck it. unblock libjpeg6b/1:6b2-2 Thanks for your understanding, -- Bill. ballo...@debian.org 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: https://lists.debian.org/20141205224723.GA10277@yellowpig
