Bug#828787: ITP: libdisorder -- library for entropy measurement of byte streams and other data

[Andreas Tille]

Great. Thanks a lot for all commits, Andreas.

On Tue, Jun 28, 2016 at 12:08:59AM +0200, Guus Sliepen wrote:
> On Mon, Jun 27, 2016 at 11:25:12PM +0200, Andreas Tille wrote:
> 
> > > I hope you will fix this description. I'd only keep the last paragraph,
> > 
> > Done.
> > 
> > > and then also explain what algorithm it actually uses to measure the
> [...]
> > I'd be happy if you would commit a fix to Git (its writable to any DD)
> > since you obviously know more about this than me.
> 
> Done.
> 
> > > I also want to point out that this library is not thread-safe, something
> > > which could easily be fixed.
> > 
> > A patch would be reall welcome.
> 
> Done.
> 
> > > It also gives the wrong answer when you
> > > have an input with more than 2^31-1 of the same bytes in the input, even
> > > though it pretends to handle inputs up to 2^63 in length.
> > 
> > I think this information should be in README.Debian.  What do you think?
> 
> I think that would belong in a bugreport sent upstream. But I have also
> committed a patch.
> 
> -- 
> Met vriendelijke groet / with kind regards,
>   Guus Sliepen 



-- 
http://fam-tille.de

Bug#784213: libarchive: crash or infinite loop via malformed cpio archive

[Petter Reinholdtsen]

According to https://bugzilla.redhat.com/show_bug.cgi?id=1216891 >
this is the same issue as
https://github.com/libarchive/libarchive/issues/503 > which was
assigned CVE-2015-8915.

-- 
Happy hacking
Petter Reinholdtsen

Bug#828306: [debian-mysql] Bug#828306: galera-3: FTBFS with openssl 1.1.0

[Otto Kekäläinen]

I have forwarded this upstream at https://github.com/codership/galera/issues/407

Upstream thinks this is a generic libasio-dev / openssl issue, in
which case you'll have a lot of software breaking.

Bug#790502: Please support ARM64

[Jeremy Bicha]

On Ubuntu, the package also builds on
arm64 ppc64el

https://launchpad.net/ubuntu/+source/hyperestraier/1.4.13-14ubuntu1

Thanks,
Jeremy Bicha

Bug#828818: linux-image-amd64: Debian don't recognize battery on Acer aspire switch 10

[carlos]

Package: linux-image-amd64
Version: 4.5+73
Severity: important

Dear Maintainer,

In Windows 10 no problems but Debian can't recognize it

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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.5.0-2-amd64  4.5.4-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#828817: firmware-realtek: Need support for Realtek Wifi card rtl8723bs

[carlix]

Package: firmware-realtek
Version: 20160110-1
Severity: important

Dear Maintainer,

This device is appearing in some OEM machines, but driver is not yet available 
upstream.
I have found this https://github.com/hadess/rtl8723bs thats works perfect but 
this must be by default.

WORKAROUND: sudo apt-get install build-essential linux-headers-generic git
git clone https://github.com/hadess/rtl8723as.git
cd rtl8723as
make
sudo make install
sudo depmod -a
sudo modprobe r8723bs

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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.125

-- no debconf information

Bug#825701: should osptoolkit be removed from Debian?

['Mattia Rizzolo']

On Tue, Jun 28, 2016 at 09:30:34AM +0800, Di-Shi Sun wrote:
> The upstream source is repackaged and uploaded to mentors.debian.net. Would
> you please review it?

I can see how you just removed that copyright header.
But now I want to know why that copyright header was there in the first
place.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#828816: ruby-rspec-puppet: FTBFS: split should run split("foo") and raise an ArgumentError with the message matching /mis-matched arguments/

[Chris Lamb]

Source: ruby-rspec-puppet
Version: 2.2.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ruby-rspec-puppet fails to build from source in unstable/amd64:

  [..]

  Selecting previously unselected package libdns162:amd64.
  Preparing to unpack .../libdns162_1%3a9.10.3.dfsg.P4-10_amd64.deb ...
  Unpacking libdns162:amd64 (1:9.10.3.dfsg.P4-10) ...
  Selecting previously unselected package libisccc140:amd64.
  Preparing to unpack .../libisccc140_1%3a9.10.3.dfsg.P4-10_amd64.deb ...
  Unpacking libisccc140:amd64 (1:9.10.3.dfsg.P4-10) ...
  Selecting previously unselected package libisccfg140:amd64.
  Preparing to unpack .../libisccfg140_1%3a9.10.3.dfsg.P4-10_amd64.deb ...
  Unpacking libisccfg140:amd64 (1:9.10.3.dfsg.P4-10) ...
  Selecting previously unselected package libbind9-140:amd64.
  Preparing to unpack .../libbind9-140_1%3a9.10.3.dfsg.P4-10_amd64.deb ...
  Unpacking libbind9-140:amd64 (1:9.10.3.dfsg.P4-10) ...
  Selecting previously unselected package liblwres141:amd64.
  Preparing to unpack .../liblwres141_1%3a9.10.3.dfsg.P4-10_amd64.deb ...
  Unpacking liblwres141:amd64 (1:9.10.3.dfsg.P4-10) ...
  Selecting previously unselected package bind9-host.
  Preparing to unpack .../bind9-host_1%3a9.10.3.dfsg.P4-10_amd64.deb ...
  Unpacking bind9-host (1:9.10.3.dfsg.P4-10) ...
  Selecting previously unselected package net-tools.
  Preparing to unpack .../net-tools_1.60+git20150829.73cef8a-2_amd64.deb ...
  Unpacking net-tools (1.60+git20150829.73cef8a-2) ...
  Selecting previously unselected package ruby-json.
  Preparing to unpack .../ruby-json_1.8.3-1+b3_amd64.deb ...
  Unpacking ruby-json (1.8.3-1+b3) ...
  Selecting previously unselected package facter.
  Preparing to unpack .../facter_2.4.6-1_all.deb ...
  Unpacking facter (2.4.6-1) ...
  Selecting previously unselected package augeas-lenses.
  Preparing to unpack .../augeas-lenses_1.2.0-0.3_all.deb ...
  Unpacking augeas-lenses (1.2.0-0.3) ...
  Selecting previously unselected package libaugeas0.
  Preparing to unpack .../libaugeas0_1.2.0-0.3_amd64.deb ...
  Unpacking libaugeas0 (1.2.0-0.3) ...
  Selecting previously unselected package ruby-augeas.
  Preparing to unpack .../ruby-augeas_1%3a0.5.0-3+b4_amd64.deb ...
  Unpacking ruby-augeas (1:0.5.0-3+b4) ...
  Selecting previously unselected package ruby-deep-merge.
  Preparing to unpack .../ruby-deep-merge_1.0.1+gitf9df6fdb-1_all.deb ...
  Unpacking ruby-deep-merge (1.0.1+gitf9df6fdb-1) ...
  Selecting previously unselected package hiera.
  Preparing to unpack .../archives/hiera_2.0.0-2_all.deb ...
  Unpacking hiera (2.0.0-2) ...
  Selecting previously unselected package libxslt1.1:amd64.
  Preparing to unpack .../libxslt1.1_1.1.28-4_amd64.deb ...
  Unpacking libxslt1.1:amd64 (1.1.28-4) ...
  Selecting previously unselected package ruby-nokogiri.
  Preparing to unpack .../ruby-nokogiri_1.6.7.2-3_amd64.deb ...
  Unpacking ruby-nokogiri (1.6.7.2-3) ...
  Selecting previously unselected package ruby-rgen.
  Preparing to unpack .../ruby-rgen_0.8.0-1_all.deb ...
  Unpacking ruby-rgen (0.8.0-1) ...
  Selecting previously unselected package ruby-safe-yaml.
  Preparing to unpack .../ruby-safe-yaml_1.0.4-1_all.deb ...
  Unpacking ruby-safe-yaml (1.0.4-1) ...
  Selecting previously unselected package ruby-shadow.
  Preparing to unpack .../ruby-shadow_2.4.1-1+b3_amd64.deb ...
  Unpacking ruby-shadow (2.4.1-1+b3) ...
  Selecting previously unselected package puppet.
  Preparing to unpack .../puppet_4.5.2-1_all.deb ...
  Unpacking puppet (4.5.2-1) ...
  Selecting previously unselected package puppet-common.
  Preparing to unpack .../puppet-common_4.5.2-1_all.deb ...
  Unpacking puppet-common (4.5.2-1) ...
  Selecting previously unselected package ruby-diff-lcs.
  Preparing to unpack .../ruby-diff-lcs_1.2.5-2_all.deb ...
  Unpacking ruby-diff-lcs (1.2.5-2) ...
  Selecting previously unselected package ruby-rspec-support.
  Preparing to unpack .../ruby-rspec-support_3.4.0c3e0m1s1-1_all.deb ...
  Unpacking ruby-rspec-support (3.4.0c3e0m1s1-1) ...
  Selecting previously unselected package ruby-rspec-expectations.
  Preparing to unpack .../ruby-rspec-expectations_3.4.0c3e0m1s1-1_all.deb ...
  Unpacking ruby-rspec-expectations (3.4.0c3e0m1s1-1) ...
  Selecting previously unselected package ruby-rspec-mocks.
  Preparing to unpack .../ruby-rspec-mocks_3.4.0c3e0m1s1-1_all.deb ...
  Unpacking ruby-rspec-mocks (3.4.0c3e0m1s1-1) ...
  Selecting previously unselected package ruby-thread-order.
  Preparing to unpack .../ruby-thread-order_1.1.0-1_all.deb ...
  Unpacking ruby-thread-order (1.1.0-1) ...
  Selecting previously unselected package ruby-rspec-core.
  Preparing to unpack .../ruby-rspec-core_3.4.0c3e0m1s1-1_all.deb ...
  Unpacking ruby-rspec-core (3.4.0c3e0m1s1-1) ...
  Selecting previously unselected package ruby-rspec.
  Preparing to unpack .../ruby-rspec_3.4.0c3e0m1s1

Bug#828815: pyvows: FTBFS: Expected strings to be equal, but they were different

[Chris Lamb]

Source: pyvows
Version: 2.0.6-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

pyvows fails to build from source in unstable/amd64:

  [..]

  
  
**
  ** Starting build 
  **
  
**
  
   Package:  pyvows
   Version:  2.0.6-2
   Build architecture:   amd64
   Date: Tue, 28 Jun 2016 07:44:25 +0200
   Hostname: 5d4680d1283e
   Uname:Linux 5d4680d1283e 4.5.0-2-amd64 #1 SMP Debian 4.5.4-1 
(2016-05-16) x86_64 GNU/Linux
   /etc/timezone:Africa/Johannesburg
  
  
**
  ** Installing build dependencies  
  **
  
**
  
  dh_testdir
  dh_testroot
  dh_prep
  dh_testdir
  dh_testroot
  dh_install
  dh_installdocs
  dh_installchangelogs
  dh_compress
  dh_fixperms
  dh_installdeb
  dh_gencontrol
  dh_md5sums
  dh_builddeb
  dpkg-deb: building package 'pyvows-build-deps' in 
'../pyvows-build-deps_2.0.6-2_all.deb'.
  
  The package has been created.
  Attention, the package has been created in the current directory,
  not in ".." as indicated by the message above!
  Selecting previously unselected package pyvows-build-deps.
  (Reading database ... 23073 files and directories currently installed.)
  Preparing to unpack pyvows-build-deps_2.0.6-2_all.deb ...
  Unpacking pyvows-build-deps (2.0.6-2) ...
  Reading package lists...
  Building dependency tree...
  Reading state information...
  Correcting dependencies... Done
  The following additional packages will be installed:
help2man python-all python-colorama python-coverage python-gevent
python-greenlet python-preggy python-setuptools python-unidecode
  Suggested packages:
python-gevent-doc python-gevent-dbg python-openssl python-greenlet-doc
python-greenlet-dev python-greenlet-dbg python-setuptools-doc
  Recommended packages:
libjs-jquery-hotkeys libjs-jquery-isonscreen libjs-jquery-tablesorter
libjs-jquery
  The following NEW packages will be installed:
help2man python-all python-colorama python-coverage python-gevent
python-greenlet python-preggy python-setuptools python-unidecode
  0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
  1 not fully installed or removed.
  Need to get 1011 kB of archives.
  After this operation, 3956 kB of additional disk space will be used.
  Get:1 http://httpredir.debian.org/debian sid/main amd64 python-setuptools all 
20.10.1-1.1 [203 kB]
  Get:2 http://httpredir.debian.org/debian sid/main amd64 python-all amd64 
2.7.11-2 [938 B]
  Get:3 http://httpredir.debian.org/debian sid/main amd64 python-colorama all 
0.3.7-1 [25.7 kB]
  Get:4 http://httpredir.debian.org/debian sid/main amd64 python-coverage amd64 
4.1+dfsg.1-2 [124 kB]
  Get:5 http://httpredir.debian.org/debian sid/main amd64 python-greenlet amd64 
0.4.9-2+b1 [19.2 kB]
  Get:6 http://httpredir.debian.org/debian sid/main amd64 python-gevent amd64 
1.1.1-1 [340 kB]
  Get:7 http://httpredir.debian.org/debian sid/main amd64 python-unidecode all 
0.04.19-1 [122 kB]
  Get:8 http://httpredir.debian.org/debian sid/main amd64 python-preggy all 
1.3.0-1 [15.4 kB]
  Get:9 http://httpredir.debian.org/debian sid/main amd64 help2man amd64 1.47.4 
[162 kB]
  Fetched 1011 kB in 0s (2297 kB/s)
  Selecting previously unselected package python-setuptools.
  (Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 23077 files and directories currently installed.)
  Preparing to unpack .../python-setuptools_20.10.1-1.1_all.deb ...
  Unpacking python-setuptools (20.10.1-1.1) ...
  Selecting previously unselected package python-all.
  Preparing to unpack .../python-all_2.7.11-2_amd64.deb ...
  Unpacking python-all (2.7.11-2) ...
  Selecting previously unselected package python-colorama.
  Preparing to unpack .../python-colorama_0.3.7-1_all.deb ...
  Unpacking python-colorama (0.3.7-1) ...
  Selecting previously unselected package python-coverage.
  Preparing to unpack .../python-coverage_4.1+

Bug#814944: [debian-mysql] Bug#814944: mariadb-connect-engine-10.0: ODBC support apparently not compiled in

[Otto Kekäläinen]

Hello!

Thanks for reporting you need this. The fix has not been backported to
Jessie.

We need a good motivation which the ftp masters accept before we can push a
change to a stable release.

Bug#828813: android-platform-tools-base: FTBFS: DefaultManifestParser.java:28: error: cannot find symbol import org.apache.http.annotation.ThreadSafe;

[Chris Lamb]

Source: android-platform-tools-base
Version: 1.5.0-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

android-platform-tools-base fails to build from source in unstable/amd64:

  [..]

  Skipping task ':base:api-generator:processResources' as it has no source 
files.
  :base:api-generator:processResources UP-TO-DATE
  :base:api-generator:processResources (Thread[Daemon worker,5,main]) 
completed. Took 0.001 secs.
  :base:api-generator:classes (Thread[Daemon worker,5,main]) started.
  :base:api-generator:classes
  Skipping task ':base:api-generator:classes' as it has no actions.
  :base:api-generator:classes (Thread[Daemon worker,5,main]) completed. Took 
0.0 secs.
  :base:api-generator:jar (Thread[Daemon worker,5,main]) started.
  :base:api-generator:jar
  Executing task ':base:api-generator:jar' (up-to-date check took 0.001 secs) 
due to:
No history is available.
  :base:api-generator:jar (Thread[Daemon worker,5,main]) completed. Took 0.008 
secs.
  :base:api-generator:startScripts (Thread[Daemon worker,5,main]) started.
  :base:api-generator:startScripts
  Executing task ':base:api-generator:startScripts' (up-to-date check took 0.01 
secs) due to:
No history is available.
  :base:api-generator:startScripts (Thread[Daemon worker,5,main]) completed. 
Took 0.319 secs.
  :base:api-generator:distTar (Thread[Daemon worker,5,main]) started.
  :base:api-generator:distTar
  Executing task ':base:api-generator:distTar' (up-to-date check took 0.003 
secs) due to:
No history is available.
  :base:api-generator:distTar (Thread[Daemon worker,5,main]) completed. Took 
0.048 secs.
  :base:api-generator:distZip (Thread[Daemon worker,5,main]) started.
  :base:api-generator:distZip
  Executing task ':base:api-generator:distZip' (up-to-date check took 0.002 
secs) due to:
No history is available.
  :base:api-generator:distZip (Thread[Daemon worker,5,main]) completed. Took 
0.107 secs.
  :base:api-generator:assemble (Thread[Daemon worker,5,main]) started.
  :base:api-generator:assemble
  Skipping task ':base:api-generator:assemble' as it has no actions.
  :base:api-generator:assemble (Thread[Daemon worker,5,main]) completed. Took 
0.0 secs.
  :base:archquery:compileJava (Thread[Daemon worker,5,main]) started.
  :base:archquery:compileJava
  Executing task ':base:archquery:compileJava' (up-to-date check took 0.002 
secs) due to:
No history is available.
  All input files are considered out-of-date for incremental task 
':base:archquery:compileJava'.
  Compiling with JDK Java compiler API.
  :base:archquery:compileJava (Thread[Daemon worker,5,main]) completed. Took 
0.025 secs.
  :base:archquery:processResources (Thread[Daemon worker,5,main]) started.
  :base:archquery:processResources
  file or directory 
'/home/lamby/temp/cdt.20160628073853.AR0UPtDuuU.android-platform-tools-base/android-platform-tools-base-1.5.0/base/legacy/archquery/src/main/resources',
 not found
  Skipping task ':base:archquery:processResources' as it has no source files.
  :base:archquery:processResources UP-TO-DATE
  :base:archquery:processResources (Thread[Daemon worker,5,main]) completed. 
Took 0.001 secs.
  :base:archquery:classes (Thread[Daemon worker,5,main]) started.
  :base:archquery:classes
  Skipping task ':base:archquery:classes' as it has no actions.
  :base:archquery:classes (Thread[Daemon worker,5,main]) completed. Took 0.001 
secs.
  :base:archquery:jar (Thread[Daemon worker,5,main]) started.
  :base:archquery:jar
  Executing task ':base:archquery:jar' (up-to-date check took 0.006 secs) due 
to:
No history is available.
  :base:archquery:jar (Thread[Daemon worker,5,main]) completed. Took 0.011 secs.
  :base:archquery:assemble (Thread[Daemon worker,5,main]) started.
  :base:archquery:assemble
  Skipping task ':base:archquery:assemble' as it has no actions.
  :base:archquery:assemble (Thread[Daemon worker,5,main]) completed. Took 0.0 
secs.
  :base:asset-studio:compileJava (Thread[Daemon worker,5,main]) started.
  :base:asset-studio:compileJava
  Executing task ':base:asset-studio:compileJava' (up-to-date check took 0.037 
secs) due to:
No history is available.
  All input files are considered out-of-date for incremental task 
':base:asset-studio:compileJava'.
  Compiling with JDK Java compiler API.
  :base:asset-studio:compileJava (Thread[Daemon worker,5,main]) completed. Took 
0.201 secs.
  :base:asset-studio:processResources (Thread[Daemon worker,5,main]) started.
  :base:asset-studio:processResources
  file or directory 
'/home/lamby/temp/cdt.20160628073853.AR0UPtDuuU.android-platform-tools-base/android-platform-tools-base-1.5.0/base/asset-studio/src/main/resources',
 not found
  file or directory 
'/home/lamby/temp/cdt.20160628073853.AR0UPtDuuU.android-platform-tools-base/android-platform-tools-base-1.5.0/base/asset-studio/src/main/resources',
 not found
  E

Bug#828814: grafana: FTBFS: sqlstore/sqlstore.go:96: cannot assign to x.Logger

[Chris Lamb]

Source: grafana
Version: 2.6.0+dfsg-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

grafana fails to build from source in unstable/amd64:

  [..]

  Unpacking golang-github-gosimple-slug-dev (1.0-1) ...
  Selecting previously unselected package golang-github-streadway-amqp-dev.
  Preparing to unpack 
.../golang-github-streadway-amqp-dev_0.0~git20150820.0.f4879ba-1_all.deb ...
  Unpacking golang-github-streadway-amqp-dev (0.0~git20150820.0.f4879ba-1) ...
  Selecting previously unselected package libprotobuf9v5:amd64.
  Preparing to unpack .../libprotobuf9v5_2.6.1-2_amd64.deb ...
  Unpacking libprotobuf9v5:amd64 (2.6.1-2) ...
  Selecting previously unselected package libprotoc9v5:amd64.
  Preparing to unpack .../libprotoc9v5_2.6.1-2_amd64.deb ...
  Unpacking libprotoc9v5:amd64 (2.6.1-2) ...
  Selecting previously unselected package protobuf-compiler.
  Preparing to unpack .../protobuf-compiler_2.6.1-2_amd64.deb ...
  Unpacking protobuf-compiler (2.6.1-2) ...
  Selecting previously unselected package golang-goprotobuf-dev.
  Preparing to unpack 
.../golang-goprotobuf-dev_0.0~git20160425.7cc19b7-1_amd64.deb ...
  Unpacking golang-goprotobuf-dev (0.0~git20160425.7cc19b7-1) ...
  Selecting previously unselected package golang-google-appengine-dev.
  Preparing to unpack .../golang-google-appengine-dev_0.0~git20150606-2_all.deb 
...
  Unpacking golang-google-appengine-dev (0.0~git20150606-2) ...
  Selecting previously unselected package 
golang-google-cloud-compute-metadata-dev.
  Preparing to unpack 
.../golang-google-cloud-compute-metadata-dev_0.0~git20160413-1_all.deb ...
  Unpacking golang-google-cloud-compute-metadata-dev (0.0~git20160413-1) ...
  Selecting previously unselected package golang-golang-x-oauth2-dev.
  Preparing to unpack 
.../golang-golang-x-oauth2-dev_0.0~git20160416.0.7e9cd5d-1_all.deb ...
  Unpacking golang-golang-x-oauth2-dev (0.0~git20160416.0.7e9cd5d-1) ...
  Selecting previously unselected package libuv1:amd64.
  Preparing to unpack .../libuv1_1.9.1-1_amd64.deb ...
  Unpacking libuv1:amd64 (1.9.1-1) ...
  Selecting previously unselected package nodejs.
  Preparing to unpack .../nodejs_4.4.6~dfsg-1_amd64.deb ...
  Unpacking nodejs (4.4.6~dfsg-1) ...
  Selecting previously unselected package node-typescript.
  Preparing to unpack .../node-typescript_1.8.10-1_all.deb ...
  Unpacking node-typescript (1.8.10-1) ...
  Selecting previously unselected package fonts-font-awesome.
  Preparing to unpack .../fonts-font-awesome_4.6.3~dfsg-1_all.deb ...
  Unpacking fonts-font-awesome (4.6.3~dfsg-1) ...
  Selecting previously unselected package node-less.
  Preparing to unpack .../node-less_1.6.3~dfsg-2_all.deb ...
  Unpacking node-less (1.6.3~dfsg-2) ...
  Processing triggers for man-db (2.7.5-1) ...
  Processing triggers for libc-bin (2.22-13) ...
  Setting up dh-golang (1.18) ...
  Setting up dh-systemd (1.35) ...
  Setting up golang-1.6-src (1.6.2-2) ...
  Setting up golang-1.6-go (1.6.2-2) ...
  Setting up golang-src (2:1.6.1+1) ...
  Setting up golang-go (2:1.6.1+1) ...
  Setting up golang-github-go-ini-ini-dev (1.8.6-2) ...
  Setting up golang-github-davecgh-go-spew-dev (0.0~git20151106.5215b55-1) ...
  Setting up golang-github-pmezard-go-difflib-dev (0.0~git20160110.0.792786c-2) 
...
  Setting up golang-github-stretchr-objx-dev (0.0~git20150928.0.1a9d0bb-1) ...
  Setting up golang-github-stretchr-testify-dev 
(1.1.3+git20160418.12.c5d7a69+ds-1) ...
  Setting up golang-github-jmespath-go-jmespath-dev (0.2.2-1) ...
  Setting up golang-github-shiena-ansicolor-dev (0.0~git20151119.0.a422bbe-1) 
...
  Setting up golang-github-lsegal-gucumber-dev (0.0~git20160110.0.44a4d7e-1) ...
  Setting up golang-github-jacobsa-oglematchers-dev (0.0~git20150320-1) ...
  Setting up golang-github-jtolds-gls-dev (4.2.0-1) ...
  Setting up golang-github-jacobsa-oglemock-dev (0.0~git20150428-2) ...
  Setting up golang-golang-x-text-dev (0.0~git20160606.0.a4d77b4-1) ...
  Setting up golang-x-text-dev (0.0~git20160606.0.a4d77b4-1) ...
  Setting up golang-golang-x-net-dev (1:0.0+git20160518.b3e9c8f+dfsg-2) ...
  Setting up golang-go.net-dev (1:0.0+git20160518.b3e9c8f+dfsg-2) ...
  Setting up golang-github-jacobsa-reqtrace-dev (0.0~git20150505-2) ...
  Setting up golang-github-jacobsa-ogletest-dev (0.0~git20150610-4) ...
  Setting up golang-github-smartystreets-assertions-dev (1.6.0+dfsg-1) ...
  Setting up golang-github-smartystreets-goconvey-dev (1.6.1-1) ...
  Setting up golang-github-vaughan0-go-ini-dev (0.0~git20130923.0.a98ad7e-1) ...
  Setting up libjs-jquery (1.12.4-1) ...
  Setting up libjs-jquery-ui (1.10.1+dfsg-1) ...
  Setting up golang-golang-x-tools-dev (1:0.0~git20160315.0.f42ec61-2) ...
  Setting up golang-github-aws-aws-sdk-go-dev (1.1.14+dfsg-1) ...
  Setting up golang-github-bradfitz-gomemcache-dev (0.0~git20141109-1) ...
  Setting up golang-github-b

Bug#828739: ssh-agent lost on nested ssh sessions

[Harald Dunkel]

Hi Jerome,

On 06/27/16 18:27, Jerome BENOIT wrote:
> 
> Was this issue present for former pam_ssh package ?
> 

I have this problem for Jessie (libpam-ssh version 2.01-2)
and Wheezy (version 1.92-15) as well.


Regards
Harri

Bug#828812: apt: buffer overrun in ListParser::VersionHash()

[J . T . Conklin]

Package: apt
Version: 1.0.9.8.3
Severity: important

Dear Maintainer,

I encountered a stack-smash error in apt-get caused by the contents of
the "Depends" header of one of my packages. While the crash occurred on
Ubuntu 14.04, the problem is still present in the apt sources as cloned
from git this evening.

In ListParser::VersionHash(), if a header (Depends, Pre-Depends, etc.)
value is less than 1024 bytes (sizeof(S)) in length, it is copied into
S. As each character is processed, ASCII space characters are skipped,
upper case characters are converted to lower case, and "<" & ">"
characters are converted to "<=" and ">=".

The latter conversion may result in a buffer overrun, especially if the
header value is close to 1024 bytes in length, as it increases the over-
all length of the data being copied.

I can see several ways that this problem might be addressed, including
truncating the copy at 1024 bytes, using a dynamic buffer (std::vector
or std::string), etc.

I have not submitted a patch, as I don't feel I have the context to make
the best implementation choice. That being said, I'm willing to follow
up with a patch given such guidance.

--jtc

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Never-MarkAuto-Sections:: "oldlibs";
APT::Never-MarkAuto-Sections:: "restricted/oldlibs";
APT::Never-MarkAuto-Sections:: "universe/oldlibs";
APT::Never-MarkAuto-Sections:: "multiverse/oldlibs";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "1";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "2";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-9n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "3";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-9";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "4";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "5";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-9";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt/";
Dir::State::lists "lists/";
D

Bug#828227: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2016e

[Adam D. Barratt]

Control: tags -1 + pending

On Sun, 2016-06-26 at 17:58 +0200, gregor herrmann wrote:
> On Sun, 26 Jun 2016 16:46:15 +0100, Adam D. Barratt wrote:
> 
> > On Sun, 2016-06-26 at 12:19 +0200, gregor herrmann wrote:
> > > I've prepared an update for libdatetime-timezone-perl in
> > > jessie{,-updates} to include the new data from the Olson db 2016e.
> > > This includes contemporary change for Egypt becoming effective on 7
> > > July.
> > 
> > Please go ahead.
> 
> Thank you! Uploaded.

Flagged for acceptance.

Regards,

Adam

Bug#827288: jessie-pu: package audiofile/0.3.6-2

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2016-06-17 at 22:46 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2016-06-14 at 17:37 +0100, James Cowgill wrote:
> > This update fixes CVE-2015-7747 (#801102). The security bug is marked
> > no-DSA, so the security team asked me to submit it as a normal stable
> > update.
> > 
> > The patch is copied directly from this Ubuntu bug (and is already
> > applied in Ubuntu):
> > https://bugs.launchpad.net/ubuntu/+source/audiofile/+bug/1502721
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#818219: digikam: Jasper removal

[Steve M. Robbins]

Hi Mattia,

I can take care of this.

On June 27, 2016 01:11:57 PM Mattia Rizzolo wrote:

> Since we are pretty near the removal of jasper, I intend to NMU digikam
> disabling jasper support with the attached patch.
 
> I'm currently holding off the upload as I first need to have imagemagick
> done and built on all architectures, as otherwise libjasper-dev would be
> pulled by it making my upload moot.

I have prepared an upload with a second change: to remove the 
find_package(Jasper) in cmake.   This way, even if libjasper-dev is 
accidentally present, the build won't use it.  So I can upload this change 
now.

-Steve


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

Bug#828810: fakeroot: [PATCH] Make the build reproducible

[Juan Picca]

Package: fakeroot
Version: 1.21-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that fakeroot could not be built reproducibly.

The attached patch fix the shebang shell used in fakeroot.in to /bin/sh.
Once applied, fakeroot can be built reproducibly in our current
experimental framework.

 [1]: https://wiki.debian.org/ReproducibleBuilds
diff -urNp fakeroot-1.21.orig/debian/patches/fix-shell-in-fakeroot fakeroot-1.21/debian/patches/reproducible-build
--- fakeroot-1.21.orig/debian/patches/fix-shell-in-fakeroot	1969-12-31 21:00:00.0 -0300
+++ fakeroot-1.21/debian/patches/fix-shell-in-fakeroot	2016-06-27 16:51:57.038058143 -0300
@@ -0,0 +1,13 @@
+Description: Fix shell in fakeroot.in
+ Use /bin/sh instead of @SHELL@ in fakeroot.in
+Author: Juan Picca 
+Last-Update: 2016-06-27
+---
+--- a/scripts/fakeroot.in
 b/scripts/fakeroot.in
+@@ -1,4 +1,4 @@
+-#!@SHELL@
++#!/bin/sh
+ 
+ # This script first starts faked (the daemon), and then it will run
+ # the requested program with fake root privileges.
diff -urNp fakeroot-1.21.orig/debian/patches/series fakeroot-1.21/debian/patches/series
--- fakeroot-1.21.orig/debian/patches/series	2016-06-26 19:07:15.0 -0300
+++ fakeroot-1.21/debian/patches/series	2016-06-27 16:48:01.489470826 -0300
@@ -1,2 +1,3 @@
 eglibc-fts-without-LFS
 glibc-xattr-types
+fix-shell-in-fakeroot

Bug#785280: xscreensaver not grabbing mouse

[Michał Mirosław]

On Tue, Jun 28, 2016 at 05:19:08AM +0200, Michał Mirosław wrote:
> I just tripped on this bug when launching 'xscreensaver-command -lock' from
> xmobar's label action. Locking via shell-script with 'sleep 0.1' before
> xscreensaver-command works around this problem.

Ah. The delay has to be greater than button press time. It looks like the
command is executed on ButtonPress event and not ButtonRelease. Maybe this
interacts badly with (just guessing) drag-n-drop or something?

Bug#785280: xscreensaver not grabbing mouse

[Michał Mirosław]

I just tripped on this bug when launching 'xscreensaver-command -lock' from
xmobar's label action. Locking via shell-script with 'sleep 0.1' before
xscreensaver-command works around this problem.

Bug#828700: RFS: twinkle/1.9.0+git20160520.0.be8b8df+dfsg-1 [binNEW] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

I have pushed two minor commits:

git show-ref --heads
76e884d7cc340d88924a51505521a5c6d7b7f1b3 refs/heads/master
9b3e492fbc6e923b7fddd9a320abfc8eba57eb03 refs/heads/pristine-tar
ef9654f270da62ba87a112e2a9724ca3fe5466a4 refs/heads/upstream

Peter


signature.asc
Description: PGP signature

Bug#828809: link-grammar: FTBFS on alpha: inconsistent Java treatment

[Aaron M. Ucko]

Source: link-grammar
Version: 5.3.7-1
Severity: important
Justification: fails to build from source

The alpha build of link-grammar failed because debian/control excludes
Java-related build dependencies there but still lists alpha in
liblink-grammar-java's Architecture list.  Please reconcile these
settings one way or the other.

  dh_install -pliblink-grammar-java \
usr/lib/alpha-linux-gnu/liblink-grammar-java.so* \
usr/lib/alpha-linux-gnu/jni
  dh_install: Cannot find (any matches for) "usr/share/java/*" (tried in "." 
and "debian/tmp")
  dh_install: liblink-grammar-java missing files: usr/share/java/*
  dh_install: Cannot find (any matches for) 
"usr/lib/alpha-linux-gnu/liblink-grammar-java.so*" (tried in "." and 
"debian/tmp")
  dh_install: liblink-grammar-java missing files: 
usr/lib/alpha-linux-gnu/liblink-grammar-java.so*
  dh_install: missing files, aborting
  make[1]: *** [override_dh_install] Error 2

Thanks!

Bug#828804: fcgiwrap: Build with hardening flags and cleanup debian/rules

[Peter Colberg]

Sigh, now with fixed indentation and man page path.

Nowadays dh_auto_configure passes all the needed paths to ./configure
including --mandir, so debian/patches/fix_mandir.patch is not needed.

Peter
--- a/debian/patches/fix_mandir.patch
+++ b/debian/patches/fix_mandir.patch
@@ -1,16 +0,0 @@
-Author: Jordi Mallach 
-Description: Install manpages in the FHS directory.
-Forwarded: no
-
-Index: fcgiwrap-1.1.0/Makefile.in
-===
 fcgiwrap-1.1.0.orig/Makefile.in
-+++ fcgiwrap-1.1.0/Makefile.in	2013-12-19 19:03:21.717676200 +0100
-@@ -1,6 +1,6 @@
- targetdir = $(DESTDIR)@prefix@@sbindir@
--man8dir = $(DESTDIR)@prefix@@mandir@/man8
-+man8dir = $(DESTDIR)@prefix@@datarootdir@@mandir@/man8
- datarootdir =
- 
- .PHONY:	clean distclean
- 
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,6 +1,5 @@
 GIT-Add-p-path-option-to-restrict-scripts.patch
 fix_systemd.patch
-fix_mandir.patch
 systemd_socket_requires.patch
 libsystemd.patch
 systemd_use_defaults.patch
--- a/debian/rules
+++ b/debian/rules
@@ -1,19 +1,14 @@
 #!/usr/bin/make -f
 
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+
 %:
 	dh $@ --with systemd,autoreconf
 
-CONFIGURE_FLAGS := --prefix /usr
 ifeq (linux,$(DEB_HOST_ARCH_OS))
-	CONFIGURE_FLAGS += --with-systemd \
-			   --with-systemdsystemunitdir=/lib/systemd/system
+CONFIGURE_FLAGS += --with-systemd \
+		   --with-systemdsystemunitdir=/lib/systemd/system
 endif
 
-override_dh_auto_build:
-	autoreconf -i
-	./configure $(CONFIGURE_FLAGS)
-	$(MAKE)
-
-override_dh_clean:
-	rm -f aclocal.m4
-	dh_clean
+override_dh_auto_configure:
+	dh_auto_configure -- $(CONFIGURE_FLAGS)

Bug#828808: syncthing: FTBFS: FAIL: TestGithubRelease

[Aaron M. Ucko]

Source: syncthing
Version: 0.13.4+dfsg1-1
Severity: important
Justification: fails to build from source

Builds of syncthing failed on arm64, ppc64el, and ppc64 because the
TestGithubRelease test failed:

=== RUN   TestGithubRelease
--- FAIL: TestGithubRelease (0.01s)
upgrade_test.go:83: Error retrieving latest version couldn't find a 
release to download
upgrade_test.go:86: Invalid upgrade release: v0.10.0-alpha -> v0.10.30, 
but got 
upgrade_test.go:83: Error retrieving latest version couldn't find a 
release to download
upgrade_test.go:86: Invalid upgrade release: v0.10.0-beta -> v0.10.30, 
but got 
upgrade_test.go:83: Error retrieving latest version couldn't find a 
release to download
upgrade_test.go:86: Invalid upgrade release: 
v0.11.0-beta0+40-g53cb66e-dirty -> v0.11.0-beta0, but got 
upgrade_test.go:83: Error retrieving latest version couldn't find a 
release to download
upgrade_test.go:86: Invalid upgrade release: v0.10.21 -> v0.10.30, but 
got 
upgrade_test.go:83: Error retrieving latest version couldn't find a 
release to download
upgrade_test.go:86: Invalid upgrade release: v0.10.29 -> v0.10.30, but 
got 

Could you please take a look?

Thanks!

Bug#828807: newlisp: FTBFS on powerpc: test suite segmentation fault

[Aaron M. Ucko]

Source: newlisp
Version: 10.7.0-1
Severity: important
Justification: fails to build from source

newlisp's compilation succeeded on powerpc, but the test suite
proceeded to crash:

   make check | grep '>>>'
   make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
   make[2]: *** [check] Segmentation fault

I don't have further details, but perhaps you can reproduce the
problem on a porterbox.

Could you please take a look?

Thanks!

Bug#828806: newlisp: FTBFS: explicit -m32/-m64 problematic

[Aaron M. Ucko]

Source: newlisp
Version: 10.7.0-1
Severity: important
Justification: fails to build from source

Builds of newlisp for many Linux architectures failed due to its
explicit use of -m32 or -m64.  Although these flags can be redundant
on several architectures, they're never necessary for fully native
compilation, and can cause problems on some architectures, most often
because the compiler doesn't support them there.  The x32 failure also
stems from this problem:

  gcc -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -m32 -Wall -Wno-strict-aliasing 
-Wno-long-long -c -O2 -g -DREADLINE -DSUPPORT_UTF8 -DLINUX -DFFI 
-I/usr/local/lib/libffi-3.0.13/include -g -O2 -fPIE -fstack-protector-strong 
-Wformat -Werror=format-security newlisp.c
  In file included from newlisp.c:20:0:
  newlisp.h:118:17: fatal error: ffi.h: No such file or directory

The use of here makes the compiler look for i386 versions of
architecture-dependent headers like ffi.h, which aren't normally
present there.

Please do not use these flags on any Debian architecture.

Thanks!

Bug#828805: newlisp: FTBFS on non-Linux: Could not discover your OS platform

[Aaron M. Ucko]

Source: newlisp
Version: 10.7.0-1
Severity: important
Justification: fails to build from source

Builds of newlisp on kFreeBSD and the Hurd have failed with a cascade
of errors starting with

  ./configure
  
  removing old objects and setting correct permissions ...
  discovering platform and default memory model ...
  
  Could not discover your OS platform

Please either teach it about these platforms or, if that proves
infeasible, declare

  Architecture: linux-any

Thanks!

(Many Linux builds also failed, due to other issues I'll report
separately.)

Bug#828804: fcgiwrap: Build with hardening flags and cleanup debian/rules

[Peter Colberg]

Please see the revised patch, which drops the redundant --prefix=/usr.

Peter
--- a/debian/rules
+++ b/debian/rules
@@ -1,19 +1,14 @@
 #!/usr/bin/make -f
 
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+
 %:
 	dh $@ --with systemd,autoreconf
 
-CONFIGURE_FLAGS := --prefix /usr
 ifeq (linux,$(DEB_HOST_ARCH_OS))
 	CONFIGURE_FLAGS += --with-systemd \
 			   --with-systemdsystemunitdir=/lib/systemd/system
 endif
 
-override_dh_auto_build:
-	autoreconf -i
-	./configure $(CONFIGURE_FLAGS)
-	$(MAKE)
-
-override_dh_clean:
-	rm -f aclocal.m4
-	dh_clean
+override_dh_auto_configure:
+	dh_auto_configure -- $(CONFIGURE_FLAGS)

Bug#828804: fcgiwrap: Build with hardening flags and cleanup debian/rules

[Peter Colberg]

Package: fcgiwrap
Version: 1.1.0-6
Severity: normal
Tags: patch

Dear Maintainer,

The attached patch to debian/rules ensures that fcgiwrap is built with
the hardening flags PIE and BINDNOW. Note that dh-autoreconf takes care
of invoking autoreconf and cleaning up, so no further manual action is
needed.

Regards,
Peter
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+
 %:
 	dh $@ --with systemd,autoreconf
 
@@ -9,11 +11,5 @@
 			   --with-systemdsystemunitdir=/lib/systemd/system
 endif
 
-override_dh_auto_build:
-	autoreconf -i
-	./configure $(CONFIGURE_FLAGS)
-	$(MAKE)
-
-override_dh_clean:
-	rm -f aclocal.m4
-	dh_clean
+override_dh_auto_configure:
+	dh_auto_configure -- $(CONFIGURE_FLAGS)

Bug#805711: Keyboard unresponsive

[Sean Whitton]

Hello,

On Mon, Jun 27, 2016 at 10:24:02AM +0200, Amir wrote:
> What exactly do you mean by "unresponsive"?
> 
> 
> The keyboard locks up for the X session and I cannot give my credentials to
> Light Locker.

Right, but does the mouse work in the X session?  Is it just the keyboard?

> As a side note: This problem disappears when upgrading to the Backports 
> Kernel.
> Oddly enough, even though it's a similar kernel to Debian Backports, Xubuntu
> 16.04 has 
> the same problems, which also disappears when going to kernel 4.6.

I saw the problem on kernel 4.6 so this is unlikely to be it.

-- 
Sean Whitton

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

Hello,

On Mon, Jun 27, 2016 at 05:32:32PM +0300, Dmitry Bogatov wrote:
> 2. In d/copyright, I think you need to specify copyright years for the
> copyright holders.  Just their names is not enough, since on a desert
> island ~60 years from now with no newer versions of evil available for
> download, the code would become public domain :) (well, I guess the
> old version of the code would be public domain on the mainland too)
> 
> Unfortunately, upstream maintains only list of contributors. So seems
> best thing we can do is to count 60 years from last debian upload.

I'm not sure whether this is likely to be acceptable to the ftp-masters
or not.  Perhaps someone more experienced on debian-mentors can chime
in.

> > 3. Any particular reason you are using gz and not xz compression in
> >gbp.conf?  Also, it might be a good idea to check the tarball into
> >git with pristine-tar so that a sponsor has exactly the same one (I
> >generated my own for testing).
> 
> No. Moved to xz.

I still don't see a pristine-tar branch :)

> 4. Please run the test suite.  Since it uses ERT, dh_elpa_test can run
>the tests for you, though you'll probably need to give it some hints.
>See dh_elpa_test(1) for how to do this: basically, raise to compat
>level 10 and then set DH_ELPA_TEST_* env vars.
> 
> Tests want tty on stdin. Added note and disabled tests. Any good
> ideas, how to run them in background?

It's unlikely that the tty issue is the problem: ERT tests are supposed
to be runnable in batch mode.  Although perhaps evil is different.

First, though, we need to fix your dh_elpa_test usage.  You don't need
DH_ELPA_TEST_ERT_EVAL: dh_elpa_test will automatically load that file
because it contains ERT test definitions.  Instead, you need to use
DH_ELPA_TEST_ERT_HELPER to call `evil-test-initialise' as upstream's
Makefile does.

> 5. Please add a d/watch.
> 
> Problem. Mercurial upstream repository, and tarballs are named not
> after version, but after hashes. I fail to extract anything useful
> from this page: [1]
> 
> [1] https://bitbucket.org/lyro/evil/downloads

Ah.  Seems that we're out of luck: uscan can't do Mercurial tags.

> PS. Your email formatting is amazing. Thank you.

Thanks!  Plaintext e-mail is very efficient if you use it right.

On Mon, Jun 27, 2016 at 05:46:58PM +0300, Dmitry Bogatov wrote:
> 
> > The function `evil-mode' doesn't seem to be properly autoloaded.
> > I.e. if I install elpa-evil-mode and then I open Emacs and type M-x,
> > evil-mode is not available.  However, if I type M-x describe-function
> > RET evil-mode RET it works.  Something is going wrong with the
> > autoloading.
> 
> I think I fixed it. Please, check.

It seems it wasn't enough.  If I move my .emacs.d out of the way and
then run it, and M-x evil-mode, I get this:

Error in post-command-hook (evil-repeat-post-hook): (void-function 
evil-repeat-post-hook)
Error in pre-command-hook (evil-repeat-pre-hook): (void-function 
evil-repeat-pre-hook)

Does that happen for you if you move .emacs.d?  I'm actually testing on
Ubuntu 16.04 instead of Debian but it shouldn't be relevant.

-- 
Sean Whitton

Bug#828803: aptitude: SIGSEGV in debVersioningSystem::CheckDep from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0

[Zhang Jingqiang]

Package: aptitude
Version: 0.8.1-1
Severity: normal

Hello,
I have previous kdepimlibs-data package installed, which has version 
4:16.04.1-2.
After this morning's update, there's two experimental version in the repo,
4:16.04.1-1 and 4:16.04.2-1, then I try to install 4:16.04.2-1 (mark this 
version to install),
and I got SIGSEGV.

There's no dbg package for this version of aptitude, so the backtrace attached 
may be useless.

Thanks

-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.1
Compiler: g++ 5.3.1 20160429
Compiled against:
  apt version 5.0.0
  NCurses version 6.0
  libsigc++ version: 2.8.0
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.0.20160319
  cwidget version: 0.5.17
  Apt version: 5.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffcdddb7000)
libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 
(0x7f531bbe5000)
libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 
(0x7f531b9b5000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7f531b78a000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f531b583000)
libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 
(0x7f531b286000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f531af81000)
libboost_iostreams.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.58.0 (0x7f531ad67000)
libboost_filesystem.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.58.0 (0x7f531ab4e000)
libboost_system.so.1.58.0 => 
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.58.0 (0x7f531a949000)
libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 
(0x7f531a545000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f531a328000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f5319fa7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5319ca9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f5319a93000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f53196ee000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f53194eb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f53192e7000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7f53190cf000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f5318eb4000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f5318ca4000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f5318a8)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f531886e000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f5318665000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f531846)
/lib64/ld-linux-x86-64.so.2 (0x55ed589f6000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common0.8.1-1
ii  libapt-pkg5.0  1.2.14
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5.1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-5.1
ii  libboost-system1.58.0  1.58.0+dfsg-5.1
ii  libc6  2.22-13
ii  libcwidget3v5  0.5.17-4+b1
ii  libgcc11:6.1.1-7
ii  libncursesw5   6.0+20160319-2+b1
ii  libsigc++-2.0-0v5  2.8.0-1
ii  libsqlite3-0   3.13.0-1
ii  libstdc++6 6.1.1-7
ii  libtinfo5  6.0+20160319-2+b1
ii  libxapian22v5  1.2.23-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-8
ii  sensible-utils 0.0.9

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 3.35

-- no debconf information
Starting program: /usr/bin/aptitude 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x73772700 (LWP 5910)]
[New Thread 0x72f71700 (LWP 5911)]
[New Thread 0x72770700 (LWP 5912)]
[New Thread 0x7fffec04e700 (LWP 5916)]

Thread 1 "aptitude" received signal SIGSEGV, Segmentation fault.
0x77b420ed in debVersioningSystem::CheckDep(char const*, int, char 
const*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0
#0  0x000

Bug#811648: FTBFS with GCC 6: cannot convert x to y

[Sean Whitton]

Dear Gert,

On Mon, Jun 27, 2016 at 11:07:05AM +0200, Gert Wollny wrote:
> attached is a patch that fixes the according build failure. 

Thank you for your contribution :)

> Regarding maintainership, I'll have to test the program first to see
> whether it is of any interest to me to maintain it (Upstream seems to
> be dead).

In the meantime, you are encouraged to make a "QA upload" to fix the
problem.  See: .

-- 
Sean Whitton

Bug#825701: should osptoolkit be removed from Debian?

[Di-Shi Sun]

Hi Mattia,

The upstream source is repackaged and uploaded to mentors.debian.net. Would
you please review it?

Thanks,

Di-Shi Sun.

-Original Message-
From: 'Mattia Rizzolo' [mailto:mat...@debian.org] 
Sent: Monday, June 27, 2016 9:02 PM
To: Di-Shi Sun
Cc: 825...@bugs.debian.org
Subject: Bug#825701: should osptoolkit be removed from Debian?

On Mon, Jun 27, 2016 at 08:53:02PM +0800, Di-Shi Sun wrote:
> Would you please send us the diff for debian/changelog again? We do 
> not find it.

whoops, I apparently forgot to attach it, here it is, sorry.

> For the license issue, it is an issue in the upstream project. We will 
> fix it in Debian first and upload the packages after we receive the 
> d/changelog diff.

yeah.
If you need to repack the upstream source, please use 4.11.3+dfsg as a
version.

--
regards,
Mattia Rizzolo

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

Bug#828006: systemd: "quiet" kernel boot parameter overrides LogLevel= in /etc/systemd/system.conf

[Brian Kroth]

Brian Kroth  2016-06-24 13:21:

Michael Biebl  2016-06-23 23:41:

Control: tags -1 + moreinfo

Hi Brian

Am 23.06.2016 um 19:09 schrieb Brian Kroth:

Per [1], the current version of systemd in Debian Jessie (v215) has an
issue that makes the "quiet" kernel boot parameter override values of
LogLevel= in the /etc/systemd/system.conf file (mine has LogLevel=info
explicitly set) and explicitly sets it to "notice" instead of the
documented default of "info".

There's a simple patch [2] that fixes this that I'd like to suggest
backporting.



That commit seem okayish for a jessie backport



[2]



A simple cherry-pick of 5e07a79e on top of v215 fails.
Have you backported this commit for v215 and given it some testing?
If so, can you attach the (tested) patch to this bug report.

Regards,
Michael


Hi, sorry, I ran out of time before the weekend.  I'll try and finish 
testing that and get back to you sometime on Monday.


I'll note that I had to use the following to cherrypick the patch from 
git since the changes to src/shared/log.c (just comments) failed to 
match anything nearby:


# git format-patch -1 5e07a79e84ab8b045b9df1a2719f14fc84471a1d -- 
src/core/main.c

Cheers,
Brian


Hi, I've done a little bit of testing with the patch and it does indeed 
appear to fix the issue.  Here's the resulting diff for the package I 
built.  Let me know if you need anything else.


Thanks,
Brian
diff -u -ruN systemd_215-17+deb8u4.debian/debian/changelog systemd_215-17+deb8u4.1.debian/debian/changelog
--- systemd_215-17+deb8u4.debian/debian/changelog	2016-03-03 12:51:40.0 -0600
+++ systemd_215-17+deb8u4.1.debian/debian/changelog	2016-06-24 13:08:05.0 -0500
@@ -1,3 +1,10 @@
+systemd (215-17+deb8u4.1) UNRELEASED; urgency=medium
+
+  * Backport systemd patch to not overwrite the LogLevel set in
+/etc/systemd/system.conf (Bug #828006).
+
+ -- Brian Kroth   Fri, 24 Jun 2016 13:03:25 -0500
+
 systemd (215-17+deb8u4) stable; urgency=medium
 
   [ Martin Pitt ]
diff -u -ruN systemd_215-17+deb8u4.debian/debian/patches/core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch systemd_215-17+deb8u4.1.debian/debian/patches/core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch
--- systemd_215-17+deb8u4.debian/debian/patches/core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch	1969-12-31 18:00:00.0 -0600
+++ systemd_215-17+deb8u4.1.debian/debian/patches/core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch	2016-06-24 13:18:43.0 -0500
@@ -0,0 +1,42 @@
+From 5e07a79e84ab8b045b9df1a2719f14fc84471a1d Mon Sep 17 00:00:00 2001
+From: Lennart Poettering 
+Date: Wed, 4 Feb 2015 01:42:49 +0100
+Subject: [PATCH] core: don't reset log level to NOTICE if we get quiet on the
+ kernel cmdline
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+quiet should really just have an effect on the stuff we dump on the
+console, not what we log elsewhere.
+
+Hence:
+
+debug on kernel cmdline → interpreted by every tool, turns up
+log levels to "debug" everywhere.
+
+quiet on kernel cmdline → interpreted only by PID 1 (and
+obviously the kernel) no alteration of the max log level, but
+turns off status output.
+
+http://lists.freedesktop.org/archives/systemd-devel/2014-December/026271.html
+---
+ src/core/main.c |2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/src/core/main.c b/src/core/main.c
+index 0480bc8..0749f04 100644
+--- a/src/core/main.c
 b/src/core/main.c
+@@ -367,8 +367,6 @@ static int parse_proc_cmdline_item(const char *key, const char *value) {
+ 
+ } else if (streq(key, "quiet") && !value) {
+ 
+-log_set_max_level(LOG_NOTICE);
+-
+ if (arg_show_status == _SHOW_STATUS_UNSET)
+ arg_show_status = SHOW_STATUS_AUTO;
+ 
+-- 
+1.7.10.4
+
diff -u -ruN systemd_215-17+deb8u4.debian/debian/patches/series systemd_215-17+deb8u4.1.debian/debian/patches/series
--- systemd_215-17+deb8u4.debian/debian/patches/series	2016-03-03 12:51:40.0 -0600
+++ systemd_215-17+deb8u4.1.debian/debian/patches/series	2016-06-24 13:12:57.0 -0500
@@ -95,6 +95,7 @@
 timesyncd-allow-two-missed-replies-before-reselectin.patch
 timesyncd-don-t-reset-polling-interval-when-reselect.patch
 backlight-Avoid-error-when-state-restore-is-disabled.patch
+core-don-t-reset-log-level-to-NOTICE-if-we-get-quiet.patch
 
 ## Cherry-picked patches:
 util-avoid-considering-dpkg-temporary-files-relevant.patch


signature.asc
Description: Digital signature

Bug#828800: verbiste: FTBFS in testing (Only can be included directly)

[Tomasz Buchert]

On 27/06/16 23:52, Santiago Vila wrote:
> Package: src:verbiste
> Version: 0.1.43-1
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> Severity: serious
> 
> Dear maintainer:
> 
> This package currently fails to build in stretch:

Hi Santiago,
correct. I was investigating this recently.

> 
> 
> [...]
> In file included from ../../src/gtk/main-window.h:26:0,
>  from panel-applet.cpp:23:
> /usr/include/gtk-3.0/gtk/gtkentry.h:34:2: error: #error "Only  can 
> be included directly."
>  #error "Only  can be included directly."
>   ^
> 
> 
> I discovered this by checking for "dpkg-buildpackage -A", but it also
> fails without -A, as shown here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/verbiste.html
> 
> Note 1: The build log from reproducible builds for unstable matches
> the error I got in testing. The build log from reproducible builds for
> testing is completely different, but that would be another bug, not
> this one.
> 
> Note 2: In case this is a bug in a header file (i.e. a -dev package),
> please use "affects" after "reassign", so that this bug is still shown
> in the web page for verbiste (this should help people to avoid filing
> duplicate bugs).
> 
> Thanks.
> 

This bug is related to gtk2 vs. gtk3 API. I'll work on it during debconf.

Tomasz


signature.asc
Description: PGP signature

Bug#828802: libfreemarker-java: Package is missing jar file

[Daniel Schepler]

Package: libfreemarker-java
Version: 2.3.23-4
Severity: grave

According to https://packages.debian.org/sid/all/libfreemarker-java/filelist
the package contents are only:

/usr/share/doc/libfreemarker-java/changelog.Debian.gz
/usr/share/doc/libfreemarker-java/copyright
/usr/share/maven-repo/org/freemarker/freemarker/2.3.23/freemarker-2.3.23.pom
/usr/share/maven-repo/org/freemarker/freemarker/debian/freemarker-debian.pom

That makes the package unusable since the jar file is missing.

(I ran into this trying to rebuild libspring-java:

FAILURE: Build failed with an exception.

* What went wrong:
Could not resolve all dependencies for configuration
':spring-context-support:compileClasspath'.
> Could not find freemarker.jar (org.freemarker:freemarker:debian).
 Searched in the following locations:
 
file:/usr/share/maven-repo/org/freemarker/freemarker/debian/freemarker-debian.jar
)
-- 
Daniel Schepler

Bug#828746: hwclock: RTC to wrong offset after reboot

[Martin-Éric Racine]

2016-06-27 23:34 GMT+03:00 Andreas Henriksson :
> Control: tags -1 + moreinfo
>
> Please check the contents of your /etc/adjtime for starters.

UTC as expected.

> Given you're using systemd you're not even running hwclock during your
> boot. Please see 'systemctl status hwclock.service'.
>
> Please read up on the RTC handling strategy usually deployed when using
> systemd. Please read the information already provided in misc bug
> reports filed by people requesting to emulate the old strategy used by
> sysvinit. Some useful sources of information might be:
> https://wiki.archlinux.org/index.php/time
> https://www.freedesktop.org/software/systemd/man/timedatectl.html
> https://www.freedesktop.org/wiki/Software/systemd/timedated/
> https://wiki.archlinux.org/index.php/systemd-timesyncd

Right.  So systemd uses an entirely different strategy for time
adjustment than sysvinit did, in addition to which it comes with a
built-in NTP client (disabled by default on Debian, for whatever
reason) that can replace standalone NTP daemons.  Great.  Nice
features but they are badly documented, from the perspective of
systems that were migrated from sysvinit.

At this point, I'm tempted to reassign this bug to release-notes,
since the migration on Debian from sysvinit as default to systemd as
default should have explained this, including the justification for
not enabling the built-in NTP client by default.

Martin-Éric

Bug#828801: Legitimate mail can contain long lines

[Gedalya]

Package: exim4-config
Version: 4.87-3

Ref: #797919

I've noticed the recent addition to acl_check_data in 
conf.d/acl/40_exim4-config_check_data:

  denymessage= maximum allowed line length is 998 octets, \
   got $max_received_linelength
  condition  = ${if > {$max_received_linelength}{998}}

I decided to try it out on a server getting some real traffic. It turns out the 
overwhelming majority of messages hit by this are spam, but not all.

Many legitimate and important messages coming from legitimate sources 
apparently have long lines. These tend to be non-human-originated messages such 
as order confirmations and alerts of various kinds.

These are coming from some major email sources such as sendgrid, mailgun, our 
favorite: GoDaddy, and others, and some from the sender's own network, such as 
Verizon.

I tested manually against gmail, and they let a long line (1150 octets) right 
through. Interestingly, Postfix 2.11.3-1 from jessie accepted the long line 
from the client but broke it into two [0] *after* DKIM as added by opendkim, so 
the signature was broken. Exim versions prior to 4.87 of course let it through. 
So in conclusion, we can't assume no legitimate mail will contain long lines, 
so this is probably not a good default configuration for a mail exchanger 
receiving mail from all over the wild.

[0] http://www.postfix.org/postconf.5.html#smtp_line_length_limit

Bug#828705: Linux kernel update creates redundant symlinks

[Evgeny Kapun]

On 27.06.2016 15:45, Ben Hutchings wrote:

Control: tag -1 wontfix

On Mon, 2016-06-27 at 15:20 +0300, Evgeny Kapun wrote:

On 27.06.2016 15:03, Ben Hutchings wrote:

Doesn't lilo fail if a file specified in its configuration is
missing?

Ben.


LILO has an "optional" option which makes it skip an entry if either
the kernel or the initrd file is missing (or is a broken link).


That's a good point.

I checked whether liloconfig would put the 'optional' keyword in
/etc/lilo.conf, but the config file it generated didn't mention the
symlinks at all.  So I don't think it makes sense to assume that people
use the 'optional' keyword.

There are other boot loaders that I think will use the symlinks during
package updates: elilo, palo and zipl.  They all have similar
configuration syntax to lilo, but it appears that elilo and palo do not
support the 'optional' keyword.

Although the 'old' symlinks will sometimes be redundant, I don't think
this issue outweighs the inconvenience of a failed boot loader update.

Ben.



On the other hand, the current behavior (when both pairs of symlinks are always 
kept) was introduced not so long ago, so most existing setups should work with 
the old behavior. And I can't find anyone reporting the old behavior as a bug, 
so I think that the old behavior isn't actually any more problematic than the 
current one. Maybe add a config option to choose between the old and the 
current behavior?

Also, if keeping all these symlinks is so important, then maintainer scripts 
should always prevent the only remaining installed kernel version from being 
removed, since there is no way to have valid symlinks after that. Now, such 
removal would proceed without any confirmation (unless that version happens to 
be the same as the one that is currently running), and all symlinks will be 
removed.

Bug#828422: Fwd: Bug#828422: links2: FTBFS with openssl 1.1.0

[Axel Beckert]

Hi Mikulas,

Mikulas Patocka wrote:
> I will release Links 2.13 soon, that will fix this problem.

Yay, thanks!

> If you need a quick fix, simply delete these lines from the file https.c:
> if (SSL_get_ssl_method(ssl) == SSLv2_client_method())
> return S_INSECURE_CIPHER;

I don't think it's that urgent, so I probably wait for 2.13.

> BTW. links verifies ssl certificates (since version 2.11), so it should 
> depend on the "ca-certificates" package.

Good point, thanks!

> You can add it to the "Recommends" field, or maybe as a mandatory
> dependency.

Will check if it works without or not and choose accordingly.

> OpenSSL 1.0.2h in Debian Sid is compiled with SSLv2_client_method enabled 
> and SSLv3_client_method disabled. Is it a configuration error? Why would 
> anyone want to enable SSL2 and disable SSL3? I suppose that the older 
> protocols should be disabled and newer protocols enabled.

No idea, Cc'ing Debian's OpenSSL team. They probably can tell.

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#828800: verbiste: FTBFS in testing (Only can be included directly)

[Santiago Vila]

Package: src:verbiste
Version: 0.1.43-1
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
In file included from ../../src/gtk/main-window.h:26:0,
 from panel-applet.cpp:23:
/usr/include/gtk-3.0/gtk/gtkentry.h:34:2: error: #error "Only  can 
be included directly."
 #error "Only  can be included directly."
  ^


I discovered this by checking for "dpkg-buildpackage -A", but it also
fails without -A, as shown here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/verbiste.html

Note 1: The build log from reproducible builds for unstable matches
the error I got in testing. The build log from reproducible builds for
testing is completely different, but that would be another bug, not
this one.

Note 2: In case this is a bug in a header file (i.e. a -dev package),
please use "affects" after "reassign", so that this bug is still shown
in the web page for verbiste (this should help people to avoid filing
duplicate bugs).

Thanks.

Bug#828799: afterstep segfaults on startup

[Bernardo F Costa]

Package: afterstepVersion: 2.2.12-3
Architecture: amd64
This error message attached was seen in a debian stable "jessie" when afterstep 
is called. This debian box has all updates available up to now. Just call 
afterstep command without a previous desktop system running on X to get this 
message. Couldn't get any previous report of this problem.afterstep ERROR: Failed to register as a client with the Gnome Session Manager. 
DBus error: The name org.gnome.SessionManager was not provided by any .service 
files
afterstep ERROR: Request SuspendAllowed to Power Management Daemon failed: 
Method "SuspendAllowed" with signature "" on interface "org.freedesktop.UPower" 
doesn't exist

afterstep ERROR: Request HibernateAllowed to Power Management Daemon failed: 
Method "HibernateAllowed" with signature "" on interface 
"org.freedesktop.UPower" doesn't exist

number of items in /usr/share/afterstep/applications = 18
number of items in /usr/share/applications = 210
number of items in /usr/share/applications/screensavers = 17
number of items in /usr/share/applications = 210
number of items in /usr/share/applications/screensavers = 17
number of items in /usr/share/applications = 210
number of items in /usr/share/applications/screensavers = 17
number of items in /usr/share/applications = 210
number of items in /usr/share/applications/screensavers = 17
number of items in /usr/share/applications = 210
number of items in /usr/share/applications/screensavers = 17
number of items in /var/lib/menu-xdg = 4
number of items in /var/lib/menu-xdg/xsessions = 3
number of items in /var/lib/menu-xdg/desktop-directories = 1
number of items in /var/lib/menu-xdg/desktop-directories/menu-xdg = 46
number of items in /var/lib/menu-xdg/applications = 1
number of items in /var/lib/menu-xdg/applications/menu-xdg = 191
number of items in /var/lib/menu-xdg/menus = 1
afterstep ERROR: unable to locate the fixed menu directory at "(null)"
Segmentation Fault trapped in afterstep.
 Call Backtrace :
 CALL#: ADDRESS:FUNCTION:
 1  0x7f94b10ba149  [/usr/lib/x86_64-linux-gnu/libAfterBase.so.0(+0x18149) 
[0x7f94b10ba149]]
 2  0x7f94affc20e0  [/lib/x86_64-linux-gnu/libc.so.6(+0x350e0) 
[0x7f94affc20e0]]
 3  0x427213  [afterstep(dirtree_fill_from_reference+0x83) [0x427213]]
 4  0x427b21  [afterstep(dirtree_parse+0x7e1) [0x427b21]]
 5  0x427bdc  [afterstep(dirtree_parse_include+0xac) [0x427bdc]]
 6  0x427bb8  [afterstep(dirtree_parse_include+0x88) [0x427bb8]]
 7  0x427bb8  [afterstep(dirtree_parse_include+0x88) [0x427bb8]]
 8  0x427bb8  [afterstep(dirtree_parse_include+0x88) [0x427bb8]]
 9  0x4276ca  [afterstep(dirtree_parse+0x38a) [0x4276ca]]
10  0x427bdc  [afterstep(dirtree_parse_include+0xac) [0x427bdc]]
11  0x427bb8  [afterstep(dirtree_parse_include+0x88) [0x427bb8]]
12  0x42086e  [afterstep(MeltStartMenu+0xee) [0x42086e]]
13  0x42162b  [afterstep(LoadASConfig+0xaeb) [0x42162b]]
14  0x41571f  [afterstep(main+0x43f) [0x41571f]]
15  0x7f94affaeb45  
[/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f94affaeb45]]
16  0x415b06  [afterstep() [0x415b06]]
Please collect all the listed information and submit a bug report to 
.
If core dump was generated by this fault, please examine it with gdb and attach 
results to your report.
 You can use the following sequence to do so :
   gdb -core core /usr/bin/afterstep
   gdb>backtrace
   gdb>info frame
   gdb>info all-registers
   gdb>disassemble

Bug#828422: Fwd: Bug#828422: links2: FTBFS with openssl 1.1.0

[Mikulas Patocka]

On Sun, 26 Jun 2016, Axel Beckert wrote:

> Hi Mikulas,
> 
> I think that's something which needs to be looked at upstream anyway.
> So if you come up with a patch, I'll happily test it.
> 
> - Forwarded message from Kurt Roeckx  -
> Date: Sun, 26 Jun 2016 12:22:53 +0200
> From: Kurt Roeckx 
> To: sub...@bugs.debian.org
> Subject: Bug#828422: links2: FTBFS with openssl 1.1.0
> Reply-To: Kurt Roeckx , 828...@bugs.debian.org
> 
> Source: links2
> Version: 2.12-2
> Severity: important
> Control: block 827061 by -1
> 
> Hi,
> 
> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/links2_2.12-2_amd64-20160529-1446
> 
> On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of 
> the
> reasons why it might fail.  There are also updated man pages at
> https://www.openssl.org/docs/manmaster/ that should contain useful 
> information.
> 
> There is a libssl-dev package available in experimental that contains a recent
> snapshot, I suggest you try building against that to see if everything works.
> 
> If you have problems making things work, feel free to contact us.
> 
> 
> Kurt
> - End forwarded message -
> 
>   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

Hi

I will release Links 2.13 soon, that will fix this problem.

If you need a quick fix, simply delete these lines from the file https.c:
if (SSL_get_ssl_method(ssl) == SSLv2_client_method())
return S_INSECURE_CIPHER;

BTW. links verifies ssl certificates (since version 2.11), so it should 
depend on the "ca-certificates" package. You can add it to the 
"Recommends" field, or maybe as a mandatory dependency.

OpenSSL 1.0.2h in Debian Sid is compiled with SSLv2_client_method enabled 
and SSLv3_client_method disabled. Is it a configuration error? Why would 
anyone want to enable SSL2 and disable SSL3? I suppose that the older 
protocols should be disabled and newer protocols enabled.

Mikulas

Bug#826042: Spyder crashes on start

[Martin Manns]

Could you package the master branch, which works pretty well out of the
box with Debian unstable?
This would make this package usable again.

Bug#828109: [pkg-gnupg-maint] Bug#828109: Bug#828109: gnupg2: does not react well to bad ECDSA subkey packet

[NIIBE Yutaka]

On 06/28/2016 02:43 AM, Daniel Kahn Gillmor wrote:
> On Mon 2016-06-27 02:25:33 -0400, NIIBE Yutaka wrote:
>> Sorry for the trouble because of my subkey.
> 
> thank you for being the experimental subject on whome the bugs are
> found, gniibe :)

Thanks, it's my pleasure.  :-)

>> And I found a bug for --list-packet option.  It's long standing, it's
>> there in 1.0.
>>
>> diff --git a/g10/mainproc.c b/g10/mainproc.c
>> index bd738ab..c191fe0 100644
>> --- a/g10/mainproc.c
>> +++ b/g10/mainproc.c
>> @@ -1328,7 +1328,7 @@ do_proc_packets (ctrl_t ctrl, CTX c, iobuf_t a)
>>/* Stop processing when an invalid packet has been encountered
>> * but don't do so when we are doing a --list-packets.  */
>>if (gpg_err_code (rc) == GPG_ERR_INV_PACKET
>> -  && opt.list_packets != 2 )
>> +  && opt.list_packets == 0)
>>  break;
>>continue;
>>  }
>>
> 
> Sounds like this needs to be applied upstream, no?

Yes.  It should be applied to all versions (1.4, 2.0, and 2.1).  I'm
going to send a message to gnupg-devel, because it requires some
explanation, and possibly another clean up.

Basically, the usage of opt.list_packets is not good, it is changed
along with functions.  I don't like this kind of assignment.  Well,
it's not in Haskell...
-- 

Bug#807369: apparmor: Apparmor "deny network" not working in Jessie

[Simon McVittie]

On Thu, 11 Feb 2016 at 17:03:22 +0100, Simon Ruderich wrote:
> Without network mediation local UNIX access is a big
> problem (DBUS).

That's because D-Bus has traditionally used the Linux-specific "abstract"
Unix sockets for the session bus on Linux, to avoid issues where
the socket persists long after the session has ended. If you install
dbus-user-session, the session bus changes to a filesystem-backed Unix
socket with a predictable name on a tmpfs provided by systemd-logind,
which avoids that cleanup problem because systemd-logind also cleans up
the tmpfs.

(Read the dbus-user-session package description before installing:
it alters the scope of the session bus in ways that you might not be
expecting. I think it's a far better model for the future of D-Bus, but
it isn't 100% backwards-compatible, which is why it's "opt-in".)

Normal filesystem-backed Unix sockets are mediated by ordinary file-based
AppArmor rules, so they are much easier to sandbox. They can also be
controlled with chroots, mount namespaces and other filesystem-based
containerization primitives, whereas abstract Unix sockets are controlled
by network namespaces; this matters if you are interested in using
something like Flatpak or Firejail for app sandboxing.

S

Bug#827732: maven-debian-helper: mh_make ignores --run-tests=false and --javadoc=false

[Emmanuel Bourg]

Le 20/06/2016 à 18:00, Christopher Hoskin a écrit :

> DependenciesSolver will always get called with the
> --generate-javadoc and --run-tests options if GEN_JAVADOC and RUN_TESTS
> have any non-empty value, even "false". So whilst tests and the javadoc
> package may be disabled, the dependencies for tests and generating docs
> are pulled in anyway.

Very good point, thank you for catching this Christopher. I'll apply
your patch.

Emmanuel Bourg

Bug#828787: ITP: libdisorder -- library for entropy measurement of byte streams and other data

[Guus Sliepen]

On Mon, Jun 27, 2016 at 11:25:12PM +0200, Andreas Tille wrote:

> > I hope you will fix this description. I'd only keep the last paragraph,
> 
> Done.
> 
> > and then also explain what algorithm it actually uses to measure the
[...]
> I'd be happy if you would commit a fix to Git (its writable to any DD)
> since you obviously know more about this than me.

Done.

> > I also want to point out that this library is not thread-safe, something
> > which could easily be fixed.
> 
> A patch would be reall welcome.

Done.

> > It also gives the wrong answer when you
> > have an input with more than 2^31-1 of the same bytes in the input, even
> > though it pretends to handle inputs up to 2^63 in length.
> 
> I think this information should be in README.Debian.  What do you think?

I think that would belong in a bugreport sent upstream. But I have also
committed a patch.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#828795: ioquake3: postinst call non-existing aa-enabled

[Simon McVittie]

Control: reassign 828795 dh-apparmor 2.10.95-2
Control: severity 828795 minor

On Mon, 27 Jun 2016 at 23:21:05 +0200, Alexandre Detiste wrote:
> postinst script call non-installed "aa-enabled" and generate errors.
...
> Paramétrage de ioquake3-server (1.36+u20160616+dfsg1-1) ...
> /var/lib/dpkg/info/ioquake3-server.postinst: 22:
> /var/lib/dpkg/info/ioquake3-server.postinst: aa-enabled: not found
> Paramétrage de ioquake3 (1.36+u20160616+dfsg1-1) ...
> Installation de la nouvelle version du fichier de configuration
> /etc/apparmor.d/usr.lib.ioquake3.ioquake3 ...
> /var/lib/dpkg/info/ioquake3.postinst: 22: 
> /var/lib/dpkg/info/ioquake3.postinst:
> aa-enabled: not found

I believe this is caused by recent changes to the dh_apparmor autoscript:

--- debian/debhelper/postinst-apparmor  2016-04-24 14:14:30 +
+++ debian/debhelper/postinst-apparmor  2016-06-24 13:13:39 +
@@ -16,9 +16,7 @@
 }
 
 # Reload the profile, including any abstraction updates
-rc=0
-aa-status --enabled 2>/dev/null || rc=$?
-if [ "$rc" = 0 ] || [ "$rc" = 2 ]; then
+if aa-enabled --quiet; then
 apparmor_parser -r -T -W "$APP_PROFILE" || true
 fi
 fi

The primary change here was to move from the Python aa-status --enabled
to the C aa-enabled, but a side-effect was to lose the "2>/dev/null".

The postinst ignores an AppArmor-detection command that does not exist,
treating it as equivalent to the unsuccessful exit status that would
indicate that the apparmor user-space tools are installed but the actual
LSM was not enabled in the kernel during boot. I think that's correct
here: if we don't have the apparmor user-space tools, we should just
not load the profile and carry on, the same as we would do if we had
the tools but the LSM wasn't enabled.

However, dropping the 2>/dev/null means that the postinst emits a message
that misleads users into thinking the package is missing a dependency on
apparmor or something.

As far as I understand the AppArmor maintainers' policy on how AppArmor
fits into Debian, we specifically do not want random packages that
happen to support AppArmor as an extra layer of hardening, like ioquake3,
to depend on apparmor. I could add a Suggests if people want that, but it
shouldn't be any stronger: it's entirely normal to use ioquake3 without
AppArmor.

S

Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]

[Lisandro Damián Nicanor Pérez Meyer]

You can't link to it directly due to licensing issues.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
El jun 27, 2016 5:49 PM, "Gert Wollny"  escribió:

>
>
>
> > From what I understand, you don't need to the the thread callbacks
> > anymore, the old functions are macro's that don't do a thing.  It
> > should set up threading support and locking internally.
> >
> > So can you clarify what kind of things you see as issue?
> This was essentially the clarification regarding the threads that I
> needed.
>
> So far I've identified all the places that need to be fixes. It seems
> however, that libopenssl is no linked directly, so I either have to add
> the defines for resolving the new functions and adding that q_* wrapper
> thing for the newly used access functions, or we change the package
> build rules to link openssl directly.
>
> best,
> Gert
>

Bug#828797: RM: r5rs-doc -- RoQA; unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove r5rs-doc. It's dropped from testing due to being
RC-buggy for nearly three years and the last maintainer upload
was in 2010. Also, that document can easily be found via any
search engine...

Cheers,
Moritz

Bug#828798: RM: iripdb -- RoQA; unmaintained, obsolete

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove iripdb. The package is up for adoption for a
decade(!), has virtually no users in popcon, the hardware
is long obsolete and it's RC-buggy.

Cheers,
Moritz

Bug#824460: works

[u]

I confirm that using the profiles from the commit/pull request which
intrigeri linked to, work correctly on Jessie.

thanks!

Bug#814944: mariadb-connect-engine-10.0: ODBC support apparently not compiled in

[Alan Dennis]

I now have mariadb-connect-engine-10.0 v10.0.25-0+deb8u1 installed 
(jessie-security) and despite this bug apparently being fixed in 
v10.0.24-4, I still get the same behaviour. i.e. trying to connect to an 
ODBC database, gives: SQL Error (1105): Unsupported table type ODBC and 
ldd /usr/lib/mysql/plugin/ha_connect.so output doesn't include unixodbc 
libs.


As this bug renders this package completely unusable, shouldn't the fix 
have been included in Jessie by now?

Bug#828796: ITP: r-bioc-geneplotter -- R package of functions for plotting genomic data

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
Owner: Debian Med team 

* Package name: r-bioc-geneplotter
  Version : 1.50.0
  Upstream Author : Bioconductor Package Maintainer 

* URL : http://bioconductor.org/packages/geneplotter/
* License : Artistic-2.0
  Programming Lang: R
  Description : R package of functions for plotting genomic data

geneplotter contains plotting functions for microarrays

Dependency for r-bioc-deseq2; team mainted by Debian Med

Bug#796599: false positive for Linux/Ebury - Operation Windigo -> due to now existing 'ssh -G' parameter

[Nathan Stratton Treadway]

For what it's worth, Fedora just released their own fix to this problem,
as discussed in:
  https://bugzilla.redhat.com/show_bug.cgi?id=1234436

(The specific patch they implemented can be found here:
  
http://pkgs.fedoraproject.org/cgit/rpms/chkrootkit.git/commit/?h=f23&id=82dd537b2fd88850eb4327a80b2c9acb7dbcf2ab
)

Ubuntu has LP: #1508248 open on this issue:
  https://bugs.launchpad.net/debian/+source/chkrootkit/+bug/1508248


Nathan

Bug#828787: ITP: libdisorder -- library for entropy measurement of byte streams and other data

[Andreas Tille]

Hi Guus,

On Mon, Jun 27, 2016 at 10:56:14PM +0200, Guus Sliepen wrote:
> 
> I hope you will fix this description. I'd only keep the last paragraph,

Done.

> and then also explain what algorithm it actually uses to measure the
> entropy (Shannon's source coding theorem). This theorem is actually only
> usable in the context of an input of "independent and identically
> distributed random variables", it does not apply to every kind of input.
> In particular, it only looks at the histogram of byte values; if you
> feed it a file with totally predictable increasing byte values 0, 1, 2,
> etc., it will report an entropy of 8. Many compression algorithms,
> especially those for sound and images, look at differences between
> consecutive values or have other means to detect such predictable
> sequences. So make it clear that it just implements Shannon's H function
> and that it also only works on bytes.

I'd be happy if you would commit a fix to Git (its writable to any DD)
since you obviously know more about this than me.
 
> I also want to point out that this library is not thread-safe, something
> which could easily be fixed.

A patch would be reall welcome.

> It also gives the wrong answer when you
> have an input with more than 2^31-1 of the same bytes in the input, even
> though it pretends to handle inputs up to 2^63 in length.

I think this information should be in README.Debian.  What do you think?
 
> > Remark: The code of libdisorder appeared in two other targets of Debian
> > Med and to avoid code duplication this library is packaged separately.
> 
> Although normally I would applaud deduplication, I personally think this
> shouldn't get its own package. It looks like one of those things you'd
> find npm.

I think I'll stick to this separate library approach.

Thanks a lot for your comments

  Andreas.

-- 
http://fam-tille.de

Bug#828795: ioquake3: postinst call non-existing aa-enabled

[Alexandre Detiste]

Package: ioquake3
Version: 1.36+u20160616+dfsg1-1
Severity: normal

postinst script call non-installed "aa-enabled" and generate errors.


--

Préparation du dépaquetage de .../ioquake3_1.36+u20160616+dfsg1-1_amd64.deb
...
Dépaquetage de ioquake3 (1.36+u20160616+dfsg1-1) sur (1.36+u20160122+dfsg1-2)
...
Préparation du dépaquetage de
.../ioquake3-server_1.36+u20160616+dfsg1-1_amd64.deb ...
Dépaquetage de ioquake3-server (1.36+u20160616+dfsg1-1) sur
(1.36+u20160122+dfsg1-2) ...
Traitement des actions différées (« triggers ») pour man-db
(2.7.5-1) ...
Paramétrage de ioquake3-server (1.36+u20160616+dfsg1-1) ...
/var/lib/dpkg/info/ioquake3-server.postinst: 22:
/var/lib/dpkg/info/ioquake3-server.postinst: aa-enabled: not found
Paramétrage de ioquake3 (1.36+u20160616+dfsg1-1) ...
Installation de la nouvelle version du fichier de configuration
/etc/apparmor.d/usr.lib.ioquake3.ioquake3 ...
/var/lib/dpkg/info/ioquake3.postinst: 22: /var/lib/dpkg/info/ioquake3.postinst:
aa-enabled: not found



-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ioquake3 depends on:
ii  ioquake3-server   1.36+u20160616+dfsg1-1
ii  libc6 2.22-11
ii  libcurl3-gnutls   7.47.0-1
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libjpeg62-turbo   1:1.5.0-1
ii  libogg0   1.3.2-1
ii  libopenal11:1.17.2-1
ii  libopus0  1.1.2-1
ii  libopusfile0  0.7-1
ii  libsdl2-2.0-0 2.0.4+dfsg2-1
ii  libvorbis0a   1.3.5-3
ii  libvorbisfile31.3.5-3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages ioquake3 recommends:
ii  x11-utils  7.7+3
ii  zenity 3.20.0-1

ioquake3 suggests no packages.

Versions of packages ioquake3 is related to:
ii  libgl1-mesa-dri  11.2.2-1

-- debconf-show failed

Bug#825936: Confirmed fixed problem : ibus-skk: when I use nicola layout, ibus-skk does not work except last character

[Yukiharu YABUKI]

Thank you for fixed problem, Ueno-san.

I built libskk from github. Then I confirmed nicola layout.
Please release minor version and upload it.

Next freeze day of stable development is near. I am happy to fix this
problem in next Debian stable.

Best
Yukiharu.

Bug#828794: fcgiwrap: Please add Depends: spawn-fcgi | systemd

[Peter Colberg]

Package: fcgiwrap
Version: 1.1.0-6
Severity: normal

Dear Maintainer,

fcgiwrap currently depends on spawn-fcgi, which is used only in the
sysvinit script and is not needed when using systemd. Could you please
adjust the dependency to "spawn-fcgi (>= 1.6.1) | systemd"?

Thanks,
Peter

Bug#809362: Willing to take over

[Tomasz Buchert]

On 27/06/16 12:55, Alexandre Viau wrote:
> Hello Tomas,
> 
> Do you have any updates on packaging OpenDHT?

Hi Alexandre,
no, not really, frankly, I don't remember even if I did some work or
not... I think that there was a nasty blocker, but cannot recall
anything precise.

> I am currently ad DebCamp and I would have time to work on it.

Feel free to do some work. :)
I'll be at Debconf, btw, we can work on that together, if you want.

> Is there a repository where I can help?

Not really. I may have worked on that a bit before, but whatever I had
is apparently gone from my home directory.

> 
> Cheers,
> 
> -- 
> Alexandre Viau
> av...@debian.org
> 

Cheers,
Tomasz




signature.asc
Description: PGP signature

Bug#828568: tcpcrypt build failures against openssl 1.1.0

[Daniel Kahn Gillmor]

On Mon 2016-06-27 16:41:22 -0400, Daniel Kahn Gillmor wrote:

> one of the major changes in OpenSSL 1.1.0 is making more of the data
> structures opaque; this looks like an instance of that.
>
> it'd be great to see an update that would let tcpcrypt build cleanly
> against newer versions as well.

Anyone interested in working on this might want to read:

 
https://wiki.openssl.org/index.php/1.1_API_Changes#Adding_forward-compatible_code_to_older_versions

hth,

--dkg


signature.asc
Description: PGP signature

Bug#828178: [Reproducible-builds] Bug#828178: afl: FTBFS: clang error unknown argument -fdebug-prefix-map=/build/afl-2.16b=.'

[Daniel Kahn Gillmor]

Hi Daniel--

On Sat 2016-06-25 16:09:08 -0400, Daniel Stender wrote:
> AFL fails to build from source in reproducible builds test build
> environments like this (log from 2.16b-1 build):
>
> 
> lang-3.7 -g -O2 -fdebug-prefix-map=/build/afl-2.16b=. -fPIE 
> -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign -DAFL_PATH=\"/usr/lib/afl\" 
> -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.16b\"  afl-clang-fast.c -o 
> ../afl-clang-fast -fPIE -pie -Wl,-z,relro -Wl,-z,now
> clang: error: unknown argument: '-fdebug-prefix-map=/build/afl-2.16b=.'
> Makefile:79: recipe for target '../afl-clang-fast' failed
> 

I think clang introduced -fdebug-prefix-map in 3.8.0 (see
https://bugs.debian.org/819185) and afl build-depends on clang-3.7.

I assume that it's the reproducible-builds toolchain that's adding the
-fdebug-prefix-map option to CFLAGS, right?  That's good -- it should
help avoid variations in the generated binaries due to build path alone,
so please keep it!  seems like the right fix here is either to build afl
against a newer version of clang, or to resolve #819185 by backporting
the option to clang-3.7.

> I'm going in it, soon.

I don't know what this means, sorry!

  --dkg

Bug#828787: ITP: libdisorder -- library for entropy measurement of byte streams and other data

[Guus Sliepen]

On Mon, Jun 27, 2016 at 10:07:04PM +0200, Andreas Tille wrote:

>   Description : library for entropy measurement of byte streams and other 
> data
>  libdisorder is a small, simple C library for use by programmers in
>  other programs. There is a small test program included that opens
>  /dev/urandom and calls libdisorder in the `test/' directory. There is
>  also a command-line tool, `ropy' in the `tool/' directory for reporting
>  on the entropy of normal files.
>  .
>  You will probably want to pipe the output of libdisorder to some other
>  math analysis or graphing environment (e.g., gnuplot).
>  .
>  The library's primary function reports entropy in bits: essentially,
>  this is the number of bits necessary to encode the actual level of
>  information contained in the data passed to the library: it is the
>  theoretical maximum amount of compression possible.

I hope you will fix this description. I'd only keep the last paragraph,
and then also explain what algorithm it actually uses to measure the
entropy (Shannon's source coding theorem). This theorem is actually only
usable in the context of an input of "independent and identically
distributed random variables", it does not apply to every kind of input.
In particular, it only looks at the histogram of byte values; if you
feed it a file with totally predictable increasing byte values 0, 1, 2,
etc., it will report an entropy of 8. Many compression algorithms,
especially those for sound and images, look at differences between
consecutive values or have other means to detect such predictable
sequences. So make it clear that it just implements Shannon's H function
and that it also only works on bytes.

I also want to point out that this library is not thread-safe, something
which could easily be fixed. It also gives the wrong answer when you
have an input with more than 2^31-1 of the same bytes in the input, even
though it pretends to handle inputs up to 2^63 in length.

> Remark: The code of libdisorder appeared in two other targets of Debian
> Med and to avoid code duplication this library is packaged separately.

Although normally I would applaud deduplication, I personally think this
shouldn't get its own package. It looks like one of those things you'd
find npm.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#827740: isympy start fails: No module named sympy.interactive

[Francesco Poli]

On Mon, 27 Jun 2016 16:08:28 +0200 Alberto Luaces wrote:

> Francesco Poli writes:
> 
> > On Thu, 23 Jun 2016 11:55:38 +0200 Alberto Luaces wrote:
> >
> >> Francesco Poli writes:
> > [...]
> >> > I see that you have python3-sympy installed.
> >> >
> >> > What's the output of
> >> >
> >> >   $ /usr/bin/python --version
> >> >
> >> > on your system?
> >> 
> >> $ python -V
> >> Python 2.7.12rc1
> >> $ python3 -V
> >> Python 3.5.2rc1
> >
> > Mmmh, then I am under the impression that you should try again after
> > installing python-sympy ...
> >
> 
> The error persists after re-installation.  The problem is that the
> shebang line of isympy calls /usr/bin/python regardless if python3-sympy
> was installed as its dependency.

Yes, that's why I suggested you to install python-sympy.

You can also keep python3-sympy installed, if you like (in case you
want to load the sympy module from python3), but isympy is a script
designed to be interpreted by /usr/bin/python, which is Python v2.7.x
and not v3.x ...

I don't know whether there is an elegant way to make isympy
automatically figure out whether you would prefer using python or
python3.

[...]
> >   $ python3 /usr/bin/isympy
> 
> Thank you.  Of course that works,

Good, this is an explicit way to express your preference for python3
over python.

> but the bug remains: isympy is that
> wrapper script :)

Maybe another binary package could be added (named isympy3), including
an appropriate isympy3 script...
At that point isympy would depend on python-sympy (without
python3-sympy as an alternative dependency) and isympy3 would depend on
python3-sympy.

I don't know, I'll let the sympy maintainers think about it and express
their opinion.

Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpt75FyMxOqo.pgp
Description: PGP signature

Bug#828793: minicom: please make the build reproducible

[Reiner Herrmann]

Source: minicom
Version: 2.7-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that X could not be built reproducibly.
The build time is embedded into gzip headers and the content of the
md5sums file is unsorted.

The attached patch fixes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/rules b/debian/rules
index 7d2d8f2..95d65e4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,7 +64,7 @@ ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
 	cd $(BUILDDIR)/usr/bin && strip -R .comment -R .note ascii-xfr minicom runscript
 endif
 	install -p -D -m 0644 debian/menu $(BUILDDIR)/usr/share/menu/minicom
-	find $(BUILDDIR)/usr/share/man -type f -print0 | xargs -0 gzip -9
+	find $(BUILDDIR)/usr/share/man -type f -print0 | xargs -0 gzip -9n
 
 	install -d -m 0755 $(BUILDDIR)/etc/minicom $(DOCDIR)/examples $(DOCDIR)/intl $(DOCDIR)/term $(DOCDIR)/todo $(DOCDIR)/tables
 	install -p -m 0644 doc/minirc.dfl extras/*login debian/minirc.nullmodem $(DOCDIR)/examples
@@ -80,12 +80,12 @@ endif
 	install -p -D -m 0644 extras/terminfo/README   $(DOCDIR)/term/README.terminfo
 	install -p -D -m 0644 extras/terminfo/minicom  $(DOCDIR)/term/terminfo
 	install -p -m 0644 TODO doc/TODO* doc/Todo* $(DOCDIR)/todo
-	find $(DOCDIR) -type f \( -size +8 -o -name 'changelog*' \) -print0 | xargs -0 gzip -9
+	find $(DOCDIR) -type f \( -size +8 -o -name 'changelog*' \) -print0 | xargs -0 gzip -9n
 
 	install -d -m 0755 $(DEBDIR)
 	install -p -m 0644 debian/control $(DEBDIR)
 	install -p -m 0755 debian/preinst debian/postinst debian/postrm $(DEBDIR)
-	cd $(BUILDDIR) && find usr -type f -print0 | xargs -0 md5sum > DEBIAN/md5sums
+	cd $(BUILDDIR) && find usr -type f -print0 | LC_ALL=C sort -z | xargs -0 md5sum > DEBIAN/md5sums
 	chmod 0644 $(DEBDIR)/md5sums
 
 	dpkg-shlibdeps $(BUILDDIR)/usr/bin/ascii-xfr $(BUILDDIR)/usr/bin/minicom $(BUILDDIR)/usr/bin/runscript


signature.asc
Description: Digital signature

Bug#828232: amanda: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Mon, Jun 27, 2016 at 08:30:08PM +0100, j...@calhariz.com wrote:
> The amanda is failing to configure with openssl 1.1.0.  I have contacted the
> upstream on the mailing list amanda-users and he sent me the attached patch.
> With the patch amanda configures and compiles, failing only during linking
> in a way I think is not amanda fault:
> 
> libtool: link: gcc -Wall -Wextra -Wparentheses -Wdeclaration-after-statement
> -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wformat
> -Wformat-security -Wsign-compare -Wfloat-equal -Wold-style-definition
> -Wno-strict-aliasing -Wno-unknown-pragmas -Wno-deprecated-declarations -g
> -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -O2 -g
> -Wall -DIGNORE_TAR_ERRORS -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o
> .libs/amflock-test amflock-test.o -Wl,--export-dynamic -pthread -pthread
> ./.libs/libamanda.so ./.libs/libtestutils.a -L/usr/lib/x86_64-linux-gnu
> -lcrypto /usr/lib/x86_64-linux-gnu/libcurl.so -lm -lgmodule-2.0
> -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lnsl -lresolv -pthread -Wl,-rpath
> -Wl,/usr/lib/amanda
> /usr/bin/ld: warning: libcrypto.so.1.0.2, needed by
> /usr/lib/x86_64-linux-gnu/libcurl.so, may conflict with libcrypto.so.1.1
> ./.libs/libamanda.so: undefined reference to `OPENSSL_init_ssl'
> collect2: error: ld returned 1 exit status
> Makefile:2206: recipe for target 'amflock-test' failed
> make[4]: *** [amflock-test] Error 1

I'm unsure why you get that error.  I think the problem is that
libamanda.so is not linked with libcrypto, but that you for some
unknown reason add -lcrypto when linking amflock-test, which you
shouldn't?

Can you do a readelf -d on that ./.libs/libamanda.so?  What does
the NEEDED say?

> I will prepare a new package for the new upstream version amanda 3.3.9.  In
> case there is the need of a fast NMU because of this bug, please go head.

There is no need to have it fixed really fast.  It would be nice
that it was fixed before I upload it to unstable in which case it
would just need a binNMU.


Kurt

Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]

[Gert Wollny]

> From what I understand, you don't need to the the thread callbacks
> anymore, the old functions are macro's that don't do a thing.  It
> should set up threading support and locking internally.
> 
> So can you clarify what kind of things you see as issue?
This was essentially the clarification regarding the threads that I
needed. 

So far I've identified all the places that need to be fixes. It seems
however, that libopenssl is no linked directly, so I either have to add
the defines for resolving the new functions and adding that q_* wrapper
thing for the newly used access functions, or we change the package
build rules to link openssl directly.

best, 
Gert 

Bug#828568: tcpcrypt build failures against openssl 1.1.0

[Daniel Kahn Gillmor]

hi all--

openssl 1.1.0 is about to be released.  Kurt Roeckx was nice enough to
try rebuilding tcpcrypt against it and got this error:

https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/tcpcrypt_0.4-4_amd64-20160529-1543


the error it hits is:

[...]
src/src_tcpcryptd-crypto.o `test -f 'src/crypto.c' || echo './'`src/crypto.c
gcc -DHAVE_CONFIG_H -I.   -Wdate-time -D_FORTIFY_SOURCE=2 -I./src -I./include 
-I./src -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall 
-Wno-deprecated-declarations -c -o src/src_tcpcryptd-crypto_rsa.o `test -f 
'src/crypto_rsa.c' || echo './'`src/crypto_rsa.c
In file included from /usr/include/openssl/asn1.h:24:0,
 from /usr/include/openssl/rsa.h:16,
 from src/crypto_rsa.c:8:
src/crypto_rsa.c: In function 'generate_keys':
src/crypto_rsa.c:64:35: error: dereferencing pointer to incomplete type 'RSA 
{aka struct rsa_st}'
  k->k_blen = BN_num_bytes(k->k_rsa->n);
   ^
Makefile:1013: recipe for target 'src/src_tcpcryptd-crypto_rsa.o' failed
make[2]: *** [src/src_tcpcryptd-crypto_rsa.o] Error 1
make[2]: Leaving directory '/<>'


(there may of course be other errors as well)


one of the major changes in OpenSSL 1.1.0 is making more of the data
structures opaque; this looks like an instance of that.

it'd be great to see an update that would let tcpcrypt build cleanly
against newer versions as well.

(this is noted in https://bugs.debian.org/828568)

   --dkg

Bug#828792: RFS: yamllint/1.3.0-1

[Adrien Vergé]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "yamllint"

* Package name: yamllint
  Version : 1.3.0-1
  Upstream Author : Adrien Vergé 
* URL : https://github.com/adrienverge/yamllint
* License : GPL-3+
  Section : devel

It builds this binary package:

  yamllint   - Linter for YAML files

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/yamllint

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/y/yamllint/yamllint_1.3.0-1.dsc

Changes since the last upload:

  * Allow disabling yamllint checks using comments
  * Detect user config using `os.path.expanduser()`
  * Update standards version to 3.9.8

Regards,
 Adrien Vergé

Bug#828791: fio: please make the build reproducible

[Reiner Herrmann]

Source: fio
Version: 2.10-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that fio could not be built reproducibly.
It collects source files in readdir order, which leads to a
non-deterministic linking order.

The attached patch fixes this by sorting the list of object files.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..cc75739
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort object files for deterministic linking order
+
+--- a/Makefile
 b/Makefile
+@@ -179,7 +179,7 @@
+   CFLAGS += -DPSAPI_VERSION=1 -Ios/windows/posix/include -Wno-format -static
+ endif
+ 
+-OBJS := $(SOURCE:.c=.o)
++OBJS := $(sort $(SOURCE:.c=.o))
+ 
+ FIO_OBJS = $(OBJS) fio.o
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 7e2c2db..3568753 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@ makefile-manpagepath
 fio2gnuplot-manpage
 configure-no-configlog
 fix-ftbfs-with-libmtd.h
+reproducible-build.patch


signature.asc
Description: Digital signature

Bug#827891: libtidy-dev: not provide buffio.h library

[Gianfranco Costamagna]

control: affects -1 abiword
G

On Wed, 22 Jun 2016 08:34:21 +0100 "Daniel James"  wrote:
> Hi Mateusz,
> 
> > Package should provides symlinks like is in Arch Linux
> 
> Thanks for the report, I'll get that fixed.
> 
> Cheers!
> 
> Daniel
> 
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#828746: hwclock: RTC to wrong offset after reboot

[Andreas Henriksson]

Control: tags -1 + moreinfo

Hello Martin-Éric Racine.

I strongly doubt there's a bug in hwclock based on your description.
All other similar cases I've looked into have always resulted in a local
misconfiguration being the culprit. It's likely your system somehow
messes up keeping track of the difference between UTC and local
timezone.
The time in the RTC can be set to either and the RTC does not keep track
of the timezone itself. (Which would explain your 3 hour offset.)

Please check the contents of your /etc/adjtime for starters.

Please followup with checking the configuration of any time source
you have that updates the RTC on your system.

On Mon, Jun 27, 2016 at 03:30:03PM +0300, Martin-Éric Racine wrote:
> Package: util-linux
> Version: 2.28-5
> Severity: important
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Whenever rebooting this host, the RTC time is 3 hours ahead of what it
> should be.  This wasn't the case when using whatever is currently in
> Debian/stable.
> 
[...]
> Init: systemd (via /run/systemd/system)
[...]

Given you're using systemd you're not even running hwclock during your
boot. Please see 'systemctl status hwclock.service'.

Please read up on the RTC handling strategy usually deployed when using
systemd. Please read the information already provided in misc bug
reports filed by people requesting to emulate the old strategy used by
sysvinit. Some useful sources of information might be:
https://wiki.archlinux.org/index.php/time
https://www.freedesktop.org/software/systemd/man/timedatectl.html
https://www.freedesktop.org/wiki/Software/systemd/timedated/
https://wiki.archlinux.org/index.php/systemd-timesyncd

Please also let me remind you that the debian bug tracking system
is not a support forum. My time is very limited and it's not possible
for me to both do debian development and user support on my spare
time. Please look for help elsewhere if you're not interested
in paying for a support contract from me.
If you're actually identified a *bug* please feel free to share
your information about what the symptoms are, what's causing it
and maybe even supply a tested fix for the problem.

Regards,
Andreas Henriksson

Bug#824222: [DM] Re: Bug#824222: [debian-refcard] change build mechanism to dblatex for ar, hi, ml

[victory]

On Mon, 27 Jun 2016 22:07:58 +0200
Holger Wansing wrote:

> Control: rename -1 [debian-refcard] change build mechanism to dblatex for ar, 
> ml

retitle


-- 
victory
no need to CC me :-)

Bug#825715: kdepim: Drop obsolete build-depends on link-grammar

[Gianfranco Costamagna]

control: severity -1 serious

> I am bumping the severity since I believe this should be done before I
> can upload link-grammar 5.

hi, for a misunderstanding I uploaded the package, because I thought you were 
aware of this bug
(sorry, bad english here!)

Anyway, link-grammar seems to be not used by your package, so it shouldn't even 
affect its testing
migration.
I'll probably leave to you the upload, and NMU just in case there is no answer 
and the package doesn't migrate.

Sorry again, it wasn't intended, I hope I didn't mess with your transition

Gianfranco



signature.asc
Description: OpenPGP digital signature

Bug#828790: debiandoc-sgml-doc: please make the build reproducible

[Dhole]

Source: debiandoc-sgml-doc 
Version: 1.1.24+nm 
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

While working on the "reproducible builds" effort [1], we have noticed that
debiandoc-sgml-doc could not be built reproducibly.

When generating the documentation files, a timestamp of the last changelog entry
is embedded in the local timezone.

The attached patch fixes this setting the timestamp to UTC. Once applied,
debiandoc-sgml-doc can be built reproducibly in our current experimental
framework.

 [1]: https://wiki.debian.org/ReproducibleBuilds

Regards,
-- 
Dhole
diff -Nru debiandoc-sgml-doc-1.1.24/debian/changelog 
debiandoc-sgml-doc-1.1.24+nmu1/debian/changelog
--- debiandoc-sgml-doc-1.1.24/debian/changelog  2015-08-12 18:31:34.0 
+0200
+++ debiandoc-sgml-doc-1.1.24+nmu1/debian/changelog 2016-06-27 
21:34:23.0 +0200
@@ -1,3 +1,10 @@
+debiandoc-sgml-doc (1.1.24+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Set the embedded date to UTC to make it reproducible. 
+
+ -- Eduard Sanou   Mon, 27 Jun 2016 21:34:14 +0200
+
 debiandoc-sgml-doc (1.1.24) unstable; urgency=medium
 
   * Reproducible build with the new debiandoc-sgml 1.2.31-1.
diff -Nru debiandoc-sgml-doc-1.1.24/debian/rules 
debiandoc-sgml-doc-1.1.24+nmu1/debian/rules
--- debiandoc-sgml-doc-1.1.24/debian/rules  2015-08-12 18:18:25.0 
+0200
+++ debiandoc-sgml-doc-1.1.24+nmu1/debian/rules 2016-06-27 21:34:09.0 
+0200
@@ -8,7 +8,7 @@
 #export DH_VERBOSE=1
 
 # Reproduceble build
-DEBIANDOC_DATE ?= $(shell date +'%Y-%m-%d' -d"`dpkg-parsechangelog -SDate`")
+DEBIANDOC_DATE ?= $(shell date --utc +'%Y-%m-%d' -d"`dpkg-parsechangelog 
-SDate`")
 export DEBIANDOC_DATE
 
 ## --


signature.asc
Description: PGP signature

Bug#804134: generated ChangeLog files make packages not multi-arch co-installible (and also not reproducible)

[Michael Biebl]

Control: tags -1 + moreinfo

Hi Roderich

On Thu, 05 Nov 2015 10:09:46 +0100 Roderich Schupp
 wrote:
> I tried to install some self-built amd64 packages from avahi 0.6.32~rc+dfsg-1
> along the corresponding i386 patches from the archives. This failed because
> some changelog.gz files were different in the amd64 and i386 packages, e.g.
> /usr/share/doc/libavahi-client3/changelog.gz:
> 
> 2015-11-04  gettextize  
> 
> * Makefile.am (EXTRA_DIST): Add config.rpath.
> * configure.ac (AC_CONFIG_FILES): Add po/Makefile.in.
> 
> This comes from the top level ChangeLog in the source which is created (or
> amended) by autogen.sh (by invoking gettextize from gettext 0.19.6-1) during
> the build, hence the date above is the build date.
> 
> Suggested fix: invoke gettextize with the --no-changelog option; patch
> attached.

I can't seem to reproduce the problem. I'm not exactly sure where the
date comes from, but it certainly doesn't seem to be the based on the
build date. After the autoreconf I still have

2015-10-14  gettextize  

* configure.ac (AC_CONFIG_FILES): Add po/Makefile.in.

2015-10-10  gettextize  

* Makefile.am (EXTRA_DIST): Add config.rpath.
* configure.ac (AC_CONFIG_FILES): Add po/Makefile.in.


Can you give more details, what exact problems you encountered?


That said, the ChangeLog is not particularly useful anyway, so maybe we
just skip installing it.

Michael


-- 
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#826843: Calls to notmuch_database_add_message() after notmuch_database_close() crash

[David Bremner]

David Bremner  writes:

> Lars Luthman  writes:
>
>
>> This should either be fixed so it doesn't crash, as documented, or the
>> documentation should be changed to describe which functions are unsafe
>> to call after notmuch_database_close().
>>
>
> The obvious thing to do is just say that any function other than
> notmuch_database_destroy has undefined behaviour after calling
> notmuch_database_close.

Reading the docs again more carefully, it doesn't actually suggest that
you can call functions on the database itself, but only documents the
behaviour on derived objects like messages. I agree the docs could be
more explicit, and I'll probably apply something like the attached
upstream. It doesn't seem very urgent to fix the bug in Debian though,
certainly not urgent enough for an update in stable.

>From 78dc819a0ced2f56537a6cbb79006ab1316093d4 Mon Sep 17 00:00:00 2001
From: David Bremner 
Date: Mon, 27 Jun 2016 20:35:01 +0200
Subject: [PATCH] doc: forbid further operations on a closed database

We could add many null pointer checks, but currently I don't see a use
case that justifies it.
---
 lib/notmuch.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/notmuch.h b/lib/notmuch.h
index d4a97cb..2faa146 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -332,7 +332,9 @@ notmuch_database_status_string (const notmuch_database_t *notmuch);
  * functions on objects derived from this database may either behave
  * as if the database had not been closed (e.g., if the required data
  * has been cached) or may fail with a
- * NOTMUCH_STATUS_XAPIAN_EXCEPTION.
+ * NOTMUCH_STATUS_XAPIAN_EXCEPTION. The only further operation
+ * permitted on the database itself is to call
+ * notmuch_database_destroy.
  *
  * notmuch_database_close can be called multiple times.  Later calls
  * have no effect.
-- 
2.8.1

Bug#828789: False-positive on samba build

[Mathieu Parent]

Package: blhc
Version: 0.06-0.1
Severity: minor
Tags: upstream

Hello,

blhc outputs:
CPPFLAGS missing (-D_FORTIFY_SOURCE=2): 19:49:25 runner  
../source3/script/build_env.sh /build/samba-4.4.4+dfsg/source3 
/build/samba-4.4.4+dfsg/source3 /usr/bin/gcc > 
default/source3/include/build_env.h 

Here, gcc is just ${CC} expanded by waf. No compilation is done.

Maybe gcc followed by ">" can always be ignored?

Regards

Mathieu Parent

Bug#828788: pyparted: please make the build reproducible

[Reiner Herrmann]

Source: pyparted
Version: 3.10.7-2
Severity: wishlist
Tags: patch upstream
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fileordering
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that pyparted could not be built reproducibly.
It collects source files without sorting, which leads to a
non-deterministic linking order.

The attached patch fixes this by sorting the globbed file list.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..d09182c
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,11 @@
+--- a/setup.py
 b/setup.py
+@@ -73,7 +73,7 @@
+   packages=['parted'],
+   package_dir={'parted': 'src/parted'},
+   ext_modules=[Extension('_ped',
+- glob.glob(os.path.join('src', '*.c')),
++ sorted(glob.glob(os.path.join('src', '*.c'))),
+  define_macros=features,
+  **pkgconfig('libparted',
+  include_dirs=['include']))
diff --git a/debian/patches/series b/debian/patches/series
index 74ae2f7..86cd2a1 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 no-last-flag-check.patch
+reproducible-build.patch


signature.asc
Description: Digital signature

Bug#828777: gap-alnuth: FTBFS: Input is: EquationOrderBasis( F ); [..] Expected output [..]

[Bill Allombert]

On Mon, Jun 27, 2016 at 07:54:58PM +0100, Chris Lamb wrote:
> Source: gap-alnuth
> Version: 3.0.0-3
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> gap-alnuth fails to build from source in unstable/amd64:
> 
>   [..]
>   > Diff in debian/gaproot/pkg/Alnuth/tst/ALNUTH.tst, line 7:
>   # Input is:
>   EquationOrderBasis( F );
>   # Expected output:
>   Basis( , 
>   [ [ [ 1, 0, 0, 0 ], [ 0, 1, 0, 0 ], [ 0, 0, 1, 0 ], [ 0, 0, 0, 1 ] ], 
> [ [ -1, 1, 1, 0 ], [ 5, -5, -5, 11 ], [ 3, -4, -7, 11 ], [ 3, -3, -4, 7 ] 
> ],
> [ [ 9, -10, -13, 22 ], [ -12, 17, 21, -33 ], [ -11, 18, 28, -44 ],
> [ -9, 13, 18, -28 ] ],
> [ [ -32, 45, 62, -99 ], [ 61, -82, -112, 187 ], [ 53, -81, -121, 198 ],
> [ 44, -62, -88, 145 ] ] ] )
>   # But found:
>   Basis( , 
>   [ [ [ 1, 0, 0, 0 ], [ 0, 1, 0, 0 ], [ 0, 0, 1, 0 ], [ 0, 0, 0, 1 ] ], 
> [ [ 11, 11, 22, -22 ], [ 33, -33, -66, 132 ], [ 22, -22, -22, 55 ], 
> [ 20, -24, -38, 80 ] ], 
> [ [ 528, -198, -132, 660 ], [ 462, -264, -660, 1848 ], 
> [ 132, 132, 330, -198 ], [ 192, -72, -180, 702 ] ], 
> [ [ 9570, -594, 2508, 7788 ], [ 18810, -16038, -28116, 66528 ], 
> [ 9108, -5412, -5544, 16830 ], [ 9816, -8400, -13740, 32532 ] ] ] )
>   
>   Installation test of Alnuth package
>   GAP4stones: 1250
>   ! grep "^" debian/gap.tst
>   > Diff in debian/gaproot/pkg/Alnuth/tst/ALNUTH.tst, line 7:
>   
>   debian/rules:7: recipe for target 'build-indep-stamp' failed
>   make: *** [build-indep-stamp] Error 1
> 
>   [..]

Thanks, thi is a test-suite failure. I just reported it upstream.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#824222: [debian-refcard] change build mechanism to dblatex for ar, hi, ml

[Holger Wansing]

Control: rename -1 [debian-refcard] change build mechanism to dblatex for ar, ml

Holger Wansing  wrote:
> Package: debian-refcard
> Tags: patch
> thanks
> 
> 
> The attached patch switches the build chain for ar, hi and ml, to use dblatex
> instead of xmlroff (patch by victory, thanks).
> 
> Please note, that the patch is only a draft, maybe other fonts would be
> better. To sort this out, proofreaders for the respective languages are
> needed and info from them, which fonts they prefer.
> Since I didn't got answers from translators for this languages, I store the
> draft as a bugreport.

Changings for Hindi applied today.

Bug renamed accordingly.


Holger


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/

Bug#827935: libqt5core5a: [kfreebsd] QProcessPrivate::createPipe: Cannot create pipe - Function not implemented

[Dmitry Shachnev]

Hi Steven,

On Mon, Jun 27, 2016 at 08:37:05PM +0100, Steven Chamberlain wrote:
> I was confused, why don't I see it in the kfreebsd-amd64 build log then?

I do see it:
https://buildd.debian.org/status/fetch.php?pkg=qbs&arch=kfreebsd-amd64&ver=1.5.1%2Bdfsg-1&stamp=1466269242

Note that this bug only appears with Qt 5.6, not 5.5 (and our latest 5.6
packages have a workaround).

> I still see the linker warnings about dup3 and pipe2, but the test
> passed?

Yes, because these are warnings, not errors (actually the workaround
I mentioned turns them into errors).

> I don't have an account, but my first thought is that it is not
> desirable to add special code upstream for GNU/kFreeBSD.
>
> Today I wrote an implementation of dup3, I will try to do the same for
> pipe2 and hopefully we can provide these in our glibc - which may be
> useful to other packages than this one.

Thanks a lot, this would be much helpful for us!

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#828787: ITP: libdisorder -- library for entropy measurement of byte streams and other data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libdisorder
  Version : 0.0.2
  Upstream Author : Michael E. Locasto
* URL : https://github.com/locasto/libdisorder
* License : GPL
  Programming Lang: C
  Description : library for entropy measurement of byte streams and other 
data
 libdisorder is a small, simple C library for use by programmers in
 other programs. There is a small test program included that opens
 /dev/urandom and calls libdisorder in the `test/' directory. There is
 also a command-line tool, `ropy' in the `tool/' directory for reporting
 on the entropy of normal files.
 .
 You will probably want to pipe the output of libdisorder to some other
 math analysis or graphing environment (e.g., gnuplot).
 .
 The library's primary function reports entropy in bits: essentially,
 this is the number of bits necessary to encode the actual level of
 information contained in the data passed to the library: it is the
 theoretical maximum amount of compression possible.


Remark: The code of libdisorder appeared in two other targets of Debian
Med and to avoid code duplication this library is packaged separately.
It is maintained at
   https://anonscm.debian.org/git/debian-med/libdisorder.git

Bug#828786: tcptraceroute: please make the build reproducible

[Reiner Herrmann]

Source: tcptraceroute
Version: 1.5beta7+debian-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: uname
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that tcptraceroute could not be built reproducibly.
It embeds the host architecture into the binary.

The attached patch removes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/main.c b/main.c
index 8f4dbe2..6ede131 100644
--- a/main.c
+++ b/main.c
@@ -407,7 +407,7 @@ int main(int argc, char **argv)
 
 			case 'd':
 o_debug++;
-debug("%s %s, %s\n", PACKAGE, VERSION, TARGET);
+debug("%s %s\n", PACKAGE, VERSION);
 debug("Compiled with libpcap %s, libnet %s (API %d)\n",
 	pcap_version, LIBNET_VERSION, LIBNET_API_VERSION);
 break;


signature.asc
Description: Digital signature

Bug#828785: uwsgi: FTBFS in testing (uwsgiconfig.py: Command not found)

[Santiago Vila]

Package: src:uwsgi
Version: 2.0.12-7
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Hello Jonas.

This package currently fails to build in stretch:


[...]
test -x debian/rules
rm -f debian/copyright_newhints
rm -f debian/cdbs-install-list debian/cdbs-package-list 
debian/stamp-copyright-check
rm -rf "debian/upstream-cruft"
rm -f debian/stamp-upstream-cruft
dh_clean 
uwsgiconfig.py -v --clean
make: uwsgiconfig.py: Command not found
debian/rules:335: recipe for target 'clean' failed
make: *** [clean] Error 127
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2


You can find a full build log here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/uwsgi_2.0.12-7.rbuild.log

Note: Maybe you need a versioned Build-Depends somewhere? (for a
build-dependency which did not enter testing yet).

It is a known fact that Britney does not currently take build-depends
in account for the unstable to testing migration, only ordinary
depends, but even in such case, a package in testing should not fail
in this way. It should better fail in the "Build-depends may not be met"
way.

Thanks.

Bug#824967: RFS: budgie-desktop/10.2.5-1 [ITP]

[foss.freedom]

Hi all,

  I've updated a new version today of my package budgie-desktop - this
tidies the vcs-browser and git fields in the control file.

Does anyone have anytime to have a look-see and maybe sponsor the package
please?

thanks

David

On 31 May 2016 at 20:14, foss.freedom  wrote:

> Many thanks Paul for the additional review comments.  I've included the
> changes below in a revised package.
>
> Important Note.  I've contacted the maintainer of the budgie-desktop
> package on a couple of issues that was raised.
>
> He has decided to consolidate all the issues raised under one umbrella
> issue:
>
>  - https://github.com/solus-project/budgie-desktop/issues/465
>
> He has graciously (albeit time-limited) offered Debian a minor point
> release that can address any packaging issue or issues.  Two caveats - the
> issue or issues must not be distro specific and he is expecting a
> consolidated list of points to consider - "let's get a complete action plan
> here so I can get my development time back. i.e. kick things into gear."
>
> Whilst I know you do not wish to sponsor this package - do you know of
> someone who can?  I'm keen to get one list together to to keep the
> maintainer positively engaged.  I cannot go back now to the maintainer with
> individual points over a period of time.
>
> On Fri, 2016-05-27 at 20:17 +0100, foss.freedom wrote:
>
> > > Looking on the mentors / mypackages webpage it says that the watch
> > > file I've included does not work.  This is very strange because I ran
> > > a uscan and it correctly downloaded the upstream release file:
>
> > The version we use on mentors is older so that might be the issue.
> > I expect if you use version=3 in the watch file it will work there.
>
> version=3 has been used now and you are quite correct - mentors website no
> longer complains :)
>
> > > In summary - users are requested to upgrade.  Moving forward, the
> > > maintainer intends to branch the project at the next major release
> > > and will backport stuff where necessary (e.g. critical issues).  This
> > > will be very useful for Debian to identify issues to include in
> > > updates.
>
> > Sounds good, please refer to the dev ref for security/stable uploads:
>
> >
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 
> >
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security
> 
>
> Thanks for this - I'll use this info for maintenance of the package moving
> forward in the future.
>
> > I suggest dropping the version number from the Upstream-Name field,
> > since version numbers are usually not in the name of upstream projects.
>
> This has now been corrected.
>
> > > I asked this upstream:
> https://github.com/solus-project/budgie-desktop/issues/448
>
> > Nice response :(
>
> > It doesn't sound like they understood what I was trying to say.
>
> > Perhaps the first paragraph of our upstream guide is more clear:
>
> > https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source
> 
>
>
> > > In the debian/clean I've removed the build artifacts that upstream
> > > have recommended here https://github.com/solus-project/budgie-
> > > desktop/issues/446#issuecomment-221378660
>
> > There was no need to remove those because autoreconf will automatically
> > overwrite them. The other generated files need to be removed though.
>
> I've removed the clean part of the debian/rules as requested.  With
> regards to the build artifacts and other possible package changes, the
> maintainer has pointed us to this:
> https://github.com/solus-project/budgie-desktop/blob/master/README.md#reporting-issues--project-integration
>
> Basically, if we change the upstream release package in anyway without the
> explicit consent of the maintainer and a problem that is reported that is
> found to be because of that change we will lose support.  "Don't make other
> users suffer because you failed to follow our established build and release
> processes. Use standard methods, and we all benefit."
>
>
> > Thanks for the info. I suggest this course of action in parallel to
> > finding a sponsor for budgie-desktop:
>
> > For each of natray and gvc:
>
> > First, get the embedded code copies documented according to this:
>
> > https://wiki.debian.org/EmbeddedCodeCopies
> 
>
> I looked at that link  - are you asking me to file bug reports to debian
> with the following body text?
>
> "Source: natray
> Severity: normal
> Usertags: embed"
>
> or
>
> "Source: gvc
> Severity: normal
> Usertags: embed"
>
>
> > Second, find out where they are developed and talk with upstream about
> > making these stable projects that are released and can be used as
> > shared libraries by each of the projects using them.
>
> The

Bug#828784: O: acoustid-fingerprinter

[Jerome Charaoui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm not interested in maintaining this package anymore. Upstream has not
made a release in nearly 4 years and several superior solutions are now
available to generate and submit fingerprints, such as Picard.

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXcYHsAAoJEIPjO9fU3UyhxM0P/2fUMURScIKd5QKjMuuaHEqR
kRP4Lgy3zTZgTEVYwKAwgv+7PZxSBL7bq2D0IcdyL14DsHNz97kUQA5Tob2A0dPY
flGJ4DkJ+0PWqqcp8lZCZG1yl49Yv38x8cYLtbLQRSb/MuAjV8rBVT1PFj967fVq
Dt0qJ/R2bXonUyOMok89u+Q0nB8WvGgm2WiXCDcB4DCoKhZhQ4ST46juaRDmp2Yk
f5d71xeQANOwOI0jUa9x7mh/3/Xyl1HIaIKge01ebMktnNWihlB3ihd38MGLXGhd
DfadBWnyX9rsFnLKOe2oRLzq6m7uo5ptTksqCOEXB+ts2JHDOvYtVsHEQpIAs9lo
oNo8e6J08IFn0eIXJpcg5IIO+/qwrzHSqrfsSBcspQ3nD/ll7Nr6C1V57enokwXP
BMEKDzii0ctoIyZdqDm8OR4E19XM7io8g4zdU814qASDKFh60mshXsvNw6zfQQCZ
SDf7sO8wMV0GDxaOeMOHeePtA7GQxxIVmdm0ssFcG2W3ZLzR3WU5pOHDHF8DK4Xb
Xmcm9+hnto11lj4Yp9NszfbwmS4shP8Try/OG3HQ6wyqfq7cMr+gQlEmZ3ft2Jnn
kC6C0P68ucydOucPJfd0loH11MOM9XmF6WiNymtCyo4ET0dRs6t/oVrh+tc6Nzni
WOuTy05G7GkCWkMWfDt9
=Y0fK
-END PGP SIGNATURE-

Bug#828783: qtwebkit-examples-opensource-src: FTBFS in testing (imageanalyzer.pro lacks an install target)

[Santiago Vila]

Package: src:qtwebkit-examples-opensource-src
Version: 5.5.1+dfsg-2
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
Severity: serious

Dear maintainer:

This package currently fails to build in stretch:


[...]
cd imageanalyzer/ && ( test -e Makefile || 
/usr/lib/x86_64-linux-gnu/qt5/bin/qmake 
/<>/qtwebkit-examples-opensource-src-5.5.1+dfsg/examples/webkitwidgets/imageanalyzer/imageanalyzer.pro
 -o Makefile ) && make -f Makefile prepare_docs
Project ERROR: 
/<>/qtwebkit-examples-opensource-src-5.5.1+dfsg/examples/webkitwidgets/imageanalyzer/imageanalyzer.pro
 is lacking an install target.
Makefile:737: recipe for target 'sub-imageanalyzer-prepare_docs' failed
make[6]: *** [sub-imageanalyzer-prepare_docs] Error 3


You can find a full build log here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/qtwebkit-examples-opensource-src_5.5.1+dfsg-2.rbuild.log

Thanks.

Bug#828782: libeatmydata1: Please install library setuid

[Nikolaus Rath]

Package: libeatmydata1
Version: 82-6
Severity: normal

Dear Maintainer,

Please consider installing /usr/lib/x86_64-linux-gnu/libeatmydata.so.1.1.2 
with the setuid bit set. Without that, executing some commands (like
fusermount) in eatmydata-enabled chroots give weird error messages like:

$ fusermount -u sshfs_mountpoint
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
$ 

..yet the command also succeeds.

This is because (from ld.so(8)):

   LD_PRELOAD
  A  list of additional, user-specified, ELF shared libraries to be 
loaded before all others.  The
  items of the list can be separated by spaces or colons.  This can 
be used to  selectively  over‐
  ride  functions in other shared libraries.  The libraries are 
searched for using the rules given
  under DESCRIPTION.  For set-user-ID/set-group-ID  ELF  binaries,  
preload  pathnames  containing
  slashes  are  ignored,  and  libraries in the standard search 
directories are loaded only if the
  set-user-ID permission bit is enabled on the library file.


Thanks!
-Nikolaus

Bug#805711: [Pkg-xfce-devel] Bug#805711: Can't easily remove light-locker w/task-xfce-desktop installed

[Yves-Alexis Perez]

On lun., 2016-06-27 at 11:58 -0400, Dominique Brazziel wrote:
> Removing light-locker is non-trivial if task-xfce-desktop is
> installed,
> as all the dependency / recommends packages are removed as well.

That's not really true. Apt will propose to remove them because they were
automatically installed, but you can safely remove task-xfce-desktop, it's a
metapackage. Just mark the other ones as manually installed if you want (using
apt-mark for example).

Regards,
-- 

Yves-Alexis

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

Bug#827935: libqt5core5a: [kfreebsd] QProcessPrivate::createPipe: Cannot create pipe - Function not implemented

[Steven Chamberlain]

Hi Dmitry,

Dmitry Shachnev wrote:
> It was on both -i386 and -amd64 with libqt5core5a 5.6.1+dfsg-2 (and -1).

I was confused, why don't I see it in the kfreebsd-amd64 build log then?

I still see the linker warnings about dup3 and pipe2, but the test
passed?

> Actually, it would be very nice if you could reply to the message linked
> in Forwarded field of this bug:
> 
> https://lists.debian.org/debian-bsd/2016/06/msg00081.html

I don't have an account, but my first thought is that it is not
desirable to add special code upstream for GNU/kFreeBSD.

Today I wrote an implementation of dup3, I will try to do the same for
pipe2 and hopefully we can provide these in our glibc - which may be
useful to other packages than this one.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#828614: yara: FTBFS with openssl 1.1.0

[Hilko Bengen]

* Kurt Roeckx:

>> crypto.h seems to have:
>> # if OPENSSL_API_COMPAT < 0x1010L
>> [...]
>> #  define CRYPTO_num_locks()(0)
>> #  define CRYPTO_set_locking_callback(func)
>> #  define CRYPTO_get_locking_callback() (NULL)
>> #  define CRYPTO_set_add_lock_callback(func)
>> #  define CRYPTO_get_add_lock_callback()(NULL)
>> 
>> I'll look into why they're inside this #if, I think that #if
>> should just get removed.
>
> When I test it myself, it just works?   It only fails when I
> actually try -DOPENSSL_API_COMPAT=0x1010L

Shouldn't the constants that may be used with the callback function
before 1.1 (CRYPTO_LOCK, CRYPTO_UNLOCK, CRYPTO_READ, CRYPTO_WRITE)
be defined inside the "#if OPENSSL_API_COMPAT < 0x1010L" block?

Cheers,
-Hilko

Bug#828614: yara: FTBFS with openssl 1.1.0

[Hilko Bengen]

* Kurt Roeckx:

>> 2. i2c_ASN1_INTEGER() is no longer available outside the OpenSSL code
>>base. What am I supposed to use instead? (What is this "context
>>encoding", anyway?)
>
> I think you mean "content".  

Yes.

> I didn't really look all that close at the asn1 stuff, but from what I
> understand it's contains the content bytes in asn1 format, and it's
> probably not something you want to do and you want to do. Can you
> point me to the code.

https://github.com/VirusTotal/yara/blob/master/libyara/modules/pe.c#L1276

Am I correct in assuming that since the X509 certificates' serial
numbers are stored in DER, one should just use i2d_ASN1_INTEGER()
instead?

Cheers,
-Hilko

Bug#828232: amanda: FTBFS with openssl 1.1.0

[jose]

The amanda is failing to configure with openssl 1.1.0.  I have contacted 
the upstream on the mailing list amanda-users and he sent me the 
attached patch.  With the patch amanda configures and compiles, failing 
only during linking in a way I think is not amanda fault:


libtool: link: gcc -Wall -Wextra -Wparentheses 
-Wdeclaration-after-statement -Wmissing-prototypes -Wstrict-prototypes 
-Wmissing-declarations -Wformat -Wformat-security -Wsign-compare 
-Wfloat-equal -Wold-style-definition -Wno-strict-aliasing 
-Wno-unknown-pragmas -Wno-deprecated-declarations -g -O2 -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security -O2 -g -Wall 
-DIGNORE_TAR_ERRORS -fPIE -pie -Wl,-z -Wl,relro -Wl,-z -Wl,now -o 
.libs/amflock-test amflock-test.o -Wl,--export-dynamic -pthread -pthread 
 ./.libs/libamanda.so ./.libs/libtestutils.a -L/usr/lib/x86_64-linux-gnu 
-lcrypto /usr/lib/x86_64-linux-gnu/libcurl.so -lm -lgmodule-2.0 
-lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lnsl -lresolv -pthread 
-Wl,-rpath -Wl,/usr/lib/amanda
/usr/bin/ld: warning: libcrypto.so.1.0.2, needed by 
/usr/lib/x86_64-linux-gnu/libcurl.so, may conflict with libcrypto.so.1.1

./.libs/libamanda.so: undefined reference to `OPENSSL_init_ssl'
collect2: error: ld returned 1 exit status
Makefile:2206: recipe for target 'amflock-test' failed
make[4]: *** [amflock-test] Error 1

I will prepare a new package for the new upstream version amanda 3.3.9.  
In case there is the need of a fast NMU because of this bug, please go 
head.


Kind regards
Jose M Calhariz


On 2016-06-26 11:20, Kurt Roeckx wrote:

Source: amanda
Version: 3.3.8-1
Severity: important
Control: block 827061 by -1

Hi,

OpenSSL 1.1.0 is about to released.  During a rebuild of all packages 
using
OpenSSL this package fail to build.  A log of that build can be found 
at:

https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/amanda_3.3.8-1_amd64-20160529-1404

On https://wiki.openssl.org/index.php/1.1_API_Changes you can see 
various of the

reasons why it might fail.  There are also updated man pages at
https://www.openssl.org/docs/manmaster/ that should contain useful 
information.


There is a libssl-dev package available in experimental that contains a 
recent
snapshot, I suggest you try building against that to see if everything 
works.


If you have problems making things work, feel free to contact us.


Kurt
diff --git a/common-src/glib-util.c b/common-src/glib-util.c
index ff26d53..c6f79dd 100644
--- a/common-src/glib-util.c
+++ b/common-src/glib-util.c
@@ -35,6 +35,8 @@
 
 #ifdef LIBCURL_USE_OPENSSL
 #include 
+#include 
+#if OPENSSL_VERSION_NUMBER < 0x1010L
 static GMutex **openssl_mutex_array;
 static void openssl_lock_callback(int mode, int type, const char *file, int line)
 {
@@ -47,19 +49,23 @@ static void openssl_lock_callback(int mode, int type, const char *file, int line
 	g_mutex_unlock(openssl_mutex_array[type]);
 }
 }
+#endif /* OPENSSL_VERSION_NUMBER */
 
 static void
 init_ssl(void)
 {
+#if OPENSSL_VERSION_NUMBER < 0x1010L
 int i;
-
 openssl_mutex_array = g_new0(GMutex *, CRYPTO_num_locks());
 
+SSL_library_init();
 for (i=0; isecret_key, (int) strlen(hdl->secret_key),
 		 EVP_sha1(), NULL);
 	HMAC_Update(&ctx, (unsigned char*) auth_string->str, auth_string->len);
 	HMAC_Final(&ctx, md->data, &md->len);
 	HMAC_CTX_cleanup(&ctx);
+#else
+	ctx = HMAC_CTX_new();
+	HMAC_CTX_reset(ctx);
+	HMAC_Init_ex(ctx, hdl->secret_key, (int) strlen(hdl->secret_key),
+		 EVP_sha1(), NULL);
+	HMAC_Update(ctx, (unsigned char*) auth_string->str, auth_string->len);
+	HMAC_Final(ctx, md->data, &md->len);
+	HMAC_CTX_free(ctx);
+#endif
 	auth_base64 = s3_base64_encode(md);
 	/* append the new headers */
 	if (is_non_empty_string(hdl->user_token)) {

Bug#828781: jodreports: FTBFS: error: package freemarker.template does not exist

[Chris Lamb]

Source: jodreports
Version: 2.4.0-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

jodreports fails to build from source in unstable/amd64:

  [..]

  Adding debian:GeoTrust_Universal_CA.pem
  Adding debian:GeoTrust_Universal_CA_2.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R4.pem
  Adding debian:GlobalSign_ECC_Root_CA_-_R5.pem
  Adding debian:GlobalSign_Root_CA.pem
  Adding debian:GlobalSign_Root_CA_-_R2.pem
  Adding debian:GlobalSign_Root_CA_-_R3.pem
  Adding debian:Global_Chambersign_Root_-_2008.pem
  Adding debian:Go_Daddy_Class_2_CA.pem
  Adding debian:Go_Daddy_Root_Certificate_Authority_-_G2.pem
  Adding debian:Hellenic_Academic_and_Research_Institutions_RootCA_2011.pem
  Adding debian:Hongkong_Post_Root_CA_1.pem
  Adding debian:IGC_A.pem
  Adding debian:IdenTrust_Commercial_Root_CA_1.pem
  Adding debian:IdenTrust_Public_Sector_Root_CA_1.pem
  Adding debian:Izenpe.com.pem
  Adding debian:Juur-SK.pem
  Adding debian:Microsec_e-Szigno_Root_CA.pem
  Adding debian:Microsec_e-Szigno_Root_CA_2009.pem
  Adding debian:NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem
  Adding debian:NetLock_Business_=Class_B=_Root.pem
  Adding debian:NetLock_Express_=Class_C=_Root.pem
  Adding debian:NetLock_Notary_=Class_A=_Root.pem
  Adding debian:NetLock_Qualified_=Class_QA=_Root.pem
  Adding debian:Network_Solutions_Certificate_Authority.pem
  Adding debian:OISTE_WISeKey_Global_Root_GA_CA.pem
  Adding debian:OISTE_WISeKey_Global_Root_GB_CA.pem
  Adding debian:PSCProcert.pem
  Adding debian:QuoVadis_Root_CA.pem
  Adding debian:QuoVadis_Root_CA_1_G3.pem
  Adding debian:QuoVadis_Root_CA_2.pem
  Adding debian:QuoVadis_Root_CA_2_G3.pem
  Adding debian:QuoVadis_Root_CA_3.pem
  Adding debian:QuoVadis_Root_CA_3_G3.pem
  Adding debian:RSA_Security_2048_v3.pem
  Adding debian:Root_CA_Generalitat_Valenciana.pem
  Adding debian:S-TRUST_Authentication_and_Encryption_Root_CA_2005_PN.pem
  Adding debian:S-TRUST_Universal_Root_CA.pem
  Adding debian:SecureSign_RootCA11.pem
  Adding debian:SecureTrust_CA.pem
  Adding debian:Secure_Global_CA.pem
  Adding debian:Security_Communication_EV_RootCA1.pem
  Adding debian:Security_Communication_RootCA2.pem
  Adding debian:Security_Communication_Root_CA.pem
  Adding debian:Sonera_Class_1_Root_CA.pem
  Adding debian:Sonera_Class_2_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_EV_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_Root_CA.pem
  Adding debian:Staat_der_Nederlanden_Root_CA_-_G2.pem
  Adding debian:Staat_der_Nederlanden_Root_CA_-_G3.pem
  Adding debian:Starfield_Class_2_CA.pem
  Adding debian:Starfield_Root_Certificate_Authority_-_G2.pem
  Adding debian:Starfield_Services_Root_Certificate_Authority_-_G2.pem
  Adding debian:StartCom_Certification_Authority.pem
  Adding debian:StartCom_Certification_Authority_2.pem
  Adding debian:StartCom_Certification_Authority_G2.pem
  Adding debian:SwissSign_Gold_CA_-_G2.pem
  Adding debian:SwissSign_Platinum_CA_-_G2.pem
  Adding debian:SwissSign_Silver_CA_-_G2.pem
  Adding debian:Swisscom_Root_CA_1.pem
  Adding debian:Swisscom_Root_CA_2.pem
  Adding debian:Swisscom_Root_EV_CA_2.pem
  Adding debian:T-TeleSec_GlobalRoot_Class_2.pem
  Adding debian:T-TeleSec_GlobalRoot_Class_3.pem
  Adding debian:TC_TrustCenter_Class_3_CA_II.pem
  Adding debian:TURKTRUST_Certificate_Services_Provider_Root_2007.pem
  Adding debian:TWCA_Global_Root_CA.pem
  Adding debian:TWCA_Root_Certification_Authority.pem
  Adding debian:Taiwan_GRCA.pem
  Adding debian:TeliaSonera_Root_CA_v1.pem
  Adding debian:Trustis_FPS_Root_CA.pem
  Adding debian:TÜBİTAK_UEKAE_Kök_Sertifika_Hizmet_Sağlayıcısı_-_Sürüm_3.pem
  Adding debian:TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H5.pem
  Adding debian:TÜRKTRUST_Elektronik_Sertifika_Hizmet_Sağlayıcısı_H6.pem
  Adding debian:USERTrust_ECC_Certification_Authority.pem
  Adding debian:USERTrust_RSA_Certification_Authority.pem
  Adding debian:UTN_USERFirst_Email_Root_CA.pem
  Adding debian:UTN_USERFirst_Hardware_Root_CA.pem
  Adding debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G4.pem
  Adding debian:VeriSign_Class_3_Public_Primary_Certification_Authority_-_G5.pem
  Adding debian:VeriSign_Universal_Root_Certification_Authority.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.pem
  Adding debian:Verisign_Class_3_Public_Primary_Certification_Authority_-_G3.pem
  Adding debian:Ve

Bug#828483: osslsigncode: FTBFS with openssl 1.1.0

[Kurt Roeckx]

On Mon, Jun 27, 2016 at 09:02:56PM +0200, Stephen Kitt wrote:
> 
> Right, that's the impression I'm getting too -- in particular for
> osssigncode, the associated SET_OF and i2d/d2i functionality appears to have
> changed (or rather, been replaced by other approaches)...

If you need help I suggest you ask on openssl-us...@openssl.org,
I don't know enough details to help.


Kurt

Bug#823165: metview: FTBFS: /usr/bin/ld: cannot find -lpython2.7

[Santiago Vila]

found 823165 4.6.5-4
thanks

Dear maintainer:

This package FTBFS in testing. This is what happens now:

--
[...] /usr/bin/ld: cannot find -lpython3.5m
--

Since this is (apparently) the same as Bug#823165, I suppose it was
not really fixed after all, so I'm just reopening the old bug.

You can find a full build log here:

https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/metview_4.6.5-4.rbuild.log

Thanks.

Bug#828780: iptraf: please make the build reproducible

[Reiner Herrmann]

Source: iptraf
Version: 3.0.0-8.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: uname
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that iptraf could not be built reproducibly.
It embeds the kernel- and machine name into the binary.

The attached patch removes this information, as it is not interesting
to the user on which architecture the binary was built.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/src/iptraf.c b/src/iptraf.c
index c386a89..3db09ed 100644
--- a/src/iptraf.c
+++ b/src/iptraf.c
@@ -261,7 +261,6 @@ void program_interface(struct OPTIONS *options,
 
 if (opt == 0) {
 attrset(STATUSBARATTR);
-mvprintw(LINES - 1, 1, PLATFORM);
 about();
 
 tx_initmenu(&menu, 13, 35, (LINES - 14) / 2, (COLS - 35) / 2,


signature.asc
Description: Digital signature