Bug#1067065: nmu: gringo_5.6.2-1
Package: release.debian.org Severity: normal X-Debbugs-Cc: gri...@packages.debian.org Control: affects -1 + src:gringo User: release.debian@packages.debian.org Usertags: binnmu nmu gringo_5.6.2-1 . ANY . unstable . -m "Rebuild against updated python3.11 for 64-bit time transition"
Bug#1018987: nmu: minc-tools_2.3.00+dfsg-9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu minc-tools_2.3.00+dfsg-9 . ANY . unstable . -m "rebuild against updated libminc"
Bug#1018888: nmu: elastix_5.0.1-3+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu elastix_5.0.1-3+b1 . ANY . unstable . -m "Rebuild against updated insighttoolkit5"
Bug#1018839: nmu: insighttoolkit5_5.2.1-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu insighttoolkit5_5.2.1-5 . ANY . unstable . -m "Rebuild against updated libminc"
Bug#944396: transition: exiv2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition New upstream, new soversion. Ben file: title = "exiv2"; is_affected = .depends ~ "libexiv2-14" | .depends ~ "libexiv2-27"; is_good = .depends ~ "libexiv2-27"; is_bad = .depends ~ "libexiv2-14"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-1-amd64 (SMP w/16 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#881688: nmu: berkeley-express_1.5.1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu berkeley-express_1.5.1-3 . ANY . unstable . -m "Rebuild with current Boost libraries" -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: [pkg-boost-devel] boost1.61 1.61.0+dfsg-3 MIGRATED to testing
On Tue, Jun 20, 2017 at 10:57:11AM +0100, Dimitri John Ledkov wrote: > Hm, this makes no sense. I thought we want to _remove_ 1.61, not > re-introduce it?! Agreed. I did not request this, FWIW. The previous removal message https://packages.qa.debian.org/b/boost1.61/news/20170202T163914Z.html was for a transition to 1.62. I thought this would make it stay out, but maybe we forgot to request a removal from "unstable" (?). I keep forgetting the rules for these things. Or maybe it was a simple oversight. Dear Release Team: can you reverse this reintroduction of boost 1.61, please? Thanks, -Steve signature.asc Description: PGP signature
Bug#796561: insighttoolkit: ABI transition needed for libstdc++ v5
On September 2, 2015 02:48:01 PM you wrote: > > I haven't checked, but I will be conservative and assume it needs > > transition. I have already staged v4.8 in experimental for that purpose; > > see also #793250 and #796561. > > Thanks, I've noted those on the Titanpad. I will not open a separate bug > here, since #796561 can act as the tracking bug. I see that there are build failures now for insighttoolkit4. I'm going to have a look at these in the coming days. Should I need an upload to fix: would I be able to target unstable or should it still stay in experimental? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Bug#755539: Elastix needs binnmu after ITK
On September 3, 2014 03:22:38 PM Emilio Pozuelo Monfort wrote: Since the .so file location changed, it is possible that the shared library itself changed location or soname. Both the location and the SONAME of libhdf5 changed. So in addition to verifying that it still builds, you need to verify that the EXISTING elastix binary continues to function. If you find it breaks and a binNMU is needed, let us know. I suppose one could do some investigation -- it won't be me -- but why bother? The SONAME changed so clearly something changed. Why are we having this discussion? Just schedule a rebuild! Regards, -Steve -- 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/7581982.2HZc3JK8QQ@riemann
Bug#755539: Elastix needs binnmu after ITK
The recent build failure of elastix (#759945) is caused by the libhdf5.so path having changed, presumably due to #755539. The path is encoded into insighttoolkit4-dev's file /usr/lib/cmake/ITK-4.6/ITKTargets-none.cmake so Elastix will need a binnmu as soon as insighttoolkit is rebuilt. -Steve signature.asc Description: Digital signature
Bug#744171: transition: boost-defaults
On July 5, 2014 06:08:41 PM Emilio Pozuelo Monfort wrote: On 02/06/14 11:15, Julien Cristau wrote: On Sun, May 25, 2014 at 08:34:08 -0500, Steve M. Robbins wrote: On May 20, 2014 06:48:33 PM Julien Cristau wrote: Are there bugs tracking packages with versioned boost build-dependencies? I'm not aware of any such bugs. Can you make that happen then? Steve, can you do this please? This transition has been stuck for a while. I have checked into the packages still build-depending on Boost 1.49, and summarized my findings in #734195. The good news is that there is no longer any impediment to removing Boost 1.49. That leaves two Boost versions 1.54 and 1.55, which made me realize that the transition tracker is too pessimistic. Right now 1.54 is considered bad, but it shouldn't be. So I suggest to change the tracker to: Good: .depends ~ /libboost[a-z-]*1\.5[45]/ Bad: .depends ~ /libboost[a-z-]*1\.(4[6-9]|5[0-3])/ Regards, -Steve -- 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/3895049.2ul62Rfe6m@riemann
Bug#744171: transition: boost-defaults
On July 9, 2014 08:15:27 AM Julien Cristau wrote: On Wed, Jul 9, 2014 at 01:03:49 -0500, Steve M. Robbins wrote: That leaves two Boost versions 1.54 and 1.55, which made me realize that the transition tracker is too pessimistic. Right now 1.54 is considered bad, but it shouldn't be. Why not? I thought the whole point was moving things from 1.54 to 1.55. No, I don't think so. In my view, the goal is to release with at most 2 boost versions. The reason for keeping multiple versions is precisely to avoid having to do hard transitions [1] and boost-defaults was proposed [2] to keep the sourceful uploads to a minimum. This had been working well (in my view) since 2009. Somewhere along the line the release team started demanding boost-defaults use the transition tracker. I don't quite understand why. But if we're going to use a tracker, IMHO the transition to track is AWAY from the oldest boost (1.49) to the two newer ones. [1] https://lists.debian.org/debian-release/2009/02/msg00614.html [2] https://lists.debian.org/debian-release/2009/03/msg00147.html Regards, -Steve signature.asc Description: This is a digitally signed message part.
Bug#744171: transition: boost-defaults
On July 9, 2014 08:55:04 AM Julien Cristau wrote: On Wed, Jul 9, 2014 at 01:39:38 -0500, Steve M. Robbins wrote: On July 9, 2014 08:15:27 AM Julien Cristau wrote: On Wed, Jul 9, 2014 at 01:03:49 -0500, Steve M. Robbins wrote: That leaves two Boost versions 1.54 and 1.55, which made me realize that the transition tracker is too pessimistic. Right now 1.54 is considered bad, but it shouldn't be. Why not? I thought the whole point was moving things from 1.54 to 1.55. No, I don't think so. In my view, the goal is to release with at most 2 boost versions. The reason for keeping multiple versions is precisely to avoid having to do hard transitions [1] and boost-defaults was proposed [2] to keep the sourceful uploads to a minimum. This had been working well (in my view) since 2009. Somewhere along the line the release team started demanding boost-defaults use the transition tracker. I don't quite understand why. But if we're going to use a tracker, IMHO the transition to track is AWAY from the oldest boost (1.49) to the two newer ones. We removed 1.49 from testing months ago, Sure, but there remains an open bug to remove it from unstable. and for at least the last two releases we've shipped with just one boost version. What's changed? I don't think anything has changed. In my view, the goal is to release with at most two versions. So if we have just one, that's fine. Best, -Steve signature.asc Description: This is a digitally signed message part.
Bug#744171: transition: boost-defaults
On May 20, 2014 06:48:33 PM Julien Cristau wrote: Are there bugs tracking packages with versioned boost build-dependencies? I'm not aware of any such bugs. -Steve signature.asc Description: This is a digitally signed message part.
Bug#744171: transition: boost-defaults
Hello Cyril, Thanks for the fast action on this! On April 11, 2014 10:41:45 AM Cyril Brulebois wrote: Since there was an old boost1.54 ben file around, I've reused it, tweaking the versions: title = boost 1.55; is_affected = .build-depends ~ /libboost[0-9\.a-z-]*-dev/; is_good = .depends ~ /libboost[a-z-]*1\.55/; is_bad = .depends ~ /libboost[a-z-]*1\.(4[6-9]|5[0-5])/; notes = #744171; export = false; So am I reading this right: it seems that is_bad matches boost 1.55? Should the last bit instead read |5[0-4])/;? Regards, -Steve signature.asc Description: This is a digitally signed message part.
Bug#744171: transition: boost-defaults
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition As previously requested on Feb 28 2014 (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704032#220): 1.55 has been in testing for a month now and has somewhat better support for recent glibc -- e.g. it doesn't suffer from .#739807 and #739904. I'd like to switch the boost-defaults to 1.55. Julien Cristau today requested that I file a new bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704032#230). Ben file: title = boost-defaults; is_affected = .build-depends ~ /libboost[a-z-]*-dev/ is_good = .depends ~ /libboost[a-z-]*1\.55/; is_bad = .depends ~ /libboost[a-z-]*1\.54/; -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20140411021118.27189.98841.reportbug@localhost
Bug#704032: Transition to 1.55
Hi, 1.55 has been in testing for a month now and has somewhat better support for recent glibc -- e.g. it doesn't suffer from .#739807 and #739904. I'd like to switch the boost-defaults to 1.55. Any objections? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Bug#704032: Transition to boost 1.54
On December 1, 2013 03:57:10 PM Julien Cristau wrote: On Sun, Jul 14, 2013 at 14:59:24 -0500, Steve M. Robbins wrote: Boost 1.54 is now in sid on all architectures, so we should transition to that. Hi Steve, The build log at https://buildd.debian.org/status/fetch.php?pkg=libzeeparch=sparcver=3.0.2- 1%2Bb1stamp=1377947044 seems to point at a boost issue. Can you take a look? I agree. It's been reported as #723115. No fix yet, I'm afraid. -Steve signature.asc Description: This is a digitally signed message part.
Bug#704032: Transition to boost 1.54
On August 13, 2013 11:33:39 AM Julien Cristau wrote: Control: tag -1 confirmed On Sun, Jul 14, 2013 at 14:59:24 -0500, Steve M. Robbins wrote: retitle 704032 transition: boost-defaults 1.54 thanks Boost 1.54 is now in sid on all architectures, so we should transition to that. Let's go ahead with this. Feel free to bump boost-defaults in sid at your convenience, and let this bug know when it's uploaded. Just uploaded. Since the new boost defaults target Boost 1.54, the transition title shoudl change. Also the Good and Bad regexps should be something like: Good: .depends ~ /libboost[a-z-]*1\.54/ Bad: .depends ~ /libboost[a-z-]*1\.(4[6-9]|5[0-3])/ Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Bug#717018: nmu: boost1.49_1.49.0-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, GCC has been updated to 4.8 since the last build of boost1.49 and the old libraries cause build failures occasionally; c.f. https://buildd.debian.org/status/fetch.php?pkg=mriconvertarch=mipsver=1%3A2.0.4-1stamp=1373192426 so I feel it would be best to rebuild the boost libraries. nmu boost1.49_1.49.0-4 . ALL . -m Rebuild after change to gcc 4.8 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20130716031658.21059.18678.reportbug@localhost
Bug#704032: Transition to boost 1.54
retitle 704032 transition: boost-defaults 1.54 thanks Boost 1.54 is now in sid on all architectures, so we should transition to that. -Steve signature.asc Description: This is a digitally signed message part.
Bug#704032: transition: boost-defaults
Hi, Another update: I did a rebuild of the boost-dependent packages in an unmodified sid chroot (using the newly-uploaded boost 1.49-4 that fixes the UTC issue (#707389). There are presently 60 such failures. After transition there are 86 failures, so the boost transition causes about 26 new failures. I will make it a priority this weekend to analyze these 26, but I know at least one is the UTC issue and several are due to Qt's moq parser which are simple fixes (see also #704045). On Wed, May 15, 2013 at 08:49:09AM -0500, Steve M. Robbins wrote: On May 15, 2013 04:28:59 AM Matthias Klose wrote: Am 14.05.2013 09:00, schrieb Steve M. Robbins: Note also that gcc 4.8 is going to break Boost 1.49 so my suggestion is that Boost transition before gcc does. GCC 4.8 will add a handful of build failures to boost 1.49 based packages, but not the 89 you mention above. As noted above, there are only 26 new ones. Based on the experience with gcc 4.7, I would expect far more than 26 failures caused by building boost 1.49 with the new gcc 4.8. How many failures did you find in the archive rebuild you did? Did you not do a rebuild? -S signature.asc Description: Digital signature
Bug#704032: transition: boost-defaults
On Fri, May 17, 2013 at 07:23:12PM +0200, Matthias Klose wrote: Am 15.05.2013 15:49, schrieb Steve M. Robbins: On May 15, 2013 04:28:59 AM Matthias Klose wrote: Am 14.05.2013 09:00, schrieb Steve M. Robbins: Note also that gcc 4.8 is going to break Boost 1.49 so my suggestion is that Boost transition before gcc does. GCC 4.8 will add a handful of build failures to boost 1.49 based packages, but not the 89 you mention above. How many failures did you find in the archive rebuild you did? would you mind reading my earlier email in this thread mentioning Dimitrijs work? That email discusses a rebuild with Boost 1.53. I am asking how many failures are found when building things using gcc 4.8. And in any case: if you know the answer, please just state it rather than prolonging the thread with more passive-agressive questions. Thanks, -Steve signature.asc Description: Digital signature
Bug#704032: transition: boost-defaults
On May 15, 2013 04:28:59 AM Matthias Klose wrote: Am 14.05.2013 09:00, schrieb Steve M. Robbins: Note also that gcc 4.8 is going to break Boost 1.49 so my suggestion is that Boost transition before gcc does. GCC 4.8 will add a handful of build failures to boost 1.49 based packages, but not the 89 you mention above. How many failures did you find in the archive rebuild you did? -S -- 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/201305150849.10892.st...@sumost.ca
Bug#704032: transition: boost-defaults
On Sun, May 12, 2013 at 11:30:58PM -0500, Steve M. Robbins wrote: On Wed, May 08, 2013 at 07:05:39PM +0200, Julien Cristau wrote: On Tue, Mar 26, 2013 at 23:08:15 -0500, Steve M. Robbins wrote: I would like to change Debian's default boost version from 1.49 to 1.53 or later -- likely to the most current Boost at the time the transition is scheduled. This change does not directly impact any binary packages. However, it will affect the buildability of source packages. Do we know how many (and which) packages would start FTBFS if the change was done now? The final tally is that 86/299 fail to build. I'll start filing bugs. Note also that gcc 4.8 is going to break Boost 1.49 so my suggestion is that Boost transition before gcc does. -S -- 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/2013051407.ga21...@sumost.ca
Bug#704032: transition: boost-defaults
On May 8, 2013 12:05:39 PM Julien Cristau wrote: On Tue, Mar 26, 2013 at 23:08:15 -0500, Steve M. Robbins wrote: I would like to change Debian's default boost version from 1.49 to 1.53 or later -- likely to the most current Boost at the time the transition is scheduled. This change does not directly impact any binary packages. However, it will affect the buildability of source packages. Do we know how many (and which) packages would start FTBFS if the change was done now? Dmitrijs: did you do a full rebuild of the archive using Boost 1.53? If so, can you post your results here? If not, I'll dust off my rebuilding scripts from the last transition and have a go. Thanks, -Steve -- 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/201305082239.06097.st...@sumost.ca
Bug#704032: transition: boost-defaults
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, Clearly this transition won't be acted upon until after the wheezy release is done. However, I'm filing the bug now so that we can track the build failure bugs related to updating boost. Source package boost-defaults provides libboost-dev and similar unversioned -dev packages that depend on a default versioned package such as libboost1.49-dev. I would like to change Debian's default boost version from 1.49 to 1.53 or later -- likely to the most current Boost at the time the transition is scheduled. This change does not directly impact any binary packages. However, it will affect the buildability of source packages. Ben file: title = boost-defaults; is_affected = .build-depends ~ /libboost[a-z-]*-dev/ is_good = .depends ~ /libboost[a-z-]*1\.53/; is_bad = .depends ~ /libboost[a-z-]*1\.4[0-9]/; -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20130327040815.29458.10846.reportbug@localhost
Bug#683991: unblock: nyquist/3.05-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package nyquist Upload fixed a FTBFS bug #622197 that prevented nyquist from building on architectures hurd-i386 and kfreebsd-i386. unblock nyquist/3.05-2 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20120806034431.2564.34519.reportbug@localhost
Bug#682460: unblock: boost1.50/1.50.0-1
On Sat, Jul 28, 2012 at 04:34:31PM +0200, Julien Cristau wrote: On Mon, Jul 23, 2012 at 20:26:36 -0500, Steve M. Robbins wrote: Yes, it's a judgement call, I'd agree. My thinking is that (a) it's already building on all architectures (low risk) and (b) has somewhat better support for GCC 4.7 and (c) it's Boost :-) Could providing updated boost packages in wheezy-backports be a possible alternative? Sure: it is a possible alternative. To be honest, however: it's not something that I will do. Regards, -Steve -- 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/20120806041718.ga2...@sumost.ca
Bug#682460: unblock: boost1.50/1.50.0-1
On Mon, Jul 23, 2012 at 11:04:13AM +0200, Cyril Brulebois wrote: Hi, Steve M. Robbins s...@debian.org (22/07/2012): Given the long lifetime of stable Debian, I expect users would appreciate having the latest Boost available. This is a leaf package so should have no impact on stability of the archive. [Testing currently has Boost 1.49 as default and I propose to keep it that way even if Boost 1.50 is also available.] unblock boost1.50/1.50.0-1 I think it's way too late to add new packages to testing, and I'm not sure boost's being boost is a strong enough reason to make an exception for it. Yes, it's a judgement call, I'd agree. My thinking is that (a) it's already building on all architectures (low risk) and (b) has somewhat better support for GCC 4.7 and (c) it's Boost :-) Anyway, I leave the decision to the Release Team. Cheers, -Steve signature.asc Description: Digital signature
Removing Boost 1.46
Hi, The output from dak for removing source boost1.46 lists a number of broken r-deps, which is to be expected. I had expected that all such packages should be part of the Boost transition tracker [1] but surprisingly, two are missing: gpsshogi: gpsshogi [amd64 i386] libosl: libosl1 [amd64 i386] Can these be added to the transition tracker? [1] http://release.debian.org/transitions/html/boost1.49.html There are additionally three broken build-depends, all of which have trivial fixes that I can NMU, if required. I've added a blocking bug for each against this removal bug. Do you want me to NMU these three prior to removal? Thanks, -Steve signature.asc Description: Digital signature
GCC 4.7
Quoting Luca Falavigna: we're struggling with a bunch of uncoordinated transitions at the moment, with extra fun thanks to an uncoordinated switch to gcc 4.7, and its extra hundreds of RC bugs; http://lists.debian.org/debian-release/2012/05/msg00632.html Why don't you just revert the default gcc change until after the freeze? -Steve signature.asc Description: Digital signature
Re: What does Transition Status uknown mean?
On Sat, Apr 07, 2012 at 10:34:43PM +0200, Philipp Kern wrote: Maybe that does shed a bit more light onto the issue. Yes. Thanks Medhi, Adam, and Philipp for the explanations! -Steve signature.asc Description: Digital signature
What does Transition Status uknown mean?
Hi, With respect to the transition trackers, e.g. [1], parameters are listed to determine Good, and Bad dependencies. However, the dependency package listing has three categories: Good, Bad, and Unknown. I don't understand what the third category means. Presumably, a package can be categorized by looking at its current dependency status. I used to imagine that this was a long process and Unknown simply meant that a given package had not yet been processed. But I've been looking at the boost transition page for weeks and the number of Unknowns has not dropped to zero. Looking again, I can see that -- contrary to what one might imagine -- Good is not the negation of Bad. For example, in the boost transition, Good is (roughly) defined as depends on the new version (1.49), while Bad (roughly) means depends on the old version (1.46 or 1.48). So does Unknown really mean neither Good nor Bad? In the case of Boost, much of the package is header-only libraries, so the Good and Bad categories do not apply. How is a transition managed when most of the dependencies are Unknown? Are the Unknowns mainly ignored and transition is declared done when there are no longer any Bad packages? Thanks, -Steve [1] http://release.debian.org/transitions/html/boost1.49.html signature.asc Description: Digital signature
Re: Bug#653823: transition: boost-defaults
On Sun, Mar 11, 2012 at 08:11:06PM +0100, Julien Cristau wrote: On Sun, Mar 11, 2012 at 13:21:19 -0500, Steve M. Robbins wrote: kdebase-workspace: #none [SOVER] cp: cannot stat `debian/tmp/usr/lib/libplasma_applet-system-monitor.so.4.6.0': No such file or directory kdeedu: #none [SOVER] cp: cannot stat `debian/tmp/usr/lib/libakregatorinterfaces.so.4.6.0': No such file or directory kdepim: #none [SOVER] cp: cannot stat `debian/tmp/usr/lib/libakonadi-xml.so.4.6.0': No such file or directory kdepim-runtime: #none [SOVER] cp: cannot stat `debian/tmp/usr/lib/libakonadi-xml.so.4.6.0': No such file or directory It'd probably be best to have kde sorted before the boost defaults change. Otherwise it sounds like it should be fine. So I see KDE transition is over. I should be able to upload new boost defaults now? Can you switch the tracker to track 1.49? Thanks, -Steve signature.asc Description: Digital signature
Re: Bug#653823: transition: boost-defaults
Hello Release Team, On Sat, Mar 03, 2012 at 12:21:20PM -0600, Steve M. Robbins wrote: I need some guidance from the release team regarding Boost. Last Sunday I uploaded another new version (1.49). It's still in NEW, but I'd like to transition boost-defaults to 1.49 ASAP. I plan to do local rebuilds as I did for 1.48 prior to transitioning and submit any patches necessary to support Boost 1.49. OK, I have just finished the local rebuilds against boost-defaults set to 1.49. The good news is that of 249 packages, there are just TWO new issues related to boost 1.49! Thus I'd like to formally request that this transition (bug #653823) be changed to Boost 1.49 transition. My next steps are to work on the issues, described in detail below. IMHO, none of them seem to be show-stoppers so I'd like to get a sense of when you feel it would be appropriate to flip the boost-default and upload. What follows is a summary of my rebuilds. I use the shorthand package: #bug [tag] explanation, where #none means no bug is yet filed. New Issues -- luabind: #none [NEW] ./luabind/detail/call_member.hpp:319:1: error: missing binary operator before token ( This issue is described in upstream tracker ticket https://svn.boost.org/trac/boost/ticket/6631 . I'm discussing the options with upstream on the mailing list; see http://lists.boost.org/Archives/boost/2012/03/191073.php . It sounds like there may be a way to fix this in boost itself that I will investigate. Otherwise, it's a simple fix to luabind. vtk: #none [NEW] vtkBoostBreadthFirstSearchTree.cxx:56:14: error: 'const class boost::detail::reverse_graph_edge_descriptorvtkEdgeType' has no member named 'underlying_desc' This issue is upstream: the VTK code depends on Boost internals and needs patch for 1.49. I've filed the bug and will work with upstream http://vtk.org/Bug/view.php?id=12988 Old Issues -- These issues were uncovered when the defaults switched to 1.48, and remain unfixed. Two of these have a patch in PTS, the third is for a package (wesnoth-1.8) that is superceeded and won't be fixed. openvrml: #652790 [PENDING] /usr/include/boost/multi_index/detail/scope_guard.hpp:122:29: error: 'boost::mpl' has not been declared wesnoth-1.8: #653806 [WONTFIX] error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable)' is private (known bug, fixed in wesnoth-1.10; won't be fixed in wesnoth-1.8) witty: #653807 [PATCH] random_device.cpp:45:63: error: 'const result_type boost::random::random_device::min_value' is not a static member of 'class boost::random::random_device' (patch known from boost 1.48) Unrelated to Boost -- These are all either due to inability to satisfy build-depends or a build failure unrelated to boost. All I plan to do is file FTBFS bugs where none yet exist. Tags used: [DEPS] Cannot install all build dependencies, not related to boost [FTBFS] Failed To Build From Source, not related to boost [SOVER] Package builds library with SOVERSION 4.7.0, but installs or links to version 4.6.0 csound: #660232 [FTBFS] scons: *** [_csnd.so] Implicit dependency `/usr/lib/libpython2.7.a' not found, needed by target `_csnd.so'. ember: #629767 [DEPS] Build-Depends dependency for ember cannot be satisfied because the package libceguiogre-dev cannot be found esys-particle: #none [DEPS] libvtk5-dev : Depends: libnetcdf-dev but it is not going to be installed feel++: #none [DEPS] Build-Depends dependency for feel++ cannot be satisfied because package libpetsc3.1-dev has no candidate version freecad: #none [FTBFS] AppPartPy.cpp:495:69: error: no matching function for call to 'BRepBuilderAPI_MakeFace::BRepBuilderAPI_MakeFace(Handle_Geom_Plane, double, double, double, double)' (verified failure on sid) gnuradio: #none [DEPS] dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. gofigure2: #none [DEPS] libvtk5-qt4-dev : Depends: libvtk5-dev (= 5.8.0-7) but it is not going to be installed gpsdrive: #646446 [FTBFS] mapnik.cpp:33:15: error: 'mapnik::Image32' has not been declared kdebase-workspace: #none [SOVER] cp: cannot stat `debian/tmp/usr/lib/libplasma_applet-system-monitor.so.4.6.0': No such file or directory kdeedu: #none [SOVER] cp: cannot stat `debian/tmp/usr/lib/libakregatorinterfaces.so.4.6.0': No such file or directory kdepim: #none [SOVER] cp: cannot stat `debian/tmp/usr/lib/libakonadi-xml.so.4.6.0': No such file or directory kdepim-runtime: #none [SOVER] cp: cannot stat `debian/tmp/usr/lib/libakonadi-xml.so.4.6.0': No such file or directory libgdf: #none [FTBFS] make[1]: *** [override_dh_auto_install] Error 1 osmium: #none [FTBFS] ../include/osmium/osm/position.hpp:31:35: fatal error: geos/geom/Coordinate.h: No such file or directory performous: #none [FTBFS] CMake Error: Required library Pango NOT FOUND. player: #662593 [FTBFS] /usr/bin/ld: cannot find -lgeos smc: #none [FTBFS] video.h:26:62: fatal error
Re: Bug#653823: transition: boost-defaults
Hello, On Sat, Mar 03, 2012 at 06:09:33PM +0100, Julien Cristau wrote: On Sat, Dec 31, 2011 at 01:29:58 -0600, Steve M. Robbins wrote: I would like to change Debian's default boost version from 1.46.1 to 1.48. This change does not directly impact any binary packages. However, it will affect the buildability of source packages. I set up http://release.debian.org/transitions/html/boost1.48.html to track the rebuild status of the reverse dependencies. Thanks, Julien. I need some guidance from the release team regarding Boost. Last Sunday I uploaded another new version (1.49). It's still in NEW, but I'd like to transition boost-defaults to 1.49 ASAP. I plan to do local rebuilds as I did for 1.48 prior to transitioning and submit any patches necessary to support Boost 1.49. Based on my experience with 1.48, that will likely take some weeks (say 4). I'm not 100% sure what happens when a transition tracker is set up (as for boost1.48). But I fear it may consume release team resources scheduling rebuilds and the like. If so, the question for the release team is: do you want to do it for 1.48 or wait for the 1.49 transition? As far as I know, the Wheezy freeze is still on for June. The next boost release should be in late May, which I suspect means it will be too late for me to package for the June freeze. Thus my proposal is that 1.49 be the default version of boost for Wheezy. This is why I raise the idea of skipping 1.48 and concentrating on migrating boost defaults to 1.49. Appreciate any feedback. Thanks, -Steve signature.asc Description: Digital signature
Re: Processed: tagging as pending bugs that are closed by packages in NEW
On Wed, Feb 01, 2012 at 07:57:01AM +, Adam D. Barratt wrote: On 01.02.2012 07:09, ow...@bugs.debian.org wrote: # Source package in NEW: boost-defaults tags 653823 + pending Bug #653823 [release.debian.org] transition: boost-defaults Please don't do that. Aside from being arguably inappropriate (along with a bunch of other cases in which pseudo-package bugs are closed in package uploads), it's also wrong... My apologies; I just wanted to mark it closed while it was top of my mind. Otherwise, I will tend to forget things. The base goal of any transition is for a package (or more commonly set of packages) to migrate to testing. Having the new package accepted in to unstable is a key step on the path to that goal, but it doesn't resolve anything in and of itself. I didn't understand that, but it makes sense. I will reopen the bug after boost-defaults is processed. Assuming I remember :-) Regards, -Steve signature.asc Description: Digital signature
Bug#653823: Status update: ready to transition this week
Hi, As previously mentioned, all known build failures have patches in the BTS. This weekend, I ran a new rebuild of 241 packages that build-depend on some part of boost-defaults. No new boost-related failures were found. I have uploaded six NMUs to delayed/10. There are only three packages left: Two that need an updated random_device: python-visual #652798 witty #653807 After fixing these, I think it is safe enough to upload a new boost defaults. That should happen this week. The last package, I will not touch since there is an unrelated build problem after fixing the boost issue. openvrml #652790 Regards, -Steve signature.asc Description: Digital signature
Re: Plans for ITK version 4
On Tue, Jan 24, 2012 at 08:38:44AM -0500, Dominique Belhachemi wrote: Steve, Thanks for all the work. It would be good to have ITK4 in 'experimental'. Having coexisting packages is nice to have but will cause probably too much trouble (especially if we build all the language wrappers again) Since it's released, I was planning to upload straight to 'unstable'. Do you think there's a need to stage in 'experimental' first? -Steve signature.asc Description: Digital signature
Re: Plans for ITK version 4
On Sat, Jan 28, 2012 at 03:11:18PM +0100, Mathieu Malaterre wrote: Since it's released, I was planning to upload straight to 'unstable'. Do you think there's a need to stage in 'experimental' first? ITK will be build against gdcm. I would prefer to see gdcm transition (#657288) to have ended (ie. gdcm 2.2.x into unstable) first. I'm not sure what your concern is; can you elaborate? ITK 4 builds with the gdcm in unstable so if it builds OK with the new gdcm, I don't see it will hinder the latter's transition. Moreover, I expect ITK 4 to be undergoing repeated source uploads to get it building everywhere (3.20.0 got up to rev -17) so it's likely that gdcm 2.2 gets into 'testing' before ITK 4 does for this reason alone. Regards, -Steve signature.asc Description: Digital signature
Re: Plans for ITK version 4
On Sat, Jan 28, 2012 at 01:25:46PM -0500, Dominique Belhachemi wrote: On Sat, Jan 28, 2012 at 4:43 AM, Steve M. Robbins st...@sumost.ca wrote: On Tue, Jan 24, 2012 at 08:38:44AM -0500, Dominique Belhachemi wrote: Steve, Thanks for all the work. It would be good to have ITK4 in 'experimental'. Having coexisting packages is nice to have but will cause probably too much trouble (especially if we build all the language wrappers again) Since it's released, I was planning to upload straight to 'unstable'. Do you think there's a need to stage in 'experimental' first? I think it is better to have ITK4 in experimental for one or two weeks. This is just to be on the safe side, there are sometimes unexpected problems with including cmake configuration files. I fully expect a number of problems with configuration. However, I see no problem with working this out in unstable rather than experimental. The new packages do not replace any existing ones and nothing will build-depend on the new packages at first. Can you explain what issue you see with working this out in unstable? Thanks, -Steve signature.asc Description: Digital signature
Re: Plans for ITK version 4
On Sat, Jan 28, 2012 at 09:07:34PM +0100, Mathieu Malaterre wrote: Steve, On Sat, Jan 28, 2012 at 7:27 PM, Steve M. Robbins st...@sumost.ca wrote: On Sat, Jan 28, 2012 at 03:11:18PM +0100, Mathieu Malaterre wrote: Since it's released, I was planning to upload straight to 'unstable'. Do you think there's a need to stage in 'experimental' first? ITK will be build against gdcm. I would prefer to see gdcm transition (#657288) to have ended (ie. gdcm 2.2.x into unstable) first. I'm not sure what your concern is; can you elaborate? Just trying to avoir another set of #(655783 655784 655785 655786 655787 655788) because ITK will be build using gdcm 2.0 So, what was the root cause of these bugs? I can't see a change in ITK during this time period. The most likely suspect I can see is a new gdcm version 2.0.19 in early January. Did it change ABI without changing SOVERSION? In any event, the proximal cause of this problem is due to ants, igstk and the like build-depending on ITK (v3). Initially, ITK v4 will have ZERO such reverse dependencies and thus ZERO impact on a gdcm transition. ITK 4 builds with the gdcm in unstable so if it builds OK with the new gdcm, I don't see it will hinder the latter's transition. The fact that ITK builds against 2.0 does not mean it builds fine with 2.2 from experimental. I would really like to have feedback on that combination just as fast as you for ITK OK, that's a different matter: I can pull the gdcm 2.2 packages into a chroot and build ITK v4 against it. (Or, you can do it since the ITK svn repository now builds) Moreover, I expect ITK 4 to be undergoing repeated source uploads to get it building everywhere (3.20.0 got up to rev -17) so it's likely that gdcm 2.2 gets into 'testing' before ITK 4 does for this reason alone. As said above, during this time, people will get another set of RC bugs identical to #655783 and al. Not until ITK v4 has packages that build-depend on it. I don't anticipate that will happen for quite some time. In the worst case, we can delay transition of ITK v4 to testing (by an artificial RC bug, if necessary) until gdcm 2.2 transitions. Can you just do at least one upload to experimental first ? I will do a test build of ITK 4 against gdcm 2.2 and post the results for discussion. -Steve signature.asc Description: Digital signature
Re: Plans for ITK version 4
On Sat, Jan 28, 2012 at 03:04:52PM -0600, Steve M. Robbins wrote: I will do a test build of ITK 4 against gdcm 2.2 and post the results for discussion. I took the source tree for gdcm 2.2.0-1 [1] and built it in a clean SID chroot. Then I took the ITK 4.0.0-1 sources [2] into a new clean SID chroot. I installed the -dev and lib gdcm packages I just built, and built ITK without trouble. So I see no issue, at least not for amd64. Cheers, -Steve [1] svn.debian.org/svn/debian-med/trunk/packages/gdcm/tags/2.2.0-1 [2] svn.debian.org/svn/debian-med/trunk/packages/insighttoolkit/trunk signature.asc Description: Digital signature
Plans for ITK version 4
Hi, As some of you know ITK, the Insight Toolkit, version 4.0.0 was released last month [1]. This is a major update from the previous version 3.20.1, and upstream deliberately broke the API in certain cases [2]. As such, I think it would be a disservice to our users to force an abrupt transition by uploading ITK 4 and removing ITK 3. Instead, I propose to keep ITK 3.20.1 in Debian and upload a new source package, insighttoolkit4 (or maybe itk4?). The existing binary packages already carry the major version (e.g. libinsightoolkit3-dev) and so can coexist with libinsightoolkit4-dev and the like in the repository (I haven't made up my mind about co-installability). I am in the process of getting a clean build of ITK 4 locally. I think I should succeed this week, so I'd appreciate feedback on the plan before I upload this weekend. Thanks, -Steve [1] http://www.kitware.com/news/home/browse/ITK?2011_12_21ITK+4.0+is+Now+Available+and+Ready+for+Download! [2] http://www.kitware.com/blog/home/post/184 signature.asc Description: Digital signature
Bug#653823: Mission Acomplished.
Dear Release Team, Thanks to the hard work of Tobias, all known build failures related to Boost 1.48 are either pending or have a patch readily available. Is there anything further you need me to do before flipping the Boost Default and closing this bug? Thanks, -Steve signature.asc Description: Digital signature
Bug#653823: status update
Status as of 2012-01-08: 5 of the 22 boost-related bugs have fixes uploaded. Another (libreoffice) has been uploaded to experimental. Fixed in Experimental (1): -- libreoffice #652784 [fixed in 1.3.5.0~beta2-1] acceleratorcache.cxx:64:29: error: no match for 'operator=' Known Fix (13): --- avogadro #653625 [moc] Parse error at BOOST_JOIN fgrun #652775 [singleton,caused by #652788] error: boost/pool/detail/singleton.hpp: No such file or directory flightgear #652797 [singleton,caused by #652788] error: boost/pool/detail/singleton.hpp: No such file or directory ovito #652795 [moc] has_binary_operator.hp:50: Parse error at BOOST_JOIN pinot #652786 [singleton] Memory.h:184:11: error: 'singleton_default' in namespace 'boost::details::pool' does not name a type pion-net #653787 [io_service] 'boost::asio::ssl::streamboost::asio::basic_stream_socketboost::asio::ip::tcp ::lowest_layer_type' has no member named 'io_service' python-visual #652798 [random] random_device.cpp:30:63: error: 'const result_type boost::random::random_device::min_value' is not a static member of 'class boost::random::random_device' qpid-cpp #653795 [singleton] fatal error: boost/pool/detail/singleton.hpp: No such file or directory qt-gstreamer #653796 [moc] has_binary_operator.hp:50: Parse error at BOOST_JOIN simgear #652788 [singleton] error: boost/pool/detail/singleton.hpp: No such file or directory vtk #653805 [upstream,patch] vtkBoostBreadthFirstSearchTree.cxx:98:5: error: 'class boost::detail::reverse_graph_edge_descriptorvtkEdgeType' has no member named 'Id' wesnoth-1.8 #653806 [pending]: error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable)' is private witty #653807 [random] random_device.cpp:45:63: error: 'const result_type boost::random::random_device::min_value' is not a static member of 'class boost::random::random_device' Unknown Fix (3): drizzle #653627 [TODO] constructor 'boost::detail::shared_count::shared_count(P, boost::detail::sp_inplace_tagD)' eiskaltdcpp #655184 [TODO] error: 'boost::interprocess::detail' has not been declared openvrml #652790 [TODO] scope_guard.hpp:122:29: error: 'boost::mpl' has not been declared signature.asc Description: Digital signature
Bug#653823: transition: boost-defaults
On Sat, Dec 31, 2011 at 12:13:46PM +0100, Julien Cristau wrote: On Sat, Dec 31, 2011 at 01:29:58 -0600, Steve M. Robbins wrote: There are 237 source packages in SID that build-depend on one of the packages in boost-defaults. I have done a test-build with all 237 packages in a chroot sid environment containing updated boost-defaults. There were 22 build failures related to the new boost. An additional 14 build failures were detected that are not related to boost. Sourceful uploads will be required to fix all these build failures. Thanks a lot for this Steve. OK, so what's the next step? Do you need me to do anything further before flipping the defaults? Thanks, -Steve signature.asc Description: Digital signature
Bug#653823: transition: boost-defaults
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Briefly, package boost-defaults provides libboost-dev and similar
unversioned -dev packages that depend on a default versioned package
such as libboost1.46-dev.
I would like to change Debian's default boost version from 1.46.1 to
1.48. This change does not directly impact any binary packages.
However, it will affect the buildability of source packages.
There are 237 source packages in SID that build-depend on one of the
packages in boost-defaults. I have done a test-build with all 237
packages in a chroot sid environment containing updated
boost-defaults. There were 22 build failures related to the new
boost. An additional 14 build failures were detected that are not
related to boost. Sourceful uploads will be required to fix all these
build failures.
The results are summarized below, with the 22 boost-related failures
broken down into two groups: 14 where the fix is known and/or pending,
and 8 where the source fix is presently not known. However, even the
latter group can be fixed immediately by changing the build-deps to
use libboost1.46-dev and similar versioned packages.
All the 36 FTBFS have bugs filed, as noted below, so there should not
be further impact for the QA automated archive rebuild folks.
Known fixes (14):
aptitude #653812 [pending] error: Boost install not found, too old, or
incomplete; install libboost-dev.
anytun #652767 [io_service] error: 'boost::asio::ip::tcp::acceptor' has no
member named 'io_service'
avogadro #653625 [moc] Parse error at BOOST_JOIN
fgrun #652775 [singleton,caused by #652788] error:
boost/pool/detail/singleton.hpp: No such file or directory
flightgear #652797 [singleton,caused by #652788] error:
boost/pool/detail/singleton.hpp: No such file or directory
libreoffice #652784 [fixed in 1.3.5.0~beta2-1] acceleratorcache.cxx:64:29:
error: no match for 'operator='
ovito #652795 [moc] has_binary_operator.hp:50: Parse error at BOOST_JOIN
pinot #652786 [singleton] Memory.h:184:11: error: 'singleton_default' in
namespace 'boost::details::pool' does not name a type
pion-net #653787 [io_service]
'boost::asio::ssl::streamboost::asio::basic_stream_socketboost::asio::ip::tcp
::lowest_layer_type' has no member named 'io_service'
qpid-cpp #653795 [singleton] fatal error: boost/pool/detail/singleton.hpp: No
such file or directory
qt-gstreamer #653796 [moc] has_binary_operator.hp:50: Parse error at
BOOST_JOIN
simgear #652788 [singleton] error: boost/pool/detail/singleton.hpp: No such
file or directory
sslsniff #652756 [io_service] error: 'boost::asio::ip::tcp::acceptor' has no
member named 'io_service'
yade #653817 [embed,pending] error: 'init' is not a member of 'traits {aka
boost::math::detail::fp_traits_nativefloat}'
Fix unknown (8):
-
drizzle #653627 [TODO] constructor
'boost::detail::shared_count::shared_count(P, boost::detail::sp_inplace_tagD)'
eiskaltdcpp # [TODO] error: 'boost::interprocess::detail' has not been declared
monotone #653764 [TODO] lgamma_small.hpp:483:38: error: expected
primary-expression before 'do'
openvrml #652790 [TODO] scope_guard.hpp:122:29: error: 'boost::mpl' has not
been declared
python-visual #652798 [TODO] random_device.cpp:30:63: error: 'const result_type
boost::random::random_device::min_value' is not a static member of 'class
boost::random::random_device'
vtk #653805 [TODO] vtkBoostBreadthFirstSearchTree.cxx:98:5: error: 'class
boost::detail::reverse_graph_edge_descriptorvtkEdgeType' has no member named
'Id'
wesnoth-1.8 #653806 [TODO]: error:
'boost::noncopyable_::noncopyable::noncopyable(const
boost::noncopyable_::noncopyable)' is private
witty #653807 [TODO] random_device.cpp:45:63: error: 'const result_type
boost::random::random_device::min_value' is not a static member of 'class
boost::random::random_device'
Failures not related to boost (14):
---
agave #652845 [pending,notboost] error: format not a string literal and no
format arguments [-Werror=format-security]
ball #653626 [notboost] error: passing 'const BALL::PeriodicBoundary' as 'this'
argument of 'BALL::Size BALL::PeriodicBoundary::addSolvent(const
BALL::String)' discards qualifiers [-fpermissive]
ember #629767 [notboost] FTBFS: build-dependency not installable:
libceguiogre-dev
esperanza #653814 [notboost] FTBFS: undefined reference to 'XKeysymToKeycode'
(and others)
getfem++ #653820 [notboost] FTBFS: install: cannot stat `macros/*.bin': No such
file or directory
gnash #651625 [patch,notboost] error: new declaration 'char*
NP_GetMIMEDescription()' ambiguates old declaration 'const char*
NP_GetMIMEDescription()'
gnuradio #642716 [notboost] FTBFS: gr_vmcircbuf_createfilemapping:
createfilemapping is not available
gpsdrive #646446 [notboost] mapnik.cpp:33:15: error: 'mapnik::Image32' has not
been declared
salome [notboost] multiple FTBFS
scenic #653821
Bug#653823: More info on Known Fixes
Some more info on items in the Known Fixes category follows.
Parse error at BOOST_JOIN
---
Tag [moc]
The parse error is from Qt's tools moc and lconvert. These tools do
not handle the entire C++ language; see the Qt issue
https://bugreports.qt.nokia.com/browse/QTBUG-22829
The workaround is to abuse the Boost header guards by defining it
on the moc/lconvert command line, thus avoiding having to parse
the boost headers. Pass -DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED
to the moc invocation. If using cmake:
QT4_WRAP_CPP(sources ${moc-sources} OPTIONS
-DBOOST_TT_HAS_OPERATOR_HPP_INCLUDED)
'boost::asio::ip::tcp::acceptor' has no member named 'io_service'
-
Tag [io_service]
Boost 1.47 removed a deprecated function [1]:
Removed the deprecated member functions named io_service(). The
get_io_service() member functions should be used instead.
The get_io_service() function is available in the current default
Boost (version 1.46.1) [2], so the change can be made now.
[1] http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/history.html
[2]
http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/reference/ip__tcp/acceptor.html
Removal of boost::details::pool::singleton_default
--
Tag [singleton]
Prior to 1.48, Boost.Pool used a singleton base class. It was an
implementation detail, now removed, but some external packages
depended upon it. This is an upstream bug, since the class was never
intended as a public interface.
The breakage may manifest in a couple of ways:
* boost/pool/detail/singleton.hpp: No such file or directory
* 'singleton_default' in namespace 'boost::details::pool' does not name a type
The class in singleton.hpp is small enough that it could simply be
included directly into the using source code.
signature.asc
Description: Digital signature
Ipe transition needs some help
Hi, Ipe 7.1.1-1 was uploaded 17 days ago with no RC bugs but has not made it into testing. The excuse is below. Does this need some manual intervention from the release team? Excuse for ipe 17 days old (needed 10 days) out of date on i386: libipe7.1.0 (from 7.1.0-1) out of date on amd64: libipe7.1.0 (from 7.1.0-1) out of date on armel: libipe7.1.0 (from 7.1.0-1) out of date on ia64: libipe7.1.0 (from 7.1.0-1) out of date on kfreebsd-amd64: libipe7.1.0 (from 7.1.0-1) out of date on kfreebsd-i386: libipe7.1.0 (from 7.1.0-1) out of date on mips: libipe7.1.0 (from 7.1.0-1) out of date on mipsel: libipe7.1.0 (from 7.1.0-1) out of date on powerpc: libipe7.1.0 (from 7.1.0-1) out of date on s390: libipe7.1.0 (from 7.1.0-1) out of date on sparc: libipe7.1.0 (from 7.1.0-1) Not considered Thanks, -Steve signature.asc Description: Digital signature
Re: Ipe transition needs some help
On Thu, Dec 29, 2011 at 07:46:24PM +0100, Julien Cristau wrote: On Thu, Dec 29, 2011 at 12:21:04 -0600, Steve M. Robbins wrote: Hi, Ipe 7.1.1-1 was uploaded 17 days ago with no RC bugs but has not made it into testing. The excuse is below. Does this need some manual intervention from the release team? No, libipe7.1.0 needs to stop having reverse dependencies. I see. Somehow I thought that the excuses report captured such problems in dependendent packages, something like the packages waiting on Which means libcgal-ipelets needs to be built against the new version. The libcgal-ipelets package is non-free. I would not have expected non-free to be considered as part of these transitions. Is it? -Steve signature.asc Description: Digital signature
Re: Ipe transition needs some help
On Thu, Dec 29, 2011 at 07:33:14PM +0100, Cyril Brulebois wrote: Hi, Steve M. Robbins st...@sumost.ca (29/12/2011): Ipe 7.1.1-1 was uploaded 17 days ago with no RC bugs but has not made it into testing. The excuse is below. Does this need some manual intervention from the release team? Excuse for ipe 17 days old (needed 10 days) out of date on i386: libipe7.1.0 (from 7.1.0-1) out of date on amd64: libipe7.1.0 (from 7.1.0-1) out of date on armel: libipe7.1.0 (from 7.1.0-1) out of date on ia64: libipe7.1.0 (from 7.1.0-1) out of date on kfreebsd-amd64: libipe7.1.0 (from 7.1.0-1) out of date on kfreebsd-i386: libipe7.1.0 (from 7.1.0-1) out of date on mips: libipe7.1.0 (from 7.1.0-1) out of date on mipsel: libipe7.1.0 (from 7.1.0-1) out of date on powerpc: libipe7.1.0 (from 7.1.0-1) out of date on s390: libipe7.1.0 (from 7.1.0-1) out of date on sparc: libipe7.1.0 (from 7.1.0-1) Not considered see daily cruft report, which mentions it: http://ftp-master.debian.org/cruft-report-daily.txt OK, thanks. Do I need to file a bug with the recommended command line? Now I'm looking at the more excuses output for ipe [1] and it says ipe is not yet built on i386: 7.1.0-1 vs 7.1.1-1 (missing 1 binary: libipe7.1.0) The corresponding page for package arb [2] is more explicit: arb no longer provides binary arb-common. ftpmaster needs to remove it. Why is that? Thanks, -Steve [1] http://release.debian.org/migration/testing.pl?package=ipe [2] http://release.debian.org/migration/testing.pl?package=arb signature.asc Description: Digital signature
Bug#653665: nmu: cgal_3.9-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu cgal_3.9-1 . ALL . -m rebuild against new libipe7.1.1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20111230031737.7924.51894.reportbug@localhost
Re: [pkg-boost-devel] Boost defaults change (1.46.1 -- 1.48)
On Wed, Dec 28, 2011 at 12:47:34PM +0100, Rene Engelhard wrote: But what worries me more is that you AGAIN ignored http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652681. I was working off a rebuild of SID. Perhaps my last message didn't clearly state that. So all the bugs reported were for the SID versions of the package. 652681 concerns a newer version found only in experimental as far as I know. That's not to say that I don't think the bug is important. It is important. Ignoring #652681 doesn't make the build failure on the version which is supposed to be in wheezy go away... Of course. So if you want my advice, here is what I would do about it. First, to help the gcc maintainers, complete the bug report according to file:///usr/share/doc/gcc-4.6/README.Bugs. Second, when the time comes to upload libreoffice 3.5 to unstable, select one of the two following options: 1. If 652681 is fixed, upload as-is. 2. If not, change boost build-deps to 1.46 version and upload. Hope this helps, -Steve signature.asc Description: Digital signature
Re: Boost defaults change (1.46.1 -- 1.48)
On Tue, Dec 27, 2011 at 10:42:07AM +0100, Rene Engelhard wrote: Hi, I'd like to point out that any resulting build failures are quite easy to fix: either (a) contact package upstream for boost 1.48 changes; or It is? #652681 doesn't look like it. I'll just note that an Internal Compiler Error is always a bug in the compiler, by definition. It may be true that boost exposed it, but boost is not the cause of the compiler bug. It would be helpful if you provided more details for the gcc folks. Will 1.46 be around long enough that reverting to 1.46 is an option there? Absolutely, 1.46 is an option. That's why I suggested it. Debian has been releasing with at least two boost versions for a while now. The less-up-to-date version is often dictated by needs of other packages, such as libreoffice. At least libreoffice is affected by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652784. The upstream bug reports a one-liner fix of building with -std=c++0x. Does that work for Debian? Cheers, -Steve signature.asc Description: Digital signature
Re: Boost defaults change (1.46.1 -- 1.48)
On Tue, Dec 27, 2011 at 04:45:21PM +0100, Lucas Nussbaum wrote: On 26/12/11 at 22:40 -0600, Steve M. Robbins wrote: It would be quite helpful to do a rebuild of the 237 boost reverse dependencies. Lucas Nussbaum seems to be able to do this: can you run a rebuild with updated boost-defaults? I already did that, since i did a rebuild while boost-defaults was pointing to .46. You can find the results in collab-qa svn, in archive-rebuilds/2011-12-20-lsid64-amd64 Great, thanks! If it's only 237 packages, I would prefer if you rebuilt them manually: the time taken to organize the rebuild is likely to be higher than the time it would take to just rebuild them locally. Note that I am starting from scratch. I know how to use pbuilder and how to manually download and build a package. At my present rate of 1-2 per week, it would take me several years to rebuild them all locally. Are there scripts etc to automate this somewhere? Thanks, -Steve signature.asc Description: Digital signature
Re: Boost defaults change (1.46.1 -- 1.48)
On Tue, Dec 27, 2011 at 11:28:14AM +0100, Thomas Krennwallner wrote: As long as something depends on 1.46, I assume that it should be around. The current situation is sub-optimal, because almost everything depends on the non-versioned boost libs of boost-defaults, despite boost's tendency to break packages when switching to a new version. In fairness, boost doesn't break everything on each release, though it often feels like it :-). One issue with boost is that it is really a conglomeration of several dozen libraries, some of which are quite stable. Others are less so, sometimes by intention, sometimes inadvertently. The other big issue with boost is they have an agressive release schedule of 4 times/year. The question is, which strategy is better? (1) Clearly record the dependencies in packages that depend on boost, i.e., Build-Depends on libboost-foo1.46-dev instead of libboost-foo-dev, or (2) let boost-defaults decide which version of boost is the currently stable boost. IMHO (2) just hides FTBSes of the packages. I will offer a third strategy: (3) Offer boost-defaults for: advanced users, for packages that generally stick to the stable parts of boost, for packages that or have upstream authors that track the latest boost. Other packages can build to versioned boost dev packages known to work. Due to the frequent boost releases, there is a large cost to using the versioned dependencies, so I encourage using the non-versioned packages when possible. This is an evolving process and I think we're still learning which category a given package might fall into. So it's not a surprise that some adjustments are necessary with each boost release. And, of course, there are the standard number of bugs in a given boost release so even if unversioned devs is the right strategy for a given package, a new boost may still break it until a boost bug is fixed. Regards, -Steve signature.asc Description: Digital signature
Re: Boost defaults change (1.46.1 -- 1.48)
On Tue, Dec 27, 2011 at 06:32:16PM +, Adam D. Barratt wrote: On Tue, 2011-12-27 at 10:52 -0600, Steve M. Robbins wrote: On Tue, Dec 27, 2011 at 10:42:07AM +0100, Rene Engelhard wrote: Will 1.46 be around long enough that reverting to 1.46 is an option there? Absolutely, 1.46 is an option. That's why I suggested it. Debian has been releasing with at least two boost versions for a while now. The less-up-to-date version is often dictated by needs of other packages, such as libreoffice. fwiw, Squeeze shipped with only one boost version (1.42). I stand corrected. [I mostly pay attention to unstable, which has generally had two versions available for a long while. I'm going to avoid making absolute statements now :-)] -Steve signature.asc Description: Digital signature
Re: [pkg-boost-devel] Boost defaults change (1.46.1 -- 1.48)
On Tue, Dec 27, 2011 at 11:20:16AM -0600, Steve M. Robbins wrote: On Tue, Dec 27, 2011 at 04:45:21PM +0100, Lucas Nussbaum wrote: On 26/12/11 at 22:40 -0600, Steve M. Robbins wrote: It would be quite helpful to do a rebuild of the 237 boost reverse dependencies. Lucas Nussbaum seems to be able to do this: can you run a rebuild with updated boost-defaults? I already did that, since i did a rebuild while boost-defaults was pointing to .46. You can find the results in collab-qa svn, in archive-rebuilds/2011-12-20-lsid64-amd64 OK, with thanks to Lucas Nussbaum for the build results, I can report that only the following 23 of 237 boost rdep packages failed to build with boost-defaults pointing to 1.48. This shouldn't take a lot of effort to bring down to a manageable level and it looks like bugs are already filed. I'm bcc'ing this email to maintainers of the list of packages, below. Each of you, I'd appreciate it if you could check with the upstream authors whether a fix is already available. Please send an update to the appropriate bug with the upstream response or mark the bug forwarded to the upstream issue. I'm hoping that some of these can be fixed very quickly and we'll shortly know the true impact of a boost defaults change. Thanks very much, -Steve agave 0.4.7-2 Failed [GCC_ERROR] #564850 RECHECK anytun 0.3.3-2.1 Failed [GCC_ERROR] #652767: anytun: FTBFS: syncServer.cpp:112:92: error: 'boost::asio::ip::tcp::acceptor' has no member named 'io_service' drizzle 2011.03.13-1 Failed [UNKNOWN] #647743 ember 0.5.7-1.1 Failed [BUILDDEPS] #629767: ember: FTBFS: build-dependency not installable: libceguiogre-dev RECHECK fgrun 1.6.0-1 Failed [UNKNOWN] #652775: fgrun: FTBFS: Singleton.hxx:4:43: fatal error: boost/pool/detail/singleton.hpp: No such file or directory flightgear 2.4.0-1 Failed [UNKNOWN] #652797: flightgear: FTBFS: Singleton.hxx:4:43: fatal error: boost/pool/detail/singleton.hpp: No such file or directory gnuradio 3.2.2.dfsg-1.1 Failed [UNKNOWN] #642716: gnuradio: FTBFS: gr_vmcircbuf_createfilemapping: createfilemapping is not available RECHECK gpsdrive 2.10~pre4-6.dfsg-5.1 Failed [GCC_ERROR] #646446: gpsdrive: FTBFS: mapnik.cpp:33:15: error: 'mapnik::Image32' has not been declared RECHECK libreoffice 1:3.4.4-2 Failed [GCC_ERROR] #652784: libreoffice: FTBFS: acceleratorcache.cxx:64:29: error: no match for 'operator=' in '((framework::AcceleratorCache*)this)-framework::AcceleratorCache::m_lCommand2Keys = rCopy.framework::AcceleratorCache::m_lCommand2Keys' openvrml 0.18.8-5 Failed [GCC_ERROR] #652790: openvrml: FTBFS: scope_guard.hpp:122:29: error: 'boost::mpl' has not been declared ovito 0.9.2-1 Failed [UNKNOWN] #652795: ovito: FTBFS: usr/include/boost/type_traits/detail/has_binary_operator.hp:50: Parse error at BOOST_JOIN pinot 0.96-1.1 Failed [GCC_ERROR] #652786: pinot: FTBFS: Memory.h:184:11: error: 'singleton_default' in namespace 'boost::details::pool' does not name a type python-visual 1:5.12-1.3 Failed [GCC_ERROR] #652798: python-visual: FTBFS: random_device.cpp:30:63: error: 'const result_type boost::random::random_device::min_value' is not a static member of 'class boost::random::random_device' qt-gstreamer 0.10.1-2 Failed [UNKNOWN] TODO NEWFAIL salome 5.1.3-12 Failed [BUILDDEPS] #629765: salome: FTBFS: build-dependency not installable: sip4 RECHECK scenic 0.6.3-1 Failed [UNKNOWN] #615772 RECHECK simgear 2.4.0-1 Failed [UNKNOWN] #652788: simgear: FTBFS: ../../simgear/structure/Singleton.hxx:4:43: fatal error: boost/pool/detail/singleton.hpp: No such file or directory smc 1.9-4 Failed [UNKNOWN] #646464: smc: FTBFS: audio/../core/../objects/../objects/../video/video.h:26:62: fatal error: RendererModules/OpenGLGUIRenderer/openglrenderer.h: No such file or directory RECHECK spring 0.82.7.1+dfsg1-3 Failed [GCC_ERROR] #652768: spring: FTBFS: FPUSettings.h:322:15: error: expected unqualified-id before '__const' sslsniff 0.8-2 Failed [GCC_ERROR] #652756: sslsniff: FTBFS: SSLConnectionManager.cpp:47:74: error: 'boost::asio::ip::tcp::acceptor' has no member named 'io_service' strigi 0.7.6-2 Failed [UNKNOWN] #618118: strigi: FTBFS: dh_makeshlibs: dpkg-gensymbols -plibsearchclient0 -Idebian/libsearchclient0.symbols.amd64 -Pdebian/libsearchclient0 returned exit code 1 RECHECK wesnoth-1.8 1:1.8.6-1 Failed [GCC_ERROR] #652765: wesnoth-1.8: FTBFS: noncopyable.hpp:27:7: error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable)' is private witty 3.1.10-1 Failed [GCC_ERROR] #642674: witty: FTBFS: WPdfImage.C:74:30: error: 'HPDF_UseUTFEncodings' was not declared in this scope RECHECK signature.asc Description: Digital signature
Boost defaults change (1.46.1 -- 1.48)
Hello, The latest Boost (1.48) is now in testing, and I'd like to switch the defaults. My first plan was to simply announce the switch then make it. I did so and got an immediate email from the release team asking to revert the default change, which I did. On Tue, Dec 20, 2011 at 08:00:15PM -0600, Steve M. Robbins wrote: On Mon, Dec 19, 2011 at 10:33:26PM +0100, Julien Cristau wrote: I heard of at least two failures in the last couple of hours: libreoffice (#652681), and wesnoth (#652677). As such, I'd appreciate if you could: - revert boost-defaults to 1.46 for the time being Done. - test-build at least the most prominent reverse deps against 1.48 before bumping it again - contact debian-release before that bump, so we can coordinate a timing that doesn't suck with regards to other ongoing transitions. Now I'd like to coordinate a time for the change. I'd like to point out that any resulting build failures are quite easy to fix: either (a) contact package upstream for boost 1.48 changes; or (b) change the build-dependency from libboostfoo-dev to libboostfoo1.46-dev. It would be quite helpful to do a rebuild of the 237 boost reverse dependencies. Lucas Nussbaum seems to be able to do this: can you run a rebuild with updated boost-defaults? Thanks, -Steve signature.asc Description: Digital signature
Re: Heads-up: Boost defaults changing from 1.46 to 1.48
On Mon, Dec 19, 2011 at 10:33:26PM +0100, Julien Cristau wrote: On Sat, Dec 10, 2011 at 21:23:49 -0600, Steve M. Robbins wrote: Hi, Boost 1.48 was uploaded to sid about 9 days ago so it should transition to testing in the next day or so. My plan is to update the default boost version to 1.48 immediately following this transition. I'd appreciate feedback on any build failures with 1.48 for boost-using packages. I heard of at least two failures in the last couple of hours: libreoffice (#652681), and wesnoth (#652677). As such, I'd appreciate if you could: - revert boost-defaults to 1.46 for the time being Done. - test-build at least the most prominent reverse deps against 1.48 before bumping it again - contact debian-release before that bump, so we can coordinate a timing that doesn't suck with regards to other ongoing transitions. OK, will do. -Steve signature.asc Description: Digital signature
Bug#650601: transition: libpng 1.5
On Mon, Dec 05, 2011 at 08:43:16AM +0100, Julien Cristau wrote: On Sun, Dec 4, 2011 at 23:34:37 -0600, Steve M. Robbins wrote: If the API has changed, as Nobuhiro states above, it would be incorrect for the new -dev package to provide the old, wouldn't it? No. It would only be incorrect if the plan was to keep libpng12-dev around as a real package. I'd have to disagree. If I install something named libpng12-dev, I'd expect it to have the same API as it always had. This is untrue for libpng 1.5. Nor can the provides be temporary; it would have to last until all the build-depends were changed, wouldn't it? That's what temporary means. Touche. The phrase I wanted was short term. Wouldn't it be better, instead, to leave both old and new -dev packages in the archive until all 123 dependent packages are fixed? There are 400 reverse dependencies of libpng. I don't think source changes to all of them (most just to switch a build-dependency) is a good plan. I don't know if most are just switching a build-dependency. I saw quite a number with serious changes; e.g. the new version has hidden at least one formerly-exposed class. If you really switch libpng12-dev, you instantly make these all unbuildable. Can we not keep both APIs around until all the upstreams switch over to the new API? This keeps everyone building and able to switch at the proper pace. Thanks, -Steve signature.asc Description: Digital signature
Bug#650601: transition: libpng 1.5
On Thu, Dec 01, 2011 at 11:30:19AM +, Adam D. Barratt wrote: On Thu, 1 Dec 2011 09:16:41 +0900, Nobuhiro Iwamatsu wrote: Libpng maintainers want to update libpng from 1.2 to 1.5. libpng of ABI and API has been changed by change of 1.2 to 1.5, so it needs a transition from libopng12 to libpng15. And it is necessary to change Build-depends of almost all packages into libpng-dev from libpng12-dev. Is there a good reason why the new libpng-dev couldn't at least Provide libpng12-dev in the short term? Would this allow some (most?) packages to be binNMUed? If the API has changed, as Nobuhiro states above, it would be incorrect for the new -dev package to provide the old, wouldn't it? Nor can the provides be temporary; it would have to last until all the build-depends were changed, wouldn't it? Wouldn't it be better, instead, to leave both old and new -dev packages in the archive until all 123 dependent packages are fixed? Cheers, -Steve signature.asc Description: Digital signature
Bug#637963: nmu: tiff_3.9.5-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu tiff_3.9.5-1 . ALL . -m Rebuild against libjpeg8 Currently, linking using both -ltiff and -ljpeg produces a warning: /usr/bin/ld: warning: libjpeg.so.62, needed by /usr/lib64/libtiff.so, may conflict with libjpeg.so.8 A simple rebuild of tiff (as hinted in #634194) fixes this. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20110816014510.27866.98209.reportbug@localhost
Re: Bug#623989: RM: boost1.42 -- ROM; Obsoleted by Boost1.46
Hello, On Fri, Apr 29, 2011 at 12:29:41PM +0200, Alexander Reichle-Schmehl wrote: Uhm... It doesn't look, like boost1.42 is obsolete. Even if I ignore non-release architectures, there's quite a lot of stuff left: Checking reverse dependencies... # Broken Depends: [...] # Broken Build-Depends: [...] OK, I've done NMUs for the last few packages that build-depend on boost1.42. There remain a dozen or so packages that depend on boost1.42; can these be rebuilt (against the newer boost) so that boost1.42 can be removed. Thanks, -Steve signature.asc Description: Digital signature
Re: Severity justification
severity 625521 normal thanks First: thanks again to all who helped me with this bug. On Thu, May 12, 2011 at 03:50:57PM -0400, Filipus Klutiero wrote: Hi Steve, sorry if you already received my last mail, but could you please justify severity critical for this bug? Thanks to the help of Michel Dänzer, the concensus is that the bug is really in the fbdev driver. Now that it is assigned to X, the report does not prevent a glibc migration from happening starting in 5 days. If this bug warrants delaying glibc's migration to wheezy, please inform the release team. Since the bug is exhibited with libc6 2.11, I don't think this bug is a reason to hold glibc. Bug #625522 may be, however (if accurate). Furthermore, this report now prevents migration of xorg-server. Is this a regression? So far nobody other than you reported experiencing this problem, and the bug seems to have no effect worst than preventing X startup. I don't know whether it's a regression, but the bug was exposed by a configuration that is perhaps unusual. And yes, the bug effect is to prevent X startup. -Steve signature.asc Description: Digital signature
Re: Insighttoolkit transition weirdness
On Tue, May 03, 2011 at 09:52:06AM +0200, Mehdi Dogguy wrote: On 05/03/2011 02:51 AM, Steve M. Robbins wrote: The testing migration excuses [1] claims insighttoolkit is out of date on kfreebsd-amd64 and mipsel. In fact, however, both arches are installed in the pool [2]. Can someone help this package to transition, please? That's normal. Note that the message mentions the library package (namely libinsighttoolkit3.18). It got decrufted on other architectures because there were no packages using it anymore. But, on kfreebsd-amd64 and mipsel, it seems to still have some reverse dependencies [1]. How did you generate your list? When I run apt-cache rdepends libinsighttoolkit3.18, I get a much smaller list: libinsighttoolkit3.18 Reverse Depends: tcl8.5-insighttoolkit3 python-insighttoolkit3 libinsighttoolkit3-jni libinsighttoolkit3-dev ants The first four are not a problem since they are part of insighttoolkit itself. The package ants is one that you listed. However, I don't see why it would be a problem only on kfreebsd-amd64 and mipsel. It hasn't been updated in months for any architecture according to https://buildd.debian.org/status/package.php?p=ants So, Insighttoolkit will be able to migrate when [1] is reduced to an empty list. When the reverse dependencies catch up a dependency on the newer library package (or simply drop it compeletely), we will be able to remove libinsighttoolkit3.18 on mipsel and kfreebsd-amd64, and then Insighttoolkit will be able to migrate (possibly using a hint). [1] R-deps are: (Only those present in testing are relevant here (I guess), others can be ignored. I didn't find time to check). Package: ants Architecture: mipsel Package: libigstk4 Source: igstk Architecture: mipsel Package: itksnap Source: itksnap (2.0.0+cvs20100615-1) Architecture: mipsel Package: libvmtk0.9 Source: vmtk Architecture: mipsel Package: python-vmtk Source: vmtk Architecture: mipsel Package: ants Architecture: kfreebsd-amd64 Package: libigstk4 Source: igstk Architecture: kfreebsd-amd64 Package: itksnap Source: itksnap (2.0.0+cvs20100615-1) Architecture: kfreebsd-amd64 Package: libslicer3 Source: slicer Architecture: kfreebsd-amd64 Package: slicer Architecture: kfreebsd-amd64 Package: libvtkedge Source: vtkedge Architecture: kfreebsd-amd64 Regards, -- Mehdi Dogguy ?? http://dogguy.org/ signature.asc Description: Digital signature
Insighttoolkit transition weirdness
Hi, The testing migration excuses [1] claims insighttoolkit is out of date on kfreebsd-amd64 and mipsel. In fact, however, both arches are installed in the pool [2]. Can someone help this package to transition, please? Thanks, -Steve [1] http://qa.debian.org/excuses.php?package=insighttoolkit [2] https://buildd.debian.org/status/package.php?p=insighttoolkit signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
On Mon, Mar 21, 2011 at 08:22:15PM +0100, Julien Cristau wrote: On Sat, Mar 19, 2011 at 13:23:41 -0500, Steve M. Robbins wrote: 1. Upload gmp4, as described above. In progress, will upload shortly. 2. Upload gmp introducing libgmp-dev as the real package, providing virtual packages libgmp3-dev and libgmp10-dev. Is this accurate? Anything else? I don't think 2 is necessary, or at least not right now. It's fairly independent as far as I can tell, and it's a cosmetic issue more than anything else. As far as I can tell, the only advantage of having libgmp-dev as real rather than virtual is so that packages can version their build-dep. Given that libgmp-dev is new, I'd agree it is not pressing. However, I've since learned that ghc and mlton both build-depend on themselves as well as libgmp3-dev. Further, mlton has a versioned build-dep on libgmp3-dev so the least painful way forward is to have libgmp3-dev become non-virtual once again. For this reason, I plan to upload a new gmp with non-virtual libgmp3-dev as a dummy package that depends on libgmp-dev. I might as well make libgmp-dev non-virtual at the same time. Let me know if this raises any concerns. Thanks, -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
Hi Julien, First, thanks for looking into the GMP issue. On Fri, Mar 18, 2011 at 03:30:45PM +0100, Julien Cristau wrote: As far as I can tell, the incompatibilities introduced in gmp 5 are the removal of mpn_bdivmod and mpn_neg_n, and the rest of the functions should stay compatible between gmp 4 and gmp 5. I think that if you mention mpn_neg_n, you need to make your list longer. There was never documentation for mpn_neg_n, just like for dozens of other internal functions that were removed. I was going by the gmp.h changes. The declarations removed from that file appear to be for just these two, not dozens of others. I think those using internal functions are on their own. Even better then. My concern was to make reasonably sure we could have libgmp.so.3 and libgmp.so.10 coexist for a while in the Debian archive, and that the risk of crashes due to both versions being loaded in the same address space would not be too high. Removed functions aren't a problem for this. So, given that the incompatibility between GMP 4 and 5 is removing a couple of public functions, you believe it is safe to have the shared libs coexist in the archive? That's fine. Can you help me work out the specific steps I should take now? In your previous message, you suggest to re-introduce gmp 4.3.2 as a separate source package (e.g. gmp4), building *only* the libgmp3c2 binary package. Raphael Geissert has requested also to change gmp to build libgmp-dev as a real package. I would also make it provide libgmp10-dev because that package name was used in experimental and a few packages are now using it. In addition, I made the new -dev package also provide libgmp3-dev because of the strange situation of the Haskell compiler ghc [1]. My intention was for that to be temporary and remove it once ghc got bootstrapped everywhere. In another of your messages you say Again, the -dev package needs to keep providing libgmp3-dev anyway, so changing the build-deps is unnecessary churn. What did you mean by this? Do you mean that the new -dev package needs to continue providing libgmp3-dev forever? Or did you mean that since it is presently providing it, there is no need to change all the build-deps at once; just let things alone until such time that we remove this provides? Assuming you meant the latter, here is my understanding of the next steps: 1. Upload gmp4, as described above. 2. Upload gmp introducing libgmp-dev as the real package, providing virtual packages libgmp3-dev and libgmp10-dev. Is this accurate? Anything else? Thanks, -Steve [1] http://lists.debian.org/debian-haskell/2011/03/msg00013.html signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
On Fri, Mar 18, 2011 at 10:24:15AM +0100, Julien Cristau wrote: On Thu, Mar 17, 2011 at 21:17:47 -0500, Steve M. Robbins wrote: I'm working my way through the dependent packages shown at http://release.debian.org/transitions/gmp5.html uploading new versions with the build-dep changed. Most of them shouldn't need any build-dep changes since they're not versioned. So no NMUs necessary for those. The -dev package has changed from libgmp3-dev to libgmp10-dev, which also provides libgmp-dev. (Raphael Geissert has requested that I flip this around and have libgmp-dev be the real package, which seems like a reasonable request.) So I'm changing the build-deps to libgmp-dev. Regards, -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
Dear GMP Developers, Is the following characterization of the changes between 4.3.2 and 5.0.1 accurate? On Fri, Mar 18, 2011 at 03:30:45PM +0100, Julien Cristau wrote: As far as I can tell, the incompatibilities introduced in gmp 5 are the removal of mpn_bdivmod and mpn_neg_n, and the rest of the functions should stay compatible between gmp 4 and gmp 5. Thanks, -Steve signature.asc Description: Digital signature
Re: [php-maint] Updates to gmp dependent packages
On Thu, Mar 17, 2011 at 08:56:10PM -0600, Raphael Geissert wrote: Why don't you actually ship the libgmp-dev package instead of using a virtual package? I have no issue with doing that. -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
Hi Julien, On Thu, Mar 17, 2011 at 07:42:13PM +0100, Julien Cristau wrote: So this is going pretty badly. gmp has a *lot* of reverse dependencies. [ ... ] I'm not sure what to do at this point. I'm working my way through the dependent packages shown at http://release.debian.org/transitions/gmp5.html uploading new versions with the build-dep changed. If there's a better way to accomplish this, I'm eager to learn it. Regards, -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
Hi, I checked with the GMP experts [1] and found no reason to expect insurmountable problems so I'm preparing the GMP upload now. [1] http://gmplib.org/list-archives/gmp-discuss/2011-February/004526.html Cheers, -Steve signature.asc Description: Digital signature
Please process Boost 1.46
Hi, The newly-released Boost is in the NEW queue. It'd be good to have it accepted into SID quickly, so that I can update the boost-defaults and get 1.42 out of the archive. See http://ftp-master.debian.org/new/boost1.46_1.46.0-1.html Thanks, -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
On Sat, Feb 26, 2011 at 05:49:49PM +0100, Matthias Klose wrote: On 26.02.2011 04:42, Steve M. Robbins wrote: On Fri, Feb 25, 2011 at 03:57:28PM +0100, Matthias Klose wrote: On 25.02.2011 08:46, Steve M. Robbins wrote: Clearly one should be mindful of the effect on GCC -- that's why I asked the question on debian-gcc. Do you have any specific concerns? Have any concerns been raised on the GCC mailing list? I've googled and found only anecdotal positive reports: http://www.listware.net/201003/gcc-gcc/99756-gmp-501-and-gcc-45.html Is there a GCC autobuilder suite that can do all these rebuilds? I will upload there. I don't have such a setup. OK, but someone must have a similar setup. People are occasionally rebuilding the archive to test new GCC versions. Anyone on the debian-gcc list got an idea? does gcc still work when gmp5 is in the archive, and mpfr is not yet rebuilt against the new gmp5? Sure: I've been running that way at home for a year. Why wouldn't it work? Instead of asking cryptic questions, could you please spell out your concerns in detail so that we could address them. Thanks, -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
Hi Adam, On Thu, Feb 24, 2011 at 08:15:44PM +, Adam D. Barratt wrote: On Sat, 2011-02-19 at 04:48 -0600, Steve M. Robbins wrote: On Sat, Feb 12, 2011 at 01:39:39PM +, Adam D. Barratt wrote: Have any of the reverse-dependencies been test-built against the new version? Does the move to 5.0.1 imply any source changes being required for reverse-dependencies, or just rebuilds? (I say just as there appear to be around 350 r-dependencies, including at least five from the GCC suite). I haven't done any test-builds. Since the -dev package changed name, I presume that just rebuild won't work; rather, the sources have to edit their build-deps. Out of interest, why is the -dev package versioned? Thinking about this more, I can't think of any reason for it to be versioned. Especially since two GMP versions cannot coexist in the archive. So I think I'll upload with simply libgmp-dev. Are you ready for the new upload? Thanks, -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
Dear Matthias, On Sat, Feb 26, 2011 at 06:10:54PM +0100, Matthias Klose wrote: On 26.02.2011 18:08, Steve M. Robbins wrote: Instead of asking cryptic questions, could you please spell out your concerns in detail so that we could address them. what is cryptic about the question? Thanks for your input. However, I don't find this conversation productive any longer. Thanks, -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
On Fri, Feb 25, 2011 at 03:57:28PM +0100, Matthias Klose wrote: On 25.02.2011 08:46, Steve M. Robbins wrote: Clearly one should be mindful of the effect on GCC -- that's why I asked the question on debian-gcc. Do you have any specific concerns? Have any concerns been raised on the GCC mailing list? I've googled and found only anecdotal positive reports: http://www.listware.net/201003/gcc-gcc/99756-gmp-501-and-gcc-45.html Is there a GCC autobuilder suite that can do all these rebuilds? I will upload there. I don't have such a setup. OK, but someone must have a similar setup. People are occasionally rebuilding the archive to test new GCC versions. Anyone on the debian-gcc list got an idea? -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
On Thu, Feb 24, 2011 at 08:15:44PM +, Adam D. Barratt wrote: On Sat, 2011-02-19 at 04:48 -0600, Steve M. Robbins wrote: On Sat, Feb 12, 2011 at 01:39:39PM +, Adam D. Barratt wrote: Have any of the reverse-dependencies been test-built against the new version? Does the move to 5.0.1 imply any source changes being required for reverse-dependencies, or just rebuilds? (I say just as there appear to be around 350 r-dependencies, including at least five from the GCC suite). I haven't done any test-builds. Since the -dev package changed name, I presume that just rebuild won't work; rather, the sources have to edit their build-deps. Out of interest, why is the -dev package versioned? I don't recall. I believe it has been versioned since before I took over maintenance. Shall I go ahead and upload the source gmp5? Then both gmp versions will co-exist in the repository and packages can choose to move to gmp5 at their leisure. After some further investigation, it looks like this isn't feasible. Neither gmp 4.3.2 nor 5.0.1 version their symbols and with both versions in the archive simultaneously and co-installable, there's a reasonable risk of a process ending up with both libraries loaded in to its address space, which is generally not a good idea. OK. So with the recent change for ia64, the experimental build shows no failures though 3 arches haven't been built (alpha, hppa, mips). You previously said hppa doesn't have an autobuilder for experimental. I believe the other two did build the previous version, but I can no longer find the buildd page that shows all the build log history so I can't verify that. Matthias asks: did you check, that all gcc versions do build with the new version on all architectures, and that the gcc testsuite doesn't show regressions with the new version? will gcc continue to work, while re-building mpfr and mpclib with the new gmp? What I have done is upload gmp to the experimental autobuilders. The GMP package build runs a comprehensive test suite that is passing on all the architectures available to the experimental autobuilders. This gives me some comfort that the code is reasonably sound. In addition, the fact that GMP 5 has been out for over a year gives me some reason to believe that upstream sources have been adapted to change in API. Clearly one should be mindful of the effect on GCC -- that's why I asked the question on debian-gcc. Do you have any specific concerns? Is there a GCC autobuilder suite that can do all these rebuilds? I will upload there. However, to ask me to manually try all combinations of architecture and GCC version is setting the bar too high, IMHO. So: what is the next step? Thanks, -Steve signature.asc Description: Digital signature
Re: GMP transition: 4.3.2 to 5.0.1?
On Sat, Feb 12, 2011 at 01:39:39PM +, Adam D. Barratt wrote:
On Sun, 2011-02-06 at 12:39 -0600, Steve M. Robbins wrote:
Looking at the package names of the unstable and experimental versions,
it looks like the main change is libgmp3c2 to libgmp3? (There is also
lib{32,64}gmp3 - lib{32,64}gmp10, but those libraries appear to only be
used by gmp itself).
All the binary packages changed name:
libgmp3c2 -- libgmp10
libgmp3-dev -- libgmp10-dev
lib32gmp3 -- lib32gmp10
lib64gmp3 -- lib64gmp10
... etc ...
except the C++ bindings libgmpxx4ldbl (and its 32-bit 64-bit
variants).
In addition, I had to introduce libmp3, lib{32,64}mp3 because the mp
libraries SOVERSION remained at 3. However, upstream subsequently
indicated these are fairly archaic [1] so I might just remove this
before uploading to unstable.
[1] http://gmplib.org/list-archives/gmp-devel/2010-November/001669.html
Have any of the reverse-dependencies been test-built against the new
version? Does the move to 5.0.1 imply any source changes being required
for reverse-dependencies, or just rebuilds? (I say just as there
appear to be around 350 r-dependencies, including at least five from the
GCC suite).
I haven't done any test-builds. Since the -dev package changed name,
I presume that just rebuild won't work; rather, the sources have
to edit their build-deps.
Main question: should I go ahead and upload the new version when
I get a free moment or do we need more investigation?
At the very least I'd first like to confirm that the suggested change
for ia64 works (rebuilding on the other architectures wouldn't hurt
either)
I have uploaded gmp 5.0.1+dfsg-4 with ia64 compiling using -O2 and it
built, so this is confirmed.
and better understand the scope of the changes, particularly in
relation to e.g. gcc.
Matthias also responded requesting:
I see that both the runtime library and the -dev packages have
different package names. But to be able to still use gmp3 for
existing GCC versions, please change the source name too, such
that gmp3 is still available in unstable after the upload of gmp5.
Shall I go ahead and upload the source gmp5? Then both gmp versions
will co-exist in the repository and packages can choose to move to
gmp5 at their leisure.
The -dev packages necessarily conflict. In addition, the C++ bindings
package libgmpxx4ldbl did not change SOVERSION so any package that
depends on libgmpxx4ldbl alone without depending on libgmp3 or
libgmp10 could possibly be compiled against libgmp3 and run with
libgmp10, or vice-versa. I'm not sure if that's a real problem or
not, but it seems potentially dangerous. What would you suggest?
Thanks,
-Steve
signature.asc
Description: Digital signature
GMP transition: 4.3.2 to 5.0.1?
Hi, Now that squeeze is out, I'd like to move from GMP 4 to GMP 5. The latter was released upstream about a year ago and the gmp lists aren't buzzing with outrageous bugs, so it appears stable enough. I know GMP is used in gcc itself, so I'd appreciate some guidance from the gcc team as well, since this is a major version change. I uploaded GMP 5 to experimental last year and it builds fine with two exceptions: hppa is BD-Uninstallable (?) and ia64 fails to build with an ICE. The underlying cause is already known [1] and from reading the bug report I suspect I may be able to work around this by building one file with -O2 rather than -O3. Other suggestions welcome. Main question: should I go ahead and upload the new version when I get a free moment or do we need more investigation? [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 Thanks, -Steve signature.asc Description: Digital signature
Bug#608629: unblock: denyhosts/2.6-8.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package denyhosts Fixes bug #607207 that prevents denyhosts being upgraded. unblock denyhosts/2.6-8.1 -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20110102094109.26326.96414.report...@localhost
Bug#608629: unblock: denyhosts/2.6-8.1
Hi Julien, On Sun, Jan 02, 2011 at 02:00:49PM +0100, Julien Cristau wrote: On Sun, Jan 2, 2011 at 03:41:09 -0600, Steve M. Robbins wrote: unblock denyhosts/2.6-8.1 I'm not convinced the changes in 2.6-8 are appropriate, and 607207 is only in that version (not in testing). OK, makes sense. I didn't realize that the bug was not in testing. Cheers, -Steve signature.asc Description: Digital signature
can remove youtube-dl from squeeze
... according to maintainer: #608176 -Steve signature.asc Description: Digital signature
Suggest to remove visualboyadvance from squeeze
... due to #607598 -S signature.asc Description: Digital signature
Bug#606911: unblock: mgltools-utpackages/1.5.4.cvs.20100912-1.1
On Sat, Dec 18, 2010 at 07:53:06PM +0100, Julien Cristau wrote: On Mon, Dec 13, 2010 at 18:41:55 +, Adam D. Barratt wrote: On Sun, 2010-12-12 at 16:45 -0600, Steve M. Robbins wrote: Please unblock package mgltools-utpackages Fixed RC bug #592417. Thanks for applying Tim's patch. The source debdiff ends up with a diffstat of 56 files changed, 36261 insertions(+), 17 deletions(-) due to the appearance of a bunch of files in UT*DIST directories, which appear to be SWIG-generated; those should probably be tidied up in the clean target. Ping? I'm not planning on doing any more work on mgltools-utpackages. In addition, the maintainer emailed to Bug #592417 that he prefers to simply remove the package from squeeze: thank you all for caring for the mgltools, but I think this is all too late and too uncertain for us to proceed for squeeze. I already got this confirmed by the release managers. We should now bet on backports and I'll have autodocktools and mgltools-* removed from squeeze. This shall a) help us by having only the latest versions of the mgltools with Debian b) prevent us from shipping something that most certainly has more issues, still, than the ones now corrected for. Steffen can fill you in. Cheers, -Steve signature.asc Description: Digital signature
Bug#606911: unblock: mgltools-utpackages/1.5.4.cvs.20100912-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package mgltools-utpackages Fixed RC bug #592417. unblock mgltools-utpackages/1.5.4.cvs.20100912-1.1 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20101212224510.6567.84372.report...@localhost
Bug#606258: unblock: distcc/3.1-3.2
Hi,
On Wed, Dec 08, 2010 at 07:32:01PM +0100, Moritz Muehlenhoff wrote:
On Tue, Dec 07, 2010 at 10:35:06PM +, Adam D. Barratt wrote:
Looking at the diff, either the original code is more broken than the
general case, or it's intentionally adding an empty entry to PYTHONPATH.
It seems an odd choice, but part of me does wonder if it was
intentional.
- PYTHONPATH='$pythonpath::$PYTHONPATH' \
+ PYTHONPATH='$pythonpath${PYTHONPATH:+:$PYTHONPATH}' \
Adding the NMUer and the maintainer to CC.
I did the NMU. I simply assumed the original code is in error: I
can't imagine why the script would want the current dir in the
PYTHONPATH.
Regards,
-Steve
signature.asc
Description: Digital signature
Re: Oops: I broke the lenny -- squeeze update
Hello Matthias, On Tue, Nov 23, 2010 at 08:01:52PM +0100, Matthias Klose wrote: On 23.11.2010 19:18, Philipp Kern wrote: On Mon, Nov 22, 2010 at 10:27:48PM -0600, Steve M. Robbins wrote: Alternatively, Jakub Wilk suggested that Python maintainers can make python2.6-minimal break (or conflict, if breaking is not enough) the old libboost* packages. I think that would be more appropriate. which version should the conflict have? The buggy versions are as follows: libboost-python-dev ( 1.34.1-16) libboost-dbg ( 1.34.1-16) libboost-python1.35-dev ( 1.35.0-10) libboost1.35-dbg ( 1.35.0-10) Thanks, -Steve signature.asc Description: Digital signature
Re: Oops: I broke the lenny -- squeeze update
Dear Release Team, Python Maintainers, I just received notice (bug 603579) that upgrade lenny to squeeze will break if a boost package containing an rtupdate script is installed. In stable there are four such packages: libboost-python-dev libboost-dbg libboost-python1.35-dev libboost1.35-dbg The issue is that the rtupdate script in stable only recognizes python 2.4 and python 2.5, and dies if any other version is supplied. Squeeze python default is 2.6 and so this blocks the upgrade of python, which is very bad. The rtupdate script has since been changed to avoid this problem. Unfortunately, the simple fix never made it into stable. Index: debian/rtupdate === --- debian/rtupdate (revision 14385) +++ debian/rtupdate (revision 14386) @@ -42,7 +42,7 @@ case $1 in python2.4) py=py24 ;; python2.5) py=py25 ;; - *) die $0 unknown python version $1 ;; + *) remove; return ;; esac update_linklibs $py a On debian-devel [1], I received advice from Raphael Hertzog to upload the fix to stable on the theory that users will upgrade to the latest stable prior to upgrading to lenny. Alternatively, Jakub Wilk suggested that Python maintainers can make python2.6-minimal break (or conflict, if breaking is not enough) the old libboost* packages. Which option do you suggest? Thanks, -Steve [1] http://lists.debian.org/debian-devel/2010/11/msg00455.html signature.asc Description: Digital signature
Re: libsoqt3-20 is linked against Qt 4 (should be Qt 3)
Dear Release Team, Please unblock soqt to fix bug #593798 as described below. The change is only in debian files (control and rules). On Sat, Aug 21, 2010 at 04:43:40PM +0100, Adam D. Barratt wrote: On Sat, 2010-08-21 at 09:36 -0500, Steve M. Robbins wrote: libsoqt3 should be linked against Qt 3 but actually it is linked against Qt 4 (apart from the suffix, there is no difference between libsoqt3 and libsoqt4). I can see a few options: 1. Fix present source package to build libsoqt3-20 properly. That may take me a couple of weeks to get to. 2. Use present source package, removing libsoqt3-20 and libsoqt3-dev. This option takes a couple of days. 3. Package new upstream (1.5.0 released March 2010) that provides improved support for Qt4. This will take me a couple of weeks. Given that nothing in the archive uses the Qt3 libraries, either of #1 or #2 should be ok. Hopefully a fix could be found more quickly though. :) I tried option #1, but the code doesn't actually build with Qt3 anymore, so I went with option #2. Thanks, -Steve signature.asc Description: Digital signature
Re: Bug#593798: libsoqt3-20 is linked against Qt 4 (should be Qt 3)
On Sun, Aug 22, 2010 at 05:18:09PM +0100, David Claughton wrote: FWIW, I could be wrong, but it looks like configure is invoking pkgconfig to determine the QT version and it's always finding QT4 regardless of what QTDIR is set to. Maybe --enable-pkgconfig wasn't the default in the previous release? In any case adding --disable-pkgconfig *seems* to do the trick, although I didn't have time to test it thoroughly. Good idea, thanks. However, when I tried it, the build eventually failed with the following error. It seems that Qt3 doesn't have QImage::hasAlphaChannel(), etc: g++ -DHAVE_CONFIG_H -I../../../src -I../../../data -I../../../../src -I/usr/include/Inventor/annex -D_REENTRANT -I/usr/share/qt3/include -DSOQT_DEBUG=1 -DSOQT_INTERNAL -g -O2 -W -Wall -Wno-unused -Wno-multichar -Woverloaded-virtual -Wno-non-virtual-dtor -fno-builtin -finline-functions -Wreturn-type -Wchar-subscripts -Wparentheses -c ../../../../src/Inventor/Qt/SoQtImageReader.cpp -fPIC -DPIC -o .libs/SoQtImageReader.o In file included from ../../../../src/Inventor/Qt/SoQtImageReader.cpp:31: /usr/share/qt3/include/qimage.h: In member function 'bool QImageTextKeyLang::operator(const QImageTextKeyLang) const': /usr/share/qt3/include/qimage.h:61: warning: suggest parentheses around '' within '||' ../../../../src/Inventor/Qt/SoQtImageReader.cpp: In member function 'SbBool SoQtImageReader::readImage(const SbString, SbImage*) const': ../../../../src/Inventor/Qt/SoQtImageReader.cpp:65: error: 'class QImage' has no member named 'hasAlphaChannel' ../../../../src/Inventor/Qt/SoQtImageReader.cpp:66: error: 'class QImage' has no member named 'convertToFormat' ../../../../src/Inventor/Qt/SoQtImageReader.cpp:66: error: 'class QImage' has no member named 'hasAlphaChannel' ../../../../src/Inventor/Qt/SoQtImageReader.cpp:67: error: 'Format_ARGB32' is not a member of 'QImage' ../../../../src/Inventor/Qt/SoQtImageReader.cpp:67: error: 'Format_RGB32' is not a member of 'QImage' I think I'll just remove the Qt3 packages after all. -Steve signature.asc Description: Digital signature
Re: libsoqt3-20 is linked against Qt 4 (should be Qt 3)
On Sat, Aug 21, 2010 at 02:52:48AM +0200, Gerhard Dirschl wrote: Package: libsoqt3-20 Version: 1.4.2~svn20090224-2 libsoqt3 should be linked against Qt 3 but actually it is linked against Qt 4 (apart from the suffix, there is no difference between libsoqt3 and libsoqt4). Wow. This was broken perhaps as long ago as March 2009 and no-one noticed until now. Must not be an important package :-) Dear Debian-Release: SoQt is a library that provides Qt widgets for a visualization library (Coin). When I first packaged it, Qt was version 3. In early days of Qt4, it seemed important to provide SoQt for both Qt3 and Qt4. So I modified the soqt source package to produce both libsoqt3-20 (Qt3 version) and libsoqt4-20 (Qt4 version). This worked in the Lenny version. In March 2009, I updated the soqt sources and apparently broke this so that libsoqt3-20 also links against Qt4. :-) Since I'm not quite sure of the freeze timelines, I'd like your advice. First, it's clear that libsoqt3-20 (and libsoqt3-dev) shouldn't be released as-is. Is it possible to remove those two binary packages from testing while keeping the others (e.g. libsoqt4-20)? If so, I'd suggest that can be done immediately. Regardless of the above, I can prepare a new upload. I can see a few options: 1. Fix present source package to build libsoqt3-20 properly. That may take me a couple of weeks to get to. 2. Use present source package, removing libsoqt3-20 and libsoqt3-dev. This option takes a couple of days. 3. Package new upstream (1.5.0 released March 2010) that provides improved support for Qt4. This will take me a couple of weeks. Option #3 is my preference. If I have to invest the time to figure out what went wrong with linking to Qt3 and fix it, I'd prefer to also update the source at the same time. Given that SoQt is a minor library, I'd consider it low risk for the archive. If the release team feels otherwise, I can work with the present sources. Please advise whether an upload in 2 weeks (option #1) will make it into the next release or whether I should instead choose option #2. Thanks, -Steve signature.asc Description: Digital signature
Bug#591092: nmu: igstk_4.2.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu igstk_4.2.0-3 . ALL . -m Rebuild against current insighttoolkit SOVERSION. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20100731203411.31648.71504.report...@localhost
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, 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
