Bug#870181: stretch-pu: package bareos/16.2.4-3+deb9u1

[Felix Geyer]

Control: tags -1 - moreinfo

On Mon, 31 Jul 2017 00:24:41 +0200 Felix Geyer  wrote:
> Uh, you are right of course. Not sure how I missed that. Thanks for checking!
> I've just upload 16.2.6-3 with those changes to unstable.
> 
> While looking further into it I noticed that the version check in
> bareos-director.postinst is wrong.
> Instead of 15.2.2-1~ it should be 16.2.4-3+deb9u1~

The fixed version is now in testing.

Felix

Bug#871448: lintian: throw an error for files-excluded being present in the orig.tar.gz

[Paul R. Tagliamonte]

Package: lintian
Severity: wishlist
thanks

After a quick chat on IRC, zhsj noted that the issue in #871448 is
present because the uploader didn't use uscan to download the
orig.tar.gz, which means that the Files-Excluded line was never used,
and Excluded files were present in the orig.tar.gz.

It'd be super snazzy if lintian were to throw an error if any of the
Files-Excluded globs hit a file in the orig.tar.gz, with a severity of
error. Hopefully this would have alerted the uploader, and caused them
to re-download the tarball.

Thanks for working on Lintian!
  Paul

-- 
:wq

Bug#871454: lintian: throw an error for files-excluded being present in the orig.tar.gz

[Paul R. Tagliamonte]

Package: lintian
Severity: wishlist
thanks

After a quick chat on IRC, zhsj noted that the issue in #871448 is
present because the uploader didn't use uscan to download the
orig.tar.gz, which means that the Files-Excluded line was never used,
and Excluded files were present in the orig.tar.gz.

It'd be super snazzy if lintian were to throw an error if any of the
Files-Excluded globs hit a file in the orig.tar.gz, with a severity of
error. Hopefully this would have alerted the uploader, and caused them
to re-download the tarball.

Thanks for working on Lintian!

-- 
:wq

Bug#871453: ITP: golang-github-markbates-inflect -- A git fork of https://bitbucket.org/pkg/inflect

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-markbates-inflect
  Version : go.r60+git20170411.16.6cacb66-1
  Upstream Author : Mark Bates, Chris Farmiloe, David Heinemeier Hansson
* URL : https://github.com/markbates/inflect
* License : Expat
  Programming Lang: Go
  Description : Go library to transform words from singular to plural (Git 
fork)

 Forked from originall Mercurial-based https://bitbucket.org/pkg/inflect,
 this Go library transforms words from singular to plural, class names to
 table names, modularized class names to ones without, and class names to
 foreign keys. The default inflections for pluralization, singularization,
 and uncountable words are kept in inflect.go.
 .
 Originally ported from the ActiveSupport::Inflector module from
 Ruby on Rails.

Reason for packaging:
 Needed by the newly released Hugo 0.26, which has switched from
 github.com/bep/inflect (provided by golang-bitbucket-pkg-inflect-dev)
 to the better-maintained github.com/markbates/inflect.

Bug#871448: [pkg-go] Bug#871448: golang-github-mattn-go-sqlite3-dev: please unbundle SQLite

[Paul Tagliamonte]

Unvendoring a code copy from shipping in a binary deb is a good idea
-- thanks for the bug! Doubly so with sqlite.

However, I don't see the point in removing it from the source if it's
at all anywhere close to more work to remove it. It's DFSG free and
it's not a huge deal to keep in source -- honestly, I'd rather keep
deltas with upstream minimal with source trees.

On Mon, Aug 7, 2017 at 11:15 PM, Aaron M. Ucko  wrote:
> Package: golang-github-mattn-go-sqlite3-dev
> Version: 1.2.0+git20170710.100.47fc4e5~dfsg1-1
> Severity: normal
>
> golang-github-mattn-go-sqlite3-dev now includes a full copy of the
> SQLite3 amalgamation, roughly 7.5 MB in size.  Per Policy 4.13, please
> omit it from the binary package, and consider dropping it from the
> source package (which you're evidently already repacking) as well.
>
> Thanks!
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32
>
> Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages golang-github-mattn-go-sqlite3-dev depends on:
> ii  libsqlite3-dev  3.19.3-3
>
> golang-github-mattn-go-sqlite3-dev recommends no packages.
>
> golang-github-mattn-go-sqlite3-dev suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
:wq

Bug#871451: stretch-pu: package up-imapproxy/1.2.8~svn20161210-2

[Richard Laager]

I have attached the patch of the changes I intend to (have my sponsor)
upload. This is identical to the changes in 1.2.8~svn20161210-3 in
unstable and testing, except for the version number and date in the
changelog and setting a debian-branch in debian/gbp.conf.

-- 
Richard
diff -urN debian-2/changelog debian/changelog
--- debian-2/changelog	2016-12-13 18:44:17.0 -0600
+++ debian/changelog	2017-08-07 23:59:22.0 -0500
@@ -1,3 +1,11 @@
+up-imapproxy (1.2.8~svn20161210-2+deb9u1) stretch; urgency=medium
+
+  * Correct the service file.
+Thanks to Marc Dequènes (Duck) (Closes: 868150)
+  * Move the pidfile to /run
+
+ -- Richard Laager   Mon, 07 Aug 2017 23:58:28 -0500
+
 up-imapproxy (1.2.8~svn20161210-2) unstable; urgency=medium
 
   [ Jose Luis Tallon ]
diff -urN debian-2/gbp.conf debian/gbp.conf
--- debian-2/gbp.conf	2016-12-13 18:44:17.0 -0600
+++ debian/gbp.conf	2017-08-07 23:57:54.0 -0500
@@ -1,4 +1,5 @@
 [DEFAULT]
+debian-branch = stretch
 pristine-tar = True
 
 [buildpackage]
diff -urN debian-2/imapproxy.service debian/imapproxy.service
--- debian-2/imapproxy.service	2016-12-13 18:44:17.0 -0600
+++ debian/imapproxy.service	2017-07-13 20:12:23.0 -0500
@@ -8,3 +8,7 @@
 Type=forking
 ExecStartPre=/usr/share/imapproxy/prepare-chroot
 ExecStart=/usr/sbin/imapproxyd -f /etc/imapproxy.conf
+PIDFile=/run/imapproxy.pid
+
+[Install]
+WantedBy=multi-user.target
diff -urN debian-2/manpages/imapproxyd.8 debian/manpages/imapproxyd.8
--- debian-2/manpages/imapproxyd.8	2016-12-13 18:44:17.0 -0600
+++ debian/manpages/imapproxyd.8	2017-08-07 23:58:20.0 -0500
@@ -48,7 +48,7 @@
 option
 .PP
 Unless foreground_mode has been enabled, IMAP Proxy will write its PID to to
-a PID-file. It defaults to /var/run/imapproxy.pid, but can be overridden with
+a PID-file. It defaults to /run/imapproxy.pid, but can be overridden with
 the
 .I -p
 option
diff -urN debian-2/patches/move-pidfile-to-run.patch debian/patches/move-pidfile-to-run.patch
--- debian-2/patches/move-pidfile-to-run.patch	1969-12-31 18:00:00.0 -0600
+++ debian/patches/move-pidfile-to-run.patch	2017-07-13 21:02:30.0 -0500
@@ -0,0 +1,19 @@
+Description: Move pidfile to /run
+ Debian is converting to /run.  This particular transition (from /var/run to
+ /run) is currently optional.
+ .
+ See: https://wiki.debian.org/ReleaseGoals/RunDirectory
+Author: Richard Laager 
+Forwarded: no
+Last-Update: 2017-07-13
+--- a/include/imapproxy.h
 b/include/imapproxy.h
+@@ -182,7 +182,7 @@
+ #define DEFAULT_CONFIG_FILE "/etc/imapproxy.conf"
+ #endif
+ #ifndef DEFAULT_PID_FILE
+-#define DEFAULT_PID_FILE   "/var/run/imapproxy.pid"
++#define DEFAULT_PID_FILE   "/run/imapproxy.pid"
+ #endif
+ 
+ #define LITERAL_PASSWORD1
diff -urN debian-2/patches/series debian/patches/series
--- debian-2/patches/series	2016-12-13 18:44:17.0 -0600
+++ debian/patches/series	2017-07-13 20:17:47.0 -0500
@@ -10,3 +10,4 @@
 cleanup-names.patch
 cleanup-readme.patch
 cleanup-imapproxy_conf.patch
+move-pidfile-to-run.patch

Bug#868150: imapproxy: fails to start

[Richard Laager]

On 07/18/2017 01:28 PM, Richard Laager wrote:
> Agreed on stable-proposed-updates. I plan to prepare an upload in the next 
> few days.

I have prepared the changes and submitted the required bug for
stable-proposed-updates here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871451

I assume I need to hear some sort of ACK on that bug before I (ask my
sponsor to) upload.

-- 
Richard

Bug#870643: [pkg-go] Bug#870643: golang-github-pierrec-lz4-dev: please split off test data

[Paul Tagliamonte]

As with the other bug, I don't see the point in this. This package is
used as a Build-Dependency, and not used by either end-users, or
developers working on Go source code on Debian, so splitting this off
will add space in the archive, and add a lot of complexity.

I'm against splitting this unless there's seriously good cause.

   Paul

On Thu, Aug 3, 2017 at 2:06 PM, Aaron M. Ucko  wrote:
> Package: golang-github-pierrec-lz4-dev
> Version: 0.0~git20170519.0.5a3d224-1
> Severity: minor
>
> The golang-github-pierrec-lz4-dev binary package now consists of 9+ MB
> of test data and a much smaller quantity of actual code.  I acknowledge
> the value of automated regression testing, but would appreciate it if
> you could please split the test data into a separate binary package.
>
> Thanks!
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32
>
> Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
:wq

Bug#871452: cherrytree: Please omit the menu option to check for newer version

[Rolf Leggewie]

Package: cherrytree
Severity: minor

Dear Maintainer,

I believe that for a distro package it does not make sense to have a binary
have a menu option to check upstream for a newer version.  The latest
available version in Debian is the one available from the mirrors.  This
should be easy enough to patch out.

Regards

Rolf

Bug#871447: [pkg-go] Bug#871447: golang-github-gogo-protobuf-dev: please split off test data

[Paul Tagliamonte]

Seeing as how these are development headers for building go debian
packages (as a Build-Dependency), and not
something users would ever install (including go developers working on
Debian, since these system -dev packages aren't useful to use there
either), I don't see the added complexity worth the space savings.

In fact, splitting this off may even result in more archive space to
store another .deb. I'd be against splitting this package unless there
was seriously good cause.

   Paul

On Mon, Aug 7, 2017 at 10:35 PM, Aaron M. Ucko  wrote:
> Package: golang-github-gogo-protobuf-dev
> Version: 0.3+git20170120.144.265e960d-1
> Severity: minor
>
> Following up on #870643, I see that several other go packages, notably
> golang-github-gogo-protobuf-dev, contain much more test data (nearly
> 22M in this case) than actual code.  Once again, I acknowledge the
> value of automated regression testing, but would appreciate it if you
> could please split the test data into a separate binary package.
>
> Thanks!
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386, x32
>
> Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> golang-github-gogo-protobuf-dev depends on no packages.
>
> Versions of packages golang-github-gogo-protobuf-dev recommends:
> ii  gogoprotobuf  0.3+git20170120.144.265e960d-1
>
> golang-github-gogo-protobuf-dev suggests no packages.
>
> -- no debconf information
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
:wq

Bug#871451: stretch-pu: package up-imapproxy/1.2.8~svn20161210-2

[Richard Laager]

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

As discussed in bug #868150, the imapproxy daemon fails to start on Stretch
with systemd.  There are two problems here.  First, the service was not
installed properly, due to the lack of an [Install] section.  Second, once the
service is properly installed, systemd (intermittently) fails to find the main
PID of the daemon unless the PIDFile is specified.

This has been corrected in unstable and testing.  I seek to upload the
equivalent of the "-3" package version to stable-proposed-updates, versioned as
1.2.8~svn20161210-2+deb9u1.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Bug#871450: ITP: golang-github-jdkato-syllables -- Go syllable counter

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-jdkato-syllables
  Version : 0.1.0+git20170409.10.8961fa0-1
  Upstream Authors: Joseph Kato, mtso, Titus Wormer
* URL : https://github.com/jdkato/syllables
* License : Expat
  Programming Lang: Go
  Description : Go syllable counter

 Go port of the JavaScript syllable counter at
 https://github.com/wooorm/syllable
 .
 Forked from https://github.com/mtso/syllables

Reason for packaging:
 github.com/jdkato/syllables is imported by github.com/jdkato/prose,
 which in turn is needed by the newly released Hugo 0.26

Bug#871449: override: curvedns:net/optional

[Ryan Tandy]

Package: ftp.debian.org
Severity: normal

The curvedns maintainer (in CC) changed its priority from standard to 
optional. Could you please make the same change on the archive side?

Bug#871448: golang-github-mattn-go-sqlite3-dev: please unbundle SQLite

[Aaron M. Ucko]

Package: golang-github-mattn-go-sqlite3-dev
Version: 1.2.0+git20170710.100.47fc4e5~dfsg1-1
Severity: normal

golang-github-mattn-go-sqlite3-dev now includes a full copy of the
SQLite3 amalgamation, roughly 7.5 MB in size.  Per Policy 4.13, please
omit it from the binary package, and consider dropping it from the
source package (which you're evidently already repacking) as well.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

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

Versions of packages golang-github-mattn-go-sqlite3-dev depends on:
ii  libsqlite3-dev  3.19.3-3

golang-github-mattn-go-sqlite3-dev recommends no packages.

golang-github-mattn-go-sqlite3-dev suggests no packages.

-- no debconf information

Bug#871447: golang-github-gogo-protobuf-dev: please split off test data

[Aaron M. Ucko]

Package: golang-github-gogo-protobuf-dev
Version: 0.3+git20170120.144.265e960d-1
Severity: minor

Following up on #870643, I see that several other go packages, notably
golang-github-gogo-protobuf-dev, contain much more test data (nearly
22M in this case) than actual code.  Once again, I acknowledge the
value of automated regression testing, but would appreciate it if you
could please split the test data into a separate binary package.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

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

golang-github-gogo-protobuf-dev depends on no packages.

Versions of packages golang-github-gogo-protobuf-dev recommends:
ii  gogoprotobuf  0.3+git20170120.144.265e960d-1

golang-github-gogo-protobuf-dev suggests no packages.

-- no debconf information

Bug#854733: Zoneminder issues fixed? (was: Re: Bug#854733 tagged as pending)

[Chris Lamb]

Hi Salvatore,

> found 854272 1.30.4+dfsg-1
> found 854733 1.30.4+dfsg-1
> thanks
> 
> Hi Salvatore,
>  
> > The recent upload to unstable claims to fix several CVEs. While for
> > #854733 this is the case for CVE-2017-5595, I fail to find fixing
> > commits for the other two CVEs from that bug. Where are they fixed?
> > Can you help identifying the commits?
> 
> Oh crumbs, I was either misinformed on (or more likely I misinterpreted!)
> an off-list conversation about these CVEs.
> 
> Am immediately re-opening them all for now whilst I investigate.

Hm, so I think these were all fixed in:

   
https://github.com/ZoneMinder/ZoneMinder/commit/d38bae72aeece85a20e3774c4953080e2e09e63c

What do you think?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#871446: jemalloc: FTBFS on hurd-i386: aligned_alloc test hangs

[Aaron M. Ucko]

Source: jemalloc
Version: 3.6.0-10
Severity: important
Justification: fails to build from source

Thanks for taking care of #828871!  jemalloc now compiles on
hurd-i386, but the build still ultimately fails because the
aligned_alloc test hangs (hard):

  === test/integration/aligned_alloc ===
  
  Session terminated, terminating shell...Killed
  Test harness error
  Makefile:344: recipe for target 'check' failed
  make[1]: *** [check] Error 1
  make[1]: Leaving directory '/<>'
  dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
  debian/rules:46: recipe for target 'build-arch' failed
  make: *** [build-arch] Error 2
  dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
  E: Build killed with signal TERM after 180 minutes of inactivity
  E: Build killed with signal KILL after 5 minutes of inactivity
  E: Build killed with signal KILL after 10 minutes of inactivity

On a possibly related note, I see some warnings regarding that test,
though jemalloc should still fail gracefully on excessive values.

  test/integration/aligned_alloc.c: In function 'test_oom_errors':
  test/integration/aligned_alloc.c:43:4: warning: argument 2 value '2147483648' 
exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
p = aligned_alloc(alignment, size);
~~^~~~
  In file included from test/include/test/jemalloc_test.h:1:0,
   from test/integration/aligned_alloc.c:1:
  /usr/include/stdlib.h:470:14: note: in a call to allocation function 
'aligned_alloc' declared here
   extern void *aligned_alloc (size_t __alignment, size_t __size)
^
  test/integration/aligned_alloc.c:56:4: warning: argument 2 value '3221225473' 
exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
p = aligned_alloc(alignment, size);
~~^~~~
  In file included from test/include/test/jemalloc_test.h:1:0,
   from test/integration/aligned_alloc.c:1:
  /usr/include/stdlib.h:470:14: note: in a call to allocation function 
'aligned_alloc' declared here
   extern void *aligned_alloc (size_t __alignment, size_t __size)
^
  test/integration/aligned_alloc.c:68:4: warning: argument 2 value '4294967280' 
exceeds maximum object size 2147483647 [-Walloc-size-larger-than=]
p = aligned_alloc(alignment, size);
~~^~~~
  In file included from test/include/test/jemalloc_test.h:1:0,
   from test/integration/aligned_alloc.c:1:
  r/usr/include/stdlib.h:470:14: note: in a call to allocation function 
'aligned_alloc' declared here
   extern void *aligned_alloc (size_t __alignment, size_t __size)
^

Could you please take a look?  You can find the full log at
https://buildd.debian.org/status/fetch.php?pkg=jemalloc=hurd-i386=3.6.0-10=1502088411=0

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#871445: linux-image-4.9.0-3-amd64: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]

[Damien Myracle]

Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I installed 'oracle java8' using ppa from Ubuntu, Team8, during the 
installation, ssh session began to 'freeze' and syslog recorded messages 
regarding CPU locking up. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Just installed Orcale Java8 on a virgin isntance of Debian9 server.

   * What was the outcome of this action?
OS began to 'freeze' with kernel messages about 'locked up CPU'

   * What outcome did you expect instead?
A normal operation of the OS. 

*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-3-amd64 root=/dev/mapper/docs--vg-root ro quiet

** Tainted: L (16384)
 * Kernel has detected soft lockup before.

** Kernel log:
[  139.486220] swapper/0   R  running task0 0  0 0x0008
[  139.486224]  93313580 926a3bcb  
93313580
[  139.486226]  9277a4b6 9ccf3fc18fc0 9324a6c0 

[  139.486229]  93313580  926dee04 
00983df7
[  139.486231] Call Trace:
[  139.486233]   
[  139.486238]  [] ? sched_show_task+0xcb/0x130
[  139.486242]  [] ? rcu_dump_cpu_stacks+0x92/0xb2
[  139.486244]  [] ? rcu_check_callbacks+0x754/0x8a0
[  139.486247]  [] ? update_wall_time+0x473/0x790
[  139.486250]  [] ? tick_sched_handle.isra.12+0x50/0x50
[  139.486252]  [] ? update_process_times+0x28/0x50
[  139.486254]  [] ? tick_sched_handle.isra.12+0x20/0x50
[  139.486255]  [] ? tick_sched_timer+0x38/0x70
[  139.486257]  [] ? __hrtimer_run_queues+0xdc/0x240
[  139.486258]  [] ? hrtimer_interrupt+0x9c/0x1a0
[  139.486261]  [] ? smp_apic_timer_interrupt+0x39/0x50
[  139.486263]  [] ? apic_timer_interrupt+0x82/0x90
[  139.486266]  [] ? _raw_spin_unlock_irqrestore+0x11/0x20
[  139.486283]  [] ? pvscsi_queue+0x42d/0x870 [vmw_pvscsi]
[  139.486294]  [] ? scsi_test_unit_ready+0x150/0x150 
[scsi_mod]
[  139.486302]  [] ? scsi_dispatch_cmd+0xd6/0x200 [scsi_mod]
[  139.486309]  [] ? scsi_request_fn+0x460/0x5e0 [scsi_mod]
[  139.486312]  [] ? __blk_run_queue+0x2f/0x40
[  139.486313]  [] ? blk_run_queue+0x21/0x40
[  139.486320]  [] ? scsi_run_queue+0x243/0x2c0 [scsi_mod]
[  139.486327]  [] ? scsi_end_request+0x122/0x1a0 [scsi_mod]
[  139.486333]  [] ? scsi_io_completion+0x1a6/0x670 [scsi_mod]
[  139.486335]  [] ? blk_done_softirq+0x88/0xb0
[  139.486337]  [] ? __do_softirq+0x105/0x290
[  139.486339]  [] ? irq_exit+0xae/0xb0
[  139.486341]  [] ? do_IRQ+0x4f/0xd0
[  139.486343]  [] ? common_interrupt+0x82/0x82
[  139.486344]   
[  139.486347]  [] ? native_safe_halt+0x2/0x10
[  139.486348]  [] ? default_idle+0x1a/0xd0
[  139.486351]  [] ? cpu_startup_entry+0x1ca/0x240
[  139.486353]  [] ? start_kernel+0x443/0x463
[  139.486355]  [] ? early_idt_handler_array+0x120/0x120
[  139.486357]  [] ? x86_64_start_kernel+0x14c/0x170
[  187.362590] TCP: ens192: Driver has suspect GRO implementation, TCP 
performance may be compromised.
[  708.602102] INFO: rcu_sched detected stalls on CPUs/tasks:
[  708.707854]  0-...: (1 GPs behind) idle=6f3/1/0 softirq=5911/5911 fqs=263 
[  708.707877]  (detected by 1, t=5282 jiffies, g=7910, c=7909, q=167)
[  708.707898] Task dump for CPU 0:
[  708.707899] swapper/0   R  running task0 0  0 0x0008
[  708.707903]  9320e500  0001 

[  708.707905]  0100   

[  708.707906]    ff4b 
92c05b02
[  708.707908] Call Trace:
[  708.707914]  [] ? native_safe_halt+0x2/0x10
[  708.707915]  [] ? default_idle+0x1a/0xd0
[  708.707917]  [] ? cpu_startup_entry+0x1ca/0x240
[  708.707920]  [] ? start_kernel+0x443/0x463
[  708.707922]  [] ? early_idt_handler_array+0x120/0x120
[  708.707923]  [] ? x86_64_start_kernel+0x14c/0x170
[  712.156417] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[swapper/0:0]
[  712.156451] Modules linked in: vmw_vsock_vmci_transport vsock coretemp 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ppdev vmw_balloon 
intel_rapl_perf joydev serio_raw pcspkr evdev shpchp sg vmwgfx vmw_vmci ttm 
drm_kms_helper drm parport_pc nfit libnvdimm parport battery ac acpi_cpufreq 
button ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb 
mbcache hid_generic usbhid hid dm_mod sr_mod cdrom sd_mod ata_generic 
crc32c_intel aesni_intel uhci_hcd aes_x86_64 glue_helper lrw gf128mul ehci_pci 
ablk_helper cryptd ata_piix psmouse ehci_hcd 

Bug#871444: transition: msgpack-c

[James McCoy]

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

I'd like to upload the new msgpack-c to unstable.  I did a test rebuild
in July and filed bugs[0] against the packages which fail to build with
the new API changes.

[0]: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=msgpac...@packages.debian.org;tag=msgpack-c-2.x;dist=unstable

The below Ben settings will detect the packages using the C library
which need to be rebuilt, but the C++ library is header-only.  I'm not
sure the how that should be tracked, other than FTBFS bugs.

Ben file:

title = "msgpack-c";
is_affected = .depends ~ "libmsgpackc2";
is_good = .depends ~ /libmsgpackc2 \(>= 2\.1\.0)/ | .depends ~ /libmsgpackc2 
\(>= 0\.5\.7);
is_bad = .depends ~ /libmsgpackc2 \(>= 1\.0\.0\)/;


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

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

Bug#870688: [Debian-science-sagemath] Sage 8.0 status (was Re: Sage 7.6 upload for RC bugfix and GAP 4.8.7 in unstable)

[Ximin Luo]

-#869778

Ximin Luo:
> [..]
> 
> Hi, I see that libgsl23 was uploaded but who is taking care of the library 
> transition? It seems that this process was not followed:
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
> 
> The transition tracker detected the library change:
> https://release.debian.org/transitions/html/auto-gsl.html
> 
> However there is no corresponding Transition Tracking bug report:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org
> 
> Currently this prevents me from doing test builds of sagemath, because some 
> of its build dependencies are not installable [..]
> 

As a temporary workaround:

$ aptitude search '~Dlibgsl2$ ~R^sagemath$ ~rnative' --disable-columns
p  python-cvxopt - Python package for convex optimization   
   
p  xcas - Computer Algebra System - console and graphical calculator

Since this list is quite small, I've done my own binNMUs of these packages 
(using sbuild --binNMU etc) and uploaded them to deb-sci-sage. This makes 
`debian/rules release-deb-sci-sage` work again, I'll run it properly in the 
morning and report the results.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#870827: docbook-utils: PDF backend requires texlive-formats-extra

[Norbert Preining]

Hi Adrian,

> jadetex is a transitional package depending on texlive-htmlxml.

That is fine.

> texlive-htmlxml is a transitional package that does not depend
> on texlive-formats-extra.

Huu?
$ apt-cache show texlive-htmlxml
...
Depends: texlive-formats-extra (>= 2017.20170628), ...


> texlive-plain-generic has Provides: jadetex

That is the bug, both xmltex and jadetex happened to be
treated in the same way as tex4ht, but are in different
packages.

> - texlive-htmlxml should depend on texlive-formats-extra, and

It does.

> - the "Provides: jadetex" should move from texlive-htmlxml
>   to texlive-formats-extra

Done in git, uploading soon

> And src:jadetex should be removed, no (build) dependency is versioned
> so the existing Provides already covers that (after the bug above has 
> been fixed).

Ok.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#793057: ITP: godot -- open source MIT licensed game engine

[Kienan Stewart]

I've had a first pass at creating a package for godot : 
https://mentors.debian.net/package/godot

There are some lintian warnings to clear up, and I was wondering a bit about 
the following

 * builds only support amd64 at the moment
 * how to handle packaging godot 3.0 when it's available (an alpha is currently 
out)

Once I find some time to clear up the lintian warnings, I'll do the RFS 
procedure following the mentor's guide and 
https://wiki.debian.org/Games/Sponsors/Queue


signature.asc
Description: PGP signature

Bug#871443: RFA: nanomsg -- a fast, scalable communications library

[Harlan Lieberman-Berg]

Package: wnpp
Severity: normal

I request an adopter for the nanomsg package. As I'm no longer using
this library, I'm having trouble giving it attention. At this point,
the library is pretty stable; there are some strange issues with
some of the more exotic architectures that have been a persistant
problem over the last couple of years, but upstream hasn't entirely
been responsive.

The package description is:
 nanomsg is a socket library that provides several common
 communication patterns. It aims to make the networking layer fast,
 scalable, and easy to use. Implemented in C, it works on a wide range
 of operating systems with no further dependencies.
 .
 The communication patterns, also called "scalability protocols", are
 basic blocks for building distributed systems. By combining them you
 can create a vast array of distributed applications. The following
 scalability protocols are currently available:
 .
 PAIR - simple one-to-one communication
 BUS - simple many-to-many communication
 REQREP - allows one to build clusters of stateless services
 to process user requests
 PUBSUB - distributes messages to large sets of interested subscribers
 PIPELINE - aggregates messages from multiple sources and
 load balances them among many destinations
 SURVEY - allows one to query state of multiple applications in a single go
 .
 This package contains the development files for nanomsg.

Bug#869778: [Debian-science-sagemath] Sage 8.0 status (was Re: Sage 7.6 upload for RC bugfix and GAP 4.8.7 in unstable)

[Ximin Luo]

Control: block 870688 by 869778
Control: affects 869778 + sagemath

Ximin Luo:
> Tobias Hansen:
>> [..]
>>
>> The accidental upload of cysignals 1.6.5 to unstable is now a RC bug
>> (#870688). Not sure if we should fix it by downgrading cysignals,
>> patching sage 7.6 or just let the bug sit until we upload sage 8.0. At
>> least the "Breaks: sagemath (<< 8.0~)" does indeed prevent cysignals
>> from migrating to testing, which is good.
>>
>> [..]
> 
> Hi, I'm at DebConf over the next week and will very likely be able to find 
> some time to deal with this.
> 

Hi, I see that libgsl23 was uploaded but who is taking care of the library 
transition? It seems that this process was not followed:
https://wiki.debian.org/Teams/ReleaseTeam/Transitions

The transition tracker detected the library change:
https://release.debian.org/transitions/html/auto-gsl.html

However there is no corresponding Transition Tracking bug report:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=release.debian.org

Currently this prevents me from doing test builds of sagemath, because some of 
its build dependencies are not installable:

[..]
cd .. && sbuild \
  --extra-repository='deb http://httpredir.debian.org/debian experimental main' 
\
  --chroot-setup-commands='apt-get install -y apt-transport-https' \
  --extra-repository='deb https://debian-science.alioth.debian.org/apt 
sid-sage/' \
  
--extra-repository-key=/home/infinity0/var/lib/sage/sagemath/debian/deb-sci-sage.asc
 \
  --build-dep-resolver=aspcud \
  --build-failed-commands '%SBUILD_SHELL' \
   \
  "sagemath_8.0-0~sage1.dsc"
[..]
(I)Distcheck: Solving...
output-version: 1.2
native-architecture: amd64
report:
 -
  package: sbuild-build-depends-sagemath-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
conflict:
 pkg1:
  package: libgslcblas0
  version: 2.4+dfsg-5
  architecture: amd64
  unsat-conflict: libgsl2:amd64
 pkg2:
  package: libgsl2
  version: 2.4+dfsg-2
  architecture: amd64
 depchain1:
  -
   depchain:
-
 package: sbuild-build-depends-sagemath-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: libgsl-dev:amd64
-
 package: libgsl-dev
 version: 2.4+dfsg-5
 architecture: amd64
 depends: libgslcblas0:amd64 (= 2.4+dfsg-5)
 depchain2:
  -
   depchain:
-
 package: sbuild-build-depends-sagemath-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: python-cvxopt:amd64
-
 package: python-cvxopt
 version: 1.1.9+dfsg-1+b1
 architecture: amd64
 depends: libgsl2:amd64
[..]

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#858911: thunderbird: Apparmor prevents opening links from emails in firefox.

[Michael Biebl]

Am 08.08.2017 um 00:52 schrieb intrigeri:
> Hi!
> 
> intrigeri:
>> Michael Biebl:
>>> Afaics, thunderbird uses x-www-browser by default, which can point at
>>> arbitrary browsers. I also tried with epiphany-browser and chromium.
>>> None of those worked either.
> 
>> Thanks for checking. I'll have a look and ensure all major browsers
>> work fine for this use case.
> 
> Reproduced the problem with Chromium after setting it as the default
> browser in GNOME Control Center ⇒ fix submitted upstream, applied
> locally, will be in apparmor 2.11.0-9 that I'll upload shortly.
> 
> But I can't reproduce the problem with epiphany-browser: I've tried
> selecting "Web" as the default browser in GNOME Control Center, and
> pointing the x-www-browser alternative to /usr/bin/epiphany-browser,
> and links open just fine from Thunderbird ⇒ Michael, can you please
> submit a dedicated bug report (against the apparmor package) about
> this issue, attaching whatever the Journal says about AppArmor?

Hm, seems you're right. Changing the default browser via
update-alternative --config x-www-browser doesn't seem influence the
behaviour of thunderbird when running under GNOME.
Using gnome-control-center to change the default application to Web
(epiphany), thunderbird does open links properly.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#871021: jadetex: transitional package since stretch and containing stuff

[Norbert Preining]

On Sun, 06 Aug 2017, Holger Levsen wrote:
> jadetex package description says it's a transitional package (in stretch and
> upwards), yet it still contains stuff and not mere meta data.

It contains changelog, readme that explains the situation. Isn't that fine?
Are there any regulations that a transitional package has to be empty?
In contrast, changelog and copyright *need* to be in the package by policy.

> I guess the proper cause of action would be to remove the package from sid.

That is the plan in the near future.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#870617: biber: deprecated regex warning

[Norbert Preining]

tags 870617 + pending
thanks

On Thu, 03 Aug 2017, Raphaël Bleuse wrote:
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
> 5.30), passed through in regex; marked by <-- HERE in m/}(\pM+\pL){ <-- HERE 
> (?!\pL+\\)/ at /usr/share/perl5/Biber/LaTeX/Recode.pm line 316,  line 1.

Fixed in git repository, will be uploaded sooner or later.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#826465: texlive-latex-recommended: Unescaped left brace in regex is deprecated

[Norbert Preining]

> Here's a one-character-patch for this issue.

Thanks, added to the git repo, I will upload soon after fixing a few more bugs.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

[Didier 'OdyX' Raboud]

Le lundi, 7 août 2017, 09.40:22 h EDT Russ Allbery a écrit :
> Daniel Kahn Gillmor  writes:
> > debian-policy should encourage verification of upstream cryptographic
> > signatures.

Yes.

> diff --git a/policy.xml b/policy.xml
> index 6086901..c14d9b4 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -2556,11 +2556,28 @@ endif
> 
>
>  This is an optional, recommended configuration file for the
> -uscan utility which defines how to
> +uscan utility which defines how to
>  automatically scan ftp or http sites for newly available updates
>  of the package.  This is used Debian QA tools to help with quality

While were at patching this, this sentence should read:
> This is used _by_ Debian QA tools …
or
> This is used _by some_ Debian QA tools…

Other than that, seconded!

Cheers,
OdyX

Bug#871442: grpc: Turn on grpcio python module building

[Ondřej Kobližek]

Source: grpc
Version: 1.3.2-0.2
Severity: normal

Hi,

I am dependant on python grpcio and looking for grpcio deb package.
Could you turn on packaging for grpcio please?

PyPI grpcio is not an option for me.

With regards,
Ondrej Koblizek

-- System Information:
Debian Release: stretch/sid
  APT prefers zesty-updates
  APT policy: (500, 'zesty-updates'), (500, 'zesty-security'), (500, 'zesty'), 
(100, 'zesty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-28-generic (SMP w/4 CPU cores)
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#871441: apparmor: Including tunables/sys to tunables/global?

[Vincent Blut]

Package: apparmor
Version: 2.11.0-6+b2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

/etc/apparmor.d/tunables/proc being part of 
/etc/apparmor.d/tunables/global, I’m wondering if there are any reasons 
preventing the sysfs pseudo file system location variable (defined in 
/etc/apparmor.d/tunables/sys) from being included as well?

Cheers,
Vincent

- -- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apparmor depends on:
ii  debconf  1.5.63
ii  init-system-helpers  1.49
ii  libapparmor-perl 2.11.0-6+b2
ii  libc62.24-12
ii  lsb-base 9.20161125
ii  python3  3.5.3-3

apparmor recommends no packages.

Versions of packages apparmor suggests:
ii  apparmor-profiles2.11.0-6
ii  apparmor-profiles-extra  1.12
ii  apparmor-utils   2.11.0-6+b2

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQJLBAEBCgA1FiEE/VQBlxWoTJPh4vI5ipzudlpxp4AFAlmI/uEXHHZpbmNlbnQu
ZGViaWFuQGZyZWUuZnIACgkQipzudlpxp4COow//UJMfmaQKFfUSXKFzNfBns2cu
4mljJIqO43SHTRyecm9QubL4WqQ1uhU/uXfvSfxw4NZLdjUWaZTS9z5oLZELuTXg
sCtQ9crQHrWr/ECb5zLfnZpYCnT5mdZ8mEV1khWYD6EqPe0mpkTi6Dz8GX4eS8/d
Mp9UewUTeqzupOfC3WTrgZXpfkuIXUR0/P++DypcrnprGrYflTo6+MBnROPRF3g3
bfyThrKIYyQglOsEjII5UuGGvXnYohPDa+JW4QMm+gX2iF8sdU7X1eQrNOgz5sK8
6JFc5vtqrCLInq+4SmVYGMCH1nYPHz1YaqfCPm+mkJ2Fwn4JVYezZzHV9ACR9wMy
YRR+nCeDERoFaGgWaC2P110bI0ezaDtdtfZ0xCyx3xhYpEzqsOyPOKohksLXea8y
S9Vm6dZ7Km1K8c6jsE+PjQz89OXh5UiQ2VozMcOymbCSEy/4F3ph+rExSejoSOa+
F2Qo40nw4sC5Th1e1acknMSWRdICIQfPIHX0vZPqAHiD/ADnO0lGU+RZlIhbzpO9
GuTG3FHS7CyCZ68KhoXYXX1otDtY0oGz4bhrY1lvSOxxsKF9zkQJ3d0F4Ut8tsC2
L2UueLXxaYF6Oabh/iXTpcw31VQxi5fUdFQ8dCVdI6XGrdhGQ8q22nn0sULQxtXz
BP6nnFrBL1mP7FFSk8M=
=Q7Hy
-END PGP SIGNATURE-

Bug#871155: brltty: FTBFS: cc1: error: -Wformat-security ignored without -Wformat [-Werror=format-security]

[Samuel Thibault]

Control: tags -1 + pending

Matthias Klose, on lun. 07 août 2017 19:38:01 -0400, wrote:
> but it's brltty setting -Wno-format

Oh, right, we haven't uploaded brltty 5.5 to unstable yet. That version
doesn't set that any more.

Thanks,
Samuel

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

[Jonathan Nieder]

Hi,

Russ Allbery wrote:

> How does this look to everyone?

Seconded, with or without the tweaks dkg suggested in
https://bugs.debian.org/732445#68

Thanks,
Jonathan

> --- a/policy.xml
> +++ b/policy.xml
> @@ -2556,11 +2556,28 @@ endif
>  
>
>  This is an optional, recommended configuration file for the
> -uscan utility which defines how to
> +uscan utility which defines how to
>  automatically scan ftp or http sites for newly available updates
>  of the package.  This is used Debian QA tools to help with quality
>  control and maintenance of the distribution as a whole.
>
> +  
> +If the upstream maintainer of the software provides PGP signatures
> +for new releases, including the information required for
> +uscan to verify signatures for new upstream
> +releases is also recommended.  To do this, use the
> +pgpsigurlmangle option in
> +debian/watch to specify the location of the
> +upstream signature, and include the key or keys used to sign
> +upstream releases in the Debian source package as
> +debian/upstream/signing-key.asc.
> +  
> +  
> +For more information about uscan and these
> +options, including how to generate the file containing upstream
> +signing keys, see
> +
> uscan1.
> +  
>  
>  
>  
> 

Bug#871155: brltty: FTBFS: cc1: error: -Wformat-security ignored without -Wformat [-Werror=format-security]

[Matthias Klose]

Control: reassign -1 brltty
Control: tags -1 + patch

http://launchpadlibrarian.net/332236575/brltty_5.4-7ubuntu3_5.4-7ubuntu4.diff.gz

On 07.08.2017 19:18, Samuel Thibault wrote:
> Control: reassign -1 python2.7
> Control: affects -1 brltty
> 
> Hello,
> 
> Lucas Nussbaum, on dim. 06 août 2017 17:15:27 -0400, wrote:
>> Relevant part (hopefully):
>>> gcc -shared -Wl,-soname,libbrlapi.so.0.6 -o libbrlapi.so brlapi_client.o 
>>> -lpthread -lsupc++ 
>>> ar rc libbrlapi.a brlapi_client.o
>>> /usr/bin/ranlib libbrlapi.a
>>> make[2]: Leaving directory '/<>/build-py2.7/Programs'
>>> set -- --quiet build --build-temp .; \
>>> [ "linux-gnu" != "mingw32" ] || set -- "${@}" --compiler mingw32; \
>>> /usr/bin/python2.7 ./setup.py "${@}"
>>> cc1: error: -Wformat-security ignored without -Wformat 
>>> [-Werror=format-security]
>>> cc1: some warnings being treated as errors
>>> error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
>>> Makefile:72: recipe for target 'brlapi.so' failed
>>> make[1]: *** [brlapi.so] Error 1
>>
>> The full build log is available from:
>>http://aws-logs.debian.net/2017/08/05/brltty_5.4-7_unstable.log
> 
> AIUI, this is coming from python2.7 itself:
> 
> /usr/lib/python2.7/plat-x86_64-linux-gnu/_sysconfigdata_nd.py: 'PY_CFLAGS': 
> '-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
> -Wdate-time -D_FORTIFY_SOURCE=2 -g 
> -fdebug-prefix-map=/build/python2.7-HVkOs2/python2.7-2.7.13=. 
> -fstack-protector-strong -Wformat -Werror=format-security  ',
> 
> Samuel
> 

but it's brltty setting -Wno-format

Bug#871440: stretch-pu: package speech-dispatcher/0.8.6-4+deb9u1

[Samuel Thibault]

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

Hello,

In #860898 it was reported that the configuration tool for
speech-dispatcher, spd-conf, is completely broken in Stretch.  Since
it took a long time for the report to come, we considered it a not bad
enough bug to propose a change before the release.

It however seems that now that Stretch is released, users are really
having problems with not having a working spd-conf (see thread starting
at https://lists.debian.org/debian-accessibility/2017/08/msg2.html),
to the point that they are considering reverting to Jessie (see "How
long id Jessie supported?" at
https://lists.debian.org/debian-accessibility/2017/08/msg00010.html)

The fix for spd-conf is really simple, see the attached patch (already
applied upstream) which I propose to upload to Stretch.

Samuel

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Samuel
 muhahaha...
 ya un train qui part de Perrache à 14h57
 qui passe à Part-Dieu à 15h10
 si je le prends à Perrache, je suis en zone bleue
 si je le prends à Part-Dieu, je suis en zone blanche
 donc je vais le prendre à Perrache *mais* à Part-Dieu ;-)
 -+- #ens-mim - vive la SNCF -+-
diff -Nru speech-dispatcher-0.8.6/debian/changelog 
speech-dispatcher-0.8.6/debian/changelog
--- speech-dispatcher-0.8.6/debian/changelog2017-03-05 23:13:08.0 
+0100
+++ speech-dispatcher-0.8.6/debian/changelog2017-08-08 01:07:02.0 
+0200
@@ -1,3 +1,9 @@
+speech-dispatcher (0.8.6-4+deb9u1) stretch; urgency=medium
+
+  * patches/spd-conf: Fix spd-conf (Closes: #860898).
+
+ -- Samuel Thibault   Tue, 08 Aug 2017 01:07:02 +0200
+
 speech-dispatcher (0.8.6-4) unstable; urgency=medium
 
   * Fix stripped audio output of flite module (Closes: #856895).
diff -Nru speech-dispatcher-0.8.6/debian/patches/series 
speech-dispatcher-0.8.6/debian/patches/series
--- speech-dispatcher-0.8.6/debian/patches/series   2017-03-05 
22:50:12.0 +0100
+++ speech-dispatcher-0.8.6/debian/patches/series   2017-08-08 
01:07:02.0 +0200
@@ -2,3 +2,4 @@
 doc-figures
 change-default-module.patch
 flite-strip-silence
+spd-conf
diff -Nru speech-dispatcher-0.8.6/debian/patches/spd-conf 
speech-dispatcher-0.8.6/debian/patches/spd-conf
--- speech-dispatcher-0.8.6/debian/patches/spd-conf 1970-01-01 
01:00:00.0 +0100
+++ speech-dispatcher-0.8.6/debian/patches/spd-conf 2017-08-08 
01:06:35.0 +0200
@@ -0,0 +1,19 @@
+--- a/src/api/python/speechd_config/config.py.in
 b/src/api/python/speechd_config/config.py.in
+@@ -156,6 +156,7 @@ def setup_argparse():
+ parser.add_argument('-D', '--debug', dest='debug',
+ action="store_true", default=False,
+ help=_("Debug a problem and generate a report"))
++return parser
+ 
+ class Tests:
+ """Tests of functionality of Speech Dispatcher and its dependencies
+@@ -746,7 +747,7 @@ you have to start it manually to continu
+ 
+ def main():
+ options = setup_argparse()
+-options.parse()
++options = options.parse_args()
+ test = Tests()
+ configure = Configure(test) # that should possibly be refactored, test 
should not be passed
+ 

Bug#871371: singularity-container: FTBFS: help2man: can't get `--version' info from /tmp/tmp.YU5T8oOc4W/run-singularity

[Yaroslav Halchenko]

On Mon, 07 Aug 2017, Lucas Nussbaum wrote:

> Hi,

> On 07/08/17 at 14:32 -0400, Yaroslav Halchenko wrote:
> > severity 871371 important
> > tags 871371 + unreproducible
> > thanks

> > Ran rebuild which succeeded just fine on up to date sid for both amd64
> > and i386 (binary only)

> > Would need to be able to reproduce to figure out WTF

> I could reproduce it using sbuild (on a different setup).

> The root cause is that you use help2man to generate manpages, but
> help2man expects both --help and --version to work. And
> 'run-singularity --version' doesn't work:
> $ run-singularity --version
> ERROR: Unknown option: --version

> That shows in the manpage for run-singularity, that contains garbage as
> version number (see man run-singularity | tail -1). This garbage comes
> from a call to tput to colorize the error message.

> For some reason, this triggers a build failure in sbuild, but not when I
> run debian/generate_manpages manually. help2man does some magic with the
> output of 'command --version', which I did not fully understand due to
> my limited perl-fu. The relevant code is:

Hi Lucas,  Thank you very much for taking time and digging into this
issue.  I am still puzzled why it didn't fail for me in cowbuilder but for
in sbuild and my perl foo also ... non-existent

also  running locally

  help2man /usr/bin/run-singularity >/tmp/1.1 

runs just fine without crashing/complaints, and indeed generated manpage
lacks version info (well - contains some garbled probably ansi
formatting symbols)...

anyways (although still interested in the answer to "why" ;) ) I will
adjust the script to consume version from the debian/changelog -- this
way even debian revision would be listed in the version.

Thank you for the report and the investigation ;)


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#826465: texlive-latex-recommended: Unescaped left brace in regex is deprecated

[gregor herrmann]

Control: tag -1 + patch

On Tue, 07 Jun 2016 15:28:42 +0200, =?UTF-8?Q?Preu=C3=9Fe wrote:

> On 05.06.2016 19:49, Niko Tyni wrote:
> 
> Dear Heiko,
> 
> here in the DBTS we got a bug report about a small syntax error in thumbpdf. 
> It
> becomes visible when calling the script using perl 5.22. Simply call thumbpdf 
> w/
> argument:
> 
> hille@sid:~ $ thumbpdf
> Unescaped left brace in regex is deprecated, passed through in regex; marked 
> by
> <-- HERE in m/\\UseRGB{ <-- HERE (\d+)}\\\s*\d+\s*R/ at /usr/bin/thumbpdf 
> line 1456.
> THUMBPDF 3.16, 2014/07/15 - Copyright (c) 1999-2014 by Heiko Oberdiek.
> Syntax:   thumbpdf [options] 
> 
> Fix should be straight forward, please be so kind to comment on this and 
> upload
> a fixed package.

Here's a one-character-patch for this issue.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   
diff -Nru texlive-base-2017.20170801/debian/changelog texlive-base-2017.20170801/debian/changelog
--- texlive-base-2017.20170801/debian/changelog	2017-08-01 03:06:47.0 -0400
+++ texlive-base-2017.20170801/debian/changelog	2017-08-07 19:23:07.0 -0400
@@ -1,3 +1,12 @@
+texlive-base (2017.20170801-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "Unescaped left brace in regex is deprecated":
+add patch thumbpdf-unescaped-left-brace to fix unescaped literal curly.
+(Closes: #826465)
+
+ -- gregor herrmann   Mon, 07 Aug 2017 19:23:07 -0400
+
 texlive-base (2017.20170801-1) unstable; urgency=medium
 
   * new upstream checkout: The Long Dark release!
diff -Nru texlive-base-2017.20170801/debian/patches/series texlive-base-2017.20170801/debian/patches/series
--- texlive-base-2017.20170801/debian/patches/series	2017-07-24 20:59:46.0 -0400
+++ texlive-base-2017.20170801/debian/patches/series	2017-08-07 19:23:07.0 -0400
@@ -29,3 +29,4 @@
 texdoctk-colors
 oberdiek-fix-boxdraw
 texdoctk-warn-missing-perltk
+thumbpdf-unescaped-left-brace
diff -Nru texlive-base-2017.20170801/debian/patches/thumbpdf-unescaped-left-brace texlive-base-2017.20170801/debian/patches/thumbpdf-unescaped-left-brace
--- texlive-base-2017.20170801/debian/patches/thumbpdf-unescaped-left-brace	1969-12-31 19:00:00.0 -0500
+++ texlive-base-2017.20170801/debian/patches/thumbpdf-unescaped-left-brace	2017-08-07 19:23:07.0 -0400
@@ -0,0 +1,18 @@
+Description: Fix "Unescaped left brace in regex is illegal here in regex" error
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/826465
+Forwarded: no
+Author: gregor herrmann 
+Last-Update: 2017-08-07
+
+--- a/texmf-dist/scripts/thumbpdf/thumbpdf.pl
 b/texmf-dist/scripts/thumbpdf/thumbpdf.pl
+@@ -1453,7 +1453,7 @@
+ my $length = $thumblength[$i];
+ my $dict = $objtext[$thumbobj[$i]];
+ $dict =~ s/\\the\\pdflastobj\\\s*\d+\s*R/{RGB_$i}/;
+-$dict =~ s/\\UseRGB{(\d+)}\\\s*\d+\s*R/{RGB_$1}/;
++$dict =~ s/\\UseRGB\{(\d+)}\\\s*\d+\s*R/{RGB_$1}/;
+ $dict =~ s/\/Length\s+\d+\s*//;
+ $dict =~ s/^\s+//;
+ $dict =~ s/\s+$//;


signature.asc
Description: Digital Signature

Bug#868047: Intent to NMU: pelican/3.7.1+dfsg.1-1

[Ben Finney]

Control: tags -1 + pending

Given that both these (bug#868049, bug#868047) are Severity: serious,
the ‘pelican’ package is scheduled for removal from “testing” very
soon.

I have a Git repository to develop release “3.7.1+dfsg.1-1”
.

If there is no substantive objection before my evening today (Tue
2017-08-08 UTC+10:00), I will do a Non-Maintainer Upload of the
release I have prepared, incorporating the patches to fix these bugs
to allow the package to remain.

-- 
 \   “The apparent lesson of the Inquisition is that insistence on |
  `\ uniformity of belief is fatal to intellectual, moral, and |
_o__)spiritual health.” —_The Uses Of The Past_, Herbert J. Muller |
Ben Finney 


signature.asc
Description: PGP signature

Bug#871155: brltty: FTBFS: cc1: error: -Wformat-security ignored without -Wformat [-Werror=format-security]

[Samuel Thibault]

Control: reassign -1 python2.7
Control: affects -1 brltty

Hello,

Lucas Nussbaum, on dim. 06 août 2017 17:15:27 -0400, wrote:
> Relevant part (hopefully):
> > gcc -shared -Wl,-soname,libbrlapi.so.0.6 -o libbrlapi.so brlapi_client.o 
> > -lpthread -lsupc++ 
> > ar rc libbrlapi.a brlapi_client.o
> > /usr/bin/ranlib libbrlapi.a
> > make[2]: Leaving directory '/<>/build-py2.7/Programs'
> > set -- --quiet build --build-temp .; \
> > [ "linux-gnu" != "mingw32" ] || set -- "${@}" --compiler mingw32; \
> > /usr/bin/python2.7 ./setup.py "${@}"
> > cc1: error: -Wformat-security ignored without -Wformat 
> > [-Werror=format-security]
> > cc1: some warnings being treated as errors
> > error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
> > Makefile:72: recipe for target 'brlapi.so' failed
> > make[1]: *** [brlapi.so] Error 1
> 
> The full build log is available from:
>http://aws-logs.debian.net/2017/08/05/brltty_5.4-7_unstable.log

AIUI, this is coming from python2.7 itself:

/usr/lib/python2.7/plat-x86_64-linux-gnu/_sysconfigdata_nd.py: 'PY_CFLAGS': 
'-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes 
-Wdate-time -D_FORTIFY_SOURCE=2 -g 
-fdebug-prefix-map=/build/python2.7-HVkOs2/python2.7-2.7.13=. 
-fstack-protector-strong -Wformat -Werror=format-security  ',

Samuel

Bug#871367: fftw: FTBFS: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.30), passed through in regex; marked by <-- HERE in m/\@(\w+){ <-- HERE ([^\{\}]+)}/ at texi2html

[gregor herrmann]

Control: tag -1 + patch

On Mon, 07 Aug 2017 11:50:33 -0400, Lucas Nussbaum wrote:

> Source: fftw
> Version: 2.1.5-4.1
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20170807 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>/doc'
> > perl texi2html -split_chapter -no_toc_href fftw.texi
> > Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
> > 5.30), passed through in regex; marked by <-- HERE in m/\@(\w+){ <-- HERE 
> > ([^\{\}]+)}/ at texi2html line 1771.
> > Unescaped left brace in regex is illegal here in regex; marked by <-- HERE 
> > in m/\@value{ <-- HERE ([^\s\{\}]+)}/ at texi2html line 842,  line 4.
> > Makefile:799: recipe for target 'html' failed
> > make[1]: *** [html] Error 25

Here's yet another patch for texi2html.
(And a bonus feature to make testing the build easier.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   
diff -Nru fftw-2.1.5/debian/changelog fftw-2.1.5/debian/changelog
--- fftw-2.1.5/debian/changelog	2016-09-18 08:15:51.0 -0400
+++ fftw-2.1.5/debian/changelog	2017-08-07 18:39:10.0 -0400
@@ -1,3 +1,14 @@
+fftw (2.1.5-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "FTBFS: Unescaped left brace in regex is deprecated here":
+add patch fix-texi2html-perl526.patch to fix Perl 5.26 regexp
+warnings/errors.
+(Closes: #871367)
+  * Add support for DEB_BUILD_OPTIONS=nocheck in debian/rules.
+
+ -- gregor herrmann <gre...@debian.org>  Mon, 07 Aug 2017 18:39:10 -0400
+
 fftw (2.1.5-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru fftw-2.1.5/debian/patches/fix-texi2html-perl526.patch fftw-2.1.5/debian/patches/fix-texi2html-perl526.patch
--- fftw-2.1.5/debian/patches/fix-texi2html-perl526.patch	1969-12-31 19:00:00.0 -0500
+++ fftw-2.1.5/debian/patches/fix-texi2html-perl526.patch	2017-08-07 18:39:10.0 -0400
@@ -0,0 +1,35 @@
+Description: Fix perl 5.26 regexp warnings/errors
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/871367
+Author: gregor herrmann <gre...@debian.org>
+Last-Update: 2017-08-07
+
+--- a/doc/texi2html
 b/doc/texi2html
+@@ -839,7 +839,7 @@
+ s/\@refill\s+//g;
+ # other substitutions
+ _substitutions;
+-s/\@value{($VARRE)}/$value{$1}/eg;
++s/\@value\{($VARRE)}/$value{$1}/eg;
+ s/\@footnote\{/\@footnote$docu_doc\{/g; # mark footnotes, cf. pass 4
+ #
+ # analyze the tag again
+@@ -1169,7 +1169,7 @@
+ #
+ # xref
+ #
+-while (/\@(x|px|info|)ref{($XREFRE)(}?)/o) {
++while (/\@(x|px|info|)ref\{($XREFRE)(}?)/o) {
+ 	# note: Texinfo may accept other characters
+ 	($type, $nodes, $full) = ($1, $2, $3);
+ 	($before, $after) = ($`, $');
+@@ -1768,7 +1768,7 @@
+ while ($changed) {
+ 	$changed = 0;
+ 	$done = '';
+-	while (/\@(\w+){([^\{\}]+)}/) {
++	while (/\@(\w+)\{([^\{\}]+)}/) {
+ 	$text = _style($1, $2);
+ 	if ($text) {
+ 		$_ = "$`$text$'";
diff -Nru fftw-2.1.5/debian/patches/series fftw-2.1.5/debian/patches/series
--- fftw-2.1.5/debian/patches/series	2016-09-18 08:06:40.0 -0400
+++ fftw-2.1.5/debian/patches/series	2017-08-07 18:39:10.0 -0400
@@ -5,3 +5,4 @@
 info-syntax
 fix-texi2html-perl522.patch
 perl-cwd-in-inc.patch
+fix-texi2html-perl526.patch
diff -Nru fftw-2.1.5/debian/rules fftw-2.1.5/debian/rules
--- fftw-2.1.5/debian/rules	2016-07-11 15:59:11.0 -0400
+++ fftw-2.1.5/debian/rules	2017-08-07 18:39:10.0 -0400
@@ -30,17 +30,21 @@
 	# single precision
 	F77=gfortran CFLAGS="$(CFLAGS)" CC=mpicc ./configure $(CONFFLAGS) --enable-float --enable-type-prefix $(ARCHCONFFLAGS)
 	$(MAKE)
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 	#$(MAKE) -C tests check
 	./tests/fftw_test  -t -e -v -p 1024 -x 1
 	./tests/rfftw_test -t -e -v -p 1024 -x 1
+endif
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp-single
 	$(MAKE) clean
 	# double precision
 	F77=gfortran CFLAGS="$(CFLAGS)" CC=mpicc ./configure $(CONFFLAGS) $(ARCHCONFFLAGS)
 	$(MAKE)
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 	#$(MAKE) -C tests check
 	./tests/fftw_test  -t -e -v -p 1024 -x 1
 	./tests/rfftw_test -t -e -v -p 1024 -x 1
+endif
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp-double
 	touch build-arch-stamp
 


signature.asc
Description: Digital Signature

Bug#870874: support sound on ltsp clients with pulseaudio

[Holger Levsen]

On Mon, Aug 07, 2017 at 10:28:07PM +0200, Petter Reinholdtsen wrote:
> In addition to removing the line, it might be an idea to remove the
> setup the line was refering to, ie
> /usr/share/debian-edu/thin-client/share/config/kcmartsrc.
> It seem to be no longer needed.
 
Thanks, also dropped now.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#870796: [tex-live] segfault on build-testing luatex

[Norbert Preining]

> > Related to gcc-7.1?
> > http://tug.org/pipermail/tex-live/2017-June/040192.html
> 
> Ahh, sounds reasonable ... will try tomorrow, time for bed.

Confirmed that the patch fixes it, at leasts for now.

THanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#871439: RM: golang-github-syndtr-goleveldb -- superseded source

[Michael Lustfield]

Package: ftp.debian.org

Please remove the source package "golang-github-syndtr-goleveldb" and it's
package (golang-github-syndtr-goleveldb-dev=0.0~git20170302.0.3c5717c-1) from
unstable.

The correct -5 version of this package, provided by src:golang-goleveldb, is
also currently in unstable.

Thanks!
--
Michael Lustfield


pgp_QI3Swo1ax.pgp
Description: OpenPGP digital signature

Bug#870073: [Pkg-mozext-maintainers] Bug#870073: gnome-keyring hijacking gpg-agent on jessie

[Daniel Kahn Gillmor]

Control: retitle 870073 gnome-keyring hijacks gpg-agent on jessie
Control: reassign -2 
Control: affects 870073 + enigmail
Control: clone 870073 -2
Control: reassign -2 thunderbird 1:52.2.1-4~deb8u1
Control: affects -2 enigmail
Control: retitle -2 thunderbird does not show checkboxes in menus on jessie


On Mon 2017-08-07 19:57:41 +0200, Paul van der Vlis wrote:
> I did now as root:
> dpkg-divert --local --rename --divert \
>   /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable \
>   --add /etc/xdg/autostart/gnome-keyring-gpg.desktop
>
> And I logged out and in again. Now I can use Enigmail, but it works not
> really nice. Before I could turn-on encrypting and signing using the
> menu. Now it says default "encrypt (auto)" and it's not clear if it's
> encrypting or not. If I click on it, it says "encrypt" without "(auto)"
> and then it works, but I cannot turn it off anymore using the menu. But
> maybe this is new and normal.

Are you talking about during message composition?

there is a big enigmail toolbar that should be at the top of each
composition window.  it has two buttons, one for signing, and one for
encryption.  those buttons should be very clear whether they're selected
or not.  If you don't have the toolbar, maybe its been customized away?
can you do "View | Toolbars | Enigmail Toolbar" ?

I think maybe the other report that you're making here is that the
checkboxes on thunderbird 53 menus on jessie are not visible.

I can confirm that:


I've cloned this bug to document that problem and bring it to the
attention of the thunderbird devs.

> So I think what other people with this probleme have to do is:
> -
> echo "use-agent" >> ~/.gnupg/gpg.conf
>
> sudo dpkg-divert --local --rename --divert \
>   /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable \
>   --add /etc/xdg/autostart/gnome-keyring-gpg.desktop
>
> logout and login again.
> -

That sounds plausible.  i could even consider shipping the
dpkg-diversion in the jessie version of enigmail, if the gnome-keyring
maintainers are OK with it.  (or they could ship an update in jessie
that disables it too)

But really, users should be encouraged to upgrade to stretch :)

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#858911: thunderbird: Apparmor prevents opening links from emails in firefox.

[intrigeri]

Hi!

intrigeri:
> Michael Biebl:
>> Afaics, thunderbird uses x-www-browser by default, which can point at
>> arbitrary browsers. I also tried with epiphany-browser and chromium.
>> None of those worked either.

> Thanks for checking. I'll have a look and ensure all major browsers
> work fine for this use case.

Reproduced the problem with Chromium after setting it as the default
browser in GNOME Control Center ⇒ fix submitted upstream, applied
locally, will be in apparmor 2.11.0-9 that I'll upload shortly.

But I can't reproduce the problem with epiphany-browser: I've tried
selecting "Web" as the default browser in GNOME Control Center, and
pointing the x-www-browser alternative to /usr/bin/epiphany-browser,
and links open just fine from Thunderbird ⇒ Michael, can you please
submit a dedicated bug report (against the apparmor package) about
this issue, attaching whatever the Journal says about AppArmor?

Cheers,
-- 
intrigeri

Bug#871437: Please ship a .pc file in the libsnappy-dev package

[Robert Edmonds]

Package: libsnappy-dev
Version: 1.1.6-2
Severity: wishlist

Hi,

Please ship a .pc file in the libsnappy-dev package.

It looks like snappy 1.1.6 ships both an autotools and CMake build
system, but the Debian package now uses the CMake build system, which
doesn't support installing a .pc file. However, there is an upstream
pull request to re-add .pc support to the CMake build system:
https://github.com/google/snappy/pull/51.

Thanks!

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libsnappy-dev depends on:
ii  libsnappy1v5  1.1.6-2

libsnappy-dev recommends no packages.

libsnappy-dev suggests no packages.

-- no debconf information

-- 
Robert Edmonds
edmo...@debian.org

Bug#868224:

[Boyan Penkov]

Hey folks,

Please disregard my message -- my issue had nothing to do with the
observation made above.

FWIF, I had an mdadm array fail to mount, and the mdadm --detail
--scan (hooked on by initramfs) was locking up.  After some faffing
around, are a restart, the array came up, and the kernel install did
not hang.

Cheers!
-- 
Boyan Penkov

Bug#871436: uhub: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: uhub
Version: 0.4.1-3.1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
uhub-0.4.1/src/network/openssl.c:
|ssize_t net_con_ssl_handshake(struct net_connection* con, enum 
net_con_ssl_mode ssl_mode, struct ssl_context_handle* ssl_ctx)
|{
|…
| if (ssl_mode == net_con_ssl_mode_server)
| {
|…
| else
| {
| handle->ssl = SSL_new(SSL_CTX_new(TLSv1_method()));
| SSL_set_fd(handle->ssl, con->sd);
| handle->bio = SSL_get_rbio(handle->ssl);
|  

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#871435: sofia-sip: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: sofia-sip
Version: 1.12.11+20110422.1-2.1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
sofia-sip-1.12.11+20110422.1/libsofia-sip-ua/stun/stun.c
| static
| int stun_tls_callback(su_root_magic_t *m, su_wait_t *w, su_wakeup_arg_t *arg)
| {
|…
|   state = sd->sd_state;
|   switch (state) {
|   case stun_tls_connecting:
| 
|…
| /* openssl initiation */
| SSLeay_add_ssl_algorithms();
| SSL_load_error_strings();
| ctx = SSL_CTX_new(TLSv1_client_method());
| self->sh_ctx = ctx;
| 
| if (ctx == NULL) {
|   STUN_ERROR(errno, SSL_CTX_new);
|   stun_free_buffer(_req->enc_buf);
|   return -1;
| }
 
An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#871434: rdesktop: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: rdesktop
Version: 1.8.3-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
rdesktop-1.8.3/tcp.c:
| /* Establish a SSL/TLS 1.0 connection */
| RD_BOOL
| tcp_tls_connect(void)
| {
|…
| if (g_ssl_ctx == NULL)
| {
| g_ssl_ctx = SSL_CTX_new(TLSv1_client_method());
| if (g_ssl_ctx == NULL)
| {
| error("tcp_tls_connect: SSL_CTX_new() failed to 
create TLS v1.0 context\n");
| goto fail;
| }

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#868224:

[Boyan Penkov]

Hey folks,

I see the same thing -- what's the best way to help?

Cheers!

-- 
Boyan Penkov

Bug#871433: poco: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: poco
Version: 1.7.6+dfsg1-5
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
poco-1.7.8+dfsg1/NetSSL_OpenSSL/src/Context.cpp:
| void Context::createSSLContext()
| {
| if (SSLManager::isFIPSEnabled())
| {
| _pSSLContext = SSL_CTX_new(TLSv1_method());
| }
| else
| {

the else path looks okay but the FIPS enabled mode looks non-working.

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#871206: libxmlbird: FTBFS: make[1]: doit3: Command not found

[Hideki Yamane]

Hi,

On Sun, 6 Aug 2017 18:37:52 -0400
Lucas Nussbaum  wrote:
> Source: libxmlbird
(snip)
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> > doit3
> > make[1]: doit3: Command not found

 It was introduced changes in doit (0.30.3-1), just "doit" is okay for now.
 Unfortunately, I cannot upload packages until back to home after DebConf17,
 so this is just a note.


-- 
Hideki Yamane 

Bug#871431: libexosip2: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: libexosip2
Version: 4.1.0-2.1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
libexosip2-4.1.0/src/eXtl_tls.c:
|initialize_client_ctx (struct eXosip_t * excontext, const char 
*certif_client_local_cn_name, eXosip_tls_ctx_t * client_ctx, int transport)
| {
|…
|  if (transport == IPPROTO_UDP) {
| #if !(OPENSSL_VERSION_NUMBER < 0x00908000L)
| meth = DTLSv1_client_method ();
| #endif
|   }
|   else if (transport == IPPROTO_TCP) {
| meth = TLSv1_client_method ();
|   }
|   else {
| return NULL;
|   }
|…
| SSL_CTX *
| initialize_server_ctx (struct eXosip_t * excontext, const char 
*certif_local_cn_name, eXosip_tls_ctx_t * srv_ctx, int transport)
| {
|…
|   if (transport == IPPROTO_UDP) {
| OSIP_TRACE (osip_trace (__FILE__, __LINE__, OSIP_INFO3, NULL, "DTLS-UDP 
server method\n"));
| #if !(OPENSSL_VERSION_NUMBER < 0x00908000L)
| meth = DTLSv1_server_method ();
| #endif
|   }
|   else if (transport == IPPROTO_TCP) {
| OSIP_TRACE (osip_trace (__FILE__, __LINE__, OSIP_INFO3, NULL, "TLS server 
method\n"));
| meth = TLSv1_server_method ();
|   }
|   else {
| return NULL;
|   }

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#871432: nmh: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: nmh
Version: 1.6-16
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
nmh-1.6/mts/smtp/smtp.c:
| static int
| tls_negotiate(void)
| {
| …
| if (! sslctx) {
| const SSL_METHOD *method;
| 
| SSL_library_init();
| SSL_load_error_strings();
| 
| method = TLSv1_client_method(); /* Not sure about this */
| 
| /* Older ssl takes a non-const arg. */
| sslctx = SSL_CTX_new((SSL_METHOD *) method);
| 
| if (! sslctx) {
| sm_end(NOTOK);
| return sm_ierror("Unable to initialize OpenSSL context: %s",
|  ERR_error_string(ERR_get_error(), NULL));
| }
| }

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Samuel Thibault]

Axel Beckert, on lun. 07 août 2017 23:53:39 +0200, wrote:
> Hi Samuel,
> 
> Samuel Thibault wrote:
> > Axel Beckert, on lun. 07 août 2017 22:43:00 +0200, wrote:
> > > Debian Bug Tracking System wrote:
> > > > > retitle 852224 ITA: gpm -- General Purpose Mouse interface
> > > > Bug #852224 [wnpp] O: gpm -- General Purpose Mouse interface
> > > > Changed Bug title to 'ITA: gpm -- General Purpose Mouse interface' from 
> > > > 'O: gpm -- General Purpose Mouse interface'.
> > > 
> > > Do you intent to maintain the package under the Debian A11Y Team?
> > 
> > Not really, I just happen to use it :)
> 
> But
> https://anonscm.debian.org/git/collab-maint/gpm.git/tree/debian/control
> looks differently. :-)

Ah :)

I guess that was mostly a habit.

> Shall I keep the Debian A11Y team in there (I'm a member there, too,
> so I wouldn't mind) or shall I change it to just you and me?

I'd say just you and me.  I'm not aware of real a11y use.

Samuel

Bug#871430: elog: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: elog
Version: 3.1.3-1-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
elog-3.1.3-1/src/elog.c:
| int ssl_connect(int sock, SSL ** ssl_con)
| {
|…
|meth = (SSL_METHOD *) TLSv1_method();
|ctx = SSL_CTX_new(meth);
|
|*ssl_con = SSL_new(ctx);

elog-3.1.3-1/src/elogd.c:
| int ssl_connect(int sock, SSL ** ssl_con)
| {
|…
|   SSL_library_init();
|SSL_load_error_strings();
|
|meth = (SSL_METHOD *) TLSv1_method();
|ctx = SSL_CTX_new(meth);
|
|…
| SSL_CTX *init_ssl(void)
| {
|…
|meth = (SSL_METHOD *) TLSv1_method();
|ctx = SSL_CTX_new(meth);
|…

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Axel Beckert]

Hi Samuel,

Samuel Thibault wrote:
> Axel Beckert, on lun. 07 août 2017 22:43:00 +0200, wrote:
> > Debian Bug Tracking System wrote:
> > > > retitle 852224 ITA: gpm -- General Purpose Mouse interface
> > > Bug #852224 [wnpp] O: gpm -- General Purpose Mouse interface
> > > Changed Bug title to 'ITA: gpm -- General Purpose Mouse interface' from 
> > > 'O: gpm -- General Purpose Mouse interface'.
> > 
> > Do you intent to maintain the package under the Debian A11Y Team?
> 
> Not really, I just happen to use it :)

But
https://anonscm.debian.org/git/collab-maint/gpm.git/tree/debian/control
looks differently. :-)

Shall I keep the Debian A11Y team in there (I'm a member there, too,
so I wouldn't mind) or shall I change it to just you and me?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#871429: dma: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: dma
Version: 0.11-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
dma-0.11/crypto.c:
| smtp_init_crypto(int fd, int feature)
| {
|…
| SSL_library_init();
| SSL_load_error_strings();
| 
| meth = TLSv1_client_method();
| 
| ctx = SSL_CTX_new(meth);

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#871428: dcap: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: dcap
Version: 2.47.10-3
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
dcap-2.47.10/plugins/ssl/sslTunnel.c:
| int eInit(int fd)
| {
|…
| ssl_ctx = SSL_CTX_new(TLSv1_client_method());
| ssl_con = (SSL *) SSL_new(ssl_ctx);
|

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Axel Beckert]

Hi Samuel,

Samuel Thibault wrote:
> > Well, sounds familiar, hence I'd really prefer not to maintain
> > additional packages alone. Would it be ok to list you as
> > co-maintainer? [...]
>
> Ok for me :)

Great, will do.

> > I'd open up a gbp-compatible git repo on collab-maint.

Actually you already created a repo there about 1.5 months ago. Will
be using that. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#871427: argyll: please switch to SSLv23_… or TLS_…_method

[Sebastian Andrzej Siewior]

Package: argyll
Version: 1.9.2+repack-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: TLS1.0_1.1_removal

Your packages uses a function which requests a TLS1.0 and/or TLS1.1 only
connection. Since openssl 1.1.0f-4 (currently in unstable) this means
won't work because it provides TLS1.2. See also [0].
Please switch to
SSLv23_method() | SSLv23_server_method() | SSLv23_client_method()

or the recommended openssl 1.1+ functions:
TLS_method() | TLS_server_method() | TLS_client_method()

as per man-page [1].
The code I identified and probably needs to be replaced:
argyll-1.9.2+repack/ccast/ccpacket.c
| // Want to use TLS_client_method(), but older OpenSSL doesn't have 
it...
| if ((p->ctx = SSL_CTX_new(TLSv1_client_method())) == NULL)

An example for replacing a TLSv1 only connection with any possible
version would look like this:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+  ctx = SSL_CTX_new(SSLv23_client_method());

If you want to use the openssl 1.1 function you need extra version
checks:

-  ctx = SSL_CTX_new(TLSv1_client_method());
+#if (OPENSSL_VERSION_NUMBER >= 0x1010L) && \
+!defined(LIBRESSL_VERSION_NUMBER)  && !defined(OPENSSL_IS_BORINGSSL)
+ctx = SSL_CTX_new (TLS_client_method ());
+#else
+ctx = SSL_CTX_new (SSLv23_client_method ());
+#endif

Note that that openssl is usually configured (at build time) to not
allow SSLv2 and SSLv3 connections. However if upstream wants to be sure
to have it disable you can add this:

+#ifdef OPENSSL_NO_SSL3
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
+#endif
+
+#ifdef OPENSSL_NO_SSL2
+SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
+#endif

to make sure it is not used for a connection even if the currently
install libssl library is supporting it.

[0] 
https://lists.debian.org/msgid-search/20170807014238.mf64rdvgpdkpa...@roeckx.be
[1] https://manpages.debian.org/stretch/libssl-doc/SSLv23_method.3ssl.en.html

Sebastian

Bug#871426: mutagen: build-depends on python3.5-doc

[Michael Hudson-Doyle]

Source: mutagen
Severity: normal
User: debian-pyt...@lists.debian.org
Usertags: python3.6

Dear Maintainer,

mutagen build depends on python3.5-doc which is obviously going to interfere
with removing it from the archive once python3.6 becomes the default. The fix
looks to be trivial.

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (400, 'xenial-proposed'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-87-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#792319: jsmath-fonts: please make the build reproducible

[Chris Lamb]

tags 792319 + pending patch
thanks

I've uploaded jsmath-fonts 1.3-3.1 to DELAYED/15:
  
  jsmath-fonts (1.3-3.1) unstable; urgency=medium
  
* Non-maintainer upload.
* Make the build reproducible. (Closes: #792319)

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diffstat for jsmath-fonts-1.3 jsmath-fonts-1.3

 changelog |7 +++
 rules |2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff -Nru jsmath-fonts-1.3/debian/changelog jsmath-fonts-1.3/debian/changelog
--- jsmath-fonts-1.3/debian/changelog   2014-03-23 15:56:56.0 -0400
+++ jsmath-fonts-1.3/debian/changelog   2017-08-07 17:41:37.0 -0400
@@ -1,3 +1,10 @@
+jsmath-fonts (1.3-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make the build reproducible. (Closes: #792319)
+
+ -- Chris Lamb   Mon, 07 Aug 2017 17:41:37 -0400
+
 jsmath-fonts (1.3-3) unstable; urgency=medium
 
   * Adopted the package. Closes: #621473
diff -Nru jsmath-fonts-1.3/debian/rules jsmath-fonts-1.3/debian/rules
--- jsmath-fonts-1.3/debian/rules   2014-03-23 15:56:56.0 -0400
+++ jsmath-fonts-1.3/debian/rules   2017-08-07 17:41:37.0 -0400
@@ -16,7 +16,7 @@
dh $@
 
 override_dh_auto_build:
-   unzip -q jsMath-*.zip
+   TZ=UTC unzip -q jsMath-*.zip
 
 override_dh_clean:
dh_clean

Bug#868248: RFS: dcm2niix/1.0.20170624-1

[Ghislain Vaillant]

On Sat, 05 Aug 2017 18:16:27 +0300 Al Nikolov  wrote:

Hi Ghislain.

Please see [1] for an RFS bug template.

[1]https://mentors.debian.net/sponsor/rfs-howto


I have been contributing to Debian long-enough to get to know the RFS 
how-to. Thanks for the reminder anyway.



What is still missing in your report, is the link to the published
package itself you want to be sponsored.


You mean the tip of the packaging repository tagged with the Debian 
version matching the title of the RFS?



It should lead essentially to the `.dsc` file (m.d.n lists them
automatically if you upload there). Mentioning "it can be build with
gdb" is not enough and cloning Git repository in order to simply build
a package is a nuisance. Both put unnecessary restrictions on the
sponsorship process.


Funny you should say that, this advice to provide the link to the 
packaging repository was given to me by past sponsors. I have got months 
of past RFS processed that way.


In fact, you'd probably have to use the packaging repository to verify 
that the uploaded .dsc matches the tip of the packaging repository. So, 
one might as well just let the sponsor generate the .dsc himself, which 
is just one `gbp buildpackage -d -S` away.


Regards,
Ghis

Bug#871371: singularity-container: FTBFS: help2man: can't get `--version' info from /tmp/tmp.YU5T8oOc4W/run-singularity

[Lucas Nussbaum]

Hi,

On 07/08/17 at 14:32 -0400, Yaroslav Halchenko wrote:
> severity 871371 important
> tags 871371 + unreproducible
> thanks
> 
> Ran rebuild which succeeded just fine on up to date sid for both amd64
> and i386 (binary only)
> 
> Would need to be able to reproduce to figure out WTF

I could reproduce it using sbuild (on a different setup).

The root cause is that you use help2man to generate manpages, but
help2man expects both --help and --version to work. And
'run-singularity --version' doesn't work:
$ run-singularity --version
ERROR: Unknown option: --version

That shows in the manpage for run-singularity, that contains garbage as
version number (see man run-singularity | tail -1). This garbage comes
from a call to tput to colorize the error message.

For some reason, this triggers a build failure in sbuild, but not when I
run debian/generate_manpages manually. help2man does some magic with the
output of 'command --version', which I did not fully understand due to
my limited perl-fu. The relevant code is:

# Call program with given option and return results.
sub get_option_value
{
my ($prog, $opt) = @_;
my $stderr = $discard_stderr ? '/dev/null' : '&1';
my $value = join '',
map { s/ +$//; expand $_ }
map { dec $_ }
`$prog $opt 2>$stderr`;

unless ($value)
{
my $err = N_("%s: can't get `%s' info from %s%s");
my $extra = $discard_stderr
? "\n" . N_("Try `--no-discard-stderr' if option outputs to stderr")
: '';

kark $err, $this_program, $opt, $prog, $extra;
}

$value;
}

- Lucas

Bug#871424: w3m can not be used in unwritable $HOME

[Osamu Aoki]

Package: w3m
Version: 0.5.3-34
Severity: normal

Dear Maintainer,

http://aws-logs.debian.net/2017/08/05/maint-guide_1.2.39_unstable.log

Here, w3m is choking when $HOME is not writable.

If unwritable, this should move on without choking.

This is very annoying to get packahe build under some chroot test for
reproducible build.


-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages w3m depends on:
ii  libc6  2.24-11+deb9u1
ii  libgc1c2   1:7.4.2-8
ii  libgpm21.20.4-6.2+b1
ii  libssl1.1  1.1.0f-3
ii  libtinfo5  6.0+20161126-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages w3m recommends:
ii  ca-certificates  20161130+nmu1

Versions of packages w3m suggests:
pn  cmigemo   
ii  curl  7.52.1-5
pn  dict  
pn  dict-wn   
pn  dictd 
pn  libsixel-bin  
ii  man-db2.7.6.1-2
ii  mime-support  3.60
pn  mpv   
pn  w3m-el
pn  w3m-img   
ii  wget  1.18-5
ii  xdg-utils 1.1.1-1
pn  xsel  

-- no debconf information

Bug#838171: duck: detect SourceForge pages for sqlitebrowser as redirects

[Simon Kainz]

Hi,

as duck is using lynx -dump at it's core to get website text contents,
javascript won't never be visible/detectable to duck.
OTOH, the current text on the website contains text which is already
detected ad pointig to a new site, thanks to your regex pattern updates.

So i am closing this bug.

Thanks & bye,

Simon


On Sun, 18 Sep 2016 10:06:39 +0800 Paul Wise  wrote:
> Package: duck
> Version: 0.10
> Severity: wishlist
> 
> These two pages are detected as OK by DUCK but both should be detected
> as not OK because they have text and JavaScript pointing elsewhere.
> I've included some suggested phrases for the detection below:
> 
> http://sqlitebrowser.sourceforge.net/
> 
> window.location =  
> Redirecting to
> We've moved
> Redirecting now
> our new website
> 
> https://sourceforge.net/projects/sqlitebrowser/
> 
> WE'VE MOVED
> MOVED TO
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-debug
>   APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
> 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
> 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages duck depends on:
> ii  devscripts   2.16.7
> ii  dpkg-dev 1.18.10
> ii  libconfig-inifiles-perl  2.89-1
> ii  libconfig-simple-perl4.59-6
> ii  libdomain-publicsuffix-perl  0.14.1-1
> ii  libfile-which-perl   1.21-1
> ii  libmailtools-perl2.13-1
> ii  libnet-dns-perl  1.06-1
> ii  libparse-debcontrol-perl 2.005-4
> ii  libpath-class-perl   0.37-1
> ii  libregexp-common-email-address-perl  1.01-4
> ii  libregexp-common-perl2016060801-1
> ii  libstring-similarity-perl1.04-1+b3
> ii  libwww-curl-perl 4.17-2+b1
> ii  libxml-xpath-perl1.37-1
> ii  libyaml-libyaml-perl 0.63-1
> ii  lynx 2.8.9dev9-1
> ii  perl 5.22.2-5
> ii  publicsuffix 20160805-1
> 
> duck recommends no packages.
> 
> Versions of packages duck suggests:
> ii  bzr 2.7.0+bzr6619-1
> ii  git 1:2.9.3-1
> ii  mercurial   3.9.1-1
> ii  subversion  1.9.4-3

Bug#867214: [git-buildpackage/master] import_orig: use a more gittish commit message

[Guido Günther]

tag 867214 pending
thanks

Date:   Mon Aug 7 18:19:09 2017 -0300
Author: Guido Günther 
Commit ID: f208a0bcba865672838fe34c9a84bac4f4764a4c
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=f208a0bcba865672838fe34c9a84bac4f4764a4c
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=f208a0bcba865672838fe34c9a84bac4f4764a4c

import_orig: use a more gittish commit message

When replacing the debian/ dir don't used past tense and
keep the subject more like git-merge.

Closes: #867214

  

Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse

[Daniel Kahn Gillmor]

On Mon 2017-08-07 09:40:22 -0700, Russ Allbery wrote:
> In an ideal world, we would have a documented set of metadata for finding
> upstream releases, of which uscan is just one implementation, and document
> that in Policy.

In an ideal world, uscan would be able to verify signed git tags and
include the diff between the orig.tar.gz and a shallow clone of the git
repo as a patch to allow verification without history ;)

> This patch doesn't attempt to do that; it tries to find a compromise
> between the current Policy language ("include a watch file for uscan")
> and specifying the location of the upstream signing keys, while
> deferring all of the details to the uscan documentation.

i think this is a sensible approach.  thanks for working on it, Russ.

> +If the upstream maintainer of the software provides PGP signatures

This should probably be s/PGP/OpenPGP/

all the rest looks good to me.  I'm also happy to second it, if needed.

--dkg


signature.asc
Description: PGP signature

Bug#859172: me too + some analysis

[dann frazier]

tags 859172 - unreproducible
thanks

Telegram attempts to load libappindicator3 as a plugin (which is why
dpkg-shlibdeps doesn't pick it up). If it fails, telegram tries to
revert to using GTK's indicator API - and this is where we are
crashing. I suspect that's a bug with upstream and, until it is
addressed, Debian just needs to add an explicit dependency on
libappindicator3-1. Even if the upstream bug weren't there, the
dependency may even be a good idea just so the behavior is consistent
for all users.

This is very easy to reproduce on Debian, so I've taken the liberty of
dropping the unreproducible tag.

(gdb) 
#0  0x7f991eaf337c in gdk_display_open ()
at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#1  0x7f991eac2fb2 in gdk_display_open_default_libgtk_only ()
at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#2  0x7f991ee89232 in gtk_init_check ()
at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#3  0x009b8cd99ca7 in setupGtkBase (lib_gtk=...)
at ./Telegram/SourceFiles/platform/linux/linux_libs.cpp:126
#4  0x009b8cd9fef1 in Platform::Libs::start() ()
at ./Telegram/SourceFiles/platform/linux/linux_libs.cpp:255
#5  0x009b8cdebc79 in Platform::ThirdParty::start() ()
at ./Telegram/SourceFiles/platform/linux/specific_linux.cpp:406
#6  0x009b8cbc7623 in ThirdParty::start() ()
at ./Telegram/SourceFiles/core/utils.cpp:261
#7  0x009b8d1313b0 in Messenger::Messenger() (this=0x9b8ec3bff0)
at ./Telegram/SourceFiles/messenger.cpp:87
#8  0x009b8cf95727 in make_unique ()
at /usr/include/c++/7/bits/unique_ptr.h:825
#9  0x009b8cf95727 in Application::createMessenger() (this=0x7ffd2fa72b50)
at ./Telegram/SourceFiles/application.cpp:316
#10 0x009b8cf95a90 in Sandbox::launch() ()
at ./Telegram/SourceFiles/application.cpp:654
#11 0x009b8cf95c39 in Application::singleInstanceChecked() 
(this=this@entry=0x7ffd2fa72b50) at ./Telegram/SourceFiles/application.cpp:217
#12 0x009b8cf95e78 in 
Application::socketError(QLocalSocket::LocalSocketError) (this=0x7ffd2fa72b50, 
e=)
at ./Telegram/SourceFiles/application.cpp:196
#13 0x7f9944e9fe51 in QMetaObject::activate(QObject*, int, int, void**) ()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x7f994898b6e1 in QLocalSocket::error(QLocalSocket::LocalSocketError) 
() at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#15 0x7f9948992d07 in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#16 0x7f994899357f in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#17 0x7f994899377a in 
QLocalSocket::connectToServer(QFlags) () at 
/usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#18 0x009b8cf96381 in Application::Application(int&, char**) 
(this=0x7ffd2fa72b50, argc=, argv=)
at ./Telegram/SourceFiles/application.cpp:107
#19 0x009b8ca8282b in main (argc=, argv=0x7ffd2fa72cb8)
at ./Telegram/SourceFiles/main.cpp:49
(gdb) 
#0  0x7f991eaf337c in gdk_display_open ()
at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#1  0x7f991eac2fb2 in gdk_display_open_default_libgtk_only ()
at /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#2  0x7f991ee89232 in gtk_init_check ()
at /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#3  0x009b8cd99ca7 in setupGtkBase (lib_gtk=...)
at ./Telegram/SourceFiles/platform/linux/linux_libs.cpp:126
#4  0x009b8cd9fef1 in Platform::Libs::start() ()
at ./Telegram/SourceFiles/platform/linux/linux_libs.cpp:255
#5  0x009b8cdebc79 in Platform::ThirdParty::start() ()
at ./Telegram/SourceFiles/platform/linux/specific_linux.cpp:406
#6  0x009b8cbc7623 in ThirdParty::start() ()
at ./Telegram/SourceFiles/core/utils.cpp:261
#7  0x009b8d1313b0 in Messenger::Messenger() (this=0x9b8ec3bff0)
at ./Telegram/SourceFiles/messenger.cpp:87
#8  0x009b8cf95727 in make_unique ()
at /usr/include/c++/7/bits/unique_ptr.h:825
#9  0x009b8cf95727 in Application::createMessenger() (this=0x7ffd2fa72b50)
at ./Telegram/SourceFiles/application.cpp:316
#10 0x009b8cf95a90 in Sandbox::launch() ()
at ./Telegram/SourceFiles/application.cpp:654
#11 0x009b8cf95c39 in Application::singleInstanceChecked() 
(this=this@entry=0x7ffd2fa72b50) at ./Telegram/SourceFiles/application.cpp:217
#12 0x009b8cf95e78 in 
Application::socketError(QLocalSocket::LocalSocketError) (this=0x7ffd2fa72b50, 
e=)
at ./Telegram/SourceFiles/application.cpp:196
#13 0x7f9944e9fe51 in QMetaObject::activate(QObject*, int, int, void**) ()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x7f994898b6e1 in QLocalSocket::error(QLocalSocket::LocalSocketError) 
() at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#15 0x7f9948992d07 in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#16 0x7f994899357f in  () at /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#17 0x7f994899377a in 
QLocalSocket::connectToServer(QFlags) () at 
/usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#18 0x009b8cf96381 in 

Bug#871055: RFP: gr-gsm -- Gnuradio blocks and tools for receiving GSM transmissions

[Petter Reinholdtsen]

Control: retitle -1 ITP: gr-gsm -- Gnuradio blocks and tools for receiving GSM 
transmissions
Control: owner -1 !

I've secured help from the gnuradio maintainer, and plan to upload
gr-gsm to Debian soon, under the debian-hams umbrella.

-- 
Happy hacking
Petter Reinholdtsen

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

[Bernhard Schmidt]

Control: tags -1 + pending

On Thu, Aug 03, 2017 at 11:21:28AM +0200, Bernhard Schmidt wrote:

> stretch-pu filed as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870604

Accepted into p-u, will be part of Debian 9.2 and should be available
shortly on https://www.debian.org/releases/proposed-updates.en.html

Best Regards,
Bernhard

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Axel Beckert]

Hi Samuel,

Samuel Thibault wrote:
> > I'm also interested in a properly maintained gpm in Debian and would
> > join you as second co-maintainer. (And I have a good contact to
> > upstream.)
> 
> I'd say please feel free to take it, as my upload latency shows, I'm
> already too busy with packages :)

Well, sounds familiar, hence I'd really prefer not to maintain
additional packages alone. Would it be ok to list you as
co-maintainer? I'd open up a gbp-compatible git repo on collab-maint.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#871300: [Pkg-gmagick-im-team] Bug#871300: libmagick++-6.q16-7: requires rebuild against GCC 7 and symbols/shlibs bump

[James Cowgill]

Hi,

On 07/08/17 16:55, roucaries bastien wrote:
> On Mon, Aug 7, 2017 at 4:47 PM,   wrote:
>> Package: libmagick++-6.q16-7
>> Version: 8:6.9.7.4+dfsg-16
>> Severity: serious
>> Tags: sid buster
>> User: debian-...@lists.debian.org
>> Usertags: gcc-7-op-mangling
>>
> 
> I need a change that break ABI, I will release a new version. Does it
> exist in this case a short cut

If you are going to rename the Debian package and trigger a package
transition, you do not need to add any of the extra symbols/shlibs
stuff. You should still build-depend on gcc (>= 4:7) however - I'm not
sure if all the buildds use GCC 7 by default yet.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#725202: release.debian.org: want a tool like d for binary packages

[Adam D. Barratt]

On Wed, 2013-10-02 at 19:46 +0100, Adam D. Barratt wrote:
> On Wed, 2013-10-02 at 20:35 +0200, Julien Cristau wrote:
> > I keep wishing I could easily debdiff the binary packages built by a
> > given source between testing and sid (on a given arch, or on all, I'm
> > not completely sure).
> 
> Implementing this in a reusable manner (e.g. in debrelease.debdiff)
> would simplify the implementation of #655976 in queue-viewer.

debrelease.debbindiff should be usable as a base for such a tool now.

Cheers,

Adam

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Samuel Thibault]

Axel Beckert, on lun. 07 août 2017 22:59:21 +0200, wrote:
> Samuel Thibault wrote:
> > > I'm also interested in a properly maintained gpm in Debian and would
> > > join you as second co-maintainer. (And I have a good contact to
> > > upstream.)
> > 
> > I'd say please feel free to take it, as my upload latency shows, I'm
> > already too busy with packages :)
> 
> Well, sounds familiar, hence I'd really prefer not to maintain
> additional packages alone. Would it be ok to list you as
> co-maintainer? I'd open up a gbp-compatible git repo on collab-maint.

Ok for me :)

Samuel

Bug#871423: libconfig-model-dpkg-perl: Update extra priority to optional priority if Standards-Version is on 4.0.1

[Salvatore Bonaccorso]

Package: libconfig-model-dpkg-perl
Version: 2.096
Severity: wishlist

If the Standards-Version is already on 4.0.1 at least, when fixing
debian/control (dpkg-control) the values of

Priority: extra

should be fixed up/migrated to

Priority: optional

This would be inline to the upgrading-checklist for 4.0.1:

   2.5

   Priorities are now used only for controlling which packages are
   part of a minimal or standard Debian installation and should be
   selected based on functionality provided directly to users (so
   nearly all shared libraries should have a priority of optional).
   Packages may now depend on packages with a lower priority.

   The extra priority has been deprecated and should be treated as
   equivalent to optional. All extra priorities should be changed to
   optional. Packages with a priority of optional may conflict with
   each other (but packages that both have a priority of standard or
   higher still may not conflict).

Salvatore

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Samuel Thibault]

Hello,

Axel Beckert, on lun. 07 août 2017 22:43:00 +0200, wrote:
> Debian Bug Tracking System wrote:
> > > retitle 852224 ITA: gpm -- General Purpose Mouse interface
> > Bug #852224 [wnpp] O: gpm -- General Purpose Mouse interface
> > Changed Bug title to 'ITA: gpm -- General Purpose Mouse interface' from 'O: 
> > gpm -- General Purpose Mouse interface'.
> 
> Do you intent to maintain the package under the Debian A11Y Team?

Not really, I just happen to use it :)

> I'm also interested in a properly maintained gpm in Debian and would
> join you as second co-maintainer. (And I have a good contact to
> upstream.)

I'd say please feel free to take it, as my upload latency shows, I'm
already too busy with packages :)

Samuel

Bug#871418: [Pkg-azure-team] Bug#871418: azure-cli: new upstream release

[Iain R. Learmonth]

Hi,

On 08/07/2017 09:17 PM, Chris Lamb wrote:

azure-cli is severely outdated; fancy packaging the latest version
and/or filing for RM?


Planning to update shortly, but need to sort out the dependencies first.

Thanks,
Iain.

Bug#852224: Processed: retitle 852224 to ITA: gpm -- General Purpose Mouse interface

[Axel Beckert]

Hi Samuel,

Debian Bug Tracking System wrote:
> > retitle 852224 ITA: gpm -- General Purpose Mouse interface
> Bug #852224 [wnpp] O: gpm -- General Purpose Mouse interface
> Changed Bug title to 'ITA: gpm -- General Purpose Mouse interface' from 'O: 
> gpm -- General Purpose Mouse interface'.

Do you intent to maintain the package under the Debian A11Y Team? I'm
also interested in a properly maintained gpm in Debian and would join
you as second co-maintainer. (And I have a good contact to upstream.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#871422: libconfig-model-dpkg-perl: cleanup old Breaks/Replaces

[gregor herrmann]

Package: libconfig-model-dpkg-perl
Version: 2.096
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

cme is very good at removing version constraints in dependencies and
build dependencies when no older version is in the archive anymore.

It would be nice if it also could detect and warn about or remove
Breaks/Replaces against old packages/packages versions which are not
relevant anymore.

Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlmI0FVfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgabjxAAsOdw+6O9yj0GSDjA6WlGk7KzzhJ1/A7wHAGGW/zOlSoW1phAjgQfMvUX
hO/9GM4fss/VLqpqURCJyBhmj5Q/H59xGf7FFbzFGWOLYiL6p7N/rVGLt9/L9qDB
/nFDv3kJvZSNr4VIUATS0lLqfyR2a+K+8DLGqY83SMYqZE9Yq36dr7DMzSOTHcih
FWFWEiwX2A24oTVlfZ1h8+umyQWGUAn1/gVHud16zyjmpFRgeOjgarqnur6SqAw1
QkuisWVMWXOz6UxFTG6y/+M3W1Qf29ZyeC36R0dXNCcCFPV6Sb9srpvknD71veI5
5AM7ENkpsjyVaJg5uZl1Z9hjyUmcNOZFb9uK5pgXEswtGqHhNle9Wn2VJrRgLYYW
AJsargjtV2g96FCpkDJAquowHDLfDcc59IB4puVx/ZoBl3RzA0mGq+un3619BXae
GA1MOjAO2qXzrufj6Keio8dkbsYhkg9JjjbquYfdi4NJSg4Ho/IAon7b4+/p5YJw
ERdLfA/pQHrVaWDUjA5qiSciPFd476BL+FEA1kYFjCwfi+BE7eV/MkJpBZw/ImXC
2CEg7v+w0VrELBdOko3gtZqyA78ScutmSJEOSR60hfIJAltFI4EQkZiBnFOGs0+8
Yb/8h3BIZCD6Uz7SHS/3Yd9YnkSHzxLw7VtZuyodzhmicAbvXq0=
=C8VG
-END PGP SIGNATURE-

Bug#871421: RFP: tcpproxy -- a simple tcp connection proxy that supports ipv6

[Sebastian Schweizer]

Package: wnpp
Severity: wishlist

"tcpproxy is a simple tcp connection proxy which combines the features
of rinetd and 6tunnel. tcpproxy supports IPv4 and IPv6 and also supports
connections from IPv6 to IPv4 endpoints and vice versa."

Since rinetd does not support IPv6 I was looking for alternatives and
found this software.

URL: https://spreadspace.org/tcpproxy/

The man page can be accessed here:
https://www.gsp.com/cgi-bin/man.cgi?section=8=tcpproxy

tcpproxy has been available as an official openwrt package since June
2014, so it should be very mature by now.

Bug#870874: support sound on ltsp clients with pulseaudio

[Petter Reinholdtsen]

[Wolfgang Schweer]
> (2) remove the line containing ESPEAKER in 
> /etc/desktop-profiles/debian-edu-config.listing

In addition to removing the line, it might be an idea to remove the
setup the line was refering to, ie
/usr/share/debian-edu/thin-client/share/config/kcmartsrc.

It seem to be no longer needed.

-- 
Happy hacking
Petter Reinholdtsen

Bug#735134: perl: rename(1) is ancient

[Niko Tyni]

Update: here's a related IRC discussion from today prompted by #870472.

Apologies for the lack of wrapping.

21:52 < ntyni> Dom: did you see #870472 ? can't recall if dropping prename was 
intentional or not
21:52 -zwiebelbot:#debian-perl- Debian#870472: rename: Please provide 'prename' 
as well as 'rename' - https://bugs.debian.org/870472
21:53 < ntyni> seems like a problem if we want to drop the src:perl version for 
buster
22:43 < Dom> hmm, seems I need to revive my old memories for this one
22:48 < Dom> isn't the problem there that the alternatives have gone wrong?
22:49 < Dom> huh, no
22:49 < Dom> there is no alternative for prename
22:49 < Dom> this is all wrong
22:49 < ntyni> right, I think we forgot about it
22:50  * Dom reads https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735134
22:50 -zwiebelbot:#debian-perl- Debian#735134: perl: rename(1) is ancient - 
https://bugs.debian.org/735134
22:53 < Dom> prename must have been issuing that warning for ages, right?
22:54 < Dom> "Additionally, if you are currently using 'prename', please
22:54 < Dom> use 'rename' (which is handled by the alternatives mechanism) or
22:54 < Dom> file-rename, which is the new implementation."
22:54 < ntyni> 5.24.1~rc3-1 I guess
22:54 < Dom> that is what was sent to maintainres
22:54 < Dom> so I think the current situation is correct, and the new 
bugreporter must be misrembering the advice to start using prename
22:54 < Dom> (or that advice was much older advice)
22:55 < ntyni> I suspect the latter
22:56 < Dom> We could turn prename into an alternative too, it's just work
22:56 < Dom> not sure if it's worth it or not
22:56 < Dom> and would delay us another release, Ithink
22:57 < ntyni> yes, that was my main worry
22:58 < ntyni> no strong opinion on whether we should do it or not
22:59 < Dom> I think given it's been like this for around a year before someone 
notice (or at least filed a bug), I'd prefer to stick to our 
previously-announced course, and finally close #735134
23:01 < ntyni> do you mean removing /usr/bin/prename altogether, or moving it 
in the rename package now without an overlapping transition period?
23:02 < Dom> I mean removing prename altogehter
23:03 < Dom> which is after all what the deprecation warning says will happen
23:03 < Dom> oh hang on, the deprecation message also says that the rename 
package will provide 'the same command'
23:03 < Dom> ugh
23:03 < ntyni> yes, was just about to point that out
23:04 < Dom> is moving it to the rename package without alternatives good 
enough?
23:05 < ntyni> I suppose yes
23:05 < Dom> I guess it would need a simultaneous upload
23:05 < ntyni> but I think I'd like a test rebuild + bugs
23:06 < ntyni> yes on simultaneousness (if that is a word)
23:06 < Dom> simultaneity
23:06 < ntyni> thanks
23:08 < ntyni> I think rename would need to Replace perl (<< something) for the 
overwriting, and Depend on perl perl (>= something) so that installing and then 
removing rename on an older perl will not lose prename prematurely
23:09 < Dom> yeah.
23:09 < Dom> Or we could just repeat the recipe we already played out for the 
rename command
23:10 < Dom> *headdesk* so frustrating
23:10 < Dom> and so trivial
23:10 < ntyni> indeed
23:12 < ntyni> the alternatives were needed because we wanted the 
/usr/bin/rename versions to be coinstallable
23:12 < ntyni> if we don't want that for /usr/bin/prename I guess we can do 
without alternatives
23:12 < ntyni> and we only want it if we want to keep prename for another 
release
23:13 < Dom> oh, I remember now
23:13 < Dom> we harnessed an already-existing alternative for rename that has 
been in perl since 2005
23:13 < Dom> I think your plan is better
23:13 < ntyni> right; /usr/bin/rename was historically an alternative with a 
brief coexistence in util-linux
23:13 < Dom> with Replaces:
23:21 < ntyni> Dom: ok with me copy-pasting this discussion to #735134 so we 
don't forget?
23:21 -zwiebelbot:#debian-perl- Debian#735134: perl: rename(1) is ancient - 
https://bugs.debian.org/735134
23:22 < Dom> sure.

-- 
Niko Tyni   nt...@debian.org

Bug#858911: thunderbird: Apparmor prevents opening links from emails in firefox.

[intrigeri]

Michael Biebl:
> Afaics, thunderbird uses x-www-browser by default, which can point at
> arbitrary browsers. I also tried with epiphany-browser and chromium.
> None of those worked either.

Thanks for checking. I'll have a look and ensure all major browsers
work fine for this use case.

Cheers,
-- 
intrigeri

Bug#871420: dpkg(1) manpage path-exclude docs possible license issue

[Adam Heath]

package: dpkg
version: 1.17.27

In the manpage for dpkg, there is an example for path-exclude/path-include:

==
--path-exclude=/usr/share/doc/*
--path-include=/usr/share/doc/*/copyright
==

These 2 patterns will end up skipping packages that have
/usr/share/doc/$foo as a symlink to another package.  Which means
things like perl-base, libstdc++6, libgcc1, etc, which have their docs
symlinked to another package from the same source, will be broken, as
the copyright for the package is not available at
/usr/share/doc/$pkg/copyright, as *required* by policy.

Perhaps --path-exclude=/usr/share/doc/*/*, with the same include,
might be better.

Bug#871419: crawl FTCBFS: make[2]: *** contrib: No such file or directory. Stop.

[Helmut Grohne]

Source: crawl
Version: 2:0.20.1-1
User: helm...@debian.org
Usertags: rebootstrap

crawl fails to cross build from source for wicked reasons. I tried to
figure it out, but now I give up and write down what I have. The first
attempt to build ends with:

| * Need to build contribs: zlib lua/src sqlite
| make[2]: Entering directory '/<>/build-console/source'
| make[2]: *** contrib: No such file or directory.  Stop.
| make[2]: Leaving directory '/<>/build-console/source'
| Makefile:1574: recipe for target '.contrib-libs' failed
| make[1]: *** [.contrib-libs] Error 2
| make[1]: Leaving directory '/<>/build-console/source'
| debian/rules:61: recipe for target 'build-stamp' failed
| make: *** [build-stamp] Error 2
| dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

It turns out that this is due to simple typo in source/Makefile. In the
"ifdef CROSSHOST" branch, it tries to check for pkg-config and does so
with "$($shell which ...)". The extra $ makes the test fail and causes
crawl to assume that pkg-config is unavailable. It then tries to build
lua, sqlite3 and zlib. s/\$shell/shell/ fixes this part.

Then crawl no longer tries to build lua and zlib, but still tries to
build sqlite3. For cross compilation it forces SQLITE_INCLUDE_DIR to
"/usr/$(ARCH)/include" and notes that this may be wrong. It then tries
to find "$(SQLITE_INCLUDE_DIR)/sqlite3.h and concludes absence of
sqlite3. An easy workaround is to pass SQLITE_INCLUDE_DIR=/usr/include
from debian/rules.

Now crawl builds for a while and fails in source/rltiles. Maybe someone
figures out how to continue from here.

Can you fix the "$shell" typo and SQLITE_INCLUDE_DIR nonetheless?

Helmut

Bug#871418: azure-cli: new upstream release

[Chris Lamb]

Package: azure-cli
Version: 0.1.0~b7-1
Severity: wishlist

Hi,

azure-cli is severely outdated; fancy packaging the latest version
and/or filing for RM?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#871417: azure-cli: debian/watch file broken

[Chris Lamb]

Package: azure-cli
Version: 0.1.0~b7-1
Severity: normal

uscan info: uscan (version 2.17.9) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="azure-cli" version="0.1.0~b7-1" (as seen in 
debian/changelog)
uscan info: package="azure-cli" version="0.1.0~b7" (no epoch/revision)
uscan info: ./debian/changelog sets package="azure-cli" version="0.1.0~b7"
uscan info: Process ./debian/watch (package=azure-cli version=0.1.0~b7)
uscan info: opts: uversionmangle=s/(a|b|c|rc)/~$1/
uscan info: line: https://github.com/azure/azure-cli/releases 
.*/archive/all-v?(\d[\d.-abcr]+)\.(?:tar(?:\.gz|\.bz2)?|tgz)
uscan info: Parsing uversionmangle=s/(a|b|c|rc)/~$1/
uscan info: line: https://github.com/azure/azure-cli/releases 
.*/archive/all-v?(\d[\d.-abcr]+)\.(?:tar(?:\.gz|\.bz2)?|tgz)
uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.1.0~b7
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.1.0~b7
uscan info: Requesting URL:
   https://github.com/azure/azure-cli/releases
uscan info: Matching pattern:
   
(?:(?:https://github.com)?\/azure\/azure\-cli\/releases)?.*/archive/all-v?(\d[\d.-abcr]+)\.(?:tar(?:\.gz|\.bz2)?|tgz)
uscan warn: In debian/watch no matching files for watch line
  https://github.com/azure/azure-cli/releases 
.*/archive/all-v?(\d[\d.-abcr]+)\.(?:tar(?:\.gz|\.bz2)?|tgz)
uscan info: Scan finished

(ie. "no matching files for watch line")


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#871416: libcxxtools-dev: Please provide pkg-config .pc files for cxxtools

[Kunal Mehta]

Package: libcxxtools-dev
Version: 2.2.1-2
Severity: wishlist

Dear Maintainer,

Please provide the pkg-config .pc files for cxxtools that are
included in the upstream tarball.

I noticed that this was implemented in the git repository[1],
but never uploaded to the archive. This is currently preventing
the unittests of libzim from running[2] since pkg-config thinks
that cxxtools-unit isn't installed.


[1] 
https://anonscm.debian.org/cgit/collab-maint/cxxtools.git/commit/?h=debian=36219f04742e7cd6ed7beed3a07ae31e05a1d17a
[2] https://github.com/openzim/libzim

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.11-300.fc26.x86_64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcxxtools-dev depends on:
ii  libcxxtools9v5   2.2.1-2
ii  libstdc++-5-dev [libstdc++-dev]  5.4.1-11
ii  libstdc++-6-dev [libstdc++-dev]  6.4.0-3
ii  libstdc++-7-dev [libstdc++-dev]  7.1.0-12

libcxxtools-dev recommends no packages.

libcxxtools-dev suggests no packages.

-- no debconf information

Bug#869986: [Debian-ha-maintainers] Bug#869986: Bug#869986: pacemaker FTBFS: missing symbols

[Valentin Vidic]

On Mon, Aug 07, 2017 at 02:31:57PM -0400, Ferenc Wágner wrote:
> There's no problem with the Pacemaker libs, the "missing" symbols are a
> manifestation of the binutils incompatibility in the libqb headers.

Ok, didn't realize the pacemaker FTBFS was caused by the libqb problem.
Even better, than we only have one nasty bug to squash :)

-- 
Valentin

Bug#868337: jessie-pu: package hexchat/2.10.1-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-08-06 at 15:55 +0100, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Fri, Jul 14, 2017 at 05:31:47PM +0200, Mattia Rizzolo wrote:
> > I'd like to fix https://bugs.debian.org/779892 also in jessie.
> > It's a somewhat hard to trig segfault, caused by a debian-only patch
> > missing braces.
> > 
> > https://sources.debian.net/src/hexchat/2.10.1-1%2Bdeb8u1/debian/patches/debian_defaults.patch/
> > You can see here how the patch adds a second statement that it is meant
> > to be within the `if`, but that if is without braces, so havoc befalls.
> > 
> > Proposed patch, tested on jessie, attached.
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#869414: package smplayer/16.11.0~ds0-1+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2017-08-06 at 23:26 +0200, Gianfranco Costamagna wrote:
> On Sun, 6 Aug 2017 13:40:28 +0100 Jonathan Wiltshire  wrote:
> > Control: tag -1 confirmed
> 
> uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#870604: stretch-pu: package openvpn/2.4.0-6+deb9u2

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2017-08-07 at 00:03 +0200, Bernhard Schmidt wrote:
> On 06.08.2017 14:05, Jonathan Wiltshire wrote:
> 
> Hi,
> 
> > Control: tag -1 confirmed
> > 
> > On Thu, Aug 03, 2017 at 11:14:04AM +0200, Bernhard Schmidt wrote:
> >> I'd like to fix RC bug #863110 in Stretch, causing OpenVPN connections to 
> >> be 
> >> broken when they are reestablished after a timeout.
> >>
> >> The patch has been part of several upstream releases which have been in 
> >> sid/buster for a couple of weeks now. The submitter tested the patch to be
> >> fixing this issue.
> >>
> >> diff attached
> > 
> > Please go ahead.
> 
> Uploaded and accepted.

Flagged for acceptance into p-u.

Regards,

Adam

Bug#864028: stretch-pu: package flatpak 0.8.7-1~deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

On Mon, 2017-07-31 at 09:49 +0100, Simon McVittie wrote:
> On Sun, 30 Jul 2017 at 22:59:15 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Thu, 2017-07-27 at 07:28 +0100, Simon McVittie wrote:
> > > 
> > > Filtered diff (patched tree in security vs. what I propose) in
> > > https://lists.debian.org/debian-release/2017/07/msg00555.html aka
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864028#57 aka
> > > Message-ID: 
> > > <20170715163609.nemdxrefaeird...@perpetual.pseudorandom.co.uk>.
> > > Notes on the differences and what I filtered are in the same mail.
> > > 
> > > I would also be happy to add the equivalent of
> > > https://anonscm.debian.org/git/collab-maint/flatpak.git/diff/?id=debian/0.8.7-2=debian/0.8.7-1
> > > to make this flatpak compatible with buster's libostree, if the SRMs
> > > would be OK with that; that would turn it into 0.8.7-2~deb9u1. The
> > > relevant commits will be in upstream release 0.8.8 eventually.
> > 
> > That sounds okay to me. Sorry for the delay in getting back to you.
> 
> I've assumed you meant "yes, please also include the 0.8.7-2
> changes" (i.e. compatibility with buster's libostree), and uploaded
> 0.8.7-2~deb9u1. If that was wrong, please reject it and I'll go for
> 0.8.7-1~deb9u1. I tested against stretch's libostree on a stretch system
> to make sure it works correctly with both.

I did indeed mean that, thanks.

Flagged for acceptance into p-u.

Regards,

Adam

Bug#865971: stable-pu: package tbdialout/1.7.2-2

[Adam D. Barratt]

Control: tags -1 + pending

On Sat, 2017-07-15 at 11:52 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2017-06-27 at 05:05 +0200, Cyril Brulebois wrote:
> > Daniel Pocock  (2017-06-26):
> > > Thanks for the feedback, I've made those changes now too
> > > 
> > > Regards,
> > > 
> > > Daniel
> > 
> > > diff -Nru tbdialout-1.7.2/debian/changelog 
> > > tbdialout-1.7.2/debian/changelog
> > > --- tbdialout-1.7.2/debian/changelog  2014-05-02 18:58:02.0 
> > > +0200
> > > +++ tbdialout-1.7.2/debian/changelog  2017-06-26 08:51:10.0 
> > > +0200
> > > @@ -1,3 +1,12 @@
> > > +tbdialout (1.7.2-1+deb9u1) stretch; urgency=medium
> > > +
> > > +  * Include leading plus symbol with tel: URI scheme.  (Closes: #865961)
> > > +  * Remove Dm-Upload-Allowed.
> > > +  * Add missing detalls to debian/copyright
> > > +  * Update watch file.
> > > +
> > > + -- Daniel Pocock   Mon, 26 Jun 2017 08:51:10 +0200
> > 
> > While the tel:/+ fix and copyright update look reasonable for stable,
> > I'm much less convinced by the DMUA/watch update in stable. DMUA isn't
> > much relevant since SRMs have the final say on what gets into stretch,
> > and packaging a new upstream release usually happens from unstable…
> > (And I'd assume tracker.debian.org and friends use metadata from
> > unstable and/or experimental.)
> 
> They're irrelevant but I wouldn't insist on them not being included if
> an uploader really wants to.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#707275: Ansible causes noise in server logs

[Lee]

(resent as I forgot to send it to the submitter)

Hi Carlos,

I'm closing this bug as wontfix. The reason is that upstream has little
motivation of changing the behaviour, and there is a workaround available
(filtering out those message via syslog).

Regards,
Lee

Bug#869938: Raising severity to serious since g-s-d 3.24 has been uploaded to unstable

[Robert Luberda]

severity 869938 important
thanks

> I have the package ready, I will upload it shortly.

I'm lowering the severity so that the package won't migrate to testing
too early.

Regards,
robert

Bug#858911: thunderbird: Apparmor prevents opening links from emails in firefox.

[Michael Biebl]

Am 07.08.2017 um 18:56 schrieb intrigeri:
> Control: reassign -1 apparmor
> Control: retitle -1 ubuntu-browsers abstraction lacks support for non-ESR 
> Firefox
> Control: affects -1 + thunderbird
> 
> Hi!
> 
> intrigeri:
>> I'll start playing with Flatpak to reproduce this.
> 
> After investigating this bug has nothing to do with Flatpak (this was
> a good opportunity to try it out though! :) 
> 
> I can't reproduce this bug when Firefox ESR is configured as the
> default browser. I can reproduce the bug when Firefox is.

Fwiw, I have firefox installed, not firefox-esr, which I guess confirms
your theory.

Afaics, thunderbird uses x-www-browser by default, which can point at
arbitrary browsers. I also tried with epiphany-browser and chromium.
None of those worked either.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature