Bug#913705: transition: zimlib

[Kunal Mehta]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'd like to upgrade zimlib to v4 to get up to date with upstream once again.

The only dependency affected is libkiwix, which will require a new major
upstream release as well (I've prepared and tested it locally). The new
libkiwix will also fix #913506 for the ICU transition.

https://release.debian.org/transitions/html/auto-zimlib.html looks correct
AFAIK.

Ben file:

title = "zimlib";
is_affected = .depends ~ "libzim2" | .depends ~ "libzim4";
is_good = .depends ~ "libzim4";
is_bad = .depends ~ "libzim2";

This is my first time doing a transition - please let me know if I missed
anything.

Thanks,
- -- Kunal

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

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

-BEGIN PGP SIGNATURE-

iQJHBAEBCgAxFiEE+h6fmkHn9DUCyl1jUvyOe+23/KIFAlvr1CITHGxlZ29rdG1A
ZGViaWFuLm9yZwAKCRBS/I577bf8onlOD/41NmzL33NCHSa3570H5lI1oLsCy/ed
LwwB94fKh4cTYnkEYo4lc7AjK7EUhU4plfhaWttKRPc8sYdFCWzrsOEnVhmpD5Od
WP8vE1rdggUpYlHqkDvwx75Rj5hF2Boge4kgzCQ8yk+/c8hqNupeY+hbhF1dsiEi
iln6MXL/7sSu/A5urKLDJplBe1q9YYjre8FeqALI3M/Z56CHtO0HDEaHpiWI6OKx
XkNOnDkMffyUPfiM/qo44vmaS7RwV2knHhYYnS82oBKUrz65Jpiqp5Yv2DK+cLQE
zeqMdV+yOOju5qoJhk43xI9zLRte6vgSJzmp6pCPhbCMafQOnrO5v7b5yhvM775+
ULPiiTkJ8M3ZIL/mkdP8l860pLS/kOHUtbifIZS0OIxU95QUu7FkWB7jVvfBMTqb
rBq/ElM25mruPcAh/pJ7Kar/q1BcLe/y7FPcRNsXdZbNFrPXWPPqPOwGMoCNYQ+O
h9IZLUNlH9zmrDy9utHZle92pdg/Dh95uUf8Be2MFB/b8E5/xSoa4qRkhwAda626
Agx31uq+nfX21+0GSr3jcfzNN9N4sKAoO9xF1u5pl6qkKwmwB4ebx+io/ra0w+ZM
SjyNPInMbT7hoov0zHQ+4Y1Sw5wG9cJaKH1uETqVzm5eFke/vQKm9uMIdbOtP/0X
Wv6s10m6UL6eRA==
=vkOO
-END PGP SIGNATURE-

Bug#913635: php7.3-common: Repeatable segfault in php7.3 when running Cacti poller since upgrade to 7.3

[Jarno Paananen]

Hi,

running:

sudo dmesg|grep php7.3|awk '{print $7}'|addr2line -e /usr/bin/php7.3

output only ??:0 but addr2line -e /usr/bin/php7.3 25f000 gave:

./cli-build/./main/streams/streams.c:694

Anything else I could try?

// Jarno



Ondřej Surý  writes:

> Hi,
>
> could you please install php7.3-cli-dbgsym debugging package, and then
> run:
>
> addr2line -e /usr/bin/php7.3 559f0d644d5a
>
> (for all the values of `ip`)
>
> Thanks,
> --
> Ondřej Surý
> ond...@sury.org
>
>
>
>> On 13 Nov 2018, at 10:34, Jarno Paananen  wrote:
>> 
>> Package: php7.3-common
>> Version: 7.3.0~rc5-1
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> Since php was upgraded to 7.3 I get constant segfaults triggered by Cacti
>> poller being run from cron. So my dmesg is filled with messages such as this:
>> 
>> [22641940.244787] php[28600]: segfault at 7f3c45c005cc ip 559f0d644d5a sp
>> 7ffcc4f01080 error 4 in php7.3[559f0d49d000+25f000]
>> [22641946.234158] php[28597]: segfault at 7fbec9c005cc ip 564c154dcd5a sp
>> 7ffd85238da0 error 4 in php7.3[564c15335000+25f000]
>> [22642238.659938] php[28915]: segfault at 7f91ce0005cc ip 55c37af78d5a sp
>> 7fff60a8d150 error 4 in php7.3[55c37add1000+25f000]
>> [22642244.906287] php[28913]: segfault at 7fc4026005cc ip 55655c313d5a sp
>> 7fffcaa166a0 error 4 in php7.3[55655c16c000+25f000]
>> 
>> There are two hosts being polled so there are two of these lines every 5
>> minutes. However Cacti still seems to get the data so the crash doesn't seem
>> fatal. This has continued since first 7.3 version, didn't get this on 7.2.
>> 
>> 
>> -- Package-specific info:
>>  Additional PHP 7.3 information 
>> 
>>  PHP @PHP_VERSION SAPI (php7.3query -S): 
>> 
>>  PHP 7.3 Extensions (php7.3query -M -v): 
>> 
>>  Configuration files: 
>>  /etc/php/7.3/mods-available/calendar.ini 
>> extension=calendar.so
>> 
>>  /etc/php/7.3/mods-available/ctype.ini 
>> extension=ctype.so
>> 
>>  /etc/php/7.3/mods-available/exif.ini 
>> extension=exif.so
>> 
>>  /etc/php/7.3/mods-available/fileinfo.ini 
>> extension=fileinfo.so
>> 
>>  /etc/php/7.3/mods-available/ftp.ini 
>> extension=ftp.so
>> 
>>  /etc/php/7.3/mods-available/gettext.ini 
>> extension=gettext.so
>> 
>>  /etc/php/7.3/mods-available/iconv.ini 
>> extension=iconv.so
>> 
>>  /etc/php/7.3/mods-available/pdo.ini 
>> extension=pdo.so
>> 
>>  /etc/php/7.3/mods-available/phar.ini 
>> extension=phar.so
>> 
>>  /etc/php/7.3/mods-available/posix.ini 
>> extension=posix.so
>> 
>>  /etc/php/7.3/mods-available/shmop.ini 
>> extension=shmop.so
>> 
>>  /etc/php/7.3/mods-available/sockets.ini 
>> extension=sockets.so
>> 
>>  /etc/php/7.3/mods-available/sysvmsg.ini 
>> extension=sysvmsg.so
>> 
>>  /etc/php/7.3/mods-available/sysvsem.ini 
>> extension=sysvsem.so
>> 
>>  /etc/php/7.3/mods-available/sysvshm.ini 
>> extension=sysvshm.so
>> 
>>  /etc/php/7.3/mods-available/tokenizer.ini 
>> extension=tokenizer.so
>> 
>> 
>> -- System Information:
>> Debian Release: buster/sid
>>  APT prefers unstable
>>  APT policy: (500, 'unstable')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>> 
>> Kernel: Linux 4.15.0-1-amd64 (SMP w/2 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/bash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>> 
>> Versions of packages php7.3-common depends on:
>> ii  libc6   2.27-8
>> ii  libssl1.1   1.1.1-2
>> ii  php-common  2:68
>> ii  ucf 3.0038
>> 
>> php7.3-common recommends no packages.
>> 
>> php7.3-common suggests no packages.
>> 
>> Versions of packages php7.3-cli depends on:
>> ii  libargon2-1  0~20171227-0.1
>> ii  libc62.27-8
>> ii  libedit2 3.1-20180525-1
>> ii  libmagic11:5.34-2
>> ii  libpcre2-8-0 10.32-3
>> ii  libsodium23  1.0.16-2
>> ii  libssl1.11.1.1-2
>> ii  libxml2  2.9.4+dfsg1-7+b1
>> ii  mime-support 3.61
>> ii  php7.3-json  7.3.0~rc5-1
>> ii  php7.3-opcache   7.3.0~rc5-1
>> ii  php7.3-readline  7.3.0~rc5-1
>> ii  tzdata   2018g-1
>> ii  ucf  3.0038
>> ii  zlib1g   1:1.2.11.dfsg-1
>> 
>> Versions of packages php7.3-cli suggests:
>> ii  php-pear  1:1.10.6+submodules+notgz-1
>> 
>> Versions of packages libapache2-mod-php7.3 depends on:
>> ii  apache2-bin [apache2-api-20120211]  2.4.37-1
>> ii  libargon2-1 0~20171227-0.1
>> ii  libc6   2.27-8
>> ii  libmagic1   1:5.34-2
>> ii  libpcre2-8-010.32-3
>> ii  libsodium23 1.0.16-2
>> ii  libssl1.1   1.1.1-2
>> ii  libxml2 2.9.4+dfsg1-7+b1
>> ii  mime-support3.61
>> ii  php7.3-

Bug#913446: wireguard-tools: optionally reload module / interfaces on upgrade

[Daniel Kahn Gillmor]

This looks great and very thorough, Fabian.  thank you!  I'm trying to
reason about some of the details, to see how we can simplify things
further.  Some questions:

 * why put the module reloading in wireguard-tools.postinst and not in
   wireguard.postinst ?  There's no guarantee that wireguard-dkms will
   have been upgraded by the time wireguard-tools.postinst gets invoked.
   Indeed, wireguard-tools only "Recommends: wireguard-dkms (=
   ${source:Version})", but doesn't "Depends: wireguard-dkms".

   In some sense, i think this might actually belong in the postinst of
   the wireguard metapackage, where we can be sure that both subpackages
   (the kernel parts and the userspace parts) have been installed.  For
   minimalist installations (those without the wireguard metapackage)
   the admins can handle the upgrades manually themselves.

 * The debconf question looks good (and thank you for taking the time to
   care for i18n!), but i'm wondering whether three values is too many
   to choose from.  Is there any common use case where people would
   really need to have "always" instead of "module"?

 * heading further down the simplification path, what if we just said
   that the "wireguard" metapackage would take the behavior currently
   specified as "module" directly in it's postinst configuration,
   without offering the admin any choice?  The admins who don't want
   that behavior can always choose to not install the "wireguard"`
   package, and can track the two sub-packages manually.

I hope it's not too frustrating that i suggested the use of debconf over
on the mailing list, and now i'm suggesting that maybe we don't need to
use it at all.  Seeing both eggie's work and your work on this has
helped me think through the various options much farther than i would
have gotten on my own.

If we end up with something even simpler, that might be even better!

What do you think about this simplified proposal?  To implement it, i'd
probably change the description of the wireguard metapackage to clarify
this new additional functionality, and then try to make a trimmed down
version of your postinst script that does things as simply/quietly as
possible.

   --dkg


signature.asc
Description: PGP signature

Bug#644356: [backuppc] In host summary, column sort doesn't work well

[Adrien Grellier]

Hi,

The bug was with firefox. I just re-tested it with firefox 60 from
Debian Stable, and it is now properly sorted :)

Maybe it was a more a problem of firefox than backuppc.

Kind regards

Adrien

Le 14/11/2018 à 03:01, Axel Beckert a écrit :
> Control: tag -1 + confirmed
> Control: found -1 3.1.0-9
> Control: found -1 3.3.1-6
> Control: found -1 3.3.2-1
>
> Hi Adrien,
>
> Adrien Grellier wrote in 2011:
>
>> In the host summary, the columns « Full age » and « speed » aren't
>> properly sorted when I clicked on the title of the column. For
>> instance I got this for speed :
>>
>> 9.42
>> 8.79
>> 7.20
>> …
>> 2.10
>> 13.92
>> 12.67
>> 10.75
>> 1.50
>> 1.07
>>
>> It seems that the 10.* aren't properly handeled.
>>
>> I am using Debian stable, with backuppc 3.1.0-9.
> Can you remember which web browser you did use? So far I only saw this
> in Chromium, but it worked correctly in Firefox.
>
>   Regards, Axel


-- 

Adrien Grellier  (02 40 37 15 55)
Informaticien du LHEEA
CNRS – École Centrale de Nantes

Bug#913704: ola: test compatibility with -Wl,--as-needed

[Steve Langasek]

Package: ola
Version: 0.10.7.nojsmin-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear maintainers,

The ola package is failing its c++ compile-and-run autopkgtest in Ubuntu,
because the test passes libraries on the g++ commandline before the source
file that references them, causing undefined references:

autopkgtest [05:31:12]: test command5: set -e; g++ -o linktest $(pkg-config --cf
lags --libs libola) debian/tests/hw.cc; ./linktest
autopkgtest [05:31:12]: test command5: [---
/usr/bin/ld: /tmp/cce3slFM.o: in function `main':
hw.cc:(.text+0x30): undefined reference to 
`ola::io::LoopbackDescriptor::LoopbackDescriptor()'
/usr/bin/ld: hw.cc:(.text+0x4a): undefined reference to 
`ola::client::OlaClient::OlaClient(ola::io::ConnectedDescriptor*)'
/usr/bin/ld: hw.cc:(.text+0x5a): undefined reference to 
`ola::client::OlaClient::Setup()'
/usr/bin/ld: hw.cc:(.text+0xfa): undefined reference to 
`ola::client::OlaClient::~OlaClient()'
/usr/bin/ld: hw.cc:(.text+0x142): undefined reference to 
`ola::client::OlaClient::~OlaClient()'
/usr/bin/ld: /tmp/cce3slFM.o: in function 
`ola::io::BidirectionalFileDescriptor::~BidirectionalFileDescriptor()':
hw.cc:(.text._ZN3ola2io27BidirectionalFileDescriptorD2Ev[_ZN3ola2io27BidirectionalFileDescriptorD5Ev]+0x18):
 undefined reference to `vtable for ola::io::BidirectionalFileDescriptor'
/usr/bin/ld: 
hw.cc:(.text._ZN3ola2io27BidirectionalFileDescriptorD2Ev[_ZN3ola2io27BidirectionalFileDescriptorD5Ev]+0x32):
 undefined reference to `vtable for ola::io::BidirectionalFileDescriptor'
[...]

  (http://autopkgtest.ubuntu.com/packages/o/ola/disco/s390x)

Per ,
libraries must be passed on the commandline after the objects which
reference them, otherwise they will be discarded by the linker, resulting in
errors such as the above.

I have uploaded the attached patch to ola in Ubuntu.  Please consider
applying it in Debian as well.

This is only a minor issue in Debian, but in Ubuntu it is a failing test
that is treated as a release blocker for this package.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ola-0.10.7.nojsmin/debian/tests/control 
ola-0.10.7.nojsmin/debian/tests/control
--- ola-0.10.7.nojsmin/debian/tests/control 2018-09-07 11:27:03.0 
-0700
+++ ola-0.10.7.nojsmin/debian/tests/control 2018-11-13 23:27:32.0 
-0800
@@ -10,6 +10,6 @@
 Test-Command: pkg-config --cflags --libs libola
 Depends: libola-dev, pkg-config
 
-Test-Command: set -e; g++ -o linktest $(pkg-config --cflags --libs libola) 
debian/tests/hw.cc; ./linktest
+Test-Command: set -e; g++ -o linktest debian/tests/hw.cc $(pkg-config --cflags 
--libs libola); ./linktest
 Depends: libola-dev, g++, pkg-config
 Restrictions: rw-build-tree

Bug#913652: xsane: Cannot build from source, ERROR: SANE-1.0.0 or newer is needed.

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

severity 913652 normal
thanks


Hello Johann,

thank you for spending your time helping to make Debian better with
this bug report. 


Am Dienstag, den 13.11.2018, 15:54 +0100 schrieb Johann Suhter:
> Package: xsane
> Version: 0.999-5
> Severity: serious
> Justification: fails to build from source (but built successfully in
> the past)
> 
> Dear Maintainer,
> 
> this bug report is closely related to #852840.
> 
> I downloaded the source of xsane:
> 
> apt-get source xsane
> mk-build-deps xsane
> sudo dpkg -i xsane-build-deps_0.999-5_all.deb
> sudo aptitude => fix the broken xsane-build-deps package by 
>  installing all dependencies
> 
> Then I tried to compile it on my machine:
> 
> cd xsane-0.999
> ./configure
> 
> The configure step failed with the following message:
> 
> checking for sane-config... no
> checking for SANE - version >= 1.0.0... no
> *** The sane-config script installed by SANE could not be found
> *** If SANE was installed in PREFIX, make sure PREFIX/bin is in
> *** your path, or set the SANE_CONFIG environment variable to the
> *** full path to sane-config.
> ...
> ERROR: SANE-1.0.0 or newer is needed for compiling xsane
>  - if you installed SANE as rpm make sure you also included
>sane-devel
> 
> The underlying problem is already fixed in #852840 by patching
> configure.in,
> and I can work around the problem by executing
> 
> autoreconf -f -i
> 
> before running 
> 
> ./configure
> 
> As I understand debian source packages, the autoreconf thing should
> not be
> necessary for building a package.
> 
This is right only if you use the Debian build systems sbuild[1] or
pbuilder[2]. Both start autoreconf automatically.

If you want to build the package manually, all required commands must
also be executed manually.  



> The error still exists in V 0.999-6.
> 
> Thank you, Johann
> [..]


CU
Jörg

[1] https://wiki.debian.org/sbuild
[2] https://wiki.debian.org/PbuilderTricks



- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlvrz14ACgkQCfifPIyh
0l1+eA//QmEAMjtvNXSxNtoI/2q7tikH8sy8+7yrwvgcbLEw4gCM/IpS3Yh0GAw/
EY4UEdVCE1LfzHxe1+WcgYU1GrxrBH7xL3lt6zgjGvyj2Bs94oeIxIrijGSfWAJx
tqGivBTyU82zbthzzI0Fk1NY/rceCtBbqkQwzkN9e5HWCs6Dh54AFcOXokjuDIo0
LD9k+iFcn+SOC4y9SOOImWNBgI5hXf/dx8L3r2awt82RSeg0oDIKKA+aTWFuqgSv
QxG/L8mBYAX8HsDxLt5votRWl/ZW5tDS//JR4FE8qQNU1tCCXVmgSPiJ/lCVdo8x
FnB/OwtqM6rBAmGLcwPOslcrnntVrscpqF5SIO4DGnNmJ6hFeNvxaDE2fitXuhy3
Wd9tzP3BAQ8FSs+tZUJgwqozRuz8v60K6DskFYVnzwFK7YjkwXVprdYYQIklDFgg
hSrJy9YR+OJiZlLsw54IrzpjZCDLGgdfXwQ6ZwN5BCMJkkxH3P2LcsnsM7mJJ7G9
jC3nQZLRm2eYkvMx5xdL0ToUpA3QgjZxXq/F/AVFZgDRpdkNuYEc/MuDEn6YP5ZT
43RJ9PyFUtoH41rlBo1ZZJRznBF9JYtoYk31RFUBRBy4qetf51ExczDCeK33Uq+h
g6G/brwGu6gpnJjbTrjTUNP8ASGFFg6iKTIj8bg4NySbc1qJ1Gc=
=RKXg
-END PGP SIGNATURE-

Bug#913703: ola: protobuf build-dep requires tighter python-protobuf runtime dep

[Steve Langasek]

Package: ola
Version: 0.10.7.nojsmin-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear maintainers,

In Ubuntu, we found that reverse-dependencies of python-protobuf were
failing their autopkgtests after the update to protobuf 3.6.1.  The reason
for this is that building against a particular version of protobuf results
in a runtime dependency on a matching version of python-protobuf, but this
is not expressed in the Depends: field, which only declares an unversioned
dependency on python-protobuf:

autopkgtest [22:25:39]: test command2: [---
Traceback (most recent call last):
  File "/usr/bin/rdm_responder_test.py", line 19, in 
from ola.testing.rdm import TestDefinitions, TestRunner
  File "/usr/lib/python2.7/dist-packages/ola/testing/rdm/TestDefinitions.py", 
line 21, in 
from ExpectedResults import (AckGetResult, BroadcastResult, NackGetResult,
  File "/usr/lib/python2.7/dist-packages/ola/testing/rdm/ExpectedResults.py", 
line 33, in 
from ola.OlaClient import OlaClient
  File "/usr/lib/python2.7/dist-packages/ola/OlaClient.py", line 21, in 
from ola.rpc.StreamRpcChannel import StreamRpcChannel
  File "/usr/lib/python2.7/dist-packages/ola/rpc/StreamRpcChannel.py", line 21, 
in 
from ola.rpc import Rpc_pb2
  File "/usr/lib/python2.7/dist-packages/ola/rpc/Rpc_pb2.py", line 23, in 


serialized_pb=_b('\n\tRpc.proto\x12\x07ola.rpc\"S\n\nRpcMessage\x12\x1b\n\x04type\x18\x01
 \x02(\x0e\x32\r.ola.rpc.Type\x12\n\n\x02id\x18\x02 
\x01(\r\x12\x0c\n\x04name\x18\x03 \x01(\t\x12\x0e\n\x06\x62uffer\x18\x04 
\x01(\x0c*\xd2\x01\n\x04Type\x12\x0b\n\x07REQUEST\x10\x01\x12\x0c\n\x08RESPONSE\x10\x02\x12\x13\n\x0fRESPONSE_CANCEL\x10\x03\x12\x13\n\x0fRESPONSE_FAILED\x10\x04\x12\x1c\n\x18RESPONSE_NOT_IMPLEMENTED\x10\x05\x12\x0e\n\nDISCONNECT\x10\x06\x12\x16\n\x12\x44\x45SCRIPTOR_REQUEST\x10\x07\x12\x17\n\x13\x44\x45SCRIPTOR_RESPONSE\x10\x08\x12\x12\n\x0eREQUEST_CANCEL\x10\t\x12\x12\n\x0eSTREAM_REQUEST\x10\n')
TypeError: __new__() got an unexpected keyword argument 'serialized_options'
autopkgtest [22:25:40]: test command2: ---]
autopkgtest [22:25:41]: test command2:  - - - - - - - - - - results - - - - - - 
- - - -
command2 FAIL non-zero exit status 1

(http://autopkgtest.ubuntu.com/packages/o/ola/disco/ppc64el)

This is a real bug in the runtime dependencies that is being detected via
the autopkgtest.  I don't know why this failure never showed up in the
autopkgtest results in Deian.

I've uploaded the attached patch to ola to Ubuntu, to force a matching
versioned dependency and build-dependency; however, it might be better to
work with the protobuf maintainers to find a more complete solution for the
runtime breakage.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ola-0.10.7.nojsmin/debian/control ola-0.10.7.nojsmin/debian/control
--- ola-0.10.7.nojsmin/debian/control   2018-09-07 06:18:11.0 -0700
+++ ola-0.10.7.nojsmin/debian/control   2018-11-13 23:12:51.0 -0800
@@ -2,7 +2,7 @@
 Priority: optional
 Maintainer: Wouter Verhelst 
 Uploaders: RenZO 
-Build-Depends: debhelper (>= 9), autotools-dev, dh-autoreconf, 
bash-completion, libcppunit-dev, bison, flex, pkg-config, uuid-dev, python, 
python-protobuf, libprotobuf-dev, protobuf-compiler, libprotoc-dev, 
libusb-1.0-0-dev, libftdi1-dev, liblo-dev, libmicrohttpd-dev (>= 
0.9.44+dfsg-1), libncurses5-dev, libavahi-client-dev, python-numpy
+Build-Depends: debhelper (>= 9), autotools-dev, dh-autoreconf, 
bash-completion, libcppunit-dev, bison, flex, pkg-config, uuid-dev, python, 
python-protobuf (>= 3.6.1~), libprotobuf-dev, protobuf-compiler, libprotoc-dev, 
libusb-1.0-0-dev, libftdi1-dev, liblo-dev, libmicrohttpd-dev (>= 
0.9.44+dfsg-1), libncurses5-dev, libavahi-client-dev, python-numpy
 Standards-Version: 3.9.8
 Section: libs
 Vcs-Git: https://salsa.debian.org/wouter/ola
@@ -28,7 +28,7 @@
 Package: ola-python
 Section: libs
 Architecture: all
-Depends: ola (>= ${source:Version}), ola (<< ${source:Version}.~), 
${python:Depends}, ${misc:Depends}, python-protobuf
+Depends: ola (>= ${source:Version}), ola (<< ${source:Version}.~), 
${python:Depends}, ${misc:Depends}, python-protobuf (>= 3.6.1~)
 Description: Open Lighting Architecture - Python Classes
  The DMX512 standard for Digital MultipleX is used for digital
  communication networks commonly used to control stage lighting and

Bug#913702: libwpd: CVE-2018-19208

[Salvatore Bonaccorso]

Source: libwpd
Version: 0.10.2-2
Severity: important
Tags: upstream security

Hi,

The following vulnerability was published for libwpd.

CVE-2018-19208[0]:
| In libwpd 0.10.2, there is a NULL pointer dereference in the function
| WP6ContentListener::defineTable in WP6ContentListener.cpp that will
| lead to a denial of service attack. This is related to WPXTable.h.

I do not know if it was reported to upstream or only in Red Hat bugzilla.

==25333== Memcheck, a memory error detector
==25333== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==25333== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==25333== Command: wpd2html ./poc0-1
==25333==
==25333== Invalid read of size 8
==25333==at 0x488C37A: operator[] (WPXTable.h:89)
==25333==by 0x488C37A: WP6ContentListener::defineTable(unsigned char, 
unsigned short) (WP6ContentListener.cpp:1314)
==25333==by 0x4893899: 
WP6Parser::parseDocument(librevenge::RVNGInputStream*, WPXEncryption*, 
WP6Listener*) (WP6Parser.cpp:149)
==25333==by 0x488D8DA: 
WP6ContentListener::_handleSubDocument(WPXSubDocument const*, 
WPXSubDocumentType, WPXTableList, unsigned int) (WP6ContentListener.cpp:1783)
==25333==by 0x489B90E: WPXContentListener::handleSubDocument(WPXSubDocument 
const*, WPXSubDocumentType, WPXTableList, unsigned int) 
(WPXContentListener.cpp:1226)
==25333==by 0x489C122: WPXContentListener::_openPageSpan() 
(WPXContentListener.cpp:415)
==25333==by 0x489C854: WPXContentListener::_openSection() 
(WPXContentListener.cpp:198)
==25333==by 0x488EF15: WP6ContentListener::_handleListChange(unsigned 
short) (WP6ContentListener.cpp:1888)
==25333==by 0x489CFC1: WPXContentListener::_openSpan() 
(WPXContentListener.cpp:797)
==25333==by 0x488B903: WP6ContentListener::insertCharacter(unsigned int) 
(WP6ContentListener.cpp:423)
==25333==by 0x48938BF: 
WP6Parser::parseDocument(librevenge::RVNGInputStream*, WPXEncryption*, 
WP6Listener*) (WP6Parser.cpp:138)
==25333==by 0x4893922: WP6Parser::parse(librevenge::RVNGInputStream*, 
WPXEncryption*, WP6Listener*) (WP6Parser.cpp:83)
==25333==by 0x4893D58: WP6Parser::parse(librevenge::RVNGTextInterface*) 
(WP6Parser.cpp:225)
==25333==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==25333==
==25333==
==25333== Process terminating with default action of signal 11 (SIGSEGV)
==25333==  Access not within mapped region at address 0x0
==25333==at 0x488C37A: operator[] (WPXTable.h:89)
==25333==by 0x488C37A: WP6ContentListener::defineTable(unsigned char, 
unsigned short) (WP6ContentListener.cpp:1314)
==25333==by 0x4893899: 
WP6Parser::parseDocument(librevenge::RVNGInputStream*, WPXEncryption*, 
WP6Listener*) (WP6Parser.cpp:149)
==25333==by 0x488D8DA: 
WP6ContentListener::_handleSubDocument(WPXSubDocument const*, 
WPXSubDocumentType, WPXTableList, unsigned int) (WP6ContentListener.cpp:1783)
==25333==by 0x489B90E: WPXContentListener::handleSubDocument(WPXSubDocument 
const*, WPXSubDocumentType, WPXTableList, unsigned int) 
(WPXContentListener.cpp:1226)
==25333==by 0x489C122: WPXContentListener::_openPageSpan() 
(WPXContentListener.cpp:415)
==25333==by 0x489C854: WPXContentListener::_openSection() 
(WPXContentListener.cpp:198)
==25333==by 0x488EF15: WP6ContentListener::_handleListChange(unsigned 
short) (WP6ContentListener.cpp:1888)
==25333==by 0x489CFC1: WPXContentListener::_openSpan() 
(WPXContentListener.cpp:797)
==25333==by 0x488B903: WP6ContentListener::insertCharacter(unsigned int) 
(WP6ContentListener.cpp:423)
==25333==by 0x48938BF: 
WP6Parser::parseDocument(librevenge::RVNGInputStream*, WPXEncryption*, 
WP6Listener*) (WP6Parser.cpp:138)
==25333==by 0x4893922: WP6Parser::parse(librevenge::RVNGInputStream*, 
WPXEncryption*, WP6Listener*) (WP6Parser.cpp:83)
==25333==by 0x4893D58: WP6Parser::parse(librevenge::RVNGTextInterface*) 
(WP6Parser.cpp:225)
==25333==  If you believe this happened as a result of a stack
==25333==  overflow in your program's main thread (unlikely but
==25333==  possible), you can try to increase the size of the
==25333==  main thread stack using the --main-stacksize= flag.
==25333==  The main thread stack size used in this run was 8388608.
==25333==
==25333== HEAP SUMMARY:
==25333== in use at exit: 39,843 bytes in 1,012 blocks
==25333==   total heap usage: 9,446 allocs, 8,434 frees, 879,851 bytes allocated
==25333==
==25333== LEAK SUMMARY:
==25333==definitely lost: 40 bytes in 1 blocks
==25333==indirectly lost: 16 bytes in 1 blocks
==25333==  possibly lost: 0 bytes in 0 blocks
==25333==still reachable: 39,787 bytes in 1,010 blocks
==25333== suppressed: 0 bytes in 0 blocks
==25333== Rerun with --leak-check=full to see details of leaked memory
==25333==
==25333== For counts of detected and suppressed errors, rerun with: -v
==25333== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

If you fix the vulnerability please al

Bug#913118: libspread-sheet-widget package required for pspp

[Friedrich Beckmann]

Hi folks,

the pspp package 0.10.1 has been removed from debian today due to a build 
failure in the regression:

https://tracker.debian.org/pkg/pspp

The new pspp 1.2.0 release is already waiting in mentors

https://mentors.debian.net/package/pspp

but that release needs the libspread-sheet-widget which is a new package 
waiting since 8 days:

https://ftp-master.debian.org/new/spread-sheet-widget_0.3-1.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913118

If there is anything missing - please let me know.

Friedrich

Bug#913700: RM: jailer -- RoQA; RC-buggy, no maintainer upload since 2011, uses internal dpkg database layout

[Niels Thykier]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Javier Fernandez-Sanguino Pen~a 

Hi,

I believe jailer is ripe for removal from unstable as:

 * It has RC bugs with a trivial patch since 2016 (#831939).
 * No maintainer uploads since 2011.
 * It relies on the internal structure of the dpkg database (#913694),
   which may stall progress in dpkg if not resolved.

Thanks,
~Niels

Bug#913701: src:knot: we should package python3-libknot

[Daniel Kahn Gillmor]

Package: src:knot
Severity: wishlist
Version: 2.7.4-1
Control: tags -1 upstream
Control: forwarded -1 https://gitlab.labs.nic.cz/knot/knot-dns/issues/622
X-Debbugs-Cc: daniel.salz...@nic.cz

It would be great to package up the python libknot package for use in
debian.

The source for the package is already in the knot packaging, but it's
missing setup.py and any automated tooling to create the PKG-INFO or
.egg-info files found in the tarballs at
http://pypi.python.org/pypi/libknot , which would be needed to make
dh_python3 happy.

upstream likes this idea (see id:cfe5149776cdb18f9c64e3c353c49...@nic.cz
on knot-dns-us...@lists.nic.cz
(https://lists.nic.cz/pipermail/knot-dns-users/2018-October/001514.html),
but i think this would be even more useful if this stuff was prepped
adequately upstream (see the upstream bug report i've opened, linked
above).

I suspect the attached patch, which aims to generate setup.py from the
correct version number is a good start, but then it should probably also
generate the additional files (PKG-INFO, libknot.egg-info/*, etc) as
well (maybe upstream could even automate the uploads to pypi during
release time).  I think that once setup.py exists, the other stuff can
be generated with something like:

python3 setup.py egg_info

but i don't know the preferred workflow or how you'd want to integrate
it into the existing build/release process upstream.

I'm cc'ing the upstream maintainer here, hopefully he'll have some good
ideas.

--dkg

From 9fb2b324269af6eb1fe66e4f135611776d39b10c Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Fri, 2 Nov 2018 11:26:09 -0400
Subject: [PATCH] python: auto-generate versioned python module setup.py

---
 configure.ac   |  3 ++-
 python/Makefile.am |  1 +
 python/setup.py.in | 32 
 3 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 python/setup.py.in

diff --git a/configure.ac b/configure.ac
index 86092089f..ef7e571b4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -31,7 +31,8 @@ AC_SUBST([KNOT_VERSION_PATCH], knot_VERSION_PATCH)
 
 AC_CONFIG_FILES([src/libknot/version.h
  src/libdnssec/version.h
- src/libzscanner/version.h])
+ src/libzscanner/version.h
+ python/setup.py])
 
 # Automatically update release date based on NEWS
 AC_PROG_SED
diff --git a/python/Makefile.am b/python/Makefile.am
index 2c03a5bb7..eef878d71 100644
--- a/python/Makefile.am
+++ b/python/Makefile.am
@@ -1,5 +1,6 @@
 EXTRA_DIST =			\
 	libknot/__init__.py	\
 	libknot/control.py	\
+	setup.py		\
 	stats_http.py		\
 	stats_influxdb.py
diff --git a/python/setup.py.in b/python/setup.py.in
new file mode 100644
index 0..d005e2975
--- /dev/null
+++ b/python/setup.py.in
@@ -0,0 +1,32 @@
+"""
+libknot setup module.
+"""
+
+from setuptools import setup, find_packages
+
+setup(
+name='libknot',
+version='@PACKAGE_VERSION@',
+description='Python bindings for libknot',
+url='https://github.com/CZ-NIC/knot',
+author='Andre Keller',
+author_email='andre.kel...@vshn.ch',
+license='GPL-3.0',
+
+# See https://pypi.python.org/pypi?%3Aaction=list_classifiers
+classifiers=[
+'Development Status :: 3 - Alpha',
+'Intended Audience :: Developers',
+'Topic :: Software Development :: Build Tools',
+'License :: OSI Approved :: BSD License',
+'Programming Language :: Python :: 3',
+'Programming Language :: Python :: 3.4',
+'Programming Language :: Python :: 3.5',
+'Programming Language :: Python :: 3.6',
+'Programming Language :: Python :: 3.7',
+],
+
+packages=[
+'libknot',
+]
+)
-- 
2.19.1



signature.asc
Description: PGP signature

Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs

[Marcus Furlong]

> > Passing the contents does the correct thing in all other cases, so not
> > sure why it would be having an issue with this?
>
> Ahah!
>
> TagFile only accepts filehandles, not static data:
>
> https://salsa.debian.org/apt-team/python-apt/blob/master/python/tag.cc#L750
>
> In deb822.py there is a function _is_real_file() and that is used so that
> python-apt's TagFile is only invoked on filehandles and not on text data,
> diverting to the in-built parser when TagFile cannot be used.

So in my case, the in-built parser is being used and it is stricter
than python-apt's parser?

> BTW if you are read()ing so that you can deal with the compressed Pacakges.gz,
> TagFile can handle on-the-fly decompression.
>
> In [1]: from debian.deb822 import Packages
>
> In [2]: with open('Packages.gz') as fh:
>...: for p in Packages.iter_paragraphs(fh):
>...: if 'version' not in p:
>...: print(p)
>
> (wild guess as to why you might be doing this!)

One reason I'm doing it is for decompression, but a second reason is
to provide feedback to the user via a progress bar. To do that, the
Packages is downloaded, decompressed, packages counted via regex, then
parsed.

I have tried to do this in a generic way, as the code also handles yum
and yast repos. These mostly follow the same logic; download package
list, decompress package list, count occurrences, parse.

   
https://github.com/furlongm/patchman/blob/master/patchman/repos/utils.py#L296-L334

Looking at the git blame, most of that code has been working fine for
6+ years. This is the first time I've ever come across a repo with
whitespace in that section.

> I've been thinking that in cases where iter_paragraphs was called with
> use_apt_pkg=True and then apt_pkg is not used contrary to what was requested,
> iter_paragraphs should generate a warning. That risks becoming noisy in a way
> that is not desirable, but also perhaps gets us away from this ambiguous
> behaviour where the use_apt_pkg setting has been ignored.
>
> I wonder what the likelihood is that introducing a warning would break someone
> else's code? (It would break an autopkgtest, for instance, by writing to
> stderr)

If other tools/libraries are more tolerant, including python-apt,
would it make sense for python-debian to be more tolerant when using
the in-built parser? In that case, the two parser implementations
would be more consistent.

--
Marcus Furlong

Bug#908678: Testing the filter-branch scripts

[Daniel Lange]

Am 13.11.18 um 23:09 schrieb Moritz Muehlenhoff:
> The current data structure works very well for us and splitting the files
> has many downsides.

Could you detail what those many downsides are besides the scripts that
need to be amended?

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277


Clearer output:

ii  alsa-oss 1.1.6-1  amd64ALSA wrapper 
for OSS applications
ii  alsa-utils   1.1.7-1  amd64Utilities 
for configuring and using ALSA
ii  alsaplayer-alsa  0.99.81-2amd64alsaplayer 
output module for ALSA
ii  alsaplayer-common0.99.81-2amd64audio player 
(common files)
ii  alsaplayer-gtk   0.99.81-2amd64alsaplayer 
gtk interface
ii  libasound2:amd64 1.1.7-1  amd64shared 
library for ALSA applications
ii  libasound2-data  1.1.7-1  all  
Configuration files and profiles for ALSA drivers
ii  libasound2-plugins:amd64 1.1.7-3  amd64ALSA library 
additional plugins
ii  libsox-fmt-alsa:amd6414.4.2-3 amd64SoX alsa 
format I/O library
ii  python-alsaaudio 0.8.4-1  amd64Alsa 
bindings for Python
ii  volumeicon-alsa  0.5.1+git20170117-1  amd64systray 
volume icon for alsa

Bug#913582: [pkg-gnupg-maint] Bug#913582: gpg-zip: wrong default TAR path if built on a merged-/usr system and used on an unmerged-/usr system

[Daniel Kahn Gillmor]

Control: tags 913582 + confirmed upstream
Control: forwarded 913582 https://dev.gnupg.org/T4251

Thanks for catching this, Simon!

On Mon 2018-11-12 16:48:29 +, Simon McVittie wrote:
> * Have two systems/chroots/containers, one with merged /usr (/bin is a
>   symlink to /usr/bin) and one without
> * Build gnupg2 on the first system
> * Install it on the second system and use gpg-zip
>
> Expected result:
>
> * gpg-zip invokes /bin/tar (or just tar as found in PATH) and succeeds
>
> Actual result:
>
> * gpg-zip invokes /usr/bin/tar and fails

I've reported this upstream, as noted above.  I'd like to avoid adding a
workaround to the package configuration and build if possible, and just
get it fixed at the source.

--dkg


signature.asc
Description: PGP signature

Bug#913628: dnssec-trigger: segfault after updating package libnm-glib4

[Daniel Dupont]

On Tue, 13/11/2018 at 11:50 -0800, Diane Trout wrote:

When you get a chance could you try the second python program as well?

I had a hunch the first one would fail, if the second one works that
suggests a possible solution.

Diane


--- nmtest.py 
#!/usr/bin/python

import gi
gi.require_version('NM', '1.0')
from gi.repository import NM

client = NM.Client().new()
print('Manager running? %s' % (client.get_nm_running(),))
-- end 


I do not have time to try both ideas today. I'll see that tomorrow.

In the meantime, here is the output of your two programs:

dldt@emt-g1:~$ export LC_ALL=C
dldt@emt-g1:~$ ./nmclient_test.py

(process:2162): libnm-glib-WARNING **:
(libnm-glib/nm-object.c:179):constructor: code should not be reached
./nmclient_test.py:7: Warning: object NMClient 0x55af46e17100
finalized
while still in-construction
client = NMClient.Client().new()
./nmclient_test.py:7: Warning: Custom constructor for class NMClient
returned NULL (which is invalid). Please use GInitable instead.
client = NMClient.Client().new()
./nmclient_test.py:7: Warning: g_object_is_floating: assertion
'G_IS_OBJECT (object)' failed
client = NMClient.Client().new()
Segmentation fault


  vvv

dldt@emt-g1:~$ ./nmtest.py
Traceback (most recent call last):
File "./nmtest.py", line 7, in 
  client = NM.Client().new()
GLib.Error: g-io-error-quark: Could not connect: No such file or
directory (1)


--
Daniel Dupont

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277



dpkg -l | egrep "(alsa|libasound)"

ii  alsa-oss  1.1.6-1   
  amd64ALSA wrapper for OSS applications
ii  alsa-utils1.1.7-1   
  amd64Utilities for configuring and using ALSA
ii  alsaplayer-alsa   0.99.81-2 
  amd64alsaplayer output module for ALSA
ii  alsaplayer-common 0.99.81-2 
  amd64audio player (common files)
ii  alsaplayer-gtk0.99.81-2 
  amd64alsaplayer gtk interface
ii  libasound2:amd64  1.1.7-1   
  amd64shared library for ALSA applications
ii  libasound2-data   1.1.7-1   
  all  Configuration files and profiles for ALSA drivers
ii  libasound2-plugins:amd64  1.1.7-3   
  amd64ALSA library additional plugins
ii  libsox-fmt-alsa:amd64 14.4.2-3  
  amd64SoX alsa format I/O library
ii  python-alsaaudio  0.8.4-1   
  amd64Alsa bindings for Python
ii  volumeicon-alsa   0.5.1+git20170117-1   
  amd64systray volume icon for alsa

Bug#885388: kbibtex: build-depends on deprecated Frameworks -dev packages

[Pino Toscano]

Hi Bastien,

In data sabato 14 aprile 2018 10:39:56 CET, Pino Toscano ha scritto:
> In data martedì 26 dicembre 2017 18:05:49 CEST, Pino Toscano ha scritto:
> > Source: kbibtex
> > Version: 0.8~20170819git31a77b27e8e83836e-3
> > Severity: wishlist
> > Tags: patch
> > 
> > Dear Maintainer,
> > 
> > your package build-depends on deprecated Frameworks -dev packages,
> > which currently are transitional packages.
> > 
> > In particular, the replacements needed for this packages are:
> > - kdoctools-dev -> libkf5doctools-dev
> > - kio-dev -> libkf5kio-dev
> > 
> > Attached there is a patch for this.
> > 
> > The non-deprecated packages are already available in the current Debian
> > stable, i.e. Stretch.
> 
> Polite ping on this bug.

I saw you recently updated kbibtex to 0.8.1 (nice!), can you please fix
this bug as well? Can I help anyhow?

Thanks,
-- 
Pino Toscano

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

Bug#898571: build dependency cycle between icu and icu-le-hb

[Helmut Grohne]

Control: reopen -1
Control: found -1 icu/63.1-4

On Sun, May 13, 2018 at 07:52:14PM +0200, Helmut Grohne wrote:
> icu introduces a build dependency cycle with icu-le-hb. Doing so breaks
> architecture bootstrap. The full cycle is:
> 
> src:icu Build-Depends: libicu-le-hb-dev
> libicu-le-hb-dev is built from src:icu-le-hb
> src:icu-le-hb Build-Depends: libicu-dev
> libicu-dev is built from src:icu

This exact dependency cycle is present in icu/63.1-4.

> An alternative may be splitting icu-lx into separate binary packages
> libiculx60 and libicu-lx-dev. Then we could add a build profile
> pkg.icu.nolayoutex to skip generating these packages. Downstream users
> would have to add an explicit dependency on libicu-lx-dev to get that
> functionality.

I see that you added libiculx63, but there is no libicu-lx-dev. At this
point, we could make the build dependency from icu on libicu-le-hb-dev
optional. That would remove libiculx63, but it would also remove
libicu-dev. Therefore the cycle is still fully present. In order to
break it, the -dev package must be split as well. Whatever
src:icu-le-hb-dev build depends on (presently libicu-dev) must not
depend on libiculx63. That's why I originally proposed "libicu-lx-dev".

Helmut

Bug#871806: #871806: check git tag signatures

[Xavier]

Le 14/11/2018 à 00:31, Daniel Kahn Gillmor a écrit :
> On Tue 2018-11-13 21:53:12 +0100, Xavier wrote:
>> Note that if there is a "git origin" that points to upstream repo, uscan
>> will use it instead of creating a temporary "git clone". It is more
>> efficient I think
> 
> hm, too bad.  i use "upstream" as the name of my upstream git repos,
> since as often as not "origin" (where the thing was originally cloned
> from) is the debian packaging. :P Maybe i should change my practices
> there though if everyone else does it differently…

In this case, salsa only looks for url (without looking at the name), so
if one points to the same url as the one given in debian/watch, salsa
uses it

>> Thanks, I copied old uscan calls since the challenge was non-regression
>> after rewriting. Time to improve now!
> 
> happy to help!  it made me notice and report #913665 as well, if you're
> poking around in there :)  sorry i didn't have the time to write and
> test the fixes!
> 
>> Unfortunately no. Git signatures are not linked to the archive itself
>> but only to the tag. I don't see any way to link an extracted archive to
>> this sort of .asc
> 
> right, i'm thinking of some kind of hack similar to a pristine-tar delta
> file, but which could maybe contain enough of a shallow clone to let the
> signature verify.  i don't know whether that's possible though, i
> haven't actually thought through the data structures or git's hashing
> tree.
> 
> all the best,
> 
>  --dkg
> 

Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs

[Stuart Prescott]

Hi Marcus,

> I've narrowed down where the issue occurs. It happens when passing the
> contents rather than the file handle to iter_paragraphs:
> 
> ~# ipython3
> Python 3.5.3 (default, Jan 19 2017, 14:11:04)
> Type "copyright", "credits" or "license" for more information.
> 
> IPython 5.1.0 -- An enhanced Interactive Python.
> ? -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help  -> Python's own help system.
> object?   -> Details about 'object', use 'object??' for extra details.
> 
> In [1]: from debian.deb822 import Packages
> 
> In [2]: with open('Packages') as fh:
>   ...:for p in Packages.iter_paragraphs(fh.read()):
>   ...:if 'version' not in p:
>   ...:print(p)
>   ...:
> Homepage: https://code.visualstudio.com/
[...]
> Passing the contents does the correct thing in all other cases, so not
> sure why it would be having an issue with this?

Ahah!

TagFile only accepts filehandles, not static data:

https://salsa.debian.org/apt-team/python-apt/blob/master/python/tag.cc#L750

In deb822.py there is a function _is_real_file() and that is used so that 
python-apt's TagFile is only invoked on filehandles and not on text data, 
diverting to the in-built parser when TagFile cannot be used.

BTW if you are read()ing so that you can deal with the compressed Pacakges.gz, 
TagFile can handle on-the-fly decompression.

In [1]: from debian.deb822 import Packages

In [2]: with open('Packages.gz') as fh:
   ...: for p in Packages.iter_paragraphs(fh):
   ...: if 'version' not in p:
   ...: print(p)

(wild guess as to why you might be doing this!)

I've been thinking that in cases where iter_paragraphs was called with 
use_apt_pkg=True and then apt_pkg is not used contrary to what was requested, 
iter_paragraphs should generate a warning. That risks becoming noisy in a way 
that is not desirable, but also perhaps gets us away from this ambiguous 
behaviour where the use_apt_pkg setting has been ignored. 

I wonder what the likelihood is that introducing a warning would break someone 
else's code? (It would break an autopkgtest, for instance, by writing to 
stderr)

Cheers
Stuart

-- 
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#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Elimar Riesebieter]

* Awtul  [2018-11-13 21:49 -0500]:

> Package: moc
> Version: 1:2.6.0~svn-r2984-1
> Followup-For: Bug #913277
> 
> I don't have .asoundrc or any custom audio (or video) file.
> (I already mentionned that in my second message :) :P )
> 
What tells

$ dpkg -l | egrep "(alsa|libasound)"

?

Elimar
-- 
  Numeric stability is probably not all that
  important when you're guessing;-)


signature.asc
Description: PGP signature

Bug#913045: [Pkg-alsa-devel] Bug#913045: Bug#913045: Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Elimar Riesebieter]

* Pedro Silva  [2018-11-13 23:48 +]:

> On Tue, 13 Nov 2018 23:44:35 +0100 Elimar Riesebieter
>  wrote:
> 
> > Heureka!
> >
> > Could you please test also libasound2-plugins 1.1.7-3 which arrived
> 
> $ dpkg -l | grep libasound2 | awk {'print $2,$3'}
> libasound2:amd64 1.1.7-1
> libasound2:i386 1.1.7-1
> libasound2-data 1.1.7-1
> libasound2-dev:amd64 1.1.7-1
> libasound2-plugins:amd64 1.1.7-3
> libasound2-plugins:i386 1.1.7-3
> 
> If ~/.asoundrc doesn't exist, same error:
> 
> ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave
> 
> If previous ~/.asoundrc exists, everything works as expected.

Ok, so it seems to be udev's task to set the priority of soundcards.
I can't do more here so I am closing this bug hereby.

Thanks for cooperation
Elimar
-- 
  Experience is something you don't get until
  just after you need it!


signature.asc
Description: PGP signature

Bug#913699: keymapper depends on nonexistent package python-yapps2

[peter green]

Package: keymapper
Version: 0.5.3-11
Severity: serious

keymapper depends on python-yapps2 which does not appear to exist, did you mean 
to depend on python-yapps?

Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs

[Marcus Furlong]

Control: retitle -1 Incorrectly parsing whitespace in Deb822.iter_paragraphs
On Tue, 13 Nov 2018 at 23:42, Marcus Furlong  wrote:
>
> > > I have come across a case where whitespace is added in
> > > Packages{.gz,.bz2} and I am not sure how it should be parsed.
> > [...]
> > > Should this whitespace be parsed as a paragraph delimiter?
> >
> > For a Packages file, each paragraph is defined as a set of DEBIAN/control
> > paragraphs; the Description field is not allowed to contain lines that are
> > whitespace-only.
> >
> > https://wiki.debian.org/DebianRepository/Format#A.22Packages.22_Indices
> >
> > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-description
> >
> > So the strict answer is yes, it should be a paragraph delimiter but most
> > implementations seem to be more forgiving in what they accept.
> >
> > Note that for debian/control files in source packages, whitespace-only lines
> > are treated as paragraph separators so that whitespace errors in an editor
> > don't accidentally make packages disappear from the archive.
> >
> >
> > > Currently, the whitespace is being treated as a paragraph delimiter,
> > > in python-debian, but not by apt-get, etc.
> >
> > Could you expand on this with an example, perhaps?
> >
> > python-debian actually uses python-apt for dealing with Sources and Packages
>
> I was incorrect. As you have shown, python-apt works correctly.
>
> > files (i.e. the exact same code as apt) and already does treat 
> > whitespace-only
> > lines as being part of a paragraph rather than breaking them:
> >
> >
> > $ ipython3
> > Python 3.6.7 (default, Oct 21 2018, 08:08:16)
> > Type "copyright", "credits" or "license" for more information.
> >
> > In [1]: from debian.deb822 import Packages
> >
> > In [2]: with open('Packages') as fh:
> >   ...: for p in Packages.iter_paragraphs(fh):
> >   ...: if p['Version'] == '1.25.0-1529904044':
> >   ...: print(p)
>
> I've narrowed down where the issue occurs. It happens when passing the
> contents rather than the file handle to iter_paragraphs:
>
> ~# ipython3
> Python 3.5.3 (default, Jan 19 2017, 14:11:04)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 5.1.0 -- An enhanced Interactive Python.
> ? -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help  -> Python's own help system.
> object?   -> Details about 'object', use 'object??' for extra details.
>
> In [1]: from debian.deb822 import Packages
>
> In [2]: with open('Packages') as fh:
>   ...:for p in Packages.iter_paragraphs(fh.read()):
>   ...:if 'version' not in p:
>   ...:print(p)
>   ...:
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
> Homepage: https://code.visualstudio.com/
>
>
> In [3]:
>
> Passing the contents does the correct thing in all other cases, so not
> sure why it would be having an issue with this?
>
> --
> Marcus Furlong



--
Marcus Furlong

Bug#913274: Incorrectly parsing whitespace in Sources.iter_paragraphs

[Marcus Furlong]

> > I have come across a case where whitespace is added in
> > Packages{.gz,.bz2} and I am not sure how it should be parsed.
> [...]
> > Should this whitespace be parsed as a paragraph delimiter?
>
> For a Packages file, each paragraph is defined as a set of DEBIAN/control
> paragraphs; the Description field is not allowed to contain lines that are
> whitespace-only.
>
> https://wiki.debian.org/DebianRepository/Format#A.22Packages.22_Indices
>
> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-description
>
> So the strict answer is yes, it should be a paragraph delimiter but most
> implementations seem to be more forgiving in what they accept.
>
> Note that for debian/control files in source packages, whitespace-only lines
> are treated as paragraph separators so that whitespace errors in an editor
> don't accidentally make packages disappear from the archive.
>
>
> > Currently, the whitespace is being treated as a paragraph delimiter,
> > in python-debian, but not by apt-get, etc.
>
> Could you expand on this with an example, perhaps?
>
> python-debian actually uses python-apt for dealing with Sources and Packages

I was incorrect. As you have shown, python-apt works correctly.

> files (i.e. the exact same code as apt) and already does treat whitespace-only
> lines as being part of a paragraph rather than breaking them:
>
>
> $ ipython3
> Python 3.6.7 (default, Oct 21 2018, 08:08:16)
> Type "copyright", "credits" or "license" for more information.
>
> In [1]: from debian.deb822 import Packages
>
> In [2]: with open('Packages') as fh:
>   ...: for p in Packages.iter_paragraphs(fh):
>   ...: if p['Version'] == '1.25.0-1529904044':
>   ...: print(p)

I've narrowed down where the issue occurs. It happens when passing the
contents rather than the file handle to iter_paragraphs:

~# ipython3
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
Type "copyright", "credits" or "license" for more information.

IPython 5.1.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from debian.deb822 import Packages

In [2]: with open('Packages') as fh:
  ...:for p in Packages.iter_paragraphs(fh.read()):
  ...:if 'version' not in p:
  ...:print(p)
  ...:
Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/

Homepage: https://code.visualstudio.com/


In [3]:

Passing the contents does the correct thing in all other cases, so not
sure why it would be having an issue with this?

-- 
Marcus Furlong

Bug#913697: texlive-full: APT hangs at 'Pregenerating ConTeXt MarkIV format. This may take some time...'

[Norbert Preining]

close 913697
forcemerge 913636 913697
thanks

> Attempted to install texlive-full on a fresh Buster install. APT hangs at 
> 'Pregenerating ConTeXt MarkIV format. This may take some time...' for over 
> five hours.

Fixed with texlive-bin upload yesterday.
Thanks

Norbert

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

Bug#913572: [Pkg-rust-maintainers] Bug#913572: Shouldn't shipping broken symlinks be against policy?

[Ximin Luo]

G. Branden Robinson:
> [..]
> $ man rust-gdb
> /usr/bin/man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink
> No manual entry for rust-gdb
> See 'man 7 undocumented' for help when manual pages are not available.
> 
>> The man page is available in the rust-doc package which is already in
>> Suggests.
> 
> In that case, isn't a better fix to put the symlink in that package,
> too?
> 

Sorry, I made a typo. I meant that the man page (the target of the symlink) is 
in the gdb-doc package, which is already in the Suggests: of rust-gdb (the 
offending package containing the potentially-broken symlink).

The subsequent side replies to this thread (that I didn't directly respond to) 
were commenting on an incorrect situation, sorry to have wasted people's time.

In order to fix the bug I would have to either

a) rust-gdb Depends: gdb-doc, or
b) split rust-gdb into rust-gdb vs rust-gdb-doc where the latter Depends: 
gdb-doc and provides only 1 symlink

Both are IMO worse options than leaving the current situation as-is.

X



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

Bug#913698: /usr/bin/ffprobe: Do not display version / build headers to stderr for ffprobe and others

[Witold Baryluk]

Package: ffmpeg
Version: 7:4.0.3-1
Severity: wishlist
File: /usr/bin/ffprobe

Hi.


user@debian:~$ ffprobe output_x264_medium_crf22.mp4 >stdout.txt 2>stderr.txt
user@debian:~$ cat stdout.txt
user@debian:~$ cat stderr.txt
ffprobe version 4.0.3-1 Copyright (c) 2007-2018 the FFmpeg developers
  built with gcc 8 (Debian 8.2.0-9)
  configuration: --prefix=/usr --extra-version=1 --toolchain=hardened
  --libdir=/usr/lib/x86_64-linux-gnu
  --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl
  --disable-stripping --enable-avresample --disable-filter=resample
  --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom
  --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
  --enable-libcdio --enable-libcodec2 --enable-libflite
  --enable-libfontconfig --enable-libfreetype --enable-libfribidi
  --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame
  --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt
  --enable-libopus --enable-libpulse --enable-librsvg
  --enable-librubberband --enable-libshine --enable-libsnappy
  --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora
  --enable-libtwolame --enable-libvidstab --enable-libvorbis
  --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265
  --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi
  --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2
  --enable-libdc1394 --enable-libdrm --enable-libiec61883
  --enable-chromaprint --enable-frei0r --enable-libopencv
  --enable-libx264 --enable-shared
  libavutil  56. 14.100 / 56. 14.100
  libavcodec 58. 18.100 / 58. 18.100
  libavformat58. 12.100 / 58. 12.100
  libavdevice58.  3.100 / 58.  3.100
  libavfilter 7. 16.100 /  7. 16.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale  5.  1.100 /  5.  1.100
  libswresample   3.  1.100 /  3.  1.100
  libpostproc55.  1.100 / 55.  1.100
Input #0, matroska,webm, from 'output_x264_medium_crf22.mp4':
  Metadata:
title   : Big Buck Bunny, Sunflower version
GENRE   : Animation
MAJOR_BRAND : isom
MINOR_VERSION   : 1
COMPATIBLE_BRANDS: isomavc1
COMPOSER: Sacha Goedegebure
ARTIST  : Blender Foundation 2008, Janus Bager Kristensen 2013
COMMENT : Creative Commons Attribution 3.0 - 
http://bbb3d.renderfarming.net
ENCODER : Lavf58.12.100
  Duration: 00:10:34.60, start: 0.00, bitrate: 11521 kb/s
Stream #0:0: Video: h264 (High), yuv420p(progressive), 3840x2160 [SAR 1:1 
DAR 16:9], 30 fps, 30 tbr, 1k tbn, 60 tbc (default)
Metadata:
  HANDLER_NAME: GPAC ISO Video Handler
  ENCODER : Lavc58.18.100 libx264
  DURATION: 00:10:34.6
Stream #0:1: Audio: ac3, 48000 Hz, 5.1(side), fltp, 320 kb/s (default)
Metadata:
  HANDLER_NAME: GPAC ISO Audio Handler
  DURATION: 00:10:34.14400
user@debian:~$ 


I find it very distracting to have half of the screen consumed by version
of ffmpeg, build options and libraries options.

There is no need for any (ANY, not even the first line) of these by default, 
because there are:

ffprobe -version

that shows the same information  (on stdout).

And more comprehensive / machine parsable commands:

ffprobe -show_program_version
ffprobe -show_library_versions
ffprobe -show_versions  (both two above combined)


Having option that restores some build info to be printed and continues
execution could be useful for some tho. But it should not be enabled by
default, and should output all these build info details to stdout.

Best regards,
Witold Baryluk


PS. Notice that the ffprobe output data to stderr, instead to stdout,
which is also weird, and other bug.

-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/32 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ffmpeg depends on:
ii  libavcodec587:4.0.3-1
ii  libavdevice58   7:4.0.3-1
ii  libavfilter77:4.0.3-1
ii  libavformat58   7:4.0.3-1
ii  libavresample4  7:4.0.3-1
ii  libavutil56 7:4.0.3-1
ii  libc6   2.27-8
ii  libpostproc55   7:4.0.3-1
ii  libsdl2-2.0-0   2.0.8+dfsg1-6
ii  libswresample3  7:4.0.3-1
ii  libswscale5 7:4.0.3-1

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

Bug#913697: texlive-full: APT hangs at 'Pregenerating ConTeXt MarkIV format. This may take some time...'

[Foo Bar]

Package: texlive-full
Version: 2018.20181106-1
Severity: important

Dear Maintainer,

Attempted to install texlive-full on a fresh Buster install. APT hangs at 
'Pregenerating ConTeXt MarkIV format. This may take some time...' for over five 
hours.

Killed the process (SIGTERM) and ran 'sudo dpkg --configure -a'. APT again 
hangs at same line.

Ran 'sudo dpkg -r texlive-full' then 'sudo apt install texlive-full'.  APT 
again hangs at same line.

Attempted to install without context and context-modules dependencies ('sudo 
dpkg -i --ignore-depends=context,context-modules 
texlive-full_2018.20181106-1_all.deb'); however, 'dependency problems prevent 
configuration of texlive-full'.

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

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

Versions of packages texlive-full depends on:
ii  asymptote  2.47-1
iu  biber  2.11-2
ii  chktex 1.7.6-2+b1
ii  cm-super   0.3.4-13
ih  context2018.04.04.20180416-1
ii  dvidvi 1.0-8.2+b1
ii  dvipng 1.15-1
iu  feynmf 1.08-10
iu  fragmaster 1.7-6
ii  info   6.5.0.dfsg.1-4+b1
ii  lacheck1.26-17
iu  latex-cjk-all  4.8.4+git20170127-2
ii  latexdiff  1.2.1-1
iu  latexmk1:4.61-0.1
ii  lcdf-typetools 2.106~dfsg-1
ii  lmodern2.004.5-5
iu  prerex 6.5.4-1
ii  psutils1.17.dfsg-4
iu  purifyeps  1.1-2
ii  t1utils1.41-2
ii  tex-gyre   20180621-2
iu  texinfo6.5.0.dfsg.1-4+b1
ii  texlive-base   2018.20181106-1
iu  texlive-bibtex-extra   2018.20181009-1
ii  texlive-binaries   2018.20181104.49075-1
ii  texlive-extra-utils2018.20181009-1
ii  texlive-font-utils 2018.20181009-1
ii  texlive-fonts-extra2018.20181009-1
ii  texlive-fonts-extra-doc2018.20181009-1
ii  texlive-fonts-extra-links  2018.20181009-1
ii  texlive-fonts-recommended  2018.20181106-1
ii  texlive-fonts-recommended-doc  2018.20181106-1
iu  texlive-formats-extra  2018.20181009-1
iu  texlive-games  2018.20181009-1
ii  texlive-humanities 2018.20181009-1
ii  texlive-humanities-doc 2018.20181009-1
ii  texlive-lang-arabic2018.20181106-1
iu  texlive-lang-chinese   2018.20181106-1
ii  texlive-lang-cjk   2018.20181106-1
iu  texlive-lang-cyrillic  2018.20181106-1
iu  texlive-lang-czechslovak   2018.20181106-1
ii  texlive-lang-english   2018.20181106-1
ii  texlive-lang-european  2018.20181106-1
ii  texlive-lang-french2018.20181106-1
ii  texlive-lang-german2018.20181106-1
ii  texlive-lang-greek 2018.20181106-1
ii  texlive-lang-italian   2018.20181106-1
ii  texlive-lang-japanese  2018.20181106-1
ii  texlive-lang-korean2018.20181106-1
ii  texlive-lang-other 2018.20181106-1
iu  texlive-lang-polish2018.20181106-1
ii  texlive-lang-portuguese2018.20181106-1
ii  texlive-lang-spanish   2018.20181106-1
ii  texlive-latex-base 2018.20181106-1
ii  texlive-latex-base-doc 2018.20181106-1
ii  texlive-latex-extra2018.20181009-1
ii  texlive-latex-extra-doc2018.20181009-1
ii  texlive-latex-recommended  2018.20181106-1
ii  texlive-latex-recommended-doc  2018.20181106-1
ii  texlive-luatex 2018.20181106-1
ii  texlive-metapost   2018.20181106-1
ii  texlive-metapost-doc   2018.20181106-1
ii  texlive-music  2018.20181009-1
ii  texlive-pictures   2018.20181106-1
ii  texlive-pictures-doc   2018.20181106-1
ii  texlive-plain-generic  2018.20181009-1
ii  texlive-pstricks   2018.20181009-1
ii  texlive-pstricks-doc   2018.20181009-1
ii  texlive-publishers 2018.20181009-1
ii  texlive-publishers-doc 2018.20181009-1
ii  texlive-science2018.20181009-1
ii  texlive-science-doc2018.20181009-1
iu  texlive-xetex  2018.20181106-1
ii  tipa   2:1.3-20
iu  vprerex1:6.5.1-1

texlive-full recommends no packages.

Versions of packages texlive-full suggests:
pn  xindy  

Bug#913696: debdelta: Script accesses internal dpkg database

[Guillem Jover]

Source: debdelta
Source-Version: 0.62
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script («debdelta»), which directly accesses
the dpkg internal database, instead of using one of the public interfaces
provided by dpkg. The code in do_patch_, should be switched to use:

  «dpkg-query --showformat='${Conffiles}\n' --show»

to fetch the list of conffiles. Then _symlink_data_tree should be switched
to always use dpkg_L, and dpkg_L_faster should be removed. Finally the
code handling 'old-control-tree' should be switched to use something like:

  «dpkg-query --control-list»


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Harlan Lieberman-Berg]

Hello Jeremy, release team,

Yes, the minimal set of involved source packages is python-acme,
python-certbot, python-certbot-nginx, and python-certbot-apache.  This
would also require the new package python-josepy, which is also
maintained by the LE team.

They should be able to be taken directly out of backports without
breaking anything.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#913695: goplay: Program accesses internal dpkg database

[Guillem Jover]

Source: goplay
Source-Version: 0.9.1+nmu1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a program («goplay»), which directly accesses
the dpkg internal database, instead of using one of the public interfaces
provided by dpkg. The code in src/goplay.cpp:StartPackage(), should be
switched to use «dpkg-query --listfiles» to fetch the package files list.

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913694: jailer: Script accesses internal dpkg database

[Guillem Jover]

Source: jailer
Source-Version: 0.4-17.1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script («jailer.pl»), which directly accesses
the dpkg internal database, instead of using one of the public interfaces
provided by dpkg. The code in get_files(), should be switched to use:

  «dpkg-query --listfiles»

to fetch the package files list. To avoid a performance hit, the code
should batch multiple packages on each call, taking into account
command-line length limits. Each package will get a paragraph separated
by a blank line (even if it is not installed).

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913693: jailtool: Script accesses internal dpkg database

[Guillem Jover]

Source: jailtool
Source-Version: 1.1-5
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script («update-jail»), which directly accesses
the dpkg internal database, instead of using one of the public interfaces
provided by dpkg. The code should be switched to use for conffiles:

  «dpkg-query --shoformat='${Conffiles}\n' --show»

and for the files list:

  «dpkg-query --listfiles»

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913277: "FATAL_ERROR: No valid sound driver! FATAL_ERROR: Server exited!"

[Awtul]

Package: moc
Version: 1:2.6.0~svn-r2984-1
Followup-For: Bug #913277

I don't have .asoundrc or any custom audio (or video) file.
(I already mentionned that in my second message :) :P )

Bug#913692: makejail: Script accesses internal dpkg database

[Guillem Jover]

Source: makejail
Source-Version: 0.0.5-10
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script [S], which directly accesses the dpkg
internal database. Instead of using one of the public interfaces
provided by dpkg. The function dpkgInfoFiles should be switched to
use «dpkg-query --listfiles» instead.

  [S] makejail

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913641: libreoffice-report-builder: report builder reports fail to run

[Anton Cohen]

On Tue, 13 Nov 2018 13:13:09 +0100 Lionel Elie Mamane 
wrote:
> Downgrading to 8u171-b11-2 makes this problem disappear.

Except 8u171-b11-2 (and all 8u171 builds) was removed from the pool for
stretch today.

> That's honestly not broken at all. That's why our packages have
dependencies, so that they can have what they require.

It is very broken that stretch doesn't have any working Java package in apt
repos (except in openjdk-11 in stretch-backports).

I realize this isn't a libreoffice package issue, but it seems like #911925
is being ignored.

Thanks,
Anton

-- 
This email and any attachments may contain information that is subject to 
copyright, that constitutes trade secrets, or that is proprietary, 
privileged, confidential or otherwise legally exempt from disclosure. If 
you are not the intended recipient, you are not authorized to read, print, 
retain, copy or disseminate any part of this email or any attachments. We 
do not waive any legal protections due to misdirection. If you have 
received this email in error, please notify the sender immediately and 
delete all copies. Any views expressed are those of the author and may not 
reflect those of the company. Emails are not perfectly secure and we do not 
warrant ours to be free of errors, viruses or other defects. By 
communicating with us by email, you accept these risks.

Bug#913691: dictionaries-common: Script accesses internal dpkg database

[Guillem Jover]

Source: dictionaries-common
Source-Version: 1.28.0
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script [S], which directly accesses the dpkg
internal database. Instead of using one of the public interfaces
provided by dpkg. The code should either be removed, as it seems it's
handling an ancient case, or updated to use «dpkg-query -W» to check
whether the package is installed (ex. by using the db:Status-Status
pseudo field).

  [S] scripts/system/dc-debconf-default-value.pl

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913690: starplot: helper script accesses internal dpkg database

[Guillem Jover]

Source: starplot
Source-Version: 0.95.5-8.3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a helper script [H], which directly accesses
the dpkg internal database. Instead of using one of the public
interfaces provided by dpkg. The code could probably be replaced
with a file trigger.

  [H] debian/starplot.sh

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

In addition the logic used in that script is not reliable, as those
files will get updated when some other package takes over some of its
files, or on a reinstall, etc.

Thanks,
Guillem

Bug#913689: packagesearch: Accesses internal dpkg database

[Guillem Jover]

Source: packagesearch
Source-Version: 2.7.10
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker
Control: block -1 by 913683

Hi!

This package wants to access the dpkg packages files lists, but it
does that by directly accessing the dpkg internal database. The
FilenamePlugin::getFileListFileName() function in
src/plugins/filenameplugin/filenameplugin.cpp should be switched to
use a new libapt interface, or barring that it should use
«dpkg-query --listfiles».

This is a problem for several reasons, because even though the layout
and format of the dpkg database is administrator friendly, and it is
expected that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913688: packagekit: Accesses internal dpkg database

[Guillem Jover]

Source: packagekit
Source-Version: 1.1.10-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker
Control: block -1 by 913683

Hi!

This package wants to access the dpkg packages files lists, but it
does that by directly accessing the dpkg internal database. At least
the backends/aptcc/apt-intf.cpp:AptIntf::searchPackageFiles(),
AptIntf::isApplication() and AptIntf::emitPackageFiles() functions
should be switched to use a new libapt interface, or barring that it
should use «dpkg-query --listfiles».

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913659: Document that not all bugs are policy violations

[Sean Whitton]

Hello Ian,

On Tue 13 Nov 2018 at 05:51PM GMT, Ian Jackson wrote:

> The discussion in #913572 is just another instance of the following
> antipattern:
>
>Submitter:   program X does strange thing Y which is undesirable
>Maintainer:  Y is not against policy
>
> I suggest adding something like this to s1.1, "Scope", as a new 3rd
> paragraph:
>
>   This manual cannot and does not prohibit every possible bug or
>   undesirable behaviour.  The fact that something is not forbidden by
>   Debian policy does not mean that it is not a bug, let alone that it
>   is desirable.  Questions not covered by policy should be evaluated
>   on their merits.

Good idea.

This seems strictly informative rather than normative, but I'd like to
see some reviews/seconds so that we can confirm that this is how the
wider project understands the role of the Policy Manual.

(If no seconds but also no objections are forthcoming, I'll just apply
it as an informative change.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#913687: RM: ruby-rbnacl -- ROM; no longer needed by ruby-net-ssh; no other rev-deps

[Unit 193]

Package: ftp.debian.org
Severity: normal

Howdy,

This package was required by ruby-net-ssh for Ed25519 support, that feature is 
now covered by ruby-ed25519 so this package is no longer useful.  This package 
is not used by anything else in Debian, and has a rapidly declining popcon 
count since its replacement.

I would thank you to remove this package from the archive.


~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#913686: libqapt: API accesses internal dpkg database

[Guillem Jover]

Source: libqapt
Source-Version: 3.0.4-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker
Control: block -1 by 913683

Hi!

This package provides an API to access the dpkg packages files lists,
but it does that by directly accessing the dpkg internal database.
The src/package.cpp:Package::installedFilesList function should be
switched to use a new libapt interface, or barring that it should
use «dpkg-query --listfiles».

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913685: synaptic: Accesses internal dpkg database

[Guillem Jover]

Source: synaptic
Source-Version: 0.84.5
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker
Control: block -1 by 913683

Hi!

This package wants to access the dpkg packages files lists, but it
does that by directly accessing the dpkg internal database. The
common/rpackage.c:RPackage::installedFiles() function should be
switched to use a new libapt interface, or barring that it should
use «dpkg-query --listfiles».

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#644356: [backuppc] In host summary, column sort doesn't work well

[Axel Beckert]

Control: tag -1 + confirmed
Control: found -1 3.1.0-9
Control: found -1 3.3.1-6
Control: found -1 3.3.2-1

Hi Adrien,

Adrien Grellier wrote in 2011:

> In the host summary, the columns « Full age » and « speed » aren't
> properly sorted when I clicked on the title of the column. For
> instance I got this for speed :
> 
> 9.42
> 8.79
> 7.20
> …
> 2.10
> 13.92
> 12.67
> 10.75
> 1.50
> 1.07
> 
> It seems that the 10.* aren't properly handeled.
> 
> I am using Debian stable, with backuppc 3.1.0-9.

Can you remember which web browser you did use? So far I only saw this
in Chromium, but it worked correctly in Firefox.

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

Bug#913684: python-apt: API accesses internal dpkg database

[Guillem Jover]

Source: python-apt
Source-Version: 1.7.0
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker
Control: block -1 by 913683

Hi!

This package provides an API to access the dpkg packages files lists,
but it does that by directly accessing the dpkg internal database.
The installed_files function should be switched to use a new libapt
interface, or barring that it should use «dpkg-query --listfiles».

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#913682: quilt: fails to document QUILT_PC environment variable

[Alan W. Irwin]

Package: quilt
Version: 0.65-2
Severity: minor

Dear Maintainer,

Sometimes quilt users must be able to switch between completely
different patch series.  For example, I ran into this issue when
dealing with applying an extra patch in debian/patches (to configure
both RCU_EXPERT and RCU_NOCB_CPU to default to "yes" to deal with
random Ryzen lockups) which turned out to conflict with a patch in
debian/patches-rt that "also" patched RCU_EXPERT default from "no" to
something else where apt-src applies the former set of patches when installing
and applies the latter set of patches on top of the former set when
building just (I think) the rt set of binary packages for the linux kernel.

I guess it could be claimed that the Debian Linux kernel should be
reorganized to use just one patch series, but currently that is not
the case (probably because that reorganization would be difficult),
and that is likely true of some other packages as well.  In sum,
multiple patch series are an unfortunate fact of life.

The only way to manage multiple patch series with quilt that I am
aware of (and it took a difficult google search to find this
information) is to specify both the QUILT_PATCHES and QUILT_PC
environment variables where the former points to the directory where
the series file is located (either debian/patches or
debian/patches-rt) and the latter is necessary to change between the
normal .pc location to somewhere else (I used .pc-rt for the above
specific case), I guess it could be argued that it is a rare case when
you attempt to manage with quilt two distinct patch series so QUILT_PC
is normally unnecessary.  But when you need it (as in the above case)
it is a lifesaver so I think it is worth documenting this environment
variable in the man page in the same section where QUILT_PATCHES and
several other environment variables are already documented.

You may also want to change the documentation of QUILT_SERIES there
that claims the search order for series can be prempted by an absolute
pathname for the series file, but that didn't work, and QUILT_PC did
the trick instead with QUILT_SERIES=series (which is the same as the
default value).

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages quilt depends on:
ii  bsdmainutils  11.1.2+b1
ii  bzip2 1.0.6-9
ii  diffstat  1.61-1+b1
ii  gettext   0.19.8.1-8
ii  patch 2.7.6-3
ii  perl  5.28.0-3

Versions of packages quilt recommends:
ii  less  487-0.1+b1

Versions of packages quilt suggests:
ii  graphviz2.40.1-5+b1
ii  postfix [mail-transport-agent]  3.3.0-1+b1
ii  procmail3.22-26

-- no debconf information

Bug#913683: apt: Please add support for package file lists API via libdpkg-dev

[Guillem Jover]

Source: apt
Source-Version: 1.8.0~alpha2
Severity: wishlist
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-interface

Hi!

The dpkg database will be changing formats in the near future, and one
of the blockers is all the code accessing it directly w/o going via a
supported interface. These include packages already using libapt, and
others using python-apt. So adding an interface in libapt would make
it possible for python-apt to do the same, and all their users to use
that properly.

A supported interface can be libdpkg-dev, which recently got support
for the file database, moved from the core dpkg code. Even though the
library is a static one, it should be built as PIC to support PIE
nowadays, so that should make it linkable for libapt. And even though
using a static library with a volatile API is not desirable, it's
probably better than any of the alternatives.

Of course, I'm happy to improve the libdpkg API to help with needs
coming from apt, just let me know.

Thanks,
Guillem

Bug#913681: lfm: Full documentation missing

[Ricardo F. Peliquero]

Package: lfm
Version: 3.1-1
Severity: normal

Dear Maintainer,

Please consider adding full documentation including keys descriptions
as stated in the manual page 'SEE ALSO' Section.

Or, should the man page be updated:

| SEE ALSO
|The full documentation which includes the keys descriptions
is in /usr/lib/python3/dist-packages/lfm/doc/README

Kind regards,

Ricardo Peliquero

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.18.0-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lfm depends on:
ii  python3  3.6.7-1

lfm recommends no packages.

lfm suggests no packages.

-- no debconf information

Bug#913661: munin-plugins-core: "apt_all update" no longer updates the state-file

[Lars Kruse]

Hello Andreas,


Am Tue, 13 Nov 2018 19:56:12 +0100
schrieb Andreas Pommer :

> The exec() call transfers the execution to the apt-get command, but exec()
> never returns, so the call to the function update_state() afterwards never
> happens, leading to a stale state-file.

thank you for your quick, precise and helpful analysis!

I just committed the fix - it will be published with a new release in a few
days.
(https://github.com/munin-monitoring/munin/commit/7f2dbcce607ce5180b634d30e4e2e32fe41d603e)

Cheers,
Lars

Bug#715470: RFP: cr3 -- Cool Reader 3, an e-book reader

[Gabriel F. T. Gomes]

Control: retitle -1 RFP: cr3 -- Cool Reader 3, an e-book reader

Hi,

I'm using this software from a local build and I'd like to add it to
Debian.  On the other hand, I'm not sure I'll be able to finish this
until Buster release (as I have many bugs to solve on bash-completion
and I want to focus on them).  So, if anyone has more time and would
like to work on the package, let's talk and I will be happy to
"transfer" the ITP.

On Tue, 26 Sep 2017 01:31:35 +0200 Axel Beckert  wrote:
> programmer11...@programist.ru wrote:
> > URL   :   http://coolreader.org/
> 
> This website is a link spammer nowadays. Seems as if the project lost
> its domain. :-/
> 
> The offical website seems to be
> https://sourceforge.net/projects/crengine/ nowadays.

And it seems that it moved again, now to github.com at
https://github.com/buggins/coolreader.

> > Version   :3.0.59

Current version on the new website is cr3.2.11-1 and it is from a month
ago (October, 2018).

> But then again the latest download link there seems to have version
> 3.0.56. (It's even a .deb and upstream seems to have some some basic
> debian-sih packaging at
> https://sourceforge.net/p/crengine/crengine/ci/master/tree/packages/ —
> last updated in 2012 though.)

Yes, there are some files for debian packaging, but I plan to go
through all the files, specially for the sake of copyright info.

> https://f-droid.org/packages/org.coolreader/ lists version 3.1.2 from
> 2015 as the newest version.
> 
> Nevertheless the last commit in the git repository as of now is from
> January 2017:
> https://sourceforge.net/p/crengine/crengine/commit_browser
> 
> So there still seem to be a little bit of activity.

A lot more on the new website.  :)

> > License   :GPL
> 
> The F-Droid app page also states: "The default dictionary app is
> non-free." — So anyone who's looking at packaging Cool Reader for
> Debian proper should have a very close look at the licenses.

That and the fact that it probes the system for some libraries and
tools, and when it doesn't find them, it builds them.  I still don't
know where it gets their source-code from (apparently not from the
internet), but I will check what's going on.


Thanks for the heads-up(s), Axel.

Bug#913680: linux-image-4.9.0-8-amd64 / 4.9.130-2 and USB pendrive problem

[Andres Bertens]

Package: src:linux
Version: 4.9.110-3+deb9u6
Severity: important

Just update to linux-image-4.9.0-8-amd64 - 4.9.130-2 and when removing an USB 
pendrive from XFCE desktop, system hangs.

Reverting to linux-image-4.9.0-8-amd64 - 4.9.110-3+deb9u6 removing USB pendrive 
works OK.

Tested on Thinkpad X230 and ASUS Zenbook UX430UNR.

Sorry for not running problematic kernel but a need a working desktop.

Regards,
Andres Bertens

-- Package-specific info:
** Version:
Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9u6 (2018-10-08)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-8-amd64 
root=UUID=a366de5f-58d3-4182-b9f6-5dd723483f8f ro iwlwifi.bt_coex_active=0 
thinkpad_acpi.fan_control=1 elevator=deadline quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 2325OF0
product_version: ThinkPad X230
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: G2ETB3WW (2.73 )
board_vendor: LENOVO
board_name: 2325OF0
board_version: Not Defined

** Loaded modules:
ctr
ccm
rfcomm
pci_stub
vboxpci(O)
vboxnetadp(O)
vboxnetflt(O)
vboxdrv(O)
ipt_MASQUERADE
nf_nat_masquerade_ipv4
cmac
xt_tcpudp
ip6table_filter
ip6_tables
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
bnep
iptable_filter
tun
bridge
stp
llc
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
iTCO_wdt
iTCO_vendor_support
kvm
snd_hda_codec_hdmi
irqbypass
crct10dif_pclmul
crc32_pclmul
arc4
btusb
btrtl
btbcm
btintel
bluetooth
snd_hda_codec_realtek
snd_hda_codec_generic
iwldvm
uvcvideo
videobuf2_vmalloc
mac80211
videobuf2_memops
videobuf2_v4l2
i915
videobuf2_core
videodev
media
ghash_clmulni_intel
snd_hda_intel
iwlwifi
snd_hda_codec
intel_cstate
intel_uncore
snd_hda_core
intel_rapl_perf
drm_kms_helper
snd_hwdep
snd_pcm
thinkpad_acpi
evdev
snd_timer
joydev
lpc_ich
drm
pcspkr
cfg80211
nvram
serio_raw
sg
mfd_core
i2c_algo_bit
mei_me
snd
mei
soundcore
wmi
rfkill
shpchp
ac
battery
video
button
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
crc32c_generic
fscrypto
ecb
mbcache
sd_mod
crc32c_intel
ahci
libahci
libata
scsi_mod
aesni_intel
i2c_i801
i2c_smbus
aes_x86_64
glue_helper
lrw
gf128mul
ablk_helper
cryptd
psmouse
ehci_pci
ehci_hcd
xhci_pci
sdhci_pci
sdhci
xhci_hcd
mmc_core
e1000e
ptp
pps_core
usbcore
usb_common
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM 
Controller [8086:0154] (rev 09)
Subsystem: Lenovo 3rd Gen Core processor DRAM Controller [17aa:21fa]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ivb_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core 
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo 3rd Gen Core processor Graphics Controller [17aa:21fa]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Lenovo 7 Series/C210 Series Chipset Family USB xHCI Host 
Controller [17aa:21fa]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216 
Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Lenovo 7 Series/C216 Chipset Family MEI Controller 
[17aa:21fa]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:16.3 Serial controller [0700]: Intel Corporation 7 Series/C210 Series 
Chipset Family KT Controller [8086:1e3d] (rev 04) (prog-if 02 [16550])
Subsystem: Lenovo 7 Series/C210 Series Chipset Family KT Controller 
[17aa:21fa]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: serial

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network 
Conne

Bug#894359: Help needed to port beast2-mcmc to Java 9

[Emmanuel Bourg]

On Mon, 9 Apr 2018 13:24:51 +0200 Andreas Tille  wrote:

> [javac] import com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl;
> [javac]  ^
> [javac] 
> /build/beast2-mcmc-2.4.8+dfsg/src/beast/util/XMLParserUtils.java:120: 
> warning: CoreDocumentImpl is internal proprietary API and may be removed in a 
> future release
> [javac] ((CoreDocumentImpl) doc).putIdentifier(id, 
> (Element) node);
> [javac]   ^
> [javac] /build/beast2-mcmc-2.4.8+dfsg/src/beast/util/TreeParser.java:353: 
> error: cannot find symbol
> [javac] CharStream charStream = CharStreams.fromString(newick);
> [javac] ^
> [javac]   symbol:   variable CharStreams
> [javac]   location: class TreeParser
> [javac] 
> /build/beast2-mcmc-2.4.8+dfsg/src/beast/util/treeparser/NewickLexer.java:98: 
> error: method does not override or implement a method from a supertype
> [javac] @Override
> [javac] ^

Hi Andreas,

I've pushed a fix for this issue and now beast2-mcmc builds fine with
antlr 4.6. Could you give it a try? If it works that would allow us to
move forward without waiting for antlr 4.7.

Emmanuel Bourg

Bug#913679: kopete: libjingle-call keeps crashing

[Oswald Buddenhagen]

Package: kopete
Version: 4:17.08.3-2
Severity: important

when an xmpp account is configured and "Enable libjingle support" is
enabled, kopete will spawn libjingle-call (being online is apparently
sufficient). this will immediately crash, leaving such an entry in
the journal:

Nov 14 00:23:30 host kernel: libjingle-call[6998]: segfault at 48 ip 
7fa8d882ec73 sp 7ffe90fdb610 error 4 in 
libcrypto.so.1.1[7fa8d87f1000+19f000]
Nov 14 00:23:30 host kernel: Code: 40 24 01 00 00 00 4c 89 e2 c7 40 50 01 00 00 
00 0f ae f0 e8 ff 35 fc ff 85 c0 74 6c e8 86 4c fc ff 48 89 43 70 48 85 c0 74 
2d <48> 8b 45 48 48 85 c0 74 74 48 89 df ff d0 85 c0 0f 84 a7 00 00 00 [...]

the executable will be instantly respawned, which on my system produces
about six entries per second. within some hours, the disk fills up,
rendering the system unusable.

the non-existing handling of the "keeps crashing" situation is certainly
an upstream issue. but the crash itself may be related to the packaging.

here's an actual backtrace:

#0  BIO_new (method=0x0) at ../crypto/bio/bio_lib.c:94
#1  0x555fe062667a in BIO_new_socket (socket=0x555fe17fee08) at 
./protocols/jabber/libjingle/talk/base/openssladapter.cc:123
#2  0x555fe0626fc3 in talk_base::OpenSSLAdapter::BeginSSL 
(this=this@entry=0x555fe17fef10) at 
./protocols/jabber/libjingle/talk/base/openssladapter.cc:345
#3  0x555fe0627122 in talk_base::OpenSSLAdapter::StartSSL 
(hostname=0x555fe17ff700 "kde.org", restartable=, 
this=0x555fe17fef10) at 
./protocols/jabber/libjingle/talk/base/openssladapter.cc:320
#4  talk_base::OpenSSLAdapter::StartSSL (this=0x555fe17fef10, 
hostname=0x555fe17ff700 "kde.org", restartable=) at 
./protocols/jabber/libjingle/talk/base/openssladapter.cc:307
#5  0x555fe0799413 in XmppSocket::StartTls (domainname=..., 
this=0x555fe17fdca0) at /usr/include/c++/8/bits/basic_string.h:2290
#6  XmppSocket::StartTls (this=0x555fe17fdca0, domainname=...) at 
./protocols/jabber/libjingle/talk/examples/login/xmppsocket.cc:227
#7  0x555fe07749e3 in buzz::XmppEngineImpl::StartTls (this=0x555fe17ff610, 
domain=...) at /usr/include/c++/8/bits/basic_string.h:1031
#8  0x555fe0777507 in buzz::XmppLoginTask::Advance 
(this=this@entry=0x555fe17ffe60) at 
./protocols/jabber/libjingle/talk/xmpp/jid.h:55
#9  0x555fe0777c20 in buzz::XmppLoginTask::Advance (this=0x555fe17ffe60) at 
./protocols/jabber/libjingle/talk/xmpp/xmpplogintask.cc:98
#10 buzz::XmppLoginTask::IncomingStanza (this=0x555fe17ffe60, 
element=element@entry=0x555fe1801a90, isStart=isStart@entry=false) at 
./protocols/jabber/libjingle/talk/xmpp/xmpplogintask.cc:85
#11 0x555fe0773c16 in buzz::XmppEngineImpl::IncomingStanza 
(this=0x555fe17ff610, stanza=0x555fe1801a90) at 
./protocols/jabber/libjingle/talk/xmpp/xmppengineimpl.cc:306
#12 0x555fe0777dbf in buzz::XmppStanzaParser::IncomingEndElement 
(name=, pctx=, this=0x555fe17ff628) at 
./protocols/jabber/libjingle/talk/xmpp/xmppstanzaparser.cc:93
#13 buzz::XmppStanzaParser::IncomingEndElement (this=0x555fe17ff628, 
pctx=, name=) at 
./protocols/jabber/libjingle/talk/xmpp/xmppstanzaparser.cc:82
#14 0x7f4731f203ff in doContent (parser=parser@entry=0x555fe17ff920, 
startTagLevel=startTagLevel@entry=0, enc=, s=, 
end=0x555fe18005cb "", nextPtr=0x555fe17ff950, haveMore=1 '\001')
at ../../src/lib/xmlparse.c:2924
#15 0x7f4731f214bc in contentProcessor (parser=0x555fe17ff920, 
start=, end=, endPtr=) at 
../../src/lib/xmlparse.c:2552
#16 0x7f4731f23a06 in XML_ParseBuffer (parser=0x555fe17ff920, len=50, 
isFinal=0) at ../../src/lib/xmlparse.c:1988
#17 0x555fe074d9c3 in buzz::XmlParser::Parse (this=0x555fe17ff640, 
data=, len=, isFinal=isFinal@entry=false) at 
./protocols/jabber/libjingle/talk/xmllite/xmlparser.cc:172
#18 0x555fe074dbe8 in buzz::XmlParser::Parse (this=, 
data=, len=, isFinal=isFinal@entry=false) at 
./protocols/jabber/libjingle/talk/xmllite/xmlparser.cc:169
#19 0x555fe0774cad in buzz::XmppStanzaParser::Parse (isFinal=false, 
len=, data=, this=) at 
./protocols/jabber/libjingle/talk/xmpp/xmppstanzaparser.h:52
#20 buzz::XmppEngineImpl::HandleInput (this=, bytes=, len=) at 
./protocols/jabber/libjingle/talk/xmpp/xmppengineimpl.cc:109
#21 0x555fe076fef4 in buzz::XmppClient::Private::OnSocketRead 
(this=0x555fe17fd370) at 
./protocols/jabber/libjingle/talk/xmpp/xmppclient.cc:350
#22 0x555fe0799805 in 
sigslot::signal0::operator() (this=0x555fe17fdd08) at 
/usr/include/c++/8/bits/stl_list.h:301
#23 XmppSocket::OnReadEvent (this=0x555fe17fdca0, socket=) at 
./protocols/jabber/libjingle/talk/examples/login/xmppsocket.cc:88
#24 0x555fe0626e58 in sigslot::signal1::operator() (a1=0x555fe17fef10, this=0x555fe17fef18) 
at /usr/include/c++/8/bits/stl_list.h:301
#25 talk_base::AsyncSocketAdapter::OnReadEvent (socket=, 
this=0x555fe17fef10) at ./protocols/jabber/libjingle/talk/base/asyncsocket.h:119
#26 talk_base::OpenSSLAdapter::OnReadEvent (this=0x555fe17fef10, 
socket=) at 
./protocols/jabber/libjingle/t

Bug#408954: checkroot.sh: should not skip running fsck with JFS root

[Theodore Y. Ts'o]

On Tue, Nov 13, 2018 at 11:46:31PM +0100, Adam Borowski wrote:
> what would you say about getting rid of fsck at boot for most filesystems?

The reason why it's important to run fsck at boot is because for many
file systems if a file system consistency problem is detected at run
time (this might be caused by a kernel bug; or a hardware problem; or
a cosmic ray).  If that happens a flag in the superblock is set
indicating that file system really needs to be checked.

For ext4, what happens after the flag is set in the superblock depends
on how the file system is configured (via mount options or by flags
set via tune2fs -e.  We can either ignore the fact that there was an
error (the "don't worry, be happy" mode), we can remount the file
system read-only --- or we can immediately force a reboot.  At which
point, when the system reboots, the file system checker will run, and
in preen mode, will automatically force a full check.

So the assertion in the bug report, "running fsck at boot is harmful
for any modern file system" falls into the same trap as ZFS did when
they asserted, "we're a modern file system, we don't need a fsck
program at all!"  They very quickly learned that in the real world,
there are cosmic rays hitting DRAM; there are hardware bugs; there are
kernel bugs.  And sending angry customers to ZFS developers to
manually fix corrupted file systems (because ZFS didn't have an fsck)
didn't scale.  :-)

So running fsck at boot is absolutely required.

> For the few that actually need it, being on battery shouldn't skip it.

It was never a good idea for checkroot.sh to be checking whether or it
was on battery.  That check needs to be done in the file system
checker.  So for ext4, if you do want to enable time-based or mount
count-based checks, e2fsck will check whether or not the system was on
battery, and skip the check if the reason for the check was the last
check time or mount count was triggering the check.  HOWEVER, if the
file system is marked as having some corruption found by the kernel,
e2fsck will always try to fix the problem, on the assumption that most
users care about the data not getting lost more than they care about
battery life.  :-)

Regards,

- Ted

Bug#913678: status/package.php: ↓ link to diagnosis for packages in state BD-Uninstallable

[Paul Wise]

Package: buildd.debian.org
Severity: wishlist

For packages in state BD-Uninstallable on some architectures, it would
be nice to have a ↓ link next to the architecture name that points at
the existing diagnosis of which build-dependencies are uninstallable.

https://buildd.debian.org/status/package.php?p=rsyslog

This is the code involved in the existing ↓ links:

library.php:$badstate = array("Failed", "Maybe-Failed", "Build-Attempted");
...
library.php-function single($info, $version, $log, $arch, $suite, $problemid) {
...
library.php:if (in_array($info["state"], $badstate)) {
library.php-  $anchor = sprintf(" ↓", 
$problemid);
library.php-}

There is other code that checks $info["state"] against $badstate so
perhaps the comparison check should have || $problemid added to it?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#913677: glusterfs-client: Hard link limit?

[Dean Hamstead]

Package: glusterfs-client
Version: 4.1.5-1~bpo9+1
Severity: normal

Dear Maintainer,

I've not been able to determine if this is a fuse limit, a gluster
limit, or something else entirely.

Anyway, I have been rsync'ing from a $commercial NFS over to a new shiny
gluster volume.

However it seems there is hard link limit I have hit.

>From rsync:

rsync: link
"/opt/nximages/pi/ae/266c042d7ec532c9fb8bf9f81d1012512e86b5-26253/.full.jpg.23309"
=> 02/f6b1b71161fbd3900b5b04cc0eca8ba5ec5efd-26253/full.jpg failed: Too
many links (31)
rsync: link
"/opt/nximages/pi/ae/266c042d7ec532c9fb8bf9f81d1012512e86b5-26253/.merch.jpg.23309"
=> 02/f6b1b71161fbd3900b5b04cc0eca8ba5ec5efd-26253/merch.jpg failed: Too
many links (31)


>From /var/log/glusterfs/opt-nximages.log

[2018-11-14 00:08:14.246446] W [MSGID: 114031]
[client-rpc-fops_v2.c:2383:client4_0_link_cbk] 0-nximages1-client-2:
remote operation failed:
(/pi/c7/57da83670efc30e2c40fc61a84c64582ca5e79-1909762/thumb.png ->
/pi/c7/8a9c2182416f9c8a3b676d842310ad75a2fde4-1909762/.thumb.png.23309)
[Too many links]
[2018-11-14 00:08:14.246532] W [MSGID: 114031]
[client-rpc-fops_v2.c:2383:client4_0_link_cbk] 0-nximages1-client-1:
remote operation failed:
(/pi/c7/57da83670efc30e2c40fc61a84c64582ca5e79-1909762/thumb.png ->
/pi/c7/8a9c2182416f9c8a3b676d842310ad75a2fde4-1909762/.thumb.png.23309)
[Too many links]
[2018-11-14 00:08:14.247201] W [fuse-bridge.c:565:fuse_entry_cbk]
0-glusterfs-fuse: 49760979: LINK()
/pi/c7/8a9c2182416f9c8a3b676d842310ad75a2fde4-1909762/.thumb.png.23309
=> -1 (Too many links)

I can't seem to locate a mention of such a limit. I place this here
hoping for assistance from those with more gluster experience than
myself

Thanks


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (98, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages glusterfs-client depends on:
ii  fuse  2.9.7-1+deb9u1
ii  glusterfs-common  4.1.5-1~bpo9+1
ii  libc6 2.24-11+deb9u3
ii  libssl1.1 1.1.0f-3+deb9u2
ii  python2.7.13-2

glusterfs-client recommends no packages.

glusterfs-client suggests no packages.

-- no debconf information


Psst! It's possible that this email contains information that is on the super 
secret side of confidential. So if you received it accidentally, let the sender 
know straight away and delete it (and the email you sent them). Also, we should 
let you know that any emails that come and go through Winc™ might be 
scanned, stored or read by Winc™ at its discretion. If you've got a 
question, please give us a buzz on +61 2 9335 0555 (Australia) or +64 9 271 
7600 (NZ). Oh, and Winc™ does its best to avoid errors on emails it 
sends, but we can't promise that it will be error free. So, please don't hold 
it against us.

Bug#848125: bash-completion: Patch to allow '+' in (ssh/know_hosts) hostnames

[Gabriel F. T. Gomes]

On Wed, 14 Dec 2016 Vincent Danjean  wrote:

>   I'm using automatic gateway with ssh (and ProxyCommand) so that
> ssh gw1+gw2+host will correctly setup a connection first to gw1,
> then to gw2 (via gw1 and ProxyCommand) and eventually with host
> (via gw2 and ProxyCommand) whatever gw1, gw2 and host are.

Do you need some sort of configuration in ~/.ssh/config?

>   To do that, I need the '+' character in ssh hostname.

Is the `+' character in the `Host' entry in ~/.ssh/config?

> It works
> perfectly with ssh, scp, rsync, ... but not with bash-completion. The
> reason is that the '+' is not escaped when a regexp for awk is built
> in _known_hosts_real.

I'd like to reproduce the problem you are describing, but I need more
information on how to do it.

> diff --git a/bash_completion b/bash_completion
> index 6d3ba76..c640278 100644
> --- a/bash_completion
> +++ b/bash_completion
> @@ -1484,6 +1496,7 @@ _known_hosts_real()
>  # Escape slashes and dots in paths for awk
>  awkcur=${cur//\//\\\/}
>  awkcur=${awkcur//\./\\\.}
> +awkcur=${awkcur//\+/\\\+}
>  curd=$awkcur
>  
>  if [[ "$awkcur" == [0-9]*[.:]* ]]; then

As mentioned by Ville Skyttä in his reply [1], this should be fixed
upstream, as a side-effect of a refactoring.  However, the patch has
been committed after the release of version 2.8.

I can certainly backport it to Debian (and I have already done so in a
local branch), but it would be nice to reproduce the bug and check that
the backport actually fixes it.

So, could you provide some `steps to reproduce'?


Thanks,
Gabriel

[1] https://bugs.debian.org/848125#10

Bug#913045: [Pkg-alsa-devel] Bug#913045: Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Pedro Silva]

On Tue, 13 Nov 2018 23:44:35 +0100 Elimar Riesebieter
 wrote:

> Heureka!
>
> Could you please test also libasound2-plugins 1.1.7-3 which arrived

$ dpkg -l | grep libasound2 | awk {'print $2,$3'}
libasound2:amd64 1.1.7-1
libasound2:i386 1.1.7-1
libasound2-data 1.1.7-1
libasound2-dev:amd64 1.1.7-1
libasound2-plugins:amd64 1.1.7-3
libasound2-plugins:i386 1.1.7-3

If ~/.asoundrc doesn't exist, same error:

ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

If previous ~/.asoundrc exists, everything works as expected.

If you require additional testing or info, please do ask.

Best regards,
Pedro Silva

Bug#904917: general: Gnome randomly crash and restart to login.

[Riccardo Gagliarducci]

I have used gnome on the previus cited Lenovo Laptop without extension
for some months and gnome is generally more stable BUT occasionaly I
had the same identical crash. Nvidia drivers were loaded.


I had setup the same identical system on a Dell G5, withOUT nvidia
drivers but nouveau only and I suffer the same identical trouble, about
once every day.

Gnome exensions are enabled:
- Freon
- GsConnect

I do 3d graphics but crash is totally indipendent and happens even on a
soft use (mail, browser, ecc...).

Here some info. I'll post dmesg info next crash.

Thank you,
Riccardo


# lsmod | grep nouveau
nouveau  2162688  1
mxm_wmi16384  1 nouveau
ttm   131072  1 nouveau
drm_kms_helper196608  2 i915,nouveau
drm   471040  23 drm_kms_helper,i915,ttm,nouveau
i2c_algo_bit   16384  2 i915,nouveau
video  45056  4 dell_wmi,dell_laptop,i915,nouveau
wmi28672  6
dell_wmi,wmi_bmof,dell_smbios,dell_wmi_descriptor,mxm_wmi,nouveau
button 16384  1 nouveau


# lspci -nnk | grep -iA2 vga 
00:02.0 VGA compatible controller [0300]: Intel Corporation Device
[8086:3e9b]
Subsystem: Dell Device [1028:0825]
Kernel driver in use: i915
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106M
[GeForce GTX 1060] [10de:1c20] (rev a1)
Kernel driver in use: nouveau
Kernel modules: nouveau






Il giorno dom, 29/07/2018 alle 15.50 +0200, Riccardo Gagliarducci ha
scritto:
> Package: general
> Severity: grave
> Justification: causes non-serious data loss
> 
> Dear Maintainer,
> 
> on Lenovo laptop ideapad 520 Gnome randomly crash and, after some
> seconds of
> text, the system ask me to login to gnome, as if I had access to it
> during
> boot.
> All the opened software and data is gone.
> 
> It happens 1 to 4 times a day.
> 
> I have consulted the syslog, kern, Xorg but I can't find any hints on
> the
> package is causing the error.
> 
> 
> The laptop harware is:
> Intel® Core™ i7-8550U CPU @ 1.80GHz × 8
> 
> and double graphic card:
> 
> VGA compatible controller: Intel Corporation UHD Graphics 620
> (Kabylake
> GT2)(rev 07)
> Subsystem: Lenovo UHD Graphics 620
> Kernel driver in use: i915
> 
> 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev
> ff)
> Kernel modules: nvidia
> 
> The system is Debian GNU/Linux buster/sid 64 bit using bumblebee and
> Nvidia
> driver Version: 390.48.
> 
> 
> Thank you,
> Riccardo
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing'), (2, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
> LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash

Bug#913676: Mangled warning message

[Ian Jackson]

Package: dgit-infrastructure
Version: 6.0
Severity: minor

I just saw this message:

 remote: Forcing due to 
--deliberately---deliberately-include-questionable-history

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#871806: #871806: check git tag signatures

[Daniel Kahn Gillmor]

On Tue 2018-11-13 21:53:12 +0100, Xavier wrote:
> Note that if there is a "git origin" that points to upstream repo, uscan
> will use it instead of creating a temporary "git clone". It is more
> efficient I think

hm, too bad.  i use "upstream" as the name of my upstream git repos,
since as often as not "origin" (where the thing was originally cloned
from) is the debian packaging. :P Maybe i should change my practices
there though if everyone else does it differently…

> Thanks, I copied old uscan calls since the challenge was non-regression
> after rewriting. Time to improve now!

happy to help!  it made me notice and report #913665 as well, if you're
poking around in there :)  sorry i didn't have the time to write and
test the fixes!

> Unfortunately no. Git signatures are not linked to the archive itself
> but only to the tag. I don't see any way to link an extracted archive to
> this sort of .asc

right, i'm thinking of some kind of hack similar to a pristine-tar delta
file, but which could maybe contain enough of a shallow clone to let the
signature verify.  i don't know whether that's possible though, i
haven't actually thought through the data structures or git's hashing
tree.

all the best,

 --dkg

Bug#913586: texlive-binaries 2018.20181104.49075-1 breaks context

[Thanasis Kinias]

Hi Norbert,

Thanks much! All looks well with 2018.20181104.49075-2.

Best,
Thanasis

On Tue, 13 Nov 2018 at 11:15, Norbert Preining  wrote:

> > Arg, indeed. Why didn't that happen here is a surprise to me, but now I
> > can reproduce it.
>
> I reverted luatex to the previous version 1.07 which works (at least
> here) and uploaded a new package of texlive-bin.
>
> Thanasis: If you are in hurry, please get the binaries from unstable.
>
> Thanks
>
> Norbert
>
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. +JAIST +TeX Live +Debian Developer
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
>


-- 
Thanasis Kinias
Instructor & Doctoral Candidate, Department of History, Northeastern
University
kinia...@husky.neu.edu

Bug#912818: getmail: socket error ([SSL: WRONG_SIGNATURE_TYPE] wrong signature type (_ssl.c:726))

[Dmitry Smirnov]

On Sunday, 4 November 2018 3:28:58 PM AEDT Daniel Kahn Gillmor wrote:
> The problem here is with the behavior of the remote server,

Thank you very much for quick and thorough analysis, Daniel.

Much appreciated.

-- 
Best wishes,
 Dmitry Smirnov.

---

There is no such thing as public opinion. There is only published opinion.
-- Winston Churchill


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

Bug#913674: release.debian.org: Regression: Recent upgrade of opensc breaks Yubikey NEO support

[Erik]

How do I unsubscribe? 

On November 13, 2018 6:10:23 PM EST, Hilko Bengen  wrote:
>* Adam D. Barratt:
>
>> On Tue, 2018-11-13 at 22:54 +0100, Hilko Bengen wrote:
>>> 
>>> A few weeks ago I reported that a security patch in
>>> opensc/0.16.0-3+deb9u1 broke support for Yubkey NEO devices
>(#910786,
>>> severity serious). Unfortunately, this did not prevent opensc from
>>> being included in the recent stretch point release.
>>
>> Indeed, because no-one reported it to us. (No, filing an RC bug
>doesn't
>> count as notifying SRM, I'm afraid.)
>
>Thanks for the clarification. I must have somehow assumed that there
>would be a similar process in place as we have for migtations from
>unstable to testing.
>
>Perhaps adding some  sort of automatic notification might  make sense
>--
>for my taste there is a bit too much "tribal knowledge" going on here.
>
>But back to the immediate issue:
>
>>> What can we do to fix the package now?
>>
>> Firstly, one needs to identify whether the same issue affects the
>> package in unstable.
>
>A trivial backport of opensc/0.19.0-1 works for the simple test I
>reported in #910786 -- and for my OpenVPN setup, albeit not without
>some
>reconfiguration. (A NEWS.Debian entry might be in order here.)
>
>All CVE-documented bugs that are mentioned in the 0.16.0-3+deb9u1
>changelog have also been fixed in 0.19.0 -- according to the upstream
>NEWS file.
>
>Cheers,
>-Hilko

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#913674: release.debian.org: Regression: Recent upgrade of opensc breaks Yubikey NEO support

[Hilko Bengen]

* Adam D. Barratt:

> On Tue, 2018-11-13 at 22:54 +0100, Hilko Bengen wrote:
>> 
>> A few weeks ago I reported that a security patch in
>> opensc/0.16.0-3+deb9u1 broke support for Yubkey NEO devices (#910786,
>> severity serious). Unfortunately, this did not prevent opensc from
>> being included in the recent stretch point release.
>
> Indeed, because no-one reported it to us. (No, filing an RC bug doesn't
> count as notifying SRM, I'm afraid.)

Thanks for the clarification. I must have somehow assumed that there
would be a similar process in place as we have for migtations from
unstable to testing.

Perhaps adding some  sort of automatic notification might  make sense --
for my taste there is a bit too much "tribal knowledge" going on here.

But back to the immediate issue:

>> What can we do to fix the package now?
>
> Firstly, one needs to identify whether the same issue affects the
> package in unstable.

A trivial backport of opensc/0.19.0-1 works for the simple test I
reported in #910786 -- and for my OpenVPN setup, albeit not without some
reconfiguration. (A NEWS.Debian entry might be in order here.)

All CVE-documented bugs that are mentioned in the 0.16.0-3+deb9u1
changelog have also been fixed in 0.19.0 -- according to the upstream
NEWS file.

Cheers,
-Hilko

Bug#840388: Confirm

[Quazgar]

I can confirm this on Ubuntu 18.04 , fusedav 0.2-3.1build1, it does 
nothing here when trying to mount a DAV directory.


--
Mein öffentlicher Schlüssel / My public key: 0x600ACB3B 2012-04-01
Fingerabdruck / Fingerprint:
9902 575B B9A0 C339 CFDF  250B 9267 CA6B 600A CB3B
Runterladen z.B. bei/ Get it e.g. here:
pgp.mit.edu, subkeys.pgp.net, pgp.uni-mainz.de, pool.sks-keyservers.net, 
...

Bug#911026: ITP: manuskript -- open-source tool for writers

[Miriam Ruiz]

Hi!!!

Sorry for not having answered before. I started my packages from
scratch. They are already in the NEW queue [1]. Hopefully they might
be in soon!

Greetings,
Miry


[1] https://ftp-master.debian.org/new.html

El mar., 23 oct. 2018 a las 17:10, Antoine Beaupré
() escribió:
>
> On 2018-10-14 23:23:30, Miriam Ruiz wrote:
> > Manuskript is an open source tool for writers. It provides a rich 
> > environment
> > to help writers create their first draft and then further refine and edit
> > their masterpiece.
> >
> > Manuskript is still in development, and in need of extensive testing.
>
> Oh! Oh! Oh! Me! Me! Me! I want to try this! :)
>
> I would be very happy to test Debian packages of this ... are you
> starting from upstream .debs?
>
> Thanks!
>
> --
> Soyons réalistes, faisons l'impossible.
> - Ernesto "Che" Guevara

Bug#408954: checkroot.sh: should not skip running fsck with JFS root

[Adam Borowski]

[JFS's regular fsck does nothing but, and is needed to, trigger journal
replay.  If the journal replay is skipped, dirty fs will fail the mount,
resulting in a boot failure if / .  Being on battery skips fsck.]

On Tue, Nov 13, 2018 at 08:22:09PM +, Dmitry Bogatov wrote:
> 
> control: tags -1 confirmed
> 
> [2018-11-12 02:03] Adam Borowski 
> > On Mon, Nov 12, 2018 at 01:20:25AM +0100, Adam Borowski wrote:
> > > And JFS doesn't do the full check either, it merely apparently needs (or
> > > more likely needed -- this report is 11¾ years old) only a trigger for the
> > > journal replay.
> > > 
> > > So I propose:
> > > 1. checking if JFS still needs this
> > 
> > Yes, it does.
> > 
> > So we still need fsck to boot, no matter if the computer is on battery or
> > not.  So this bug is still valid.
> 
> Am I correct, that fsck (checkroot.sh) is actually needed only in case
> of ext2 or jfs root?

No idea about some weird filesystems -- but at least for ext*, there's a guy
who knows it a wee bit better than any of us.  Might also offer advice wrt
other filesystems as well.

Ted:
what would you say about getting rid of fsck at boot for most filesystems?
For the few that actually need it, being on battery shouldn't skip it.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#913045: [Pkg-alsa-devel] Bug#913045: Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Elimar Riesebieter]

* Pedro Silva  [2018-11-13 22:29 +]:

> On Fri, 9 Nov 2018 20:41:17 + Pedro Silva 
> wrote:
> > No difference.
> >
> > Reboot, login, start game, sound ok. Start browser, play youtube video,
> > playback hangs until game is closed.
> >
> > cat ~/.asoundrc
> > ###
> > pcm.!default {
> >     type hw
> >     card 2
> > }
> > ###
> > ctl.snd_card {
> >     type hw
> >     card 2
> >     device 2
> > }
> > ###
> >
> > Best regards,
> > Pedro Silva
> 
> Hi Elimar,
> 
> I found a working ~/.asoundrc :
> 
> $ cat .asoundrc
> ctl.dmixer {
> type pulse
> }
> pcm.pulse {
> type pulse
> }
> ctl.pulse {
> type pulse
> }
> pcm.!default {
> type pulse
> }
> ctl.!default {
> type pulse
> }
> 
> I can run Steam Alsa games and youtube videos at the same time (I
> believe system wide). I can even connect a bluetooth headset and have it
> work without additional setup.
> 
> Found the info here :
> 
> https://steamcommunity.com/app/221410/discussions/0/618458030650103916/#c618458030650649992
> 
> Don't know if this is a libasound2 or steam games bug/feature.

Heureka!

Could you please test also libasound2-plugins 1.1.7-3 which arrived
in the repos today?

Many thanks for cooperation.

Elimar
-- 
  >what IMHO then?
  IMHO - Inhalation of a Multi-leafed Herbal Opiate ;)
  --posting from alex in debian-user--


signature.asc
Description: PGP signature

Bug#913045: [Pkg-alsa-devel] Bug#913045: libasound2: ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave

[Pedro Silva]

On Fri, 9 Nov 2018 20:41:17 + Pedro Silva 
wrote:
> No difference.
>
> Reboot, login, start game, sound ok. Start browser, play youtube video,
> playback hangs until game is closed.
>
> cat ~/.asoundrc
> ###
> pcm.!default {
>     type hw
>     card 2
> }
> ###
> ctl.snd_card {
>     type hw
>     card 2
>     device 2
> }
> ###
>
> Best regards,
> Pedro Silva

Hi Elimar,

I found a working ~/.asoundrc :

$ cat .asoundrc
ctl.dmixer {
type pulse
}
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}

I can run Steam Alsa games and youtube videos at the same time (I
believe system wide). I can even connect a bluetooth headset and have it
work without additional setup.

Found the info here :

https://steamcommunity.com/app/221410/discussions/0/618458030650103916/#c618458030650649992

Don't know if this is a libasound2 or steam games bug/feature.

Thank you for your support.

Best regards,
Pedro Silva

Bug#913675: tiff: CVE-2018-19210

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.9+git181026-1
Severity: important
Tags: security upstream
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2820

Hi,

The following vulnerability was published for tiff.

CVE-2018-19210[0]:
| In LibTIFF 4.0.9, there is a NULL pointer dereference in the
| TIFFWriteDirectorySec function in tif_dirwrite.c that will lead to a
| denial of service attack, as demonstrated by tiffset.

The issue can be verified with the poc0 included upstream in the rar
archive attached).

==23934== Memcheck, a memory error detector
==23934== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==23934== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==23934== Command: tiffset ~/poc0
==23934==
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not 
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 390 (0x186) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 302 (0x12e) encountered.
TIFFReadDirectory: Warning, Unknown field with tag 61961 (0xf209) encountered.
TIFFReadDirectory: Warning, Photometric tag is missing, assuming data is YCbCr.
TIFFReadDirectory: Warning, SamplesPerPixel tag is missing, applying correct 
SamplesPerPixel value of 3.
==23934== Invalid read of size 8
==23934==at 0x483BA14: __memcmp_sse4_1 (vg_replace_strmem.c:1099)
==23934==by 0x4877929: TIFFWriteDirectoryTagTransferfunction 
(tif_dirwrite.c:1896)
==23934==by 0x4877929: TIFFWriteDirectorySec.part.12 (tif_dirwrite.c:628)
==23934==by 0x4878EEF: TIFFRewriteDirectory (tif_dirwrite.c:358)
==23934==by 0x109519: main (tiffset.c:361)
==23934==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23934==
==23934==
==23934== Process terminating with default action of signal 11 (SIGSEGV)
==23934==  Access not within mapped region at address 0x0
==23934==at 0x483BA14: __memcmp_sse4_1 (vg_replace_strmem.c:1099)
==23934==by 0x4877929: TIFFWriteDirectoryTagTransferfunction 
(tif_dirwrite.c:1896)
==23934==by 0x4877929: TIFFWriteDirectorySec.part.12 (tif_dirwrite.c:628)
==23934==by 0x4878EEF: TIFFRewriteDirectory (tif_dirwrite.c:358)
==23934==by 0x109519: main (tiffset.c:361)
==23934==  If you believe this happened as a result of a stack
==23934==  overflow in your program's main thread (unlikely but
==23934==  possible), you can try to increase the size of the
==23934==  main thread stack using the --main-stacksize= flag.
==23934==  The main thread stack size used in this run was 8388608.
==23934==
==23934== HEAP SUMMARY:
==23934== in use at exit: 9,087 bytes in 20 blocks
==23934==   total heap usage: 47 allocs, 27 frees, 21,497 bytes allocated
==23934==
==23934== LEAK SUMMARY:
==23934==definitely lost: 504 bytes in 1 blocks
==23934==indirectly lost: 0 bytes in 0 blocks
==23934==  possibly lost: 0 bytes in 0 blocks
==23934==still reachable: 8,583 bytes in 19 blocks
==23934== suppressed: 0 bytes in 0 blocks
==23934== Rerun with --leak-check=full to see details of leaked memory
==23934==
==23934== For counts of detected and suppressed errors, rerun with: -v
==23934== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19210
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19210
[1] http://bugzilla.maptools.org/show_bug.cgi?id=2820

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#913674: release.debian.org: Regression: Recent upgrade of opensc breaks Yubikey NEO support

[Adam D. Barratt]

Control: severity -1 normal

On Tue, 2018-11-13 at 22:54 +0100, Hilko Bengen wrote:
> Package: release.debian.org
> Severity: grave

RC bugs in psuedo-packages / teams generally don't make much sense. (On
the whole, anything > normal against release.d.o is likely to be
wrong.)

> Tags: stretch
> 
> A few weeks ago I reported that a security patch in
> opensc/0.16.0-3+deb9u1 broke support for Yubkey NEO devices (#910786,
> severity serious). Unfortunately, this did not prevent opensc from
> being included in the recent stretch point release.

Indeed, because no-one reported it to us. (No, filing an RC bug doesn't
count as notifying SRM, I'm afraid.)

> What can we do to fix the package now?

Firstly, one needs to identify whether the same issue affects the
package in unstable.

Once it's been confirmed that unstable is no{t, longer} affected,
someone should produce a fixed package and open a p-u bug to document
uploading that to proposed-updates.

Regards,

Adam

Bug#570623: Submitted MR on Salsa

[John Goerzen]

One additional comment - it would probably be good to default Limit: 1
to mimic prior behavior, wouldn't it?

- John

Bug#908678: Testing the filter-branch scripts

[Moritz Muehlenhoff]

On Tue, Nov 13, 2018 at 12:22:54PM -0500, Antoine Beaupré wrote:
 > But before going through that trouble, I think we'd need to get approval
> from the security team first, as that's quite a lot of work. I figured
> we would make a feasability study first...

The current data structure works very well for us and splitting the files
has many downsides.

If we can't get the repository in run on salsa in a manner that doesn't
impact other repositories (e.g. by disabling the repository browser or
similar), then moving the security tracker repository out of Salsa is
the more likely solution.

Did anyone follow Guido's suggestion to report this upstream to
get their assessment on possible optimisations?

Cheers,
Moritz

Bug#905673: menu-xdg: diff for NMU version 0.5+nmu1

[Bill Allombert]

On Sun, Nov 11, 2018 at 04:36:00PM +, Niels Thykier wrote:
> Not fully. I did not know how to exercise that bit of code in menu-xdg
> live (I am not a use of menu myself).  The best I could come up with was
> testing comparing original shell call and its replacement in isolation
> (which is what I did).
>   If you have a means to test it, it would a great help for me. :)

No problem, I will test the package and upload it. At least I will know
whether it is still useful.

Thanks for your patch!

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#711469: Can we have libslapi-dev back please:

[Florian Schlichting]

Hi Ryan,

On Mon, Nov 12, 2018 at 08:18:07AM -0800, Ryan Tandy wrote:
> As I understand, you are already using the proposed patch (re-adding
> slapi-dev) in your own builds? If you're confident the built package works,
> you are welcome to NMU (or team-upload :-)) the addition.

yes I am building and using the slapi-dev package, and I'm confident
that "it works". It is quite trivial really, consisting only of a single
ASCII file copied verbatim from the openldap source package, and a
symlink. Quoting from the build log:

slapi-dev_2.4.44+dfsg-5+deb9u2_amd64.deb


 new debian package, version 2.0.
 size 86504 bytes: control archive=639 bytes.
 539 bytes,14 lines  control  
 278 bytes, 4 lines  md5sums  
 Package: slapi-dev
 Source: openldap
 Version: 2.4.44+dfsg-5+deb9u2
 Architecture: amd64
 Maintainer: Debian OpenLDAP Maintainers 

 Installed-Size: 138
 Depends: slapd (= 2.4.44+dfsg-5+deb9u2)
 Section: libdevel
 Priority: optional
 Homepage: http://www.openldap.org/
 Description: OpenLDAP SLAPI plugin interface development headers
  This package allows development of plugins for the OpenLDAP slapd server
  using the SLAPI interface. It includes the headers and libraries needed
  to build such plugins.

drwxr-xr-x root/root 0 2018-05-23 04:25 ./
drwxr-xr-x root/root 0 2018-05-23 04:25 ./usr/
drwxr-xr-x root/root 0 2018-05-23 04:25 ./usr/include/
-rw-r--r-- root/root 38351 2018-05-23 04:25 ./usr/include/slapi-plugin.h
drwxr-xr-x root/root 0 2018-05-23 04:25 ./usr/lib/
drwxr-xr-x root/root 0 2018-05-23 04:25 ./usr/lib/x86_64-linux-gnu/
lrwxrwxrwx root/root 0 2018-05-23 04:25 
./usr/lib/x86_64-linux-gnu/libslapi.so -> libslapi-2.4.so.2.10.7
drwxr-xr-x root/root 0 2018-05-23 04:25 ./usr/share/
drwxr-xr-x root/root 0 2018-05-23 04:25 ./usr/share/doc/
drwxr-xr-x root/root 0 2018-05-23 04:25 ./usr/share/doc/slapi-dev/
-rw-r--r-- root/root 46965 2018-05-23 04:25 
./usr/share/doc/slapi-dev/changelog.Debian.gz
-rw-r--r-- root/root 23853 2016-02-05 23:57 
./usr/share/doc/slapi-dev/changelog.gz
-rw-r--r-- root/root 20216 2018-05-23 04:25 
./usr/share/doc/slapi-dev/copyright


(and yes, the plugin that we build with this header builds successfully,
and works - but that's beyond the scope of openldap packaging, IMHO)

> The things I would want do before uploading myself are:
> 
> - figure out what the "discussion with ftp-master" referenced in the
> 2.4.7-2 changelog was about and determine whether further follow-up is
> needed;

I think this refers to FTP masters pushing back against "trivial"
packages that only contain a few small files, where they felt the burden
on the ftpmaster and mirror infrastructure was disproportionate compared
to the benefit users might enjoy by not needing to install certain
packages. I'm not sure how big an issue this was a decade ago, but I
don't think it plays a role nowadays.

Building a new binary package does send the upload to NEW though, so I
don't think this is something to do in an NMU (and btw I'm not the
person who wrote our plugin and won't be of much help beyond packaging
questions)

> - check for file collisions with other packages (389-ds uses slapi, I'm  not
> sure whether public headers/libs are installed); and

$ apt-file search slapi-plugin.h
389-ds-base-dev: /usr/include/dirsrv/slapi-plugin.h
slapi-dev: /usr/include/slapi-plugin.h

> - build and test some kind of example SLAPI module to convince myself  the
> slapi-dev package is functional.
> 
> (hmm, shouldn't the package properly be called libslapi-dev?)

Steve's changelog entry says

  * Split slapi dev support into a new libslapi-dev package, as this is
unrelated to libldap; and drop libslapi.a since it would be insane to try
to statically link a dynamically-loaded slapi plugin.

but then there's commit 06777b964 renaming debian/libslapi-dev.install
to debian/slapi-dev.install: "be a bit more consistent about the package
name, so it can actually find its files..." - it seems in debian/control
it was always named slapi-dev?

Florian

Bug#913674: release.debian.org: Regression: Recent upgrade of opensc breaks Yubikey NEO support

[Hilko Bengen]

Package: release.debian.org
Severity: grave
Tags: stretch

A few weeks ago I reported that a security patch in
opensc/0.16.0-3+deb9u1 broke support for Yubkey NEO devices (#910786,
severity serious). Unfortunately, this did not prevent opensc from being
included in the recent stretch point release. What can we do to fix the
package now?

Cheers,
-Hilko

Bug#913673: broadcom-sta-dkms: Building module for kernel 4.18.0-0.bpo.1-amd64 fails

[mdrouet]

Package: broadcom-sta-dkms
Version: 6.30.223.271-5
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I'm on debian stretch. I've updated my systeme with apt update and apt -t
stretch-backports

   * What was the outcome of this action?
When I rebooted, I have no wifi anymore.

I tried to delete the package and to re-install it. Here is what I got:
Building initial module for 4.18.0-0.bpo.1-amd64
Error! Bad return status for module build on kernel: 4.18.0-0.bpo.1-amd64
(x86_64)
Consult /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log for more
information.

# cat /var/lib/dkms/broadcom-sta/6.30.223.271/build/make.log
DKMS make.log for broadcom-sta-6.30.223.271 for kernel 4.18.0-0.bpo.1-amd64
(x86_64)
mardi 13 novembre 2018, 21:24:13 (UTC+0100)
/bin/sh: 1: [: Illegal number:
/bin/sh: 1: [: Illegal number:
Wireless Extension is the only possible API for this kernel version
Using Wireless Extension API
KBUILD_NOPEDANTIC=1 make -C /lib/modules/4.18.0-0.bpo.1-amd64/build M=`pwd`
make[1]: avertissement : jobserver n'est pas disponible : utilisation de -j1.
Ajouter « + » à la règle parent du make.
make[1] : on entre dans le répertoire « /usr/src/linux-
headers-4.18.0-0.bpo.1-amd64 »
CFG80211 API is prefered for this kernel version
Using CFG80211 API
Kernel architecture is X86_64
  CC [M]  /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.o
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c: In
function ‘osl_os_get_image_block’:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:1083:26:
warning: passing argument 2 of ‘kernel_read’ makes pointer from integer without
a cast [-Wint-conversion]
  rdlen = kernel_read(fp, fp->f_pos, buf, len);
  ^~
In file included from /usr/src/linux-
headers-4.18.0-0.bpo.1-common/include/linux/huge_mm.h:7:0,
 from /usr/src/linux-
headers-4.18.0-0.bpo.1-common/include/linux/mm.h:503,
 from /var/lib/dkms/broadcom-
sta/6.30.223.271/build/src/include/linuxver.h:65,
 from /var/lib/dkms/broadcom-
sta/6.30.223.271/build/src/shared/linux_osl.c:25:
/usr/src/linux-headers-4.18.0-0.bpo.1-common/include/linux/fs.h:2875:16: note:
expected ‘void *’ but argument is of type ‘loff_t {aka long long int}’
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
^~~
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:1083:37:
warning: passing argument 3 of ‘kernel_read’ makes integer from pointer without
a cast [-Wint-conversion]
  rdlen = kernel_read(fp, fp->f_pos, buf, len);
 ^~~
In file included from /usr/src/linux-
headers-4.18.0-0.bpo.1-common/include/linux/huge_mm.h:7:0,
 from /usr/src/linux-
headers-4.18.0-0.bpo.1-common/include/linux/mm.h:503,
 from /var/lib/dkms/broadcom-
sta/6.30.223.271/build/src/include/linuxver.h:65,
 from /var/lib/dkms/broadcom-
sta/6.30.223.271/build/src/shared/linux_osl.c:25:
/usr/src/linux-headers-4.18.0-0.bpo.1-common/include/linux/fs.h:2875:16: note:
expected ‘size_t {aka long unsigned int}’ but argument is of type ‘char *’
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
^~~
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.c:1083:42:
warning: passing argument 4 of ‘kernel_read’ makes pointer from integer without
a cast [-Wint-conversion]
  rdlen = kernel_read(fp, fp->f_pos, buf, len);
  ^~~
In file included from /usr/src/linux-
headers-4.18.0-0.bpo.1-common/include/linux/huge_mm.h:7:0,
 from /usr/src/linux-
headers-4.18.0-0.bpo.1-common/include/linux/mm.h:503,
 from /var/lib/dkms/broadcom-
sta/6.30.223.271/build/src/include/linuxver.h:65,
 from /var/lib/dkms/broadcom-
sta/6.30.223.271/build/src/shared/linux_osl.c:25:
/usr/src/linux-headers-4.18.0-0.bpo.1-common/include/linux/fs.h:2875:16: note:
expected ‘loff_t * {aka long long int *}’ but argument is of type ‘int’
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
^~~
  CC [M]  /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.o
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In
function ‘wl_pci_probe’:
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:774:2:
warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
  if ((val & 0xff00) != 0)
  ^~
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:776:3:
note: ...this statement, but the latter is misleadingly indented as if it is
guarded by the ‘if’
   bar1_size = pci_resource_len(pdev, 2);
   ^
/var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In
function ‘wl_init_timer’:
/var/lib/dkms/broadcom-st

Bug#912862: Please provide libgap.la

[Bill Allombert]

On Sun, Nov 11, 2018 at 03:00:47PM +0100, Tobias Hansen wrote:

> > autopkgtest for gap-float/0.9.1+ds-1: amd64: Regression ♻
> > autopkgtest for gap-guava/3.13+ds-2: amd64: Regression ♻
> > autopkgtest for gap-io/4.5.1+ds-1: amd64: Regression ♻
> > autopkgtest for gap-laguna/3.7.0+ds-1: amd64: Regression ♻
> > autopkgtest for gap-scscp/2.1.4+ds-3: amd64: Regression ♻
> > autopkgtest for gap-sonata/2.8+ds-1: amd64: Regression ♻
> >
> > Do you understand what happen ?
> >
> > Cheers,
> 
> 
> I think most of them are actually fine. The failing tests are mostly
> with the versions in testing, so if the packages can migrate together
> with gap, the test failure should not matter. However gap-sonata was
> not updated and some packages are waiting for gap-smallgrp to migrate
> to testing.

Well it seems gap-sonata needs to be updated. The version in testing
is the same as the version in unstable and the test fails. Maybe
a RC bug against sonata would speed up the transition.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#913672: Sudden black screen when playing video files

[Shivani Singh]

Package: Gnome

Version: 3.22.2

Random black sreen appearing, without labtop switching off, whenever
playing, pausing, opening or skipping video files on Debian 4.9.0.8. Black
screen does not disapear unless you reboot the labtop, by holding down
power button. When rebooting the error message is "Clearing orphaned inode"
followed by a number. I am using Debian GNU/Linux 9 (stretch) 64-bit.

Bug#898795: it might be a good idea to use node-normalize.css as it already is used by libreoffice

[shirish शिरीष]

Dear all,

Saw  the following -

$ dpkg -L node-normalize.css
/.
/usr
/usr/lib
/usr/lib/nodejs
/usr/lib/nodejs/normalize.css
/usr/lib/nodejs/normalize.css/normalize.css
/usr/lib/nodejs/normalize.css/package.json
/usr/share
/usr/share/doc
/usr/share/doc/node-normalize.css
/usr/share/doc/node-normalize.css/README.md
/usr/share/doc/node-normalize.css/changelog.Debian.gz
/usr/share/doc/node-normalize.css/changelog.gz
/usr/share/doc/node-normalize.css/copyright
/usr/share/doc/node-normalize.css/examples
/usr/share/doc/node-normalize.css/examples/test.html
/usr/share/doc/node-normalize.css/examples/test.svg
/usr/share/javascript
/usr/share/javascript/normalize.css
/usr/share/javascript/normalize.css/normalize.min.css
/usr/share/javascript/normalize.css/normalize.css


$ aptitude why node-normalize.css
i   task-mate-desktop   Recommends libreoffice-help-en-us
i A libreoffice-help-en-us  Dependslibreoffice-help-common (= 1:6.1.3-1)
i A libreoffice-help-common Dependslibjs-normalize.css
i A node-normalize.css  Provides   libjs-normalize.css

So it anyways is there so we might as well as use that and save a bit
on resources instead of running a second copy of the same thing.

Unless of course there is something more the embedded version provides
which the shared library cannot provide.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#913271: segfault - broken rust compiling

[Sylvestre Ledru]

forwarded 913271 https://bugs.llvm.org/show_bug.cgi?id=39427
thanks

Hello,

Le 13/11/2018 à 21:05, Josh Stone a écrit :
> There's an ABI incompatibility between LLVM compiled with GCC and Clang:
> https://bugs.llvm.org/show_bug.cgi?id=39427
>
> So if you have a Clang-built libLLVM.so, and rustc's src/rustllvm is
> built with GCC, then I think you may be hitting this problem.
>
well spoted, thanks :)

S

Bug#871806: #871806: check git tag signatures

[Xavier]

Le 13/11/2018 à 20:39, Daniel Kahn Gillmor a écrit :
> Hi Xavier--

Hi Daniel

> On Tue 2018-09-25 23:45:18 +0200, Xavier wrote:
>> I just implement a git-tag-signature-verify feature [1] to fix #827065:
>> just to add "pgpmode=gittag" in opts.
>> I think it fixes this issue too. If you agree, I'll merge it.
> 
> Thanks for this!  I finally got around to testing out your changes, and
> i really like them.  I'll be adopting this on all of my packages where
> upstream prefers signed git tags as a release mechanism.

Thanks ;-)

Note that if there is a "git origin" that points to upstream repo, uscan
will use it instead of creating a temporary "git clone". It is more
efficient I think

> I've opened https://salsa.debian.org/debian/devscripts/merge_requests/82
> to clean up the git tag verification a little bit more :)

Thanks, I copied old uscan calls since the challenge was non-regression
after rewriting. Time to improve now!

> The one thing that's missing to close #871806 is the extraction of a git
> tag that can be shipped with (and verified against) debian source
> tarballs, though.  We currently do ship .asc files that correspond to
> signatures over the tarball.
> 
> Do you see a way that we could ship something that would let a
> verification happen from just what we ship in debian based on signatures
> extracted from the git tag?

Unfortunately no. Git signatures are not linked to the archive itself
but only to the tag. I don't see any way to link an extracted archive to
this sort of .asc

Cheers,
Xavier



signature.asc
Description: OpenPGP digital signature

Bug#913664: Does not integrate with firewalld, will be broken when nftables backend is used

[Michael Biebl]

Am 13.11.18 um 22:04 schrieb Dmitry Smirnov:
> On Wednesday, 14 November 2018 6:38:05 AM AEDT Michael Biebl wrote:
>> firewalld switched its default backend from iptables to nftables
>> recently [1]. Unfortunately, this caused issues with libvirt and as
>> reported in [2], also docker. I don't use docker myself, so I'm only
>> relaying this information.
>> The main problem seems to be, that currently there is no integration
>> between docker and firewalld. Both manage firewall rules on their own.
>> As soon as nftables(firewalld) and iptables(docker) are mixed, the
>> result is a broken network setup.
>> Please consider forwarding this issue upstream. Best is probably if
>> docker upstream get's in touch with firewalld upstream to figure a
>> solution.
> 
> Docker is not great on cooperation (to say the least) and they are perfectly 
> happy with Docker managing iptables in the way that's incompatible with 
> everything else. Even trivial bugs like #903635 are practically neglected by 
> upstream. I have little confidence in upstream motivation to work on this 
> issue...

Thanks for your feedback, Dmitry.

For clarification: I patched firewalld downstream in Debian to default
to iptables for now. That said, I would like to / plan to drop this
patch again in buster+1.

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature

Bug#913552: firehol: Firehol upgrade 3.1.6+ds-4 to 3.1.6+ds-5 leaves firehol broken

[Jerome BENOIT]

On 13/11/2018 16:33, Jerome BENOIT wrote:
> 
> 
> On 13/11/2018 16:23, Russel Winder wrote:
>>
>>> It does not look as a solution anyway.
>>> And the issue does not seem to be a FireHOL issue.
>>> I guess that we have to stick to package 3.1.6+ds-4 for a while.
>>
>> I've held all but one machine on 3.1.6+ds-4 but now need to revert the one
>> test machine.  Aptitude is telling me there is only 3.1.6+ds-5. Can this
>> version be removed from the repository and 3.1.6+ds-4 reinstated, or do I 
>> just
>> have to manually grab the packages and install them?
> 
> It is a building environment issue: I would build the debian package from 
> source,
> and them install it.
> 
> I have just submitted the issue to the debian-devel debian list (I CCed to 
> you).
> As temporary solution, I can submit a package built from a local chroot 
> environment.

I have just ask for suggestions to the upstream maintainer.

Jerome

> 
> Jerome
> 
> 
>>
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#913664: Does not integrate with firewalld, will be broken when nftables backend is used

[Dmitry Smirnov]

On Wednesday, 14 November 2018 6:38:05 AM AEDT Michael Biebl wrote:
> firewalld switched its default backend from iptables to nftables
> recently [1]. Unfortunately, this caused issues with libvirt and as
> reported in [2], also docker. I don't use docker myself, so I'm only
> relaying this information.
> The main problem seems to be, that currently there is no integration
> between docker and firewalld. Both manage firewall rules on their own.
> As soon as nftables(firewalld) and iptables(docker) are mixed, the
> result is a broken network setup.
> Please consider forwarding this issue upstream. Best is probably if
> docker upstream get's in touch with firewalld upstream to figure a
> solution.

Docker is not great on cooperation (to say the least) and they are perfectly 
happy with Docker managing iptables in the way that's incompatible with 
everything else. Even trivial bugs like #903635 are practically neglected by 
upstream. I have little confidence in upstream motivation to work on this 
issue...

-- 
Cheers,
 Dmitry Smirnov.

---


Democracy is a pathetic belief in the collective wisdom of individual
ignorance.
-- H. L. Mencken


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

Bug#913671: ITP: minetest-mod-basic-materials

[Julien Puydt]

Package: wnpp
Severity: wishlist

* Package name: minetest-mod-basic-materials
  Version : 20181109.2
  Upstream Author : Vanessa Ezekowitz
* URL : https://gitlab.com/VanessaE/basic_materials
* License : LGPL-3, CC-BY-SA-4.0
  Programming Lang: lua
  Description : Minetest mod providing basic materials and items
 This game extension provides various materials (different metals,
 plastic) and items (wires, strips, ingots, chainlinks, gears, padlocks,
 etc).


 I plan to maintain it within the Debian Games Team, with my other 
minetest-related packages ; in fact it is a new dep of 
minetest-mod-homedecor.


Cheers,

jpuydt on irc.debian.org

Bug#871806: #871806: check git tag signatures

[Daniel Kahn Gillmor]

Hi Xavier--

On Tue 2018-09-25 23:45:18 +0200, Xavier wrote:
> I just implement a git-tag-signature-verify feature [1] to fix #827065:
> just to add "pgpmode=gittag" in opts.
> I think it fixes this issue too. If you agree, I'll merge it.

Thanks for this!  I finally got around to testing out your changes, and
i really like them.  I'll be adopting this on all of my packages where
upstream prefers signed git tags as a release mechanism.

I've opened https://salsa.debian.org/debian/devscripts/merge_requests/82
to clean up the git tag verification a little bit more :)

The one thing that's missing to close #871806 is the extraction of a git
tag that can be shipped with (and verified against) debian source
tarballs, though.  We currently do ship .asc files that correspond to
signatures over the tarball.

Do you see a way that we could ship something that would let a
verification happen from just what we ship in debian based on signatures
extracted from the git tag?

  --dkg


signature.asc
Description: PGP signature

Bug#913670: ITP: minetest-mod-currency -- Minetest mod providing shops and currency

[Julien Puydt]

Package: wnpp
Severity: wishlist

* Package name: minetest-mod-currency
  Version : 20181109
  Upstream Author : Vanessa Ezekowitz
* URL : https://gitlab.com/VanessaE/currency
* License : LGPL-3, CC-BY-SA-4.0
  Programming Lang: lua
  Description : Minetest mod providing shops and currency
 This minetest extension adds:
  - shops,
  - barter tables,
  - safes
  - and multiple denominations of currency.


 I plan to maintain it within the Debian Games Team, with my other 
minetest-related packages ; in fact it is a new dep of 
minetest-mod-homedecor.


Cheers,

jpuydt on irc.debian.org

Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Dmitry Bogatov]

[Adding systemd maintainers into thread]
(We are discussing #826214)

[2018-11-11 22:37] Michael Biebl 
> > #!/lib/init/init-d-script?
> 
> It doesn't work with #!/lib/init/init-d-script either.
> 
> Only
> 
> #!/bin/sh
> 
> if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
> set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
> fi
> 
> currently works wrt to systemctl redirection.

At least it does not feel magic. In case of #!/lib/init/init-d-script,
$0 = /lib/init/init-d-script; in case of sourcing $0 is path to script
(/etc/init.d/foo).

Now, issue seems to be /lib/lsb/init-functions.d/40-systemd from
bin:systemd. On line 7 we read:

prog=${0##*/}

As far as I know, there is no way to modify "$0". So we have two
options:

 * have systemd folks use `${__init_d_script_name##*/}' in
   `40-systemd' instead of `$0'

 * write wrapper in C, which sets $0 to value, expected by `40-systemd'.
   Actually, there is number of utilities floating around, which set $0
   to arbitrary value (`chpst' from bin:runit is one of them :)), but we
   do not want to add new dependency to essentail sysvinit-utils, don't
   we?

Opinions?

Bug#408954: checkroot.sh: should not skip running fsck with JFS root

[Dmitry Bogatov]

control: tags -1 confirmed

[2018-11-12 02:03] Adam Borowski 
> On Mon, Nov 12, 2018 at 01:20:25AM +0100, Adam Borowski wrote:
> > And JFS doesn't do the full check either, it merely apparently needs (or
> > more likely needed -- this report is 11¾ years old) only a trigger for the
> > journal replay.
> > 
> > So I propose:
> > 1. checking if JFS still needs this
> 
> Yes, it does.
> 
> So we still need fsck to boot, no matter if the computer is on battery or
> not.  So this bug is still valid.

Am I correct, that fsck (checkroot.sh) is actually needed only in case
of ext2 or jfs root?

Bug#913091: RFS: scdoc/1.5.2-1

[Dmitry Bogatov]

[2018-11-08 21:43] Birger Schacht 
> > Here is my review for commit (6b2f11).
> 
> Thanks for your feedback! I've adjusted the files accordingly, pushed
> dddbe9 to salsa and uploaded a new package to mentors.

Fine. Uploaded.

Let me suggest you to put tags like 'debian/1.5.2-1' after package hit
sid. Otherwise, if your sponsor or ftp-team ask you to make any changes,
you end with either wrong tag or tag rewriting.

Bug#913271: segfault - broken rust compiling

[Josh Stone]

There's an ABI incompatibility between LLVM compiled with GCC and Clang:
https://bugs.llvm.org/show_bug.cgi?id=39427

So if you have a Clang-built libLLVM.so, and rustc's src/rustllvm is
built with GCC, then I think you may be hitting this problem.

Bug#913669: ITP: python-cssselect2 -- implementation of CSS3 Selectors

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-cssselect2
  Version : 0.2.1
  Upstream Author : Simon Sapin 
* URL : https://github.com/Kozea/cssselect2/
* License : BSD-3-clause
  Programming Lang: Python
  Description : implementation of CSS3 Selectors

 cssselect2 is a straightforward implementation of CSS3 Selectors for markup
 documents (HTML, XML, etc.) that can be read by ElementTree-like parsers
 (including cElementTree, lxml, html5lib, etc.)
 .
 Unlike cssselect, it does not translate selectors to XPath and therefore does
 not have all the correctness corner cases that are hard or impossible to fix in
 cssselect.

 I intend to maintain this package as part of the DPMT and it is required by
 cairosvg 2.x.

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlvrLcoRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90Wq/Ogf8CvwyDxRgkRDvov3VK5AXK9EtPSQvQB6O
ESrjSzXab6ReFr9dNZFtTsrPoHdRn8HdHhR2XOPBqQDPbLDJj1dQGQofbkjXFlG7
+iOo8Xuyx+Tsa1+kA9qZNExi0MPtdt8sJR96WIJVii7Kh00S+gWSmX/Z6hUm/tCI
varBLkA4q7S7zPEs+0cNyI2ewHvofrma4j+IJHpYyrhULVCYjU1avDM/GLXh96Gu
dh7ZmWC8jvR90Ujkv/U3jQMiEHAtFER0bj7hlhwfTkRNB7X7Bb+SK4X9PdXcF8jj
FR3/DYGzv/5s2Y/QMVLwdKB9uvcqY4Zl7km1DtwgDnyyTUlQ1H9nTg==
=ni98
-END PGP SIGNATURE-

Bug#913668: collectd confuses build/host

[Helmut Grohne]

Source: collectd
Version: 5.8.0-5.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

I looked into cross building collectd and that turns out to be
difficult. However one thing became apparent quite quickly to me:
debian/rules confuses build and host. These terms are defined in man
dpkg-architecture. Furthermore, debian/rules tries to match everything
against the Debian architecture name, but there are better ways to match
e.g. the kernel. The attached patch fixes that. Please consider applying
it. Please also consider going beyond. For instance, a comment says
"These plugins are Intel-hardware specific.". If that is really the
case, then maybe use "ifeq (,$(filter amd64 i386,$(DEB_HOST_ARCH_CPU)))".
Doing so would additionally match kfreebsd-amd64, hurd-i386 and x32. I'm
not sure whether that's appropriate.

Before looking further into cross building collectd, I'll need to file a
patch for libvirt.

Helmut
diff --minimal -Nru collectd-5.8.0/debian/rules collectd-5.8.0/debian/rules
--- collectd-5.8.0/debian/rules	2018-08-06 20:36:32.0 +0200
+++ collectd-5.8.0/debian/rules	2018-11-13 06:09:53.0 +0100
@@ -8,9 +8,7 @@
 
 # These are used for cross-compiling and for saving the configure script
 # from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_ARCH  ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+include /usr/share/dpkg/architecture.mk
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
@@ -28,7 +26,7 @@
 
 # A PostgreSQL header redefines CACHE_LINE_SIZE on FreeBSD.
 # Cf. https://bugs.debian.org/760719 and https://bugs.debian.org/763098
-ifneq (,$(filter kfreebsd-i386 kfreebsd-amd64, $(DEB_BUILD_ARCH)))
+ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
 	CPPFLAGS += -Wp,-w
 endif
 
@@ -95,7 +93,7 @@
 confflags += --disable-varnish
 
 # These plugins are Linux-specific.
-ifneq (,$(filter kfreebsd-i386 kfreebsd-amd64, $(DEB_BUILD_ARCH)))
+ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
 	confflags += \
 		--disable-barometer \
 		--disable-cgroups \
@@ -117,7 +115,7 @@
 endif
 
 # This plugin is FreeBSD-specific.
-ifeq (,$(filter kfreebsd-i386 kfreebsd-amd64, $(DEB_BUILD_ARCH)))
+ifneq ($(DEB_HOST_ARCH_OS),kfreebsd)
 	confflags += \
 		--disable-pf
 endif
@@ -127,7 +125,7 @@
 		--disable-zone
 
 # These plugins have not been ported to FreeBSD yet.
-ifneq (,$(filter kfreebsd-i386 kfreebsd-amd64, $(DEB_BUILD_ARCH)))
+ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
 	# Work-around an incomplete check for kvm functionality
 	CPPFLAGS  += -DHAVE_STRUCT_KINFO_PROC_FREEBSD
 	confflags += --enable-processes=force
@@ -150,7 +148,7 @@
 endif
 
 # Build-dependencies of these plugins are (not yet) available for kfreebsd.
-ifneq (,$(filter kfreebsd-i386 kfreebsd-amd64, $(DEB_BUILD_ARCH)))
+ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
 	confflags += \
 		--disable-gmond \
 		--disable-virt \
@@ -159,7 +157,7 @@
 endif
 
 # These plugins are Intel-hardware specific.
-ifeq (,$(filter amd64 i386, $(DEB_BUILD_ARCH)))
+ifeq (,$(filter amd64 i386, $(DEB_HOST_ARCH)))
 	confflags += \
 		--disable-dpdkevents \
 		--disable-dpdkstat \
@@ -171,25 +169,25 @@
 endif
 
 # This plugin is x86 and arm specific.
-ifeq (,$(filter amd64 arm64 armhf i386, $(DEB_BUILD_ARCH)))
+ifeq (,$(filter amd64 arm64 armhf i386, $(DEB_HOST_ARCH)))
 	confflags += \
 		--disable-xencpu
 endif
 
 # libatasmart isn't available on these platforms.
-ifneq (,$(filter hurd-i386 kfreebsd-i386 kfreebsd-amd64, $(DEB_BUILD_ARCH)))
+ifneq (,$(filter hurd kfreebsd,$(DEB_HOST_ARCH_OS)))
 	confflags += --disable-smart
 endif
 
 # The hppa buildds currently do not keep up with Java related stuff, thus
 # prevending testing transitions. sparc is also having trouble building the
 # java plugin.
-ifneq (,$(filter hppa sparc, $(DEB_BUILD_ARCH)))
+ifneq (,$(filter hppa sparc, $(DEB_HOST_ARCH)))
 	confflags += --disable-java
 endif
 
 # gRPC is only available on x86, arm, ppc.
-ifeq (,$(filter amd64 arm64 armel armhf i386 ppc64el powerpc, $(DEB_BUILD_ARCH)))
+ifeq (,$(filter amd64 arm64 armel armhf i386 ppc64el powerpc, $(DEB_HOST_ARCH)))
 	confflags += --disable-grpc
 endif
 

Bug#913667: c-blosc breaks python-blosc autopkgtest: times out

[Paul Gevers]

Source: c-blosc, python-blosc
Control: found -1 c-blosc/1.14.4+ds1-1
Control: found -1 python-blosc/1.5.1+ds2-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update timeout

Dear maintainers,

With a recent upload of c-blosc the autopkgtest of python-blosc fails in
testing when that autopkgtest is run with the binary packages of c-blosc
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
c-bloscfrom testing1.14.4+ds1-1
python-blosc   from testing1.5.1+ds2-1
all others from testingfrom testing

The test times out after 5 and a half hours, while successful runs are
done in slightly over 1 minute. The last recorded thing before the time
out (in both python2 and python3 testing) is:
Doctest: blosc.toplevel.decompress ... Output buffer size should be
larger than 16 bytes

This string isn't present in successful runs.

Currently this regression is contributing to the delay of the migration
of c-blosc to testing [1]. Due to the nature of this issue, I filed this
bug report against both packages. Can you please investigate the
situation and reassign the bug to the right package? If needed, please
change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=c-blosc

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-blosc/1307149/log.gz




signature.asc
Description: OpenPGP digital signature

Bug#913666: gocryptfs: autopkgtest regression

[Paul Gevers]

Source: gocryptfs
Version: 1.6-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of gocryptfs the autopkgtest of gocryptfs fails in
testing when that autopkgtest is run with the binary packages of
gocryptfs from unstable. It yields a neutral result when run with only
packages from testing. In tabular form:
   pass/neutralfail
gocryptfs  from testing1.6-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gocryptfs

https://ci.debian.net/data/autopkgtest/testing/amd64/g/gocryptfs/1307199/log.gz

autopkgtest [05:25:27]: test gocryptfs-test: [---
/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/build.6eK/src/debian/tests/gocryptfs-test:
line 4: modprobe: command not found
cp: cannot stat 'obj/*': No such file or directory
cp: target
'/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/internal/'
is not a directory
cp: target
'/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/tests'
is not a directory
cp: cannot create regular file
'/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/':
No such file or directory
can't load package: package github.com/rfjakob/gocryptfs: cannot find
package "github.com/rfjakob/gocryptfs" in any of:
/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs (from $GOROOT)

/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs
 (from $GOPATH)
can't load package: package github.com/rfjakob/gocryptfs/gocryptfs-xray:
cannot find package "github.com/rfjakob/gocryptfs/gocryptfs-xray" in any of:
/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs/gocryptfs-xray (from
$GOROOT)

/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/gocryptfs-xray
 (from $GOPATH)
can't load package: package
github.com/rfjakob/gocryptfs/internal/configfile: cannot find package
"github.com/rfjakob/gocryptfs/internal/configfile" in any of:
/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs/internal/configfile
(from $GOROOT)

/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/internal/configfile
 (from $GOPATH)
can't load package: package
github.com/rfjakob/gocryptfs/internal/contentenc: cannot find package
"github.com/rfjakob/gocryptfs/internal/contentenc" in any of:
/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs/internal/contentenc
(from $GOROOT)

/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/internal/contentenc
 (from $GOPATH)
can't load package: package
github.com/rfjakob/gocryptfs/internal/cryptocore: cannot find package
"github.com/rfjakob/gocryptfs/internal/cryptocore" in any of:
/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs/internal/cryptocore
(from $GOROOT)

/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/internal/cryptocore
 (from $GOPATH)
can't load package: package
github.com/rfjakob/gocryptfs/internal/ctlsock: cannot find package
"github.com/rfjakob/gocryptfs/internal/ctlsock" in any of:
/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs/internal/ctlsock
(from $GOROOT)

/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/internal/ctlsock
 (from $GOPATH)
can't load package: package
github.com/rfjakob/gocryptfs/internal/exitcodes: cannot find package
"github.com/rfjakob/gocryptfs/internal/exitcodes" in any of:
/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs/internal/exitcodes
(from $GOROOT)

/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/internal/exitcodes
 (from $GOPATH)
can't load package: package
github.com/rfjakob/gocryptfs/internal/fusefrontend: cannot find package
"github.com/rfjakob/gocryptfs/internal/fusefrontend" in any of:
/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs/internal/fusefrontend
(from $GOROOT)

/tmp/autopkgtest-lxc.m4gtsp_3/downtmp/autopkgtest_tmp/obj/src/github.com/rfjakob/gocryptfs/internal/fusefrontend
 (from $GOPATH)
can't load package: package
github.com/rfjakob/gocryptfs/internal/fusefrontend_reverse: cannot find
package "github.com/rfjakob/gocryptfs/internal/fusefrontend_reverse" in
any of:

/usr/lib/go-1.10/src/github.com/rfjakob/gocryptfs/internal/fusefrontend_rev