Processed: Re: Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
Processing control commands: > retitle -1 unblock: openjpeg/1.3+dfsg-4.6 Bug #681717 [release.debian.org] unblock: openjpeg/1.3+dfsg-4.5 Changed Bug title to 'unblock: openjpeg/1.3+dfsg-4.6' from 'unblock: openjpeg/1.3+dfsg-4.5' -- 681717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681717 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: http://lists.debian.org/handler.s.b681717.13509394249080.transcr...@bugs.debian.org
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
control: retitle -1 unblock: openjpeg/1.3+dfsg-4.6 On Sun, Oct 14, 2012 at 5:38 AM, Julien Cristau wrote: > On Sat, Oct 13, 2012 at 17:59:37 -0400, Michael Gilbert wrote: >> Please review the attached patch, and let me know if it is ok to >> upload to unstable. The security issue is fixed, and the tool >> binaries are now not excluded from the -dbg package. >> > Go ahead. Uploaded. Please unblock 1.3+dfsg-4.6. Thanks, Mike -- 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/CANTw=MPjy9CS__aM=e_g8f9_hagntfsxajmhvg3cfnww15s...@mail.gmail.com
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Sat, Oct 13, 2012 at 17:59:37 -0400, Michael Gilbert wrote: > > Needing to debug the tools is both a lot more unlikely than debugging > > the library or something that uses it, and easy enough to build a debug > > version of the tool (which you need to do anyway to debug). So I don't > > think this is a problem. > > Please review the attached patch, and let me know if it is ok to > upload to unstable. The security issue is fixed, and the tool > binaries are now not excluded from the -dbg package. > Go ahead. Cheers, Julien signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
> Needing to debug the tools is both a lot more unlikely than debugging > the library or something that uses it, and easy enough to build a debug > version of the tool (which you need to do anyway to debug). So I don't > think this is a problem. Please review the attached patch, and let me know if it is ok to upload to unstable. The security issue is fixed, and the tool binaries are now not excluded from the -dbg package. Best wishes, Mike openjpeg.patch Description: Binary data
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Fri, Oct 12, 2012 at 16:29:21 -0400, Michael Gilbert wrote: > On Fri, Oct 12, 2012 at 4:05 AM, Julien Cristau wrote: > > On Thu, Oct 11, 2012 at 20:34:08 -0400, Michael Gilbert wrote: > > > >> So, the -dbg issue has to do with way in which debug files are > >> compared betwen different arch m-a:same packages. At compat level 9 > >> hashes of the paths are used vs. actual file contents at lower compt > >> levels. Consequently, debug packages cannot be m-a:same at lower > >> compat levels. > >> > > debug packages for a multiarch library have different paths on each > > arch. The bug here IMO is to include debug symbols for the tools in > > libopenjpeg2-dbg. > > Yes, of course that would work, but what about when someone wants to > debug one of the tools. We would need a separate package for that, > but creating a new debug package just for the tools is an intrusive > change at this point. > Needing to debug the tools is both a lot more unlikely than debugging the library or something that uses it, and easy enough to build a debug version of the tool (which you need to do anyway to debug). So I don't think this is a problem. > So, since compat 9 is off the table, I think it best to just not > multiarch the debug package, which lets the user select the right > package for the arch that they're interested in debugging. > *shrug* Cheers, Julien signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Fri, Oct 12, 2012 at 4:05 AM, Julien Cristau wrote: > On Thu, Oct 11, 2012 at 20:34:08 -0400, Michael Gilbert wrote: > >> So, the -dbg issue has to do with way in which debug files are >> compared betwen different arch m-a:same packages. At compat level 9 >> hashes of the paths are used vs. actual file contents at lower compt >> levels. Consequently, debug packages cannot be m-a:same at lower >> compat levels. >> > debug packages for a multiarch library have different paths on each > arch. The bug here IMO is to include debug symbols for the tools in > libopenjpeg2-dbg. Yes, of course that would work, but what about when someone wants to debug one of the tools. We would need a separate package for that, but creating a new debug package just for the tools is an intrusive change at this point. So, since compat 9 is off the table, I think it best to just not multiarch the debug package, which lets the user select the right package for the arch that they're interested in debugging. Best wishes, Mike -- 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/CANTw=moukzofeetarqxnitcajqendxejgxz4rmue6oxptuk...@mail.gmail.com
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Thu, Oct 11, 2012 at 20:34:08 -0400, Michael Gilbert wrote: > So, the -dbg issue has to do with way in which debug files are > compared betwen different arch m-a:same packages. At compat level 9 > hashes of the paths are used vs. actual file contents at lower compt > levels. Consequently, debug packages cannot be m-a:same at lower > compat levels. > debug packages for a multiarch library have different paths on each arch. The bug here IMO is to include debug symbols for the tools in libopenjpeg2-dbg. Cheers, Julien signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Wed, Sep 26, 2012 at 2:50 PM, Julien Cristau wrote: > On Wed, Sep 19, 2012 at 01:27:15 -0400, Michael Gilbert wrote: > >> On Thu, Aug 16, 2012 at 5:18 AM, Jon Severinsson wrote: >> > Release note that this bug blocks sound from working in wine and other i386 >> > applications on amd64 in wheezy for many configurations (including mine). >> > >> > That is because libopenjpeg2 is required by libavcodec53 which is required >> > by >> > libasound2-plugins, which I need in both amd64 and i386 flavours to get >> > sound >> > to work in both 64 and 32 bit applications. >> >> Trying this one more time since I would really like the wine sound >> situation to be of high quality with the wheezy release. >> >> Attached is a patch (diffed against testing) that reverts back to >> debhelper 5 but otherwise retains the multiarch conversion, which is >> needed to resolve said sound situation. >> >> I know this is late, and its been late, but multiarch openjpeg has >> been in unstable for over 60 days without issue related to multiarch. >> So, in my opinion its far less risky than it may seem. But anyway I >> certainly respect alternative viewpoints. >> >> Anyway, the patch attached is for review and I will not upload without >> pre-approval. >> > This approach looks ok to me. I'm guessing it needs an additional patch > for CVE-2012-3535 though. One thing I don't understand is the comment > about the -dbg package in the changelog. Care to explain what the > problem is? Apologies for the delay, I've been too busy lately. So, the -dbg issue has to do with way in which debug files are compared betwen different arch m-a:same packages. At compat level 9 hashes of the paths are used vs. actual file contents at lower compt levels. Consequently, debug packages cannot be m-a:same at lower compat levels. Anyway, I'll look at applying the patch for CVE-2012-3535 and uploading to unstable in the next couple days, if that is reasonable? Best wishes, Mike -- 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/CANTw=MPxL_GALLCg0fWv3i9Y-TWMSAB=c_o16rkhq23j35n...@mail.gmail.com
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Wed, Sep 26, 2012 at 20:50:52 +0200, Julien Cristau wrote: > On Wed, Sep 19, 2012 at 01:27:15 -0400, Michael Gilbert wrote: > > > On Thu, Aug 16, 2012 at 5:18 AM, Jon Severinsson wrote: > > > Release note that this bug blocks sound from working in wine and other > > > i386 > > > applications on amd64 in wheezy for many configurations (including mine). > > > > > > That is because libopenjpeg2 is required by libavcodec53 which is > > > required by > > > libasound2-plugins, which I need in both amd64 and i386 flavours to get > > > sound > > > to work in both 64 and 32 bit applications. > > > > Trying this one more time since I would really like the wine sound > > situation to be of high quality with the wheezy release. > > > > Attached is a patch (diffed against testing) that reverts back to > > debhelper 5 but otherwise retains the multiarch conversion, which is > > needed to resolve said sound situation. > > > > I know this is late, and its been late, but multiarch openjpeg has > > been in unstable for over 60 days without issue related to multiarch. > > So, in my opinion its far less risky than it may seem. But anyway I > > certainly respect alternative viewpoints. > > > > Anyway, the patch attached is for review and I will not upload without > > pre-approval. > > > This approach looks ok to me. I'm guessing it needs an additional patch > for CVE-2012-3535 though. One thing I don't understand is the comment > about the -dbg package in the changelog. Care to explain what the > problem is? > Ping. Does anyone still want this in wheezy, or should I just close this bug? Cheers, Julien signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Wed, Sep 26, 2012 at 20:46:08 +0200, Julien Cristau wrote: > On Sun, Jul 15, 2012 at 17:43:54 -0400, Michael Gilbert wrote: > > > Package: release.debian.org > > User: release.debian@packages.debian.org > > Usertags: unblock > > Severity: normal > > > > Please unblock package openjpeg > > > > The unstable version enables multiarch and fixes a security issue. > > > Is there a particular reason this library needs to be multiarched in > wheezy? As in what multiarch-relevant package depends on it? > Sorry for the noise, I found the other part of the report. (Do I hate it when a conversation is broken up into multiple threads? Why yes, yes I do!) Cheers, Julien signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Wed, Sep 19, 2012 at 01:27:15 -0400, Michael Gilbert wrote: > On Thu, Aug 16, 2012 at 5:18 AM, Jon Severinsson wrote: > > Release note that this bug blocks sound from working in wine and other i386 > > applications on amd64 in wheezy for many configurations (including mine). > > > > That is because libopenjpeg2 is required by libavcodec53 which is required > > by > > libasound2-plugins, which I need in both amd64 and i386 flavours to get > > sound > > to work in both 64 and 32 bit applications. > > Trying this one more time since I would really like the wine sound > situation to be of high quality with the wheezy release. > > Attached is a patch (diffed against testing) that reverts back to > debhelper 5 but otherwise retains the multiarch conversion, which is > needed to resolve said sound situation. > > I know this is late, and its been late, but multiarch openjpeg has > been in unstable for over 60 days without issue related to multiarch. > So, in my opinion its far less risky than it may seem. But anyway I > certainly respect alternative viewpoints. > > Anyway, the patch attached is for review and I will not upload without > pre-approval. > This approach looks ok to me. I'm guessing it needs an additional patch for CVE-2012-3535 though. One thing I don't understand is the comment about the -dbg package in the changelog. Care to explain what the problem is? Cheers, Julien signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Sun, Jul 15, 2012 at 17:43:54 -0400, Michael Gilbert wrote: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > Severity: normal > > Please unblock package openjpeg > > The unstable version enables multiarch and fixes a security issue. > Is there a particular reason this library needs to be multiarched in wheezy? As in what multiarch-relevant package depends on it? Cheers, Julien signature.asc Description: Digital signature
Bug#681717: Re: Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
Hi, > Release note that this bug blocks sound from working in wine and > other i386 applications on amd64 in wheezy for many configurations > (including mine). > > That is because libopenjpeg2 is required by libavcodec53 which is > required by libasound2-plugins, which I need in both amd64 and i386 > flavours to get sound to work in both 64 and 32 bit applications. Indeed this would be a regression compared to Squeeze, where lib32asound-plugins was available. Kind regards, Ralf -- 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/5061c651.40...@ralfj.de
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Thu, Aug 16, 2012 at 5:18 AM, Jon Severinsson wrote: > Release note that this bug blocks sound from working in wine and other i386 > applications on amd64 in wheezy for many configurations (including mine). > > That is because libopenjpeg2 is required by libavcodec53 which is required by > libasound2-plugins, which I need in both amd64 and i386 flavours to get sound > to work in both 64 and 32 bit applications. Trying this one more time since I would really like the wine sound situation to be of high quality with the wheezy release. Attached is a patch (diffed against testing) that reverts back to debhelper 5 but otherwise retains the multiarch conversion, which is needed to resolve said sound situation. I know this is late, and its been late, but multiarch openjpeg has been in unstable for over 60 days without issue related to multiarch. So, in my opinion its far less risky than it may seem. But anyway I certainly respect alternative viewpoints. Anyway, the patch attached is for review and I will not upload without pre-approval. In related news, Paul Tagliamonte and I are heading up a BSP at Ohio Linux Fest next week (Sept. 28-30). I'm going to be working on rc bugs there anyway, but if this gets approved and causes any rc bugs, during that event I will personally commit to fixing 5 times as manybugs as those caused. So, anyway hopefully that offsets some of the risk averseness (appropriately) present in the release team. Anyway, even if there is a new bug, you get far fewer overall. Hopefully, that's a reasonable trade. Best wishes, Mike openjpeg.patch Description: Binary data
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
Release note that this bug blocks sound from working in wine and other i386 applications on amd64 in wheezy for many configurations (including mine). That is because libopenjpeg2 is required by libavcodec53 which is required by libasound2-plugins, which I need in both amd64 and i386 flavours to get sound to work in both 64 and 32 bit applications. signature.asc Description: This is a digitally signed message part.
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Mon, Jul 16, 2012 at 15:17:02 -0400, Michael Gilbert wrote: > Is > it the release team's opinion that multiarch conversions at this point > are invasive (even though multiarch is a release goal)? > It's my opinion that they're invasive, regardless of the timing. Cheers, Julien signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Mon, Jul 16, 2012 at 3:17 PM, Michael Gilbert wrote: > On Mon, Jul 16, 2012 at 3:09 PM, Philipp Kern wrote: >> On Sun, Jul 15, 2012 at 07:05:35PM -0400, Michael Gilbert wrote: >>> We are still in the early freeze where riskier changes are allowable, aren't >>> we? >> >> No. There's no such thing as an early freeze that allows riskier changes this >> cycle. We might be convinced that certain delays in preparing a final package >> for the next release might have been someone else's fault, but that's no "go >> for risky changes". > > "Riskier" may not have been the best qualifier for me to choose to > describe this. The right term I should have used is "invasive." Is > it the release team's opinion that multiarch conversions at this point > are invasive (even though multiarch is a release goal)? I'll also plead the case that I did have the work in before the freeze, but was blocked. The original multiarch nmu was uploaded to delayed/5 on June 16th (bug #675773), but it was canceled and blocked shortly thereafter. Then, I didn't get the go ahead to upload again until after the release team made a call on the 1.5 transition. I was busy the following days and didn't get to it again until July 2nd (two days after the freeze) when I uploaded to delayed/5. Best wishes, Mike -- 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/CANTw=MN+B=wj7bvoeha+lk-50_fjatalf3prcum6qwbtwwh...@mail.gmail.com
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Sun, Jul 15, 2012 at 07:05:35PM -0400, Michael Gilbert wrote: > We are still in the early freeze where riskier changes are allowable, aren't > we? No. There's no such thing as an early freeze that allows riskier changes this cycle. We might be convinced that certain delays in preparing a final package for the next release might have been someone else's fault, but that's no "go for risky changes". Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
On Mon, Jul 16, 2012 at 3:09 PM, Philipp Kern wrote: > On Sun, Jul 15, 2012 at 07:05:35PM -0400, Michael Gilbert wrote: >> We are still in the early freeze where riskier changes are allowable, aren't >> we? > > No. There's no such thing as an early freeze that allows riskier changes this > cycle. We might be convinced that certain delays in preparing a final package > for the next release might have been someone else's fault, but that's no "go > for risky changes". "Riskier" may not have been the best qualifier for me to choose to describe this. The right term I should have used is "invasive." Is it the release team's opinion that multiarch conversions at this point are invasive (even though multiarch is a release goal)? Best wishes, Mike -- 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/CANTw=moub79m6phfyt7hgxnjxwmrqfaqvuao5o5utc0vbpk...@mail.gmail.com
Processed: Re: Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
Processing commands for cont...@bugs.debian.org: > retitle 681717 unblock: openjpeg/1.3+dfsg-4.5 Bug #681717 [release.debian.org] unblock: openjpeg/1.3+dfsg-4.4 Changed Bug title to 'unblock: openjpeg/1.3+dfsg-4.5' from 'unblock: openjpeg/1.3+dfsg-4.4' > thanks Stopping processing here. Please contact me if you need assistance. -- 681717: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681717 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: http://lists.debian.org/handler.s.c.134239354130937.transcr...@bugs.debian.org
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
retitle 681717 unblock: openjpeg/1.3+dfsg-4.5 thanks On Sun, Jul 15, 2012 at 5:59 PM, Cyril Brulebois wrote: > Hello. > > Michael Gilbert (15/07/2012): >> Package: release.debian.org >> User: release.debian@packages.debian.org >> Usertags: unblock >> Severity: normal >> >> Please unblock package openjpeg >> >> The unstable version enables multiarch and fixes a security issue. >> >> unblock openjpeg/1.3+dfsg-4.4 > > Waiting after the freeze has happened to introduce such changes really > isn't appreciated, especially when you get them wrong, I agree. The situation with openjpeg is far from ideal. I was working on a lot of multiarch changes supporting wine, and this one got blocked for a while by people expecting the 1.5 transition to happen. Then the release team made the call on that a couple days before the freeze, at that point those opposing stopped opposing, and so I finally uploaded the multiarch nmu again to 1.3 but that was unfortunately late (two days after the freeze). You've probably already seen all the details of those discussions in #675773 and #669348. > That doesn't match: > 2. changes for release goals, if they are not invasive; Fortunately the multiarch conversion for this package was very straightforward and not very invasive, but I can understand your alternative perspective. We are still in the early freeze where riskier changes are allowable, aren't we? > Also, debhelper (>= 5) certainly isn't sufficient for those changes, is > it? I apologize for missing that. You are quite correct, that should have been bumped to 9 as well. I've just uploaded 1.3+dfsg-4.5 with that change. Best wishes, Mike -- 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/CANTw=MNYmKRVCxo2wUcAM=gcXjayAzmr=6pxob2ke9zs+8k...@mail.gmail.com
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
Hello. Michael Gilbert (15/07/2012): > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > Severity: normal > > Please unblock package openjpeg > > The unstable version enables multiarch and fixes a security issue. > > unblock openjpeg/1.3+dfsg-4.4 Waiting after the freeze has happened to introduce such changes really isn't appreciated, especially when you get them wrong, and when changelog entries absolutely don't describe the actual changes (1.3+dfsg-4.2 and 1.3+dfsg-4.3 notably). That doesn't match: 2. changes for release goals, if they are not invasive; in: http://release.debian.org/wheezy/freeze_policy.html Also, debhelper (>= 5) certainly isn't sufficient for those changes, is it? Other release team members may have a different opinion, but that's a no for me. One way to go from here is reverting the multiarch changes so that you get the security fix in. Another way would be t-p-u, but that means close to no testing, which isn't helpful. Mraw, KiBi. signature.asc Description: Digital signature
Bug#681717: unblock: openjpeg/1.3+dfsg-4.4
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package openjpeg The unstable version enables multiarch and fixes a security issue. unblock openjpeg/1.3+dfsg-4.4 -- 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/CANTw=mov6ek12rwjabef+q6w9shujcbegbcoa-sh_tfrx47...@mail.gmail.com
