Bug#803503: libfile-stripnondeterminism-perl: substr outside of string at /usr/share/perl5/File/StripNondeterminism/handlers/zip.pm

[Chris Lamb]

Hi Daniel,

> Yep, still there are messages on this (2.52b-4, just let the dh helper 
> run over the docs package):

So, why you `-Nafl-doc` instead of letting it print the warning
messages…?

Or, rather, are we corrupting the .png file here...? If not, we can
just silence this warning to close this issue, no? We can't trust
this header anyway...

Anyway, can confirm this and I am attaching the
docs/vuln_samples/msie-zlib-dos.png file for posterity:

   dh_strip_nondeterminism
Using 1540845961 as canonical time
[…]
debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/msie-zlib-dos.png: invalid 
length in '2,u' header at 
/usr/share/perl5/File/StripNondeterminism/handlers/png.pm line 130.
substr outside of string at 
/usr/share/perl5/File/StripNondeterminism/handlers/zip.pm line 155.
Use of uninitialized value in unpack at 
/usr/share/perl5/File/StripNondeterminism/handlers/zip.pm line 155.
IO error: reading local extra field :  
 at /usr/bin/dh_strip_nondeterminism line 90.
Can't write to /tmp/rHhftxVN2q.zip 
 at /usr/share/perl5/Archive/Zip/Archive.pm line 439.

Archive::Zip::Archive::overwrite(Archive::Zip::Archive=HASH(0x55d6b2580c40)) 
called at /usr/share/perl5/File/StripNondeterminism/handlers/zip.pm line 218

File::StripNondeterminism::handlers::zip::normalize("debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/unzip-t-mem"...)
 called at /usr/bin/dh_strip_nondeterminism line 90
eval {...} called at /usr/bin/dh_strip_nondeterminism line 90
[…]

As an aside, this made me check:

  
https://codesearch.debian.net/search?q=override_dh_strip_nondeterminism=1
 

:)


Regards,

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

Bug#912297: ansible: CVE-2018-16837

[Chris Lamb]

Hi Ivo,

> From the upstream changelog for 2.7.1+dfsg-1 (already in unstable):
[..]
> - user module - do not pass ssh_key_passphrase on cmdline
>   (CVE-2018-16837)

Thanks for providing this and no problem that this wasn't in the
changelog.

Security team: This still affects stretch and jessie as I unless
I'm missing something - would you like me to prepare an upload for
stable? I'm happy to take the LTS side of things.

(If so Ivo, can I push these to some VCS? I note it is in collab-
maint but I thought I might check...)


Best wishes,

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

Bug#912308: "-o" mount options in "tune2fs" is not being honoured by the OS.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: e2fsprogs
Version: 1.44.4-2

The mount options set in "e2fsprogs" are not being used by the OS, regardless 
whether there are corresponding entries in "/etc/fstab".
Here is my example:
===BEGIN OUTPUT===
root@AVENTHEIM:/u/h/root>tune2fs -l /dev/sda
tune2fs 1.44.4 (18-Aug-2018)
Filesystem volume name:   DEBIAN
Last mounted on:  /root
Filesystem UUID:  c5971091-77d2-40fe-9095-54bb0ff96a2c
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal ext_attr dir_index sparse_super2 
needs_recovery extent flex_bg inline_data large_file uninit_bg
Filesystem flags: signed_directory_hash
Default mount options:discard
Filesystem state: clean
Errors behavior:  Remount read-only
Filesystem OS type:   Linux
Inode count:  228960
Block count:  117220824
Reserved block count: 0
Free blocks:  107372244
Free inodes:  130667
First block:  1
Block size:   1024
Fragment size:1024
Blocks per group: 8192
Fragments per group:  8192
Inodes per group: 16
Inode blocks per group:   4
Flex block group size:16
Filesystem created:   Wed Oct 17 19:58:28 2018
Last mount time:  Tue Oct 30 08:04:00 2018
Last write time:  Tue Oct 30 08:04:00 2018
Mount count:  3
Maximum mount count:  -1
Last checked: Mon Oct 29 08:13:17 2018
Check interval:   0 ()
Lifetime writes:  267 GB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Required extra isize: 32
Desired extra isize:  32
Journal inode:8
First orphan inode:   163356
Default directory hash:   legacy
Directory Hash Seed:  a4bd0a95-469a-48ff-8d9e-c1a3e4674ec8
Journal backup:   inode blocks
root@AVENTHEIM:/u/h/root>mount |grep /dev/sda
/dev/sda on / type ext4 (rw,relatime,lazytime)
root@AVENTHEIM:/u/h/root>cat /etc/fstab
/dev/block/8:0 / ext4 lazytime 0 1
===END OUTPUT===
Note that "discard" is not in the mount parameters despite that I have set it 
in "tune2fs".
(It is an SSD and it supports TRIM. And yes, I do not partition it.)
Another example:
===BEGIN OUTPUT===
root@AVENTHEIM:/u/h/root>tune2fs -l /dev/sdc
tune2fs 1.44.4 (18-Aug-2018)
Filesystem volume name:   USERDATA
Last mounted on:  /run/mount/sdc
Filesystem UUID:  afb8ef7a-29bc-42fa-8d6b-970f5d91f45a
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal dir_index sparse_super2 needs_recovery 
extent flex_bg large_file uninit_bg
Filesystem flags: signed_directory_hash
Default mount options:bsdgroups uid16
Filesystem state: clean
Errors behavior:  Remount read-only
Filesystem OS type:   Linux
Inode count:  1907744
Block count:  1953506646
Reserved block count: 0
Free blocks:  1768323885
Free inodes:  1905162
First block:  0
Block size:   4096
Fragment size:4096
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 32
Inode blocks per group:   1
Flex block group size:16
Filesystem created:   Wed Oct 17 21:07:45 2018
Last mount time:  Tue Oct 30 08:04:37 2018
Last write time:  Tue Oct 30 08:04:37 2018
Mount count:  3
Maximum mount count:  -1
Last checked: Mon Oct 29 08:13:35 2018
Check interval:   0 ()
Lifetime writes:  1551 GB
Reserved blocks uid:  65534 (user nobody)
Reserved blocks gid:  65534 (group nogroup)
First inode:  11
Inode size:   128
Journal inode:8
Default directory hash:   legacy
Directory Hash Seed:  b99b9c29-ee43-423e-b4bd-0321c1f7d12a
Journal backup:   inode blocks
root@AVENTHEIM:/u/h/root>mount |grep /dev/sdc
/dev/sdc on /run/mount/sdc type ext4 
(rw,nosuid,nodev,relatime,resuid=65534,resgid=65534,user)
===END OUTPUT===
Again, the default options are not being honoured. I mounted it using "pmount 
-e" but it should not affect options like "bsdgroups" and "uid16". Also, it is 
not in "/etc/fstab".
--
Please reply to this e-mail with UTF8-encoded plain text.
You are as malicious as any other spammer if you send HTML e-mails.

-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAQBQJb19LBCRDYtWA5RV10HwAAhccIALRLrZ/EglI5VSThTNSP
yGnd/95GV5gOMEFhTW1kcKp1zReC06Ja6IFzBWQrMZsksl9dpseFEZqUjvcn
J+/h5lGLNPTjO7D4Aujqpyh+qxKq9UIfSnBAeSDaojT9i8nl5vGHfs/rRWhf
adML2703nJQjuNgLP/SThuQJQqAOk3vXCLhlp7whA1zH57h5yIO99QuUMRKT
T2P04ZhhIf/2ljJng0DJ73nPtW0gunIJcmoHLUEjMIQv7SigEzVg1TZt8qQm
In08fCK289CG6Dde1lNRQjqqcC+Kj3Og1KtXCC08ekBsuoSedrvvztqyrHKv
eZF1VFoqeci3uKq0K0fW22k=
=uB8a
-END PGP SIGNATURE-

Bug#912307: elementtidy: Will package maintenance be continued?

[Boyuan Yang]

Source: elementtidy
Version: 1.0-8
Severity: important
X-Debbugs-CC: shlo...@debian.org

Dear elementtidy maintainers,

I found that elementtidy hasn't seen any maintainer upload since 2008
(!) and there's no team upload since 2015. It seems that upstream
development stalled since 2005 too. Package python-elementtidy is
python2-only and it also has no reverse dependencies. The popcon is
also dropping.

As a result, I'm wondering if it's still worthwhile to keep elementtidy
in Debian archive anymore. Specifically I'd like to hear from the
package uploader (Torsten Marek) for your idea. If we are to keep it in
Debian Buster, I'm also wondering if it's okay for me to make a NMU
before Buster freeze to clean up legacy packaging instructions and
migrate VCS repo onto Salsa. Any ideas or help would be appreciated.

Thanks,
Boyuan yang


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

Bug#909635:

[Frank Wu]

I tested with "70.0.3538.67-1", it can successfully startup on Debian 9
Stretch.
But would need lots of package upgrade, is there has the plan to let Debian
9 Stretch have v70 in the future?
Thanks.

BR,
Frank Wu

Bug#902036: pygame FTBFS on s390x, testsuite failure.

[peter green]

found 902036 1.9.4.post1+dfsg-1
tags 902036 +patch
thanks


On 30/10/18 02:03, peter green wrote:


Unfortunately while the 1.9.4.post1+dfsg-1 upload fixed the ppc64el failure, it 
did not fix the s390x failure.

I just took a look at this, turned out to be a typo in a #if causing a 32-bit 
value to be written to a 64-bit variable. The variable was initialized to zero 
earlier, so we got away with this on little endian 64-bit but on big endian 
64-bit it resulted in the value being 4294967296 times larger than it should be 
which resulted in an out of range error.

Debdiff attached, no immediate intent to NMU.
diff -Nru pygame-1.9.4.post1+dfsg/debian/changelog 
pygame-1.9.4.post1+dfsg/debian/changelog
--- pygame-1.9.4.post1+dfsg/debian/changelog2018-10-28 13:09:16.0 
+
+++ pygame-1.9.4.post1+dfsg/debian/changelog2018-10-30 03:03:07.0 
+
@@ -1,3 +1,10 @@
+pygame (1.9.4.post1+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix a typo that breaks bufferproxy on 64-bit big endian.
+
+ -- Peter Michael Green   Tue, 30 Oct 2018 03:03:07 +
+
 pygame (1.9.4.post1+dfsg-1) unstable; urgency=high
 
   [ Ondřej Nový ]
diff -Nru pygame-1.9.4.post1+dfsg/debian/patches/fix-bufferproxy-be64.patch 
pygame-1.9.4.post1+dfsg/debian/patches/fix-bufferproxy-be64.patch
--- pygame-1.9.4.post1+dfsg/debian/patches/fix-bufferproxy-be64.patch   
1970-01-01 00:00:00.0 +
+++ pygame-1.9.4.post1+dfsg/debian/patches/fix-bufferproxy-be64.patch   
2018-10-30 03:03:07.0 +
@@ -0,0 +1,22 @@
+Description: Fix a typo that breaks bufferproxy on 64-bit big endian.
+ A typo in a #if caused a wrong definition of ARG_FORMAT to be used
+ leading to reading a 32-bit value into a 64-bit variable on 64 bit
+ systems.
+ 
+ On little endian we got away with this because the 64-bit value is
+ initialised to zero. However on big endian this resulted in a value
+ 4294967296 times larger than it should be which resulted in an out
+ of range error.
+Author: Peter Michael Green 
+
+--- pygame-1.9.4.post1+dfsg.orig/src/bufferproxy.c
 pygame-1.9.4.post1+dfsg/src/bufferproxy.c
+@@ -479,7 +479,7 @@ proxy_write(PgBufproxyObject *self, PyOb
+ Py_ssize_t offset = 0;
+ char *keywords[] = {"buffer", "offset", 0};
+ 
+-#if Py_VERSION_HEX >= 0x0205
++#if PY_VERSION_HEX >= 0x0205
+ #define ARG_FORMAT "s#|n"
+ #else
+ #define ARG_FORMAT "s#|i"  /* In this case Py_ssize_t is an int */
diff -Nru pygame-1.9.4.post1+dfsg/debian/patches/series 
pygame-1.9.4.post1+dfsg/debian/patches/series
--- pygame-1.9.4.post1+dfsg/debian/patches/series   2018-10-28 
13:09:16.0 +
+++ pygame-1.9.4.post1+dfsg/debian/patches/series   2018-10-30 
03:03:07.0 +
@@ -5,3 +5,4 @@
 arithmetic_fixes.patch
 fix_sphinx_unicode.patch
 skip_flaky_tests_on_le.patch
+fix-bufferproxy-be64.patch

Bug#912306: ITS: efitools

[Arnaud Rebillout]

Package: efitools
Version: 1.4.2-2+b1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

  Dear Maintainer,

It seems that this package is not maintained anymore.

The version currently package, 1.4.2, was released by upstream in
October 2013, that's 5 years ago. [1]

A bug was opened in May 2016, asking to package a new upstream version.
This bug was not answered so far. [2]

I myself opened a bug in June 2018, and submitted a debdiff of a new
version of the package, and there's been no answer. [3]

I also e-mailed the maintainer privately, but I didn't receive any
reply.

Therefore I would like to "salvage" this package. I would like to
handover the maintenance of this package to the Debian EFI Team [4],
which already maintains a bunch of EFI related packages. Then I will
request to join the EFI Team and help maintaining this package through
the team.

Best regards,

  Arnaud

- 

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tag/?h=v1.4.2
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823751
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900889
[4]: https://salsa.debian.org/efi-team


-BEGIN PGP SIGNATURE-

iQJTBAEBCgA9FiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAlvXzbgfHGFybmF1ZC5y
ZWJpbGxvdXRAY29sbGFib3JhLmNvbQAKCRDnJeh5FGACFkG1D/4q2NZlsq0OhHIv
2yTQAdB2P2V98Clr8tD/otKfbrqz+KZP9A6YGaT8MRCNiIXTYKBqfAYCzf0BxJw8
nYWnx8jOgZ+PVqLtUnyu3NTSQ4TB0jIw4uAVKSBYECsL8SBd9icMDy/mYL8yWnRj
meXw8gr/O2TPc0ljaMPMUICptSoxO+2RcyAekNl92mUTq6FXzK7A3MUSMl6Inpve
nHh2ejgJvaxgcm6Tb3eO2GVc9CeE79Equj6j3tAFeEFqA0qqWbTLEDm6N38bxaAm
q2qo2lbWyM9t7v3f3WOslJGwoQ0k+NweiXLyQYRreMGyN/zD6OcLJ2hKpO94d7ZJ
8ThbIBATrjZRl4uScPEpW53NMipedfiPnJNMLPXNGuIPKfXSCl71ulCJnfsfdcdL
Y/3sriHnXuP5bxP1av7w8NH4Qu3LwxQDpQF+w+a8/5OWPtJ5KtU0CC2VIwfuwUTz
rwHQk/8N4aRJ1/1I/vd3RXVKt3YqztQceSdsv01Bse1kGiUTEQEXX8fW8QnuAA9u
exxLQd6zjyVZBn7F5vMI0ugtx66Hq7Tu7P/24G1XG/XmFC+6hSYIb3y8CP16k8i7
j6D+H8kj1nyzChYGA693Hocf6c6tgHAgyZokvUvaFykG7R5oKPyuT33il2X+YDih
Y+lowPOrhPqz+r91RR1qsdswOkn4Ww==
=usNU
-END PGP SIGNATURE-

Bug#911575: Two ITPs for different packages named bitfield

[Andrew Donnellan]

On Sun, 28 Oct 2018 at 02:51, Adrian Bunk  wrote:
>
> Hi Vitalie, hi Andrew,
>
> you both have submitted ITPs for different packages named bitfield.
>
> This is a conflict that has to be resolved.
>
> IMHO the name "bitfield" is too generic for both packages.

I'm happy to rename mine to "bitfield-decoder" or something like that.

-- 
Andrew Donnellan
http://andrew.donnellan.id.au and...@donnellan.id.au

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Michael Biebl]

On Tue, 30 Oct 2018 01:18:08 +0100 Sebastian Andrzej Siewior
 wrote:
> Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to
> /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment
> the entropy count after it was written. Those two are documented in
> random(4). Or RNDRESEEDCRNG could be used to force crng to be reseeded.
> It does also the job, too.
> 
> Ted, is there any best practise what to do with the seed which as
> extrected from /dev/urandom on system shutdown? Using RNDADDTOENTCNT to
> speed up init or just write to back to urandom and issue RNDRESEEDCRNG?

Sebastian, if you have more insight on this matter, please followup on
https://github.com/systemd/systemd/issues/4271

What systemd-random-seed currently does is more or less the same what
the old /etc/init.d/urandom init script did.

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#902036: pygame FTBFS on s390x, testsuite failure.

[peter green]

found 902036 1.9.4.post1+dfsg-1
thanks

Unfortunately while the 1.9.4.post1+dfsg-1 upload fixed the ppc64el failure, it 
did not fix the s390x failure.

Bug#912305: ITP: unrardll -- Python wrapper for the unrar shared library

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Norbert Preining 

* Package name: unrardll
  Version : 0.1.3
  Upstream Author : Kovid Goyal 
* URL : https://github.com/kovidgoyal/unrardll
* License : BSD type
  Programming Lang: Python
  Description : Python wrapper for the unrar shared library

Python library that provides access to libunrar

going to nonfree because it depends on libunrar4 which is from nonfree.

Suggested by Calibre to allow reading cbz/cbr (comic files) which
are rar packed.

Bug#912304: Also needed kio-extras...

[Charles Huber]

Looks like I also needed 'kio-extras' proper, not just 'kio-extras-data'.

Bug#912219: lintian-brush: Missing dependency on python3-dulwich, and more

[Jelmer Vernooij]

On Mon, Oct 29, 2018 at 01:34:23PM +0100, gregor herrmann wrote:
> Thanks for writing lintian-brush, this looks really helpful. But
> currently it has its quirks:
Thanks for the detailed bug report, much appreciated. I hope to fix
most of these issues in the upcoming upload.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#912304: dolphin: Missing thumbnails/previews without kio-extras-data

[Charles Huber]

Package: dolphin
Version: 4:18.08.0-1
Severity: normal

Dear Maintainer,

2-3 months ago thumbnails/previews were working fine (images had thumbnails, 
videos had thumbnails, etc.) in Dolphin.

Then sometime in the past couple of weeks after the usual upgrade they 
just...stopped displaying.  The Preferences -> General -> Previews list was 
also empty.

Installing 'kio-extras-data' fixed the issue for me.


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

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

Versions of packages dolphin depends on:
ii  baloo-kf5  5.49.0-1+b1
ii  kinit  5.49.0-1
ii  kio5.49.0-1
ii  libc6  2.27-6
ii  libdolphinvcs5 4:18.08.0-1
ii  libkf5baloo5   5.49.0-1+b1
ii  libkf5baloowidgets54:18.08.1-1
ii  libkf5bookmarks5   5.49.0-1
ii  libkf5codecs5  5.49.0-1
ii  libkf5completion5  5.49.0-1
ii  libkf5configcore5  5.49.0-1
ii  libkf5configgui5   5.49.0-1
ii  libkf5configwidgets5   5.49.0-1
ii  libkf5coreaddons5  5.49.0-1
ii  libkf5crash5   5.49.0-1
ii  libkf5dbusaddons5  5.49.0-1
ii  libkf5filemetadata35.49.0-1
ii  libkf5i18n55.49.0-1
ii  libkf5iconthemes5  5.49.0-1
ii  libkf5itemviews5   5.49.0-1
ii  libkf5jobwidgets5  5.49.0-1
ii  libkf5kcmutils55.49.0-1
ii  libkf5kiocore5 5.49.0-1
ii  libkf5kiofilewidgets5  5.49.0-1
ii  libkf5kiowidgets5  5.49.0-1
ii  libkf5newstuff55.49.0-1
ii  libkf5notifications5   5.49.0-1
ii  libkf5parts5   5.49.0-1
ii  libkf5service-bin  5.49.0-1
ii  libkf5service5 5.49.0-1
ii  libkf5solid5   5.49.0-1
ii  libkf5textwidgets5 5.49.0-1
ii  libkf5widgetsaddons5   5.49.0-1
ii  libkf5xmlgui5  5.49.0-1+b1
ii  libphonon4qt5-44:4.10.1-1
ii  libqt5core5a   5.11.2+dfsg-3
ii  libqt5dbus55.11.2+dfsg-3
ii  libqt5gui5 5.11.2+dfsg-3
ii  libqt5widgets5 5.11.2+dfsg-3
ii  libqt5xml5 5.11.2+dfsg-3
ii  libstdc++6 8.2.0-8
ii  phonon4qt5 4:4.10.1-1

Versions of packages dolphin recommends:
ii  kimageformat-plugins  5.49.0-1
ii  kio-extras4:18.08.1-1
ii  ruby  1:2.5.1

Versions of packages dolphin suggests:
pn  dolphin-plugins  

-- no debconf information

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Sebastian Andrzej Siewior]

On 2018-10-29 23:33:34 [+0100], Kurt Roeckx wrote:
> On Mon, Oct 29, 2018 at 09:58:20PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> > > So I believe this is not an openssl issue, but something in the
> > > order that the kernel's RNG is initialized and openssh is started.
> > > Potentionally the RNG isn't initialized at all and you actually
> > > have to wait for the kernel to get it's random data from the slow
> > > way.
> > > 
> > > So I'm reassigning this to systemd and openssh-server, I have no
> > > idea where the problem really is.
> > 
> > I see it, too. So during boot someone invokes "sshd -t" which invokes
> 
> That's:
> ExecStartPre=/usr/sbin/sshd -t
> 
> > getrandom(, 32, 0)
> > and this blocks.
> 
> And did systemd-random-seed.service get run before that?

Yes, but it does not matter from what I can see in the code. On my
system this writes 512 to /dev/urandom at timestamp 11.670639. But sshd
does this:

  sshd-2638  [004] ...22.445819: __x64_sys_getrandom: 1| 32 0
sshd asks for 32 bytes (flags = 0)

  sshd-2638  [004] ...22.445824: __x64_sys_getrandom: 2
-> crng_ready() is not true so we wait_for_random_bytes()

  sshd-3164  [004] ...   117.577454: __x64_sys_getrandom: 3
-> "crng init done", sshd's getrandom() resumed.

The problem is that the entropy is added but the entropy count is not
increased. So we wait.

Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to
/dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment
the entropy count after it was written. Those two are documented in
random(4). Or RNDRESEEDCRNG could be used to force crng to be reseeded.
It does also the job, too.

Ted, is there any best practise what to do with the seed which as
extrected from /dev/urandom on system shutdown? Using RNDADDTOENTCNT to
speed up init or just write to back to urandom and issue RNDRESEEDCRNG?

> Kurt

Sebastian

Bug#912221: jabref: incompatible with openjdk 11

[Emmanuel Bourg]

Le 30/10/2018 à 00:41, gregor herrmann a écrit :

> I guess we need to make sure that we build with openjdk-8.
> (You know this better than me but I seem to remember that the plan
> was to keep openjdk-8 in buster for building packages?)

No please don't built with openjdk-8 if there is a workaround with
openjdk-11. Building with openjdk-8 is really a last resort solution,
and very few cases justify its use (see lombok for a good example).

Emmanuel Bourg

Bug#912303: RFA: libopenhmd

[Bálint Réczey]

Package: wnpp
Severity: normal
X-Debbugs-CC: debian-de...@lists.debian.org

Hi,

Due to trying to focus on other packages I'm looking for someone to
adopt this package.
It does not need a lot of attention and is in a good shape, I just did
not start the project I wanted to use it for.

Thanks,
Balint

Bug#911256: libopenhmd: Vcs metadata outdated

[Bálint Réczey]

Control: fixed -1 0.2.0-4

Hi Simon,

Simon McVittie  ezt írta (időpont: 2018. okt. 17., Sze, 20:15):
>
> Source: libopenhmd
> Version: 0.2.0-3
> Severity: minor
>
> libopenhmd's Vcs-* metadata is no longer valid since the shutdown of
> alioth.debian.org. A code-drop is available in
> .
>
> Since it was in the collab-maint group, I've assumed it's OK to
> import it into the equivalent Debian group on salsa.debian.org:
> . Please update the Vcs-*
> metadata to point there, or to any other location of your choice.

Thanks for the import!
I just uploaded the fix but forgot to close this bug, hence this email.

Cheers,
Balint

Bug#912302: RM: erlsvc -- ROM; low popcon

[Bálint Réczey]

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

Please remove src:erlsvc. Apparenty basically no one is using the
package, which would make the effort of migrating the packaging
repository to Salsa and updating the package itself worthless.

Thanks,
Balint

Bug#912193: [Pkg-samba-maint] Bug#912193: samba: Ignores UNIX groups

[Paul Szabo]

Sorry, my typo. I just wrote:

   ... and does seem to add those ...

but of course I meant to say:

   ... and does NOT seem to add those ...

Cheers, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#912221: jabref: incompatible with openjdk 11

[gregor herrmann]

On Mon, 29 Oct 2018 16:33:54 -0700, tony mancill wrote:

> On Mon, Oct 29, 2018 at 11:44:36PM +0100, Emmanuel Bourg wrote:
> > jabref should no longer use the java.se.ee module, it was a temporary
> > module in Java 9 & 10 now removed in Java 11. jabref should add jaxb to
> > its classpath instead.
> Thanks Emmanuel.  Yes, I was able to get things working during the bus
> ride in this morning, 

:)
Great, thanks Tony.

> just need to finish up the wrapper script logic
> so it can start on Java 8, 9, 10, > 10 without the user having to worry
> with it...

Awesome.
 
> I'll look at the FTBFS as well.

I guess we need to make sure that we build with openjdk-8.
(You know this better than me but I seem to remember that the plan
was to keep openjdk-8 in buster for building packages?)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Janis Joplin: Cry Baby (live)


signature.asc
Description: Digital Signature

Bug#912301: O: outguess -- universal steganographic tool

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: normal

I intend to orphan the outguess package.

The package description is:
 OutGuess is a universal tool for steganography that allows the insertion
 of hidden information into the redundant bits of data sources. The nature
 of the data source is irrelevant to the core of OutGuess.
 .
 The program relies on data specific handlers that will extract redundant
 bits and write them back after modification. The supported formats are
 JPEG, PPM and PNM.
 .
 This package is useful in forensics investigations and security actions.

---

The outguess is not building in all architectures. Please, see #909442,
caused by #882538.

Regards,

Eriberto

Bug#912221: jabref: incompatible with openjdk 11

[tony mancill]

On Mon, Oct 29, 2018 at 11:44:36PM +0100, Emmanuel Bourg wrote:
> Le 29/10/2018 à 13:54, gregor herrmann a écrit :
> 
> > Now that openjdk 11 is the default, jabref won't start without some
> > help:
> > 
> > % jabref
> > Error occurred during initialization of boot layer
> > java.lang.module.FindException: Module java.se.ee not found
> 
> jabref should no longer use the java.se.ee module, it was a temporary
> module in Java 9 & 10 now removed in Java 11. jabref should add jaxb to
> its classpath instead.

Thanks Emmanuel.  Yes, I was able to get things working during the bus
ride in this morning, just need to finish up the wrapper script logic
so it can start on Java 8, 9, 10, > 10 without the user having to worry
with it...

I'll look at the FTBFS as well.


signature.asc
Description: PGP signature

Bug#912193: [Pkg-samba-maint] Bug#912193: samba: Ignores UNIX groups

[Paul Szabo]

Dear Mathieu,

> Why your UNIX groups don't match your Windows groups? This is usually
> the case, with nss_winbind.

My site is mainly Linux; we have secondary groups in the /etc/group
file. I am trying to move from Samba3 to the Debian Samba4, setting up
Samba as an AD DC (for Windows10). I have the libnss-winbind package.
Still, Samba (winbidd?) seems to create separate "Domain\user" entities,
and does seem to add those to the groups that the Linux user belongs to.

> Alternatively, you can reverse the logic with idmap_nss.

I tried that, did not seem to help.

>> (Seems to me that Samba4.9 suffers from the same issue.)
> Have you tried it? ...

I had tried to build Samba 4.9.1 the "Debian way", following the method
in the "experimental" packages, but failed on my "stretch" machine due
to some version incompatibility issues. (Did not try the "native way"
with configure/make, thought it would be best to follow Debian.)

> ... This part of the code has changed a lot.

The file source3/auth/auth_util.c did not change that much between
4.5.12 and 4.9.1, the "essence" of my patch still seems to apply
(though not the patch file I posted).

> Also please note that we don't accept patches that are not merged
> upstream first.
> Additionnaly, this patch target stable while it's not a security or
> stability patch.

Understood. I have been using my own Samba for years, can keep doing
that.

Cheers, Paul
-- 
Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#912300: linux-image-amd64: SD card reader on Dell E7250 doesn't work in Debian Stretch

[Adam Chancler]

Package: linux-image-amd64
Version: 4.9+80+deb9u6
Severity: normal

There is a known issue on 4.x kernels for this device:

01:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 
01)
sdhci-pci :01:00.0: SDHCI controller found [1217:8520] (rev 1)

Whenever we try to use this reader with any kind of SD card, it doesn't work
 and reports the following in dmesg:

[ 4357.435988] sdhci: Timeout waiting for Buffer Read Ready interrupt during 
tuning procedure, falling back to fixed sampling clock
[ 4357.443304] mmc0: tuning execution failed: -5
[ 4357.443315] mmc0: error -5 whilst initialising SD card

There is a same issue open on Ubuntu bug tracker: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1514821

I have tried the solution from:
https://www.0xf8.org/2016/01/workaround-for-broken-o2-micro-sd-card-reader-support-since-linux-kernel-version-4-1-8/
which proposes loading the `sdhci` module with a debug_quirks2="0x4" flag, but 
it doesn't work and people report this error comes back after every kernel 
update.

This bug persisted since Debian Stretch appeared and never been fixed in any of 
kernel updates.

It seems someone already submitted a patch in linux.kernel.mmc but it was never 
included in Debian mainline:
http://comments.gmane.org/gmane.linux.kernel.mmc/34979


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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.9.0-8-amd64  4.9.110-3+deb9u6

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#912299: blender: make the build reproducible

[Nicholas M Gregory]

Source: blender
Version: 2.79.b+dfsg0-4
Severity: wishlist
Tags: patch
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi there,

While working on the reproducible builds project
(https://wiki.debian.org/ReproducibleBuilds), we noticed that blender
could not be built reproducibly.

The attached patch changes the build system to use the
SOURCE_DATE_EPOCH envvar (if set) in place of the current build
date/time to make blender build reproducibly.

Best,
-Nick Gregory

 begin patch 
diff --git a/build_files/cmake/buildinfo.cmake
b/build_files/cmake/buildinfo.cmake
index a43b99f..ab7d3e3 100644
--- a/build_files/cmake/buildinfo.cmake
+++ b/build_files/cmake/buildinfo.cmake
@@ -148,12 +148,21 @@ endif()
 # BUILD_PLATFORM and BUILD_PLATFORM are taken from CMake
 # but BUILD_DATE and BUILD_TIME are platform dependent
 if(UNIX)
-   if(NOT BUILD_DATE)
-   execute_process(COMMAND date "+%Y-%m-%d"
OUTPUT_VARIABLE BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)
-   endif()
-   if(NOT BUILD_TIME)
-   execute_process(COMMAND date "+%H:%M:%S"
OUTPUT_VARIABLE BUILD_TIME OUTPUT_STRIP_TRAILING_WHITESPACE)
-   endif()
+if(DEFINED ENV{SOURCE_DATE_EPOCH})
+execute_process(COMMAND "date" "-u" "-d"
"@$ENV{SOURCE_DATE_EPOCH}" "+%Y-%m-%d"
+OUTPUT_VARIABLE BUILD_DATE
+OUTPUT_STRIP_TRAILING_WHITESPACE)
+execute_process(COMMAND "date" "-u" "-d"
"@$ENV{SOURCE_DATE_EPOCH}" "+%H:%M:%S"
+OUTPUT_VARIABLE BUILD_TIME
+OUTPUT_STRIP_TRAILING_WHITESPACE)
+else()
+if(NOT BUILD_DATE)
+execute_process(COMMAND date "+%Y-%m-%d" OUTPUT_VARIABLE
BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)
+endif()
+if(NOT BUILD_TIME)
+execute_process(COMMAND date "+%H:%M:%S" OUTPUT_VARIABLE
BUILD_TIME OUTPUT_STRIP_TRAILING_WHITESPACE)
+endif()
+endif()
 elseif(WIN32)
if(NOT BUILD_DATE)
execute_process(COMMAND cmd /c date /t OUTPUT_VARIABLE
BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)

Bug#912298: linux-image-amd64: SD card reader on Dell E7250 doesn't work in Debian Stretch

[mc1983]

Package: linux-image-amd64
Version: 4.9+80+deb9u6
Severity: normal

There is a known issue on 4.x kernels for this device:

01:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller 
(rev 01)

sdhci-pci :01:00.0: SDHCI controller found [1217:8520] (rev 1)

Whenever we try to use this reader with any kind of SD card, it doesn't 
work

 and reports the following in dmesg:

[ 4357.435988] sdhci: Timeout waiting for Buffer Read Ready interrupt 
during tuning procedure, falling back to fixed sampling clock

[ 4357.443304] mmc0: tuning execution failed: -5
[ 4357.443315] mmc0: error -5 whilst initialising SD card

There is a same issue open on Ubuntu bug tracker: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1514821


I have tried the solution from:
https://www.0xf8.org/2016/01/workaround-for-broken-o2-micro-sd-card-reader-support-since-linux-kernel-version-4-1-8/
which proposes loading the `sdhci` module with a debug_quirks2="0x4" 
flag, but it doesn't work and people report this error comes back after 
every kernel update.


This bug persisted since Debian Stretch appeared and never been fixed in 
any of kernel updates.



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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.9.0-8-amd64  4.9.110-3+deb9u6

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#912221: jabref: incompatible with openjdk 11

[Emmanuel Bourg]

Le 29/10/2018 à 13:54, gregor herrmann a écrit :

> Now that openjdk 11 is the default, jabref won't start without some
> help:
> 
> % jabref
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Module java.se.ee not found

jabref should no longer use the java.se.ee module, it was a temporary
module in Java 9 & 10 now removed in Java 11. jabref should add jaxb to
its classpath instead.

Emmanuel Bourg

Bug#912221: jabref: incompatible with openjdk 11

[gregor herrmann]

Control: tag -1 + ftbfs

On Mon, 29 Oct 2018 13:54:26 +0100, gregor herrmann wrote:

> Package: jabref
> Version: 3.8.2+ds-7
> Severity: important
> 
> Now that openjdk 11 is the default, jabref won't start without some
> help:
> 
> % jabref
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Module java.se.ee not found

And it also FTBFS:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jabref.html

(Thanks to Adrian for already raising the severity.)


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Simon and Garfunkel: American Tune


signature.asc
Description: Digital Signature

Bug#912231: bnd FTBFS with OpenJDK 11

[Markus Koschany]

The OpenJDK 11 issue is rather simple to fix, however the build fails
later on with this error message, a Gradle issue?

Patch is attached.

Cannot find pom file
/build/bnd-3.5.0/debian/.m2/repository/biz/aQute/bnd/aQute.libg/3.5.0/aQute.libg-3.5.0.pom
Oct 29, 2018 7:44:01 PM org.debian.maven.repo.POMCleaner cleanPom
SEVERE: null
java.io.FileNotFoundException:
debian/.m2/repository/biz/aQute/bnd/aQute.libg/3.5.0/aQute.libg-3.5.0.pom (No
such file or directory)
>---at java.base/java.io.FileInputStream.open0(Native Method)
>---at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
>---at java.base/java.io.FileInputStream.(FileInputStream.java:157)
>---at org.debian.maven.util.Readers.read(Readers.java:50)
>---at org.debian.maven.repo.POMReader.readPom(POMReader.java:57)
>---at
org.debian.maven.repo.POMTransformer.transformPom(POMTransformer.java:226)
>---at
org.debian.maven.repo.POMTransformer.transformPom(POMTransformer.java:211)
>---at org.debian.maven.repo.POMCleaner.cleanPom(POMCleaner.java:75)
>---at org.debian.maven.repo.POMCleaner.main(POMCleaner.java:372)

Cannot find pom file
/build/bnd-3.5.0/debian/.m2/repository/biz/aQute/bnd/aQute.libg/3.5.0/aQute.libg-3.5.0.pom
Oct 29, 2018 7:44:02 PM org.debian.maven.repo.POMCleaner cleanPom
SEVERE: null
java.io.FileNotFoundException:
debian/.m2/repository/biz/aQute/bnd/aQute.libg/3.5.0/aQute.libg-3.5.0.pom (No
such file or directory)
>---at java.base/java.io.FileInputStream.open0(Native Method)
>---at java.base/java.io.FileInputStream.open(FileInputStream.java:219)
>---at java.base/java.io.FileInputStream.(FileInputStream.java:157)
>---at org.debian.maven.util.Readers.read(Readers.java:50)
>---at org.debian.maven.repo.POMReader.readPom(POMReader.java:57)
>---at
org.debian.maven.repo.POMTransformer.transformPom(POMTransformer.java:226)
>---at
org.debian.maven.repo.POMTransformer.transformPom(POMTransformer.java:211)
>---at org.debian.maven.repo.POMCleaner.cleanPom(POMCleaner.java:75)
>---at org.debian.maven.repo.POMCleaner.main(POMCleaner.java:372)

/usr/bin/mh_installpom: line 148: debian/.mh/pom.properties: No such
file or directory
make: *** [debian/rules:9: binary] Error 1
From: Markus Koschany 
Date: Mon, 29 Oct 2018 20:36:31 +0100
Subject: java11

Fix biz.aQute.remote/src/aQute/remote/agent/RedirectOutput.java:41: error:
nullOutputStream() in RedirectOutput cannot override nullOutputStream() in
OutputStream private static PrintStream nullOutputStream() { ^ attempting to
assign weaker access privileges; was public

Bug-Debian: https://bugs.debian.org/912231
Forwarded: no
---
 biz.aQute.remote/src/aQute/remote/agent/RedirectOutput.java | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/biz.aQute.remote/src/aQute/remote/agent/RedirectOutput.java b/biz.aQute.remote/src/aQute/remote/agent/RedirectOutput.java
index 28ee248..fde8e95 100644
--- a/biz.aQute.remote/src/aQute/remote/agent/RedirectOutput.java
+++ b/biz.aQute.remote/src/aQute/remote/agent/RedirectOutput.java
@@ -38,7 +38,7 @@ public class RedirectOutput extends PrintStream {
 		this.err = err;
 	}
 
-	private static PrintStream nullOutputStream() {
+	public static PrintStream nullOutputStream() {
 		return new PrintStream(new NullOutputStream());
 	}
 


signature.asc
Description: OpenPGP digital signature

Bug#912087: [Pkg-openssl-devel] Bug#912087: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Kurt Roeckx]

On Mon, Oct 29, 2018 at 09:58:20PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> > So I believe this is not an openssl issue, but something in the
> > order that the kernel's RNG is initialized and openssh is started.
> > Potentionally the RNG isn't initialized at all and you actually
> > have to wait for the kernel to get it's random data from the slow
> > way.
> > 
> > So I'm reassigning this to systemd and openssh-server, I have no
> > idea where the problem really is.
> 
> I see it, too. So during boot someone invokes "sshd -t" which invokes

That's:
ExecStartPre=/usr/sbin/sshd -t

>   getrandom(, 32, 0)
> and this blocks.

And did systemd-random-seed.service get run before that?


Kurt

Bug#803503: libfile-stripnondeterminism-perl: substr outside of string at /usr/share/perl5/File/StripNondeterminism/handlers/zip.pm

[Daniel Stender]

... sorry for the delay.

Yep, still there are messages on this (2.52b-4, just let the dh helper run over 
the docs package):


make[1]: Entering directory '/<>'
dh_strip_nondeterminism
Using 1540827893 as canonical time
Normalizing debian/afl/usr/share/doc/afl/buildinfo_amd64.gz using 
File::StripNondeterminism::handlers::gzip
Using 1540827893 as canonical time
Normalizing debian/afl-clang/usr/share/doc/afl-clang/buildinfo_amd64.gz 
using File::StripNondeterminism::handlers::gzip
debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/msie-zlib-dos.png: invalid 
length in '^@2,u' header at 
/usr/share/perl5/File/StripNondeterminism/handlers/png.pm line 130.
substr outside of string at 
/usr/share/perl5/File/StripNondeterminism/handlers/zip.pm line 155.
Use of uninitialized value in unpack at 
/usr/share/perl5/File/StripNondeterminism/handlers/zip.pm line 155.
IO error: reading local extra field :
 at /usr/bin/dh_strip_nondeterminism line 90.
Can't write to /tmp/rXEyUsKJcD.zip
 at /usr/share/perl5/Archive/Zip/Archive.pm line 439.

Archive::Zip::Archive::overwrite(Archive::Zip::Archive=HASH(0x55800895e938)) 
called at /usr/share/perl5/File/StripNondeterminism/handlers/zip.pm line 218

File::StripNondeterminism::handlers::zip::normalize("debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/unzip-t-mem"...)
 called at /usr/bin/dh_strip_nondeterminism line 90
eval {...} called at /usr/bin/dh_strip_nondeterminism line 90
Using 1540827893 as canonical time
Normalizing 
debian/afl-doc/usr/share/afl/testcases/images/png/not_kitty_alpha.png using 
File::StripNondeterminism::handlers::png
Normalizing 
debian/afl-doc/usr/share/afl/testcases/images/png/not_kitty.png using 
File::StripNondeterminism::handlers::png
Normalizing 
debian/afl-doc/usr/share/afl/testcases/images/png/not_kitty_icc.png using 
File::StripNondeterminism::handlers::png
Normalizing 
debian/afl-doc/usr/share/afl/testcases/images/png/not_kitty_gamma.png using 
File::StripNondeterminism::handlers::png
Normalizing 
debian/afl-doc/usr/share/afl/testcases/archives/common/ar/small_archive.a using 
File::StripNondeterminism::handlers::ar
Normalizing 
debian/afl-doc/usr/share/afl/testcases/archives/common/zip/small_archive.zip 
using File::StripNondeterminism::handlers::zip
Normalizing 
debian/afl-doc/usr/share/afl/testcases/archives/common/gzip/small_archive.gz 
using File::StripNondeterminism::handlers::gzip
Normalizing 
debian/afl-doc/usr/share/afl/testcases/archives/common/cpio/small_archive.cpio 
using File::StripNondeterminism::handlers::cpio
Normalized 
debian/afl-doc/usr/share/afl/testcases/archives/common/cpio/small_archive.cpio
Normalizing 
debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/msie-png-mem-leak.png using 
File::StripNondeterminism::handlers::png
Normalizing 
debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/msie-zlib-dos.png using 
File::StripNondeterminism::handlers::png
Normalizing 
debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/unzip-t-mem-corruption.zip 
using File::StripNondeterminism::handlers::zip
Normalizing 
debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/lesspipe-cpio-bad-write.cpio 
using File::StripNondeterminism::handlers::cpio
Normalized 
debian/afl-doc/usr/share/doc/afl-doc/vuln_samples/lesspipe-cpio-bad-write.cpio
make[1]: Leaving directory '/<>'


However, like said, the vuln_samples shipped by this package might contain non 
standard files, so you might
close this bug report if this occurrence doesn't matter.

DS

--
4096R/DF5182C8 (sten...@debian.org)
http://www.danielstender.com/

Bug#912266: tomcat7 FTBFS with OpenJDK 11

[Emmanuel Bourg]

Control: tags -1 + wontfix

src:tomcat7 builds one package, libservlet3.0-java, which is only used
by eclipse. Once eclipse is removed tomcat7 will follow.

Bug#912297: ansible: CVE-2018-16837

[Chris Lamb]

Package: ansible
Version: 1.7.2+dfsg-2
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for ansible.

CVE-2018-16837[0]:
| Ansible "User" module leaks any data which is passed on as a parameter
| to ssh-keygen. This could lean in undesirable situations such as
| passphrases credentials passed as a parameter for the ssh-keygen
| executable. Showing those credentials in clear text form for every
| user which have access just to the process list.

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-16837
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16837


Regards,

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

Bug#912296: jboss-modules FTBFS with OpenJDK 11

[Adrian Bunk]

Source: jboss-modules
Version: 1.8.6-1
Severity: serious
Tags: ftbfs

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

...
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 4.708 s
[INFO] Finished at: 2019-12-01T14:56:10-12:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) 
on project jboss-modules: Compilation failure: Compilation failure: 
[ERROR] 
/build/1st/jboss-modules-1.8.6/src/main/java/org/jboss/modules/JDKSpecific.java:[37,19]
 cannot find symbol
[ERROR]   symbol:   class Reflection
[ERROR]   location: package sun.reflect
[ERROR] 
/build/1st/jboss-modules-1.8.6/src/main/java/org/jboss/modules/JDKSpecific.java:[85,22]
 cannot find symbol
[ERROR]   symbol:   variable Reflection
[ERROR]   location: class org.jboss.modules.JDKSpecific
[ERROR] 
/build/1st/jboss-modules-1.8.6/src/main/java/org/jboss/modules/JDKSpecific.java:[85,75]
 cannot find symbol
[ERROR]   symbol:   variable Reflection
[ERROR]   location: class org.jboss.modules.JDKSpecific
[ERROR] 
/build/1st/jboss-modules-1.8.6/src/main/java/org/jboss/modules/JDKSpecific.java:[87,22]
 cannot find symbol
[ERROR]   symbol:   variable Reflection
[ERROR]   location: class org.jboss.modules.JDKSpecific
[ERROR] 
/build/1st/jboss-modules-1.8.6/src/main/java/org/jboss/modules/JDKSpecific.java:[87,54]
 cannot find symbol
[ERROR]   symbol:   class Reflection
[ERROR]   location: class org.jboss.modules.JDKSpecific
[ERROR] 
/build/1st/jboss-modules-1.8.6/src/main/java/org/jboss/modules/JDKSpecific.java:[120,20]
 cannot find symbol
[ERROR]   symbol:   variable Reflection
[ERROR]   location: class org.jboss.modules.JDKSpecific
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/1st/jboss-modules-1.8.6 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/build/1st/jboss-modules-1.8.6/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml 
-Ddebian.dir=/build/1st/jboss-modules-1.8.6/debian 
-Dmaven.repo.local=/build/1st/jboss-modules-1.8.6/debian/maven-repo 
--batch-mode package javadoc:jar javadoc:aggregate -DskipTests 
-Dnotimestamp=true -Dlocale=en_US returned exit code 1
make: *** [debian/rules:4: build] Error 1

Bug#912295: jboss-jdeparser2 FTBFS with OpenJDK 11

[Adrian Bunk]

Source: jboss-jdeparser2
Version: 2.0.2-1
Severity: serious
Tags: ftbfs buster sid

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

...
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 3.884 s
[INFO] Finished at: 2018-10-29T07:13:06-12:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) 
on project jdeparser: Compilation failure: Compilation failure: 
[ERROR] 
/build/1st/jboss-jdeparser2-2.0.2/src/main/java/org/jboss/jdeparser/Assertions.java:[21,19]
 cannot find symbol
[ERROR]   symbol:   class Reflection
[ERROR]   location: package sun.reflect
[ERROR] 
/build/1st/jboss-jdeparser2-2.0.2/src/main/java/org/jboss/jdeparser/Assertions.java:[29,20]
 cannot find symbol
[ERROR]   symbol:   variable Reflection
[ERROR]   location: class org.jboss.jdeparser.Assertions
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/1st/jboss-jdeparser2-2.0.2 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/build/1st/jboss-jdeparser2-2.0.2/debian/maven.properties
 org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml 
-Ddebian.dir=/build/1st/jboss-jdeparser2-2.0.2/debian 
-Dmaven.repo.local=/build/1st/jboss-jdeparser2-2.0.2/debian/maven-repo 
--batch-mode package javadoc:jar javadoc:aggregate -DskipTests 
-Dnotimestamp=true -Dlocale=en_US returned exit code 1
make: *** [debian/rules:4: build] Error 1

Bug#902324: [zebmccor...@asymptote.club: Re: Bug#902324: RFS: zeyple/1.2.2-3 [ITP]]

[Piper McCorkle]

I can't seem to ever remember to reply to the BTS, so here's the message
forwarded.

- Forwarded message from Piper McCorkle  -

Date: Mon, 29 Oct 2018 21:32:15 +
From: Piper McCorkle 
To: Dmitry Bogatov 
Subject: Re: Bug#902324: RFS: zeyple/1.2.2-3 [ITP]
Message-ID: <20181029213215.ga5...@asymptote.club>
References: <1783205.UGH6EXJrsk@broensted-debian>
<1783205.UGH6EXJrsk@broensted-debian>

<1783205.UGH6EXJrsk@broensted-debian>
<20181027201236.gb8...@asymptote.club>

MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.4 (2018-02-28)

On Mon, Oct 29, 2018 at 08:04:19PM +, Dmitry Bogatov wrote:
> 
> // removed items that I have no comments on.
> [2018-10-27 20:12] Piper McCorkle 
> > >  * Build-depend on debhelper >= 11~ (mind the tilde). Be nice to
> > >backporters.
> 
> Just recently discovered, that debhelper introduced new syntax for
> compat: Build-Depends: debhelper-compat (= 11), and `debian/compat'
> is no longer used. Not significant, just FYI. See debhelper(7).

Changed.

> > >  * There seems to be typos in zeyple.1
> > I can't seem to find any typos, could you give an example?
> 
> Sure.
> 
>  * In BUGS section, https:// part of URL to upstream bugtracker seems
>ito be missing.

Fixed.

>  * In FILES section, `/etc/foo.conf' is referenced. I believe it have
>to be `/etc/zeyple.conf'

Fixed.

>  * DESCRIPTION section is rather non-informative. Maybe you could use
>something from README on github?

Reworded the first sentence and bullet points; fixed.

>  * According to `zeyple/zeyple.py:278', SYNOPSIS should a least mention
> 
>   zeyplin [recepient ...]

Fixed.

> There is also following issues, I did not noticed last time
> {or they did not exist}
> 
>   * Your identities in debian/control and debian/changelog differs.
> Debian tools compare not only emails, but full name too.

Fixed; changed all of them to what I have on a signed PGP UID.

>   * You build-depends on dh-exec, but seems to not actually use it.

Fixed.

>   * You package does not build twice, since `dh_clean' does not
> clean __pycache__ after previous build. Consider something like
> 
> override_dh_auto_clean:
> dh_auto_clean
> rm -r tests/__pycache__ zeyple/__pycache__
> 
> debhelper automatically manages this for packages, that use
> setuputils. Probably worth discussing with upstream?

Added that to d/rules, this is the consensus of upstream wrt
setuptools (I assume you meant setuptools instead of setuputils):
https://github.com/infertux/zeyple/issues/3

>   * It seems that zeyple is new package. So it must have revision -1
> and you have to remove all entries for next revisions. Revision
> reflects changes between versions, uploaded into Archives.

Fixed.

>   * Urgency of new packages is always low (`debian/changelog':23)

Fixed.

> All above apply to commit b6c366.


Thanks for all the help with this!

-- 
Piper McCorkle (transitioning s/Zeb(ulon)?/Piper/)
zebmccor...@asymptote.club | https://keybase.io/zebMcCorkle
803A 0F47 82AD DDEA 46BE  055F F8F9 DB8C 1A54 6398

   |
   |
__/
  __  Asymptote Club
 /(bad ASCII graph by yours truly)
 |
 |



- End forwarded message -


signature.asc
Description: PGP signature

Bug#912294: squid: SQUID-2018:5: Denial of Service issue in SNMP processing

[Salvatore Bonaccorso]

Source: squid
Version: 4.3-1
Severity: important
Tags: security upstream

Hi

Filling bug for tacking, no CVE is assigned yet (but requested):

http://www.squid-cache.org/Advisories/SQUID-2018_5.txt

> Problem Description:
> 
>  Due to a memory leak in SNMP query rejection code, Squid is
>  vulnerable to a denial of service attack.

Regards,
Salvatore

Bug#912189: [Xcb] Bug#912189: libpthread: man pthread_mutex_init doesn't find a man page

[Josh Triplett]

On Sun, Oct 28, 2018 at 04:15:14PM -0700, Joshua wrote:
> Package: libpthread-stubs0-dev
> Version: 0.3-4
> Severity: normal
> File: libpthread
> Tags: newcomer
> 
> It's possible I don't quite have the right package.
> 
> man pthread_init does not find a man page but should. I'm not certain but I 
> think one can be thrown
> together pretty quickly from the one on the open group.

You want the glibc-doc package. (The Open Group materials may not be
licensed appropriately, but it shouldn't be hard to put together a
manpage.)

Bug#912293: squid: SQUID-2018:4: Cross-Site Scripting issue in TLS error processing

[Salvatore Bonaccorso]

Source: squid
Version: 4.3-1
Severity: minor
Tags: security upstream

Hi

Filling this bug to have an identifier (as long no CVEs are yet
assigned):

http://www.squid-cache.org/Advisories/SQUID-2018_4.txt

> Problem Description:
> 
>  Due to incorrect input handling, Squid is vulnerable to a
>  Cross-Site Scripting vulnerability when generating HTTPS response
>  messages about TLS errors.

Squid in Debian builds without TLS support, so it is marked as
"unimportant" from security-tracker point of view.

Regards,
Salvatore

Bug#909218: Xmas Gift

[NOEL ANTOINE]

Donation to you, contact jleac...@outlook.com

Bug#912292: lintian: Update Java bytecode checks for openjdk-11

[Chris Lamb]

tags 912292 + pending
thanks

Thanks; applied in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/f48c92363b83a98155612fa499c929a8e657319a

  checks/java.desc  | 2 +-
  checks/java.pm| 3 ++-
  data/java/constants   | 7 ---
  debian/changelog  | 4 
  t/tests/java-class-format/debian/debian/rules | 4 ++--
  t/tests/java-class-format/tags| 2 +-
  6 files changed, 14 insertions(+), 8 deletions(-)


Regards,

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

Bug#911958: [Pkg-nagios-devel] Bug#911958: nagios-nrpe-plugin: On large installations, check_nrpe logs are very spammy around nrpe packet version.

[Sebastiaan Couwenberg]

On 10/29/18 10:13 PM, Faidon Liambotis wrote:
> On Mon, Oct 29, 2018 at 09:10:40PM +0100, Sebastiaan Couwenberg wrote:
>>> I disagree on that -- excessive and spurious logging is a serious issue
>>> and filling up logs of the Nagios server fast is as well. Logrotate
>>> helps, but not with that rate, and regardless, not a great solution
>>> either (the logs become just an endless sea of garbage).
>>
>> Then we'll have to agree to disagree. As maintainer of the package I
>> have evaluated the severity of this issue, and not deemed it high enough
>> to be eligible for a stable update.
>>
>>> And really, what's the downside? These logs are useless; the patch is
>>> upstream, is tiny, safe and easily backportable. If you're concerned
>>> about the effort... I'd be happy to provide patches and/or NMU!
>>
>> If you're going to the effort to patch the package, why bother arguing
>> in this issue? Just provide the package in your local repo and be done
>> with it.
> 
> We've already done that (in fact, before even reporting this bug!):
> https://phabricator.wikimedia.org/T207775#4693987
> https://apt.wikimedia.org/wikimedia/pool/main/n/nagios-nrpe/
> 
> ...but, given that we encountered this, and we already battle-tested it,
> we thought it might be preferrable for other Debian users to benefit
> from the fix as well. Given the Nagios forum link above, it doesn't look
> like we were the only ones affected. All of us in the Wikimedia team
> (three of us DDs) in that loop agreed on this FWIW :)

But none of you are active in the Nagios team, (co-)maintainers of the
nrpe package, nor SRMs.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#912292: lintian: Update Java bytecode checks for openjdk-11

[Bas Couwenberg]

Source: lintian
Version: 2.5.110
Severity: normal
Tags: patch

Dear Maintainer,

Now that openjdk-11 is the default JDK & JRE in unstable, the Java
bytecode checks in lintian need to be updated again, as per the attached
patch.

Note that the bytecode version for the upcoming Java12 is assumed to be
56, but this may not be the case. max-bytecode-existing-version has not
been incremented because of that.

Kind Regards,

Bas
>From 7d25cdc4c055b0c06962e8cc23a5ac0f8f4c7702 Mon Sep 17 00:00:00 2001
From: Bas Couwenberg 
Date: Mon, 29 Oct 2018 22:21:53 +0100
Subject: Update Java bytecode checks for openjdk-11.

---
 checks/java.desc  | 2 +-
 checks/java.pm| 3 ++-
 data/java/constants   | 7 ---
 t/tests/java-class-format/debian/debian/rules | 4 ++--
 t/tests/java-class-format/tags| 2 +-
 5 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/checks/java.desc b/checks/java.desc
index 78e7e03f2..db1c491f0 100644
--- a/checks/java.desc
+++ b/checks/java.desc
@@ -91,7 +91,7 @@ Info: The package contains a Jar file with Java class files 
compiled for an
  for a newer version of Java than Lintian knows about.  In the latter case,
  please file a bug against Lintian.
  .
- The latest class version known by Lintian is Java10 (Major version 54).
+ The latest class version known by Lintian is Java11 (Major version 55).
 
 Tag: zip-parse-error
 Severity: normal
diff --git a/checks/java.pm b/checks/java.pm
index 1c2c97598..19e670fab 100644
--- a/checks/java.pm
+++ b/checks/java.pm
@@ -98,7 +98,7 @@ sub run {
 or $mver
 > $MAX_BYTECODE->value('max-bytecode-existing-version')) {
 # First public major version was 45 (Java1), latest
-# version is 54 (Java10).
+# version is 55 (Java11).
 tag 'unknown-java-class-version', $jar_file,
   "($class -> $mver)";
 # Skip the rest of this Jar.
@@ -215,6 +215,7 @@ sub run {
 # 52 -> Java8
 # 53 -> Java9
 # 54 -> Java10
+# 55 -> Java11
 my $bad = 0;
 
 # If the lowest version used is greater than the requested
diff --git a/data/java/constants b/data/java/constants
index b08e0cfd4..ebb45af62 100644
--- a/data/java/constants
+++ b/data/java/constants
@@ -6,9 +6,10 @@
 # 51 -> Java7
 # 52 -> Java8
 # 53 -> Java9
-# 54 -> Java10 - Current max version in Debian unstable
-# 55 -> Java11
-max-bytecode-version = 54
+# 54 -> Java10
+# 55 -> Java11 - Current max version in Debian unstable
+# 56 -> Java12
+max-bytecode-version = 55
 
 max-bytecode-existing-version = 55
 
diff --git a/t/tests/java-class-format/debian/debian/rules 
b/t/tests/java-class-format/debian/debian/rules
index b79c40c78..59235963f 100755
--- a/t/tests/java-class-format/debian/debian/rules
+++ b/t/tests/java-class-format/debian/debian/rules
@@ -7,8 +7,8 @@ override_jh_build:
unzip test.jar
# Unknown class version
perl -i -pe 's/^(\xCA\xFE\xBA\xBE...)./$$1\x2A/' 
org/debian/lintian/TestA.class
-   # Java11 (unsupported)
-   perl -i -pe 's/^(\xCA\xFE\xBA\xBE...)./$$1\x37/' 
org/debian/lintian/TestB.class
+   # Java12 (unsupported)
+   perl -i -pe 's/^(\xCA\xFE\xBA\xBE...)./$$1\x38/' 
org/debian/lintian/TestB.class
# Put them in separate Jars because Lintian stops when the first
# "unknown class format" is seen
zip -r testa.jar META-INF/ org/debian/lintian/TestA.class
diff --git a/t/tests/java-class-format/tags b/t/tests/java-class-format/tags
index 588eb01c0..aa21ea634 100644
--- a/t/tests/java-class-format/tags
+++ b/t/tests/java-class-format/tags
@@ -1,2 +1,2 @@
-W: libtest-java: incompatible-java-bytecode-format Java11 version (Class 
format: 55)
+W: libtest-java: incompatible-java-bytecode-format Java12 version (Class 
format: 56)
 W: libtest-java: unknown-java-class-version usr/share/java/testa-1.0.jar 
(org/debian/lintian/TestA.class -> 42)
-- 
2.11.0

Bug#908756: [Pkg-mpd-maintainers] Bug#908756: mpc: frequent parallel FTBFS

[Max Kellermann]

On 2018/10/29 22:23, Florian Schlichting  wrote:
> I had a look at meson, and while there seems to be no option to turn off
> parallelism in a specific meson.build, enforcing serialisation of doc
> targets by having manpage generation depend on the HTML docs should do
> the trick, perhaps like so:

ncmpc had the same problem, and somebody submitted this workaround for
the Sphinx file corruption bug:

 
https://github.com/MusicPlayerDaemon/ncmpc/commit/d5aff222515ccd3ab8068796d5c13abf9329e11c

Bug#877638: seems this was already upstream as #1110 in github

[shirish शिरीष]

Dear all,

Seems this was reported ages ago, see https://github.com/Guake/guake/issues/1110

I am guessing that #910778 is probably part of the same issue.

-- 
  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#890594: salsa script ready to review

[Xavier]

Le 29/10/2018 à 21:50, Xavier a écrit :
> Le 29/10/2018 à 21:35, Xavier a écrit :
>> Le 29/10/2018 à 12:27, Raphael Hertzog a écrit :
>>> On Sun, 28 Oct 2018, Xavier wrote:
 Mattia explained me dep14. I found a way to do it: create branch from
 master, update project to set default_branch to debian/master then
 remove master. It works as expected.

 $ salsa update_repo node-mongodb --group js-team --rename-head

 $ salsa update_repo --all --rename-head --no-fail # all user projects

 Manpage updated:
 https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L339
>>>
>>> Nice, thanks!
>>>
>>> Now, this tool is really powerful and one could be wary of breaking
>>> things. It would be nice if there was a "--no-act" option that would not
>>> change anything but only display what would be done.
>>>
>>> It could be useful to see what repositories are currently not following
>>> the usual rules and double check that we really want to override their
>>> current configuration.
>>
>> Done: now you have a "check_repo" command that reports bad configured
>> repositories without modifying anything.
>>
>> https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L117
> 
> It can check:
>  - kgb/irc channel
>  - tagpending
>  - description
>  - default branch
> 
> $? contains the number of failed packages.
> 
> Examples:
> 
> # Some js-team packages:
> $ salsa check_repo --team js-team --desc \
>--kgb --irc-channel=debian-js \
>--tagpending \
>--rename-head \
> node-tap node-mongodb
> node-tap:
> bad description: Repository imported from
> https://anonscm.debian.org/git/pkg-javascript/node-tap.git/
> Default branch is master
> kgb missing
> Tagpending missing
> node-mongodb:
> Default branch is master
> kgb missing
> 
> 
> # All perl-team packages:
> $ salsa check_repo --team-id=2666 --desc \
>--kgb --irc-channel=debian-perl \
>--tagpending \
>--all
> 
> (takes a very long time)

I also added an "update_safe" command that starts "check_repo", then
reports and asks before launching "update_repo" (unless --yes). I think
that's what you want, isn't it?

Bug#912193: [Pkg-samba-maint] Bug#912193: samba: Ignores UNIX groups

[Mathieu Parent]

Le lun. 29 oct. 2018 à 04:09, Paul Szabo  a écrit :
>
> Package: samba
> Version: 2:4.5.12+dfsg-2+deb9u3
> Severity: normal
> Tags: patch
>
> Dear Maintainer,

Hi,

> Samba ignores the UNIX secondary groups of the UNIX user; then file
> permissions (based on those secondary groups) fail. (Instead, Samba
> adds the "Windows groups" that the "Windows user" belongs to, but
> that is probably useless or wrong for file accesses.)

Why your UNIX groups don't match your Windows groups? This is usually
the case, with nss_winbind.

Alternatively, you can reverse the logic with idmap_nss.

> The following patch seems to solve the issue.
>
> (Seems to me that Samba4.9 suffers from the same issue.)

Have you tried it? This part of the code has changed a lot.

> Cheers, Paul

Also please note that we don't accept patches that are not merged
upstream first.
Additionnaly, this patch target stable while it's not a security or
stability patch.

Regards

Mathieu Parent

Bug#908756: [Pkg-mpd-maintainers] Bug#908756: mpc: frequent parallel FTBFS

[Florian Schlichting]

Hi Max,

Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908756
reports frequent build failures of mpc on the reproducible builds
infrastructure due to an issue with running sphinx in parallel:

> ...
> [26/27] /usr/bin/sphinx-build -q -b html -d doc/doctrees 
> /build/1st/mpc-0.30/doc doc/html
> FAILED: doc/html 
> /usr/bin/sphinx-build -q -b html -d doc/doctrees /build/1st/mpc-0.30/doc 
> doc/html
> 
> Exception occurred:
>   File "/usr/lib/python3/dist-packages/sphinx/environment/__init__.py", line 
> 786, in get_doctree
> doctree = pickle.load(f)
> _pickle.UnpicklingError: pickle data was truncated
> The full traceback has been saved in /tmp/sphinx-err-upx0cr5x.log, if you 
> want to report the issue to the developers.
> Please also report this if it was a user error, so that a better error 
> message can be provided next time.
> A bug report can be filed in the tracker at 
> . Thanks!
> [27/27] /usr/bin/sphinx-build -q -b man -d doc/doctrees 
> /build/1st/mpc-0.30/doc doc/man/man1
> ninja: build stopped: subcommand failed.
> dh_auto_build: cd obj-i686-linux-gnu && LC_ALL=C.UTF-8 ninja -j10 -v returned 
> exit code 1

On Thu, Sep 13, 2018 at 04:22:00PM +0300, Adrian Bunk wrote:
> dh compat >= 10 defaults to parallel building.
> 
> Ideally doc/meson.build should be fixed to not run both in parallel,
> but passing --no-parallel to dh in debian/rules would be an option
> to workaround the problem.

I had a look at meson, and while there seems to be no option to turn off
parallelism in a specific meson.build, enforcing serialisation of doc
targets by having manpage generation depend on the HTML docs should do
the trick, perhaps like so:

--- a/doc/meson.build
+++ b/doc/meson.build
@@ -1,4 +1,4 @@
-custom_target(
+html = custom_target(
   'HTML documentation',
   output: 'html',
   input: ['index.rst', 'conf.py'],
@@ -16,4 +16,5 @@
   build_by_default: true,
   install: true,
   install_dir: get_option('datadir'),
+  depends: html,
 )


What do you think?

Florian

Bug#912291: make: man page/info doc enhancement

[Michael Stone]

Package: make
Version: 4.2.1-1.2
Severity: wishlist

The man page for make contains

SEE ALSO
   The full documentation for make is maintained as a Texinfo manual.  If
   the info and make programs are properly installed at  your  site,  the
   command

  info make

   should give you access to the complete manual.

Obviously, in debian the info page isn't available by default since it
was broken out. Adding a tutorial on how to install a package from
non-free is probably outside the scope of make.1. But, perhaps you could
add something like:

  Full documentation available at 
https://www.gnu.org/software/make/manual/html_node/index.html 

Which is much more likely to be useful to a user on a default debian
install.

Mike Stone

Bug#911900: AppArmor blocks XCompose, buddy icon

[Anthony DeRobertis]

Package: pidgin
Version: 2.13.0-2
Followup-For: Bug #911900

In addition, app icons:

Oct 29 16:36:37 Zia kernel: [444528.926213] audit: type=1400 
audit(1540845397.534:1567): apparmor="DENIED" operation="open" 
profile="/usr/bin/pidgin" name="/home/anthony/.icons/gnome/48x48/apps/" 
pid=12089 comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Oct 29 16:36:37 Zia kernel: [444528.928268] audit: type=1400 
audit(1540845397.534:1568): apparmor="DENIED" operation="open" 
profile="/usr/bin/pidgin" name="/home/anthony/.icons/gnome/48x48/apps/" 
pid=12089 comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Oct 29 16:36:37 Zia kernel: [444528.942792] audit: type=1400 
audit(1540845397.550:1569): apparmor="DENIED" operation="open" 
profile="/usr/bin/pidgin" name="/home/anthony/.icons/gnome/48x48/apps/" 
pid=12089 comm="pidgin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

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

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

Versions of packages pidgin depends on:
ii  libatk1.0-0 2.30.0-1
ii  libc6   2.27-6
ii  libcairo2   1.16.0-1
ii  libdbus-1-3 1.12.10-1
ii  libdbus-glib-1-20.110-3
ii  libfontconfig1  2.13.1-1
ii  libfreetype62.8.1-2
ii  libgadu31:1.12.2-3
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-6
ii  libglib2.0-02.58.1-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk2.0-0 2.24.32-3
ii  libgtkspell02.0.16-1.2
ii  libice6 2:1.0.9-2
ii  libpango-1.0-0  1.42.4-3
ii  libpangocairo-1.0-0 1.42.4-3
ii  libpangoft2-1.0-0   1.42.4-3
ii  libpurple0  2.13.0-2
ii  libsm6  2:1.2.2-1+b3
ii  libx11-62:1.6.7-1
ii  libxss1 1:1.2.3-1
ii  perl-base [perlapi-5.26.2]  5.26.2-7+b1
ii  pidgin-data 2.13.0-2

Versions of packages pidgin recommends:
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-base  1.14.4-1
ii  gstreamer1.0-plugins-good  1.14.4-1
ii  gstreamer1.0-pulseaudio1.14.4-1

Versions of packages pidgin suggests:
ii  libsqlite3-0  3.25.2-1

-- no debconf information

Bug#912290: gthumb: CVE-2018-18718

[Salvatore Bonaccorso]

Source: gthumb
Version: 3:3.6.2-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/gthumb/issues/18

Hi,

The following vulnerability was published for gthumb.

CVE-2018-18718[0]:
| An issue was discovered in gThumb through 3.6.2. There is a double-free
| vulnerability in the add_themes_from_dir method in dlg-contact-sheet.c
| because of two successive calls of g_free, each of which frees the same
| buffer.

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-18718
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18718
[1] https://gitlab.gnome.org/GNOME/gthumb/issues/18

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#911958: [Pkg-nagios-devel] Bug#911958: nagios-nrpe-plugin: On large installations, check_nrpe logs are very spammy around nrpe packet version.

[Faidon Liambotis]

On Mon, Oct 29, 2018 at 09:10:40PM +0100, Sebastiaan Couwenberg wrote:
> > I disagree on that -- excessive and spurious logging is a serious issue
> > and filling up logs of the Nagios server fast is as well. Logrotate
> > helps, but not with that rate, and regardless, not a great solution
> > either (the logs become just an endless sea of garbage).
> 
> Then we'll have to agree to disagree. As maintainer of the package I
> have evaluated the severity of this issue, and not deemed it high enough
> to be eligible for a stable update.
> 
> > And really, what's the downside? These logs are useless; the patch is
> > upstream, is tiny, safe and easily backportable. If you're concerned
> > about the effort... I'd be happy to provide patches and/or NMU!
> 
> If you're going to the effort to patch the package, why bother arguing
> in this issue? Just provide the package in your local repo and be done
> with it.

We've already done that (in fact, before even reporting this bug!):
https://phabricator.wikimedia.org/T207775#4693987
https://apt.wikimedia.org/wikimedia/pool/main/n/nagios-nrpe/

...but, given that we encountered this, and we already battle-tested it,
we thought it might be preferrable for other Debian users to benefit
from the fix as well. Given the Nagios forum link above, it doesn't look
like we were the only ones affected. All of us in the Wikimedia team
(three of us DDs) in that loop agreed on this FWIW :)

Regards,
Faidon

Bug#912080: vlc GUI does not start

[Paul Dagnelie]

Package: src:vlc
Version: 3.0.3-1-0+deb9u1
Followup-For: Bug #912080

Dear Maintainer,

VLC player is broken on debian stable. This occured at some point in the past 
few months when a new version of VLC was released. The symptoms, as others have 
reported, are that the GUI of VLC does not appear. Audio begins to play, but 
there is no window. Every attempt to reinstall VLC was made, including cleaning 
all configuration files. This is, according to the VLC forums, a bug with the 
VLC packages; see https://forum.videolan.org/viewtopic.php?t=135609 for an 
example of this issue reported on Fedora.


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

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

Versions of packages vlc depends on:
ii  dpkg 1.18.25
ii  vlc-bin  3.0.3-1-0+deb9u1
ii  vlc-l10n 3.0.3-1-0+deb9u1
ii  vlc-plugin-base  3.0.3-1-0+deb9u1
ii  vlc-plugin-qt3.0.3-1-0+deb9u1
ii  vlc-plugin-video-output  3.0.3-1-0+deb9u1

Versions of packages vlc recommends:
ii  vlc-plugin-notify  3.0.3-1-0+deb9u1
ii  vlc-plugin-samba   3.0.3-1-0+deb9u1
ii  vlc-plugin-skins2  3.0.3-1-0+deb9u1
ii  vlc-plugin-video-splitter  3.0.3-1-0+deb9u1
ii  vlc-plugin-visualization   3.0.3-1-0+deb9u1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.24-11+deb9u3
ii  libvlc5  3.0.3-1-0+deb9u1

Versions of packages libvlc5 depends on:
ii  dpkg 1.18.25
ii  libc62.24-11+deb9u3
ii  libvlccore9  3.0.3-1-0+deb9u1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.3-1-0+deb9u1

Versions of packages libvlccore8 depends on:
ii  dpkg 1.18.25
ii  libc62.24-11+deb9u3
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libidn11 1.33-1

Versions of packages libvlccore8 recommends:
ii  libproxy-tools  0.4.14-2

Versions of packages vlc-bin depends on:
ii  libc6   2.24-11+deb9u3
ii  libvlc-bin  3.0.3-1-0+deb9u1
ii  libvlc5 3.0.3-1-0+deb9u1

Versions of packages vlc-plugin-base depends on:
ii  dpkg 1.18.25
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-2
ii  libasound2   1.1.3-5
ii  libass5  1:0.13.4-2
ii  libavahi-client3 0.6.32-2
ii  libavahi-common3 0.6.32-2
ii  libavc1394-0 0.5.4-4+b1
ii  libavcodec57 7:3.2.12-1~deb9u1
ii  libavformat577:3.2.12-1~deb9u1
ii  libavutil55  7:3.2.12-1~deb9u1
ii  libbasicusageenvironment12016.11.28-1
ii  libbluray1   1:0.9.3-3
ii  libc62.24-11+deb9u3
ii  libcairo21.14.8-1
ii  libcddb2 1.3.2-5
ii  libchromaprint1  1.4.2-1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.5-10
ii  libdvbpsi10  1.3.0-5
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.4-1
ii  libfaad2 2.8.0~cvs20161113-1+deb9u1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libfribidi0  0.19.7-1+b1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgcrypt20  1.7.6-2+deb9u3
ii  libglib2.0-0 2.50.3-2
ii  libgnutls30  3.5.8-5+deb9u3
ii  libgpg-error01.26-2
ii  libgroupsock82016.11.28-1
ii  libharfbuzz0b1.4.2-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.9.4c-9
ii  liblivemedia57   2016.11.28-1
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8+deb9u1
ii  libmatroska6v5   1.4.5-2
ii  libmicrodns0 0.0.3-3
ii  libmpcdec6   2:0.1~r495-1+b1
ii  libmpeg2-4   0.5.1-7+b2
ii  libmpg123-0  1.23.8-1+b1
ii  libmtp9  1.1.13-1
ii  libncursesw5 

Bug#912289: devilspie2 FTCBFS: multiple reasons

[Helmut Grohne]

Source: devilspie2
Version: 0.43-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

devilspie2 fails to cross build from source. debian/rules does not pass
cross tools to make. The easiest way of fixing that is using
dh_auto_build. Then the upstream Makefile hard codes the build
architecture pkg-config. The attached patch fixes both and makes
devilspie2 cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru devilspie2-0.43/debian/changelog 
devilspie2-0.43/debian/changelog
--- devilspie2-0.43/debian/changelog2018-07-21 13:24:37.0 +0200
+++ devilspie2-0.43/debian/changelog2018-10-29 22:07:24.0 +0100
@@ -1,3 +1,12 @@
+devilspie2 (0.43-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Mon, 29 Oct 2018 22:07:24 +0100
+
 devilspie2 (0.43-2) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru devilspie2-0.43/debian/patches/cross.patch 
devilspie2-0.43/debian/patches/cross.patch
--- devilspie2-0.43/debian/patches/cross.patch  1970-01-01 01:00:00.0 
+0100
+++ devilspie2-0.43/debian/patches/cross.patch  2018-10-29 22:07:24.0 
+0100
@@ -0,0 +1,24 @@
+--- devilspie2-0.43.orig/Makefile
 devilspie2-0.43/Makefile
+@@ -20,6 +20,9 @@
+ ifndef CC
+   CC=gcc
+ endif
++ifndef PKG_CONFIG
++  PKG_CONFIG=pkg-config
++endif
+ SRC=src
+ OBJ=obj
+ BIN=bin
+@@ -59,9 +62,9 @@
+   PKG_WNCK=libwnck-3.0
+ endif
+ 
+-LIB_CFLAGS=$(shell pkg-config --cflags --silence-errors $(PKG_GTK) 
$(PKG_WNCK) lua5.1 || pkg-config --cflags $(PKG_GTK) $(PKG_WNCK) lua)
++LIB_CFLAGS=$(shell $(PKG_CONFIG) --cflags --silence-errors $(PKG_GTK) 
$(PKG_WNCK) lua5.1 || $(PKG_CONFIG) --cflags $(PKG_GTK) $(PKG_WNCK) lua)
+ STD_LDFLAGS=
+-LIBS=-lX11 $(shell pkg-config --libs --silence-errors $(PKG_GTK) $(PKG_WNCK) 
lua5.1 || pkg-config --libs $(PKG_GTK) $(PKG_WNCK) lua)
++LIBS=-lX11 $(shell $(PKG_CONFIG) --libs --silence-errors $(PKG_GTK) 
$(PKG_WNCK) lua5.1 || $(PKG_CONFIG) --libs $(PKG_GTK) $(PKG_WNCK) lua)
+ 
+ LOCAL_CFLAGS=$(STD_CFLAGS) $(DEPRECATED) $(CFLAGS) $(LIB_CFLAGS)
+ LOCAL_LDFLAGS=$(STD_CFLAGS) $(LDFLAGS) $(STD_LDFLAGS)
diff --minimal -Nru devilspie2-0.43/debian/patches/series 
devilspie2-0.43/debian/patches/series
--- devilspie2-0.43/debian/patches/series   2017-09-26 15:30:40.0 
+0200
+++ devilspie2-0.43/debian/patches/series   2018-10-29 22:07:24.0 
+0100
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru devilspie2-0.43/debian/rules devilspie2-0.43/debian/rules
--- devilspie2-0.43/debian/rules2017-09-26 15:30:40.0 +0200
+++ devilspie2-0.43/debian/rules2018-10-29 22:07:22.0 +0100
@@ -11,7 +11,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) PREFIX=/usr
+   dh_auto_build -- PREFIX=/usr
 
 override_dh_auto_install:
$(MAKE) DESTDIR=$$(pwd)/debian/devilspie2 PREFIX=/usr install

Bug#851051: bison: using YYERROR in empty rule leads to segmentation fault

[Akim Demaille]

On Wed, 11 Jan 2017 20:50:16 +0100 Simon Richter  wrote:
> Package: bison
> Version: 2:3.0.4.dfsg-1
> Severity: normal
> Tags: upstream
> 
> Hi,
> 
> if an empty rule matches, but calls YYERROR, the parser catches a
> segmentation fault in the line
> 
> yyerror_range[1].location = yystack_[yylen - 1].location;
> 
> inside the error handling, because yylen is 0, (yylen-1) underflows as a 32
> bit unsigned value, so the array is accessed at yystack_[4294967295].
> 
> On 32 bit system, there is still an invalid access, but this is usually not
> detected.
> 
>Simon

This was fixed in Bison 3.0.5.  Since then, versions 3.1 and 3.2 were released.

Bug#912288: zeroc-ice FTBFS with OpenJDK 11

[Adrian Bunk]

Source: zeroc-ice
Version: 3.7.1-3
Severity: serious
Tags: ftbfs

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

...
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':test:compileJava'.
> error: invalid source release: 1.11

Bug#912087: [Pkg-openssl-devel] Bug#912087: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Sebastian Andrzej Siewior]

On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> So I believe this is not an openssl issue, but something in the
> order that the kernel's RNG is initialized and openssh is started.
> Potentionally the RNG isn't initialized at all and you actually
> have to wait for the kernel to get it's random data from the slow
> way.
> 
> So I'm reassigning this to systemd and openssh-server, I have no
> idea where the problem really is.

I see it, too. So during boot someone invokes "sshd -t" which invokes
getrandom(, 32, 0)
and this blocks. I get a login prompt and everything but sshd is started
"late" due to this.

> Kurt

Sebastian

Bug#912087: [Pkg-openssl-devel] Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Kurt Roeckx]

On Mon, Oct 29, 2018 at 07:11:17PM +0100, Michael Biebl wrote:
> On Mon, 29 Oct 2018 18:22:08 +0100 Kurt Roeckx  wrote:
> > reassign 912087 openssh-server,systemd
> > thanks
> > 
> > On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote:
> > > On Mon, Oct 29, 2018 at 12:28:15AM +, Colin Watson wrote:
> > > > Reassigning to OpenSSL - could the OpenSSL maintainers please have a
> > > > look and advise what's best to do?  (See the start of the bug, reporting
> > > > a delay of more than one minute in system boot in some cases, mainly
> > > > waiting for sshd to start.)
> > > 
> > > The biggest change related to this is that we know use
> > > getrandom()/getentropy() on kernels that have it, so kernels
> > > >= 3.17. And the kernel using that interface doesn't return random
> > > numbers until it has been initialized.
> > > 
> > > Something should be initializing the kernel with random data from
> > > the previous boot. This used to be done by /etc/init.d/urandom,
> > > but I'm not sure if that's still used. This should be done as
> > > early as possible during the boot not to cause such problems. You
> > > should look into when during the boot process the kernel gets this
> > > random data.
> > 
> > So I believe this is not an openssl issue, but something in the
> > order that the kernel's RNG is initialized and openssh is started.
> > Potentionally the RNG isn't initialized at all and you actually
> > have to wait for the kernel to get it's random data from the slow
> > way.
> 
> The service is called systemd-random-seed.service and stores the random
> seed during shutdown and restores it during boot. Pretty much as urandom
> did under sysvinit.
> This service is run in sysinit.target, ssh.service is started in
> multi-user.target, which is ordered after sysvinit.target.

Clearly it's not working for the person reporting this issue,
or we wouldn't have this discussion.


Kurt

Bug#890594: salsa script ready to review

[Xavier]

Le 29/10/2018 à 21:35, Xavier a écrit :
> Le 29/10/2018 à 12:27, Raphael Hertzog a écrit :
>> On Sun, 28 Oct 2018, Xavier wrote:
>>> Mattia explained me dep14. I found a way to do it: create branch from
>>> master, update project to set default_branch to debian/master then
>>> remove master. It works as expected.
>>>
>>> $ salsa update_repo node-mongodb --group js-team --rename-head
>>>
>>> $ salsa update_repo --all --rename-head --no-fail # all user projects
>>>
>>> Manpage updated:
>>> https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L339
>>
>> Nice, thanks!
>>
>> Now, this tool is really powerful and one could be wary of breaking
>> things. It would be nice if there was a "--no-act" option that would not
>> change anything but only display what would be done.
>>
>> It could be useful to see what repositories are currently not following
>> the usual rules and double check that we really want to override their
>> current configuration.
> 
> Done: now you have a "check_repo" command that reports bad configured
> repositories without modifying anything.
> 
> https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L117

It can check:
 - kgb/irc channel
 - tagpending
 - description
 - default branch

$? contains the number of failed packages.

Examples:

# Some js-team packages:
$ salsa check_repo --team js-team --desc \
   --kgb --irc-channel=debian-js \
   --tagpending \
   --rename-head \
node-tap node-mongodb
node-tap:
bad description: Repository imported from
https://anonscm.debian.org/git/pkg-javascript/node-tap.git/
Default branch is master
kgb missing
Tagpending missing
node-mongodb:
Default branch is master
kgb missing


# All perl-team packages:
$ salsa check_repo --team-id=2666 --desc \
   --kgb --irc-channel=debian-perl \
   --tagpending \
   --all

(takes a very long time)

Bug#912287: ITP: libappimage -- Core library of the AppImage project.

[Scarlett Moore]

Package: libappimage
Version: 0.1.1
Severity: wishlist

I intend on maintaining this package.



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

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

Bug#912286: libgzstream FTBFS on 32bit: symbol differences

[Adrian Bunk]

Source: libgzstream
Version: 1.5+dfsg-3
Severity: serious
Tags: ftbfs

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

...
   dh_makeshlibs -a -O--no-parallel
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libgzstream0/DEBIAN/symbols doesn't match 
completely debian/libgzstream0.symbols
--- debian/libgzstream0.symbols (libgzstream0_1.5+dfsg-3_i386)
+++ dpkg-gensymbolsguhOdo   2018-10-29 01:05:56.585746020 +
@@ -22,5 +22,7 @@
  _ZTT12gzstreambase@Base 1.5+dfsg
  _ZTV11gzstreambuf@Base 1.5+dfsg
  _ZTV12gzstreambase@Base 1.5+dfsg
- _ZTv0_n24_N12gzstreambaseD0Ev@Base 1.5+dfsg
- _ZTv0_n24_N12gzstreambaseD1Ev@Base 1.5+dfsg
+ _ZTv0_n12_N12gzstreambaseD0Ev@Base 1.5+dfsg-3
+ _ZTv0_n12_N12gzstreambaseD1Ev@Base 1.5+dfsg-3
+#MISSING: 1.5+dfsg-3# _ZTv0_n24_N12gzstreambaseD0Ev@Base 1.5+dfsg
+#MISSING: 1.5+dfsg-3# _ZTv0_n24_N12gzstreambaseD1Ev@Base 1.5+dfsg
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:14: binary-arch] Error 2

Bug#912285: mtools: New upstream release

[Chris Lamb]

Source: mtools
Version: 4.0.18-2.1
Severity: wishlist

Hi,

New upstream 4.0.19 release is available at:

  http://lists.gnu.org/archive/html/info-mtools/2018-09/msg00015.html


Regards,

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

Bug#890594: salsa script ready to review

[Xavier]

Le 29/10/2018 à 12:27, Raphael Hertzog a écrit :
> On Sun, 28 Oct 2018, Xavier wrote:
>> Mattia explained me dep14. I found a way to do it: create branch from
>> master, update project to set default_branch to debian/master then
>> remove master. It works as expected.
>>
>> $ salsa update_repo node-mongodb --group js-team --rename-head
>>
>> $ salsa update_repo --all --rename-head --no-fail # all user projects
>>
>> Manpage updated:
>> https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L339
> 
> Nice, thanks!
> 
> Now, this tool is really powerful and one could be wary of breaking
> things. It would be nice if there was a "--no-act" option that would not
> change anything but only display what would be done.
> 
> It could be useful to see what repositories are currently not following
> the usual rules and double check that we really want to override their
> current configuration.

Done: now you have a "check_repo" command that reports bad configured
repositories without modifying anything.

https://salsa.debian.org/yadd/devscripts/blob/devscripts-salsa-890594/scripts/salsa.pl#L117

> Cheers,

Regards,
Xavier

Bug#912284: nginx FTCBFS: multiple reasons

[Helmut Grohne]

Source: nginx
Version: 1.14.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

nginx fails to cross build from source for multiple reasons. Upstream
does not support cross compilation and it is not clear whether doing so
is feasible at all. Yet, I found a number of easy fixes I would like to
share with you:

 * debian/rules checks DEB_BUILD_ARCH for sparc, but it should be
   checking DEB_HOST_ARCH.
 * debian/rules should be passing documented options such as
   --crossbuild or --with-cc to ./configure.
 * auto/cc/name requires running compiled binaries, but that's not
   strictly necessary.
 * auto/types/sizeof also requires running compiled binaries.

The attached patch fixes all of the issues above. After applying it,
nginx fails finding accept4, struct in6_pktinfo and NGX_SYS_NERR.
Likely, some checks are still broken. Still I think that the patch is an
incremental step in the right direction. Please consider applying it and
close this bug when doing so.

Helmut
diff --minimal -Nru nginx-1.14.0/debian/changelog nginx-1.14.0/debian/changelog
--- nginx-1.14.0/debian/changelog   2018-08-31 14:28:04.0 +0200
+++ nginx-1.14.0/debian/changelog   2018-10-29 20:57:17.0 +0100
@@ -1,3 +1,10 @@
+nginx (1.14.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross compilation: (Closes: #-1)
++ Fix build/host confusion in debian/rules.
++ Pass --crossbuild and --with-cc to ./configure for cross compilation.
++ cross.patch: Detect C compiler without running host binaries.
++ cross.patch: Make auto/types/sizeof work without running host binaries.
+
+ -- Helmut Grohne   Mon, 29 Oct 2018 20:57:17 +0100
+
 nginx (1.14.0-1) unstable; urgency=medium
 
   [ Kartik Mistry ]
diff --minimal -Nru nginx-1.14.0/debian/patches/cross.patch 
nginx-1.14.0/debian/patches/cross.patch
--- nginx-1.14.0/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ nginx-1.14.0/debian/patches/cross.patch 2018-10-29 20:57:17.0 
+0100
@@ -0,0 +1,86 @@
+--- nginx-1.14.0.orig/auto/cc/name
 nginx-1.14.0/auto/cc/name
+@@ -7,7 +7,7 @@
+ 
+ ngx_feature="C compiler"
+ ngx_feature_name=
+-ngx_feature_run=yes
++ngx_feature_run=compile
+ ngx_feature_incs=
+ ngx_feature_path=
+ ngx_feature_libs=
+--- nginx-1.14.0.orig/auto/types/sizeof
 nginx-1.14.0/auto/types/sizeof
+@@ -26,8 +26,8 @@
+ $NGX_INCLUDE_AUTO_CONFIG_H
+ 
+ int main(void) {
+-printf("%d", (int) sizeof($ngx_type));
+-return 0;
++int x[sizeof($ngx_type) == 8 ? 1 : -1] = {};
++return x;
+ }
+ 
+ END
+@@ -36,27 +36,35 @@
+ ngx_test="$CC $CC_TEST_FLAGS $CC_AUX_FLAGS \
+   -o $NGX_AUTOTEST $NGX_AUTOTEST.c $NGX_LD_OPT $ngx_feature_libs"
+ 
+-eval "$ngx_test >> $NGX_AUTOCONF_ERR 2>&1"
+-
+-
+-if [ -x $NGX_AUTOTEST ]; then
+-ngx_size=`$NGX_AUTOTEST`
++if eval "$ngx_test >> $NGX_AUTOCONF_ERR 2>&1"; then
++ngx_size=8
+ echo " $ngx_size bytes"
+-fi
++ngx_max_value=9223372036854775807LL
++ngx_max_len='(sizeof("-9223372036854775808") - 1)'
++else
++cat << END > $NGX_AUTOTEST.c
+ 
++#include 
++#include 
++$NGX_INCLUDE_UNISTD_H
++#include 
++#include 
++#include 
++$NGX_INCLUDE_INTTYPES_H
++$NGX_INCLUDE_AUTO_CONFIG_H
+ 
+-case $ngx_size in
+-4)
++int main(void) {
++int x[sizeof($ngx_type) == 4 ? 1 : -1] = {};
++return x;
++}
++
++END
++if eval "$ngx_test >> $NGX_AUTOCONF_ERR 2>&1"; then
++ngx_size=4
++echo " $ngx_size bytes"
+ ngx_max_value=2147483647
+ ngx_max_len='(sizeof("-2147483648") - 1)'
+-;;
+-
+-8)
+-ngx_max_value=9223372036854775807LL
+-ngx_max_len='(sizeof("-9223372036854775808") - 1)'
+-;;
+-
+-*)
++else
+ echo
+ echo "$0: error: can not detect $ngx_type size"
+ 
+@@ -69,7 +77,8 @@
+ rm -rf $NGX_AUTOTEST*
+ 
+ exit 1
+-esac
++fi
++fi
+ 
+ 
+ rm -rf $NGX_AUTOTEST*
diff --minimal -Nru nginx-1.14.0/debian/patches/series 
nginx-1.14.0/debian/patches/series
--- nginx-1.14.0/debian/patches/series  2018-08-31 14:28:04.0 +0200
+++ nginx-1.14.0/debian/patches/series  2018-10-29 20:57:17.0 +0100
@@ -1,2 +1,3 @@
 0002-Make-sure-signature-stays-the-same-in-all-nginx-buil.patch
 0003-define_gnu_source-on-other-glibc-based-platforms.patch
+cross.patch
diff --minimal -Nru nginx-1.14.0/debian/rules nginx-1.14.0/debian/rules
--- nginx-1.14.0/debian/rules   2018-08-31 14:28:04.0 +0200
+++ nginx-1.14.0/debian/rules   2018-10-29 20:57:17.0 +0100
@@ -1,6 +1,7 @@
 #!/usr/bin/make -f
 export DH_VERBOSE=1
 
+include /usr/share/dpkg/architecture.mk
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 debian_cflags:=$(shell dpkg-buildflags --get CFLAGS) -fPIC $(shell 
dpkg-buildflags --get CPPFLAGS)
 debian_ldflags:=$(shell dpkg-buildflags --get LDFLAGS) -fPIC
@@ -31,8 +32,7 @@
 BASEDIR = $(CURDIR)
 $(foreach flavour,$(FLAVOURS),$(eval BUILDDIR_$(flavour) = 

Bug#912272: staden-io-lib FTBFS: dh_installdocs: Cannot find (any matches for) "README" (tried in .)

[Niels Thykier]

Helmut Grohne:
> Source: staden-io-lib
> Version: 1.14.9-4
> Severity: serious
> Tags: ftbfs
> 
> staden-io-lib fails to build from source in unstable. This smells a bit
> like a debhelper regression, but I'm not sure actually. In any case, it
> fails to build reliably.
> 
> |dh_installdocs -O--no-parallel
> | dh_installdocs: Cannot find (any matches for) "README" (tried in .)
> | 
> | make: *** [debian/rules:11: binary] Error 2
> | dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
> exit status 2
> 
> Helmut
> 

That is a real issue in staden-io-lib.  The
debian/staden-io-lib-utils.docs file lists "README" but there is no
"README" in the source root.

Note that there was a regression in debhelper's reporting of such issues
which was fixed in debhelper/11.3.5 (#902355).  This can explain why
this issue was not noticed until now.

Thanks,
~Niels

Bug#897846: HELP needed for uploading a new debianisation of the Rheolef package

[Pierre Saramito]

Hi Andreas, 

I just commit with git a new release 7.0-2 of the debianisation 
of the rheolef package: it fixes a FTBS bug #897846 (see d/changelog). 

The upstream version is unchanged (7.0). 

Could you please upload it in debian ? 

Many thanks for your help. 

Best regards, 

Pierre 
-- 
Laboratoire Jean Kuntzmann, Grenoble, France 
http://ljk.imag.fr/membres/Pierre.Saramito 

Bug#912283: Unable to get name "org.gnome.zeitgeist.datahub" on the bus

[shirish शिरीष]

Package: zeitgeist-datahub
Version: 1.0.1-0.2+b1
Severity: normal

Dear all,

Get the following warning in .xsession-errors -

** (zeitgeist-datahub:25130): WARNING **: 01:33:37.467:
zeitgeist-datahub.vala:224: Unable to get name
"org.gnome.zeitgeist.datahub" on the bus!

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

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

Versions of packages zeitgeist-datahub depends on:
ii  libatk1.0-0  2.30.0-1
ii  libc62.27-6
ii  libcairo-gobject21.16.0-1
ii  libcairo21.16.0-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  libjson-glib-1.0-0   1.4.4-1
ii  libpango-1.0-0   1.42.4-3
ii  libpangocairo-1.0-0  1.42.4-3
ii  libtelepathy-glib0   0.24.1-2
ii  libzeitgeist-2.0-0   1.0.1-0.2+b1
ii  zeitgeist-core   1.0.1-0.2+b1

zeitgeist-datahub recommends no packages.

zeitgeist-datahub suggests no packages.

-- no debconf information

-- 
  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#912282: fonts-cantarell: U+0335 to U+0338 do not visually combine with the previous glyph

[Thibaut Girka]

Package: fonts-cantarell
Version: 0.111-2
Severity: normal

In Gtk3 applications such as gucharmap, combining characters U+0335 to U+0338
do not visually combine to the previous character.
Because of this, since they have null width, they visually combine with the
*next* character.

E.g., “a̸” should show as a with a “long solidus” (U+0338) overlayed, but this
is overlayed to the next character instead.

This does not occur with other fonts such as those of the DejaVu family.



-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  fontconfig 2.13.1-1 amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.8.1-2  amd64FreeType 2 font engine, shared 
library files
ii  libfreetype6:i386  2.8.1-2  i386 FreeType 2 font engine, shared 
library files
ii  libxft2:amd64  2.3.2-2  amd64FreeType-based font drawing 
library for X

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

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

Versions of packages fonts-cantarell depends on:
ii  fontconfig  2.13.1-1

fonts-cantarell recommends no packages.

fonts-cantarell suggests no packages.

-- no debconf information

Bug#911958: [Pkg-nagios-devel] Bug#911958: nagios-nrpe-plugin: On large installations, check_nrpe logs are very spammy around nrpe packet version.

[Sebastiaan Couwenberg]

On 10/29/18 8:53 PM, Faidon Liambotis wrote:
> On Mon, Oct 29, 2018 at 06:12:21PM +0100, Sebastiaan Couwenberg wrote:
>>> Could you explain a little bit more your rationale about this? It feels
>>> to me like a prime candidate for an SPU: serious issue affecting the
>>> overall stability of the system, that has a tiny, safe and easily
>>> backportable patch.
>>
>> The version packet logging is not a serious issue, it's a normal or
>> minor issue as it doesn't affect the usability of the package.
>>
>> If this causes an issue on large installation as reported in the OP,
>> then logrotate can be used to rotate the logs more frequently. Or the
>> newer version from stretch-backports can be installed.
> 
> I disagree on that -- excessive and spurious logging is a serious issue
> and filling up logs of the Nagios server fast is as well. Logrotate
> helps, but not with that rate, and regardless, not a great solution
> either (the logs become just an endless sea of garbage).

Then we'll have to agree to disagree. As maintainer of the package I
have evaluated the severity of this issue, and not deemed it high enough
to be eligible for a stable update.

> And really, what's the downside? These logs are useless; the patch is
> upstream, is tiny, safe and easily backportable. If you're concerned
> about the effort... I'd be happy to provide patches and/or NMU!

If you're going to the effort to patch the package, why bother arguing
in this issue? Just provide the package in your local repo and be done
with it.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#864082: fontconfig: please make the cache files reproducible

[Chris Lamb]

forwarded 864082 
https://lists.freedesktop.org/archives/fontconfig/2018-October/006374.html
thanks

Chris Lamb wrote:

> On this. Indeed, I can reproduce it […]

Can also confirm that SOURCE_DATE_EPOCH is available in the
postinst and to fc-cache itself;locally added some printf(3)
statements to FcDirChecksum.

> @@ -1,5 +1,5 @@
> +7fd806a4-197a-4989-8a34-2c49019d041b-le64.cache-7
> +95c367ca-9c9b-47d7-9625-c03688da4239-le64.cache-7
>  CACHEDIR.TAG
> -a4fcff53-9cdb-4103-baea-3115d0f9e21e-le64.cache-7
> -afd762ff-b72e-4c3f-98f5-19b3b7cf7f95-le64.cache-7
> -c8c796f6-9945-4521-bb11-2ad6a193bcf2-le64.cache-7
> -ee218622-3364-4921-aaae-6e7d011e7c5e-le64.cache-7
> +cb3a236e-83c1-49d4-92f9-a44aa67ef71c-le64.cache-7
> +dc12f21a-6ea1-4373-b9e4-cfc7bd8165f7-le64.cache-7

These are uuid's generated by uuid(3)'s uuid_generate_random.

I've sent a patch upstream to:

  https://lists.freedesktop.org/archives/fontconfig/2018-October/006374.html


Best wishes,

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

Bug#900244: smartmontools: NVM error information log entry count increase not an error

[Christian Franke]

Please provide two differing "smartctl -i -l error /dev/nvmeX" outputs 
of an affected device.


The error log may be filled with "Invalid Field in Command" or a similar 
"Generic Command" (0x0) errors.
Smartd should possibly limit the error count to entries with Status Code 
Type "Media and Data Integrity Errors" (0x2).

Bug#912281: elpa-devscripts: please change Recommends to elpa-dpkg-dev-el instead of dpkg-dev-el

[Julian Gilbey]

Package: elpa-devscripts
Version: 40.1
Severity: normal
Tags: patch

Hi!

Thanks for all your work on these packages!

I notice that elpa-devscripts currently Recommends dpkg-dev-el rather
than elpa-dpkg-dev-el.  Please could you change this?

(Also, I notice that these are the only two elpa-* packages which end
with -el.  Wouldn't it make more sense to name them elpa-dpkg-dev and
elpa-debian?  To change it would need two transitional packages
elpa-dpkg-dev-el and elpa-debian-el which could be presumably be
dropped before the freeze, as these two packages only exist in
testing, or at least immediately after the release of buster.)

Best wishes,

   Julian

Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)

[Dmitry Bogatov]

[2018-10-28 00:23] Axel Beckert 
> Dmitry: Welcome! I'm really happy to see you on board!

Hello! Glad to see you too.

> Dmitry: Please try again to push to
> https://salsa.debian.org/debian/sysvinit/ — your account is listed as
> "Given access 2 days ago". So I assume the user database wasn't synced
> as quickly as you gained traction. :-)

I switched from my -guest account to @kaction, and things started to
work. I thought that access is tied to ssh key, but seems it is not.

Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)

[Dmitry Bogatov]

[2018-10-27 17:28] Andreas Henriksson 
> [...]

> Also working towards using the debian/sysvinit repo would likely
> be a good move. It seems like you're using a -guest account on
> salsa, but at the same time you're a DD?! You should have an
> account on salsa matching your debian username (kaction?) which will
> allow you full access to debian/sysvinit. Try using that.

Thank you. I used my @kaction account on salsa, and now it worked.
So now sources of 2.88dsf-60 are on `master' branch on `debian/sysvinit'
repository.

> I'd like to suggest you put the alioth mailinglist back as maintainer
> and put yourself as uploader. That will allow casual bystanders to
> have a chance to follow progress from the sidelines (and hopefully
> that way build up an interest in stepping in). If you want to
> aquire admin access to the mailing list, that can probably be
> arranged by contacting either Ian Jackson or pere.

Seems like a good idea. So, I made two commits on top of
debian/2.88dsf-60, that bring back Uploaders and make Vcs-* fields point
to common debian/sysvinit repository.

Did not upload yet, but Ian, if you want -- go ahead.

> > [Dmitry Bogatov]
> > Oh, and surely, while I did my best to not introduce any functional
> > changes in 2.89-60, brave souls to test upload are more then welcome.
> Unfortunately you seem to have been a little to eager with
> "(lintian?) cleanups" where you broke a few things.
> Please remember to always decide for yourself rather than listen
> to what lintian has to say. Lintian is usually good at "regular"
> packages but very often wrong about "special" packages (like sysvinit,
> et.al.). Also always be very careful and understand all possible
> consequenses when changing LSB headers in central init scripts.
> [...]
> 
> You might want to consider reverting all the LSB header changes and
> adding lintian overrides where needed instead.

You are right. I am sorry about being so reckless to upload.
I made a commits, that revert changes to LSB headers and add Lintian
overrides instead. They are on `wip/revert-lsb-headers', to allow
clean metainfo-only upload from `master' branch.

> PS. I'm personally looking forward to a fix for #799329 finally being
> incorporated. That'll make helping out with testing easier.

Moved this bug upper in my todo list :)

Bug#811377: closed by Dmitry Bogatov (Bug#811377: fixed in sysvinit 2.88dsf-60)

[Dmitry Bogatov]

[2018-10-27 22:47] Ian Jackson 
> I dont have time right now but can you please introduce Dmitry for me
> on debian-init-diversity ?  AIUI he's subscribed to the list.

FWIW, let me introduce myself.

 * my first package dates back to 2014
 * I am DM for about two years, and DD for week or so
 * I maintain several command-line tools, including:
   + cdist configuration management system
   + dvtm terminal multiplexer
   + inotify-tools
   + gdbm
   + mmh mail user agent
   + tup build system
   + bcron (implementation of cron interface)
   + ...
 * I contribute to Haskell team
 * I used to contribute to Emacs team (no longer use Emacs)
 * I write in almost any language, except Java and JavaScript
 * I strongly dislike interfacing anything, that is not usable from tty
 * I strongly prefer Unix way to put-it-all-in way
 * what is most important, I maintain runit supervision and
   initialization system

That is why I am here. runit uses bin:initscripts to do what must be
done at system boot, and for every daemon {foo} falls backs on
/etc/init.d/{foo} if native runscript {foo} is not present. While I do
my best to provide runscript packages, there is ~1300 daemons in Debian.

Should sysvinit get removed from Debian, so are those ~1300 scripts. In
case of such calamity, to keep runit system viable option I would have
to either conjure thousand runscripts instantly, or take burden of
maintaining those sysvinit scripts. I'd like to prevent such a
nightmare.

> It might be worth mentioning that he did an upload to experimental
> intending to adopt the package, unaware of our efforts (in part
> because we failed to write to this RFA bug about them), but that we
> are welcoming him, or some such.

Yes, I have admit it. I made quite rushy upload to experimental.  I
wanted to get things moving. I was scared by talks in @debian-devel,
number of NMU and age of RFA bug.

Bug#911907: monkeysphere: Patch v3

[Sunil Mohan Adapa]

On Monday 29 October 2018 11:50 AM, Sunil Mohan Adapa wrote:
[...]
> 
> I agree that it is better to not expose the environment to runuser. I
> will make the change to use 'env' instead.

Attached the patches do this with /usr/bin/env (better to have full
path?). I have retested all invocations again.

> 
> A bigger concern should be to scrub all environment from the parent root
> user process except for the values that need to be passed down.
> Unfortunately, this is an issue equally problematic in the earlier and
> proposed code.
> 
> # TESTVAR1='test' su -s /bin/bash -c 'set' |grep TESTVAR
> TESTVAR1=test
> 
> # TESTVAR1='test' runuser -u monkeysphere -- bash -c set |grep TESTVAR
> TESTVAR1=test
> 
> I will try to scrub the environment using 'env -i' and see if that
> introduces any breakages.

I tried this and it looks like this requires more changes and time which
I currently am short on. So, I am not proposing 'env -i' at this time.

[...]
> 
> I belive this is because I have libpam-tmpdir installed on my test VM
> (FreedomBox). I will test my next patch without this.

I confirm that I no longer see problems with TMPDIR after removing
libpam-tmpdir from the system.

Thanks,

-- 
Sunil
From 50df0dca1a247be52c17ef5e71e11b73ea03eb0a Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 25 Oct 2018 14:43:57 -0700
Subject: [PATCH] Use runuser instead of su

On systems with restricted PAM security, it may not possible to use su.
---
 src/monkeysphere-authentication |  6 +++---
 src/monkeysphere-host   |  2 +-
 src/share/common| 20 +++-
 src/share/ma/add_certifier  |  2 +-
 src/share/ma/update_users   |  5 +++--
 src/share/mh/add_revoker| 10 +-
 src/share/mh/publish_key|  4 ++--
 7 files changed, 22 insertions(+), 27 deletions(-)

diff --git a/src/monkeysphere-authentication b/src/monkeysphere-authentication
index b3eb1e6..8d6bee0 100755
--- a/src/monkeysphere-authentication
+++ b/src/monkeysphere-authentication
@@ -81,11 +81,11 @@ gpg_sphere() {
 GNUPGHOME="$GNUPGHOME_SPHERE"
 export GNUPGHOME
  
-su_monkeysphere_user gpg --fixed-list-mode --no-greeting --quiet --no-tty "$@"
+run_as_monkeysphere_user gpg --fixed-list-mode --no-greeting --quiet --no-tty "$@"
 }
 
 check_openpgp2ssh_sanity() {
-if [[ `su_monkeysphere_user openpgp2ssh ABC &>/dev/null || echo $?` != "255" ]]; then
+if [[ `run_as_monkeysphere_user openpgp2ssh ABC &>/dev/null || echo $?` != "255" ]]; then
 echo "openpgp2ssh command gives unexpected return code. This can lead to a scenario where no authorized keys are populated, even though they are otherwise valid. Aborting!" 
 exit 1
 fi; 
@@ -137,7 +137,7 @@ GNUPGHOME_SPHERE=${MONKEYSPHERE_GNUPGHOME_SPHERE:="${MADATADIR}/sphere"}
 CORE_KEYLENGTH=${MONKEYSPHERE_CORE_KEYLENGTH:="2048"}
 LOG_PREFIX=${MONKEYSPHERE_LOG_PREFIX:='ms: '}
 
-# export variables needed in su invocation
+# export variables needed for invoking command under monkeysphere user
 export DATE
 export LOG_LEVEL
 export KEYSERVER
diff --git a/src/monkeysphere-host b/src/monkeysphere-host
index 75895e9..089c2b6 100755
--- a/src/monkeysphere-host
+++ b/src/monkeysphere-host
@@ -360,7 +360,7 @@ PROMPT=${MONKEYSPHERE_PROMPT:=$PROMPT}
 GNUPGHOME_HOST=${MONKEYSPHERE_GNUPGHOME_HOST:="${MHDATADIR}"}
 LOG_PREFIX=${MONKEYSPHERE_LOG_PREFIX:='ms: '}
 
-# export variables needed in su invocation
+# export variables needed for invoking command under monkeysphere user
 export DATE
 export LOG_LEVEL
 export KEYSERVER
diff --git a/src/share/common b/src/share/common
index 80ae88a..cccdaaa 100644
--- a/src/share/common
+++ b/src/share/common
@@ -93,20 +93,14 @@ log() {
 }
 
 # run command as monkeysphere user
-su_monkeysphere_user() {
+run_as_monkeysphere_user() {
 # our main goal here is to run the given command as the the
 # monkeysphere user, but without prompting for any sort of
 # authentication.  If this is not possible, we should just fail.
-
-# FIXME: our current implementation is overly restrictive, because
-# there may be some su PAM configurations that would allow su
-# "$MONKEYSPHERE_USER" -c "$@" to Just Work without prompting,
-# allowing specific users to invoke commands which make use of
-# this user.
-
-# chpst (from runit) would be nice to use, but we don't want to
-# introduce an extra dependency just for this.  This may be a
-# candidate for re-factoring if we switch implementation languages.
+#
+# A simple command and its arguments are expected.  Shell
+# expressions are not supported.  If they are required, they may
+# be executed with 'bash -c ""'.
 
 case $(id -un) in
 	# if monkeysphere user, run the command as a subshell
@@ -114,10 +108,10 @@ su_monkeysphere_user() {
 	( "$@" )
 	;;
 
- # if root, su command as monkeysphere user
+ # if root, run command as monkeysphere user
 	'root')
 # requote 

Bug#911958: [Pkg-nagios-devel] Bug#911958: nagios-nrpe-plugin: On large installations, check_nrpe logs are very spammy around nrpe packet version.

[Faidon Liambotis]

On Mon, Oct 29, 2018 at 06:12:21PM +0100, Sebastiaan Couwenberg wrote:
> > Could you explain a little bit more your rationale about this? It feels
> > to me like a prime candidate for an SPU: serious issue affecting the
> > overall stability of the system, that has a tiny, safe and easily
> > backportable patch.
> 
> The version packet logging is not a serious issue, it's a normal or
> minor issue as it doesn't affect the usability of the package.
>
> If this causes an issue on large installation as reported in the OP,
> then logrotate can be used to rotate the logs more frequently. Or the
> newer version from stretch-backports can be installed.

I disagree on that -- excessive and spurious logging is a serious issue
and filling up logs of the Nagios server fast is as well. Logrotate
helps, but not with that rate, and regardless, not a great solution
either (the logs become just an endless sea of garbage).

And really, what's the downside? These logs are useless; the patch is
upstream, is tiny, safe and easily backportable. If you're concerned
about the effort... I'd be happy to provide patches and/or NMU!

Thanks!
Faidon

Bug#912272: staden-io-lib FTBFS: dh_installdocs: Cannot find (any matches for) "README" (tried in .)

[Andreas Tille]

Control: tags -1 pending

Hi Helmut,

On Mon, Oct 29, 2018 at 08:09:25PM +0100, Helmut Grohne wrote:
> staden-io-lib fails to build from source in unstable. This smells a bit
> like a debhelper regression, but I'm not sure actually. In any case, it
> fails to build reliably.
> 
> |dh_installdocs -O--no-parallel
> | dh_installdocs: Cannot find (any matches for) "README" (tried in .)

Strange since the file was renamed to README.md - no idea why this
has built in pbuilder before.

Anyway, fix is under way but needs to pass new since the new upstream
version has a soversion bump.

Thanks for all your QA work

  Andreas.

-- 
http://fam-tille.de

Bug#912280: packagesearch FTCBFS: runs the build architecture qmake

[Helmut Grohne]

Source: packagesearch
Version: 2.7.10
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

packagesearch fails to cross build from source, because it runs the
build architcture qmake. The attached patch passes a cross qmake along
for cross compilation. An alternative fix could be running
dh_auto_configure for each of src and src/plugins. Please consider
applying the patch.

Helmut
diff --minimal -Nru packagesearch-2.7.10/debian/changelog 
packagesearch-2.7.10+nmu1/debian/changelog
--- packagesearch-2.7.10/debian/changelog   2018-10-19 21:50:28.0 
+0200
+++ packagesearch-2.7.10+nmu1/debian/changelog  2018-10-29 20:47:13.0 
+0100
@@ -1,3 +1,10 @@
+packagesearch (2.7.10+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass a cross qmake to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Oct 2018 20:47:13 +0100
+
 packagesearch (2.7.10) unstable; urgency=medium
 
   * fixed build because of included Makefile 
diff --minimal -Nru packagesearch-2.7.10/debian/rules 
packagesearch-2.7.10+nmu1/debian/rules
--- packagesearch-2.7.10/debian/rules   2018-10-19 21:50:28.0 +0200
+++ packagesearch-2.7.10+nmu1/debian/rules  2018-10-29 20:47:11.0 
+0100
@@ -10,17 +10,24 @@
 export DH_VERBOSE=1
 export QT_SELECT=qt5
 
+include /usr/share/dpkg/architecture.mk
+ifeq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+QMAKE = /usr/bin/qmake
+else
+QMAKE = /usr/bin/$(DEB_HOST_GNU_TYPE)-qmake
+endif
+
 %:
dh $@ 
 
 override_dh_auto_build:
docbook-to-man debian/manpage.sgml > debian/packagesearch.1
-   dh_auto_build
+   dh_auto_build -- QMAKE=$(QMAKE)
# not yet ready for release - no popcon data available
rm -f src/plugins/libpopconplugin.so
 
 override_dh_auto_clean:
-   dh_auto_clean
+   dh_auto_clean -- QMAKE=$(QMAKE)
rm -f debian/packagesearch.1
 
 override_dh_installchangelogs:

Bug#912279: ITP: python-django-timezone-field -- database and form fields for pytz objects

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-django-timezone-field
  Version : 3.0
  Upstream Author : Mike Fogel 
* URL : https://github.com/mfogel/django-timezone-field/
* License : BSD-2-clause
  Programming Lang: Python
  Description : database and form fields for pytz objects

A Django app providing database and form fields for pytz timezone objects.

This is a requirement for python-django-celery-beat (>= 1.2.0).

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAlvXY8QRHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WoolAf+NEowzGjtEwE6ey7m9rRDEg8LKAH7WIzL
C55Q1zyF0868Wc5NCOtX4OLVXtPQ8KEYO1iTHgCXsUV7afgzFvsJcev9H7MAQfAO
O/lZceieS03Sto/q2HS0dFN6j9Oxg6nnoKkcRhVOY5h+9+iNfiWH0bLj/jDto8lc
Yz2p4XtIVfPiIzhp6Ca3iVJz2UN+Bap1WTTP/kwiGxq4YaDZ5dZ8OMeXFuxaCEEe
aUzE/o/Esp2SlJbnZ8Cd4rTqWoCe42H8L5P/DxRcAilgDaXrlnaPuinzos75kdjx
HgDVxhDZM0q8rLkd4u8GTHoIrn1fJFnFCEXL7uC6x/xZt5S+SosMcQ==
=zSgM
-END PGP SIGNATURE-

Bug#912278: wala FTBFS with OpenJDK 11

[Adrian Bunk]

Source: wala
Version: 1.3.9-2
Severity: serious
Tags: ftbfs

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

...
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':util:compileJava'.
> error: invalid source release: 1.11

Bug#912277: apache2: does not start any more: AH01903: Failed to configure CA certificate chain!

[Thorsten Glaser]

Package: apache2
Version: 2.4.35-1
Severity: important

After a recent upgrade, apache2 does not start any more:

tglase@tglase:~ $ cat /var/log/apache2/error.log
 
[Mon Oct 29 20:18:58.090841 2018] [ssl:emerg] [pid 17306] AH01903: Failed to 
configure CA certificate chain!
[Mon Oct 29 20:18:58.090919 2018] [ssl:emerg] [pid 17306] AH02311: Fatal error 
initialising mod_ssl, exiting. See /var/log/apache2/error.log for more 
information
AH00016: Configuration Failed

The certificate itself and the chain are ok, though:

tglase@tglase:~ $ openssl verify -CApath /etc/ssl/certs -show_chain -purpose 
sslserver -verify_hostname tglase.lan.tarent.de -untrusted 
/etc/ssl/W_lan_tarent_de.ca /etc/ssl/W_lan_tarent_de.cer
/etc/ssl/W_lan_tarent_de.cer: OK
Chain:
depth=0: CN = *.lan.tarent.de (untrusted)
depth=1: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = RapidSSL TLS RSA 
CA G1 (untrusted)
depth=2: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global 
Root G2

Postfix, on the same system, using the same certificates…
smtpd_tls_cert_file = /etc/ssl/W_lan_tarent_de.cer
smtpd_tls_key_file = /etc/ssl/private/W_lan_tarent_de.key
smtpd_tls_CAfile = /etc/ssl/W_lan_tarent_de.ca
… runs fine, so this must be some regression in Apache2.

-- Package-specific info:

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages apache2 depends on:
ii  apache2-bin2.4.35-1
ii  apache2-data   2.4.35-1
ii  apache2-utils  2.4.35-1
ii  dpkg   1.19.2
ii  lsb-base   9.20170808
ii  mime-support   3.61
ii  perl   5.26.2-7+b1
ii  procps 2:3.3.15-2

Versions of packages apache2 recommends:
ii  ssl-cert  1.0.39

Versions of packages apache2 suggests:
ii  apache2-doc  2.4.35-1
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  dillo [www-browser]  3.0.5-4
ii  links2 [www-browser] 2.17-1
ii  lynx [www-browser]   2.8.9rel.1-2
ii  opera-static [www-browser]   9.64.2480.gcc4.qt3

Versions of packages apache2-bin depends on:
ii  libapr1  1.6.3-3
ii  libaprutil1  1.6.1-3+b1
ii  libaprutil1-dbd-pgsql1.6.1-3+b1
ii  libaprutil1-dbd-sqlite3  1.6.1-3+b1
ii  libaprutil1-ldap 1.6.1-3+b1
ii  libbrotli1   1.0.6-1
ii  libc62.27-6
ii  libcurl4 7.61.0-1
ii  libjansson4  2.11-1
ii  libldap-2.4-22.4.46+dfsg-5+x32.1
ii  liblua5.2-0  5.2.4-1.1+b1
ii  libnghttp2-141.34.0-1
ii  libpcre3 2:8.39-11
ii  libssl1.11.1.1-1
ii  libxml2  2.9.4+dfsg1-7+b1
ii  perl 5.26.2-7+b1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages apache2-bin suggests:
ii  apache2-doc  2.4.35-1
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  dillo [www-browser]  3.0.5-4
ii  links2 [www-browser] 2.17-1
ii  lynx [www-browser]   2.8.9rel.1-2
ii  opera-static [www-browser]   9.64.2480.gcc4.qt3

Versions of packages apache2 is related to:
ii  apache2  2.4.35-1
ii  apache2-bin  2.4.35-1

-- Configuration Files:
/etc/apache2/apache2.conf changed:
DefaultRuntimeDir ${APACHE_RUN_DIR}
PidFile ${APACHE_PID_FILE}
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
HostnameLookups Off
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf
Include ports.conf

Options FollowSymLinks
AllowOverride None
Require all denied


AllowOverride None
Require all granted


Options Indexes FollowSymLinks ExecCGI
AddHandler cgi-script .cgi
AllowOverride None
Require all granted

AccessFileName .htaccess

Require all denied

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" 
combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
IncludeOptional conf-enabled/*.conf
IncludeOptional sites-enabled/*.conf

/etc/apache2/sites-available/default-ssl.conf changed:


ServerAdmin webmaster@localhost

Bug#912194: stretch-pu: package enigmail/2.0.8-5~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2018-10-29 at 01:07 -0400, Daniel Kahn Gillmor wrote:
> Please consider enigmail 2.0.8-5~deb9u1 for inclusion in debian
> stretch.
> 
> Since thunderbird 60 landed in debian stretch via stretch-security,
> the version of enigmail in stretch has been uninstallable.  (see
> https://bugs.debian.org/909000)
> 
> the 2.0.x series upstream is the only supported version of enigmail
> that works with this more recent version of thunderbird.
> 
> Note, however, that due to dependency issues, this version depends on
> some backported features+bugfixes in the gnupg2 package (see
> https://bugs.debian.org/910398).  As a result, the dependency on
> gnupg here is versioned to be >= 2.1.18-8~deb9u3, so that version
> needs to propagate into testing as well.

I assume you mean stable here. :-)

> Note that the requested enigmail version is currently in debian
> unstable and debian testing (buster) and works fine with the packages
> there.
> 
> The debdiff between the version of enigmail currently in stable
> (2:1.9.9-1~deb9u1) and the proposed new version is attached.
> Unfortunately, the upstream changes have made quite a few
> differences.
> Here, i've stripped the debdiff of all image files and other binaries
> that were otherwise shipped so that the debdiff file is manageable.

It was still large enough for the mail to not make it to debian-
release, fwiw.

Please go ahead.

Regards,

Adam

Bug#912276: xmacro FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: xmacro
Version: 0.3pre-2911-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xmacro fails to cross build from source, because debian/rules does not
pass cross tools to make. The easiest way of doing so is deferring to
dh_auto_build. That is sufficient to make xmacro cross buildable. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru xmacro-0.3pre-2911/debian/changelog 
xmacro-0.3pre-2911/debian/changelog
--- xmacro-0.3pre-2911/debian/changelog 2017-01-05 13:50:50.0 
+0100
+++ xmacro-0.3pre-2911/debian/changelog 2018-10-29 20:24:48.0 
+0100
@@ -1,3 +1,10 @@
+xmacro (0.3pre-2911-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 29 Oct 2018 20:24:48 +0100
+
 xmacro (0.3pre-2911-7) unstable; urgency=low
 
   * QA upload.
diff --minimal -Nru xmacro-0.3pre-2911/debian/control 
xmacro-0.3pre-2911/debian/control
--- xmacro-0.3pre-2911/debian/control   2017-01-05 13:43:06.0 
+0100
+++ xmacro-0.3pre-2911/debian/control   2018-10-29 20:24:48.0 
+0100
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Debian QA Group 
-Build-Depends: debhelper (>> 5.0), libx11-dev, libxtst-dev
+Build-Depends: debhelper (>= 7), libx11-dev, libxtst-dev
 Standards-Version: 3.9.2
 
 Package: xmacro
diff --minimal -Nru xmacro-0.3pre-2911/debian/rules 
xmacro-0.3pre-2911/debian/rules
--- xmacro-0.3pre-2911/debian/rules 2017-01-05 13:50:37.0 +0100
+++ xmacro-0.3pre-2911/debian/rules 2018-10-29 20:24:46.0 +0100
@@ -27,9 +27,7 @@
 
 build-stamp: configure-stamp 
dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE)
+   dh_auto_build
#/usr/bin/docbook-to-man debian/xmacro-0.3pre.sgml > xmacro-0.3pre.1
 
touch build-stamp

Bug#912275: uncommons-watchmaker FTBFS with OpenJDK 11

[Adrian Bunk]

Source: uncommons-watchmaker
Version: 0.7.1-1
Severity: serious
Tags: ftbfs buster sid

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

...
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':framework:compileJava'.
> error: invalid source release: 1.11

Bug#912274: ruby-clockwork FTBFS: Mocha::NotInitializedError: Mocha methods cannot be used outside the context of a test

[Helmut Grohne]

Source: ruby-clockwork
Version: 1.2.0-3
Severity: serious
Tags: ftbfs

ruby-clockwork fails to build from source in unstable.

|   1) Error:
| Clockwork::Event::#thread?::manager config thread option set to 
true#test_0001_is true:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/event_test.rb:12:in `block (4 levels) in '
| 
|   2) Error:
| Clockwork::Event::#thread?::manager config thread option set to 
true#test_0002_is false when event thread option set:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/event_test.rb:12:in `block (4 levels) in '
| 
|   3) Error:
| Clockwork::Manager#test_0013_exceptions still set the last timestamp to avoid 
spastic error loops:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/manager_test.rb:131:in `block (2 levels) in '
| 
|   4) Error:
| Clockwork#test_0006_support module re-open style:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/clockwork_test.rb:80:in `block (2 levels) in '
| 
|   5) Error:
| Clockwork#test_0001_should run events with configured logger:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/clockwork_test.rb:24:in `block (2 levels) in '
| 
|   6) Error:
| Clockwork#test_0002_should log event correctly:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/clockwork_test.rb:37:in `block (2 levels) in '
| 
|   7) Error:
| Clockwork#test_0004_should not run anything after reset:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/clockwork_test.rb:62:in `block (2 levels) in '
| 
|   8) Error:
| Clockwork#test_0003_should pass event without modification to handler:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/clockwork_test.rb:50:in `block (2 levels) in '
| 
|   9) Error:
| Clockwork#test_0005_should pass all arguments to every:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/clockwork_test.rb:69:in `block (2 levels) in '
| 
|  10) Error:
| Clockwork::Event::#thread?::manager config thread option not set#test_0001_is 
true if event thread option is true:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/event_test.rb:28:in `block (4 levels) in '
| 
|  11) Error:
| Clockwork::Manager::max_threads#test_0001_should warn when an event tries to 
generate threads more than max_threads:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/manager_test.rb:276:in `block (3 levels) in '
| 
|  12) Error:
| Clockwork::Manager::max_threads#test_0002_should not warn when thread is 
managed by others:
| Mocha::NotInitializedError: Mocha methods cannot be used outside the context 
of a test
| /<>/test/manager_test.rb:291:in `block (3 levels) in '
| 
| 85 runs, 139 assertions, 0 failures, 12 errors, 0 skips
| rake aborted!
| Command failed with status (1): [ruby -w -I"test"  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/at_test.rb" 
"test/clockwork_test.rb" "test/database_events/sync_performer_test.rb" 
"test/event_test.rb" "test/manager_test.rb" 
"test/database_events/test_helpers.rb" -v]
| 
| Tasks: TOP => default
| (See full trace by running task with --trace)
| ERROR: Test "ruby2.5" failed. Exiting.
| dh_auto_install: dh_ruby --install /<>/debian/ruby-clockwork 
returned exit code 1
| make: *** [debian/rules:6: binary] Error 1
| dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

Helmut

Bug#908989: thunderbird: AppArmor denies access to /etc/ld.so.conf

[Carsten Schoenert]

Hello Vincas,

Am 29.10.18 um 19:44 schrieb Vincas Dargis:
> On Mon, 29 Oct 2018 20:32:21 +0200 Vincas Dargis  wrote:
>> Looks like I've already fixed it some time ago:
> 
> Although, that's only for latest AppArmor, meanwhile it will not help
> for Debian Stable releases. On the over hand, maybe deny is
> introduced by some newer library, which is only available in
> Buster...>
> I could try Thunderbird from experimental on Stretch to test that (if
> that's possible).

currently there is no version of TB in experimental (it's on my list of
plannings :) ). Currently it looks like if we have tomorrow a new ESR
version 60.3.0.

If some features of AppArmor are not available in Stretch we probably
need to document this somehow so we can point users to this file then.

-- 
Regards
Carsten Schoenert

Bug#912198: stretch-pu: package spamassassin/3.4.2-1~deb9u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2018-10-28 at 23:11 -0700, Noah Meyerhans wrote:
> I have prepared an upload for stretch that is a backport of the
> 3.4.2-1 package currently in testing. The changelog entries from
> 3.4.1-6 to 3.4.2-1~deb9u1 are below. Note that stretch currently
> contains 3.4.1-6+deb9u1. The changes in that version are included in
> the 3.4.1-7 entry in the backport.
> 
> The debdiff for the debian/ subdirectory is attached. I pruned the
> upstream changes, since they result in a large diff, but can provide
> them if you want.

Yes, please.

>   * Add Multi-Arch: foreign headers to package definitions (Closes:
> #850454)

>From an initial look through the changes, this is one we wouldn't
usually include in a stable update. (It's not m-a:same at least, but
I'm not convinced we want to be changing m-a headers in stable in
general, unless they can be shown to fix specific issues, usually in
the upgrade path.)

Regards,

Adam

Bug#912235: Bug#912235: figtree FTBFS with OpenJDK 11

[Andreas Tille]

Hi Fabian,

On Mon, Oct 29, 2018 at 04:41:56PM +0100, Fabian Klötzl wrote:
> Thank you for reporting. I added a fix to the repo. Will get resolved with
> the next upload.

I've seen your patch to enforce Java 8.  I'm not sure whether this is a
sustainable solution.  Did you pointed upstream to the issue and asked
for upgrading to Java 11?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#912273: unsafe-mock FTBFS with OpenJDK 11

[Adrian Bunk]

Source: unsafe-mock
Version: 8.0-2
Severity: serious
Tags: ftbfs

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

...
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 1.499 s
[INFO] Finished at: 2018-10-29T06:59:56-12:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) 
on project unsafe-mock: Compilation failure
[ERROR] /build/1st/unsafe-mock-8.0/src/main/java/sun/misc/Unsafe.java:[83,34] 
cannot find symbol
[ERROR]   symbol:   class Reflection
[ERROR]   location: package sun.reflect
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/build/1st/unsafe-mock-8.0 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/build/1st/unsafe-mock-8.0/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/build/1st/unsafe-mock-8.0/debian 
-Dmaven.repo.local=/build/1st/unsafe-mock-8.0/debian/maven-repo --batch-mode 
package -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1
make: *** [debian/rules:4: build] Error 2

Bug#912272: staden-io-lib FTBFS: dh_installdocs: Cannot find (any matches for) "README" (tried in .)

[Helmut Grohne]

Source: staden-io-lib
Version: 1.14.9-4
Severity: serious
Tags: ftbfs

staden-io-lib fails to build from source in unstable. This smells a bit
like a debhelper regression, but I'm not sure actually. In any case, it
fails to build reliably.

|dh_installdocs -O--no-parallel
| dh_installdocs: Cannot find (any matches for) "README" (tried in .)
| 
| make: *** [debian/rules:11: binary] Error 2
| dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned 
exit status 2

Helmut

Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure

[Jan Kowalsky]

to mention: with version 1.3.5.17-2 in stretch everything works fine again.

Bug#911334: [Piuparts-devel] Bug#911334: Create /dev/ptmx like debootstrap does

[Holger Levsen]

On Mon, Oct 29, 2018 at 06:33:50PM +0100, Mathieu Parent wrote:
> This was hard work for me (I even wrote a minimum C program), but I've
> learnt more things.

:) nice.

> > If not, I suppose the changelog entry should be clarified...
> Don't know.

I'll guess we'll leave things as they are now. Thanks again for both
your and Andreas' feedback.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#911907: [monkeysphere] Bug#911907: [Pkg-privacy-maintainers] Bug#911907: monkeysphere: Install fails on systems with PAM login restrictions

[Sunil Mohan Adapa]

On Monday 29 October 2018 05:24 AM, Daniel Kahn Gillmor wrote:
[...]
>> # usermod -s /usr/sbin/nologin monkeysphere
>> # su monkeysphere ls
>> This account is currently not available.
>> # runuser --user monkeysphere ls
>> 
> 
> reading the documentation for runuser:
> 
>-s, --shell=shell
>   Run  the  specified  shell instead of the default.  The shell to
>   run is selected according to the following rules, in order:
> 
>  o  the shell specified with --shell
> 
>  o  the shell specified in the environment variable  SHELL
> if the --preserve-environment option is used
> 
>  o  the  shell  listed  in  the passwd entry of the target
> user
> 
>  o  /bin/sh
> 
>   If the target user has a restricted shell (i.e.  not  listed  in
>   /etc/shells)  the --shell option and the SHELL environment vari‐
>   ables are ignored unless the calling user is root.
> 
> 
> which of these cases do you think is triggering the shell selection in
> run_as_monkeysphere_user?
> 

I believe this option is only applicable if we run `runuser -
monkeysphere` and not when we run `runuser --user monkeysphere`.

From runuser man page: "runuser allows to run commands with a substitute
user and group ID. If the option -u is not given, it falls back to
su-compatible semantics and a shell is executed."

Running with -u
---

# usermod -s /bin/dash monkeysphere
# runuser -u monkeysphere --shell /bin/dash sleep 100
runuser: options --{shell,fast,command,session-command,login} and --user
are mutually exclusive

# runuser -u monkeysphere sleep 100
# pstree -ap 8969
bash,8969
  `-runuser,32377 -u monkeysphere sleep 100
  `-sleep,32378 100

Running with -
--

# usermod -s /bin/dash monkeysphere
# runuser monkeysphere -s /bin/dash -c 'sleep 100'
# pstree -ap 8969
bash,8969
  `-runuser,4677 monkeysphere -s /bin/dash -c sleep 100
  `-dash,4678 -c sleep 100
  `-sleep,4679 100
# runuser monkeysphere -c 'sleep 100'
# pstree -ap 8969
bash,8969
  `-runuser,5403 monkeysphere -c sleep 100
  `-dash,5404 -c sleep 100
  `-sleep,5405 100

[..]
>> # TESTVAR1='Hello!' runuser -u monkeysphere -- bash -c 'set' |grep TESTVAR1
>> TESTVAR1='Hello!'
> 
> while we certainly *can* do this, this change means that runuser itself
> will see the changed environment variable, which might affect runuser's
> behavior, or the behavior of the (arbitrary, unknown!) pam stack that
> runuser executes.  Is that really a desirable outcome?  in general, i'd
> lean toward the smallest perturbation possible.  Can we avoid that
> problem?
> 
> What if we replaced "su_monkeysphere_user KEY=value foo arg" with
> "run_as_monkeysphere_user env KEY=value foo arg" instead?

I agree that it is better to not expose the environment to runuser. I
will make the change to use 'env' instead.

A bigger concern should be to scrub all environment from the parent root
user process except for the values that need to be passed down.
Unfortunately, this is an issue equally problematic in the earlier and
proposed code.

# TESTVAR1='test' su -s /bin/bash -c 'set' |grep TESTVAR
TESTVAR1=test

# TESTVAR1='test' runuser -u monkeysphere -- bash -c set |grep TESTVAR
TESTVAR1=test

I will try to scrub the environment using 'env -i' and see if that
introduces any breakages.

> 
>> 4) Redirection expressions like what you have described above currently
>> do not exist. I added documentation that bash expressions should not be
>> run using the method.
> 
> I didn't mean to imply that redirection was the only thing.  what about
> other shell metacharacters, like ';' or '||' ?
> 
> When you say "no shell expressions" in the comments, does that include
> function invocations? variable assignments?

Yes, that includes:

- No function invocations which have been done explicitly using bash -c
'. ; '.

- No shell metacharacters such as '&', ';', '|', '||', '<', '>' etc.

- Variable assignments were done but handled differently in my patch
(above discussion).

> 
>> PS: I ran into issues with TMPDIR as described in #656750 and I am
>> currently working around them.
> 
> hm, this sounds like it might be an interaction across your changes made
> to point 3, above, but i'm not sure how.  can you explain the issues
> you're running into in more detail?  can you explain your workaround?
> 

I belive this is because I have libpam-tmpdir installed on my test VM
(FreedomBox). I will test my next patch without this.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#908989: thunderbird: AppArmor denies access to /etc/ld.so.conf

[Vincas Dargis]

On Mon, 29 Oct 2018 20:32:21 +0200 Vincas Dargis  wrote:

Looks like I've already fixed it some time ago:


Although, that's only for latest AppArmor, meanwhile it will not help for Debian Stable releases. On 
the over hand, maybe deny is introduced by some newer library, which is only available in Buster...


I could try Thunderbird from experimental on Stretch to test that (if that's 
possible).

Bug#912271: please provide a newlib source package

[Matthias Klose]

Package: src:newlib
Version: 3.0.0.20180802-2
Severity: important
Tags: sid buster

The newlib source package doesn't have a nice history. When introducing the
armeabi package, the spu support was dropped without comment, depite packages
depending on it. So please provide a newlib source package ensuring that package
maintainers are independent of random decisions of the newlib package 
maintainers.

Thanks, Matthias

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Mehdi Dogguy]

Sure, but it is still an improvement over the current situation and is simple 
enough to minimize its impact. Of course, it should be considered as a 
wrkaround, until upstream releases a fixed version.


Le 29 octobre 2018 19:41:06 GMT+01:00, Brian Smith 
 a écrit :
>Hi Mehdi,
>
>
>On Mon, Oct 29, 2018 at 4:48 AM Mehdi Dogguy  wrote:
>>
>> Sorry for not replying sooner.
>>
>> On 2018-10-20 17:54, Brian Smith wrote:
>> > The change is in psm2_hal.c. It is a brand new file. Reference the
>> > initialization loop at line 246.
>> >
>>
>> Indeed. The solution described in the github issue looks very fine.
>> Why not uploading it in Debian? It will solve a real issue for users
>> (and reverse dependencies) while giving upstream more time to
>> investigate it.
>>
>> --
>> Mehdi
>
>Thank you for looking it over. I'm still working with upstream to get
>an approved patch. The proposed patch corrects the symptom that
>resulted in this issue, but I can't guarantee it won't cause some
>other aberrant behavior.

-- 
Mehdi

Bug#910485: Confirm issue with libpsm2-2/11.2.68-1

[Brian Smith]

Hi Mehdi,


On Mon, Oct 29, 2018 at 4:48 AM Mehdi Dogguy  wrote:
>
> Sorry for not replying sooner.
>
> On 2018-10-20 17:54, Brian Smith wrote:
> > The change is in psm2_hal.c. It is a brand new file. Reference the
> > initialization loop at line 246.
> >
>
> Indeed. The solution described in the github issue looks very fine.
> Why not uploading it in Debian? It will solve a real issue for users
> (and reverse dependencies) while giving upstream more time to
> investigate it.
>
> --
> Mehdi

Thank you for looking it over. I'm still working with upstream to get
an approved patch. The proposed patch corrects the symptom that
resulted in this issue, but I can't guarantee it won't cause some
other aberrant behavior.

-- 
Brian T. Smith
System Fabric Works
Senior Technical Staff
bsm...@systemfabricworks.com
GPG Key: 0xB3C2C7B73BA3CD7F

Bug#912269: gringo: Please update symbols for riscv64

[Manuel A. Fernandez Montecelo]

Source: gringo
Version: 5.2.3-2
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

This package builds fine for the riscv64 architecture, but symbols need to be
updated.

I am attaching a patch that shows a debdiff, which is basically that update of
the symbols file using pkgkde-symbolshelper.  It built fine in both amd64 and
riscv64 with the new changes.

It would be great if you could include these changes and release a new version
for unstable, at the moment it lives in "unreleased".


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru gringo-5.2.3/debian/changelog gringo-5.2.3/debian/changelog
--- gringo-5.2.3/debian/changelog   2018-07-03 06:23:44.0 +0200
+++ gringo-5.2.3/debian/changelog   2018-10-29 15:03:10.0 +0100
@@ -1,3 +1,10 @@
+gringo (5.2.3-2+0.riscv64.1) unreleased; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/symbols: update symbols for riscv64
+
+ -- Manuel A. Fernandez Montecelo   Mon, 29 Oct 2018 15:03:10 
+0100
+
 gringo (5.2.3-2) unstable; urgency=medium
 
   * debian/symbols: batchpatch symbols
diff -Nru gringo-5.2.3/debian/symbols gringo-5.2.3/debian/symbols
--- gringo-5.2.3/debian/symbols 2018-07-03 06:23:44.0 +0200
+++ gringo-5.2.3/debian/symbols 2018-10-29 15:02:39.0 +0100
@@ -1,36 +1,36 @@
-# SymbolsHelper-Confirmed: 1 alpha amd64 arm64 armel armhf hppa hurd-i386 i386 
ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe 
ppc64 ppc64el s390x sh4 x32
+# SymbolsHelper-Confirmed: 1 alpha amd64 arm64 armel armhf hppa hurd-i386 i386 
ia64 kfreebsd-amd64 kfreebsd-i386 m68k mips mips64el mipsel powerpc powerpcspe 
ppc64 ppc64el riscv64 s390x sh4 x32
 libclingo.so.1 gringo #MINVER#
  (optional=templinst)_ZNKSt5ctypeIcE8do_widenEc@Base 1
  
(optional=templinst)_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE4findERKS5_@Base
 1
  
(optional=templinst)_ZNSt10_HashtableINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_jESaIS8_ENSt8__detail10_Select1stESt8equal_toIS5_ESt4hashIS5_ENSA_18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyENSA_17_Hashtable_traitsILb1ELb0ELb110_M_emplaceIJS8_EEES6_INSA_14_Node_iteratorIS8_Lb0ELb1EEEbESt17integral_constantIbLb1EEDpOT_@Base
 1
  
(optional=templinst|subst)_ZNSt10_HashtableINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_jESaIS8_ENSt8__detail10_Select1stESt8equal_toIS5_ESt4hashIS5_ENSA_18_Mod_range_hashingENSA_20_Default_ranged_hashENSA_20_Prime_rehash_policyENSA_17_Hashtable_traitsILb1ELb0ELb19_M_rehashE{size_t}RK{size_t}@Base
 1
- (optional=templinst|arch=amd64 arm64 armel armhf m68k mips64el ppc64el sh4 
x32|subst)_ZNSt10_HashtableIiSt4pairIKi{uint64_t}ESaIS2_ENSt8__detail10_Select1stESt8equal_toIiESt4hashIiENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeE{size_t}{size_t}PNS4_10_Hash_nodeIS2_Lb0EEE@Base
 1
- (optional=templinst|arch=alpha amd64 arm64 armel armhf hurd-i386 i386 m68k 
mips mips64el mipsel powerpcspe ppc64 ppc64el s390x sh4 
x32|subst)_ZNSt10_HashtableIiSt4pairIKi{uint64_t}ESaIS2_ENSt8__detail10_Select1stESt8equal_toIiESt4hashIiENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb15eraseENS4_20_Node_const_iteratorIS2_Lb0ELb0EEE@Base
 1
- (optional=templinst|arch=alpha amd64 arm64 armel armhf hurd-i386 i386 m68k 
mips mips64el mipsel powerpcspe ppc64 ppc64el s390x sh4 
x32|subst)_ZNSt10_HashtableIiSt4pairIKi{uint64_t}ESaIS2_ENSt8__detail10_Select1stESt8equal_toIiESt4hashIiENS4_18_Mod_range_hashingENS4_20_Default_ranged_hashENS4_20_Prime_rehash_policyENS4_17_Hashtable_traitsILb0ELb0ELb19_M_rehashE{size_t}RK{size_t}@Base
 1
- (optional=templinst|arch=amd64 arm64 armel armhf hppa ia64 kfreebsd-amd64 
m68k mips64el ppc64el sh4 
x32|subst)_ZNSt10_HashtableIjSt4pairIKjPKcESaIS4_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeE{size_t}{size_t}PNS6_10_Hash_nodeIS4_Lb0EEE@Base
 1
- (optional=templinst|arch=!alpha !amd64 !arm64 !ia64 !kfreebsd-amd64 !mips64el 
!ppc64 !ppc64el 
!s390x)_ZNSt10_HashtableIjSt4pairIKjPKcESaIS4_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsILb0ELb0ELb19_M_rehashEjRS1_@Base
 1
- (optional=templinst|arch=alpha amd64 arm64 ia64 kfreebsd-amd64 mips64el ppc64 
ppc64el 
s390x)_ZNSt10_HashtableIjSt4pairIKjPKcESaIS4_ENSt8__detail10_Select1stESt8equal_toIjESt4hashIjENS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsILb0ELb0ELb19_M_rehashEmRKm@Base
 1
+ (optional=templinst|arch=amd64 arm64 armel armhf hppa