Processed: Re: Bug#868484: transition: bullet

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #868484 [release.debian.org] transition: bullet
Added tag(s) confirmed.

-- 
868484: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868484
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#868484: transition: bullet

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 16/07/17 00:09, Markus Koschany wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I would like to request a transition slot for Bullet 2.86 which is
> already available in experimental.
> 
> The affected reverse-dependencies are:
> 
> kido
> hkl
> gazebo
> cyphesis-cpp
> openmw
> ros-geometry
> ros-geometry-experimental
> 
> Except for hkl (#868481), a test is failing now, all packages build fine with
> the new version.

Go ahead.

Emilio

Processed: Re: Bug#868540: transition: libprelude

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #868540 [release.debian.org] transition: libprelude
Added tag(s) confirmed.

-- 
868540: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868540
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#868540: transition: libprelude

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 16/07/17 15:46, Thomas Andrejak wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> New upstream version of libprelude (3.1.0) changes its soname from 2 to 23 for
> low level library (libprelude2 -> libprelude23) and form 0 to 2 for high level
> library (libpreludecpp0 to libpreludecpp8). Can you please create a new
> transition slot for this ?
> 
> Affected packages (test rebuild OK):
> * audit
> * libpreludedb
> * nufw
> * prelude-lml
> * suricata
> * prelude-manager
> * samhain

Go ahead.

Emilio

Bug#868646: nmu: gstreamer-vaapi_1.12.2-1

[Sebastian Dröge]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

gstreamer-vaapi depends on the exact upstream version of
libgstreamer-plugins-bad1.0-0 it was built against. Because this, a binNMU is
needed to update the generated dependencies to the latest version.

Thanks!

nmu gstreamer-vaapi_1.12.2-1 . ANY . unstable . -m "Rebuild against GStreamer 
1.12.2 to fix dependencies (Closes: #868429)"

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#868540: transition: libprelude

[Mattia Rizzolo]

On Mon, Jul 17, 2017 at 09:48:20AM +0200, Emilio Pozuelo Monfort wrote:
> Go ahead.

Uploaded and built everywhere where it matters.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#868646: marked as done (nmu: gstreamer-vaapi_1.12.2-1)

[Debian Bug Tracking System]

Your message dated Mon, 17 Jul 2017 16:53:23 +0300
with message-id <1500299603.1888.25.ca...@debian.org>
and subject line Re: nmu: gstreamer-vaapi_1.12.2-1
has caused the Debian Bug report #868646,
regarding nmu: gstreamer-vaapi_1.12.2-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.)


-- 
868646: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868646
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

gstreamer-vaapi depends on the exact upstream version of
libgstreamer-plugins-bad1.0-0 it was built against. Because this, a binNMU is
needed to update the generated dependencies to the latest version.

Thanks!

nmu gstreamer-vaapi_1.12.2-1 . ANY . unstable . -m "Rebuild against GStreamer 
1.12.2 to fix dependencies (Closes: #868429)"

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Closing this one, accidentially created two bugs

signature.asc
Description: This is a digitally signed message part
--- End Message ---

Bug#868684: stretch-pu: package haveged/1.9.1-5+deb9u1

[Jérémy Bobbio]

Package: release.debian.org
User: release.debian@packages.debian.org
Usetags: pu
Tags: stretch
Severity: normal

Hi!

I'd like to update the haveged package in stretch. The current version
has a bug which is proving to be affecting more computers than it
originally seemed. The issue (#858134) is a race that can lead to failed
or greatly delayed boots.

Attached is the diff between the package currently in stretch and the
proposed update.

Thanks!

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
diff -Nru haveged-1.9.1/debian/changelog haveged-1.9.1/debian/changelog
--- haveged-1.9.1/debian/changelog	2016-11-30 15:49:36.0 +0100
+++ haveged-1.9.1/debian/changelog	2017-07-17 18:31:46.0 +0200
@@ -1,3 +1,11 @@
+haveged (1.9.1-5+deb9u1) stable; urgency=medium
+
+  * Start haveged.service after systemd-tmpfiles-setup.service has been run.
+Many thanks to Jan Echternach for reporting the problem and suggesting
+a fix. (Closes: #858134)
+
+ -- Jérémy Bobbio   Mon, 17 Jul 2017 18:31:46 +0200
+
 haveged (1.9.1-5) unstable; urgency=medium
 
   * Fix URL in Homepage control field.
diff -Nru haveged-1.9.1/debian/gbp.conf haveged-1.9.1/debian/gbp.conf
--- haveged-1.9.1/debian/gbp.conf	2015-09-04 17:39:38.0 +0200
+++ haveged-1.9.1/debian/gbp.conf	2017-07-17 18:31:46.0 +0200
@@ -1,2 +1,2 @@
 [DEFAULT]
-debian-branch = master
+debian-branch = stretch
diff -Nru haveged-1.9.1/debian/haveged.service haveged-1.9.1/debian/haveged.service
--- haveged-1.9.1/debian/haveged.service	2016-11-30 12:22:40.0 +0100
+++ haveged-1.9.1/debian/haveged.service	2017-07-17 18:31:46.0 +0200
@@ -3,7 +3,7 @@
 Documentation=man:haveged(8) http://www.issihosts.com/haveged/
 DefaultDependencies=no
 ConditionVirtualization=!container
-After=apparmor.service systemd-random-seed.service
+After=apparmor.service systemd-random-seed.service systemd-tmpfiles-setup.service
 Before=sysinit.target shutdown.target
 
 [Service]


signature.asc
Description: Digital signature

Bug#868484: transition: bullet

[Markus Koschany]

Am 17.07.2017 um 09:46 schrieb Emilio Pozuelo Monfort:
> Control: tags -1 confirmed
[...]
> Go ahead.

Uploaded. Thank you.




signature.asc
Description: OpenPGP digital signature

Bug#867461: should ca-certificates certdata.txt synchronize across all suites?

[Antoine Beaupré]

On 2017-07-07 16:02:51, Guido Günther wrote:
> On Fri, Jul 07, 2017 at 03:57:35PM +0200, Philipp Kern wrote:
>> On 07/06/2017 08:01 PM, Antoine Beaupré wrote:
>> > In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
>> > wheezy, I noticed the issue was also pending in jessie. Furthermore, the
>> > idea originally raised by pabs[1] was to also update the packages for
>> > the latest changes in certdata.txt in wheezy, including the ISRG Root
>> > for Let's Encrypt (LE).
>> > 
>> > While it should be fairly trivial to do this update, I wonder if the
>> > same logic should apply to jessie itself. Right now, jessie and stretch
>> > are synchronized, but that's only because there's an update pending in
>> > unstable to synchronize with the upstream 2.11 NSS database.
>> > 
>> > This raises the question of how synchronized we want this file to be? It
>> > seems a little arbitrary to me to synchronize the file from jessie to
>> > wheezy only for this one certificate authority (LE). How about the other
>> > authorities? It doesn't seem like we should be calling the shots on
>> > this: if we follow the Mozilla policies here, either we update all
>> > supported suites at once, or we accept that some suites will have
>> > outdated material.
>> > 
>> > I have therefore opened this specific discussion with the release team
>> > in #867461 (in CC as well). Hopefully this will bring a consistent
>> > policy.
>> > 
>> > For what it's worth, my opinion is that we should attempt to synchronize
>> > certdata.txt (and blacklist.txt, for that matter) across all suites (but
>> > not other changes to the packaging). This would remove another decision
>> > point in our infrastructure and ensure harmonious X509 processing across
>> > suites.
>> > 
>> > [1]: https://lists.debian.org/1490430746.9127.2.ca...@debian.org
>> > 
>> > Thanks for any feedback. For now I'll hold on another week or so for the
>> > wheezy update, since it seems unreasonable to push that update out
>> > before jessie is updated and that question is resolved.
>> 
>> But it's not just about certdata.txt. The WoSign and StartCom distrust
>> was actually hardcoded in NSS and hence what Mozilla enforced in NSS we
>> couldn't check in any other tools using ca-certificates. We also do not
>> sync the NSS version or backport the cert checks when such distrusts
>> happen. So we can only react in a similar way when the time for full
>> distrust has come (which is sort of the case now with these two),
>> otherwise we diverge in logic and potentially break users with different
>> expectations[1].
>
> Which brings us back to #824872 (same nss/nspr in all suites). We're
> basically shipping new NSS with firefox / thunderbird but not for the
> rest.

Let's not jump the gun here. We're not shipping NSS in ca-certificates,
just a tiny part of it: one text file, more or less.

Also, what Mozilla enforced in NSS, we enforced in ca-certificates in
other ways, through the use of a blacklist.txt file. So we can
definitely fix #858539 without syncing all of NSS to wheezy.

The proposed patch here, is more or less only to merge that very file,
blacklist.txt. The *other* thing proposed to the release team (in
#867461) is to sync the *other* changes to certdata.txt from sid. But
considering *that* work seems mostly stalled, I wonder how hard to push
on that. Of course, we could also just decide, in LTS, to sync with
jessie at least: we do not need release-team approval for this. This
would be (let's be honest here) really to get Let's Encrypt directly in
wheezy, and I think it would be worthwhile.

Also I would very well see another NMU that would release those new
changes and sync up ca-certificates with NSS, at least in sid. Then it
could trickle down to buster, and from there, if everyone is okay,
trickle down to all suites. But that discussion concerns mostly the
release team and the maintainer at this point.

I'm not sure I want to bring back the question of syncing NSS across all
suites here again. It's a different question: NSS is a library, not
just a set of policies and certificates (which is, after all, what
ca-certificates is). Backporting it forcefully across all suites
may/will have an impact on programs that link against it, something that
we won't have with ca-certicates.

So while I would like NSS to be sync'd across suites as well, I'd like
to keep the questions separate here because ca-certificates is easier to
fix.

Thanks for your feedback, keep it coming.

A.

-- 
L'homme construit des maisons parce qu'il est vivant, mais il écrit des
livres parce qu'il se sait mortel.
- Daniel Pennac, Comme un roman

NEW changes in oldstable-new

[Debian FTP Masters]

Processing changes file: xorg-server_1.16.4-1+deb8u1+b1_amd64.changes
  ACCEPT

Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3

[Jochen Sprickerhof]

[adding Philipp and Anton as the respective maintainers]

* Emilio Pozuelo Monfort  [2017-07-15 09:40]:
> On 14/07/17 21:42, Jochen Sprickerhof wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > 
> > Hi,
> > 
> > please rebuild Ceres against the current Eigen3 version, as it encodes the
> > version in the CeresConfig.cmake and makes Google Cartographer to file in 
> > cmake
> > with:
> > 
> > CMake Error at /usr/lib/cmake/ceres/CeresConfig.cmake:88 (message):
> >   Failed to find Ceres - Found Eigen dependency, but the version of Eigen
> >   found (3.3.4) does not exactly match the version of Eigen Ceres was
> >   compiled with (3.3.2).  This can cause subtle bugs by triggering 
> > violations
> >   of the One Definition Rule.  See the Wikipedia article
> >   http://en.wikipedia.org/wiki/One_Definition_Rule for more details
> 
> Why do you need the same version at runtime than the one it was compiled with?
> Multiple definitions doesn't sound like a good reason to me, as eigen and 
> ceres
> shouldn't be defining things in the same namespace in the first place, thus
> conflicts should be impossible.
> 
> Sounds like a too strict check that should be removed.

I think it's an actual problem not only in Ceres:

http://eigen.tuxfamily.narkive.com/fweQWUaX/eigen-and-the-one-definition-rule

At the moment Ceres is not usable in Debian unstable, so as a simple
measure I would propose to do the binnmu.

I'm not sure about a long term solution. I've looked into the
Built-Using field [1]. But we would have to make sure that every package
using Eigen adds this field and I have found nothing about recompiling
every user automatically when a new Eigen version is uploaded.
I assume it would be better to trigger a rebuild of all dependencies
when Eigen is uploaded, but I'm not aware of an automatic mechanism in
Debian to do that. Any ideas?

Cheers Jochen

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using


signature.asc
Description: PGP signature

Bug#868722: transition: notmuch

[David Bremner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There is an upstream SONAME bump in libnotmuch due to some long
deprecated symbols changing API.

There are two reverse depends: mutt rebuilds fine.  notmuch-addrlookup
currently fails, but apparently this is fixed with the latest upstream
version.  I can NMU notmuch-addrlookup, but I'd rather the maintainer
uploaded a new pustream version.

Ben file:

title = "notmuch";
is_affected = .depends ~ "libnotmuch4" | .depends ~ "libnotmuch5";
is_good = .depends ~ "libnotmuch5";
is_bad = .depends ~ "libnotmuch4";


- -- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlltRqEACgkQ8gKXHaSn
niwmAgwAkB4WPQ92AbW74buG6OEtCCgzVZHz0L2m4e7A5vPHqhCW8fJvDGZcr0Iz
iti4Pzu3oQJlcrOQ5dBSR4OOqmXA6++NlYgHxMIRpAXB2fyK0duDjIb8VHipx3yi
ONN+lHBw/6aKlCPE8xzBsr9LLSinM1EGbf8UqZCXhJeZE0kqgTBOVfCR/YZ6qCax
8LLCTtzXgFH5MIkF4RyPWUKAo1H1re+e0zVnkCCDETVgJsC7GP1xz0XQTvofURmr
ggz91XR+FuCPuhzoCWn8SMwvAj9Vq9uQUrAJDXCutCLsTLgAklrJhPlyy0D6AHOt
TBwQ+xSfGD0ym07golCM/YBwSuvC5dvQ9jn4qkOZEKuJCIkeIQ7zXGZAum+aovBi
YAzaJsy2/yHwkZLABC+d8Rqtflevwp4rGaalkOiZo3rqpgso4D51rMGMxhiRZq1i
o8W0//K6cP+dM3n5qwgFZrg8ivcByyIx2a1XloSYNvRYBWE4df5Q18ZWqSyWTDVy
V2jMcWC7
=cvtH
-END PGP SIGNATURE-

Processed: block 868722 with 868664

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 868722 with 868664
Bug #868722 [release.debian.org] transition: notmuch
868722 was not blocked by any bugs.
868722 was not blocking any bugs.
Added blocking bug(s) of 868722: 868664
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
868722: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868722
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#868645: nmu: gstreamer-vaapi_1.12.2-1

[Sebastian Dröge]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

gstreamer-vaapi depends on the exact upstream version of
libgstreamer-plugins-bad1.0-0 it was built against. Because this, a binNMU is
needed to update the generated dependencies to the latest version.

Thanks!

nmu gstreamer-vaapi_1.12.2-1 . ANY . unstable . -m "Rebuild against GStreamer 
1.12.2 to fix dependencies (Closes: #868429)"

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)