Bug#674634: transition: celt
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We'd like to remove the celt package from the distro for the Wheezy release. CELT was an experimental codec from Xiph, and that work has now been merged into the Opus codec which is about to be ratified as an IETF standard. As a result of that, upstream is no longer maintaining celt at all, and being an experimental codec, no two releases of it were ever bitstream compatible with each other (and only one release was ever made that even maintained API compatibility with prior versions). All packages using it at the time knew and accepted that this would be the situation with it while it evolved ... The version that Debian currently is shipping we tried to get consensus on people agreeing to consider it an interoperability snapshot before squeeze, but in the end that never actually happened in practice and other distros shipped other incompatible versions of it anyway. So we (meaning myself, upstream, and anyone else who has discussed this with us in detail) see little value in continuing to ship this, and plenty of opportunity for Harm. Apps using it in Debian will only be interoperable with the Debian releases of themselves, there will be no security support, and it will just further fragment the codec space, at a time when there is a real standard alternative people should be looking at for the future. I'd have moved on this sooner, but it's only been in the last few days that we actually had enough certainty about the IETF process concluding to really know what the foreseeable future of all this was going to be. I've already been actively talking to upstreams of the affected packages to be sure we might actually pull this off in the time we have remaining, and I'm sure enough that this will be possible now to really propose a formal course of action for Wheezy. We've been planning for this in general terms for years now, but nothing could actually move until the IETF did. And now they have. Death, taxes, and bad timing. Anyhow, this actually should be fairly simple, being an experimental codec almost everything already has support for only optionally enabling it. So we just need sourceful uploads of packages to turn it off - then celt can safely be removed. Some of the deps have already been updated to remove it, the remaining ones as of yesterday were: # Broken Depends: gst-plugins-bad0.10: gstreamer0.10-plugins-bad jack-audio-connection-kit: jackd1 jackd2: jackd2 libjack-jackd2-0 mangler: libventrilo3-0 opal: libopal3.10.4 [amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc] roaraudio: libroar2 roaraudio Opal I've been told will remove it with its next upload. Mangler appears to be under control, details here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674244 gst, I've spoken to upstream and this is a no-brainer, but I still need to get a ping back from slomo about updating the package. jack should be just disable the option too, but I'm still chasing its Debian maintainer for confirmation of doing it. Worst case I should be able to do a trivial NMU myself. Roar, I've been assured by its upstream is likewise easy to just disable support for it - but the-me is giving me some pointless pushback ... I'll NMU that too when the time comes if really needed if this is the final blocker. There shouldn't be any other flow on from this so far as I know. Some of these packages may enable Opus support instead, but doing so is not a prerequisite for us being able to remove celt for Wheezy. Thanks! Ron -- 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/20120526090811.7081.20212.report...@audi.shelbyville.oz
Re: Bug#620322: libvncserver package split
2012/5/25 Julien Cristau jcris...@debian.org: Probably 2. OK, I'll prepare the changes and do some tests to verify everything is fine. Once I'm confident, I'll get in touch again to see whether I'm still in time to target Wheezy. -- 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/CADk7b0OX4sx=z61D5C7ZQHzy=8uzv_4eu2p8oj2ee8g9fkk...@mail.gmail.com
Processed: unblock 645105 with 672152
Processing commands for cont...@bugs.debian.org: unblock 645105 with 672152 Bug #645105 [release.debian.org] transition: gdal 645105 was blocked by: 673165 672152 648628 673594 673567 631019 669468 645105 was blocking: 674541 Removed blocking bug(s) of 645105: 672152 thanks Stopping processing here. Please contact me if you need assistance. -- 645105: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645105 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.133802812423515.transcr...@bugs.debian.org
Re: Please retry hugin 2011.4.0+dfsg-2 on s390
On 2012-05-25 Cyril Brulebois k...@debian.org wrote: Andreas Metzler ametz...@downhill.at.eu.org (25/05/2012): please retry hugin 2011.4.0+dfsg-2 (experimental) on s390. - It previously FTBFS due to swig issues which might now be fixed. This would alllow me to fix #671998 (FTBFS due to gcc4.7 in sid/testing). Yeah, that should be nice. kibi@grieg:~$ wb gb hugin . s390 . -d experimental Thank you, the rebuild seems to have worked. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- 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/2012052606.ga2...@downhill.g.la
Re: Comments regarding automake1.12_1.12-1_amd64.changes
2012/5/23 Eric Dorland e...@debian.org: I'll still be able to upload new versions of automake 1.11 if this upload is rejected right? Yes, a rejected upload won't interfere at all with other packages. -- 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/CADk7b0ONqg7cRrysw0rEvs8UuKpoejuin4TXwOC2Fn=hx7p...@mail.gmail.com
Re: [Pkg-xfce-devel] Bug#668806: Bug#668806: Bits from the Release Team: Freeze approaching!
On lun., 2012-05-14 at 23:13 +0200, Yves-Alexis Perez wrote: On lun., 2012-05-14 at 20:45 +0200, Cyril Brulebois wrote: Hello Yves-Alexis, Yves-Alexis Perez cor...@debian.org (14/05/2012): This is just a friendly ping about #668806. I think it's safe to say that we won't squeeze Xfce 4.10 in Wheezy, but at least paving the way for Wheezy+1 upgrades would be better. as discussed on IRC, I think having “traditional” transitions would be the easiest for everyone, we have tools to handle them. Worst case, you don't actually need to bump the soname for one release; then you just don't bump it, and done. I don't see any drawback with this approach. And thanks for the friendly ping. Ok, since it seems things are a bit unclear, we can't really use the traditional (soname) way because we would need to split the binary and the lib and then we might have: xfce4-foo-plugin built against libxfce4panel.so.1 (Xfce 4.6) xfce4-bar-plugin built against libxfce4panel-1.0.so.3 (Xfce 4.8) with both lib packages installed. But we can only have one binary xfce4-package installed (4.8), and at runtime, xfce4-foo-plugin won't load in xfce4-panel 4.8. So we do need to have stricter dependencies than soname here. After a bit more thinking, we may have a way to split libxfce4panel in Wheezy+1. Basically, we would have xfce4-panel (linked against and depending on libxfce4panel-1.0-6) xfce4-foo-plugin (linked against and depending on libxfce4panel-1.0-6, and depending on xfce4-panel) If a new xfce4-panel is released (with, say, libxfce4panel-1.0-7) which breaks plugins built against libxfce4panel-1.0-6 we could ship a shlib file with: Breaks: libxfce4panel-1.0-6 so xfce4-panel would only be installed with the previous library removed, so at least users would have the choice not to install it until it's ready. Then, depending on the context, we would ask for binNMUs or do the required porting. I need to think a bit more about that, but in any case this will only happen in experimental, since right now I'm a bit more thinking about Wheezy. So, this is another friendly ping about the main issue. Can I upload a new 4.6 xfce4-panel which adds the Conflicts against xfce4-panel 4.8 in shlibs. Then RT would need to schedule the binNMUs for all the relevant dependencies so, when Wheezy/Wheezy+1 upgrade time comes, a plugin not working with with 4.10+ panel has a chance to be upgraded *before* the new panel is used? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sun, May 13, 2012 at 19:56:15 +0200, Matthias Klose wrote: sorry, thinko. I did mean End of May. So we're at the end of May. Can we have that revert now, or do I need to NMU? Cheers, Julien signature.asc Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sat, 2012-05-26 at 19:39 +0200, Julien Cristau wrote: On Sun, May 13, 2012 at 19:56:15 +0200, Matthias Klose wrote: sorry, thinko. I did mean End of May. So we're at the end of May. Can we have that revert now, or do I need to NMU? Stop nagging about the default gcc compiler for wheezy. Right now it is gcc-4.7, and problems will be resolved in due time for the release. -- 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/1338065890.3547.2.camel@x60
Processed: forcibly merging 673264 661422
Processing commands for cont...@bugs.debian.org: forcemerge 673264 661422 Bug #673264 [myodbc] myodbc: FTBFS in sid: mysql_real_query... no Bug #661422 [myodbc] myodbc: New release 5.1.10 available Severity set to 'serious' from 'important' 671115 was blocked by: 674328 672765 673528 673260 673161 667428 673183 673263 668232 649638 650058 673153 674122 649955 651110 672824 672714 650060 666331 672619 672950 673264 672716 672621 672816 651317 674210 672207 673262 672588 671115 was blocking: 672928 Added blocking bug(s) of 671115: 661422 661422 was not blocked by any bugs. 661422 was blocking: 671115 Added blocking bug(s) of 661422: 590905, 604887, and 590906 661422 was blocked by: 590905 604887 590906 661422 was blocking: 671115 Ignoring request to alter blocking bugs of bug #661422 to the same blocks previously set 661422 was blocked by: 590905 604887 590906 661422 was blocking: 671115 Ignoring request to alter blocking bugs of bug #661422 to the same blocks previously set There is no source info for the package 'myodbc' at version '5.1.6-3' with architecture '' Unable to make a source version for version '5.1.6-3' Marked as found in versions 5.1.6-3. Added tag(s) fixed-upstream. Merged 661422 673264 thanks Stopping processing here. Please contact me if you need assistance. -- 661422: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661422 671115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671115 673264: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673264 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.133806684526704.transcr...@bugs.debian.org
Processed: reassign 673264 to src:myodbc, forcibly merging 673264 674309
Processing commands for cont...@bugs.debian.org: reassign 673264 src:myodbc Bug #673264 [myodbc] myodbc: FTBFS in sid: mysql_real_query... no Bug #661422 [myodbc] myodbc: New release 5.1.10 available Bug reassigned from package 'myodbc' to 'src:myodbc'. Bug reassigned from package 'myodbc' to 'src:myodbc'. No longer marked as found in versions 5.1.6-3. No longer marked as found in versions 5.1.6-3. Ignoring request to alter fixed versions of bug #673264 to the same values previously set Ignoring request to alter fixed versions of bug #661422 to the same values previously set forcemerge 673264 674309 Bug #673264 [src:myodbc] myodbc: FTBFS in sid: mysql_real_query... no Bug #661422 [src:myodbc] myodbc: New release 5.1.10 available Bug #674309 [src:myodbc] myodbc: FTBFS: ld: cannot find -lssl 671115 was blocked by: 674328 672765 661422 673260 673528 673183 667428 673161 673263 649638 668232 673153 650058 674122 649955 651110 672824 650060 672714 672950 672619 666331 672716 673264 672621 672816 651317 673262 672207 674210 672588 671115 was blocking: 672928 Added blocking bug(s) of 671115: 674309 674309 was not blocked by any bugs. 674309 was blocking: 671115 Added blocking bug(s) of 674309: 590905, 604887, and 590906 674309 was blocked by: 590905 604887 590906 674309 was blocking: 671115 Ignoring request to alter blocking bugs of bug #674309 to the same blocks previously set 674309 was blocked by: 590905 604887 590906 674309 was blocking: 671115 Ignoring request to alter blocking bugs of bug #674309 to the same blocks previously set Added tag(s) fixed-upstream. Bug #661422 [src:myodbc] myodbc: New release 5.1.10 available Marked as found in versions myodbc/5.1.6-3. Marked as found in versions myodbc/5.1.6-3. Added tag(s) sid and wheezy. Added tag(s) sid and wheezy. Merged 661422 673264 674309 thanks Stopping processing here. Please contact me if you need assistance. -- 661422: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661422 671115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671115 673264: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673264 674309: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674309 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.133806714527731.transcr...@bugs.debian.org
Re: Accepted gcc-defaults 1.118 (source all amd64)
Svante Signell svante.sign...@telia.com writes: On Sat, 2012-05-26 at 19:39 +0200, Julien Cristau wrote: On Sun, May 13, 2012 at 19:56:15 +0200, Matthias Klose wrote: sorry, thinko. I did mean End of May. So we're at the end of May. Can we have that revert now, or do I need to NMU? Stop nagging about the default gcc compiler for wheezy. Right now it is gcc-4.7, and problems will be resolved in due time for the release. It is Julien's *job* as a member of the release team to nag about problems like this. And, beyond that, it's part of the release team's job to decide whether gcc-4.7 is acceptable as a release compiler for wheezy. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87aa0u635z@windlord.stanford.edu
Re: Accepted gcc-defaults 1.118 (source all amd64)
Svante, am Sat, May 26, 2012 at 10:58:10PM +0200 hast du folgendes geschrieben: On Sat, 2012-05-26 at 19:39 +0200, Julien Cristau wrote: On Sun, May 13, 2012 at 19:56:15 +0200, Matthias Klose wrote: sorry, thinko. I did mean End of May. So we're at the end of May. Can we have that revert now, or do I need to NMU? Stop nagging about the default gcc compiler for wheezy. Right now it is gcc-4.7, and problems will be resolved in due time for the release. sorry to annoy you but nagging about problems of the upcoming release is actually our job description. So no, we won't stop just because you're telling us to, just with solid reasons instead of handwaving about it all going away because you say so. It's a hell lot of work it's causing. Nobody's saying anything against having gcc-4.7 as an option. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Accepted gcc-defaults 1.118 (source all amd64)
On Sat, 2012-05-26 at 23:51 +0200, Philipp Kern wrote: Svante, am Sat, May 26, 2012 at 10:58:10PM +0200 hast du folgendes geschrieben: On Sat, 2012-05-26 at 19:39 +0200, Julien Cristau wrote: On Sun, May 13, 2012 at 19:56:15 +0200, Matthias Klose wrote: sorry, thinko. I did mean End of May. So we're at the end of May. Can we have that revert now, or do I need to NMU? Stop nagging about the default gcc compiler for wheezy. Right now it is gcc-4.7, and problems will be resolved in due time for the release. sorry to annoy you but nagging about problems of the upcoming release is actually our job description. So no, we won't stop just because you're telling us to, just with solid reasons instead of handwaving about it all going away because you say so. It's a hell lot of work it's causing. Nobody's saying anything against having gcc-4.7 as an option. Philipp, With all due respect, So far I have not seen any bug report causing the gcc-4.7 as default compiler being serious enough to make it reverted. Name the problematic bugs then, please. And, where is the big problem, please explain? -- 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/1338072725.3547.10.camel@x60
