Bug#791257: qscintilla2: library transition may be needed when GCC 5 is the default
On Sat, Aug 15, 2015 at 22:05:51 -0400, Scott Kitterman wrote: Please let me know when I can go ahead. Go ahead. Cheers, Julien signature.asc Description: Digital signature
Bug#790991: transition: cal3d (libcal3d12v5)
2015-08-16 0:43 GMT+01:00 Simon McVittie s...@debian.org: retitle 790991 transition: cal3d (libcal3d12v5) severity 790991 normal reassign 790991 release.debian.org user release.debian@packages.debian.org usertags 790991 + transition forwarded 790991 https://release.debian.org/transitions/html/auto-cal3d.html thanks On Fri, 14 Aug 2015 at 15:54:38 +0100, Manuel A. Fernandez Montecelo wrote: Uploaded changes to experimental. As Julien clarified in https://lists.debian.org/debian-release/2015/08/msg00426.html, I believe this is ready for upload to unstable whenever you want. There are only two reverse dependencies. crystalspace is not in testing and FTBFS anyway, so I think that one can be disregarded. soya has no other C++ build-dependencies, so it is probably ready to be queued up as soon as the updated cal3d gets to unstable: nmu soya_0.15~rc1-10 . ALL . -m 'Rebuild with libcal3d12v5' dw soya_0.15~rc1-10 . ALL . -m 'libcal3d12v5' Thanks, I am a bit behind on my reading of the mailing lists. Uploaded to unstable now. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
Bug#795673: nmu: google-glog_0.3.4-0.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu google-glog_0.3.4-0.1 . ALL . unstable . -m Previous upload was not built against proper libgflags-dev. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#791070: htmlcxx: library transition may be needed when GCC 5 is the default
On Sun, Aug 16, 2015 at 00:32:50 +0100, Simon McVittie wrote: retitle 791070 transition: htmlcxx (g++-5) forwarded 791070 https://release.debian.org/transitions/html/auto-htmlcxx.html thanks On Fri, 14 Aug 2015 at 22:34:49 +0200, Stephen Kitt wrote: Thanks for the info, I'll upload an NMU in the near future. This has reached unstable and built everywhere except mips. The build-dependencies of the only reverse dependency have all started their transitions. Release team, please consider: nmu lgogdownloader_2.24-1 . ALL . -m 'Rebuild with libhtmlcxx3v5' dw lgogdownloader_2.24-1 . mips . -m 'libhtmlcxx3v5' mips is built now; binNMU scheduled. Cheers, Julien signature.asc Description: Digital signature
Bug#791314: xqilla gcc 5 transition
On Sat, Aug 15, 2015 at 16:36:25 +0300, Tommi Vainikainen wrote: FYI, xqilla 2.3.0-3 with libxqilla6 renamed to libxqilla6v5 compiled with gcc 5 is now in sid. xqilla has two reverse dependencies related to transition as listed here https://release.debian.org/transitions/html/auto-xqilla.html Both of those are libraries, and both of them are RC-buggy. IMO they should either be removed or somebody should look after them (including checking if they break ABI with g++ 5). Cheers, Julien signature.asc Description: Digital signature
Bug#795673: marked as done (nmu: google-glog_0.3.4-0.1)
Your message dated Sun, 16 Aug 2015 12:08:18 +0200 with message-id 20150816100818.gx3...@betterave.cristau.org and subject line Re: Bug#795673: nmu: google-glog_0.3.4-0.1 has caused the Debian Bug report #795673, regarding nmu: google-glog_0.3.4-0.1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 795673: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795673 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu google-glog_0.3.4-0.1 . ALL . unstable . -m Previous upload was not built against proper libgflags-dev. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) ---End Message--- ---BeginMessage--- On Sun, Aug 16, 2015 at 01:51:44 -0700, David Martínez Moreno wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu google-glog_0.3.4-0.1 . ALL . unstable . -m Previous upload was not built against proper libgflags-dev. This is handled in #795543. Cheers, Julien signature.asc Description: Digital signature ---End Message---
Re: Bug#791141: libmusicbrainz3: library transition may be needed when GCC 5 is the default
On Sun, Aug 2, 2015 at 17:43:20 +0200, Sebastian Ramacher wrote: A transition is needed for libmusicbrainz3. I have uploaded an NMU to rename the libmusicbrainz3-6 to libmusicbrainz3-6v5 to experimental. Hi, any particular reason you're changing the library's SONAME instead of leaving it alone and adding Conflicts/Replaces on the old package, which seems to be the more usual pattern? Thanks, Julien signature.asc Description: Digital signature
Bug#791077: transition: libmagick++-6.q16-5v5
On Fri, 14 Aug 2015 at 19:02:54 +0200, Julien Cristau wrote: On Fri, Aug 14, 2015 at 15:58:30 +0100, Simon McVittie wrote: [imagemagick] has reached unstable, and built everywhere except mips. It has now built on mips too, and I think its rdeps are ready for binNMUs. S
Re: transition: libmusicbrainz3 (GCC 5)
On Sun, Aug 16, 2015 at 11:26:51 +0200, Julien Cristau wrote:
any particular reason you're changing the library's SONAME instead of
leaving it alone and adding Conflicts/Replaces on the old package, which
seems to be the more usual pattern?
Indeed, the standard practice here is to change the binary package name, but
not to change the library soname without upstream coordination because this
will make the Debian binary incompatible with any other third-party binaries
built against the new C++ ABI using upstream sources rather than the Debian
package.
If you want an soname change, this should be done via upstream, not via a
Debian patch to the upstream build system in an NMU.
I'm uploading a new NMU with the attached patch, which brings
libmusicbrainz3 in line with best practices for this transition.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -u libmusicbrainz3-3.0.2/debian/changelog
libmusicbrainz3-3.0.2/debian/changelog
--- libmusicbrainz3-3.0.2/debian/changelog
+++ libmusicbrainz3-3.0.2/debian/changelog
@@ -1,3 +1,12 @@
+libmusicbrainz3 (3.0.2-2.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Revert changes to upstream SONAME is previous NMU. The g++5 transition
+should not change upstream sonames without coordination.
+Closes: #791141.
+
+ -- Steve Langasek vor...@debian.org Sun, 16 Aug 2015 09:41:05 +
+
libmusicbrainz3 (3.0.2-2.4) unstable; urgency=medium
* Non-maintainer upload.
diff -u libmusicbrainz3-3.0.2/debian/control
libmusicbrainz3-3.0.2/debian/control
--- libmusicbrainz3-3.0.2/debian/control
+++ libmusicbrainz3-3.0.2/debian/control
@@ -9,6 +9,8 @@
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libmusicbrainz3-6
+Replaces: libmusicbrainz3-6
Description: library to access the MusicBrainz.org database
MusicBrainz is a community music metadatabase that attempts to create a
comprehensive music information site.
reverted:
--- libmusicbrainz3-3.0.2/debian/patches/gcc-5.patch
+++ libmusicbrainz3-3.0.2.orig/debian/patches/gcc-5.patch
@@ -1,18 +0,0 @@
-Description: Bump SONAME for GCC 5 transition
-Author: Sebastian Ramacher sramac...@debian.org
-Last-Update: 2015-08-02
-
libmusicbrainz3-3.0.2.orig/CMakeLists.txt
-+++ libmusicbrainz3-3.0.2/CMakeLists.txt
-@@ -15,8 +15,8 @@
- MATH(EXPR musicbrainz3_SOVERSION_MINOR ${musicbrainz3_SOVERSION_AGE})
- MATH(EXPR musicbrainz3_SOVERSION_PATCH ${musicbrainz3_SOVERSION_REVISION})
-
--SET(musicbrainz3_VERSION
${musicbrainz3_SOVERSION_MAJOR}.${musicbrainz3_SOVERSION_MINOR}.${musicbrainz3_SOVERSION_PATCH})
--SET(musicbrainz3_SOVERSION ${musicbrainz3_SOVERSION_MAJOR})
-+SET(musicbrainz3_VERSION
${musicbrainz3_SOVERSION_MAJOR}v5.${musicbrainz3_SOVERSION_MINOR}.${musicbrainz3_SOVERSION_PATCH})
-+SET(musicbrainz3_SOVERSION ${musicbrainz3_SOVERSION_MAJOR}v5)
-
- SET(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
- FIND_PACKAGE(Neon REQUIRED)
-
signature.asc
Description: Digital signature
Re: Bug#791141: libmusicbrainz3: library transition may be needed when GCC 5 is the default
On 2015-08-16 11:26:51, Julien Cristau wrote: On Sun, Aug 2, 2015 at 17:43:20 +0200, Sebastian Ramacher wrote: A transition is needed for libmusicbrainz3. I have uploaded an NMU to rename the libmusicbrainz3-6 to libmusicbrainz3-6v5 to experimental. Hi, any particular reason you're changing the library's SONAME instead of leaving it alone and adding Conflicts/Replaces on the old package, which seems to be the more usual pattern? Changing the SONAME makes it possible to keep third party apps built against the current stretch (or the jessie) version libmusicbrainz3 working even after an upgrade of libstdc++ to something = 5.2. They do not simple fail to start because symbols from /usr/lib/libmusicbrainz3.so.6 disappeared. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#791141: marked as done (transition: libmusicbrainz3 (GCC 5))
Your message dated Sun, 16 Aug 2015 10:20:27 + with message-id e1zqv3d-0007mu...@franck.debian.org and subject line Bug#791141: fixed in libmusicbrainz3 3.0.2-2.5 has caused the Debian Bug report #791141, regarding transition: libmusicbrainz3 (GCC 5) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 791141: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791141 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: src:libmusicbrainz3 Version: 3.0.2-2.2 Severity: important Tags: sid stretch User: debian-...@lists.debian.org Usertags: libstdc++-cxx11 Background [1]: libstdc++6 introduces a new ABI to conform to the C++11 standard, but keeps the old ABI to not break existing binaries. Packages which are built with g++-5 from experimental (not the one from testing/unstable) are using the new ABI. Libraries built from this source package export some of the new __cxx11 or B5cxx11 symbols, and dropping other symbols. If these symbols are part of the API of the library, then this rebuild with g++-5 will trigger a transition for the library. What is needed: - Rebuild the library using g++/g++-5 from experimental. Note that most likely all C++ libraries within the build dependencies need a rebuild too. You can find the log for a rebuild in https://people.debian.org/~doko/logs/gcc5-20150701/ Search for BEGIN GCC CXX11 in the log. - Decide if the symbols matching __cxx11 or B5cxx11 are part of the library API, and are used by the reverse dependencies of the library. - If there are no symbols matching __cxx11 or B5cxx11 in the symbols forming the library API, you should close this issue with a short explanation. - If there are no reverse dependencies, it should be the package maintainers decision if a transition is needed. However this might break software which is not in the Debian archive, and built against these packages. - If a library transition is needed, please prepare for the change. Rename the library package, append v5 to the name of the package (e.g. libfoo2 - libfoo2v5). Such a change can be avoided, if you have a soversion bump and you upload this version instead of the renamed package. Prepare a patch and attach it to this issue (mark this issue with patch), so that it is possible to NMU such a package. We'll probably have more than hundred transitions triggered. Then reassign the issue to release.debian.org and properly tag it as a transition issue, by sending an email to cont...@bugs.debian.org: user release.debian@packages.debian.org usertag this issue + transition block this issue by 790756 reassign this issue release.debian.org - If unsure if a transition is needed, please tag the issue with help to ask for feedback from other Debian developers. The libstdc++6 transition will be a large one, and it will come with a lot of pain. Please help it by preparing the follow-up transitions. [1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition ---End Message--- ---BeginMessage--- Source: libmusicbrainz3 Source-Version: 3.0.2-2.5 We believe that the bug you reported is fixed in the latest version of libmusicbrainz3, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 791...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Steve Langasek vor...@debian.org (supplier of updated libmusicbrainz3 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 16 Aug 2015 09:41:05 + Source: libmusicbrainz3 Binary: libmusicbrainz3-6v5 libmusicbrainz3-dev Architecture: source amd64 Version: 3.0.2-2.5 Distribution: unstable Urgency: medium Maintainer: Ross Burton r...@debian.org Changed-By: Steve Langasek vor...@debian.org Description: libmusicbrainz3-6v5 - library to access the MusicBrainz.org database libmusicbrainz3-dev - library to access the MusicBrainz.org database (development files Closes: 791141 Changes: libmusicbrainz3 (3.0.2-2.5) unstable; urgency=medium . * Non-maintainer upload. * Revert changes to upstream SONAME is previous NMU. The g++5 transition should
Bug#791077: transition: libmagick++-6.q16-5v5
On Sun, Aug 16, 2015 at 10:25:07 +0100, Simon McVittie wrote: On Fri, 14 Aug 2015 at 19:02:54 +0200, Julien Cristau wrote: On Fri, Aug 14, 2015 at 15:58:30 +0100, Simon McVittie wrote: [imagemagick] has reached unstable, and built everywhere except mips. It has now built on mips too, and I think its rdeps are ready for binNMUs. - inkscape given back - k3d looks like it needs a ftbfs bug? - converseen gem libtuxcap pfstools pstoedit pythonmagick synfig vdr-plugin-skinenigmang binNMUs scheduled Cheers, Julien signature.asc Description: Digital signature
Bug#795311: hhvm rdepends on google-glog.
Don't worry about hhvm for now. It's a huge codebase in C++ and there are several packages that are totally broken right now preventing a rebuild. It's though a leaf node and no one depends on it. Ender. signature.asc Description: OpenPGP digital signature
Bug#791257: qscintilla2: library transition may be needed when GCC 5 is the default
On Sunday, August 16, 2015 08:30:40 AM Julien Cristau wrote: On Sat, Aug 15, 2015 at 22:05:51 -0400, Scott Kitterman wrote: Please let me know when I can go ahead. Go ahead. Cheers, Julien Uploaded. Thanks, Scott K signature.asc Description: This is a digitally signed message part.
Bug#795543: nmu: google-glog and autofdo
On Sat, Aug 15, 2015 at 10:23:10 +0200, Matthias Klose wrote: please binNMU 0.3.4-0.1 on amd64, the upload had the old gflags installed. Scheduled. Cheers, Julien signature.asc Description: Digital signature
Processed: retitle 789133 to transition: ocaml 4.02.3
Processing commands for cont...@bugs.debian.org: retitle 789133 transition: ocaml 4.02.3 Bug #789133 [release.debian.org] transition: ocaml 4.02.2 Changed Bug title to 'transition: ocaml 4.02.3' from 'transition: ocaml 4.02.2' thanks Stopping processing here. Please contact me if you need assistance. -- 789133: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789133 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Depend on a package from an other arch
+++ Bertrand Marc [2015-08-13 09:42 +0200]: Dear developpers, I am trying to fix Debian bug #783875 [1]: playonlinux (which is arch independant) should depend on the 32 bits version of wine. Therefore I added a dependency on wine32|wine32-development, but it seems the package will not migrate to testing [2], because wine32 is not available on amd64. So playonlinux should depend on wine32 for arches where it exists (which is i386, kfreebsd-i386, and powerpc)? But on 64-bit arches it should depend on wine32:some foreign arch? should playonlinux on ppc64el depend on wine32:powerpc? (It's not currently built on ppc64el, and maybe it makes no sense there, I just note that wine32 is built on powerpc so this isn't just an x86 thing?) Niels Thykier suggested on mentors that this could be an issue with the testing migration code [3], so I send this question to debian-release@ too. I thought I should instead add a dependency on wine32:any | wine32-development:any and ask the wine maintainer to move to multiarch:allowed. That seems plausible, but I'm not quite sure what the actual restrictions you want are. If you are at debconf you might want to drop in to the marathon multiarch BoF where this could be clarified. If not, lets work it out here. But the best source on this subject is an Ubuntu one [4]. I cannot find any reliable Debian source about this The Multiarch spec https://wiki.ubuntu.com/MultiarchSpec was written up on the ubuntu wiki because the initial implementation was done there, but it absolutely should be considered a Debian spec as well as an Ubuntu one. It should have been converted into policy some time ago, but it's actually quite hard to re-write in that form, and as you will see from the list of issues for the multiarch BoF at debconf, there actually remain quite a few corner-cases that need to be resolved before a definitive spec can be produced. Hopefully that will be finalised this week and it will finally make it into policy. and it seems I was wrong [3]. Could you give me a pointer on this ? Or do you know any package with a dependency on a package from an other arch ? The only other packages in the archive with dependencies on other (explicit) arches are multiarch-built (wdotap) cross-compilers (https://wiki.debian.org/MultiarchCrossToolchainBuild). So far as I know wine and cross-compilers are the only two areas where explicit cross-arch dependencies are appropriate, but there may be a couple of others. e.g: gcc-4.9-arm-linux-gnueabihf in unstable depends on libgcc-4.9-dev:armhf Such packages cannot currently migrate into testing as britney does not check foreign arches for dependencies. Such dependencies have been dealt with in the past (e.g for ia32-libs) by declaring fake dependencies in britney to packages wanting them them to migrate. This is very hacky. We propose to do this properly now by correctly checking the dependencies against foreign arches, and allowing migration for packages on a whitelist, with dependencies on whitelisted arches. This allows the release team to ensure this functionality is only used when appropriate. But in your case I'm not sure that you need any of this. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
Processed: user deb...@kitterman.com
Processing commands for cont...@bugs.debian.org: user release.debian@packages.debian.org Setting user to release.debian@packages.debian.org (was sc...@kitterman.com). usertag 791286 + transition There were no usertags set. Usertags are now: transition. block 791286 by 790756 Bug #791286 [src:smokegen] smokegen: library transition may be needed when GCC 5 is the default 791286 was not blocked by any bugs. 791286 was not blocking any bugs. Added blocking bug(s) of 791286: 790756 reassign 791286 release.debian.org Bug #791286 [src:smokegen] smokegen: library transition may be needed when GCC 5 is the default Bug reassigned from package 'src:smokegen' to 'release.debian.org'. No longer marked as found in versions smokegen/4.14.2-1. Ignoring request to alter fixed versions of bug #791286 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- 791286: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791286 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#795311: google-glog/0.3.4-0.1 Hurd build issue
László Böszörményi (GCS), le Sun 16 Aug 2015 21:58:56 +0200, a écrit : Build killed with signal TERM after 180 minutes of inactivity Often that means that a test got stuck, and I had to kill it by hand (because for some reason the current sudo version doesn't kill the whole group ATM). It happens that the build then apparently actually ignored the auto_test error. I have given it back, let's see what happens. Samuel
Bug#795311: google-glog/0.3.4-0.1 Hurd build issue
Samuel Thibault, le Sun 16 Aug 2015 22:46:14 +0200, a écrit : László Böszörményi (GCS), le Sun 16 Aug 2015 21:58:56 +0200, a écrit : Build killed with signal TERM after 180 minutes of inactivity Often that means that a test got stuck, and I had to kill it by hand (because for some reason the current sudo version doesn't kill the whole group ATM). It happens that the build then apparently actually ignored the auto_test error. I have given it back, let's see what happens. This time it went just fine. Samuel
Bug#795311: google-glog/0.3.4-0.1 Hurd build issue
Hi, Please reschedule the build of google-glog on Hurd. The previous buildd attempt failed[1] for an unknown reason to me, but the binary packages are ready. As end of the log states: -- cut -- dpkg-deb: building package 'libgoogle-glog0v5' in '../libgoogle-glog0v5_0.3.4-0.1_hurd-i386.deb'. dpkg-genchanges: binary-only arch-specific upload (source code and arch-indep packages not included) dpkg-source --after-build google-glog-0.3.4 dpkg-buildpackage: binary-only upload (no source included) Build killed with signal TERM after 180 minutes of inactivity Build killed with signal KILL after 5 minutes of inactivity -- cut -- This is needed for the google-glog transition due to libstdc++ ABI changes. Thanks, Laszlo/GCS [1] https://buildd.debian.org/status/fetch.php?pkg=google-glogarch=hurd-i386ver=0.3.4-0.1stamp=1439425485
Bug#795794: jessie-pu: package nss/3.17.2-1.1+deb8u1
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi!
This is a small patch from mozilla hg. It fixes #774195 and is
confirmed to work. Would be cool if if can be included in the next
stable release.
Thanks!
Christoph
-- System Information:
Debian Release: 8.0
APT prefers stable-kfreebsd
APT policy: (990, 'stable-kfreebsd'), (500, 'buildd-unstable'), (500,
'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru nss-3.17.2/debian/changelog nss-3.17.2/debian/changelog
--- nss-3.17.2/debian/changelog 2014-12-22 04:46:52.0 +0100
+++ nss-3.17.2/debian/changelog 2015-08-15 12:40:34.0 +0200
@@ -1,3 +1,12 @@
+nss (2:3.17.2-1.1+deb8u1) jessie; urgency=medium
+
+ [ Andrew Ayer ]
+ * Apply upstream patch (99_prefer_stronger_cert_chains.patch) to fix
+certificate chain generation to prefer stronger/newer certificates
+over weaker/older certs. Closes: #774195.
+
+ -- Christoph Egger christ...@debian.org Sat, 15 Aug 2015 12:40:31 +0200
+
nss (2:3.17.2-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru nss-3.17.2/debian/patches/99_prefer_stronger_cert_chains.patch nss-3.17.2/debian/patches/99_prefer_stronger_cert_chains.patch
--- nss-3.17.2/debian/patches/99_prefer_stronger_cert_chains.patch 1970-01-01 01:00:00.0 +0100
+++ nss-3.17.2/debian/patches/99_prefer_stronger_cert_chains.patch 2015-05-25 18:34:09.0 +0200
@@ -0,0 +1,135 @@
+Description: Prefer stronger, newer certs when building chain.
+Origin: https://hg.mozilla.org/projects/nss/rev/34e1379ff6c7
+Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1112461
+
+# HG changeset patch
+# User Ryan Sleevi ryan.sle...@gmail.com
+# Date 1420768742 28800
+# Node ID 34e1379ff6c77f6c2dc52b542eafbe9c18034828
+# Parent 6978c29bd763e8e20c4e837ef4cdc7f7d6e802bc
+Bug 1112461 - Have libpkix match classic mozilla::pkix in preferring newer certs to older certs. r=wtc
+
+diff --git a/lib/libpkix/pkix/checker/pkix_revocationchecker.c b/lib/libpkix/pkix/checker/pkix_revocationchecker.c
+--- a/nss/lib/libpkix/pkix/checker/pkix_revocationchecker.c
b/nss/lib/libpkix/pkix/checker/pkix_revocationchecker.c
+@@ -132,32 +132,38 @@ pkix_RevocationChecker_RegisterSelf(void
+ entry.comparator = NULL;
+ entry.duplicateFunction = pkix_RevocationChecker_Duplicate;
+
+ systemClasses[PKIX_REVOCATIONCHECKER_TYPE] = entry;
+
+ PKIX_RETURN(REVOCATIONCHECKER);
+ }
+
+-/* Sort methods by theirs priorities */
++/* Sort methods by their priorities (lower priority = higher preference) */
+ static PKIX_Error *
+ pkix_RevocationChecker_SortComparator(
+ PKIX_PL_Object *obj1,
+ PKIX_PL_Object *obj2,
+ PKIX_Int32 *pResult,
+ void *plContext)
+ {
+ pkix_RevocationMethod *method1 = NULL, *method2 = NULL;
+
+ PKIX_ENTER(BUILD, pkix_RevocationChecker_SortComparator);
+
+ method1 = (pkix_RevocationMethod *)obj1;
+ method2 = (pkix_RevocationMethod *)obj2;
+
+-*pResult = (method1-priority method2-priority);
++if (method1-priority method2-priority) {
++ *pResult = -1;
++} else if (method1-priority method2-priority) {
++ *pResult = 1;
++} else {
++ *pResult = 0;
++}
+
+ PKIX_RETURN(BUILD);
+ }
+
+
+ /* --Public-Functions- */
+
+
+diff --git a/lib/libpkix/pkix/top/pkix_build.c b/lib/libpkix/pkix/top/pkix_build.c
+--- a/nss/lib/libpkix/pkix/top/pkix_build.c
b/nss/lib/libpkix/pkix/top/pkix_build.c
+@@ -655,19 +655,21 @@ pkix_ForwardBuilderState_IsIOPending(
+
+ /* --Private-BuildChain-Functions--- */
+
+ /*
+ * FUNCTION: pkix_Build_SortCertComparator
+ * DESCRIPTION:
+ *
+ * This Function takes two Certificates cast in obj1 and obj2,
+- * compares their validity NotAfter dates and returns the result at
+- * pResult. The comparison key(s) can be expanded by using other
+- * data in the Certificate in the future.
++ * compares them to determine which is a more preferable certificate
++ * for chain building. This Function is suitable for use as a
++ * comparator callback for pkix_List_BubbleSort, setting *pResult to
++ * 0 if obj1 is less desirable than obj2 and 0 if obj1
++ * is more desirable than obj2.
+ *
+ * PARAMETERS:
+ * obj1
+ * Address of the PKIX_PL_Object that is a cast of PKIX_PL_Cert.
+ * Must be non-NULL.
+ * obj2
+ * Address of the PKIX_PL_Object that is a cast of PKIX_PL_Cert.
+ * Must be non-NULL.
+@@ -686,24 +688,24 @@ static PKIX_Error *
+ pkix_Build_SortCertComparator(
+ PKIX_PL_Object *obj1,
+ PKIX_PL_Object *obj2,
+ PKIX_Int32 *pResult,
+ void
