date:20171204

Hi Paul,

> It would be great if lintian could detect inconsistencies between
> Files-Excluded in debian/copyright and the files in the upstream
> tarball.

Good idea. I actually rejected liborcus (0.13.1-2) from NEW yesterday
with this inconsistency, resulting in:

  1 liborcus (0.13.1-3) experimental; urgency=medium
  2 
  3   * actually remove Files-Excluded: files...
  4   * debian/copyright: mention Markus Morhard (src/parser/win_stdint.h)
  5 
  6  -- Rene Engelhard   Mon, 04 Dec 2017 17:33:59 +0100


Regards,

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

Bug#883558: linux: not yet ready to enter testing

Source: linux
Version: 4.14.2-1
Severity: serious
Justification: not yet ready for entering testing

Hi

We think 4.14.2-1 should not yet enter testing, thus filling a
blocking bug to preventing migration.

We will close the bug as soon we think 4.14.2-1 or an increment is
good.

Regards,
Salvatore

Bug#883557: lintian: detect files present in the upstream tarball that match Files-Excluded patterns

2017-12-04 Thread Paul Wise

Package: lintian
Severity: wishlist

It would be great if lintian could detect inconsistencies between
Files-Excluded in debian/copyright and the files in the upstream
tarball. The files in the tarball should never match the patterns
listed in the Files-Excluded field because uscan should have removed
them when repacking the tarball. If there are files that match, then
this is a sign that the maintainer didn't do the required repacking,
possibly because they used a very old uscan or didn't use uscan at all.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#866980: Won't fix

2017-12-04 Thread Andreas Tille

Hi Olivier,

On Wed, 27 Sep 2017 you wrote:
> As this package version is deprecated in favor of biomaj3 (in NEW queue at
> this time), this is not really needed to fix.

Since biomaj3 is available now do you want to open a Request Of Removal bug
to get this settled?

I'd also think that the bug is only closes in the case that package
python3-biomaj3 "Provides: biomaj" to provide a clean upgrade path.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#876840: fseeko() on reference file: Invalid argument (Was: Bug#876840: staden-io-lib FTBFS on non-i386 32bit: FAIL: java)

2017-12-04 Thread Andreas Tille

Hi again James,

this is a kind ping since as I wrote below the issue seems not be solved.

Kind regards

Andreas.

On Thu, Sep 28, 2017 at 04:24:19PM +0200, Andreas Tille wrote:
> Hi James,
> 
> I uploaded staden-io-lib now with your patch which solved the other bug.
> 
> On Thu, Sep 28, 2017 at 10:11:50AM +0100, James Bonfield wrote:
> > > On Tue, Sep 26, 2017 at 10:38:12PM +0200, Christian Seiler wrote:
> > 
> > Debugging the code for this test case shows it is doing fseeko with
> > offset 8 (on a working machine), SEEK_SET.  Strace shows this as an
> > lseek SEEK_SET to offset 0 and a read of 8 for some reason, but it
> > amounts to the same thing.
> > 
> > I'll try and find a qemu / virtual machine of one of the affected
> > architectures to test on.
> > 
> > My money is on something odd to do with large file support (it's a
> > total minefield) and changing of types.  Eg bad prototypes leading to
> > 32-bit to 64-bit type changes yielding a daft interpretation of offset
> > and/or whence.
> > 
> > I see bgzip.c doesn't have the standard boilerplate header setup of:
> > 
> > #ifdef HAVE_CONFIG_H
> > #include "io_lib_config.h"
> > #endif
> > 
> > Does adding that fix the fseeko call to start working again?
> 
> Unfortunately not - see here the build logs:
> 
> https://buildd.debian.org/status/package.php?p=staden-io-lib
> 
> Thanks for your quick response in any case
> 
>Andreas.

-- 
http://fam-tille.de

Bug#865537: stretch-pu: plasma 5.8.7 LTS pre-approval

2017-12-04 Thread Kyle Janse van Rensburg

Any news on getting us on plasma 5.8.8?

Bug#883556: libsqlite3-0-dbg: missing Build-Ids, please drop -dbg package in favour of automatic -dbgsym packages

2017-12-04 Thread Paul Wise

Package: libsqlite3-0-dbg
Version: 3.21.0-1
Severity: wishlist
Usertags: dbgsym

The libsqlite3-0-dbg package is missing Build-Ids for some files,
please drop the -dbg package in favour of automatic -dbgsym packages.

https://wiki.debian.org/AutomaticDebugPackages
https://lintian.debian.org/tags/debian-control-has-obsolete-dbg-package.html

$ find-dbgsym-packages 
/var/crash/1000/5898-1000-1000-11-1512446696-chianamo--usr-lib-tracker-tracker-store.core
 |& grep sqlite
Cannot find debug package for libsqlite3.so.0 
(00abea0a7a967792f9bc9a4451e87a11c6422855)
$ dpkg -L libsqlite3-0-dbg  | sed -n 's/.*build-id.//;s/\.debug$//p' | tr -d /
00abea0a7a967792f9bc9a4451e87a11c6422855
63ec44572953ec25f41d3ac54669c5e8f87e4d41
c88251158cbd970fd1e138c831e33620e8767021
efb966dcb688a17e82834c3e6ae9cc4a90fcb659
fde098258e504081f188151ef47322608ae51f67
$ apt-cache show libsqlite3-0-dbg | grep Build
Build-Ids: 63ec44572953ec25f41d3ac54669c5e8f87e4d41

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libsqlite3-0-dbg depends on:
ii  libsqlite3-0  3.21.0-1

libsqlite3-0-dbg recommends no packages.

libsqlite3-0-dbg suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#883555: apt-get build-dep --arch-only -a mips kde-gtk-config fails

Package: apt
Version: 1.6~alpha5
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:kde-gtk-config

I noticed that apt-get build-dep --arch-only -a mips kde-gtk-config
fails in an amd64 chroot. The final message is that libgtk-3-dev:mips
was not installable.  Now why do I think this is a bug?

1. dose-builddebcheck thinks that kde-gtk-config is satisfiable.
2. If I install libgtk-3-dev:mips before issuing that command, it
   succeeds (and replaces systemd-shim with systemd-sysv).
3. If I install systemd-sysv before that command, it succeeds.

It seems a bit like apt is first resolving the tree around libgtk-3-dev
using systemd-shim and then fails to back down to systemd-sysv for the
full tree. I note that libpam-systemd has a dependency (with this order)
on "systemd-shim | systemd-sysv".

If the issue is not immediately reproducible in an amd64 sid chroot, try
using http://snapshot.debian.org/archive/debian/20171205T034902Z/.

I'll append the full resolver output from sbuild (which is not apt-get
build-dep, but close) to the end of this mail.

Helmut

Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 sbuild-build-depends-kde-gtk-config-dummy:mips : Depends: libgtk-3-dev:mips 
but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
apt-get failed.
E: Package installation failed
Not removing build depends: cloned chroot in use
du: cannot access '/<>': No such file or directory
E: read_command failed to execute du
E: Cannot determine space needed for /<> (du failed)
Reading package lists...
Building dependency tree...
Reading state information...
  MarkInstall sbuild-build-depends-kde-gtk-config-dummy:mips < none -> 
0.invalid.0 @un puN Ib > FU=1
  Installing libc6-dev as Depends of sbuild-build-depends-kde-gtk-config-dummy
MarkInstall libc6-dev:mips < none -> 2.25-3 @un uN Ib > FU=0
Installing libc6 as Depends of libc6-dev
  MarkInstall libc6:mips < none -> 2.25-3 @un uN Ib > FU=0
  Installing libgcc1 as Depends of libc6
MarkInstall libgcc1:mips < none -> 1:7.2.0-16 @un uN Ib > FU=0
Installing gcc-7-base as Depends of libgcc1
  MarkInstall gcc-7-base:mips < none -> 7.2.0-16 @un uN > FU=0
Installing linux-libc-dev as Depends of libc6-dev
  MarkInstall linux-libc-dev:mips < none -> 4.14.2-1 @un uN > FU=0
  Installing libstdc++-7-dev as Depends of 
sbuild-build-depends-kde-gtk-config-dummy
MarkInstall libstdc++-7-dev:mips < none -> 7.2.0-16 @un uN Ib > FU=0
Installing libgcc-7-dev as Depends of libstdc++-7-dev
  MarkInstall libgcc-7-dev:mips < none -> 7.2.0-16 @un uN Ib > FU=0
  Installing libgomp1 as Depends of libgcc-7-dev
MarkInstall libgomp1:mips < none -> 7.2.0-16 @un uN > FU=0
  Installing libatomic1 as Depends of libgcc-7-dev
MarkInstall libatomic1:mips < none -> 7.2.0-16 @un uN > FU=0
Installing libstdc++6 as Depends of libstdc++-7-dev
  MarkInstall libstdc++6:mips < none -> 7.2.0-16 @un uN > FU=0
  Installing cmake as Depends of sbuild-build-depends-kde-gtk-config-dummy
MarkInstall cmake:amd64 < none -> 3.9.5-1 @un uN Ib > FU=0
Installing cmake-data as Depends of cmake
  MarkInstall cmake-data:amd64 < none -> 3.9.5-1 @un uN > FU=0
Installing procps as Depends of cmake
  MarkInstall procps:amd64 < none -> 2:3.3.12-3 @un uN Ib > FU=0
  Installing libncurses5 as Depends of procps
MarkInstall libncurses5:amd64 < none -> 6.0+20171125-1 @un uN > FU=0
  Installing libprocps6 as Depends of procps
MarkInstall libprocps6:amd64 < none -> 2:3.3.12-3 @un uN > FU=0
  Installing lsb-base as Depends of procps
MarkInstall lsb-base:amd64 < none -> 9.20170808 @un uN > FU=0
Installing libarchive13 as Depends of cmake
  MarkInstall libarchive13:amd64 < none -> 3.2.2-3.1 @un uN Ib > FU=0
  Installing liblzo2-2 as Depends of libarchive13
MarkInstall liblzo2-2:amd64 < none -> 2.08-1.2+b2 @un uN > FU=0
Installing libcurl3 as Depends of cmake
  MarkInstall libcurl3:amd64 < none -> 7.57.0-1 @un uN Ib > FU=0
  Installing libgssapi-krb5-2 as Depends of libcurl3
MarkInstall libgssapi-krb5-2:amd64 < none -> 1.15.2-2 @un uN Ib > FU=0
Installing libk5crypto3 as Depends of libgssapi-krb5-2
  MarkInstall libk5crypto3:amd64 < none -> 1.15.2-2 @un uN Ib > FU=0
  Installing libkeyutils1 as Depends of libk5crypto3
MarkInstall libkeyutils1:amd64 < none -> 1.5.9-9.2 @un uN > FU=0
  Installing libkrb5support0 as Depends of libk5crypto3

Bug#883501: ktikz: depends on libpoppler-qt4 which is about to be removed

2017-12-04 Thread Stuart Prescott

Control: tags -1 + help upstream
Control: forwarded 874996 https://github.com/fhackenberger/ktikz/issues/8


On Monday, 4 December 2017 18:41:33 AEDT po...@debian.org wrote:
> ktikz should switch to the Qt5 bindings, or disable Poppler support
> if the former is not possible.

Neither of these are possible other than entirely dropping the KDE version of 
the package and retaining only the Qt version, which is against upstream's 
wishes.

(Was there a deprecation schedule for poppler-qt4 that we missed?)

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#883554: cups keeps breaking network printer with implicitclass:

2017-12-04 Thread David Fries

Package: cups
Version: 2.2.1-8
Severity: important

Dear Maintainer,

It seems to be every day or so the /etc/cups/printers.conf DeviceURI is
modified to replace the version that works with a version that doesn't.
This is printing to a cups system on the local network.
Was working with the cups in Debian jessie.

It doesn't matter if I use a dnssd (auto detected), ipps, ipp, it gets
replaced by,
DeviceURI implicitclass:Canon_BJC-2100
and that doesn't allow it to print.  I've even gone so far as deleting
the printer, the detecting it through the ipp web configuration
interface and after a day or so it goes back to the implicitclass.

Any ideas?

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client2.2.1-8
ii  cups-common2.2.1-8
ii  cups-core-drivers  2.2.1-8
ii  cups-daemon2.2.1-8
ii  cups-filters   1.11.6-3
ii  cups-ppdc  2.2.1-8
ii  cups-server-common 2.2.1-8
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript9.20~dfsg-3.2+deb9u1
ii  libavahi-client3   0.6.32-2
ii  libavahi-common3   0.6.32-2
ii  libc-bin   2.24-11+deb9u1
ii  libc6  2.24-11+deb9u1
ii  libcups2   2.2.1-8
ii  libcupscgi12.2.1-8
ii  libcupsimage2  2.2.1-8
ii  libcupsmime1   2.2.1-8
ii  libcupsppdc1   2.2.1-8
ii  libgcc11:6.3.0-18
ii  libstdc++6 6.3.0-18
ii  libusb-1.0-0   2:1.0.21-1
ii  poppler-utils  0.48.0-2
ii  procps 2:3.3.12-3

Versions of packages cups recommends:
ii  avahi-daemon 0.6.32-2
ii  colord   1.3.3-2
ii  cups-filters [ghostscript-cups]  1.11.6-3
ii  printer-driver-gutenprint5.2.11-1+b2

Versions of packages cups suggests:
ii  cups-bsd   2.2.1-8
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20161201-1
ii  hplip  3.16.11+repack0-3
ii  printer-driver-hpcups  3.16.11+repack0-3
ii  smbclient  2:4.5.12+dfsg-2+deb9u1
ii  udev   232-25+deb9u1

-- Configuration Files:
/etc/default/cups changed:


-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

Bug#836217: retitle to RFP: nfstash -- CLI tools suite implementing NFS client procedures

Hi Sandro,

On Mon, Dec 04, 2017 at 05:19:48PM -0500, Sandro Tosi wrote:
> we dont really use nfstash anymore, so feel free to go ahead; if so i
> can forward you what the ftp master told me back in the days when
> rejecting the package (theres probably a git repo around, somewhere) -
> let me know

Yes that would be appreciated!

Regards,
Salvatore

Bug#883553: update to newer upstream release

2017-12-04 Thread Pirate Praveen

Package: node-es6-promise
version: 3.2.2+ds-1
severity: wishlist

Please update to 4.1.1 release. I have tried to update it in babel
branch (using babel), but tests of node-yargs (in git) fails.

mocha --require ./test/before.js --timeout=8000 --check-leaks
/<>/test/completion.js:7
require('es6-promise').polyfill()
   ^

TypeError: require(...).polyfill is not a function
at Object. (/<>/test/completion.js:7:24)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at /usr/lib/nodejs/mocha/lib/mocha.js:172:27
at Array.forEach (native)
at Mocha.loadFiles (/usr/lib/nodejs/mocha/lib/mocha.js:169:14)
at Mocha.run (/usr/lib/nodejs/mocha/lib/mocha.js:356:31)
at Object. (/usr/lib/nodejs/mocha/bin/_mocha:366:16)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.runMain (module.js:604:10)
at run (bootstrap_node.js:383:7)
at startup (bootstrap_node.js:149:9)
at bootstrap_node.js:496:3



signature.asc
Description: OpenPGP digital signature

Bug#883552: openimageio-tools: missing /usr/bin/iv

2017-12-04 Thread Giovanni "Ivan" Alberotanza

Package: openimageio-tools
Version: 1.8.6~dfsg0-4
Severity: important

Dear Maintainer,

this is the output of the command

dpkg -L openimageio-tools

/.
/usr
/usr/bin
/usr/bin/iconvert
/usr/bin/idiff
/usr/bin/igrep
/usr/bin/iinfo
/usr/bin/maketx
/usr/bin/oiiotool
/usr/share
/usr/share/doc
/usr/share/doc/openimageio-tools
/usr/share/doc/openimageio-tools/changelog.Debian.gz
/usr/share/doc/openimageio-tools/changelog.gz
/usr/share/doc/openimageio-tools/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/iconvert.1.gz
/usr/share/man/man1/idiff.1.gz
/usr/share/man/man1/igrep.1.gz
/usr/share/man/man1/iinfo.1.gz
/usr/share/man/man1/iprocess.1.gz
/usr/share/man/man1/iv.1.gz
/usr/share/man/man1/maketx.1.gz
/usr/share/man/man1/oiiotool.1.gz


as you can see there isn't a /usr/bin/iv executable, nevertheless there
is the relative man page /usr/share/man/man1/iv.1.gz

Indeed in the list of file 
https://packages.debian.org/sid/amd64/openimageio-tools/filelist
/usr/bin/iv is correctely reported.

Best regards,
Giovanni "Ivan" Alberotanza

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

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

Versions of packages openimageio-tools depends on:
ii  libatomic1 7.2.0-16
ii  libboost-atomic1.62.0  1.62.0+dfsg-4+b2
ii  libboost-chrono1.62.0  1.62.0+dfsg-4+b2
ii  libboost-date-time1.62.0   1.62.0+dfsg-4+b2
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4+b2
ii  libboost-system1.62.0  1.62.0+dfsg-4+b2
ii  libboost-thread1.62.0  1.62.0+dfsg-4+b2
ii  libc6  2.25-3
ii  libfreetype6   2.8.1-0.1
ii  libgcc11:7.2.0-16
ii  libgif75.1.4-1
ii  libilmbase12   2.2.0-12
ii  libjpeg62-turbo1:1.5.2-2
ii  libopencolorio1v5  1.0.9~dfsg0-12
ii  libopencv-core3.2  3.2.0+dfsg-4
ii  libopencv-highgui3.2   3.2.0+dfsg-4
ii  libopencv-imgproc3.2   3.2.0+dfsg-4
ii  libopencv-videoio3.2   3.2.0+dfsg-4
ii  libopenexr22   2.2.0-11.1
ii  libopenimageio1.8  1.8.6~dfsg0-4
ii  libopenjp2-7   2.3.0-1
ii  libpng16-161.6.34-1
ii  libraw16   0.18.5-1
ii  libstdc++6 7.2.0-16
ii  libtiff5   4.0.8-6
ii  libwebp6   0.6.0-4
ii  zlib1g 1:1.2.8.dfsg-5

openimageio-tools recommends no packages.

openimageio-tools suggests no packages.

-- no debconf information

Bug#882106: mirror submission for mirror.ufam.edu.br

2017-12-04 Thread Bastian Blank

On Mon, Nov 27, 2017 at 02:36:58PM -0400, Gerson Barreiros wrote:
> One of them is in network 200.129.163.0/24 on one of our datacenters, and
> the other network is 200.129.164.0/24 another Datacenter, geographically
> distant location with another power supply, another optic fiber cable, and
> so on.

Both systems are within the same BGP route, behind the same second to
last hop.  Where exactly is the redundancy?

> Unfortunatellly, we dont have another ISP, but this one ( RNP - Rede
> Nacional de Ensino e Pesquisa ) we know that have redundancy in all aspects
> including backbone.

And what did they tell you after asking for a secondary DNS?

You want to add a mirror that does not even provide the full set of
architectures.  Why do you think I should ignore this problem?

Regards,
Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9

Bug#883550: cgal FTCBFS: configures for the build architecture

Source: cgal
Version: 4.11-2
Severity: minor
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

cgal fails to cross build from source, because it configures for the
build architecture by failing to pass the correct cross toolchain flags
to cmake. The easiest way to fix this is to defer to dh_auto_configure
and that actually makes debian/rules a little simpler. After doing so,
configuration still fails, because it runs try_run checks for
discovering dependency versions. There are approaches for extracting
strings from compiled objects by other means than running them, but this
is non-trivial. I haven't attempted to fix this, but think that cgal
must have regressed upstream in this respect as other parts of it
carefully check CMAKE_CROSSCOMPILING. Please close this bug when
applying the attached patch to make the underlying upstream failure
visible even though cgal will still fail to cross build.

Helmut
diff --minimal -Nru cgal-4.11/debian/changelog cgal-4.11/debian/changelog
--- cgal-4.11/debian/changelog  2017-11-04 19:50:06.0 +0100
+++ cgal-4.11/debian/changelog  2017-12-04 23:01:31.0 +0100
@@ -1,3 +1,11 @@
+cgal (4.11-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Address FCBFS: Let dh_auto_configure pass cross flags to cmake.
+(Closes: #-1)
+
+ -- Helmut Grohne   Mon, 04 Dec 2017 23:01:31 +0100
+
 cgal (4.11-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru cgal-4.11/debian/rules cgal-4.11/debian/rules
--- cgal-4.11/debian/rules  2017-11-04 19:50:06.0 +0100
+++ cgal-4.11/debian/rules  2017-12-04 23:01:29.0 +0100
@@ -39,23 +39,20 @@
 override_dh_auto_configure-arch:
# Fail early if SOVERSION changed
grep -q "CGAL_SONAME_VERSION \"13\"" CMakeLists.txt
-   mkdir -p static
-   cd static && QTDIR= cmake .. \
- -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=Release \
+   QTDIR= dh_auto_configure --builddirectory=static -- \
+ -DCMAKE_BUILD_TYPE=Release \
  -DWITH_GMPXX=ON -DWITH_demos=OFF -DWITH_examples=OFF \
  -DCGAL_ENABLE_PRECONFIG=OFF -DBUILD_SHARED_LIBS=FALSE \
  -DCGAL_INSTALL_LIB_DIR=lib/$(DEB_HOST_MULTIARCH) \
  -DCGAL_INSTALL_CMAKE_DIR=lib/$(DEB_HOST_MULTIARCH)/cmake/CGAL 
$(CMAKE_QT5)
-   mkdir -p shared
-   cd shared && QTDIR= cmake .. \
- -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=Release \
+   QTDIR= dh_auto_configure --builddirectory=shared -- \
+ -DCMAKE_BUILD_TYPE=Release \
  -DWITH_GMPXX=ON -DWITH_demos=OFF -DWITH_examples=OFF \
  -DCGAL_ENABLE_PRECONFIG=OFF -DBUILD_SHARED_LIBS=TRUE 
-DCMAKE_SKIP_RPATH=TRUE \
  -DCGAL_INSTALL_LIB_DIR=lib/$(DEB_HOST_MULTIARCH) \
  -DCGAL_INSTALL_CMAKE_DIR=lib/$(DEB_HOST_MULTIARCH)/cmake/CGAL 
$(CMAKE_QT5)
-   mkdir -p shared/demo/CGAL_ipelets
-   cd shared/demo/CGAL_ipelets && QTDIR= cmake ../../../demo/CGAL_ipelets \
- -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=Release \
+   QTDIR= dh_auto_configure --builddirectory=shared/demo/CGAL_ipelets 
--sourcedirectory=demo/CGAL_ipelets -- \
+ -DCMAKE_BUILD_TYPE=Release \
  -DCGAL_DIR=$(CURDIR)/shared
 
 override_dh_auto_configure-indep:

Bug#883551: sane: samsung mfc cannot scann

2017-12-04 Thread Andreas Matthus

Package: sane
Version: 1.0.14-12
Severity: normal

Dear Maintainer,

by using samsung multifunction-devices sane works only some seconds after
plugin the usb-cable. After that printing is possible but no scanning.

Solution:
1. comment out the device-line in
/etc/sane.d/xerox_mfp.conf
2. Add
deb http://www.bchemnet.com/suldr/ debian extra
to /etc/apt/sources.list
3. apt update
4. apt install suldr-keyring suld-ppd-2 suld-driver-common-1 suld-
driver-4.01.17 suld-configurator-1-qt4

Then the scanner is no longer ""xerox_mfp:..." but "smfp:SAMSUNG..." and it
works in all situations.

with regards
Andreas Matthus



-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages sane depends on:
ii  libc6 2.24-11+deb9u1
ii  libgimp2.02.8.18-1
ii  libglib2.0-0  2.50.3-2
ii  libgtk2.0-0   2.24.31-2
ii  libsane   1.0.25-4.1

sane recommends no packages.

Versions of packages sane suggests:
ii  gimp  2.8.18-1

-- no debconf information

Bug#883367: RFS: roadfighter/1.0.0-1 [ITP] -- Drive a car in a death race

2017-12-04 Thread Carlos Donizete Froes

Hi Adam,

> Alas, the game segfaults on start, unless ran from a directory containing
> the source tree.  This looks like the same problem as in April 2016.

The binary has to be in the same directory where it finds the data: graphics,
sound and maps.

For the time being, I did not learn to work using "debian/rules" or creating a
script in the debian directory.

> There's also the unfixed problem of some assets: the .ogg files bear
> metadata saying they come from Konami.

Thank you for notifying us of this case. I corrected this bug with some sounds
and changed the metadata. It's in my GitHub account.[1]

[1] - https://github.com/coringao/roadfighter/tree/master/sound

> Also, fullscreening doesn't work on multi-monitor setups.  It doesn't obey
> settings such as which monitor is primary, orientation or positions (most
> programs that fail here at least go to (0,0)).  This puts the game on the
> wrong monitor, rotated.  Even worse, it permanently destroys randr settings
> -- desktop environments (at least XFCE) save modifications, thus setting
> everything from scratch is required.
> 
> Some displays don't allow non-native resolutions at all.

The resolution of this game is 512x384 in window mode by default.

You do not have the option to play full screen at the moment.

I'm still working with the source code of this game to have this option.

> As far as I know, fixing this is possible but quite tricky in SDL1.2, a
> non-issue in SDL2 which doesn't ever try to change resolutions (impossible
> on non-CRTs anyway) but tells the GPU to scale.

I am a week ago going to SDL2 version of this game, will soon have version 1.1.0

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#882810: RFS: jag/0.3.3-1 [ITP] -- arcade-puzzle 2D game in which you have to break all the target pieces

2017-12-04 Thread Carlos Donizete Froes

Hi Adam

> However, it crashes a lot.
> 
> For example, try to enable fullscreen -> SIGSEGV.
> 
> Exit -> SIGABRT:
> #0  0x7f4207738a70 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f420773a19a in __GI_abort () at abort.c:89
> #2  0x7f4201b78744 in _dbus_abort () at /lib/x86_64-linux-gnu/libdbus-
> 1.so.3
> .

This did not happen on my machine, other than a bug not related to the game, but
from the SDL2 library.

---

dbus[18767]: arguments to dbus_connection_unref() were incorrect, assertion
"connection->generation == _dbus_current_generation" failed in file
../../../dbus/dbus-connection.c line 2822.
This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace

Thread 8 "QDBusConnection" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffbcb29700 (LWP 18778)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51

---

This bug reported on bugzilla SDL2, but so far I have not got answers.[1]

[1] - https://bugzilla.libsdl.org/show_bug.cgi?id=3978

> Autopkgtest that consists of "Test-Command: /bin/true" is not exactly of any
> use.  Please remove that, or replace with an actual test (although I don't
> see what could be testable this way in a graphical game).

Unfortunately, I have not yet learned to use autopkgtest. After the end of
"debuild", lintian notifies me to add autopkgtest where I chose to do it
erroneously to pass. :(

> Package short descs are not supposed to be in title case, unless it's an
> actual title -- "Arcade and Puzzle 2D Game" is not.

It was to be "arcade-puzzle 2D game in which you have to break all the target
pieces", but it went beyond line 60 of the title.

> The man page lists documentation sections as if they were arguments that can
> be passed to the executable.

The man page in my opinion this is normal showing the details about the game.
But if you want me to change something in it or you want to change, feel free.
;)

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#845297: Website transition from CVS to Git - now with cvs-revisions file

2017-12-04 Thread Paul Wise

On Mon, 4 Dec 2017 14:50:41 +0100 Laura Arjona Reina wrote:

> I've done another "git cvsimport" conversion, this time with the -R
> option so we get a file "cvs-revisions" mapping each file+cvsrevision to
> the corresponding git commit.

Great, we could use that for a redirector from viewvc to cgit URLs.

I was thinking the revision info should be in the commit messages too,
so that anyone can look up historical CVS version numbers in gitk.

Based on Osamu Aoki's git-cvs sync code I've come up with the attached
script that works for me with a small CVS repository. Like git-cvs,
the script rsyncs the repository locally for faster conversion.
I haven't tried it on the full webwml CVS repository. The additions to
the git commit logs are customisable. The script also adds itself to
the git history as a record of exactly how the conversion was done.
It needs customising to set your username and to switch from the small
CVS repository to webwml.

> -A ./cvs_authors_20170820.txt

I couldn't find a copy of this, is it online somewhere?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

cvs2git
Description: CVS to git conversion script, preserves CVS revision numbers

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

Bug#810455: marked as done (quisk: please switch to libusb 1.0)

2017-12-04 Thread aldo.zav...@gmail.com

unsubscribe

On Mon, Dec 4, 2017 at 7:51 PM, Debian Bug Tracking System <
debianbugtrackingsystemadministra...@bendel.debian.org> wrote:

> Your message dated Tue, 05 Dec 2017 03:50:04 +
> with message-id 
> and subject line Bug#810455: fixed in quisk 4.1.12-1
> has caused the Debian Bug report #810455,
> regarding quisk: please switch to libusb 1.0
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 810455: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810455
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: Aurelien Jarno 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Fri, 8 Jan 2016 19:38:48 +0100
> Subject: quisk: please switch to libusb 1.0
> Package: quisk
> Version: 3.7.6-1
> Severity: wishlist
>
> Dear Maintainer,
>
> quisk has a build-depends on libusb-dev. A few years ago upstream
> has released a new major version libusb 1.0 with a different API which
> aims to fix design deficiencies with USB 2.0 and 3.0 in mind.
>
> The old libusb 0.1 package is not supported upstream anymore and should
> be considered deprecated.
>
> If quisk supports the new libusb 1.0 library, please consider
> switching the build-depends from libusb-dev to libusb-1.0-0-dev. If not
> please inform upstream that porting the software to the new API is
> recommended.
>
> Thanks,
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>
>
> -- Forwarded message --
> From: "A. Maitland Bottoms" 
> To: 810455-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 05 Dec 2017 03:50:04 +
> Subject: Bug#810455: fixed in quisk 4.1.12-1
> Source: quisk
> Source-Version: 4.1.12-1
>
> We believe that the bug you reported is fixed in the latest version of
> quisk, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 810...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> A. Maitland Bottoms  (supplier of updated quisk
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Mon, 04 Dec 2017 18:44:47 -0500
> Source: quisk
> Binary: quisk
> Architecture: source
> Version: 4.1.12-1
> Distribution: unstable
> Urgency: medium
> Maintainer: A. Maitland Bottoms 
> Changed-By: A. Maitland Bottoms 
> Description:
>  quisk  - Software Defined Radio (SDR)
> Closes: 747944 810455
> Changes:
>  quisk (4.1.12-1) unstable; urgency=medium
>  .
>* New upstream release
>* Default config works (Closes: #747944) (LP: #1022391)
>* Use libusb-1.0 (Closes: #810455)
> Checksums-Sha1:
>  5896d8bf9b8b72c3203a640c1627fa859a49008e 2114 quisk_4.1.12-1.dsc
>  1359b69837f977e880232ff33fa30d0128523fb3 15976
> quisk_4.1.12.orig-charleston.tar.xz
>  76d589c8e24b68332ed54dab4e5bbcbb66a6760b 297100 quisk_4.1.12.orig.tar.xz
>  110bfbddc9678fa9da66f026a934b57ce875fc3c 8868
> quisk_4.1.12-1.debian.tar.xz
>  2d97f46cf47f303a77c81db551f0ff7d4a093b35 10710
> quisk_4.1.12-1_amd64.buildinfo
> Checksums-Sha256:
>  801dbbba11a920154758426d49cabbec1059f6cfbdbf626ff8f4c3cc0c4b08f7 2114
> quisk_4.1.12-1.dsc
>  1ea1d72fbf3a81e243abd22f442d0991468f40b3181e3a8402ae590dc0624ab6 15976
> quisk_4.1.12.orig-charleston.tar.xz
>  ffc9ffb532c0c464e56a50813577ad22ecead118417bda2718b6d59005cd006a 297100
> quisk_4.1.12.orig.tar.xz
>  21d3e758d0166afb4ef511f38c34ddfff65b87bf65f229b6e4d466b77b98320a 8868
> quisk_4.1.12-1.debian.tar.xz
>  229f5852a64cc6ef87382444a361ba6c1f1ddaf48e325d6dd1c255bd221cce47 10710
> quisk_4.1.12-1_amd64.buildinfo
> Files:
>  0e9d1d3c460e4bff2d17efc9ad95036e 2114 hamradio optional
> quisk_4.1.12-1.dsc
>  53fdce7df14933439bb236e180169e4f 15976 hamradio optional
> quisk_4.1.12.orig-charleston.tar.xz
>  b4820a7d655524f6e439ef97aa9825e3 297100 hamradio optional
> quisk_4.1.12.orig.tar.xz
>  cba3ca79376f31678dbe3ce860128d6a 8868 hamradio optional
> quisk_4.1.12-1.debian.tar.xz
>

Bug#883549: Debian Installer Buster Alpha 1 release - Hardware support of Xunlong Orange Pi zero

2017-12-04 Thread Vasilis

Package: debian-installer-9-netboot-armhf
Version: 20170615+deb9u2

Tested the netinstall version
(debian-buster-DI-alpha1-armhf-netinst.iso) in a Xunlong Orange Pi zero
device and it seems that the board is not booting up --both ethernet
LEDs are on. I attached a serial cable to troubleshot the installation
but I don't see any output (perhaps the serial console is disabled).

According to the 'Hardware support changes' section
(https://www.debian.org/devel/debian-installer/News/2017/20170903) in
the release post the Orange Pi zero system seems to be supported:
"Add machine db entries for various sunxi-based systems that are (at
least partially) supported in kernel 4.12 and u-boot v2017.07-rc3:
Banana Pi BPI-M2-Plus, FriendlyArm NanoPi M1, FriendlyARM NanoPi NEO
Air, Lichee Pi Zero, NextThing C.H.I.P. Pro, Xunlong Orange Pi Zero."

Does this mean that these boards be supported by the installer and if
yes how one can test the installation on these boards?

Happy to do any further tests.



signature.asc
Description: OpenPGP digital signature

Bug#883548: chdist apt should use proxy configured in host

2017-12-04 Thread Pirate Praveen

package: devscripts
version: 2.7.11

Currently the chdist step in build-and-upload script (from
pkg-ruby-extras) take a long time even though, sbuild and autopkgtest
completes much faster because it use apt-cacher-ng.

Please take proxy configuration from host's apt configuration.



signature.asc
Description: OpenPGP digital signature

Bug#882810: RFS: jag/0.3.3-1 [ITP] -- arcade-puzzle 2D game in which you have to break all the target pieces

On Tue, Dec 05, 2017 at 12:09:40AM -0200, Carlos Donizete Froes wrote:
> Em seg, 2017-12-04 às 23:45 +0100, Adam Borowski escreveu:
> > It FTBFSes unless I add libqt5opengl5-dev to Build-Depends.
> 
> I forgot to add this library to the package. Now I have made the package again
> this added. :)
> 
> > On startup, it dies with:
> > (It should look in /usr/share/games/jag/data/)
> 
> Fixed in this package.

It builds and starts now.

However, it crashes a lot.

For example, try to enable fullscreen -> SIGSEGV.

Exit -> SIGABRT:
#0  0x7f4207738a70 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7f420773a19a in __GI_abort () at abort.c:89
#2  0x7f4201b78744 in _dbus_abort () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#3  0x7f4201b6f130 in _dbus_strdup () at 
/lib/x86_64-linux-gnu/libdbus-1.so.3
#4  0x7f4201b5549a in  () at /lib/x86_64-linux-gnu/libdbus-1.so.3
#5  0x7f4201b52344 in dbus_bus_remove_match () at 
/lib/x86_64-linux-gnu/libdbus-1.so.3
#6  0x7f41fc52be1e in  () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7f41fc52cc3c in  () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#8  0x7f4208ab48c2 in QObject::event(QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x7f4208a85241 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7f4208a879cd in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) ()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7f4208adeac3 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f4202b55fa7 in g_main_context_dispatch () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7f4202b561e0 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7f4202b5626c in g_main_context_iteration () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7f4208ade0ef in 
QEventDispatcherGlib::processEvents(QFlags) ()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7f4208a832aa in 
QEventLoop::exec(QFlags) ()
at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7f42088a235a in QThread::exec() () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x7f41fc51ce45 in  () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#19 0x7f42088a722d in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x7f4208358519 in start_thread (arg=0x7f41d919d700) at 
pthread_create.c:456
#21 0x7f42077f1a5f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Also, a minor issue: on a multi-monitor setup, it makes a big window that
spans all monitors; this can be worked around by setting the size to
something just smaller than one of the monitors (because fullscreen crashes,
and window decoration takes some space), after which it works ok.

Otherwise, the game seems to work ok.

Autopkgtest that consists of "Test-Command: /bin/true" is not exactly of any
use.  Please remove that, or replace with an actual test (although I don't
see what could be testable this way in a graphical game).

Package short descs are not supposed to be in title case, unless it's an
actual title -- "Arcade and Puzzle 2D Game" is not.

The man page lists documentation sections as if they were arguments that can
be passed to the executable.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 14:13 < icenowy[m]> are they hot enough? ;-)
⣾⠁⢰⠒⠀⣿⡁ 14:17 < icenowy[m]> I think now in Europe it should be winter? Let
⢿⡄⠘⠷⠚⠋⠀ the BPi warm you ;-)
⠈⠳⣄ 14:17 <@KotCzarny> yeah, i have a pc to warm me ;)

Bug#883340: dgit build accesses the internet and fails when offline.

2017-12-04 Thread peter green


(resending this to the bug report and also extending it slightly beyond the 
original version I sent to Ian)

On 04/12/17 12:30, Ian Jackson wrote:

peter green writes ("Bug#883340: dgit build accesses the internet and fails when 
offline."):

Trying to build a package with dgit build while offline results in an error 
message about api.ftp-master.debian.org There is no mention in the manpage 
section for dgit build about it accessing the internet in any way.

This is problematic for two reasons.

1. It is really annoying to be unable to work while offline.
2. Undocumented access to the internet could be considered a privacy breach.

This is, sadly, inevitable, when using `dgit build'.

The reason is as follows:

dgit build (and dgit sbuild et al) do all the preparation work needed
to do a binary upload using dgit push.  That includes generating the
.changes file.It would not be good to defer generation of the .changes
file because the user ought to be able to review everything before
invoking dgit push.

dgit push already modifies the changes file to add the dgit: header to the dsc 
and to sign everything.


The .changes file is supposed to contain changes since the last upload
to the relevant distro.  That involves knowing what that last upload
is.  dgit automates this, querying the prospective destination server
so it can know the version to pass to dpkg-genchanges's -v option.
But, if the user were doing this by hand, they would probably have to
check that themselves by hand anyway.

I expect the reality is that most developers run dpkg-buildpackage and upload 
the changes file that it spits out.  AIUI this does the right thing most of the 
time but there are some corner cases where it does not. For example if the 
version corresponding to a given changelog entry is never uploaded.

AIUI what you are saying is that dgit wants to fix up these corner cases and 
needs internet access to do so.

Is this understanding correct.


So it is not possible to fully prepare a build-for-upload offline.


OTOH, if you are not trying to build for upload, then then there is no
need for this.  Then it would be better not to use dgit build at all,
but rather to invoke dpkg-buildpackage.

Perhaps it would be useful for dgit to have a "not (yet) for upload"
build option, which generates source and binary packages, but not a
.changes file.

What do you think ?

It seems to me that "dgit build" or "dgit build-source" does two categories of 
things on top of what dpkg-buildpackage does.

1. It does stuff related to building from a dgit git tree, including checking the working 
tree matches the head (and erroring out if not), checking the quilt series matches head 
(and fixing it if not) and excluding the ".git" directory from the resulting 
source packages. Maybe there is other stuff too.
2. It tries to ensure a "more correct" changes file at the cost of requiring 
Internet access.

1 is the reason for using dgit build in the first place.

2 was unexpected to me and I would expect to a lot of users.



TBH I would like to know what you were trying to do when you
encountered this problem

I was working on testing my autoforwardporter on a machine that happened to be 
offline.

  - and which docs you read that led you to
choose this approach.

I think it was a mixture of reading the dgit manpage and trial and error.


I would like to improve the docs.


In the meantime, a workaround would be to pass a -v option to dgit.
Then it would have no need to talk to an archive server to find this
information; and there is no other information in a build that comes
from off the local machine.

Thanks.

Specifically from re-reading the manpage and from testing it seems passing -v_ 
is the solution to making dgit build work offline but I wouldn't have found it 
if I hadn't been explicitly looking for the -v option.

So it seems that the main things that are needed are.

1. Extend the "dgit build" section of the man page to clarify that dgit build 
accesses the Internet by default and how to override that for offline use..
2. Improve the error message so that when people do try to run "dgit build" 
while offline they know how to get around it.

Bug#883547: flash-kernel: please allow flavourless kernels

Package: flash-kernel
Version: 3.88
Severity: wishlist

Hi!
If for whatever reason you want or need to build your own kernels, the
preferred way these days is "make bindeb-pkg".  It is also a good idea
to use CONFIG_LOCALVERSION_AUTO=y, which marks the exact tree used to
build the kernel.

However, with this option, the version is _appended_ after local version,
thus making it hard to add that "-armmp" string.

I found no way to override this, other than manually editing
--- functions~  2017-08-03 05:01:54.0 +0200
+++ functions   2017-12-05 02:39:54.113903579 +0100
@@ -775,11 +775,6 @@
done
 fi
 
-if [ "$kfile_suffix" = "$kfile" ]; then
-   echo "Kernel $kfile does not match any of the expected flavors 
($kflavors), therefore not writing it to flash." >&2
-   exit 0
-fi
-
 echo "flash-kernel: installing version $kvers" >&2
 
 mkarch="$(get_mkimage_architecture $kvers)"


Just allowing an empty string flavour doesn't work, as it'll still want a -
after the version.

Thus, it would nice if there was an override -- or, perhaps, I'm holding it
wrong?


Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.14.0-00115-g3d7c587c4c1b (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  devio  1.2-1.2+b1
ii  initramfs-tools0.130
ii  linux-base 4.5
ii  mtd-utils  1:2.0.1-1
ii  ucf3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2017.09+dfsg1-3

flash-kernel suggests no packages.

-- debconf information excluded

Bug#882810: RFS: jag/0.3.3-1 [ITP] -- arcade-puzzle 2D game in which you have to break all the target pieces

2017-12-04 Thread Carlos Donizete Froes

Hi, Adam

Em seg, 2017-12-04 às 23:45 +0100, Adam Borowski escreveu:
> It FTBFSes unless I add libqt5opengl5-dev to Build-Depends.

I forgot to add this library to the package. Now I have made the package again
this added. :)

> On startup, it dies with:
> .--[ Files are missing ]
> Cannot find data folder
> /usr/loca/games/jag/data/
> JAG will exit now
> ` [ ✗ Close ]
> 
> (It should look in /usr/share/games/jag/data/)

Fixed in this package.

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#881506: xul-ext-gnome-keyring doesn't work with firefox >=57

2017-12-04 Thread Ximin Luo

Control: severity -1 important
Control: tags -1 + upstream
Control: forwarded -1 https://github.com/swick/mozilla-gnome-keyring/issues/48

Mozilla are being slow.

https://bugzilla.mozilla.org/show_bug.cgi?id=309807
https://bugzilla.mozilla.org/show_bug.cgi?id=106400

In the meantime this still works for firefox-esr so I'm downgrading the 
severity to not be RC.

X

Laurent Bigonville:
> Package: xul-ext-gnome-keyring
> Version: 0.12-1
> Severity: serious
> Tags: sid buster
> 
> Hi,
> 
> xul-ext-gnome-keyring does not work with firefox 57 anymore due to the
> the switch webextension.
> 
> The package should probably be removed or fixed to support that.
> 
> Regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.14.0-rc8+ (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 


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

Bug#883455: transition: gnustep-sqlclient

2017-12-04 Thread Yavor Doganov

Emilio Pozuelo Monfort wrote:
> > libsqlclient1.7 -> libsqlclient1.8

> Sure, go ahead.

Thanks, 1.8.1-3 is now built and installed on all architectures.

Please schedule binNMUs for adun.app (you can omit sparc64 as it just
got built there; it was in BD-Uninstallable state due to #880477).

Bug#769380: python3-mako: Please make the package multi-arch compatible

2017-12-04 Thread Manuel A. Fernandez Montecelo

Hi Piotr,

2017-12-04 23:16 GMT+01:00 Piotr Ożarowski :
>> So, Piotr, do you think that any of the options is preferable?
>>
>> If there's no reply I'd like to upload an NMU with a fix for this
>> problem.
>>
>> I think that changing the package to "Architecture: any" and "M-A: same"
>> is safer than dropping a dependency to recommends.  It's not ideal, but
>> in the end is just causes a small overhead, and changing dependencies
>> can even break reverse-depends and introduce bugs difficult to detect.
>
> please point me to the policy if it's already known what's the right
> approach

It's not documented in Policy yet.  The best source of information is:
https://wiki.debian.org/Multiarch

Although probably Ubuntu is best/more accurate/more complete:
https://wiki.ubuntu.com/MultiarchSpec

Abut this package, since the package could be marked "foreign" (as in
"package from foreign arch satisfies dependency") if it was only for
its contents (because it's an arch:all, the same in all arches), but
since it exposes arch-independent behaviour throught dependencies
(i.e. needs to load arch-dependent modules for markupsafe), it cannot
be marked in that way, which is the most beneficial and the original
suggestion.  It has to be marked as "give me the version for the same
architecture that the package to be built that depends on this one".

Despite having binaries in /usr/bin/ and libraries shipped in /usr/lib
but not // (see next url), since they are byte-for-byte the
same across architectures, it should be covered by the same provisions
as if the files were in /usr/include (but not inside subdir
//), /usr/share, etc. -- at least that's how I interpret it.

https://packages.debian.org/sid/all/python-mako/filelist


Regards.
-- 
Manuel A. Fernandez Montecelo

Bug#883546: ejabberd: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2017-12-04 Thread Adriano Rafael Gomes


Package: ejabberd
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#883545: uptimed: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2017-12-04 Thread Adriano Rafael Gomes


Package: uptimed
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#883094: Accessibility: Mate: Screen reader is not available in login screen

2017-12-04 Thread sirgazil


On 04/12/17 16:04, mike.gabr...@das-netzwerkteam.de wrote:

Hi,

On Monday, December 4, 2017, sirgazil wrote:

On 04/12/17 06:18, Mike Gabriel wrote:

Hi,

On  Fr 01 Dez 2017 01:02:25 CET, sirgazil wrote:


On 30/11/17 04:38, Mike Gabriel wrote:

Hi,

On  Mi 29 Nov 2017 16:59:27 CET, sirgazil wrote:


Package: mate-desktop
Version: 1.16.2-2

I'm using Debian Linux zenme 4.9.0-4-686-pae #1 SMP Debian 4.9.51-1
(2017-09-28) i686 GNU/Linux.

When a blind person starts the computer, they don't have any way of
knowing whether the login screen has loaded or not. The system does
not provide any aural cues for blind users, so they have to call
sighted people to help them log in.


Thanks for your feedback on accessibility.

Please note that the MATE desktop does not come with a login manager
itself. It uses a "3rd party product" for session login management.

The default display manager in use for MATE desktop installations is
LightDM.

Please also note that I have recently uploaded the Arctica Greeter, a
fork from Ubuntu's Unity Greeter. Arctica Greeter, like Unity
Greeter, sends a little drum roll to the speaker, so there is indeed
an accoustic signal that the greeter has loaded and the computer is
ready for login.

The greeter has Orca support built-in, so you can enable it (or have
it enabled by default as a system-wide setting that survives reboot
of the computer). Orca then will read to you the different text
fragments you find on the login screen.

I will ping you via this bug, once the Arctica Greeter has landed in
Debian testing.

Please note that such changes as requested / proposed cannot be made
in a Debian stable release, so we need to look forward regarding this
and improve ourselves for Debian 10 (aka buster).

Thanks for your input!
Mike



Thank you for the information, Mike.

I'd like to add that working around this problem by activating Orca
screen reader in the LightDM GTK+ Greeter Settings is not possible
because the greeter hangs when doing so (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883215).

So it seems Debian 9 with Mate is currently not accessible at all to
blind users?


Please note that LightDM GTK+ Greeter is _not_ Arctica Greeter.



Yes, I know that. I was referring to the default greeter that is used in
Debian when you select the Mate desktop in the installation process.



If you are not scared of third party APT repositories, you can get a
build of Arctica Greeter here:

```
deb http://packages.arctica-greeter.org/debian stretch main
```

The GnuPG Archive Key can be obtained this way:

```
wget -qO - http://packages.arctica-project.org/archive.key | sudo
apt-key add -
```

Looking forward for your feedback! Orca can be enable in the greeter
with ALT + SUPER + S.



Well, in this particular case, only Debian stable repositories are allowed.

I'd like to try this workaround on my machine, though, but trying to add
the GPG Archive Key failed:

  # apt-key add archive.key
  gpg: keydb_get_keyblock failed: Value not found




Does archive.key really contain a GPG public key? It seems that the key block 
is missing in the file you use as archive.key. Please check with a text editor 
or pager...


The file looks like a public key; the PUBLIC KEY BLOCK is there.

Trying to import the key in Synaptic results in an error saying that the 
file may not be a GPG key or that it is corrupt, and Synaptic generates 
an entry in the list of Trusted software providers that looks like the 
information in a PO file:


https://multimedialib.files.wordpress.com/2017/12/synaptic-import-key-file.png

So maybe this key file is funny?

Bug#883536: [Pkg-dns-devel] Bug#883536: isc-dhcp FTBFS with libbind-export-dev 1:9.11.2+dfsg-2

2017-12-04 Thread Bernhard Schmidt

Control: tags -1 pending

On 04.12.2017 23:41, Adrian Bunk wrote:

Hi,

> The pattern is clear:
> https://tests.reproducible-builds.org/debian/history/isc-dhcp.html
> 
> I am also able to reproduce it locally.
> 
> Am I guessing correct that merged /usr is used in your
> successful build?

You are, as always, right. Totally forgot that debootstrap defaults to
/usr-merge nowadays. Thanks for the hint.

There is an ugly piece of code fixing that that was lost in
https://anonscm.debian.org/git/pkg-dns/bind9.git/commit/?id=3e1f232b9781bd15ae49369c10c4e96d89a0e734
. I've readded it, looks okay now. This needs to be cleaned up
eventually, but we should reach a version that builds and does not break
other builds first.

Bernhard

Bug#883543: RFA: mathematica-fonts (contrib) -- installer for Mathematica fonts

Package: wnpp
Severity: normal

I request an adopter for the mathematica-fonts package.

The package description is:
 This package downloads Mathematica fonts from http://support.wolfram.com/
 and installs them, because the license prohibits their distribution.
 Please note that it may fail if the web site no longer offers them for
 download.

I'd like to divest myself from this ugly undistributable thing.  I adopted
the package two years ago to fix long-standing uninstallability, but it
turns out upgrading to the current version (Mathematica 11) requires more
effort than I'm willing to give to a package that's not my itch to scratch. 
It does work at the moment, but at any time Mathematica 10 fonts might be
pulled from the old download URL, making the downloader useless once again.

The package is nominally team-maintained by the Fonts Team, but the previous
time, it rotted uninstallable for best part of a year with no one taking
action (gee, guess why?) until I stepped in.

It might sound trivial "just insert the new URL", but I wasted hours trying
to find it on the redesigned site, and no one seems to know (no, I'm not
willing to pay for official tech support).

Bug#883214: Please package new upstream 3.0 version in experimental (with GTK+ 3.0 support)

2017-12-04 Thread Josh Triplett

On Mon, Dec 04, 2017 at 03:01:33PM -0600, Gary Kramlich wrote:
> Hello, I'm Gary Kramlich the lead developer of Pidgin. While 3.0 does work,
> I think putting it in experimental right now is a bit premature.  It's been
> in development for the better part of a decade (if it hasn't already been a
> decade).  There is a lot of stuff that's in bad shape and is not compatible
> with Pidgin 2 in any way shape or form (minus the config directory).  That
> said it requires a currently unpackage library called gplugin (written by
> me) that does have packaging written but is not in any distributions at
> this time.  It does however follow a fairly recent version of the Debian
> standards.
> 
> I am working on getting all of this stuff into so packagecloud.io
> repositories for people to try, but right now having more people dealing
> with dependency changes and stuff right now doesn't seem like a good use of
> anyone's time.

I appreciate the feedback. If you don't think Pidgin 3.0 is suitable
even for experimental at this time, and you don't want anyone other
than its developers testing it yet, then it probably isn't a good idea
to package it yet.

My goal was purely to seek a GTK+3 version of Pidgin, and some
searching turned up the Pidgin 3.0 branch.

Bug#833507: wpasupplicant: workaround wifi.scan-rand-mac-address=no

2017-12-04 Thread Thomas

I had the exact same issue and this fixed it for me.

On 04/12/17 20:29, Noël Köthe wrote:
> Package: wpasupplicant
> Version: 2:2.6-11
> Followup-For: Bug #833507
> 
> Dear Maintainer,
> 
> with one of the sid updates last week my wireless stop
> working again with the
> wpa_supplicant[737]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
> 
> I remember a workaround for this problem from the past to add 
> into /etc/NetworkManager/NetworkManager.conf the following:
> 
> [device]
> wifi.scan-rand-mac-address=no
> 
> which fixed it again for me.
> 
> ...
> network-manager (1.4.0-4) unstable; urgency=medium
> ...
>   * Fix MAC address randomization.
> Cherry-pick a couple of upstream commits which work around driver bugs
> when MAC address randomization is used. (Closes: #835822, #835553)
> ...
> 
> Because the last network-manager was from 2017-11-10 and my wlan problem
> started last week I'm a bit unsure where the root cause is.
> 
> Maybe the workaround helps someone.
> 
> Regards
> 
>   Noël
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
> LANGUAGE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages wpasupplicant depends on:
> ii  adduser   3.116
> ii  libc6 2.25-3
> ii  libdbus-1-3   1.12.2-1
> ii  libnl-3-200   3.2.27-2
> ii  libnl-genl-3-200  3.2.27-2
> ii  libpcsclite1  1.8.22-1
> ii  libreadline7  7.0-3
> ii  libssl1.1 1.1.0g-2
> ii  lsb-base  9.20170808
> 
> wpasupplicant recommends no packages.
> 
> Versions of packages wpasupplicant suggests:
> pn  libengine-pkcs11-openssl  
> pn  wpagui
> 
> -- no debconf information
> N�r��zǧvf���<�~t��칻�&�n�,u��jz+
> 



signature.asc
Description: OpenPGP digital signature

Bug#877344: [Debian-med-packaging] Bug#877344: Bug#877344: python-mne FTBFS: ERROR: Test ICA on raw and epochs

2017-12-04 Thread Yaroslav Halchenko

On Mon, 04 Dec 2017, Alexandre Gramfort wrote:

>oh mayavi
>I would really be in favor of removing mayavi as a hard dependency.
>is it an option?

well, it is not a hard dependency already... I just hate when
users keep reporting all those and then I need to react.  Prefer not to
upload if an issue is known thus having as many dependencies installed
during tests as I could "afford"

anyways -- only one left segfaulting (situation improved after I
realized that you switched to use py.test instead of nosetests),
for now will just disable that test... fighting other minor things ATM
;)

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

Bug#883542: pulseaudio: Pulseaudio does not honor paprefs "combine output

2017-12-04 Thread Gabriel Corona

Package: pulseaudio
Version: 11.1-3
Severity: normal

Latest pulseaudio update (11.1-1 -> 11.1-3) broke "simultaneous
output" option in paprefs: the "simultaneous output" virtual sink does
not appear anymore in pavucontrol.

The gconf module is enabled in /etc/pulse/default.pa:

.ifexists module-gconf.so
.nofail
load-module module-gconf
.fail
.endif

And is found in /proc/$(pidof pulseaudio)/maps:

$ cat /proc/$(pidof pulseaudio)/maps | grep gconf
7fb9c33f7000-7fb9c33fa000 r-xp  08:01 788560 
/usr/lib/pulse-11.1/modules/module-gconf.so
7fb9c33fa000-7fb9c35f9000 ---p 3000 08:01 788560 
/usr/lib/pulse-11.1/modules/module-gconf.so
7fb9c35f9000-7fb9c35fa000 r--p 2000 08:01 788560 
/usr/lib/pulse-11.1/modules/module-gconf.so
7fb9c35fa000-7fb9c35fb000 rw-p 3000 08:01 788560 
/usr/lib/pulse-11.1/modules/module-gconf.so

Manually loading the module brings back the virtual sink:

$ pactl load-module module-combine-sink
24

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.116
ii  libasound2   1.1.3-5
ii  libasound2-plugins   1.1.1-1
ii  libc62.25-2
ii  libcap2  1:2.25-1.1
ii  libdbus-1-3  1.12.2-1
ii  libgcc1  1:7.2.0-16
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-2
ii  liborc-0.4-0 1:0.4.28-1
ii  libpulse011.1-3
ii  libsm6   2:1.2.2-1+b3
ii  libsndfile1  1.0.28-4
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   7.2.0-16
ii  libsystemd0  235-3
ii  libtdb1  1.3.15-2
ii  libudev1 235-3
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxtst6 2:1.2.3-1
ii  lsb-base 9.20170808
ii  pulseaudio-utils 11.1-3

Versions of packages pulseaudio recommends:
ii  libpam-systemd  235-3
pn  rtkit   

Versions of packages pulseaudio suggests:
pn  paman
ii  paprefs  0.9.10-2+b1
ii  pavucontrol  3.0-3.1
ii  pavumeter0.9.3-4+b3
ii  udev 235-3

-- Configuration Files:
/etc/pulse/daemon.conf changed [not included]

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
##

Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.

2017-12-04 Thread Tormod Volden

Dang, you're right. It has only gone almost 9 months sometimes. Nice
table. perl?

Bug#882810: RFS: jag/0.3.3-1 [ITP] -- arcade-puzzle 2D game in which you have to break all the target pieces

On Sun, Nov 26, 2017 at 09:25:50PM -0200, Carlos Donizete Froes wrote:
>   I am looking for a sponsor for my package "jag"
> 
>  * Package name: jag
>Version : 0.3.3-1
>Upstream Author : Carlos Donizete Froes 
>  * URL : https://github.com/coringao/jag

>   It builds those binary packages:
> 
>  jag  - Arcade and Puzzle 2D Game
>  jag-data - Arcade and Puzzle 2D Game (Data)

It FTBFSes unless I add libqt5opengl5-dev to Build-Depends.

On startup, it dies with:
.--[ Files are missing ]
Cannot find data folder
/usr/loca/games/jag/data/
JAG will exit now
` [ ✗ Close ]

(It should look in /usr/share/games/jag/data/)


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 14:13 < icenowy[m]> are they hot enough? ;-)
⣾⠁⢰⠒⠀⣿⡁ 14:17 < icenowy[m]> I think now in Europe it should be winter? Let
⢿⡄⠘⠷⠚⠋⠀ the BPi warm you ;-)
⠈⠳⣄ 14:17 <@KotCzarny> yeah, i have a pc to warm me ;)

Bug#877344: [Debian-med-packaging] Bug#877344: Bug#877344: python-mne FTBFS: ERROR: Test ICA on raw and epochs

2017-12-04 Thread Alexandre Gramfort

oh mayavi

I would really be in favor of removing mayavi as a hard dependency.

is it an option?

Alex

Bug#883536: [Pkg-dns-devel] Bug#883536: isc-dhcp FTBFS with libbind-export-dev 1:9.11.2+dfsg-2

Control: reassign -1 libbind-export-dev 1:9.11.2+dfsg-2
Control: retitle -1 libbind-export-dev: dangling libisc-export.so symlink 
without merged /usr
Control: affects -1 src:isc-dhcp

On Mon, Dec 04, 2017 at 11:04:21PM +0100, Bernhard Schmidt wrote:
> On 04.12.2017 21:45, Adrian Bunk wrote:
> 
> Hi Adrian,
> > Source: isc-dhcp
> > Version: 4.3.5-3
> > Severity: serious
> > Tags: buster sid
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/isc-dhcp.html
> > 
> > ...
> > gcc  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> > -I/usr/include/bind-export -g -O2 -fstack-protector-strong -Wformat 
> > -Werror=format-security -D_PATH_DHCPD_CONF='"/etc/dhcp/dhcpd.conf"' 
> > -D_PATH_DHCPD_DB='"/var/lib/dhcp/dhcpd.leases"' 
> > -D_PATH_DHCPD6_DB='"/var/lib/dhcp/dhcpd6.leases"' 
> > -D_PATH_DHCLIENT_SCRIPT='"/sbin/dhclient-script"' 
> > -D_PATH_DHCLIENT_CONF='"/etc/dhcp/dhclient.conf"' 
> > -D_PATH_DHCLIENT_DB='"/var/lib/dhcp/dhclient.leases"' 
> > -D_PATH_DHCLIENT6_DB='"/var/lib/dhcp/dhclient6.leases"' -DNSUPDATE  
> > -I../includes -I../bind/include  -lirs-export -Wl,-z,relro -Wl,-z,now -o 
> > svtest test.o libomapi.a -lirs-export -ldns-export -lisc-export 
> > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libirs-export.a(dnsconf.o):
> >  In function `configure_dnsseckeys.constprop.0':
> > (.text+0x49): undefined reference to `cfg_map_get'
>...
> That's weird, I cannot reproduce this (against -3, but that only fixed
> udeb shlibs and issues with any/all buildds)
> 
> Installed-Build-Depends:
> [...]
>  libbind-export-dev (= 1:9.11.2+dfsg-3),
>  libdns-export169 (= 1:9.11.2+dfsg-3),
>  libirs-export160 (= 1:9.11.2+dfsg-3),
>  libisc-export166 (= 1:9.11.2+dfsg-3),
>  libisccc-export160 (= 1:9.11.2+dfsg-3),
>  libisccfg-export160 (= 1:9.11.2+dfsg-3),
>...
> Can you retry the test?

The pattern is clear:
https://tests.reproducible-builds.org/debian/history/isc-dhcp.html

I am also able to reproduce it locally.

Am I guessing correct that merged /usr is used in your
successful build?

libisc-export166: /lib/x86_64-linux-gnu/libisc-export.so.166.2.0
libbind-export-dev: /usr/lib/x86_64-linux-gnu/libisc-export.so

The .so symlink is dangling without merged /usr,
and in that case the static library is used instead.

> Bernhard

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#883541: git-buildpackage: gbp pq export should default to content-transfer-encoding: 8bit

2017-12-04 Thread Daniel Kahn Gillmor

Package: git-buildpackage
Version: 0.9.4
Severity: normal

I have a few patches that contain text that is not 7-bit-clean US
ASCII.

They are all UTF-8.

"gbp pq export" used to generate patch files that were
Content-Transfer-Encoding: 8bit.  But today i see they are doing
Content-Transfer-Encoding: base64.

base64 is a lot harder to read!  we should just use 8bit encoding for
the patch files.

I *think* it was working with 0.9.3, but it might be that git itself
changed out from under gbp.  sorry for not testing in more detail
right now.

  --dkg

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.17.11
ii  git1:2.15.0-1
ii  man-db 2.7.6.1-4
ii  python33.6.3-2
ii  python3-dateutil   2.6.1-1
ii  python3-pkg-resources  36.7.1-1

Versions of packages git-buildpackage recommends:
pn  cowbuilder | pbuilder | sbuild  
ii  pristine-tar1.42
ii  python3-requests2.18.1-1

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
pn  sudo 
ii  unzip6.0-21

-- no debconf information

Bug#769380: python3-mako: Please make the package multi-arch compatible

2017-12-04 Thread Piotr Ożarowski

> So, Piotr, do you think that any of the options is preferable?
> 
> If there's no reply I'd like to upload an NMU with a fix for this
> problem.
> 
> I think that changing the package to "Architecture: any" and "M-A: same"
> is safer than dropping a dependency to recommends.  It's not ideal, but
> in the end is just causes a small overhead, and changing dependencies
> can even break reverse-depends and introduce bugs difficult to detect.

please point me to the policy if it's already known what's the right
approach

Bug#883540: Wishlist banshee-extension-lyrics

2017-12-04 Thread Josh Blagden

Package: banshee-extension-lyrics

Severity: Wishlist


Dear Debian developers an maintainers, the banshee lyrics extension,
titled banshee-extension-lyrics, is available for earlier branches of
Debian, but not Buster.


Regards,

    Joshua Blagden

Bug#883539: metastore: New upstream version (1.1.1) with important bugfix has been released

2017-12-04 Thread Przemysław Pawełczyk

Package: metastore
Version: 1+20080623+debian-5
Severity: important

Dear Maintainer,

I am official maintainer of metastore project since commit
f65c0a03c214 done by David Härdeman, who was the previous metastore
maintainer (and co-maintainer of Debian package). He ceded
maintainership of metastore to me publicly via GitHub PR (because
GitHub was where I was developing my metastore continuation,
unofficial back then):

https://github.com/przemoc/metastore/pull/32

I merged commit f65c0a03c214 on the same day, i.e. 2015-10-26.

Before that happened I reported important xattr-related bug to Debian
on 2015-09-07 (#798222) and provided a patch (commit 489d58670283,
2015-09-06), but there was no action from your side.

A few months later another important xattr-related bug has been
discovered and fixed (commit 98e73203bf9d, 2016-01-12).

On 2016-01-31 I mailed you about metastore-announce mailing list (very
low traffic - 2 mails/year so far), which archive is available at:
https://www.freelists.org/archive/metastore-announce/
You didn't subscribe to it.

metastore 1.1.0 has been released shortly after (commit 0197117b4411,
2016-02-01).

Recently another important xattr-related bug manifesting on 64-bit
platforms has been discovered (maybe even CVE-worthy) and fixed
(commit 5b060d5b7f0d, 2017-11-24), and I quite quickly informed about
it on ML:
https://www.freelists.org/post/metastore-announce/Serious-xattrrelated-bug-in-metastore-v110

Unfortunately back then I didn't have time and other resources to do
the release, so it was delayed until yesterday night, or actually
today, to be precise.

metastore 1.1.1 has been released with commit 56f3f9228dfe, pointed by
annotated and GPG-signed tag v1.1.1. Announcement on mailing list:
https://www.freelists.org/post/metastore-announce/metastore-v111

I still use Debian from time to time, so it pains me that metastore is
in such neglected state here. I am not willing to become Debian
maintainer of metastore, though, as I am not sure if being upstream
maintainer and distro package maintainer at the same time is a good
thing.

Beside updating metastore itself, its homepage (debian/control) and
upstream download URL (debian/watch) should be changed as well:
https://github.com/przemoc/metastore
http://ftp.przemoc.net/pub/software/utils/metastore/ metastore-(.+)\.tar\.gz

Tarballs are signed with my signing-only subkey:

rsa4096/0xFA94ECC62EBFBFBA[expires: 2017-12-13]
fingerprint = B97A 7939 E022 800C 9808 6A32 FA94 ECC6 2EBF BFBA

(this one expires soon, so future versions will be signed with some
new one, obviously).
My signing-only subkey is associated with my main key:

rsa4096/0x879C7468EAD49C84
fingerprint = BA46 8718 D588 669A 6633 98CE 879C 7468 EAD4 9C84

As you can easily check on GitHub, I cannot say I'm actively
developing metastore right now, but I always treat bugs seriously, so
at least it's not an abandoned project.

I know that metastore userbase is extremely small, but if Debian
provides such package, it should be as bug-free version as possible,
which is not the case for a second year already. At this moment there
are 3 unfixed and important xattr-related bugs in metastore available
in Debian (and its derivatives).

I hope you'll find time to bring metastore in Debian to proper state
in upcoming weeks.

Regards.

--
Przemysław 'Przemoc' Pawełczyk
http://przemoc.net/

Bug#875416: Pending fixes for bugs in the jasperreports package

2017-12-04 Thread pkg-java-maintainers

tag 875416 + pending
thanks

Some bugs in the jasperreports package are closed in revision
d16bc110ff3835b53e8baf3f1d3bdd3e9df52466 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/jasperreports.git/commit/?id=d16bc11

Commit message:

Removed the -java-doc package to avoid the build failure with Java 9 
(Closes: #875416)

Bug#836217: retitle to RFP: nfstash -- CLI tools suite implementing NFS client procedures

2017-12-04 Thread Sandro Tosi

we dont really use nfstash anymore, so feel free to go ahead; if so i
can forward you what the ftp master told me back in the days when
rejecting the package (theres probably a git repo around, somewhere) -
let me know

On Mon, Dec 4, 2017 at 4:38 PM, Salvatore Bonaccorso  wrote:
> Control: retitle -1 ITP: nfstash -- CLI tools suite implementing NFS client 
> procedures
> Control: owner -1 !
>
> Hello,
>
> On Mon, Dec 04, 2017 at 04:19:58PM +, Bart Martens wrote:
>> retitle 836217 RFP: nfstash -- CLI tools suite implementing NFS client 
>> procedures
>> noowner 836217
>> stop
>>
>> ITP 836217 has no visible progress for a long time, so retitling to RFP.
>
> In case Sandro would not be interested anymore in packaging nfstash I
> will try to look at it in the next couple of days.
>
> Regards,
> Salvatore



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#831094: attal: FTBFS with GCC 6: cmath:568:33: error: 'FP_NAN' was not declared in this scope

2017-12-04 Thread Markus Koschany

Am 01.12.2017 um 13:49 schrieb Juhani Numminen:
> Control: tags -1 patch
> 
> Hello!
> 
> I made attal to build again by removing "#undef __USE_ISOC99", so I'm
> adding the patch tag.
> 
> However, as I don't know why those undefs were added in the first place,
> so this change might be breaking something. All I know is the build was
> completed and I could install the package and start the executable.
> 
> Cheers,
> Juhani

Hello,

thanks for your patch! Unfortunately there is another big issue with
this package and that is the upcoming removal of QT4 from Debian. [1]
I believe there is not much point in fixing/work-arounding this bug and
then, a few months later, the package will be in the same state again.
So unless someone is able to port this game to QT5, we should keep attal
out of testing IMHO.

Regards,

Markus


[1] https://bugs.debian.org/874827



signature.asc
Description: OpenPGP digital signature

Bug#819460: lintian: duplicate-updaterc.d-calls-in-postinst false positive

Hi Stefan,

> lintian: duplicate-updaterc.d-calls-in-postinst false positive

Thank you for your bug report. I'm struggling to think how Lintian
might avoid this kind of false positive; looking at other packages
that override this tag there is no consistent pattern that I can see.

Thus, the resolution here might simply be "please override" - you
clearly know what you are doing here. :)


Regards,

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

Bug#769380: python3-mako: Please make the package multi-arch compatible

2017-12-04 Thread Manuel A. Fernandez Montecelo


Hi,

2017-10-22 20:07 Helmut Grohne:

On Fri, Oct 20, 2017 at 10:03:01PM +0200, Manuel A. Fernandez Montecelo wrote:

#875650 looks like a duplicate of #769380, and according to #769380 back
in 2014 josch and helmut seem to have concluded that the better solution
was to either change the package to "Architecture: any" and "M-A: same",
or demote the dependency on python-markupsafe.


They kinda are duplicates, but unless the markupsafe dependency is
demoted, the advice from #875650 to add m-a:foreign is simply wrong.
Since #769380 contains all the deatils, I am simply closing the newer
bug.

[...]

Since the package is actively maintained and you uploaded a version very
recently, I am not sure if it makes much sense to offer to NMU, but
nevertheless if we can help in some way, please tell.


The issue here is that the bug kinda is under (inactive) discussion:
There are multiple ways to fix and nobody knows which one is better. The
first question to answer is whether it would be reasonable to demote the
dependency on markupsafe to recommends. Having an answer on that
question from someone of the DPMT would be very helpful.

Barring that, we're still talking with Guillem whether dpkg could allow
:native annotations on Arch:all packages (which dose does allow). In
case that moves forward, we might be able to cancel this bug.

If all else fails, I see no way around turning it Arch:any at some
point. What we need here is an answer to the demotion question to move
on.


So, Piotr, do you think that any of the options is preferable?

If there's no reply I'd like to upload an NMU with a fix for this
problem.

I think that changing the package to "Architecture: any" and "M-A: same"
is safer than dropping a dependency to recommends.  It's not ideal, but
in the end is just causes a small overhead, and changing dependencies
can even break reverse-depends and introduce bugs difficult to detect.


Cheers.
--
Manuel A. Fernandez Montecelo

Bug#883536: [Pkg-dns-devel] Bug#883536: isc-dhcp FTBFS with libbind-export-dev 1:9.11.2+dfsg-2

2017-12-04 Thread Bernhard Schmidt

On 04.12.2017 21:45, Adrian Bunk wrote:

Hi Adrian,
> Source: isc-dhcp
> Version: 4.3.5-3
> Severity: serious
> Tags: buster sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/isc-dhcp.html
> 
> ...
> gcc  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> -I/usr/include/bind-export -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -D_PATH_DHCPD_CONF='"/etc/dhcp/dhcpd.conf"' 
> -D_PATH_DHCPD_DB='"/var/lib/dhcp/dhcpd.leases"' 
> -D_PATH_DHCPD6_DB='"/var/lib/dhcp/dhcpd6.leases"' 
> -D_PATH_DHCLIENT_SCRIPT='"/sbin/dhclient-script"' 
> -D_PATH_DHCLIENT_CONF='"/etc/dhcp/dhclient.conf"' 
> -D_PATH_DHCLIENT_DB='"/var/lib/dhcp/dhclient.leases"' 
> -D_PATH_DHCLIENT6_DB='"/var/lib/dhcp/dhclient6.leases"' -DNSUPDATE  
> -I../includes -I../bind/include  -lirs-export -Wl,-z,relro -Wl,-z,now -o 
> svtest test.o libomapi.a -lirs-export -ldns-export -lisc-export 
> /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libirs-export.a(dnsconf.o):
>  In function `configure_dnsseckeys.constprop.0':
> (.text+0x49): undefined reference to `cfg_map_get'
> (.text+0x5c): undefined reference to `cfg_list_first'
> (.text+0x89): undefined reference to `cfg_listelt_value'
> (.text+0x91): undefined reference to `cfg_list_first'
> (.text+0xbb): undefined reference to `cfg_listelt_value'
> (.text+0xcd): undefined reference to `cfg_tuple_get'
> (.text+0xd5): undefined reference to `cfg_obj_asuint32'
> (.text+0xe7): undefined reference to `cfg_tuple_get'
> (.text+0xef): undefined reference to `cfg_obj_asuint32'
> (.text+0x101): undefined reference to `cfg_tuple_get'
> (.text+0x109): undefined reference to `cfg_obj_asuint32'
> (.text+0x11c): undefined reference to `cfg_tuple_get'
> (.text+0x124): undefined reference to `cfg_obj_asstring'
> (.text+0x1cb): undefined reference to `cfg_tuple_get'
> (.text+0x1d3): undefined reference to `cfg_obj_asstring'
> (.text+0x393): undefined reference to `cfg_list_next'
> (.text+0x3a9): undefined reference to `cfg_list_next'

That's weird, I cannot reproduce this (against -3, but that only fixed
udeb shlibs and issues with any/all buildds)

Installed-Build-Depends:
[...]
 libbind-export-dev (= 1:9.11.2+dfsg-3),
 libdns-export169 (= 1:9.11.2+dfsg-3),
 libirs-export160 (= 1:9.11.2+dfsg-3),
 libisc-export166 (= 1:9.11.2+dfsg-3),
 libisccc-export160 (= 1:9.11.2+dfsg-3),
 libisccfg-export160 (= 1:9.11.2+dfsg-3),
[...]
isc-dhcp-server_4.3.5-3_amd64.deb
Depends: debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.15),
libdns-export169, libirs-export160, libisc-export166, debianutils (>=
2.8.2), lsb-base
[...]
Build Architecture: amd64
Build Type: full
Build-Space: 98652
Build-Time: 85
Distribution: unstable
Host Architecture: amd64
Install-Time: 7
Job: /tmp/isc-dhcp_4.3.5-3.dsc
Machine Architecture: amd64
Package: isc-dhcp
Package-Time: 99
Source-Version: 4.3.5-3
Space: 98652
Status: successful
Version: 4.3.5-3

Can you retry the test?

Bernhard

Bug#883538: ITP: libmsnumpress -- numerical compression in mass spectrometry data

2017-12-04 Thread Filippo Rusconi

Package: wnpp
Severity: wishlist
Owner: Filippo Rusconi 

* Package name: libmsnumpress
  Version : 1.0.0
  Upstream Author : Johan Teleman et al 
* URL : https://github.com/ms-numpress/ms-numpress  
* License : (Apache-2.0)
  Programming Lang: (C++)
  Description : numerical compression in mass spectrometry data

 Implementations of two compression schemes for numeric data from mass
 spectrometers.
 .
 The library provides implementations of 3 different algorithms, 1 designed to
 compress first order smooth data like retention time or M/Z arrays, and 2 for
 compressing non smooth data with lower requirements on precision like ion count
 arrays.

Bug#849411: diffoscope: HTML markup warnings/errors

severity 849411 minor
thanks

I'm downgrading this to "minor". The requirement of valid HTML — whilst
strictly defined — is not a pressing concern with modern browsers which
can parse almost anything, and it's not as if our HTML is too awful
wrt the specs. :)


Regards,

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

Bug#872826: Diffoscope: difference of "Device ID" caused an error in test suite on FreeBSD

Hey Ximin,

> A proposed patch is attached. Thank you!

LGTM :)  Fancy applying it?


Regards,

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

Bug#855273: diffoscope: fails to clean up after SIGTERM

tags 855273 + moreinfo
thanks

Chris Lamb wrote:

> > diffoscope: still fails to clean up after SIGTERM
>
> Can we reproduce this outside of Jenkins? Would really love a testcase
> so I can my teeth into this...

Ping on this, Mattia?  Would be great to either solve this or close the
bug either way. :)


Best wishes,

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

Bug#881937: diffoscope: Doesn't show differences in .deb's control.tar.xz (regression?)

tags 881937 + pending
thanks

> https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=e5dc438f3d4fabd91798b93f02e85810465f3c12

Marking as pending to match :)


Regards,

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

Bug#879011: diffoscope: zipinfo diff shows warning differences that are due to temporary file names

tags 879011 + pending
thanks

Ximin wrote:

> I've fixed it a different way:
>
> https://anonscm.debian.org/cgit/reproducible/diffoscope.git/commit/?id=25fee28c8b29dbc66cd7bb57a2ab427651050c23

Marking as pending to match.


Regards,

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

Bug#826410: Pending fixes for bugs in the maven-debian-helper package

2017-12-04 Thread pkg-java-maintainers

tag 826410 + pending
thanks

Some bugs in the maven-debian-helper package are closed in revision
ef1177ba4f1b07478d58902c8f515e3464242df0 in branch 'master' by
Christopher Hoskin

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/maven-debian-helper.git/commit/?id=ef1177b

Commit message:

Fix "Add non-interactive option to mh_make" (Closes: #826410)

Bug#877849: [tryton-debian] Namespace conflict for python-magic

2017-12-04 Thread Mathias Behrle

* Adam Hupp: " Re: [tryton-debian] Namespace conflict for python-magic" (Mon, 4
  Dec 2017 11:58:22 -0800):

Thanks a lot, Adam, I will take a look ASAP.

> I've pushed an update here:
> 
> https://github.com/ahupp/python-magic/tree/libmagic-compat
> 
> It includes a copy of libmagic's bindings, wrapped in deprecation
> warnings.  So apps should work regardless of which they depend on.
> Could you take a look and see if this works for your case?
> 
> On Fri, Oct 27, 2017 at 5:44 AM, Mathias Behrle  wrote:
> > * Mathias Behrle: " Re: [tryton-debian] Namespace conflict for
> >   python-magic" (Thu, 5 Oct 2017 12:01:16 +0200):
> >
> > Hi Adam,
> >
> > are there any news on the subject?
> >
> > The release of Tryton, that will require python-magic is scheduled for next
> > week. It would be a great service to our users and simplify things a lot,
> > if we had a common python-magic in place. Please let us know, if we can
> > help with the planned merge.
> >
> > Thanks,
> > Mathias
> >
> >  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
>  [...]  
> >
> >
> >
> > --
> >
> > Mathias Behrle
> > PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
> > AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6  
> 
> 
> 



-- 

Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#769377: [Pkg-haskell-maintainers] Bug#769377: haskell-devscripts: please mark as M-A:foreign

2017-12-04 Thread Manuel A. Fernandez Montecelo


Control: tags -1 - pending


Hi,

2014-11-13 10:29 Joachim Breitner:

Hi,

Am Donnerstag, den 13.11.2014, 09:52 +0100 schrieb Johannes Schauer:

Helmut Grohne corrected me that this is not that simple.

haskell-devscripts depends on ghc and specifically uses ghci for example to do
tests which should be carried out for the host architecture but are instead
being done for the build architecture. Example:

./usr/share/cdbs/1/class/hlibrary.mk:NO_GHCI_FLAG = $(shell test -e 
/usr/bin/ghci || echo --ghc-option=-DDEBIAN_NO_GHCI; exit 0)

So this requires quite some additional work which probably only makes sense to
do once haskell can be cross compiled in practice.


ok, undone the change to the repo.


So I am unmarking this as +pending then :)

--
Manuel A. Fernandez Montecelo

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

2017-12-04 Thread Simon Deziel

Hello Yves-Alexis,

On 2017-12-04 03:56 PM, Yves-Alexis Perez wrote:
> On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote:
>> Pushed it to the same debian-submission-nov2017 branch as before.
> 85150f06 (kernel-libipsec enable): for reference, this is #739641 and I'm
> still not sure I like it. I might pick it but end up disabling it before
> release

The plugin is configured /not/ to load by default which means the
kernel's implementation will be used as normal. Users would need to
opt-in to use this userspace stack.

> f9e7f9007 (CCN move): NACK, what's the justification?

CCM is apparently more popular in the embedded space so maybe it was a
typo for GCM? GCM would make more sense IMHO.

> 8dbf648b7 (libcharon-standard-plugin): I can understand the rationale (plugins
> for common password-based mobile VPN setup), but I don't really like it. I
> don't really like adding a new binary package, and the name is definitely not
> good. Also, as far as I understand it, the plugins are useful when you're
> actually configuring a client/roadwarrior to imitate a mobile client with its
> limitations. I don't think it's a good thing to do, I'd prefer simplifying the
> secure uses cases, like pubkeys-based ones.

The rational for having EAP-MSCHAPv2 and XAUTH easily available is to
support users connecting to corporate VPNs configured to be compatible
with Windows and macOS.

Public keys would be far better indeed but in the enterprises/govs I had
to deal with, they were not popular. In the past 6-7 years, I only had
one client using public keys for roadwarrior scenario.

Regards,
Simon

signature.asc
Description: OpenPGP digital signature

Bug#881715: alsa-utils: High CPU usage on the default device

2017-12-04 Thread Andoru

> As you are the only one out of 60thsd Debian Alsa users who
> reported a high cpu-usage running alsa apps

Forgot to mention this: just because I'm the only one to report this issue
doesn't mean I'm the only one to experience it! I'm sure at least other
Debian users with the same sound chip as mine would probably experience the
same issue, if not users of other distros as well. They probably just
didn't bother reporting it as it is a sort of a minor-ish issue, or they
might've not even noticed it.

Could you (or someone else) perhaps let me know who provided the driver for
ALC887-VD? Maybe that way I could contact them directly.

Bug#883439: Pending fixes for bugs in the dh-make-perl package

2017-12-04 Thread pkg-perl-maintainers

tag 883439 + pending
thanks

Some bugs in the dh-make-perl package are closed in revision
e6e6767e0bdbd25106bd1584f724c034836b7129 in branch 'master' by Damyan
Ivanov

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/dh-make-perl.git/commit/?id=e6e6767

Commit message:

Debian::Control::Stanza: add support for user-defined fields (X-Moon-Phase)

Closes: #883439

Bug#836217: retitle to RFP: nfstash -- CLI tools suite implementing NFS client procedures

Control: retitle -1 ITP: nfstash -- CLI tools suite implementing NFS client 
procedures
Control: owner -1 !

Hello,

On Mon, Dec 04, 2017 at 04:19:58PM +, Bart Martens wrote:
> retitle 836217 RFP: nfstash -- CLI tools suite implementing NFS client 
> procedures
> noowner 836217
> stop
> 
> ITP 836217 has no visible progress for a long time, so retitling to RFP.

In case Sandro would not be interested anymore in packaging nfstash I
will try to look at it in the next couple of days.

Regards,
Salvatore

Bug#878498: snakemake FTBFS with Python 3.6 as default

2017-12-04 Thread chrysn

On Sun, Dec 03, 2017 at 06:47:48PM +0100, Andreas Tille wrote:
> Ping?

sorry, I thought I had already done that: my latest WIP state is now
pushed; it includes a patch that disables rate limiting for sake of
being able to work on the main issue, but I haven't made any progress
there yet.


signature.asc
Description: PGP signature

Bug#878726: wireshark-gtk: Deterministically crashes of 'Compile selected BPFs'

2017-12-04 Thread Bálint Réczey

Control: tags -1 confirmed upstream

2017-10-16 10:30 GMT+02:00 Yangfl :
> Package: wireshark-gtk
> Version: 2.4.1-1
> Severity: normal
>
> Dear Maintainer,
>
> Wireshark crashes for me if I do the following in the GUI:
>
> 1. Capture Options -> select sth like 'usbmon1'
> 2. Start -> Permission denied warning
> 3. Capture Options again -> Compile selected BPFs
> 4. Crash, error message was:
>
> ERROR:/build/wireshark-HB0Xtn/wireshark-2.4.1/ui/gtk/capture_dlg.c:2174:capture_all_filter_compile_cb:
> code should not be reached

Yes it crashes when trying to compile BPF for interfaces the user
can't capture on.
In the Qt UI the button for compiling BPF is disabled.

It seems latest development version still has the issue, but I have to check.

Cheers,
Balint

Bug#883528: libextractor: CVE-2017-15600 and CVE-2017-15602 are not completely fixed

Hi Markus,

On Mon, Dec 04, 2017 at 09:56:27PM +0100, Markus Koschany wrote:
> Am 04.12.2017 um 20:53 schrieb Salvatore Bonaccorso:
> > Hi
> > 
> > On Mon, Dec 04, 2017 at 08:27:13PM +0100, Salvatore Bonaccorso wrote:
> >> Hi Markus,
> >>
> >> On Mon, Dec 04, 2017 at 08:13:38PM +0100, Markus Koschany wrote:
> >>> Package: src:libextractor
> >>> Version: 1:1.6-1
> >>> Severity: important
> >>> Tags: security
> >>>
> >>> Hi,
> >>>
> >>> while I was working on the security update for Wheezy I discovered
> >>> that libextractor in Buster/Sid is still vulnerable to CVE-2017-15600
> >>> and CVE-2017-15602. I could reproduce two segmentation faults with the
> >>> provided POCs. They are attached to the upstream bug report:
> >>>
> >>> http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg4.html
> >>> http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg5.html
> >>>
> >>> Just run "extract -i $POC"
> >>>
> >>> I'm attaching my gdb log files to this bug report.
> >>
> >> Since the issues happen in different places from the original reports,
> >> can you request two new CVEs for those issues?
> >>
> >> So for tracking purposes these are two new raised issues, different
> >> from CVE-2017-15600 and CVE-2017-15602 and would possibly require two
> >> new ones. Can you as well report it to upstream in case Bertrand
> >> cannot cime in?
> >>
> >> In case not let me know, and I can take care of it tomorrow.
> > 
> > Interestignly the issues you describe does not seem triggerable with a
> > fresh build of 1.6 in sid (with --enable-shared=no,
> > --enable-static=yes with -O0).
> > 
> > sid:~/libextractor-1.6# ./src/main/extract -i ~/1338044
> > Keywords for file /root/1338044:
> > sid:~/libextractor-1.6# ./src/main/extract -i ~/bin_6iRW3tXve.bin
> > Keywords for file /root/bin_6iRW3tXve.bin:
> > sid:~/libextractor-1.6#
> > 
> > and neither with current HEAD (6c70420641fc1d081bcecf323671ca169b13a129).
> > 
> > It is though with the Debian package (re)build. What is different?
> 
> I can still reproduce it when I rebuild the package. If you disable
> optimization with -O0 some compiler behaviors will change. I don't know
> the details but what is undefined behavior with -O2 is somehow OK with
> -O0. I just wanted to forward this upstream but if you say that it is
> not reproducible with upstream HEAD, it's probably pointless.

Well, need to further properly investigate that. It was just a quick
ASAN build of the current head. From my reply in
https://bugs.debian.org/883528#20 it might actually be that the second
issue is not an upstream one but. Please note that I misstyped the
CVEs.

> Maybe we should wait for the next release which will also fix
> CVE-2017-15922 or Bertrand could package the latest Git snapshot?

Yes, for CVE-2017-15922 either works, cherry-pick the commit, wait for
the new upstream release or package the latest git snapshot.

> Shall
> I remove the fixed versions for both CVE in the security tracker?

Please not. The first issue is actually a different one (happening
with same reproducer for CVE-2017-15600, but in a different place,
unless I'm completely mistaken. So CVE-2017-15600 should be kept
associated with the 38e8933539ee9d044057b18a971c2eae3c21aba7 commit
and track your finding as separate issue.

For the issue reproduced with the CVE-2017-15602-reproducing file,
after beeing fixed with ffab889c1710c7646af9ed360c796a2a0a619efc
triggers a new issue, which is possibly in libgm or
libavformat.so/ffmpeg. So still not sure if the uncovered issue is in
src:libextractor.

See the ASAN traces from https://bugs.debian.org/883528#20

Thanks for your work on the libextractor update and triaging.

Salvatore

Bug#883094: Accessibility: Mate: Screen reader is not available in login screen

2017-12-04 Thread mike . gabriel

Hi,

On Monday, December 4, 2017, sirgazil wrote:
> On 04/12/17 06:18, Mike Gabriel wrote:
> > Hi,
> > 
> > On  Fr 01 Dez 2017 01:02:25 CET, sirgazil wrote:
> > 
> >> On 30/11/17 04:38, Mike Gabriel wrote:
> >>> Hi,
> >>>
> >>> On  Mi 29 Nov 2017 16:59:27 CET, sirgazil wrote:
> >>>
>  Package: mate-desktop
>  Version: 1.16.2-2
> 
>  I'm using Debian Linux zenme 4.9.0-4-686-pae #1 SMP Debian 4.9.51-1 
>  (2017-09-28) i686 GNU/Linux.
> 
>  When a blind person starts the computer, they don't have any way of 
>  knowing whether the login screen has loaded or not. The system does 
>  not provide any aural cues for blind users, so they have to call 
>  sighted people to help them log in.
> >>>
> >>> Thanks for your feedback on accessibility.
> >>>
> >>> Please note that the MATE desktop does not come with a login manager 
> >>> itself. It uses a "3rd party product" for session login management.
> >>>
> >>> The default display manager in use for MATE desktop installations is 
> >>> LightDM.
> >>>
> >>> Please also note that I have recently uploaded the Arctica Greeter, a 
> >>> fork from Ubuntu's Unity Greeter. Arctica Greeter, like Unity 
> >>> Greeter, sends a little drum roll to the speaker, so there is indeed 
> >>> an accoustic signal that the greeter has loaded and the computer is 
> >>> ready for login.
> >>>
> >>> The greeter has Orca support built-in, so you can enable it (or have 
> >>> it enabled by default as a system-wide setting that survives reboot 
> >>> of the computer). Orca then will read to you the different text 
> >>> fragments you find on the login screen.
> >>>
> >>> I will ping you via this bug, once the Arctica Greeter has landed in 
> >>> Debian testing.
> >>>
> >>> Please note that such changes as requested / proposed cannot be made 
> >>> in a Debian stable release, so we need to look forward regarding this 
> >>> and improve ourselves for Debian 10 (aka buster).
> >>>
> >>> Thanks for your input!
> >>> Mike
> >>
> >>
> >> Thank you for the information, Mike.
> >>
> >> I'd like to add that working around this problem by activating Orca 
> >> screen reader in the LightDM GTK+ Greeter Settings is not possible 
> >> because the greeter hangs when doing so (see 
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883215).
> >>
> >> So it seems Debian 9 with Mate is currently not accessible at all to 
> >> blind users?
> > 
> > Please note that LightDM GTK+ Greeter is _not_ Arctica Greeter.
> 
> 
> Yes, I know that. I was referring to the default greeter that is used in 
> Debian when you select the Mate desktop in the installation process.
> 
> 
> > If you are not scared of third party APT repositories, you can get a 
> > build of Arctica Greeter here:
> > 
> > ```
> > deb http://packages.arctica-greeter.org/debian stretch main
> > ```
> > 
> > The GnuPG Archive Key can be obtained this way:
> > 
> > ```
> > wget -qO - http://packages.arctica-project.org/archive.key | sudo 
> > apt-key add -
> > ```
> > 
> > Looking forward for your feedback! Orca can be enable in the greeter 
> > with ALT + SUPER + S.
> 
> 
> Well, in this particular case, only Debian stable repositories are allowed.
> 
> I'd like to try this workaround on my machine, though, but trying to add 
> the GPG Archive Key failed:
> 
>  # apt-key add archive.key
>  gpg: keydb_get_keyblock failed: Value not found
> 
>

Does archive.key really contain a GPG public key? It seems that the key block 
is missing in the file you use as archive.key. Please check with a text editor 
or pager...

Mike

-- 
Sent from my Fairphone 2 (running Sailfish OS)

Bug#883214: Please package new upstream 3.0 version in experimental (with GTK+ 3.0 support)

2017-12-04 Thread Gary Kramlich

Hello, I'm Gary Kramlich the lead developer of Pidgin. While 3.0 does work,
I think putting it in experimental right now is a bit premature.  It's been
in development for the better part of a decade (if it hasn't already been a
decade).  There is a lot of stuff that's in bad shape and is not compatible
with Pidgin 2 in any way shape or form (minus the config directory).  That
said it requires a currently unpackage library called gplugin (written by
me) that does have packaging written but is not in any distributions at
this time.  It does however follow a fairly recent version of the Debian
standards.

I am working on getting all of this stuff into so packagecloud.io
repositories for people to try, but right now having more people dealing
with dependency changes and stuff right now doesn't seem like a good use of
anyone's time.

On Thu, Nov 30, 2017 at 1:48 PM, Josh Triplett 
wrote:

> Package: pidgin
> Version: 2.12.0-1+b1
> Severity: wishlist
>
> Upstream has a new 3.0 version in development, which includes GTK+ 3.0
> support. Please consider packaging it in experimental.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages pidgin depends on:
> ii  libatk1.0-0 2.26.1-1
> ii  libc6   2.25-2
> ii  libcairo2   1.15.8-2
> ii  libdbus-1-3 1.12.2-1
> ii  libdbus-glib-1-20.108-3
> ii  libfontconfig1  2.12.6-0.1
> ii  libfreetype62.8.1-0.1
> ii  libgadu31:1.12.2-2
> ii  libgdk-pixbuf2.0-0  2.36.11-1
> ii  libglib2.0-02.54.2-1
> ii  libgstreamer1.0-0   1.12.3-1
> ii  libgtk2.0-0 2.24.31-3
> ii  libgtkspell02.0.16-1.1
> ii  libice6 2:1.0.9-2
> ii  libpango-1.0-0  1.40.13-2
> ii  libpangocairo-1.0-0 1.40.13-2
> ii  libpangoft2-1.0-0   1.40.13-2
> ii  libpurple0  2.12.0-1+b1
> ii  libsm6  2:1.2.2-1+b3
> ii  libx11-62:1.6.4-3
> ii  libxss1 1:1.2.2-1+b2
> ii  perl-base [perlapi-5.26.0]  5.26.1-3
> ii  pidgin-data 2.12.0-1
>
> Versions of packages pidgin recommends:
> ii  gstreamer1.0-alsa  1.12.3-1
> ii  gstreamer1.0-libav 1.12.3-1
> ii  gstreamer1.0-plugins-base  1.12.3-1
> ii  gstreamer1.0-plugins-good  1.12.3-1
> ii  gstreamer1.0-pulseaudio1.12.3-1
>
> Versions of packages pidgin suggests:
> ii  libsqlite3-0  3.21.0-1
>
> -- no debconf information
>
>

-- 
Thanks,

--
Gary Kramlich

Bug#883528: libextractor: CVE-2017-15600 and CVE-2017-15602 are not completely fixed

2017-12-04 Thread Markus Koschany

Am 04.12.2017 um 20:53 schrieb Salvatore Bonaccorso:
> Hi
> 
> On Mon, Dec 04, 2017 at 08:27:13PM +0100, Salvatore Bonaccorso wrote:
>> Hi Markus,
>>
>> On Mon, Dec 04, 2017 at 08:13:38PM +0100, Markus Koschany wrote:
>>> Package: src:libextractor
>>> Version: 1:1.6-1
>>> Severity: important
>>> Tags: security
>>>
>>> Hi,
>>>
>>> while I was working on the security update for Wheezy I discovered
>>> that libextractor in Buster/Sid is still vulnerable to CVE-2017-15600
>>> and CVE-2017-15602. I could reproduce two segmentation faults with the
>>> provided POCs. They are attached to the upstream bug report:
>>>
>>> http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg4.html
>>> http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg5.html
>>>
>>> Just run "extract -i $POC"
>>>
>>> I'm attaching my gdb log files to this bug report.
>>
>> Since the issues happen in different places from the original reports,
>> can you request two new CVEs for those issues?
>>
>> So for tracking purposes these are two new raised issues, different
>> from CVE-2017-15600 and CVE-2017-15602 and would possibly require two
>> new ones. Can you as well report it to upstream in case Bertrand
>> cannot cime in?
>>
>> In case not let me know, and I can take care of it tomorrow.
> 
> Interestignly the issues you describe does not seem triggerable with a
> fresh build of 1.6 in sid (with --enable-shared=no,
> --enable-static=yes with -O0).
> 
> sid:~/libextractor-1.6# ./src/main/extract -i ~/1338044
> Keywords for file /root/1338044:
> sid:~/libextractor-1.6# ./src/main/extract -i ~/bin_6iRW3tXve.bin
> Keywords for file /root/bin_6iRW3tXve.bin:
> sid:~/libextractor-1.6#
> 
> and neither with current HEAD (6c70420641fc1d081bcecf323671ca169b13a129).
> 
> It is though with the Debian package (re)build. What is different?

I can still reproduce it when I rebuild the package. If you disable
optimization with -O0 some compiler behaviors will change. I don't know
the details but what is undefined behavior with -O2 is somehow OK with
-O0. I just wanted to forward this upstream but if you say that it is
not reproducible with upstream HEAD, it's probably pointless.

Maybe we should wait for the next release which will also fix
CVE-2017-15922 or Bertrand could package the latest Git snapshot? Shall
I remove the fixed versions for both CVE in the security tracker?

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#848890: [Pkg-swan-devel] Bug#848890: polished remaining delta for re-review

2017-12-04 Thread Yves-Alexis Perez

On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote:
> Pushed it to the same debian-submission-nov2017 branch as before.

Thanks,

I don't really have good news though. I took a look and first, it seems that
the git commit entries aren't really good. git log --format=oneline is barely
readable, for example.

For the commit contents:

1aa409a5 (mass plugin enable): NACK again; I won't enable that many stuff (and
especially not in one go)
d83c243b (duplicheck disable): one good reason for the NACK just above: it's
not enabled in Debian, you just enabled it in 1aa409a5 :)
766d4f0d (ha disable): not really sure; it's way easier to have a custom
kernel than a custom strongSwan
85150f06 (kernel-libipsec enable): for reference, this is #739641 and I'm
still not sure I like it. I might pick it but end up disabling it before
release
a587dc11 (TNC move): I might pick this one because TNC is pretty standalone
per-se and it might make sense to split it, but really that's a lot of new
binary packages.
7629c11a7 (test-vectors move): NACK, what's the justification? Also it'll need
some breaks/replaces
f9e7f9007 (CCN move): NACK, what's the justification? Also, the break/replace
have the ubuntu version in them, which is wrong for Debian.
13300d3bf (libstrongswan.install reorder): ACK, I could pick it if there was
an isolated changelog entry with it
4fe0861e2 (kernel-netlink conffiles): NACK, these files are installed only on
Linux and thus the handling is done in debian/rules
76535cba5 (libfast disable): Should be ok, if I have an isolated changelog
entry for this
8dbf648b7 (libcharon-standard-plugin): I can understand the rationale (plugins
for common password-based mobile VPN setup), but I don't really like it. I
don't really like adding a new binary package, and the name is definitely not
good. Also, as far as I understand it, the plugins are useful when you're
actually configuring a client/roadwarrior to imitate a mobile client with its
limitations. I don't think it's a good thing to do, I'd prefer simplifying the
secure uses cases, like pubkeys-based ones.
9b5769771 (changelog update): NACK for obvious reason, I'd need isolated
changes to the changelog (although obviously it's not simple to cherry-pick
them either, I think I prefer it that way).

Regards, and again thanks for the work you do.

Regards,
-- 
Yves-Alexis

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

Bug#883340: dgit build accesses the internet and fails when offline.

2017-12-04 Thread Sean Whitton

Hello,

On Mon, Dec 04 2017, Ian Jackson wrote:

> I think we are talking about cross purposes.
>
> dgit's build subcommands all pass non-standard -I -i options to
> dpkg-buildpackage.  These -I -i options are lengthy (and have changed
> in dgit's history at least once due to a bug being discovered), so
> they need to be abstracted somewhere.
>
> So even to do a completely offline build, not intended for upload, it
> is necessary to use some kind of nonstandard wrapper (other than
> debuild or whatever), unless no source package is required at all.

Yes, sorry.

I was unconsciously assuming that the only offline builds anyone would
want would be binary packages, not source packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#883537: sosreport: Regresion from [sosreport] add per-plugin package verification lists.

2017-12-04 Thread Eric Desrochers

Package: sosreport
Version: 3.5-1
Severity: normal

Dear Maintainer,

We found a severe regression introduced by the following change:
[sosreport] add per-plugin package verification lists.

Many "packages = " lines are no longer work preventing
automatic package detection.

The situation is also reproducible with sosreport upstream

Current upstream PR :
https://github.com/sosreport/sos/issues/1155

Would be great to have this fix into Debian once the upstream PR is
merged in sosreport project.

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

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

Versions of packages sosreport depends on:
ii  python3  3.5.3-1
ii  python3-six  1.10.0-3

sosreport recommends no packages.

sosreport suggests no packages.

Bug#883518: boomaga: FTBFS with poppler 0.61.1

2017-12-04 Thread Lisandro Damián Nicanor Pérez Meyer

El 4 dic. 2017 3:21 p.m., "Emilio Pozuelo Monfort" 
escribió:

Package: boomaga
Version: 0.9.1-2
Severity: important
Control: block 883514 with -1

Hi,

Your package fails to build with poppler 0.61.1 from experimental. This
version introduces some API changes to the Object class which cause
some problems to a few packages. In some cases upstream has already
adapted to these changes, so it'd be good if you can backport a
patch to ease the transition.

Build log attached.


ACK, I'll take a look as soon as possible.

Thanks!

Bug#883536: isc-dhcp FTBFS with libbind-export-dev 1:9.11.2+dfsg-2

Source: isc-dhcp
Version: 4.3.5-3
Severity: serious
Tags: buster sid

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

...
gcc  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall 
-I/usr/include/bind-export -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_PATH_DHCPD_CONF='"/etc/dhcp/dhcpd.conf"' 
-D_PATH_DHCPD_DB='"/var/lib/dhcp/dhcpd.leases"' 
-D_PATH_DHCPD6_DB='"/var/lib/dhcp/dhcpd6.leases"' 
-D_PATH_DHCLIENT_SCRIPT='"/sbin/dhclient-script"' 
-D_PATH_DHCLIENT_CONF='"/etc/dhcp/dhclient.conf"' 
-D_PATH_DHCLIENT_DB='"/var/lib/dhcp/dhclient.leases"' 
-D_PATH_DHCLIENT6_DB='"/var/lib/dhcp/dhclient6.leases"' -DNSUPDATE  
-I../includes -I../bind/include  -lirs-export -Wl,-z,relro -Wl,-z,now -o svtest 
test.o libomapi.a -lirs-export -ldns-export -lisc-export 
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libirs-export.a(dnsconf.o):
 In function `configure_dnsseckeys.constprop.0':
(.text+0x49): undefined reference to `cfg_map_get'
(.text+0x5c): undefined reference to `cfg_list_first'
(.text+0x89): undefined reference to `cfg_listelt_value'
(.text+0x91): undefined reference to `cfg_list_first'
(.text+0xbb): undefined reference to `cfg_listelt_value'
(.text+0xcd): undefined reference to `cfg_tuple_get'
(.text+0xd5): undefined reference to `cfg_obj_asuint32'
(.text+0xe7): undefined reference to `cfg_tuple_get'
(.text+0xef): undefined reference to `cfg_obj_asuint32'
(.text+0x101): undefined reference to `cfg_tuple_get'
(.text+0x109): undefined reference to `cfg_obj_asuint32'
(.text+0x11c): undefined reference to `cfg_tuple_get'
(.text+0x124): undefined reference to `cfg_obj_asstring'
(.text+0x1cb): undefined reference to `cfg_tuple_get'
(.text+0x1d3): undefined reference to `cfg_obj_asstring'
(.text+0x393): undefined reference to `cfg_list_next'
(.text+0x3a9): undefined reference to `cfg_list_next'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libirs-export.a(dnsconf.o):
 In function `irs_dnsconf_load':
(.text+0x765): undefined reference to `cfg_obj_destroy'
(.text+0x76d): undefined reference to `cfg_parser_destroy'
(.text+0x7de): undefined reference to `cfg_parser_create'
(.text+0x813): undefined reference to `cfg_type_dnsconf'
(.text+0x825): undefined reference to `cfg_parse_file'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdns-export.a(openssl_link.o):
 In function `dst__openssl_init':
(.text+0x1d4): undefined reference to `CRYPTO_set_mem_functions'
(.text+0x23a): undefined reference to `OPENSSL_load_builtin_modules'
(.text+0x23f): undefined reference to `ENGINE_load_builtin_engines'
(.text+0x244): undefined reference to `ERR_clear_error'
(.text+0x252): undefined reference to `CONF_modules_load_file'
(.text+0x269): undefined reference to `ENGINE_by_id'
(.text+0x286): undefined reference to `ENGINE_set_default'
(.text+0x2a0): undefined reference to `ENGINE_free'
(.text+0x2e1): undefined reference to `ENGINE_get_default_RAND'
(.text+0x2f0): undefined reference to `ENGINE_finish'
(.text+0x311): undefined reference to `ENGINE_new'
(.text+0x333): undefined reference to `ENGINE_set_RAND'
(.text+0x33b): undefined reference to `ENGINE_set_default_RAND'
(.text+0x343): undefined reference to `ENGINE_free'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdns-export.a(openssl_link.o):
 In function `dst__openssl_destroy':
(.text+0x355): undefined reference to `OPENSSL_cleanup'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdns-export.a(openssl_link.o):
 In function `dst__openssl_toresult':
(.text+0x394): undefined reference to `ERR_get_error'
(.text+0x3a9): undefined reference to `ERR_clear_error'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdns-export.a(openssl_link.o):
 In function `dst__openssl_toresult3':
(.text+0x3f2): undefined reference to `ERR_get_error'
(.text+0x48c): undefined reference to `ERR_error_string_n'
(.text+0x4ea): undefined reference to `ERR_get_error_line_data'
(.text+0x4f4): undefined reference to `ERR_clear_error'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdns-export.a(openssl_link.o):
 In function `dst__openssl_getengine':
(.text+0x5b6): undefined reference to `ENGINE_get_id'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdns-export.a(openssldh_link.o):
 In function `openssldh_cleanup':
(.text+0xc): undefined reference to `BN_free'
(.text+0x18): undefined reference to `BN_free'
(.text+0x24): undefined reference to `BN_free'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdns-export.a(openssldh_link.o):
 In function `openssldh_isprivate':
(.text+0x6a): undefined reference to `DH_get0_key'
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libdns-export.a(openssldh_link.o):
 In function `openssldh_tofile':
(.text+0x124): undefined reference to `DH_get0_key'
(.text+0x13d): undefined reference to `DH_get0_pqg'
(.text+0x155): undefined reference to `BN_num_bits'
(.text+0x1a0): undefined reference to

Bug#768073: LXC team take over ITP?

2017-12-04 Thread Clément Hermann

Hi !

Time for a status update on this one, hopefully !

On Fri, 13 Oct 2017 13:36:47 +0200 Clément Hermann
 wrote:

>
> I see there are only a couple dependancies left on the wiki page. Do you
> need help ?
> I'm not a Go expert, but I would really like to see LXD in Debian.
> (also, not a DM/DD - Yet! )
>
> I started looking at golang-gopkg-inconshreveable-log15.v2, the
> packaging should be straightforward enough apparently. I'm willing to do
> it if it helps.

This last one is not needed anymore.

So, I did some work on golang-gopkg-flosch-pongo2

(#839748), since I had no answer.
It should be fit for release but I would need someone (from the pkg-go
team) to review and upload.

I also started working on golang-gopkg-lxc-go-lxc.v2-dev (ITP: #883488).

That's the last dependancy for LXD.

So I started looking packaging LXD stable-2.0 as well, and asked to join
the pkg-lxc team (pending approval).

I think the best approach would be to not start from the ubuntu package,
but instead, start from scratch, with dh-make-golang, so that we have
proper initial packaging, and then integrate ubuntu work where needed.

Cheers,

-- 
nodens

Bug#695887: reportbug locks terminal, refuses echo, requires "reset" after viewing followup

2017-12-04 Thread Nis Martensen

control: forcemerge 695887 849763 882983
control: tags -1 patch

These bugs are caused by file descriptors not being closed properly. The
attached patch should help.
>From 1dbc071c3b966f4fb351948412ffe438de11e62f Mon Sep 17 00:00:00 2001
From: Nis Martensen 
Date: Mon, 4 Dec 2017 21:33:15 +0100
Subject: [PATCH] Make sure some file descriptors will be closed properly

---
 bin/reportbug   |  3 ++-
 reportbug/submit.py |  3 ++-
 reportbug/ui/text_ui.py | 18 ++
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/bin/reportbug b/bin/reportbug
index 7eda598..6a554b6 100755
--- a/bin/reportbug
+++ b/bin/reportbug
@@ -339,7 +339,8 @@ def handle_editing(filename, dmessage, options, sendto, attachments, package,
 skip_editing = True
 if x == 'l':
 pager = os.environ.get('PAGER', 'sensible-pager')
-os.popen(pager, 'w').write(message)
+with os.popen(pager, 'w') as p:
+p.write(message)
 else:
 sys.stdout.write(message)
 elif x == 't':
diff --git a/reportbug/submit.py b/reportbug/submit.py
index e6bd50b..ea613cb 100644
--- a/reportbug/submit.py
+++ b/reportbug/submit.py
@@ -265,7 +265,8 @@ def send_report(body, attachments, mua, fromaddr, sendto, ccaddr, bccaddr,
 if paranoid and not (template or printonly):
 pager = os.environ.get('PAGER', 'sensible-pager')
 try:
-os.popen(pager, 'w').write(message)
+with os.popen(pager, 'w') as p:
+p.write(message)
 except  Exception as e:
 # if the PAGER exits before all the text has been sent,
 # it'd send a SIGPIPE, so crash only if that's not the case
diff --git a/reportbug/ui/text_ui.py b/reportbug/ui/text_ui.py
index b852b79..4a60ff8 100644
--- a/reportbug/ui/text_ui.py
+++ b/reportbug/ui/text_ui.py
@@ -451,10 +451,9 @@ def show_report(number, system, mirrors,
 text = 'Original report - %s\n\n%s' % (buginfo.subject, messages[0])
 
 if not skip_pager:
-fd = os.popen('sensible-pager', 'w')
 try:
-fd.write(text)
-fd.close()
+with os.popen('sensible-pager', 'w') as fd:
+fd.write(text)
 except IOError as x:
 if x.errno == errno.EPIPE:
 pass
@@ -1009,7 +1008,8 @@ def display_report(text, use_pager=True, presubj=False):
 
 pager = os.environ.get('PAGER', 'sensible-pager')
 try:
-os.popen(pager, 'w').write(text)
+with os.popen(pager, 'w') as p:
+p.write(text)
 except IOError:
 pass
 
@@ -1023,9 +1023,10 @@ def spawn_editor(message, filename, editor, charset='utf-8'):
 
 # Move the cursor for lazy buggers like me; add your editor here...
 ourline = 0
-for (lineno, line) in enumerate(open(filename)):
-if line == '\n' and not ourline:
-ourline = lineno + 2
+with open(filename) as f:
+for (lineno, line) in enumerate(f):
+if line == '\n' and not ourline:
+ourline = lineno + 2
 
 opts = ''
 if 'vim' in edname:
@@ -1061,7 +1062,8 @@ def spawn_editor(message, filename, editor, charset='utf-8'):
 if '&' in editor:
 return (None, 1)
 
-newmessage = open(filename).read()
+with open(filename) as f:
+newmessage = f.read()
 
 if newmessage == message:
 ewrite('No changes were made in the editor.\n')
-- 
2.11.0

Bug#883535: O: python-characteristic -- helper for implementing attribute-related object protocols

2017-12-04 Thread Matthias Klose

Package: wnpp

Description: helper for implementing attribute-related object protocols (Python 
2)
 characteristic is Python package with class decorators that ease the chores
 of implementing the most common attribute-related object protocols.
 .
 You just specify the attributes to work with and characteristic gives you:
 .
   - a nice human-readable __repr__,
   - a complete set of comparison methods,
   - and a kwargs-based initializer (that cooperates with your existing one)
 .
 without writing dull boilerplate code again and again.

Bug#883534: dietlibc-dev: linux-libc-dev 4.14.2-1 linux/fs.h does not compile with dietlibc-dev linux/types.h

Package: dietlibc-dev
Version: 0.34~cvs20160606-7
Severity: serious
Control: affects -1 src:util-vserver linux-libc-dev

linux-libc-dev 4.13.13-1 -> 4.14.2-1 makes util-vserver FTBFS:

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

...
diet -Os gcc -DHAVE_CONFIG_H -I.  -I ./lib -I ./ensc_wrappers -D_GNU_SOURCE 
-D_REENTRANT -DNDEBUG -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -std=c99 -Wall 
-pedantic -W -funit-at-a-time -MT 
lib_internal/lib_internal_libinternal_diet_a-util-cleanupmount.o -MD -MP -MF 
lib_internal/.deps/lib_internal_libinternal_diet_a-util-cleanupmount.Tpo -c -o 
lib_internal/lib_internal_libinternal_diet_a-util-cleanupmount.o `test -f 
'lib_internal/util-cleanupmount.c' || echo './'`lib_internal/util-cleanupmount.c
In file included from lib_internal/util-cleanupmount.c:25:0:
/usr/include/linux/fs.h:366:23: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '__kernel_rwf_t'
 typedef int __bitwise __kernel_rwf_t;
   ^~
Makefile:7565: recipe for target 
'lib_internal/lib_internal_libinternal_diet_a-util-cleanupmount.o' failed
make[3]: *** [lib_internal/lib_internal_libinternal_diet_a-util-cleanupmount.o] 
Error 1


The root cause is:

/usr/lib/x86_64-linux-gnu/diet/include/linux/fs.h does not exist
but /usr/include/linux/fs.h does exist.

/usr/lib/x86_64-linux-gnu/diet/include/linux/types.h does exist.

The result is a combination of the linux-libc-dev linux/fs.h
and the dietlibc-dev linux/types.h.

__bitwise is defined in /usr/include/linux/types.h but not in
/usr/lib/x86_64-linux-gnu/diet/include/linux/types.h, and
/usr/include/linux/fs.h just started using it.

Bug#883438: [Pkg-emacsen-addons] Bug#883438: ert-helper.el does not execute configured alternative for (ert-run-tests-batch-and-exit)

2017-12-04 Thread Nicholas D Steeves

control: tag -1 -moreinfo
control: close -1

On Mon, Dec 04, 2017 at 10:19:03AM -0700, Sean Whitton wrote:
> control: tag -1 +moreinfo
> 
> Hello,
> 
> On Sun, Dec 03 2017, Nicholas D Steeves wrote:
> 
> > Steps to reproduce:
> >
> > 1. Pick a package that has ert tests.
> > 2. echo '(exit)' > debian/ert-helper.el
> 
> Do you have the line
> 
> ert_helper = debian/ert-helper.el
> 
> in debian/elpa-test?
> 
> -- 
> Sean Whitton

Touché, I'm not sure how I failed to noticed that the ert_helper
configuration key was missing from d/elpa-test on my WIP branch for
this package.  Sorry for wasting your time, I'm humbly closing this
bug as invalid.

Sincerely,
Nicholas

signature.asc
Description: PGP signature

Bug#855632: Bug#883217: linux: open on NFSv4 exported file on nfs server: "Resource temporarily unavailable" under reproducible conditions when client has granted read delegation on file

Hi

On Thu, Nov 30, 2017 at 03:35:40PM -0700, Stephen Dowdy wrote:
> On 11/30/2017 01:39 PM, Salvatore Bonaccorso wrote:
> > Is this worth trying to be fixed for the jessie kernel?
> 
> Salvatore,
> 
> I believe this is likely the reason for my bug report:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855632
> 
> as that system has thrown EAGAIN errors since i installed it in April, 2015.
> It's a 10 NIC NFS server for the department, and often throws the error when 
> i update files that are likely being read/open by client systems.
> (it doesn't have a huge resource consumption load ever and i get that failure)
> 
> So, i vote yeah ;)

Okay.

I tried to track that further down, and attached 

0001-locks-remove-i_have_this_lease-check-from-__break_le.patch
0002-locks-__break_lease-cleanup-in-preparation-of-allowi.patch

to be applied on top of the current jessie branch in git.

Attached are the two individual patches:

locks-remove-i_have_this_lease-check-from-__break_le.patch
locks-__break_lease-cleanup-in-preparation-of-allowi.patch

With these two patches applied I was not able to reproduce the problem
now for a while, whereas previously it was relatively fast
triggerable.

Can you confirm the issue would be addressed as well for you?
See the kernel-handbook for the simple-patching guideline:
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.2

Still since the patches were integrated in a bigger rewrite/touching
of fs/locks.c, fs/nfsd this might need a proper/deeper review if that
is complete and does not break anything.

Regards,
Salvatore
>From 6997c3a97579e46cb839c334b4b9b6f96c3b573b Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Mon, 4 Dec 2017 11:11:28 +0100
Subject: [PATCH 1/2] locks: remove i_have_this_lease check from __break_lease

---
 debian/changelog   |  6 +++
 ...e-i_have_this_lease-check-from-__break_le.patch | 54 ++
 debian/patches/series  |  1 +
 3 files changed, 61 insertions(+)
 create mode 100644 debian/patches/bugfix/all/locks-remove-i_have_this_lease-check-from-__break_le.patch

diff --git a/debian/changelog b/debian/changelog
index 977e1cea3..955b86f56 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+linux (3.16.51-3) UNRELEASED; urgency=medium
+
+  * locks: remove i_have_this_lease check from __break_lease
+
+ -- Salvatore Bonaccorso   Mon, 04 Dec 2017 12:17:53 +0100
+
 linux (3.16.51-2) jessie; urgency=medium
 
   * [mips*] inst: Avoid ABI change in 3.16.51
diff --git a/debian/patches/bugfix/all/locks-remove-i_have_this_lease-check-from-__break_le.patch b/debian/patches/bugfix/all/locks-remove-i_have_this_lease-check-from-__break_le.patch
new file mode 100644
index 0..04a778b40
--- /dev/null
+++ b/debian/patches/bugfix/all/locks-remove-i_have_this_lease-check-from-__break_le.patch
@@ -0,0 +1,54 @@
+From: Jeff Layton 
+Date: Mon, 1 Sep 2014 14:27:43 -0400
+Subject: locks: remove i_have_this_lease check from __break_lease
+Origin: https://git.kernel.org/linus/843c6b2f4cef384af8e0de6b7ac7191675030e3a
+
+I think that the intent of this code was to ensure that a process won't
+deadlock if it has one fd open with a lease on it and then breaks that
+lease by opening another fd. In that case it'll treat the __break_lease
+call as if it were non-blocking.
+
+This seems wrong -- the process could (for instance) be multithreaded
+and managing different fds via different threads. I also don't see any
+mention of this limitation in the (somewhat sketchy) documentation.
+
+Remove the check and the non-blocking behavior when i_have_this_lease
+is true.
+
+Signed-off-by: Jeff Layton 
+[carnil: Backport for 3.16:
+ - adjust context
+]
+---
+ fs/locks.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/fs/locks.c
 b/fs/locks.c
+@@ -1326,7 +1326,6 @@ int __break_lease(struct inode *inode, u
+ 	struct file_lock *new_fl, *flock;
+ 	struct file_lock *fl;
+ 	unsigned long break_time;
+-	int i_have_this_lease = 0;
+ 	bool lease_conflict = false;
+ 	int want_write = (mode & O_ACCMODE) != O_RDONLY;
+ 
+@@ -1346,8 +1345,7 @@ int __break_lease(struct inode *inode, u
+ 	for (fl = flock; fl && IS_LEASE(fl); fl = fl->fl_next) {
+ 		if (leases_conflict(fl, new_fl)) {
+ 			lease_conflict = true;
+-			if (fl->fl_owner == current->files)
+-i_have_this_lease = 1;
++			break;
+ 		}
+ 	}
+ 	if (!lease_conflict)
+@@ -1377,7 +1375,7 @@ int __break_lease(struct inode *inode, u
+ 		fl->fl_lmops->lm_break(fl);
+ 	}
+ 
+-	if (i_have_this_lease || (mode & O_NONBLOCK)) {
++	if (mode & O_NONBLOCK) {
+ 		trace_break_lease_noblock(inode, new_fl);
+ 		error = -EWOULDBLOCK;
+ 		goto out;
diff --git a/debian/patches/series b/debian/patches/series
index 4cd4a739c..4ab96adb2 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -251,6 +251,7 @@

Bug#877344: [Debian-med-packaging] Bug#877344: python-mne FTBFS: ERROR: Test ICA on raw and epochs

2017-12-04 Thread Yaroslav Halchenko

On Mon, 04 Dec 2017, Alexandre Gramfort wrote:

>Hi Andreas,
>I don't have the bandwidth to address this sorry.
>Also mne 0.13 is now 2 versions behind where we are now.
>Nobody found the time to do the debian packaging for 0.14
>and 0.15 so far.
>Really sorry about this.

if only life was easy and fair ;)

...
/usr/lib/python2.7/dist-packages/mayavi/core/source.py:209: DeprecationWarning: 
use "HasTraits.trait_set" instead
  obj.set(scene=self.scene, parent=self)
/usr/lib/python2.7/dist-packages/mayavi/core/module_manager.py:260: 
DeprecationWarning: use "HasTraits.trait_set" instead
  obj.set(module_manager=self, scene=self.scene, parent=self)
/usr/lib/python2.7/dist-packages/mayavi/tools/pipe_base.py:157: 
DeprecationWarning: use "HasTraits.trait_get" instead
  traits = self.get(self.class_trait_names())
/usr/lib/python2.7/dist-packages/mayavi/tools/pipe_base.py:171: 
DeprecationWarning: use "HasTraits.trait_set" instead
  **traits)
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:833: 
DeprecationWarning: use "HasTraits.trait_set" instead
  ).set(item = item, object_name = item.object )
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:809: 
DeprecationWarning: use "HasTraits.trait_set" instead
  editor_factory = trait.get_editor().set(**item.editor_args)
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:833: 
DeprecationWarning: use "HasTraits.trait_set" instead
  ).set(item = item, object_name = item.object )
/usr/lib/python2.7/dist-packages/traitsui/group.py:793: DeprecationWarning: use 
"HasTraits.trait_set" instead
  orientation = self.orientation ) )
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:809: 
DeprecationWarning: use "HasTraits.trait_set" instead
  editor_factory = trait.get_editor().set(**item.editor_args)
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:833: 
DeprecationWarning: use "HasTraits.trait_set" instead
  ).set(item = item, object_name = item.object )
Segmentation fault (core dumped)
debian/rules:25: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 139

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

Bug#883533: nmu: db5.3, tcl8.6, libjpeg-turbo, wayland, fftw3, nspr, libgudev, tk8.6

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

I would like to ask for binNMUing 8 packages. All of them happen to be
+b1 for mips64el and "normal" for all other architectures. Fixing these
resolves all binNMU-induced skews affecting dependency satisfaction of
source packages with popcon of at least 8000, so this limited set has a
noticeable impact to cross build QA. I hope I got the wanna-build
invocation right:

nmu db5.3_5.3.28-13.1 . ANY -mips64el . -m "unskew multiarch"
nmu tcl8.6_8.6.7+dfsg-1 . ANY -mips64el . -m "unskew multiarch"
nmu libjpeg-turbo_1:1.5.2-2 . ANY -mips64el . -m "unskew multiarch"
nmu wayland_1.14.0-1 . ANY -mips64el . -m "unskew multiarch"
nmu fftw3_3.3.6p2-2 . ANY -mips64el . -m "unskew multiarch"
nmu nspr_2:4.16-1 . ANY -mips64el . -m "unskew multiarch"
nmu libgudev_232-1 . ANY -mips64el . -m "unskew multiarch"
nmu tk8.6_8.6.7-1 . ANY -mips64el . -m "unskew multiarch"

Barring errors with binNMU handling of M-A:same packages, I don't expect
to send more of such batches. This is the big fish to me. Most other
skews I am seeing are caused by arch-specific FTBFS. Scheduling them at
low priority is fine. QA will benefit as soon as they hit unstable.

Helmut

Bug#883532: mount bind creates multiple mounts on multiple calls

2017-12-04 Thread ST

Package: mount
Version: 2.25.2-6
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

1. create an entry in /etc/fstab as follows:
/home/testuser1 /chroots/testuser1/home/testuser1 bind defaults,bind 0 0

2. run multiple times following command:
mount /home/testuser1

3. run
mount

4. see the outcome - /home/testuser1 was mounted multiple times, instead of 
quiting with error message "/home/testuser1 is already mounted"

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
see above

   * What was the outcome of this action?
the directory was mounted several times.

   * What outcome did you expect instead?
the directory should be mounted only once and any further attempt should 
produce an error "already mounted"


While normaly one will not mount the same directory several times - it does 
occur when using Ansible to configure the system, as it is common to run the 
same Ansible scripts (playbooks) multiple times which are supposed to be 
idempotent (not to cause changes on multiple runs of the same script).

Thank you very much!

see:
https://github.com/ansible/ansible/issues/29870
https://askubuntu.com/questions/595418/how-to-prevent-duplicate-bind-mounts


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


-- System Information:
I observed this problem on a remote system (Debian 9)...

Here is my local machine info:
Debian Release: 8.3
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mount depends on:
ii  libc6  2.19-18+deb8u3
ii  libmount1  2.25.2-6
ii  libselinux12.3-2
ii  libsmartcols1  2.25.2-6

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common  1:1.2.8-9

-- no debconf information

Bug#883528: libextractor: CVE-2017-15600 and CVE-2017-15602 are not completely fixed

And additionally the results from an ASAN build:

For the one related to the CVE-2017-15000 reproducer:

root@sid:~# extract -i extract-nsf_extract_method-nsf_extractor-164.crash
Keywords for file extract-nsf_extract_method-nsf_extractor-164.crash:
xm_extractor.c:80:7: runtime error: null pointer passed as argument 1, which is 
declared to never be null
ASAN:DEADLYSIGNAL
=
==22442==ERROR: AddressSanitizer: SEGV on unknown address 0x0008 (pc 
0x7f916bdf6d06 bp 0x7ffd356d46c0 sp 0x7ffd356d4520 T0)
==22442==The signal is caused by a READ memory access.
==22442==Hint: address points to the zero page.
#0 0x7f916bdf6d05 in EXTRACTOR_xm_extract_method 
(/usr/lib/x86_64-linux-gnu/libextractor/libextractor_xm.so+0x1d05)
#1 0x7f917a6d709c  (/usr/lib/x86_64-linux-gnu/libextractor.so.3+0x3209c)
#2 0x7f917a6d85d3 in EXTRACTOR_extract 
(/usr/lib/x86_64-linux-gnu/libextractor.so.3+0x335d3)
#3 0x403892  (/usr/bin/extract+0x403892)
#4 0x7f91793fa560 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x20560)
#5 0x404ce9  (/usr/bin/extract+0x404ce9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
(/usr/lib/x86_64-linux-gnu/libextractor/libextractor_xm.so+0x1d05) in 
EXTRACTOR_xm_extract_method
==22442==ABORTING
root@sid:~#

for the one related to the CVE-2017-15602 reproducer:

root@sid:~# extract -i bin_6iRW3tXve.bin 
Keywords for file bin_6iRW3tXve.bin:
=
==22470==ERROR: AddressSanitizer: negative-size-param: (size=-8)
#0 0x7fb94e64279b  (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x7679b)
#1 0x7fb93ba7be6c  (/usr/lib/x86_64-linux-gnu/libgme.so.0+0x8e6c)
#2 0x7fb93ba7bc89  (/usr/lib/x86_64-linux-gnu/libgme.so.0+0x8c89)
#3 0x7fb93ba9f231  (/usr/lib/x86_64-linux-gnu/libgme.so.0+0x2c231)
#4 0x7fb93ba9f5f2  (/usr/lib/x86_64-linux-gnu/libgme.so.0+0x2c5f2)
#5 0x7fb93ba7f94d  (/usr/lib/x86_64-linux-gnu/libgme.so.0+0xc94d)
#6 0x7fb93ba7eb7b in gme_load_data 
(/usr/lib/x86_64-linux-gnu/libgme.so.0+0xbb7b)
#7 0x7fb93ba7ec33 in gme_open_data 
(/usr/lib/x86_64-linux-gnu/libgme.so.0+0xbc33)
#8 0x7fb93f2be581  (/usr/lib/x86_64-linux-gnu/libavformat.so.57+0xbc581)
#9 0x7fb93f3ad16f in avformat_open_input 
(/usr/lib/x86_64-linux-gnu/libavformat.so.57+0x1ab16f)
#10 0x7fb93f8ece71 in EXTRACTOR_previewopus_extract_method 
(/usr/lib/x86_64-linux-gnu/libextractor/libextractor_previewopus.so+0x4e71)
#11 0x7fb94e39b09c  (/usr/lib/x86_64-linux-gnu/libextractor.so.3+0x3209c)
#12 0x7fb94e39c5d3 in EXTRACTOR_extract 
(/usr/lib/x86_64-linux-gnu/libextractor.so.3+0x335d3)
#13 0x403892  (/usr/bin/extract+0x403892)
#14 0x7fb94d0be560 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x20560)
#15 0x404ce9  (/usr/bin/extract+0x404ce9)

0x6160789e is located 30 bytes inside of 482-byte region 
[0x61607880,0x61607a62)
allocated by thread T0 here:
#0 0x7fb94e6a6758 in __interceptor_posix_memalign 
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xda758)
#1 0x7fb93f68c782 in av_malloc 
(/usr/lib/x86_64-linux-gnu/libavutil.so.55+0x31782)

SUMMARY: AddressSanitizer: negative-size-param 
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0x7679b) 
==22470==ABORTING
root@sid:~#

Regards,
Salvatore

Bug#877849: [tryton-debian] Namespace conflict for python-magic

2017-12-04 Thread Adam Hupp

I've pushed an update here:

https://github.com/ahupp/python-magic/tree/libmagic-compat

It includes a copy of libmagic's bindings, wrapped in deprecation
warnings.  So apps should work regardless of which they depend on.
Could you take a look and see if this works for your case?

On Fri, Oct 27, 2017 at 5:44 AM, Mathias Behrle  wrote:
> * Mathias Behrle: " Re: [tryton-debian] Namespace conflict for
>   python-magic" (Thu, 5 Oct 2017 12:01:16 +0200):
>
> Hi Adam,
>
> are there any news on the subject?
>
> The release of Tryton, that will require python-magic is scheduled for next
> week. It would be a great service to our users and simplify things a lot, if 
> we
> had a common python-magic in place. Please let us know, if we can help with 
> the
> planned merge.
>
> Thanks,
> Mathias
>
>
>> * Adam Hupp: " Re: Namespace conflict for python-magic" (Tue, 3 Oct 2017
>>   11:06:38 -0700):
>>
>> That's good news, Adam, thanks for it! Looking forward to get your diff.
>>
>> Best regards,
>> Mathias
>>
>>
>> > Sorry about the slow response.  This has been a pain for a while.  I
>> > have a provisional diff to merge the two packages.  Will give it some
>> > testing and pass a branch to you folks to take a look.  Ideally the
>> > upstream file package would take it over.
>> >
>> > On Wed, Sep 6, 2017 at 1:23 AM, Mathias Behrle  wrote:
>> > > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Tue, 5 Sep
>> > > 2017 18:24:25 +0200):
>> > >
>> > >> Mathias Behrle wrote...
>> > >>
>> > >> > * Christoph Biedl: " Re: Namespace conflict for python-magic" (Mon, 4
>> > >> > Sep 2017 19:38:56 +0200):
>> > >>
>> > >> > > The cleanest solution indeed was to bring both upstreams together 
>> > >> > > and
>> > >> > > ask them to reconcile the APIs and eventually make one of the both
>> > >> > > implementations obsolete. As things happen such an attempt was
>> > >> > > started two years ago but appearently never came to a result.[1]
>> > >> >
>> > >> > Agreed, that this would be the cleanest solution, but as you say there
>> > >> > is little probability, that the two upstreams will work together to
>> > >> > merge their implementations.
>> > >>
>> > >> Still this should be tried first. Also, I'm not that pessimistic, see
>> > >> below. So let's bring the parties involved into the loop:
>> > >
>> > > [...]
>> > >
>> > > Thanks for your additional information and initiative to re-launch the
>> > > merge of the two packages. This reads much better and more optimistic 
>> > > than
>> > > what I could find until now! Crossing fingers now in the hope for the 
>> > > best
>> > > outcome for everybody.
>> > >
>> > > Cheers,
>> > > Mathias
>> > >
>> > > --
>> > >
>> > > Mathias Behrle
>> > > PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
>> > > AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6
>> >
>> >
>> >
>>
>>
>>
>
>
>
> --
>
> Mathias Behrle
> PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
> AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6



-- 
Adam Hupp | http://hupp.org/adam/

Bug#881715: alsa-utils: High CPU usage on the default device

2017-12-04 Thread Andoru

> As you are the only one out of 60thsd Debian Alsa users who
> reported a high cpu-usage running alsa apps and I can't reproduce
> and don't know your system

What is there else that you'd like to know? What is it that I should be
doing to diagnose this? That's what I've been asking for the entirety of
this bug report!

> Hence you'll find a solution

I pretty much doubt it since I haven't got any useful info from you, nor
did I get any replies on alsa-users/alsa-dev.

Bug#883528: libextractor: CVE-2017-15600 and CVE-2017-15602 are not completely fixed

Hi

On Mon, Dec 04, 2017 at 08:27:13PM +0100, Salvatore Bonaccorso wrote:
> Hi Markus,
> 
> On Mon, Dec 04, 2017 at 08:13:38PM +0100, Markus Koschany wrote:
> > Package: src:libextractor
> > Version: 1:1.6-1
> > Severity: important
> > Tags: security
> > 
> > Hi,
> > 
> > while I was working on the security update for Wheezy I discovered
> > that libextractor in Buster/Sid is still vulnerable to CVE-2017-15600
> > and CVE-2017-15602. I could reproduce two segmentation faults with the
> > provided POCs. They are attached to the upstream bug report:
> > 
> > http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg4.html
> > http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg5.html
> > 
> > Just run "extract -i $POC"
> > 
> > I'm attaching my gdb log files to this bug report.
> 
> Since the issues happen in different places from the original reports,
> can you request two new CVEs for those issues?
> 
> So for tracking purposes these are two new raised issues, different
> from CVE-2017-15600 and CVE-2017-15602 and would possibly require two
> new ones. Can you as well report it to upstream in case Bertrand
> cannot cime in?
> 
> In case not let me know, and I can take care of it tomorrow.

Interestignly the issues you describe does not seem triggerable with a
fresh build of 1.6 in sid (with --enable-shared=no,
--enable-static=yes with -O0).

sid:~/libextractor-1.6# ./src/main/extract -i ~/1338044
Keywords for file /root/1338044:
sid:~/libextractor-1.6# ./src/main/extract -i ~/bin_6iRW3tXve.bin
Keywords for file /root/bin_6iRW3tXve.bin:
sid:~/libextractor-1.6#

and neither with current HEAD (6c70420641fc1d081bcecf323671ca169b13a129).

It is though with the Debian package (re)build. What is different?

Regards,
Salvatore

Bug#833507: wpasupplicant: workaround wifi.scan-rand-mac-address=no

2017-12-04 Thread Noël Köthe

Package: wpasupplicant
Version: 2:2.6-11
Followup-For: Bug #833507

Dear Maintainer,

with one of the sid updates last week my wireless stop
working again with the
wpa_supplicant[737]: wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0

I remember a workaround for this problem from the past to add 
into /etc/NetworkManager/NetworkManager.conf the following:

[device]
wifi.scan-rand-mac-address=no

which fixed it again for me.

...
network-manager (1.4.0-4) unstable; urgency=medium
...
  * Fix MAC address randomization.
Cherry-pick a couple of upstream commits which work around driver bugs
when MAC address randomization is used. (Closes: #835822, #835553)
...

Because the last network-manager was from 2017-11-10 and my wlan problem
started last week I'm a bit unsure where the root cause is.

Maybe the workaround helps someone.

Regards

Noël

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

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

Versions of packages wpasupplicant depends on:
ii  adduser   3.116
ii  libc6 2.25-3
ii  libdbus-1-3   1.12.2-1
ii  libnl-3-200   3.2.27-2
ii  libnl-genl-3-200  3.2.27-2
ii  libpcsclite1  1.8.22-1
ii  libreadline7  7.0-3
ii  libssl1.1 1.1.0g-2
ii  lsb-base  9.20170808

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

Bug#883531: RM: libplexus-containers1.5-java -- RoQA; manual cruft removal needed

Package: ftp.debian.org
Severity: normal
Control: block 880829 by -1


plexus-containers (1.7.1-7) unstable; urgency=medium
...
  * Removed libplexus-containers1.5-java (no longer used)
...
 -- Emmanuel Bourg   Tue, 07 Nov 2017 13:32:00 +0100

Bug#883528: libextractor: CVE-2017-15600 and CVE-2017-15602 are not completely fixed

Hi Markus,

On Mon, Dec 04, 2017 at 08:13:38PM +0100, Markus Koschany wrote:
> Package: src:libextractor
> Version: 1:1.6-1
> Severity: important
> Tags: security
> 
> Hi,
> 
> while I was working on the security update for Wheezy I discovered
> that libextractor in Buster/Sid is still vulnerable to CVE-2017-15600
> and CVE-2017-15602. I could reproduce two segmentation faults with the
> provided POCs. They are attached to the upstream bug report:
> 
> http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg4.html
> http://lists.gnu.org/archive/html/bug-libextractor/2017-10/msg5.html
> 
> Just run "extract -i $POC"
> 
> I'm attaching my gdb log files to this bug report.

Since the issues happen in different places from the original reports,
can you request two new CVEs for those issues?

So for tracking purposes these are two new raised issues, different
from CVE-2017-15600 and CVE-2017-15602 and would possibly require two
new ones. Can you as well report it to upstream in case Bertrand
cannot cime in?

In case not let me know, and I can take care of it tomorrow.

Regards,
Salvatore

Bug#883530: vtun FTCBFS: uses the build architecture strip