Bug#584606: nmu: insighttoolkit_3.18.0-2
On Fri, 2010-06-04 at 19:49 -0500, Steve M. Robbins wrote: nmu insighttoolkit_3.18.0-2 . ALL . -m Rebuild with gccxml 0.9.0+cvs20100501-2 I assume this is intended to fix the gccxml-related complex.h FTBFS mentioned in #580527. If so then you need a give-back, not a binNMU, and only on those architectures where the package previously FTBFS and therefore /can't/ currently be binNMUed. I've given it back on s390, as the new gccxml is already available there. If that builds ok then I'll do so on the other failing architectures as well, with a dep-wait on the new gccxml. Regards, Adam -- 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/1275730616.31376.14446.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#584606: nmu: insighttoolkit_3.18.0-2
On Sat, Jun 05, 2010 at 10:36:56AM +0100, Adam D. Barratt wrote: On Fri, 2010-06-04 at 19:49 -0500, Steve M. Robbins wrote: nmu insighttoolkit_3.18.0-2 . ALL . -m Rebuild with gccxml 0.9.0+cvs20100501-2 I assume this is intended to fix the gccxml-related complex.h FTBFS mentioned in #580527. Yes. If so then you need a give-back, not a binNMU, and only on those architectures where the package previously FTBFS and therefore /can't/ currently be binNMUed. OK. I don't know what the distinction between a give-back and a binNMU is, so I'll take your word for it :-) I originally had the same thought: only rebuild on those architectures that previously failed. But I decided to ask for all architectures to ensure that my gccxml fix didn't accidentally break them in other ways. If it's not too much trouble, can you get insighttoolkit rebuilt on ALL architectures, please? Many thanks, -Steve signature.asc Description: Digital signature
Bug#584606: insighttoolkit built on s390
Hi, I just saw that buildd is reporting a maybe successful build on s390! So we can go for the other architectures any time you're ready. -Steve signature.asc Description: Digital signature
Bug#584606: nmu: insighttoolkit_3.18.0-2
On Sat, 2010-06-05 at 08:34 -0500, Steve M. Robbins wrote: On Sat, Jun 05, 2010 at 10:36:56AM +0100, Adam D. Barratt wrote: If so then you need a give-back, not a binNMU, and only on those architectures where the package previously FTBFS and therefore /can't/ currently be binNMUed. OK. I don't know what the distinction between a give-back and a binNMU is, so I'll take your word for it :-) A give-back implies retrying a failed build, whereas a binNMU is a completely new build of a previously successfully built package (i.e. a binary-only NMU). I originally had the same thought: only rebuild on those architectures that previously failed. But I decided to ask for all architectures to ensure that my gccxml fix didn't accidentally break them in other ways. If it's not too much trouble, can you get insighttoolkit rebuilt on ALL architectures, please? I've given it back on all of the failing architectures. Several of the architectures on which it originally succeeded do not have the spare capacity to justify a rebuild just to check - particularly not when the build takes over two days on at least one architecture, and over a week on another. As a hopefully acceptable compromise, I've binNMUed it on i386 and kfreebsd-amd64. That would give attempts on two-thirds of the available architectures and, assuming no other issues, a complete set of builds. Regards, Adam -- 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/1275761435.3301.4438.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#584606: nmu: insighttoolkit_3.18.0-2
On Sat, Jun 05, 2010 at 07:10:35PM +0100, Adam D. Barratt wrote: I've given it back on all of the failing architectures. Several of the architectures on which it originally succeeded do not have the spare capacity to justify a rebuild just to check - particularly not when the build takes over two days on at least one architecture, and over a week on another. As a hopefully acceptable compromise, I've binNMUed it on i386 and kfreebsd-amd64. That would give attempts on two-thirds of the available architectures and, assuming no other issues, a complete set of builds. OK, that's great. Thanks! -Steve signature.asc Description: Digital signature
Bug#583916: Upcoming jack transition
On Mon, May 31, 2010 at 18:39:11 +0200, Reinhard Tartler wrote: The last transition switched the jack-audio-connection-kit package from 'jackd' to 'jackd2'. 'jackd2' is a complete reimplementation of jackd in C++ with SMP support. Most importantly however, is an added feature that improves interoperability with pulseaudio. For this reason, we decided to make this version the default version for Squeeze. During testing, however, we discovered that this transition has been and still is a bit problematic. Besides some more or less known bugs in 'jackd2', it exposes a lot of additional (internal, C++ only) symbols, with which we are not comfortable at all. Moreover, we have been approached by upstream(s) with concerns that our current package does not make it easy for 3rd parties (may it be upstream or backports.org) to provide replacement packages for other jackd implementations. For this reason, we propose to: - revert the 'jack-audio-connection-kit' package to the jackd1 implementation - make this package the provider of libjack-dev, however the actual daemon will be packaged as 'jackd1' (currently jackd) - create a shlibs file that makes application packages depend on 'libjack0-0.116 | libjack0-0.118+svn3796 (= 1:0.0116)' (or similar). This effectively defines a new virtual package 'libjack0-0.116' that is provided by any jack implementation that claims to be binary compatible with the 0.116 release of the original jack implementation. - have all packages that are linked against libjack recompiled to pick up the new shlibs - introduce the jackd2 implementation as a new source package 'jackd2'. The binary package name of this jack daemon will be 'jackd2', the library package will be 'libjack-jackd2-0' and (of course also) provide 'libjack0-0.116'. - introduce a new source package 'jackd-defaults' that generates a meta package 'jackd' which points to the default jack implementation, which will be jackd2 for Debian. So I have a few questions about this plan: - if all implementations of libjack are binary-compatible, then why do we need to change the package name when changing implementations of libjack? - I understand you want to allow different jackd implementations to coexist. Do we really need 2 implementations of libjack as well? - related to this, the libjack0.symbols file currently has things like 'jack_client_kill_thr...@base 1.9.5~dfsg-13' which suggest that it is, actually, not completely compatible with other implementations (a quick check suggests that nothing out of the jack-audio-connection-kit source package uses these additional symbols, but..) - many packages apparently depend on symbols labelled 0.118.0 or later in the symbols file, how does that fly with a 0.116 jackd1? Overall this looks like a lot of churn, late in the release cycle, for an end result which seems quite close to the current situation. Cheers, Julien signature.asc Description: Digital signature
Processed: closing 551151
Processing commands for cont...@bugs.debian.org: # random chealer bug, no release team action needed close 551151 Bug#551151: [release.debian.org] nvidia non-free drivers unusable 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Filipus Klutiero chea...@gmail.com thanks Stopping processing here. Please contact me if you need assistance. -- 551151: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551151 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.127576699128344.transcr...@bugs.debian.org
Processed: user release.debian....@packages.debian.org, usertagging 583916, tagging 583916
Processing commands for cont...@bugs.debian.org: user release.debian@packages.debian.org Setting user to release.debian@packages.debian.org (was jcris...@debian.org). usertags 583916 transition Bug#583916: Upcoming jack transition There were no usertags set. Usertags are now: transition. tags 583916 moreinfo Bug #583916 [release.debian.org] Upcoming jack transition Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 583916: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583916 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.127576726129806.transcr...@bugs.debian.org
Re: Please allow flash-kernel/2.29 into testing
On Fri, 2010-06-04 at 22:17 +0100, Martin Michlmayr wrote: Please allow flash-kernel/2.29 into testing. It has a udeb and therefore requires manual approval. The new version adds support for two new devices but doesn't change anything in an incompatible way. Unblocked. Regards, Adam -- 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/1275767933.6561.49.ca...@kaa.jungle.aubergine.my-net-space.net
Re: please binnmu flightgear and simgear
On Thu, 2010-06-03 at 18:35 +0100, Adam D. Barratt wrote: On Wed, 2010-06-02 at 20:25 +0100, peter green wrote: per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584156 flightgear is uninstallable in sid due to dependencies on an outdated libopenscenegraph. Trying to rebuild it reveals that simgear (one of it's build-depends) has the same problem so please binnmu them both. nmu simgear _1.9.1-2 . ALL . -m 'rebuild against newer libopenscenegraph' nmu flightgear_1.9.1-1.1 . ALL . -m 'rebuild against newer libopenscenegraph' [...] I'll also note that flightgear 1.9.1 FTBFS on armel Filed as #584706. and openscenegraph is itself unbuildable (and therefore out-of-date) on s390 due to coin3/s390 not correctly appearing in the Packages files. This is no longer an issue, and openscenegraph is now built on s390. I've scheduled the simgear binNMUs, with a dep-wait on libopenscenegraph65. Regards, Adam -- 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/1275768739.6561.287.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#584165: [SRM] pu: package apr/1.2.12-5+lenny2
On Tue, 2010-06-01 at 23:41 +0200, Stefan Fritsch wrote: Please review apr/1.2.12-5+lenny2 for inclusion in lenny: This was accepted a couple of days ago, as you no doubt noticed. It's now built almost everywhere, although the alpha build appears to have been killed due to inactivity. Regards, Adam -- 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/1275768922.6993.33.ca...@kaa.jungle.aubergine.my-net-space.net
Bug#583916: Upcoming jack transition
On Sat, Jun 5, 2010 at 15:36, Julien Cristau jcris...@debian.org wrote: On Mon, May 31, 2010 at 18:39:11 +0200, Reinhard Tartler wrote: The last transition switched the jack-audio-connection-kit package from 'jackd' to 'jackd2'. 'jackd2' is a complete reimplementation of jackd in C++ with SMP support. Most importantly however, is an added feature that improves interoperability with pulseaudio. For this reason, we decided to make this version the default version for Squeeze. During testing, however, we discovered that this transition has been and still is a bit problematic. Besides some more or less known bugs in 'jackd2', it exposes a lot of additional (internal, C++ only) symbols, with which we are not comfortable at all. Moreover, we have been approached by upstream(s) with concerns that our current package does not make it easy for 3rd parties (may it be upstream or backports.org) to provide replacement packages for other jackd implementations. For this reason, we propose to: - revert the 'jack-audio-connection-kit' package to the jackd1 implementation - make this package the provider of libjack-dev, however the actual daemon will be packaged as 'jackd1' (currently jackd) - create a shlibs file that makes application packages depend on 'libjack0-0.116 | libjack0-0.118+svn3796 (= 1:0.0116)' (or similar). This effectively defines a new virtual package 'libjack0-0.116' that is provided by any jack implementation that claims to be binary compatible with the 0.116 release of the original jack implementation. - have all packages that are linked against libjack recompiled to pick up the new shlibs - introduce the jackd2 implementation as a new source package 'jackd2'. The binary package name of this jack daemon will be 'jackd2', the library package will be 'libjack-jackd2-0' and (of course also) provide 'libjack0-0.116'. - introduce a new source package 'jackd-defaults' that generates a meta package 'jackd' which points to the default jack implementation, which will be jackd2 for Debian. So I have a few questions about this plan: - if all implementations of libjack are binary-compatible, then why do we need to change the package name when changing implementations of libjack? Because there can be only one package of a given name... unless I'm misparsing your question. - I understand you want to allow different jackd implementations to coexist. Do we really need 2 implementations of libjack as well? Yes. The server and the library have an internal API that is not guaranteed to be compatible across any kind of release. So these two must be the same upstream version. - related to this, the libjack0.symbols file currently has things like 'jack_client_kill_thr...@base 1.9.5~dfsg-13' which suggest that it is, actually, not completely compatible with other implementations (a quick check suggests that nothing out of the jack-audio-connection-kit source package uses these additional symbols, but..) - many packages apparently depend on symbols labelled 0.118.0 or later in the symbols file, how does that fly with a 0.116 jackd1? I believe the symbols file is borked. Client applications are only allowed to assume functions defined in 0.116 to exist. Extra symbols are defined as weak, and clients intending to use them must check for their availability. Clients assuming such symbols exist are broken according to upstream. So... libjack *can* have extra symbols added after the 0.116 API, and it *can* have extra symbols for use for the server. Client applications cannot assume they exist, though. -- Saludos, Felipe Sateler -- 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/aanlktil1etwhungso56wbbtf3qzvn0rmhngno5m-4...@mail.gmail.com
Bug#583916: Upcoming jack transition
On Sat, Jun 5, 2010 at 16:09:53 -0400, Felipe Sateler wrote: On Sat, Jun 5, 2010 at 15:36, Julien Cristau jcris...@debian.org wrote: So I have a few questions about this plan: - if all implementations of libjack are binary-compatible, then why do we need to change the package name when changing implementations of libjack? Because there can be only one package of a given name... unless I'm misparsing your question. Your proposal talked about introducing a libjack-jackd2-0 and a libjack0-0.118+svn3796 package, AIUI. I don't understand why the current libjack0 package can't stay. - I understand you want to allow different jackd implementations to coexist. Do we really need 2 implementations of libjack as well? Yes. The server and the library have an internal API that is not guaranteed to be compatible across any kind of release. So these two must be the same upstream version. OK. - related to this, the libjack0.symbols file currently has things like 'jack_client_kill_thr...@base 1.9.5~dfsg-13' which suggest that it is, actually, not completely compatible with other implementations (a quick check suggests that nothing out of the jack-audio-connection-kit source package uses these additional symbols, but..) - many packages apparently depend on symbols labelled 0.118.0 or later in the symbols file, how does that fly with a 0.116 jackd1? I believe the symbols file is borked. Client applications are only allowed to assume functions defined in 0.116 to exist. Extra symbols are defined as weak, and clients intending to use them must check for their availability. Clients assuming such symbols exist are broken according to upstream. So... libjack *can* have extra symbols added after the 0.116 API, and it *can* have extra symbols for use for the server. Client applications cannot assume they exist, though. In that case I suggest changing libjack0 to: - kill the .symbols file - have the libjack0 package provide, replace and conflict with libjack0-0.116 - have the libjack0.shlibs file point at 'libjack0 | libjack0-0.116' or similar Then reverse deps can be gradually rebuilt. I'm not quite sure about the rest of the plan (switching the j-a-c-k package from one implementation to another one, introducing a jackd-defaults), it seems overengineered compared to leaving the current j-a-c-k package alone, and reintroducing jackd1 and its libjack alongside it. Can you explain why you need all this? Cheers, Julien signature.asc Description: Digital signature
Bug#551151: [pkg-nvidia-devel] Removal of buggy packages
Filipus Klutiero chea...@gmail.com writes: So the remaining breakage in testing is limited to the prebuilt modules for the current series. My request for their removal to the release team has fallen through the cracks. On the other hand, these packages are now broken since over a year, and were broken for extended periods of time several times before. Would you rather request their removal from unstable? Otherwise, I'll prod the release team again. Please don't do either of those things. We will be uploading a new version of the metapackage that builds them and take care of them at that time. Removing them is just a waste of time for the people removing them, since we'll just upload them again shortly thereafter. -- 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/87wrudnjsd@windlord.stanford.edu
Bug#551151: [pkg-nvidia-devel] Removal of buggy packages
Russ Allbery r...@debian.org writes: Filipus Klutiero chea...@gmail.com writes: So the remaining breakage in testing is limited to the prebuilt modules for the current series. My request for their removal to the release team has fallen through the cracks. On the other hand, these packages are now broken since over a year, and were broken for extended periods of time several times before. Would you rather request their removal from unstable? Otherwise, I'll prod the release team again. Please don't do either of those things. We will be uploading a new version of the metapackage that builds them and take care of them at that time. Removing them is just a waste of time for the people removing them, since we'll just upload them again shortly thereafter. Ack, sorry, I fail reading comprehension. For some reason I kept thinking you were talking about unstable. Feel free to remove them from testing if you want. The goal is to get a set of modules built against the current ABI in unstable now that it's probably stabilized relatively well for the release and get them to propagate to testing normally. The existing packages in testing are useless; please feel free to remove them however is easiest. Once the packages from unstable propagate, they'll be no longer built from source and presumably will go away semi-automatically. -- 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/87ljatnjdw@windlord.stanford.edu
Bug#551151: [pkg-nvidia-devel] Bug#551151: Removal of buggy packages
Russ Allbery r...@debian.org writes:
Feel free to remove them from testing if you want. The goal is to get a
set of modules built against the current ABI in unstable now that it's
probably stabilized relatively well for the release and get them to
propagate to testing normally.
The existing packages in testing are useless; please feel free to remove
them however is easiest. Once the packages from unstable propagate,
they'll be no longer built from source and presumably will go away
semi-automatically.
I've just filed bugs against ftp.debian.org for removal of the old
nvidia-graphics-modules-{i386,amd64} packages from unstable, which should
clarify matters further.
Thank you for making sure this didn't fall between the cracks!
--
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/87aar9nj2b@windlord.stanford.edu
