Bug#934729: gradle-debian-helper: support dh_auto_test

[merkys]

Package: gradle-debian-helper
Version: 2.0.2

Hello,

gradle-debian-helper does not seem to support dh_auto_test action,
although this would be beneficial. In at least some of the sources I am
interested in (for example [1]), gradle task 'test' is used to run the
test suite. To run it, I may add the following to debian/rules:

override_dh_auto_test:
    dh_auto_build -- test

Nevertheless, proper dh_auto_test would run tests implicitly, as well as
ignore them when DEB_BUILD_OPTIONS=nocheck is supplied. My uneducated
guess is that this could be easily achieved by adding the following code
to /usr/share/perl5/Debian/Debhelper/Buildsystem/gradle.pm:

sub test {
    my $this=shift;

    if (!@_) {
    push(@_, "test");
    }

    $this->build(@_);
}

Best,
Andrius

[1] https://salsa.debian.org/java-team/libejml-java

Bug#934089: firehol fails to use iptables-restore

[Jerome BENOIT]

Dear Jean Louis, thanks for your report.

Have you tried, as suggested in the FireHOL message,

/usr/sbin/firehol nofast try

Please let me know the output of this action, if possible.

Thanks in advance,
Jerome

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



signature.asc
Description: OpenPGP digital signature

Bug#934728: new upstream (7.80)

[Daniel Baumann]

Package: nmap
Severity: wishlist

Hi,

nmap 7.80 was released, it would be nice if you could upload it to unstable.

Regards,
Daniel

Bug#934034: monkeysphere: FTBFS in stretch

[Niels Thykier]

Chris Lamb:
> [Correctly adding t...@release.debian.org to CC...]
> 
> Hi Santiago,
> 
>> For completeness I would also make the build-dependency on gnupg to be
>> versioned.
> 
> Good idea; updated patch attached.
> 
> Stable release managers, would you consider this for the next stretch
> point release?
> 
> 
> Regards,
> 

Hi Chris,

Thanks for considering to fix bugs in stretch.

Please use the process described in [1] to ensure we will get to look at it:

 1) The current bug metadata suggests it affects sid.  Please ensure the
bug is resolved in sid (by fixing it in sid or correcting bug
metadata as appropriate).

 2) File an opu (and a separate pu bug if it also affects buster) with
the full debdiff (including changelog). This ensures that the stable
release team will get have a look at the issue.


We are quite insisting on 2) as it is very hard for us to keep track of
non-bugs requests.  This is a lesson learned time and again (both for us
and Debian contributors).


As for your concrete diff (IANASRM, but my personally take is that): It
looks like something we would accept as stable update. Note that [1]
describes some short cuts that may or may not be applicable to your
situation.

Thanks,
~Niels

[1] https://lists.debian.org/debian-devel-announce/2019/08/msg0.html

Bug#934727: libvanessa-socket-dev: move vanessa-socket.pc to a Multi-Arch location

[Helmut Grohne]

Package: libvanessa-socket-dev
Version: 0.0.13-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:perdition

perdition fails to cross build from source, because it cannot find
vanessa-socket.pc. During cross compilation, pkg-config searches
/usr/share/pkgconfig and /usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig, but
it does not search /usr/lib/pkgconfig. Thus vanessa-socket.pc must be
moved. Please consider applying the attached patch.

Helmut
diff --minimal -Nru vanessa-socket-0.0.13/debian/changelog 
vanessa-socket-0.0.13/debian/changelog
--- vanessa-socket-0.0.13/debian/changelog  2015-06-14 06:53:27.0 
+0200
+++ vanessa-socket-0.0.13/debian/changelog  2019-08-14 06:22:37.0 
+0200
@@ -1,3 +1,10 @@
+vanessa-socket (0.0.13-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move vanessa-socket.pc to a Multi-Arch location. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 14 Aug 2019 06:22:37 +0200
+
 vanessa-socket (0.0.13-1) unstable; urgency=medium
 
   * New Upstream
diff --minimal -Nru vanessa-socket-0.0.13/debian/libvanessa-socket-dev.files 
vanessa-socket-0.0.13/debian/libvanessa-socket-dev.files
--- vanessa-socket-0.0.13/debian/libvanessa-socket-dev.files2014-09-11 
03:26:15.0 +0200
+++ vanessa-socket-0.0.13/debian/libvanessa-socket-dev.files2019-08-14 
06:22:01.0 +0200
@@ -1,8 +1,8 @@
 usr/include/vanessa_socket.h
-usr/lib/libvanessa_socket.so
-usr/lib/libvanessa_socket.a
-usr/lib/libvanessa_socket.la
-usr/lib/pkgconfig/vanessa-socket.pc
+usr/lib/*/libvanessa_socket.so
+usr/lib/*/libvanessa_socket.a
+usr/lib/*/libvanessa_socket.la
+usr/lib/*/pkgconfig/vanessa-socket.pc
 usr/share/doc/libvanessa-socket-dev/changelog.gz
 usr/share/doc/libvanessa-socket-dev/README
 
diff --minimal -Nru vanessa-socket-0.0.13/debian/libvanessa-socket2.files 
vanessa-socket-0.0.13/debian/libvanessa-socket2.files
--- vanessa-socket-0.0.13/debian/libvanessa-socket2.files   2014-09-11 
03:26:15.0 +0200
+++ vanessa-socket-0.0.13/debian/libvanessa-socket2.files   2019-08-14 
06:22:28.0 +0200
@@ -1,2 +1,2 @@
-usr/lib/libvanessa_socket.so.2
-usr/lib/libvanessa_socket.so.2.1.0
+usr/lib/*/libvanessa_socket.so.2
+usr/lib/*/libvanessa_socket.so.2.1.0
diff --minimal -Nru vanessa-socket-0.0.13/debian/rules 
vanessa-socket-0.0.13/debian/rules
--- vanessa-socket-0.0.13/debian/rules  2014-09-11 03:37:45.0 +0200
+++ vanessa-socket-0.0.13/debian/rules  2019-08-14 06:21:25.0 +0200
@@ -2,8 +2,10 @@
 # Sample debian/rules that uses debhelper.
 # GNU copyright 1997 to 1999 by Joey Hess.
 
+include /usr/share/dpkg/architecture.mk
+
 pwd:=$(shell pwd)
-cfg:=--prefix=/usr --mandir=/usr/share/man
+cfg:=--prefix=/usr --mandir=/usr/share/man 
--libdir='$${prefix}/lib/${DEB_HOST_MULTIARCH}'
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk

Bug#934726: acme FTCBFS again: does not pass cross tools to make

[Helmut Grohne]

Source: acme
Version: 1:0.96.4-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

acme fails to cross build from source again, because it does not pass
cross tools to make while building contrib/toacme/src. The easiest way
of fixing that - using dh_auto_build - makes acme cross buildable.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru acme-0.96.4/debian/changelog acme-0.96.4/debian/changelog
--- acme-0.96.4/debian/changelog2019-08-12 08:34:04.0 +0200
+++ acme-0.96.4/debian/changelog2019-08-14 06:13:47.0 +0200
@@ -1,3 +1,10 @@
+acme (1:0.96.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 14 Aug 2019 06:13:47 +0200
+
 acme (1:0.96.4-2) unstable; urgency=medium
 
   * Apply patch to fix -dbgsym packages. (Closes: 934517)
diff --minimal -Nru acme-0.96.4/debian/rules acme-0.96.4/debian/rules
--- acme-0.96.4/debian/rules2019-08-10 20:11:47.0 +0200
+++ acme-0.96.4/debian/rules2019-08-14 06:13:45.0 +0200
@@ -18,7 +18,7 @@
 
 override_dh_auto_build:
dh_auto_build
-   $(MAKE) -C contrib/toacme/src
+   dh_auto_build --sourcedirectory=contrib/toacme/src
 
 override_dh_compress:
dh_compress -X.a -X.exp

Bug#934725: nmu: golang-github-google-pprof_0.0~git20190109.e84dfd6-1

[Drew Parsons]

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

golang-github-google-pprof is holding up other Go packages from
migrating to testing.  pprof itself is not migrating since it was
built by the uploader and never built on the buildds. So this is a
request to build on a buildd to allow migration.

The dependency chain being held up is
  golang-github-google-pprof
  golang-google-cloud
  rclone


nmu golang-github-google-pprof_0.0~git20190109.e84dfd6-1 . ANY . unstable . -m 
"build on buildd to enable migration to testing"

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

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

Bug#923084: Misuse of dh_python3

[Unit 193]

Howdy,

On Wed, 14 Aug 2019, Ben Finney wrote:


On 01-Apr-2019, Unit 193 wrote:


dh_python3 reads [its arguments such that] any path passed as an
argument is prefixed with 'debian/$package/', which in this case
ends up being 'debian/gandi-cli/debian/gandi-cli/...'


I can now confirm this difference.

The original described problem was that Debhelper was reading the
package control stanza's “Depends” field in the source package:

   Depends: ${python3:Depends}, ${misc:Depends}

and incorrectly expanding its “python3:Depends” placeholder to an
empty dependency list in the binary package:

   Depends:

When I change the ‘dh_python3’ arguments as Unit 193 describes, the
resulting “Depends” field in the binary package is:

   Depends: python3-click (>= 7.0), python3-ipy,
   python3-pkg-resources, python3-requests, python3-yaml,
   python3:any

Unit 193, can you confirm that is correct to resolve this bug?


Just passing dh_python3 with no arguments does give me the expected value of

Depends: python3-click (>= 7.0), python3-ipy, python3-pkg-resources,
 python3-requests, python3-yaml, python3:any

So yep, I can indeed confirm!


~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#934724: bugs.debian.org: Kernel Upgrade to 5.2.0-2 Appears to Break WiFi Using Broadcom BCM4352 Adapter

[Kurt Meyer]

Package: linux-headers-5.2.0-2-common:amd64 (5.2.7-1, automatic), 
linux-image-5.2.0-2-amd64:amd64 (5.2.7-1, automatic), 
linux-headers-5.2.0-2-amd64:amd64 (5.2.7-1, automatic), linux-kbuild-5.2:amd64 
(5.2.7-1, automatic)
Severity: important

Dear Maintainer,

Kernel was upgraded to 5.2.0-2 on 08/09/2019. I booted into my Debian Unstable 
partition today and WiFi was not working. I received no notification that 
wireless networks were available and left mouse clicking on the network manager 
applet showed no options for wireless. Booting into kernels 4.19.0-5 or 
4.19.0-4 results in working WiFi.

I've checked kernel.log and I'm not seeing anything that stands out. I've 
checked syslog and I found the following, although I don't know if it's an 
issue:

Aug 13 17:58:39 debian-unstable NetworkManager[691]:  [1565733519.5033] 
NetworkManager (version 1.20.0) is starting... (for the first time)
Aug 13 17:58:39 debian-unstable NetworkManager[691]:  [1565733519.5034] 
Read config: /etc/NetworkManager/NetworkManager.conf (lib: 
no-mac-addr-change.conf)
Aug 13 17:58:39 debian-unstable NetworkManager[691]:  [1565733519.5034] 
config: unknown key 'wifi.cloned-mac-address' in section 
[device-mac-addr-change-wifi] of file 
'/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'
Aug 13 17:58:39 debian-unstable NetworkManager[691]:  [1565733519.5034] 
config: unknown key 'ethernet.cloned-mac-address' in section 
[device-mac-addr-change-wifi] of file 
'/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf'

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)
LSM: AppArmor: enabled

Bug#933848: FTBFS if cmake is installed or if built twice in a row

[Drew Parsons]

Source: pygalmesh
Followup-For: Bug #933848
Control: severity -1 important
Control: tags -1 + moreinfo,unreproducible


There is no cmake-related FTBFS for me.

Fixing the tags for moreinfo,unreproducible

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

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

Bug#923084: Misuse of dh_python3

[Ben Finney]

Control: tags -1 + confirmed pending

On 01-Apr-2019, Unit 193 wrote:

> dh_python3 reads [its arguments such that] any path passed as an
> argument is prefixed with 'debian/$package/', which in this case
> ends up being 'debian/gandi-cli/debian/gandi-cli/...'

I can now confirm this difference.

The original described problem was that Debhelper was reading the
package control stanza's “Depends” field in the source package:

Depends: ${python3:Depends}, ${misc:Depends}

and incorrectly expanding its “python3:Depends” placeholder to an
empty dependency list in the binary package:

Depends:

When I change the ‘dh_python3’ arguments as Unit 193 describes, the
resulting “Depends” field in the binary package is:

Depends: python3-click (>= 7.0), python3-ipy,
python3-pkg-resources, python3-requests, python3-yaml,
python3:any

Unit 193, can you confirm that is correct to resolve this bug?

-- 
 \   “If trees could scream, would we be so cavalier about cutting |
  `\   them down? We might, if they screamed all the time, for no good |
_o__)reason.” —Jack Handey |
Ben Finney 

signature.asc
Description: PGP signature

Bug#842306: ITP: falco -- Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in your applications

[Dean Hamstead]

Falco now has its very own website https://falco.org/

And github https://github.com/falcosecurity/falco

+1 to getting this packaged


On Wed, 2 Nov 2016 12:42:22 +0100 Julien Rabier  
wrote:


> Le 01 nov. à 17:07, Evgeni Golov a écrit :
> > Hi,
> >
> > On Mon, Oct 31, 2016 at 07:04:31PM +0100, Julien Rabier wrote:
> > > > Would you like to join Harlan and me in maintaining sysdig 
itself too?

> > >
> > > Yes, that would be great !
> >
> > You are "taziden-guest" on Alioth? And member of collab-maint?
> > Then there is nothing more to do than to say welcome :)
>
> Yes, that's me indeed !
> I will start working on it some time next week.
>
> Julien/taziden
>
>

Bug#934723: shotwell: Crash when opening google photo login page

[Android Dev]

Package: shotwell
Version: 0.30.4-1
Severity: normal

Steps to reproduce:
- select an image
- click on "Publish"
- the publish dialog opens... choose "Google Photos"
- click the "Log in" button
-> Segmentation fault

A backtrace gives:
#0  0x7fffd5c0cc9b in  () at 
/usr/lib/x86_64-linux-gnu/libshotwell-authenticator.so.0
#1  0x77d8bc7d in g_closure_invoke () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0x77d9f345 in  () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3  0x77da825e in g_signal_emit_valist () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4  0x77da891f in g_signal_emit () at 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5  0x7fffe4b8d4b5 in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#6  0x7fffe4b6e567 in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#7  0x7fffe4984cbb in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#8  0x7fffe4cbbb71 in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#9  0x7fffe4cb3e74 in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#10 0x7fffe48f9409 in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#11 0x7fffe49b3082 in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#12 0x7fffe48f4fab in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#13 0x7fffe48f5bd8 in  () at 
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37
#14 0x7fffd9ca7115 in WTF::RunLoop::performWork() () at 
/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#15 0x7fffd9ca5fc9 in  () at 
/usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18
#16 0x77ca9dd8 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x77caa1c8 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x77caa4c2 in g_main_loop_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x77139583 in gtk_dialog_run () at 
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0
#20 0x55645fbf in publishing_ui_publishing_dialog_run ()
#21 0x556461f5 in publishing_ui_publishing_dialog_go ()


-- Package-specific info:

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

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

Versions of packages shotwell depends on:
ii  dbus-x11 [dbus-session-bus] 1.10.24-0+deb9u1
ii  dconf-cli   0.26.0-2+b1
ii  libc6   2.28-8
ii  libcairo2   1.14.6-1
ii  libexif12   0.6.21-2
ii  libgcr-base-3-1 3.18.0-1
ii  libgcr-ui-3-1   3.18.0-1
ii  libgdata22  0.17.9-3
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u1
ii  libgee-0.8-20.18.0-1
ii  libgexiv2-2 0.10.8-1
ii  libglib2.0-02.58.3-1
ii  libgphoto2-62.5.10-3
ii  libgphoto2-port12   2.5.10-3
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  230-2
ii  libjson-glib-1.0-0  1.2.6-1
ii  libpango-1.0-0  1.42.4-6
ii  libpangocairo-1.0-0 1.42.4-6
ii  libraw190.19.0-3
ii  librsvg2-common 2.40.11-2
ii  libsoup2.4-12.56.0-2+deb9u1
ii  libsqlite3-03.16.2-5+deb9u1
ii  libwebkit2gtk-4.0-372.16.6-0+deb9u1
ii  libxml2 2.9.4+dfsg1-2.2+deb9u2
ii  shotwell-common 0.30.4-1

shotwell recommends no packages.

shotwell suggests no packages.

-- no debconf information

Bug#934661: [PATCH] Keep help files in upstream location

[Aaron Schrab]

tags 934661 patch
thanks

- >8 -

Removing the entire contents due to the missing __init__.py file.
Removing the markdown files from this location prevents the help from
being displayed through the web UI.
---
debian/python3-fava.docs | 1 -
debian/rules | 4 
2 files changed, 5 deletions(-)

diff --git a/debian/python3-fava.docs b/debian/python3-fava.docs
index bd619a9..a1320b1 100644
--- a/debian/python3-fava.docs
+++ b/debian/python3-fava.docs
@@ -1,2 +1 @@
README.rst
-fava/help/
diff --git a/debian/rules b/debian/rules
index f1bf718..d6e9c81 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,6 @@ include /usr/share/dpkg/pkg-info.mk

export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie

-export PYBUILD_AFTER_INSTALL=rm -rf '{destdir}/{install_dir}/fava/help'
export PYBUILD_NAME=fava
%:
dh $@ --with python3 --buildsystem=pybuild
@@ -26,6 +25,3 @@ endif
override_dh_auto_clean:
dh_auto_clean
rm -f debian/manpages/fava.1
-
-override_dh_installdocs:
-   dh_installdocs -X __init__.py -X __pycache__
--
2.23.0.rc1



signature.asc
Description: PGP signature

Bug#934722: urweb: _FORTIFY_SOURCE=2 causes extreme slowdown

[Benjamin Barenblat]

Source: urweb
Version: 20170720+dfsg-2

Ur/Web’s C runtime currently builds with -D_FORTIFY_SOURCE=2 (really,
with DEB_BUILD_MAINT_OPTIONS=hardening=+all), since it’s a library in
the serving path. However, the runtime makes heavy use of %n format
specifiers, and _FORTIFY_SOURCE=2 causes that format specifier to be
incredibly slow:

/tmp$ cat stuff.c
#include 
int main(int argc, char* argv[]) {
  int n;
  for (int i = 0; i < 100; ++i) {
printf("%s%n\n", argv[1], );
printf("%d\n", n);
  }
}
/tmp$ gcc -O3 -o stuff stuff.c
/tmp$ time ./stuff 'Hello, world!' >/dev/null

real0m0.167s
user0m0.167s
sys 0m0.000s
/tmp$ gcc -O3 -D_FORTIFY_SOURCE=1 -o stuff stuff.c
/tmp$ time ./stuff 'Hello, world!' >/dev/null

real0m0.170s
user0m0.170s
sys 0m0.000s
/tmp$ gcc -O3 -D_FORTIFY_SOURCE=2 -o stuff stuff.c
/tmp$ time ./stuff 'Hello, world!' >/dev/null

real0m8.605s
user0m2.058s
sys 0m6.482s

This has been confirmed to affect Ur/Web benchmark results [1, 2].
(Short version: TechEmpower switched from a custom build of Ur/Web to
using the package out of the archive and observed a 100× slowdown.)

One of Ur/Web’s major selling points is its speed, and while hardening
is valuable, users are likely to be surprised by Debian shipping an
Ur/Web that runs orders of magnitude slower than published benchmark
results. We should probably force _FORTIFY_SOURCE=1 in Ur/Web builds.


[1] http://www.impredicative.com/pipermail/ur/2019-July/002850.html
[2] http://www.impredicative.com/pipermail/ur/2019-August/002854.html

Bug#933828: ncbi-tools6/6.1.20170106+dfsg1-0+deb9u1

[Aaron M. Ucko]

"Adam D. Barratt"  writes:

> Please go ahead with the stretch upload.

Uploaded, thanks!

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

Bug#934311: ncbi-tools6/6.1.20170106+dfsg1-0+deb10u1

[Aaron M. Ucko]

"Adam D. Barratt"  writes:

> Please go ahead; thanks.

Uploaded, thanks!

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

Bug#772891: Doodle Mobile

[DEGIOANNI Régine]

لقد تم منحك مبلغ 1،300،000 دولار أمريكي
من مؤسسة عبد الله الغرير دبي ، الإمارات العربية المتحدة
لبرنامج المعونة الإنسانية / تخفيف وطأة الفقر.
الرد على البريد الإلكتروني لدينا: 
em...@online-grant.org
اكتب اسمك
عنوان
رقم
ولاية
الرد على البريد الإلكتروني لدينا: 
em...@online-grant.org



Subject: RE: Doodle Mobile




Envoyé depuis mon mobile Huawei




Régine Degioanni

Enseignante en  Education Socio-culturelle

LEPRP Jeanne Antide

55 impasse du Brévent
74 930 Reignier

04 50 43 87 65

06 47 56 92 10










De : Eric Rigaud mailto:rigauderi...@gmail.com>>
Envoyé : lundi 7 janvier 2019 08:17:00
À : DEGIOANNI Régine
Objet : Doodle Mobile

Découvrez la nouvelle application Doodle Mobile et vivez la puissance de la 
planification sociale https://doodle.com/features/mobile

Envoyé depuis mon mobile Huawei

Bug#934720: osm2pgsql 0.96 tile expiration memory leak

[j]

Package: osm2pgsql
Version: 0.92.0+ds-2
Severity: important
Tags: upstream

Dear Maintainer,

This bug report is for 0.96 from backports, NOT 0.92. To summarize, there 
appears to be a memory leak related to tile expiration. My initial bug report 
to the osm-dev list contains more information and can be found here (i'm afraid 
there are several relevant emails as my testing spanned several days):
https://lists.openstreetmap.org/pipermail/dev/2019-May/030644.html
https://lists.openstreetmap.org/pipermail/dev/2019-May/030645.html
https://lists.openstreetmap.org/pipermail/dev/2019-June/030680.html

Note: anywhere I mentioned '22GB', I should have said ~50GB as I did not 
initially take swap into account.

My workaround uses 0.92 output and an external program to emulate what the 
newer tile expiration code is supposed to do:
https://intergalacticdata.com/public_domain/expandExpire.c

At this time, we have chosen to regenerate our map periodically rather than 
expire tiles due to scale/cost of the required infrastructure. As such, I am 
unable to spend the time to create a clean patch.

Thanks for your time.

j

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/1 CPU core)
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: sysvinit (via /sbin/init)

Versions of packages osm2pgsql depends on:
ii  libboost-filesystem1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0  1.62.0+dfsg-4
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-11+deb9u4
ii  libexpat1  2.2.0-2+deb9u2
ii  libgcc11:6.3.0-18+deb9u1
ii  libgeos-3.5.1  3.5.1-3
ii  liblua5.2-05.2.4-1.1+b2
ii  libpq5 11.4-1.pgdg90+1
ii  libproj12  4.9.3-1
ii  libstdc++6 6.3.0-18+deb9u1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages osm2pgsql recommends:
ii  postgis  2.5.2+dfsg-1~exp1.pgdg90+1

osm2pgsql suggests no packages.

-- no debconf information

Bug#934717: xterm: fullscreen:never resource causes "xterm: Unrecognized keyword: never" warning

[Thomas Dickey]

On Tue, Aug 13, 2019 at 07:10:08PM -0400, Greg Klanderman wrote:
> Package: xterm
> Version: 348-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I notice that in xterm 348 (vs 337), I am seeing the following warning when
> starting xterm from a shell:

Actually broken in #347.  Someone reported it a few weeks ago, and I commited
a fix (there's some other items to do for #349, but I'm working on lynx now).

The diff's in my xterm-348b snapshot here:

https://github.com/ThomasDickey/xterm-snapshots

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#934719: RM: task-print-server -- NBS; RoM

[Nicolas Braud-Santoni]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear ftpmaster,

In tasksel/3.54, task-print-server was renamed to task-print-service.

Despite being NBS, it doesn't appear in the latest [cruft-report],
so I am filing this request for removal.


Best,

  nicoo

[cruft-report]: http://ftp-master.debian.org/cruft-report-daily.txt

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1TUiwRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7Mvf3g/9FYuNWO6XoSzN81QdODknxk47g9kD82Mo
thggnXIN9BZZjt9NmPc0Unj3T1Mt05BRzP526yvfRsHGin1q5cZrsBdwjVtuqO0m
m2ojbl5VuDEVIVSuSnVaAYhdMTD3Dz//iuSCAB8bmvzdOPe7W3hytPd9LYW9dnxB
1AJOHw/TPApABaYX4SRGlQXJg8LJw62W20b2v8SJoSsFskWzFhKETqTrakoBgZ4D
RCN0iZvx4AGR01R2JBGi7G4595yhv7Yh76eszL7oD6jzKTvuwsU/8Rn4SGyxxl4s
P/iFtAMMDOeZoUNdWV0WlMRyBOHZLxwm415SOTHs81ZJsaYm/OkSC+XhDf/b4buj
HRURva9jjuuJF4jn9O7WltqKboc9xMrehO7v6IXU+KCT3blK7Fy0fWrlaIbmdmxZ
8tSbu7qNjfP7jF9ob7Ai6ONQpRflM7lNOsyXBh7XzVDdgL+GGDFwpKNJ9cClHCH0
Y+3so5UxUB3m+EDNlH5mMwnQCeejnyLETm9Qeqb4rtxHLEeWNBgqs3sgPpIsSpX5
TPoUlUwW1HGg3P3c6fmwRxvTFMU3GSkBHU3vxy3OoAesZwLW95BxfuTVgsm760Z9
edbFura/03KDSKwDeROUtECpT04M5x9kcuOOX3BpN9HVcdc9pVCKUqsp8tVX3jJ4
rmpAo2Zomhs=
=ugwa
-END PGP SIGNATURE-

Bug#931591: Bug update

[Seth Foley]

Hi Bernhard,

I ran `ulimit -c 0` and started handbrake from the Terminal. I added a 
folder's worth of files to the queue, set the output folder to the 5TB 
external drive, and clicked Start. Handbrake crashed as expected when 
starting the second encoding pass.


The associated `journalctl --no-pager` output is attached as a text 
file. The associated core dump is only 34.1 MB this time. Please let me 
know if there is information I should extract from it, or a separate 
location where I should upload it.


Thanks, --SF
Aug 13 16:20:33 sethix kernel: handbrake[25962]: segfault at 0 ip 
7f7ce7188fb4 sp 7f7cd67fa4e8 error 4 in 
libc-2.28.so[7f7ce7109000+148000]
Aug 13 16:20:33 sethix kernel: Code: 74 12 88 0c 0c 8a 48 03 48 83 c0 04 88 0c 
0c f6 c1 ff 75 d2 48 8d 42 fc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 83 
c0 04 <8a> 08 84 0c 0c 74 21 8a 48 01 84 0c 0c 74 16 8a 48 02 84 0c 0c 74
Aug 13 16:20:33 sethix systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Aug 13 16:20:33 sethix systemd[1]: Started Process Core Dump (PID 26090/UID 0).
Aug 13 16:20:34 sethix systemd-coredump[26091]: Process 25924 (handbrake) of 
user 1000 dumped core.

Stack trace of thread 25962:
#0  0x7f7ce7188fb4 n/a 
(libc.so.6)
#1  0x7f7cebc47e73 n/a 
(libavformat.so.58)
#2  0x7f7cebc48102 n/a 
(libavformat.so.58)
#3  0x7f7cebc48a2e n/a 
(libavformat.so.58)
#4  0x7f7cebc4d187 n/a 
(libavformat.so.58)
#5  0x7f7cebc4d1ee 
avio_open2 (libavformat.so.58)
#6  0x561ecd32d8fd n/a (ghb)
#7  0x561ecd2e4112 n/a (ghb)
#8  0x561ecd317e56 n/a (ghb)
#9  0x561ecd2d607b n/a (ghb)
#10 0x7f7ce9457fa3 
start_thread (libpthread.so.0)
#11 0x7f7ce71e04cf __clone 
(libc.so.6)

Stack trace of thread 25926:
#0  0x7f7ce71d5819 __poll 
(libc.so.6)
#1  0x7f7ce7479136 n/a 
(libglib-2.0.so.0)
#2  0x7f7ce74794c2 
g_main_loop_run (libglib-2.0.so.0)
#3  0x7f7ce7acb0d6 n/a 
(libgio-2.0.so.0)
#4  0x7f7ce74a1415 n/a 
(libglib-2.0.so.0)
#5  0x7f7ce9457fa3 
start_thread (libpthread.so.0)
#6  0x7f7ce71e04cf __clone 
(libc.so.6)

Stack trace of thread 25932:
#0  0x7f7ce71ad720 
__nanosleep (libc.so.6)
#1  0x7f7ce71d8874 usleep 
(libc.so.6)
#2  0x561ecd2cb323 n/a (ghb)
#3  0x561ecd2d607b n/a (ghb)
#4  0x7f7ce9457fa3 
start_thread (libpthread.so.0)
#5  0x7f7ce71e04cf __clone 
(libc.so.6)

Stack trace of thread 25933:
#0  0x7f7ce71ad720 
__nanosleep (libc.so.6)
#1  0x7f7ce71d8874 usleep 
(libc.so.6)
#2  0x561ecd2cb323 n/a (ghb)
#3  0x561ecd2d607b n/a (ghb)
#4  0x7f7ce9457fa3 
start_thread (libpthread.so.0)
#5  0x7f7ce71e04cf __clone 
(libc.so.6)

Stack trace of thread 25925:
#0  0x7f7ce71d5819 __poll 
(libc.so.6)
#1  0x7f7ce7479136 n/a 
(libglib-2.0.so.0)
#2  0x7f7ce747925c 
g_main_context_iteration (libglib-2.0.so.0)
   

Bug#934718: switcheroo-control: Failed to start Switcheroo Control Proxy service

[Eric Heintzmann]

Package: switcheroo-control
Version: 1.2-2
Severity: important

Dear Maintainer,

Switcheroo does not start.

I tried, without success:
$ systemctl restart switcheroo-control

Here is the output of journalctl -xe:

août 14 01:07:20 ARRAKIS systemd[1]: Starting Switcheroo Control Proxy
service...
-- Subject: L'unité (unit) switcheroo-control.service a commencé à démarrer
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) switcheroo-control.service a commencé à démarrer.
août 14 01:07:20 ARRAKIS switcheroo-cont[4510]: switcheroo-control could not
query vga_switcheroo status: Operation not permitted
août 14 01:07:20 ARRAKIS systemd[1]: switcheroo-control.service: Main process
exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit switcheroo-control.service has
exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
août 14 01:07:20 ARRAKIS systemd[1]: switcheroo-control.service: Failed with
result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit switcheroo-control.service has entered the 'failed' state with
result 'exit-code'.
août 14 01:07:20 ARRAKIS systemd[1]: Failed to start Switcheroo Control Proxy
service.
-- Subject: L'unité (unit) switcheroo-control.service a échoué
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) switcheroo-control.service a échoué, avec le résultat failed.

Best regards

PS
I cannot read the switch file:
$ sudo cat /sys/kernel/debug/vgaswitcheroo/switch
cat: /sys/kernel/debug/vgaswitcheroo/switch: Opération non permise



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-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 switcheroo-control depends on:
ii  libc6 2.28-10
ii  libglib2.0-0  2.61.2-1

switcheroo-control recommends no packages.

switcheroo-control suggests no packages.

Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging

[brian m. carlson]

On 2019-08-13 at 06:12:30, Philip Withnall wrote:
> Hi,
> 
> I can’t speak for the Debian project, but as an upstream GLib developer
> I can say such an environment variable would not be welcome upstream.
> 
> Hiding such warnings makes them less likely to be fixed. It’s a way of
> sweeping bugs under the carpet which I don’t want to encourage. Each
> warning emitted by GTK or GLib indicates a non-trivial bug in the code
> which is calling it, which should be fixed.

Unfortunately, it's often impossible to write code which works on
multiple versions of GTK+ without warnings. I took a version of GVim
which worked fine on Debian unstable with GTK+3 but produced copious
warnings on CentOS 7. This makes it difficult for folks who would like
to upgrade one single component on a system without rebuilding the
entire GTK+ stack. In addition, an upgrade of GTK+ can cause previously
working programs to produce errors where they did not before, causing
problems for users.

In addition, Unix programs typically produce output to standard error to
reflect a user-relevant error: something that the user has done wrong or
that prevents the program from functioning in the way the user
requested. These warnings are not user relevant: they reflect a
developer error, not a problem that reflects a user-visible failure.
From the user perspective, everything is functioning as intended, so
output to standard error is not appropriate.

And finally, overwhelmingly, developers take a long time to fix warnings
like this, if they get fixed at all. Perhaps they don't see the use case
of running graphical programs like PDF viewers from the command line.
More likely, they are overwhelmed with other issues and consider this
low priority.

I appreciate that these reflect a defect in the program that should be
fixed, but it isn't fair to force users to either fix these defects for
themselves or deal with terminal junk. As a Git developer, I can tell
you people would be extremely unhappy if libpcre or libcurl produced
errors on their terminals when they ran Git, even if those were bugs in
Git itself. I'm not sure why GLib should be different in this regard.

Ultimately, I think it's most appropriate to let users decide for
themselves if they would like to see non-user-visible issues on their
terminal. I'm not even asking for this to be the default, just an option
users can turn on.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#813815: Open ITPs (turned into RFPs)

[Joost van Baal-Ilić]

Hi Andreas,

On Mon, Jul 22, 2019 at 07:42:06PM +0200, Andreas Tille wrote:
> 
> you have at least two long standing ITPs (#813815 - r-cran-nfactors,
> #835082 - r-cran-semplot, may be others) which were turned into RFPs
> automatically.  Could you give some statement whether these packages
> might remain interesting for you and whether we should fire up
> prepare_missing_cran_package for these?

Thanks for this reminder.  For both r-cran-nfactors and r-cran-semplot there
already _is_ work in our g...@salsa.debian.org:r-pkg-team : at
r-cran-nfactors.git and r-cran-semplot.git .  So no need for
prepare_missing_cran_package for those.

I cannot commit to maintaining these packages appear in a stable Debian
release: I do all my R packaging work during $dayjob; I'm mainly interested in
keeping the packages working on Debian stable, and somewhat in sync with
upsteam.  So that's technically what would end up in debian backports.  The
reason I stick the work in git @ salsa is I feel there's a chance others might
benefit from it too.  That's the reason I've recently not been very active in
actually uploading it to NEW.

There some packages of me in our git now for which I've not yet posted ITP's.
I believe this interferes badly with some of your workflows.  Would it help you
if I actually _would_ post ITP's?  I'd be glad to.

Also, debian/copyright of most of my recent packages is still lacking.  I'll
try to find time to work on that (note to self: have another look at cme).

What do you think?

Bye,

Joost

PS: thanks for your talk @ debconf, I enjoyed the video!

Bug#934717: xterm: fullscreen:never resource causes "xterm: Unrecognized keyword: never" warning

[Greg Klanderman]

Package: xterm
Version: 348-1
Severity: normal

Dear Maintainer,

I notice that in xterm 348 (vs 337), I am seeing the following warning when
starting xterm from a shell:

| xterm: Unrecognized keyword: never

This is being caused by the following resource setting:

XTerm*fullscreen: never

and additionally, the resource is not having any effect (fullscreen is not being
inhibited).

I looked briefly at the v348 source and it seemed that "never" is still intended
as a supported value.

thank you,
Greg


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xterm depends on:
ii  libc6   2.28-10
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-4
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20190713-2
ii  libutempter01.1.6-3+b1
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#923481: alpine: replies lose In-Reply-To and References headers

[Unit 193]

Howdy,

On Tue, 13 Aug 2019, Thorsten Glaser wrote:


severity 923481 serious
thanks

(Please remember to Cc the bug submitter when replying.)

On Sat, 9 Mar 2019, Unit 193 wrote:


As I understand it, this is not a regression in alpine but a
difference in how pine and alpine function, correct?


No, this is definitively a serious loss of functionality,
namely, message threading (which is expected to work correctly
in contemporary MUAs excepting those from Redmond).


Ah right.  Though while looking through several of my recent sent items, it 
seems it preserved those fields as expected.  I am using alpine 2.21.


It seems I am unable to reproduce the results you're getting?


~Unit 193
Unit193 @ freenode
Unit193 @ OFTC

Bug#934716: binutils patch applied, package now ftbfs

[Matthias Klose]

Package: src:cross-toolchain-base-mipsen
VersioN: 5
Severity: serious
Tags: sid bullseye

the binutils patch is now applied, and the package now ftbfs. please remove the
patch again.

Bug#932014: lib32stdc++-9-dev-x32-cross: Missing parenthesis in short description

[Matthias Klose]

Fixed in unstable/bullseye.

Bug#925573: gcc-9-cross-ports: incomplete copyright

[Matthias Klose]

Fixed in unstable/bullseye.

Bug#934678: libreoffice-writer: Cropping an image that is flipped does not work as expected

[Vangelis Skarmoutsos]

Package: libreoffice-writer
Version: 1:6.3.0-2
Followup-For: Bug #934678



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8),
LANGUAGE=el_GR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.2-1
ii  libc6  2.28-10
ii  libe-book-0.1-10.1.3-1+b2
ii  libepubgen-0.1-1   0.1.1-1
ii  libetonyek-0.1-1   0.1.9-1
ii  libgcc11:9.1.0-10
ii  libicu63   63.2-2
ii  liblangtag10.6.2-1
ii  libmwaw-0.3-3  0.3.15-2
ii  libodfgen-0.1-10.1.7-1
ii  libreoffice-base-core  1:6.3.0-2
ii  libreoffice-core   1:6.3.0-2
ii  librevenge-0.0-0   0.0.4-6+b1
ii  libstaroffice-0.0-00.0.6-1
ii  libstdc++6 9.1.0-10
ii  libwpd-0.10-10 0.10.3-1
ii  libwpg-0.3-3   0.3.3-1
ii  libwps-0.4-4   0.4.10-1
ii  libxml22.9.4+dfsg1-7+b3
ii  uno-libs3  6.3.0-2
ii  ure6.3.0-2
ii  zlib1g 1:1.2.11.dfsg-1+b1

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:6.3.0-2

Versions of packages libreoffice-writer suggests:
ii  default-jre [java6-runtime] 2:1.11-72
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  libreoffice-base1:6.3.0-2
ii  libreoffice-java-common 1:6.3.0-2
ii  openjdk-10-jre [java6-runtime]  10.0.2+13-2
ii  openjdk-11-jre [java6-runtime]  11.0.4+11-1
ii  openjdk-8-jre [java6-runtime]   8u212-b01-1
ii  openjdk-9-jre [java6-runtime]   9.0.4+12-4

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-2
ii  fonts-opensymbol2:102.11+LibO6.3.0-2
ii  libboost-date-time1.67.01.67.0-13
ii  libboost-locale1.67.0   1.67.0-13
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1
ii  libclucene-core1v5  2.3.3.4+dfsg-1
ii  libcmis-0.5-5v5 0.5.2-1
ii  libcups22.2.10-6
ii  libcurl3-gnutls 7.65.1-1
ii  libdbus-1-3 1.12.16-1
ii  libdconf1   0.30.1-2
ii  libeot0 0.01-5
ii  libepoxy0   1.5.3-0.1
ii  libexpat1   2.2.7-1
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-4
ii  libgcc1 1:9.1.0-10
ii  libglib2.0-02.60.6-1
ii  libgpgmepp6 1.12.0-6
ii  libgraphite2-3  1.3.13-7
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libharfbuzz-icu02.5.3-1
ii  libharfbuzz0b   2.5.3-1
ii  libhunspell-1.7-0   1.7.0-2+b1
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.9-2
ii  libicu6363.2-2
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-3
ii  libldap-2.4-2   2.4.48+dfsg-1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.30.2-3
ii  libnspr42:4.21-1
ii  libnss3 2:3.45-1
ii  libnumbertext-1.0-0 1.0.5-1
ii  libodfgen-0.1-1 0.1.7-1
ii  liborcus-0.14-0 0.14.1-6
ii  libpng16-16 1.6.37-1
ii  libpoppler820.71.0-5
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:6.3.0-2
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  9.1.0-10
ii  libx11-62:1.6.7-1
ii  libxext62:1.3.3-1+b2
ii  libxinerama12:1.1.4-2
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxmlsec1  1.2.28-2
ii  libxmlsec1-nss  1.2.28-2
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.32-2.1
ii  uno-libs3   6.3.0-2
ii  ure 6.3.0-2
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages libreoffice-core recommends:
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-bad   1.14.4-1+b1
ii  gstreamer1.0-plugins-base  1.14.4-2

Bug#934034: monkeysphere: FTBFS in stretch

[Chris Lamb]

[Correctly adding t...@release.debian.org to CC...]

Hi Santiago,

> For completeness I would also make the build-dependency on gnupg to be
> versioned.

Good idea; updated patch attached.

Stable release managers, would you consider this for the next stretch
point release?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-diff --git a/debian/control b/debian/control
index 95750f4..19c4dbb 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
  cpio,
  debhelper (>= 10~),
  dpkg-dev (>= 1.17.14),
- gnupg ,
+ gnupg (>= 2.1.18-8~deb9u4) ,
  gnupg-agent ,
  libassuan-dev,
  libcrypt-openssl-rsa-perl ,
diff --git a/tests/keytrans b/tests/keytrans
index fd9a144..5b23a16 100755
--- a/tests/keytrans
+++ b/tests/keytrans
@@ -137,9 +137,9 @@ gpg --list-keys
 cat >"$TEMPDIR"/expectedout <"$TEMPDIR"/expectedout <"$TEMPDIR"/expectedout <

Bug#931684: libgit2 0.28 transition and libgit2-glib

[Jongmin Kim]

On Tue, Aug 13, 2019 at 02:08:12PM +0530, Pirate Praveen wrote:
> I'm trying to update in https://salsa.debian.org/praveen/libgit2-glib
> (requested access to gnome-team)

I sent you an MR [1]: updated the symbols, to fix another build failure.

[1] https://salsa.debian.org/praveen/libgit2-glib/merge_requests/1

> 
> But build is failing with this error,
> 
> meson.build:154:2: ERROR: Assert failed: libgit2 ssh support was
> requested, but not found. Use -Dssh=false to build without it.
> 
> I'm not sure if libgit2 build needs fixing.

Actually, ssh was enabled in libgit2. In its CMakeLists.txt:58, we could
see ssh support is enabled by default.

No error reported on chroot without ccache. When I tried with ccache
installed chroot, following same issue was occurred:

  Compiler stderr:
   ccache: error: Failed to create directory
  /sbuild-nonexistent/.ccache/tmp: Permission denied

  Checking if "libgit2 supports SSH" compiles: NO

  meson.build:148:2: ERROR: Assert failed: libgit2 ssh support was
  requested, but not found. Use -Dssh=false to build without it.

The problem seems ccache was installed and its output path (CCACHE_DIR,
default is $HOME/.ccache) is not writable. It seems Meson detects if
ccache installed and use it [2]..

[2] 
https://github.com/mesonbuild/meson/blob/master/docs/markdown/Feature-autodetection.md


-- 
Jongmin Kim

OpenPGP key located at https://jongmin.dev/pgp
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8

PS

Some notes for sbuild and ccache:

sbuild page in Debian wiki [3] guided me to do sbuild-createchroot
including ccache. I found some:

  * To use ccache, [4] should be done after. Setting the `CCACHE_DIR` to
writable path is enough.
  * To not use ccache, re-create the sbuild chroot without
`--include=ccache`.

[3] https://wiki.debian.org/sbuild
[4] https://wiki.debian.org/sbuild#Using_.22ccache.22_with_sbuild


signature.asc
Description: PGP signature

Bug#934678: libreoffice-writer: Cropping an image that is flipped does not work as expected

[Vangelis Skarmoutsos]

Package: libreoffice-writer
Version: 1:6.3.0-2
Followup-For: Bug #934678

bug found



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), 
LANGUAGE=el_GR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice-writer depends on:
ii  libabw-0.1-1   0.1.2-1
ii  libc6  2.28-10
ii  libe-book-0.1-10.1.3-1+b2
ii  libepubgen-0.1-1   0.1.1-1
ii  libetonyek-0.1-1   0.1.9-1
ii  libgcc11:9.1.0-10
ii  libicu63   63.2-2
ii  liblangtag10.6.2-1
ii  libmwaw-0.3-3  0.3.15-2
ii  libodfgen-0.1-10.1.7-1
ii  libreoffice-base-core  1:6.3.0-2
ii  libreoffice-core   1:6.3.0-2
ii  librevenge-0.0-0   0.0.4-6+b1
ii  libstaroffice-0.0-00.0.6-1
ii  libstdc++6 9.1.0-10
ii  libwpd-0.10-10 0.10.3-1
ii  libwpg-0.3-3   0.3.3-1
ii  libwps-0.4-4   0.4.10-1
ii  libxml22.9.4+dfsg1-7+b3
ii  uno-libs3  6.3.0-2
ii  ure6.3.0-2
ii  zlib1g 1:1.2.11.dfsg-1+b1

Versions of packages libreoffice-writer recommends:
ii  libreoffice-math  1:6.3.0-2

Versions of packages libreoffice-writer suggests:
ii  default-jre [java6-runtime] 2:1.11-72
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  libreoffice-base1:6.3.0-2
ii  libreoffice-java-common 1:6.3.0-2
ii  openjdk-10-jre [java6-runtime]  10.0.2+13-2
ii  openjdk-11-jre [java6-runtime]  11.0.4+11-1
ii  openjdk-8-jre [java6-runtime]   8u212-b01-1
ii  openjdk-9-jre [java6-runtime]   9.0.4+12-4

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-2
ii  fonts-opensymbol2:102.11+LibO6.3.0-2
ii  libboost-date-time1.67.01.67.0-13
ii  libboost-locale1.67.0   1.67.0-13
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1
ii  libclucene-core1v5  2.3.3.4+dfsg-1
ii  libcmis-0.5-5v5 0.5.2-1
ii  libcups22.2.10-6
ii  libcurl3-gnutls 7.65.1-1
ii  libdbus-1-3 1.12.16-1
ii  libdconf1   0.30.1-2
ii  libeot0 0.01-5
ii  libepoxy0   1.5.3-0.1
ii  libexpat1   2.2.7-1
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-4
ii  libgcc1 1:9.1.0-10
ii  libglib2.0-02.60.6-1
ii  libgpgmepp6 1.12.0-6
ii  libgraphite2-3  1.3.13-7
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libharfbuzz-icu02.5.3-1
ii  libharfbuzz0b   2.5.3-1
ii  libhunspell-1.7-0   1.7.0-2+b1
ii  libhyphen0  2.8.8-7
ii  libice6 2:1.0.9-2
ii  libicu6363.2-2
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-3
ii  libldap-2.4-2   2.4.48+dfsg-1
ii  libmythes-1.2-0 2:1.2.4-3+b1
ii  libneon27-gnutls0.30.2-3
ii  libnspr42:4.21-1
ii  libnss3 2:3.45-1
ii  libnumbertext-1.0-0 1.0.5-1
ii  libodfgen-0.1-1 0.1.7-1
ii  liborcus-0.14-0 0.14.1-6
ii  libpng16-16 1.6.37-1
ii  libpoppler820.71.0-5
ii  librdf0 1.0.17-1.1+b1
ii  libreoffice-common  1:6.3.0-2
ii  librevenge-0.0-00.0.4-6+b1
ii  libsm6  2:1.2.3-1
ii  libstdc++6  9.1.0-10
ii  libx11-62:1.6.7-1
ii  libxext62:1.3.3-1+b2
ii  libxinerama12:1.1.4-2
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libxmlsec1  1.2.28-2
ii  libxmlsec1-nss  1.2.28-2
ii  libxrandr2  2:1.5.1-1
ii  libxrender1 1:0.9.10-1
ii  libxslt1.1  1.1.32-2.1
ii  uno-libs3   6.3.0-2
ii  ure 6.3.0-2
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages libreoffice-core recommends:
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-bad   1.14.4-1+b1
ii  

Bug#934034: monkeysphere: FTBFS in stretch

[Chris Lamb]

[Adding rele...@lists.debian.org to CC]

Hi Santiago,

> For completeness I would also make the build-dependency on gnupg to be
> versioned.

Good idea; updated patch attached.

Stable release managers, would you consider this for the next stretch
point release?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-diff --git a/debian/control b/debian/control
index 95750f4..19c4dbb 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
  cpio,
  debhelper (>= 10~),
  dpkg-dev (>= 1.17.14),
- gnupg ,
+ gnupg (>= 2.1.18-8~deb9u4) ,
  gnupg-agent ,
  libassuan-dev,
  libcrypt-openssl-rsa-perl ,
diff --git a/tests/keytrans b/tests/keytrans
index fd9a144..5b23a16 100755
--- a/tests/keytrans
+++ b/tests/keytrans
@@ -137,9 +137,9 @@ gpg --list-keys
 cat >"$TEMPDIR"/expectedout <"$TEMPDIR"/expectedout <"$TEMPDIR"/expectedout <

Bug#934715: libcryptsetup12: crypt_keyslot_add_by_volume_key() fails on a LUKS2 header where all bound key slots were deleted

[Guilhem Moulin]

Package: libcryptsetup12
Version: 2:2.1.0-7
Severity: important
Tags: upstream

(Cloning upstream issue #466 so we can track it for Buster, Bullseye and sid.)

Even when all (bound) key slots were removed from a LUKS header, the header is
still salvageable given a copy of the master key.

The crypt_keyslot_add_by_volume_key() API call works for LUKSv1 headers
without keyslot, but fails for LUKSv2:

$ dd if=/dev/zero of=./disk.img bs=1M count=64
$ cryptsetup luksFormat --pbkdf-force-iterations 1000 \
--type luks1 -q ./disk.img <<#include 
#include 
#include 

#include "libcryptsetup.h"

int main(int argc, char *argv[]) {
struct crypt_device *cd = NULL;
if (crypt_init(, argv[1]))
errx(EXIT_FAILURE, "Error: crypt_init");

if (crypt_load(cd, NULL, NULL))
errx(EXIT_FAILURE, "Error: crypt_load");

size_t vk_size = crypt_get_volume_key_size(cd);
char *volume_key = malloc(vk_size);

int keyslot = crypt_volume_key_get(cd, CRYPT_ANY_SLOT, volume_key, _size,
argv[2], strlen(argv[2]));
if (keyslot < 0)
errx(EXIT_FAILURE, "Error: crypt_volume_key_get");

if (crypt_keyslot_destroy(cd, keyslot))
errx(EXIT_FAILURE, "Error: crypt_keyslot_destroy");

if (crypt_keyslot_add_by_volume_key(cd, keyslot, volume_key, vk_size,
argv[3], strlen(argv[3])))
errx(EXIT_FAILURE, "Error: crypt_keyslot_add_by_volume_key");

return EXIT_SUCCESS;
}


signature.asc
Description: PGP signature

Bug#934711: Please package latest upstream, and switch to Python 3

[GCS]

Control: severity -1 normal
Control: tags -1 pending

On Tue, Aug 13, 2019 at 9:48 PM Thomas Goirand  wrote:
> We're trying to remove Python 2 for Bullseye.
 Yup, I do know it like you.

> Please package the latest version upstream which has support for Python 3,
> and remove Python 2 support / use.
 I'm working on it. A day or two and it will be uploaded.

Regards,
Laszlo/GCS

Bug#934590: [Mlt-devel] Bug#934590: libmlt-data: The package became bloated

[Горбешко Богдан]

On 13.08.2019 22:22, Dan Dennedy wrote:
On Mon, Aug 12, 2019 at 5:27 AM Patrick Matthäi > wrote:


Am 12.08.2019 um 13:11 schrieb Горбешко Богдан:
> Package: libmlt-data
> Version: 6.16.0-3
> Severity: minor
>
> Dear Maintainer,
>
> After the last upgrade, the package became about 230 MBs larger,
> because of a lot of large lumas in PGM format, each about 4 MBs. Is
> there an important reason to keep them uncompressed on a disk? Even
> the fast GZip compression can drastically reduce their size.
>
Hi Dan,

what is your opionion about this? This is the list of the affected
files:


This was intentional to produce transitions with the correct aspect 
ratio. The PGM images cannot be simply gzip compressed because the PGM 
reader in MLT is not integrated with zlib. Instead, the package can 
use the configure option --luma-compress to output compressed PNG. 
However, these are 8-bit instead of the 16-bit PGM, which provides 
better quality transitions. Since these are procedurally-generated, I 
started working on a change to generate the image on-demand instead of 
reading a file. I plan to do that for the next release.



Okay; thanks for explanation!

Bug#934714: RFA: yojson -- JSON library for OCaml

[Stéphane Glondu]

Package: wnpp
Severity: normal

Hello,

Currently, yojson has no human maintainers. It is maintained by
the Debian OCaml team because of the need of transition coordination,
but needs more love and a dedicated maintainer.

A potential maintainer should get familiar with [1], and in particular
with our policy and practices, and get subscribed to our mailing-list.

[1] http://wiki.debian.org/Teams/OCamlTaskForce


Cheers,

-- 
Stéphane

Bug#934713: os-prober: missing dependency on mount

[Johannes 'josch' Schauer]

Package: os-prober
Version: 1.76
Severity: important

Hi,

The script /usr/lib/os-probes/50mounted-tests calls the `umount` utility
which resides in the mount package. But os-prober does not depend on
mount and thus one might get this error message:

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.2.0-2-amd64
Found initrd image: /boot/initrd.img-5.2.0-2-amd64
/usr/lib/os-probes/50mounted-tests: 10: umount: not found
rmdir: failed to remove '/var/lib/os-prober/mount': Device or resource busy


The mount package used to be Essential:yes. Since version 2.29.2-3 it is
not essential anymore and os-prober should depend on it.

Thanks!

cheers, josch

Bug#695873: memtest86+: Serial console does not work

[ydirson]

Hi,

Feel free do NMU - thanks much for this :)

- Mail original -
> De: "Louis-Philippe Véronneau" 
> À: 695...@bugs.debian.org
> Envoyé: Mardi 13 Août 2019 21:44:38
> Objet: Bug#695873: memtest86+: Serial console does not work
> 
> Hello!
> 
> I'd be happy to make an NMU to fix this, since:
> 
> * there is a patch
> * the patch was tested by 4 people and it seems to work
> * the patch looks trivial
> * the patch has been merged in Fedora [1]
> 
> I've emailed the maintainer directly to ask him if it would be OK
> with
> him for me to NMU this.
> 
> If I don't get an answer I'll look into fixing this by an NMU :)
> 
> Cheers,
> 
> [1]
> https://src.fedoraproject.org/rpms/memtest86+/blob/master/f/memtest86+-5.01-serial-console-fix.patch
> 
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
>   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
>   ⠈⠳⣄
> 
> 

Bug#934697: re2c: please make the build reproducible

[Chris Lamb]

forwarded 934697 https://github.com/skvadrik/re2c/pull/258
thanks

I've forwarded this upstream here:

  https://github.com/skvadrik/re2c/pull/258


Regards,

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

Bug#934698: libchamplain: please make the build reproducible

[Chris Lamb]

forwarded 934698 https://gitlab.gnome.org/GNOME/libchamplain/merge_requests/9
thanks

I've forwarded this upstream here:

  https://gitlab.gnome.org/GNOME/libchamplain/merge_requests/9


Regards,

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

Bug#934405: debhelper: Please ignore binNMUs in get_source_date_epoch() function

[Niels Thykier]

Control: tags -1 wontfix

On Sat, 10 Aug 2019 21:24:37 +0300 Dmitry Shachnev 
wrote:
> Package: debhelper
> Version: 12.3
> Severity: wishlist
> 
> Dear debhelper maintainers,
> 
> Our package qtbase5-dev (which is marked as Multi-Arch: same) was recently
> binNMUed, after which it started producing errors when trying to install it
> for different architectures (so it has become non-same actually). Please
> see bugs #934215 and #934265.
> 
> diffoscope showed me the following diff for
> /usr/share/qt5/doc/global/template/images/Qt-logo.png:
> 
>tIME {
>   -#  7 Aug 2019 18:06:40 GMT
>   +#  7 Aug 2019 17:59:06 GMT
>   ...
> 
> I figured out that these timestamps are coming from binNMU changelogs.
> For example, usr/share/doc/qtbase5-dev/changelog.Debian.i386.gz has:
> 
>   qtbase-opensource-src (5.11.3+dfsg1-2+b1) sid; urgency=low, binary-only=yes
> 
> * Binary-only non-maintainer upload for i386; no source changes.
> * Rebuild with libdouble-conversion3.
> 
>-- i386 Build Daemon (x86-grnet-01) 
>   Wed, 07 Aug 2019 17:59:06 +
> 
> The date in PNG metadata is changed by dh_strip_nondeterminism. Originally
> I wanted to submit a bug against that tool, but I noticed that it uses
> get_source_date_epoch() function from Debian::Debhelper::Dh_Lib module.
> 
> I think it would be nice if that function ignored binNMU changelog entries.
> As a workaround, we will use the -X option of dh_strip_nondeterminism for now.
> 
> --
> Dmitry Shachnev

Hi Dmitry,

I brought up this bug in the #debian-reproducible IRC channel and was
pointed to #843773 as a counter argument against fiddling with the
timestamp get_source_date_epoch.
  Often it is better to *not* store timestamps within file metadata of
generated files in the first place instead of normalizing them (if
possible).

Thanks,
~Niels

Bug#934689: tzdata 2019b-0+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 934689 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: tzdata
Version: 2019b-0+deb10u1

Explanation: new upstream release

Bug#934688: tzdata 2019b-0+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 934688 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: tzdata
Version: 2019b-0+deb9u1

Explanation: new upstream release

Bug#906697: ck: baseline violation on i386

[JCF Ploemen]

Looks like upstream release 0.7.0 has an option to disable sse, see:
https://github.com/concurrencykit/ck/commit/f00aaa977b0cbdfb513e1e4e68c1e31ec42270d7


pgp9CzK01XWDT.pgp
Description: OpenPGP digital signature

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Thorsten Glaser]

On Tue, 13 Aug 2019, Adam Borowski wrote:

> > 1. Merge elogind into libpam-elogind (not the other way round),
> >as elogind without libpam-elogind is apparently (see the
> >other thread) not useful in any way.
> 
> I don't think it's reasonable to have the daemon in a library package.
> 
> There's also multiarch to think about:
> foo:pdp11 Depends libpam-systemd:pdp11

Not exactly what you wrote, but I see it now (M-A same vs foreign,
even though libpam-elogind is no library package and contains a
conffile additioinally).

There is no libpam-systemd in this equation.

So then, rename elogind to elogind-daemon instead of merging it,
and let libpam-elogind depend on elogind-daemon. The rest still
stands (it is important that installing a package called simply
“elogind” is the final step after a potential reboot, for being
able to tell people to “just install elogind”).

This would solve two of my confusions.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Adam Borowski]

On Tue, Aug 13, 2019 at 10:43:30PM +0200, Thorsten Glaser wrote:
> On Tue, 13 Aug 2019, Adam Borowski wrote:
> 
> > The prerm also makes systemd non-removable without uninstalling most 
> > packages,
> > rebooting, then installing anew.  Requiring such a reinstall is pretty much
> > RC in by book.
> > 
> > I've reported this before as #930105 but this got insta-closed+downgraded by
> 
> Hm ☹ but I just had this crazy idea:
> 
> 1. Merge elogind into libpam-elogind (not the other way round),
>as elogind without libpam-elogind is apparently (see the
>other thread) not useful in any way.

I don't think it's reasonable to have the daemon in a library package.

There's also multiarch to think about:
foo:pdp11 Depends libpam-systemd:pdp11

> If this is not suitable I’m blaming the beer I’ve had with supper.

[The queue to board is almost over...]

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Adam Borowski]

On Tue, Aug 13, 2019 at 10:36:04PM +0200, Thorsten Glaser wrote:
> > > I would also add that it surprises me that apt requires symbols from
> > > libsystemd.so.
> > 
> > libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
> > provided by libelogind), to tell systemd-logind (or elogind) not to
> > shut down while an apt frontend is still installing packages.
> 
> Ah.
> 
> Can that be moved into a separate subprocess (does sd-bus have
> a command-line interface) or, if not, dlopen() so it can be
> downgraded to a Recommends? (libsystemd0 is still quasi-Essential
> as most dæmons also Depend on it, but this would make apt at
> least work.)

The use is contained to a single function (apt-pkg/contrib/fileutl.cc
Inhibit()) thus implementing dlopen() should be easy.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Thorsten Glaser]

On Tue, 13 Aug 2019, Adam Borowski wrote:

> The prerm also makes systemd non-removable without uninstalling most packages,
> rebooting, then installing anew.  Requiring such a reinstall is pretty much
> RC in by book.
> 
> I've reported this before as #930105 but this got insta-closed+downgraded by

Hm ☹ but I just had this crazy idea:

1. Merge elogind into libpam-elogind (not the other way round),
   as elogind without libpam-elogind is apparently (see the
   other thread) not useful in any way.

2. Make libpam-elogind (which apparently Provides logind) work with
   libsystemd0 and not Conflict with systemd, only systemd-sysv.
   This means code changes (so it works with either library) and
   packaging changes: Depends: libelogind0 (>= …) | libsystemd0 (>= …)
   (note libelogind0 is first, for fresh installs)

3. Create a new package elogind which Depends on libelogind0 and
   libpam-elogind and Conflicts with systemd, to finish the install.
   It probably belongs into Section metapackages and has no content
   and can use dh_installdocs --link-doc=libpam-elogind so even its
   /usr/share/doc/elogind is just a symlink.

This way, a sequence would look like:

- apt-get install libpam-elogind
  ⇒ removes libpam-systemd and systemd-sysv
  ⇒ installs libpam-elogind and sysvinit-core
- reboot
- apt-get install elogind
  ⇒ removes systemd
  ⇒ replaces libsystemd0 with libelogind0

If this is not suitable I’m blaming the beer I’ve had with supper.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#933220: siridb-server: missing source for Release/makefile

[Paul Gevers]

Control: severity -1 normal

Hi Jeroen,

On 13-08-2019 11:51, Jeroen van der Heijden wrote:
> The SiriDB project once started by using the Eclipse IDE which generates
> the make-files and adds the "Auto generated.." comments. Since the
> project is ejected from Eclipse we can now simply remove the comments
> and make future changes by hand. (This does not happen a lot, so changes
> are relative easy to maintain).

If you as upstream consider these files the preferred source for
modification, than this bug isn't severity serious. Can you please
remove the text upstream, so that it will be in the next release and we
can close this bug when that happens, as the text *is* confusing.

The same applies to Debug/makefile I assume.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Thorsten Glaser]

On Tue, 13 Aug 2019, Simon McVittie wrote:

> Ah, that's a major constraint on finding a correct solution here. systemd
> is from the same source package as libsystemd0, so I think it's
> reasonable for them to be in lockstep: systemd executables could well be
> using private symbols or relying on specific behaviour beyond what the

Indeed.

> > I would also add that it surprises me that apt requires symbols from
> > libsystemd.so.
> 
> libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
> provided by libelogind), to tell systemd-logind (or elogind) not to
> shut down while an apt frontend is still installing packages.

Ah.

Can that be moved into a separate subprocess (does sd-bus have
a command-line interface) or, if not, dlopen() so it can be
downgraded to a Recommends? (libsystemd0 is still quasi-Essential
as most dæmons also Depend on it, but this would make apt at
least work.)

Thanks for the explanation,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#928920: patch: Introduce logging functions that check ${VERBOSE}

[Thorsten Glaser]

Dmitry Bogatov dixit:

>--- /dev/null
>+++ b/init-functions.d/00-verbose.jinja
>@@ -0,0 +1,9 @@
>+## Generated automatically. Do not edit! -*- shell-script -*-
>+{% for fn in log_functions %}
>+v{{ fn }} () {
   ↑ no space here, please, for pdksh compatibility
(allowing the space is a bashism)
>+  if test "${VERBOSE:-yes}" != no ; then
instead:if test x"${VERBOSE:-yes}" != x"no"; then
>+  {{ fn }} "$@"
>+  fi
>+}
>+{% endfor %}

Reason: test(1) can behave funny if the argument starts with
a hyphen-minus so when using test or [ instead of the secure
[[ of Korn shell use the x"…" = x"…" form.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Thorsten Glaser]

On Tue, 13 Aug 2019, Mark Hindley wrote:

> I would also add that it surprises me that apt requires symbols from
> libsystemd.so. I haven't yet investigated what functionality that is. But that
> is a side issue.

Probably for “modern Poett^WLinux desktop” logging, or somesuch.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#933035: dmtcp: Should this package be removed?

[Cooperman, Gene]

Hi Moritz,
I'm sorry for the delayed reply.  We are about to release DMTCP version 
2.6.0, and we are including a Debian package.  We have verified with Yaroslav 
Halchenko that our proposed Debian package will pass.  We should be submitting 
it this week.  Also, we are replacing Kapil Arya by Paul Grosu 
(pgr...@gmail.com) as the new maintainer for DMTCP.

Thanks,
- Gene


From: Moritz Muehlenhoff 
Sent: Thursday, July 25, 2019 5:35:07 PM
To: Debian Bug Tracking System
Subject: Bug#933035: dmtcp: Should this package be removed?

Source: dmtcp
Severity: serious

The last upload was in 2014 and it's RC-buggy for a long time, it missed two
stable releases already.

Cheers,
Moritz

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Adam Borowski]

On Tue, Aug 13, 2019 at 09:10:12PM +0100, Simon McVittie wrote:
> On Tue, 13 Aug 2019 at 19:58:09 +0100, Mark Hindley wrote:
> > I would also add that it surprises me that apt requires symbols from
> > libsystemd.so.
> 
> libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
> provided by libelogind), to tell systemd-logind (or elogind) not to
> shut down while an apt frontend is still installing packages.
> 
> If apt wants to talk to D-Bus, sd-bus is certainly not a terrible choice:
> newer D-Bus implementations like GDBus and sd-bus have had the opportunity
> to learn from libdbus' mistakes.

Because of consequences of apt failing to run, perhaps this could be ldopened
instead?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Adam Borowski]

On Tue, Aug 13, 2019 at 07:58:09PM +0100, Mark Hindley wrote:
> On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> > On Sun, 11 Aug 2019, Simon McVittie wrote:
> > > Found while preparing a test VM to test #923240. Please raise this to
> > > RC severity if you think it is justified - I don't want to create the
> > 
> > I don’t think it’s RC in any of the involved packages (elogind,
> > systemd (shock!), apt) because it’s really a whole-system / package
> > management issue.
> 
> Yes, that is my conclusion after 2 days of trying different things. Certainly
> systemd's prerm failure is pretty brutal. But this happens before any of the
> src:elogind preinsts run, so I can't see a way around it.

The prerm also makes systemd non-removable without uninstalling most packages,
rebooting, then installing anew.  Requiring such a reinstall is pretty much
RC in by book.

I've reported this before as #930105 but this got insta-closed+downgraded by
mbiebl.  On the other hand, mbiebl routinely does this (or reports RC bugs
on perfectly working packages without naming a reason), thus the closure
might have not been related to merits or lack thereof.


[I'm in Sao Paulo airport, after a day of travel and about to embark again,
thus I can't investigate yet.  Not before going home then around a week of
sleep.]

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#934712: node-mysql: CVE-2019-14939

[Salvatore Bonaccorso]

Source: node-mysql
Version: 2.16.0-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/mysqljs/mysql/issues/2257

Hi,

The following vulnerability was published for node-mysql. I'm opening
this bug for now mainly for tracking. The upstream issue got locked
down and the original report removed until further investigated. See
[1].

CVE-2019-14939[0]:
| An issue was discovered in the mysql (aka mysqljs) module 2.17.1 for
| Node.js. The LOAD DATA LOCAL INFILE option is open by default.


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-2019-14939
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14939
[1] https://github.com/mysqljs/mysql/issues/2257

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Simon McVittie]

On Tue, 13 Aug 2019 at 19:58:09 +0100, Mark Hindley wrote:
> systemd depends on a specific pacakged version of libsystemd0 (currently 241-7
> in sid) whilst all other packages at most depend on a particular src version
> (eg. >= 213).

Ah, that's a major constraint on finding a correct solution here. systemd
is from the same source package as libsystemd0, so I think it's
reasonable for them to be in lockstep: systemd executables could well be
using private symbols or relying on specific behaviour beyond what the
stable public API guarantees. (dbus-daemon and libdbus have a similar
relationship.)

> I would also add that it surprises me that apt requires symbols from
> libsystemd.so.

libapt-pkg uses sd-bus, systemd's implementation of D-Bus (the same one
provided by libelogind), to tell systemd-logind (or elogind) not to
shut down while an apt frontend is still installing packages.

If apt wants to talk to D-Bus, sd-bus is certainly not a terrible choice:
newer D-Bus implementations like GDBus and sd-bus have had the opportunity
to learn from libdbus' mistakes.

smcv

Bug#885947: marco: After updating, restart (user or pc) and log in, desktop fails

[Y G2709]

Package: marco
Followup-For: Bug #885947
Version: 1.22.2-1


Dear Maintainer.

> This might really be a X driver specific issue.
Perhaps, but as I said in message #30 "The PC woks fine in Debian 9, and
too in Debian 10 testing with mate 1.18.1-3, just until I update to the
following versions."


Message # 40 really helped, thank you very much!, with which I could
continue in "testing" until migrating to the new machine.


Surely in order to reproduce it you would have to have something similar
to my hardware.
I'm going to disassemble and recycle the hardware, and I'll keep the two
graphics card (NV25 "GeForce4 Ti 4200", NV34 "GeForce FX 5500")  apart,
in case someone needed it.
I still use the "Sony Trinitron Multiscan100ES" monitor successfully on
VGA-1.


If you need any more information, I'll send it to you.


Regards.

Bug#695873: memtest86+: Serial console does not work

[Louis-Philippe Véronneau]

Hello!

I'd be happy to make an NMU to fix this, since:

* there is a patch
* the patch was tested by 4 people and it seems to work
* the patch looks trivial
* the patch has been merged in Fedora [1]

I've emailed the maintainer directly to ask him if it would be OK with
him for me to NMU this.

If I don't get an answer I'll look into fixing this by an NMU :)

Cheers,

[1]
https://src.fedoraproject.org/rpms/memtest86+/blob/master/f/memtest86+-5.01-serial-console-fix.patch

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#934711: Please package latest upstream, and switch to Python 3

[Thomas Goirand]

Package: python-googleapi
Version: 1.5.5-1
Severity: serious

Hi,

We're trying to remove Python 2 for Bullseye.

python-monotonic support for Python 2 is removed, and therefore, your package
depends on a cruft package.

Please package the latest version upstream which has support for Python 3,
and remove Python 2 support / use.

Cheers,

Thomas Goirand (zigo)

Bug#934710: systemtap: autopkgtest fails when there are two versions of linux-latest available

[Paul Gevers]

Source: systemtap
Version: 4.1-7
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky
Control: affects -1 src:linux-latest

Dear maintainers,

With a recent upload of linux-latest the autopkgtest of systemtap fails
in testing when that autopkgtest is run with the binary packages of
linux-latest from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
linux-latest   from testing106
systemtap  from testing4.1-7
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

Currently this regression is blocking the migration of linux-latest to
testing [1], but I'll tell the migration software to ignore this
failure, as it seems to me that your autopkgtest is broken when it is
tested in our migration setup with a different linux-latest the two
suites that are tested together. I copied some of the output at the
bottom of this report.

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
linux-latest/106. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=linux-latest

https://ci.debian.net/data/autopkgtest/testing/amd64/s/systemtap/2720472/log.gz

autopkgtest [08:11:28]: test build-hello: [---
Checking "/lib/modules/5.2.0-2-amd64
4.19.0-5-amd64/build/.config" failed with error: No such file or directory
Tip: /usr/share/doc/systemtap/README.Debian should help you get started.
autopkgtest [08:11:28]: test build-hello: ---]


and


autopkgtest [08:11:32]: test list-coreutils-probe-points:
[---
Checking "/lib/modules/5.2.0-2-amd64
4.19.0-5-amd64/build/.config" failed with error: No such file or directory
Tip: /usr/share/doc/systemtap/README.Debian should help you get started.
autopkgtest [08:11:32]: test list-coreutils-probe-points:
---]



signature.asc
Description: OpenPGP digital signature

Bug#934709: v4l2loopback: autopkgtest fails when there is a new version of linux-latest

[Paul Gevers]

Source: v4l2loopback
Version: 0.12.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue
Control: affects -1 src:linux-latest

Dear maintainers,

With a recent upload of linux-latest the autopkgtest of v4l2loopback
fails in testing when that autopkgtest is run with the binary packages
of linux-latest from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
linux-latest   from testing106
v4l2loopback   from testing0.12.1-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

Currently this regression is blocking the migration of linux-latest to
testing [1], but I'll tell the migration software to ignore this
failure, as it seems to me that your package is broken when the latest
linux kernel isn't equal to the kernel running your test. I copied some
of the output at the bottom of this report. For your first test, if this
really can't be fixed and this installation is supposed to fail, I
suggest you mark the first test with the skip-not-installable
restriction. Maybe the second test should be marked as skippable as well
(I don't know, but you'll need to make it exit with code 77 in the
skippable situation).

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
linux-latest/106. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=linux-latest

https://ci.debian.net/data/autopkgtest/testing/amd64/v/v4l2loopback/2720576/log.gz

Setting up v4l2loopback-dkms (0.12.1-1) ...
Loading new v4l2loopback-0.12.1 DKMS files...
It is likely that 4.9.0-8-amd64 belongs to a chroot's host
Building for 5.2.0-2-amd64
Building initial module for 5.2.0-2-amd64
Error! Bad return status for module build on kernel: 5.2.0-2-amd64 (x86_64)
Consult /var/lib/dkms/v4l2loopback/0.12.1/build/make.log for more
information.
dpkg: error processing package v4l2loopback-dkms (--configure):
 installed v4l2loopback-dkms package post-installation script subprocess
returned error exit status 10
Setting up linux-headers-5.2.0-2-amd64 (5.2.7-1) ...
/etc/kernel/header_postinst.d/dkms:
Error! Bad return status for module build on kernel: 5.2.0-2-amd64 (x86_64)
Consult /var/lib/dkms/v4l2loopback/0.12.1/build/make.log for more
information.
dpkg: dependency problems prevent configuration of autopkgtest-satdep:
 autopkgtest-satdep depends on v4l2loopback-dkms; however:
  Package v4l2loopback-dkms is not configured yet.

dpkg: error processing package autopkgtest-satdep (--configure):
 dependency problems - leaving unconfigured
Setting up linux-headers-amd64 (5.2+106) ...
Processing triggers for systemd (241-7) ...
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
 v4l2loopback-dkms
 autopkgtest-satdep
E: Sub-process /usr/bin/dpkg returned an error code (1)


and:


# Build modules
/usr/bin/make -C /usr/src/modules/v4l2loopback v4l2loopback \
KERNEL_DIR=/usr/src/linux-headers-5.2.0-2-amd64
KERNEL_VERSION=5.2.0-2-amd64
KERNELCONF=/usr/src/linux-headers-5.2.0-2-amd64/.config
make[2]: Entering directory '/usr/src/modules/v4l2loopback'
Building v4l2-loopback driver...
/usr/bin/make -C /usr/src/linux-headers-5.2.0-2-amd64
M=/usr/src/modules/v4l2loopback modules
make[3]: Entering directory '/usr/src/linux-headers-5.2.0-2-amd64'
  CC [M]  /usr/src/modules/v4l2loopback/v4l2loopback.o
/usr/src/modules/v4l2loopback/v4l2loopback.c: In function ‘vidioc_qbuf’:
/usr/src/modules/v4l2loopback/v4l2loopback.c:1509:4: error: implicit
declaration of function ‘v4l2_get_timestamp’; did you mean
‘v4l2_get_subdevdata’? [-Werror=implicit-function-declaration]
v4l2_get_timestamp(>buffer.timestamp);
^~
v4l2_get_subdevdata
cc1: some warnings being treated as errors
make[6]: ***
[/usr/src/linux-headers-5.2.0-2-common/scripts/Makefile.build:290:
/usr/src/modules/v4l2loopback/v4l2loopback.o] Error 1
make[5]: *** [/usr/src/linux-headers-5.2.0-2-common/Makefile:1610:
_module_/usr/src/modules/v4l2loopback] Error 2
make[4]: *** [Makefile:179: sub-make] Error 2
make[3]: *** [Makefile:8: all] Error 2
make[3]: Leaving directory '/usr/src/linux-headers-5.2.0-2-amd64'
make[2]: *** [Makefile:43: v4l2loopback.ko] Error 2
make[2]: Leaving directory '/usr/src/modules/v4l2loopback'
make[1]: *** [debian/rules:17: binary-modules] Error 2
make[1]: Leaving directory '/usr/src/modules/v4l2loopback'
make: *** [/usr/share/modass/include/common-rules.make:56: kdist_build]
Error 2
tput: No value for $TERM and no 

Bug#934590: [Mlt-devel] Bug#934590: libmlt-data: The package became bloated

[Dan Dennedy]

On Mon, Aug 12, 2019 at 5:27 AM Patrick Matthäi 
wrote:

> Am 12.08.2019 um 13:11 schrieb Горбешко Богдан:
> > Package: libmlt-data
> > Version: 6.16.0-3
> > Severity: minor
> >
> > Dear Maintainer,
> >
> > After the last upgrade, the package became about 230 MBs larger,
> > because of a lot of large lumas in PGM format, each about 4 MBs. Is
> > there an important reason to keep them uncompressed on a disk? Even
> > the fast GZip compression can drastically reduce their size.
> >
> Hi Dan,
>
> what is your opionion about this? This is the list of the affected files:
>

This was intentional to produce transitions with the correct aspect ratio.
The PGM images cannot be simply gzip compressed because the PGM reader in
MLT is not integrated with zlib. Instead, the package can use the configure
option --luma-compress to output compressed PNG. However, these are 8-bit
instead of the 16-bit PGM, which provides better quality transitions. Since
these are procedurally-generated, I started working on a change to generate
the image on-demand instead of reading a file. I plan to do that for the
next release.

Bug#867067: nfs-kernel-server: nfsdcltrack fails to init database

[Kurt Roeckx]

This problem is still present in buster.

The relevant strace output seems to be:
capget({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, NULL) = 0
capset({version=_LINUX_CAPABILITY_VERSION_3, pid=0}, {effective=0, permitted=0, 
inheritable=0}) = 0
access("/var/lib/nfs/nfsdcltrack", W_OK) = -1 ENOENT (No such file or directory)
lstat("/var/lib/nfs/nfsdcltrack/main.sqlite", 0x7fffcc2d1530) = -1 ENOENT (No 
such file or directory)
getpid()= 9566
getpid()= 9566
openat(AT_FDCWD, "/var/lib/nfs/nfsdcltrack/main.sqlite", 
O_RDWR|O_CREAT|O_CLOEXEC, 0644) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/lib/nfs/nfsdcltrack/main.sqlite", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
mkdir("/var/lib/nfs/nfsdcltrack", 0700) = -1 EACCES (Permission denied)

So my understanding is that it's dropping priviledges, and
/var/lib/nfs is owned by statd, but nfsdcltrack is probably run
as root instead.


Kurt

Bug#934453: curl: SSL

[Sebastian Andrzej Siewior]

On 2019-08-12 23:59:10 [+0200], Kurt Roeckx wrote:
> > Kurt, could we get something into OpenSSL (aka openssl s_client
> > -connect) which describes the error more accurate / verbose?
> > I will try to collect some information and point the ssllabs people to
> > it hoping that it will pop up in the server rating…
> 
> The error is very clear to me. The server picked a signature
> algorithm that the client didn't offer.

signature algorithm used for the key-exchange (forward-security) if I'm
not mistaken. My point is that with more information here, we maybe
could avoid being involved :)
I don't know if the problem is a bug in an older openssl version or a
bad configarion used on the server side.

> Should I try to contact
> level 3?

Yes, please. As an openssl dev you might have more luck. With a template
I would ping the ssllabs folks :)

> 
> Kurt
> 
Sebastian

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Mark Hindley]

Thorsten,

Thanks for this.

On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> On Sun, 11 Aug 2019, Simon McVittie wrote:
> 
> > Found while preparing a test VM to test #923240. Please raise this to
> > RC severity if you think it is justified - I don't want to create the
> 
> I don’t think it’s RC in any of the involved packages (elogind,
> systemd (shock!), apt) because it’s really a whole-system / package
> management issue.

Yes, that is my conclusion after 2 days of trying different things. Certainly
systemd's prerm failure is pretty brutal. But this happens before any of the
src:elogind preinsts run, so I can't see a way around it. If anything, it is a
limitation in apt (although I am not trying to pass the buck here).

> > Actual result (transcript below):
> > 
> > * systemd-sysv is removed
> > * sysvinit-core is unpacked
> > * systemd is also removed
> > * systemd's prerm fails because it is still the active init system
> 
> Interesting. But this probably happens before the preinst of
> libelogind0 and does prevent its installation, which is not
> something easily circumvented.

systemd depends on a specific pacakged version of libsystemd0 (currently 241-7
in sid) whilst all other packages at most depend on a particular src version
(eg. >= 213). libelogind Provides libsystemd0 (= ${source:Upstream-Version}) so
the attempted removal of systemd is not triggered  by any Conflict with
libelogind, but by the removal of libsystemd0 *before* replacing it with
libelogind0.

So far, I haven't discovered a way to mitigate or preempt that.

I would also add that it surprises me that apt requires symbols from
libsystemd.so. I haven't yet investigated what functionality that is. But that
is a side issue.

Mark

Bug#934708: gitlab: CVE-2019-14942 CVE-2019-14944 (GitLab Critical Security Release: 12.1.6, 12.0.6, and 11.11.8)

[Salvatore Bonaccorso]

Source: gitlab
Version: 11.8.10+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerabilities were published for gitlab, another round
of gitlab issues. Where this time only two CVE are affecting the
versions present in Debian.

CVE-2019-14942[0]:
Insecure Cookie Handling on GitLab Pages

CVE-2019-14944[1]:
Multiple Command-Line Flag Injection Vulnerabilities

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-14942
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14942
[1] https://security-tracker.debian.org/tracker/CVE-2019-14944
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14944
[2] 
https://about.gitlab.com/2019/08/12/critical-security-release-gitlab-12-dot-1-dot-6-released/

Regards,
Salvatore

Bug#672361: bootlogd: escape sequences should be filtered out

[Jesse Smith]

On 8/13/19 2:06 PM, Dmitry Bogatov wrote:
> [2019-08-12 17:45] Jesse Smith 
>> Certainly. Attached is a file with the last 20 lines of the
>> /var/boot/log file on a test machine. When I view the log with "less"
>> the output looks normal. When I run the file through "head" "tail" or
>> "cat" the "[ ok" part of the message line appears at the beginning of
>> the text. This happens in both the text console and in a virtual
>> terminal window.
> Ah, everything is clear now. Log file contains following escape
> sequence:
>
>[ 1 G
>
> It moves cursor to first column of terminal, so text after displaces
> text (timestamp) at beginning of line.

I came to a similar conclusion. I found I could edit the character
sequences in vim and pick which ones to keep or erase. As you pointed
out, editing or filtering some sequences makes for fragile formatting.
We could remove just those sequences in bootlogd, but I think the better
solution is (as you wrote) to fix the formatting in the program sending
us the log messages.

Bug#695873: memtest86+: Serial console does not work

[Matt Taggart]

I have also confirmed the patch to fix serial console that was sent to
#695873 works. I was applying it to 5.01-3, building on buster,
installed and booted fine. Please apply.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#933275: Patch for #933275

[Simon Richter]

tags 933275 +patch
thanks

Hi,

here's a patch I've also sent to the mailing list. Works for me, but
probably needs some testing that it doesn't break anything else.

   Simon
>From 13105537e68f0d3692b19a0f5cf675d79e32d42a Mon Sep 17 00:00:00 2001
From: Simon Richter 
Date: Tue, 13 Aug 2019 13:49:06 +0200
Subject: [PATCH] Apply path correction to correct argument

This fixes running OpenCL tests under Valgrind, by applying the path
transformation to the argument that the original command turned into.

It would be nice to have a cleaner solution here that doesn't depend on
text substitution, but as long as there is no OpenCL test named "valgrind",
this should work.
---
 framework/test/piglit_test.py | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/framework/test/piglit_test.py b/framework/test/piglit_test.py
index 0881f00a6..ab6de0398 100644
--- a/framework/test/piglit_test.py
+++ b/framework/test/piglit_test.py
@@ -75,8 +75,7 @@ class PiglitBaseTest(ValgrindMixin, Test):
 @Test.command.getter
 def command(self):
 # Prepend TEST_BIN_DIR to the path.
-cmd = os.path.join(TEST_BIN_DIR, super(PiglitBaseTest, self).command[0])
-return [cmd] + self._command[1:]
+return [os.path.join(TEST_BIN_DIR, c) if c == self._command[0] else c for c in super(PiglitBaseTest, self).command ]
 
 def interpret_result(self):
 out = []
@@ -231,8 +230,7 @@ class CLProgramTester(PiglitCLTest):
 @PiglitCLTest.command.getter
 def command(self):
 command = super(CLProgramTester, self).command
-command.insert(1, os.path.join(ROOT_DIR, self.filename))
-return command
+return command + [ os.path.join(ROOT_DIR, self.filename) ]
 
 
 class VkRunnerTest(PiglitBaseTest):
-- 
2.20.1

Bug#934707: Temporal fix-up

[Anonymous Legionus]

As temp workaround, inspect policy files in /etc/dbus-1/system.d and create
missed users. One liner:
for i in $(awk 'BEGIN{FS="user=\"|\">"}; $0 ~ /policy user=/{print $2}'
/etc/dbus-1/system./* | sort -u); do [ "x$(getent passwd $i)" = "x" ] && {
useradd -Mr $i && echo System user $i created; }; done

Bug#932540: epiphany-browser: Gmail doesn't work correctly in Epiphany in buster

[Gerardo Ballabio]

I ticked off everything: Try to block advertisements, Try to block web
trackers, and even Try to block dangerous websites. Didn't work
(sending this from Firefox).

As a test I tried sending a message. While I was composing it a red
banner appeared with the text "Errore durante il salvataggio della
bozza." (Error while saving draft.) and when I clicked the Send button
the text changed to: "Errore durante l'invio del messaggio." (Error
while sending message.). The message was neither sent nor stored in
the Draft folder.

Gerardo

Il giorno mar 13 ago 2019 alle ore 13:42 Alberto Garcia
 ha scritto:
>
> On Tue, Aug 13, 2019 at 08:52:33AM +0200, Gerardo Ballabio wrote:
>
> > Could be. How can I turn it off?
>
> Menu -> Preferences -> Web Content
>
> Berto

Bug#934678: libreoffice-writer: Cropping an image that is flipped does not work as expected

[Rene Engelhard]

notfound 934678 6.3.0.4
# according to upstream bug
found 934678 1:5.0.0~rc5-1
forwarded 934678 https://bugs.documentfoundation.org/show_bug.cgi?id=104995
thanks

On Tue, Aug 13, 2019 at 12:25:27PM +0300, Vangelis Skarmoutsos wrote:
>Package: libreoffice-writer
>Version: 6.3.0.4

Version: is the package version. The Bug Tracking system doesn not know
upstream internal versions (the official version would be 6.3.0 anyway)
anyways.
The Bug tracking system can't find a matching version and thus thinks
this bug has been in any LO (and OOo!) from since the beginning in 2002.

>Cropping an image after flip horizontal or vertical, works the opposite
>way
>To reproduce do the following:
>Insert an image or clip art.
>Flip horizontal the image.
>Try to crop the image. Select the right handle and reduce the size of the
>image by hiding the right part of the image.
>When mouse action is complete, you will see that the left part of the
>image is hidden instead of the right.
>This affects flip horizontal and flip vertical actions.
>All other rotate options are working fine with crop.
>Libreoffice Calc is not affected by this bug.

Sounds like https://bugs.documentfoundation.org/show_bug.cgi?id=104995

Regards,

Rene

Bug#932584: Please help fix pydoctor

[Guido Günther]

Hi,
On Sun, Jul 28, 2019 at 02:00:56PM +0100, Ian Jackson wrote:
> Hi, Python folks.
> 
> I think help is needed regarding
> 
>   #932584  python-pydoctor: Epydoc will be removed
> 
> It seems to be languishing rather.  What I don't understand is why
> pydoctor depends on epydoc given that, in the words of the
> Description:
> 
>   [Pydoctor] was written primarily to replace epydoc ...
> 
> I had a quick look through the source but I don't know enough about
> pydoctor to make immediate sense of the results of my grep.  Maybe
> some person who knows more about pydoctor can help ?
> 
> (I'm CCing this to the gbp maintainers because this came to my
> attention due to an autoremoval bug where a package of mine has a
> dependency chain via gbp.)

epydoc only seems to be used for formatting and README.Debian confirms
this:

...and looking at the bug it seems it was already dealt with by dropping
the epydoc dependency. Thanks!
 -- Guido

> 
> Thanks,
> Ian.
> 
> -- 
> Ian JacksonThese opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 

Bug#598351: texlive-latex-base: Error when using lmodern fonts together with T1 fontenc

[Norbert Preining]

On Tue, 13 Aug 2019, Hilmar Preuße wrote:
> Are you sure, that the format files read the EC fonts? If yes, why does
> redefining the \fontfamily before loading fontenc solves the problem?

Indeed, maybe then it is some AtBeginDocument hooks? Not sure exactely,
but I am not really interested in tracking down.

Best

Norbert

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

Bug#934518: stretch-pu: package libebml/1.3.4-1

[Sebastian Ramacher]

On 2019-08-13 18:22:48, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sun, 2019-08-11 at 23:08 +0200, Sebastian Ramacher wrote:
> > I'd like to fix CVE-2019-13615 in libebml in stetch (the security
> > team
> > classified it as no-DSA). The proposed debdiff is attached.
> > 
> 
> Please go ahead; thanks.

Thanks, uploaded.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#934707: [dbus,systemd,sssd]: Unresponsive domain and nonexistent user in policy lead to reload fail and fall of dependant daemons.

[Arano-kai]

Package: dbus
Version: 1.12.16-1
Severity: normal

Dear Maintainer.

As subject says, if sssd can't reach dc, dbus get NoReply fail and succesfully 
restarted aftervards with following consequences:
1. reload process lagging due sssd timeouts;
2. other daemons fail because 1 or dbus restart;
3. failed reload at packet install process may lead to overall install fail;

Because of automatic config reload, 1 is strikes at periodic manner.
The most notorious example of 2 is NetworkManager, which gets SIGTERM 
(org.freedesktop.nm_dispatcher timeout), shutdown network and require manual 
restart, despite the fact that dbus already restarted. Nice to have bunch of 
isolated instances at midnight because of network spike (:
3 is theoretical and depends on packages postinstall scripts and hooks.

Steps to reproduce:
1a. Get minimal setup with some additional packages:
  # debootstrap --arch=amd64 
--include=network-manager,sssd,iio-sensor-proxy,ovirt-guest-agent,linux-image-amd64,grub-pc
 stable /mnt
  # #Do other stuff to boot from...
1b. Or add network-manager, sssd, iio-sensor-proxy and ovirt-guest-agent to 
fresh setup. Last two will add policy with currently nonexistent users gdm and 
geoclue. Skip sssd realm config. You may notice NoReply fail due setup.
2. Check NetworkManager status and restart if already dead.
3. Do systemctl reload dbus.service. Notice time taken.
4. Check NetworkManager again. Status change to 'dead' after step 3 or some 
short time.
5. Check dbus journal. Notice org.freedesktop.nm_dispatcher activation fail, 
NoReply and restart.
BONUS STAGE: remove one user policy (eg. purge ovirt-guest-agent OR 
iio-sensor-proxy), restart NetworkManager and do dbus reload again. This time 
NM not fail.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dbus depends on:
ii  adduser   3.118
ii  libapparmor1  2.13.2-10
ii  libaudit1 1:2.8.4-3
ii  libc6 2.28-10
ii  libcap-ng00.7.9-2
ii  libdbus-1-3   1.12.16-1
ii  libexpat1 2.2.6-2
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-5

dbus recommends no packages.

Versions of packages dbus suggests:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1

Versions of packages dbus is related to:
pn  dbus-x11  
ii  systemd   241-5
ii  systemd-sysv  241-5

-- no debconf information
-- Logs begin at Tue 2019-08-13 14:27:09 UTC, end at Tue 2019-08-13 17:45:55 
UTC. --
Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: 
NetworkManager-wait-online.service: Succeeded.
Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Stopped Network Manager 
Wait Online.
Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Stopping Network Manager 
Wait Online...
Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Starting Network 
Manager...
Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]:   
[1565718209.3909] NetworkManager (version 1.14.6) is starting... (after a 
restart)
Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]:   
[1565718209.3917] Read config: /etc/NetworkManager/NetworkManager.conf (lib: 
no-mac-addr-change.conf)
Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Started Network Manager.
Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Starting Network Manager 
Wait Online...
Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]:   
[1565718209.4021] bus-manager: acquired D-Bus service 
"org.freedesktop.NetworkManager"
Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]:   
[1565718209.4029] manager[0x55a91f88b020]: monitoring kernel firmware directory 
'/lib/firmware'.
Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]:   
[1565718209.4031] monitoring ifupdown state file '/run/network/ifstate'.
Aug 13 17:43:29 test-dbus-fail.fake.domain dbus-daemon[7179]: [system] 
Activating via systemd: service name='org.freedesktop.hostname1' 
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.8' (uid=0 
pid=7338 comm="/usr/sbin/NetworkManager --no-daemon ")
Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Starting Hostname 
Service...
Aug 13 17:43:29 test-dbus-fail.fake.domain dbus-daemon[7179]: [system] 
Successfully activated service 'org.freedesktop.hostname1'
Aug 13 17:43:29 test-dbus-fail.fake.domain systemd[1]: Started Hostname Service.
Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]:   
[1565718209.4680] hostname: hostname: using hostnamed
Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]:   
[1565718209.4681] hostname: hostname changed from (none) to 
"test-dbus-fail.fake.domain"
Aug 13 17:43:29 test-dbus-fail.fake.domain NetworkManager[7338]:   
[1565718209.4683] 

Bug#598351: texlive-latex-base: Error when using lmodern fonts together with T1 fontenc

[Hilmar Preuße]

Am 13.08.2019 um 18:07 teilte Norbert Preining mit:
> On Tue, 13 Aug 2019, Hilmar Preuße wrote:

Hi Norbert,

>> information that the problem can be avoided as described above. Still
>> I'm not sure if it is a bug in fontenc package.
> 
> I guess it is a problem with the default format dump, which is
> loaded before the fontenc package is loaded. So fonts that are
> required there will be loaded, even if fontenc redefines everything
> and the font is never used again.
> 

Are you sure, that the format files read the EC fonts? If yes, why does
redefining the \fontfamily before loading fontenc solves the problem?

> Fixing this would probably require defining special formats, which will
> definitely not happen, or adding lazy loading to TeX, which is a big
> endevaour.
> 

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#684128: Bug 684128, GB vs GiB

[Jeff Norden]

Well, it's been 7 years since this bug was opened.

Sure, it's not killing anyone.  And I assume that the partitioner
correctly handles alignment issues for current drives.  But still, IMHO,
any time software does something other than what you expect it to do,
it's broken.

A simple suggestion: just have partman correctly parse KiB, MiB, GiB,
and TiB when someone manually enters a partition size.  Currently, these
generate an error message.  Also, on that page, include a short
explanation of the acceptable units and their meanings.

I'd say it's fine for partman to just always display partition sizes in
10^n units.  The only folks likely to care about this are ones doing
manual partitioning.  It's likely that any such person will understand
what's going on when they specify a 32GiB partition and then see 34.4GB
in the list of partitions.

It also might be handy to include fdisk on the net-install cd, for use
in a shell (or ctrl-alt-f2).  But that might be a pain, given that fdisk
now has its own shared libs.

Just my 2c.
-Jeff

Bug#934697: re2c: please make the build reproducible

[JCF Ploemen]

Control: tags -1 + confirmed pending

https://github.com/jcfp/debpkg-re2c/commit/9301836027a2292cc992e7525b1891b91f8b33b2

Thanks for the patch!



pgp0wo7WHSndn.pgp
Description: OpenPGP digital signature

Bug#934508: stretch-pu: package openldap/2.4.44+dfsg-5+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-08-11 at 11:45 -0700, Ryan Tandy wrote:
> I would like to update openldap in stretch to fix two CVEs and one
> additional important bug. I already discussed the CVEs with the
> security
> team and we agreed on fixing them in a point release.
> 

Please go ahead.

Regards,

Adam

Bug#934518: stretch-pu: package libebml/1.3.4-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-08-11 at 23:08 +0200, Sebastian Ramacher wrote:
> I'd like to fix CVE-2019-13615 in libebml in stetch (the security
> team
> classified it as no-DSA). The proposed debdiff is attached.
> 

Please go ahead; thanks.

Regards,

Adam

Bug#934507: buster-pu: package openldap/2.4.47+dfsg-3+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-08-11 at 11:45 -0700, Ryan Tandy wrote:
> I would like to update openldap in buster to fix two CVEs and one 
> additional important bug. I already discussed the CVEs with the
> security 
> team and we agreed on fixing them in a point release.
> 

Please go ahead; thanks.

Regards,

Adam

Bug#934704: buster-pu: package node-lodash/4.17.11+dfsg-2+deb10u1

[Xavier Guimard]

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

Hi all,

node-lodash is vulnerable to prototype pollution (#933079,
CVE-2019-10744). I imported upstream fix in the attached debdiff.

Cheers,
Xavier
diff --git a/debian/changelog b/debian/changelog
index 70f10cb..880adff 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-lodash (4.17.11+dfsg-2+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Fix prototype pollution (Closes: #933079, CVE-2019-10744)
+
+ -- Xavier Guimard   Tue, 13 Aug 2019 19:02:17 +0200
+
 node-lodash (4.17.11+dfsg-2) unstable; urgency=medium
 
   * Drop modules directory (now generated from source)
diff --git a/debian/patches/CVE-2019-10744.patch 
b/debian/patches/CVE-2019-10744.patch
new file mode 100644
index 000..bdf0936
--- /dev/null
+++ b/debian/patches/CVE-2019-10744.patch
@@ -0,0 +1,34 @@
+Description: fix for CVE-2019-10744
+Author: Xavier Guimard 
+Origin: upstream, https://github.com/lodash/lodash/pull/4336/files
+Bug: https://github.com/lodash/lodash/issues/4348
+Bug-Debian: https://bugs.debian.org/933079
+Forwarded: not-needed
+Last-Update: 2019-08-13
+
+--- a/dist/lodash.js
 b/dist/lodash.js
+@@ -6613,6 +6613,10 @@
+  * @returns {*} Returns the property value.
+  */
+ function safeGet(object, key) {
++  if (key === 'constructor' && typeof object[key] === 'function') {
++return;
++  }
++
+   if (key == '__proto__') {
+ return;
+   }
+--- a/lodash.js
 b/lodash.js
+@@ -6613,6 +6613,10 @@
+  * @returns {*} Returns the property value.
+  */
+ function safeGet(object, key) {
++  if (key === 'constructor' && typeof object[key] === 'function') {
++return;
++  }
++
+   if (key == '__proto__') {
+ return;
+   }
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..2dd5579
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2019-10744.patch

Bug#933799: geary FTBFS - ERROR: Problem encountered: SQLite3 is missing FTS3 tokenizer support

[Pirate Praveen]

On Sat, 03 Aug 2019 21:10:48 +0530 Pirate Praveen  
wrote:
> Package: geary
> version: 3.32.0-1
> Severity: serious
> 
> I tried building in both buster and sid, both builds failed. Built with 
> an uptodate chroot using sbuild.
> 
> Header  has symbol "SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER" 
> with dependency sqlite3: NO
> 
> meson.build:111:2: ERROR: Problem encountered: SQLite3 is missing FTS3 
> tokenizer support. Please compile it with -DSQLITE_ENABLE_FTS3.
> See https://bugzilla.gnome.org/show_bug.cgi?id=763203 for details.

This seems caused by ccache installed in chroot, similar to libgit2-glib bug 
#934673
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#934463: initscripts: consider taking over hwclock policy machinery

[Dmitry Bogatov]

[2019-08-12 22:37] Andreas Henriksson 
> > This is how things usually done on non-conffiles. Are there
> > additional complications with conffiles?
>
> Yes, there are many gotchas with conffiles. Extensive testing is
> needed.

Yes. We could use semi-automatic tests in Docker, like
salsa:kaction/daemons. No, I do not volonteer doing same for this bug.

Alternatively, we could do it slower:

 * util-linux moves files in question into separate package 
   and initscripts adds dependency on it.

 * initscripts incorporates  package.

It will require two releases, but may be simplier.

> I'd say the two main things to test is that there are no confusion with
> unmodified files and also that local modifications (incl. removed  files
> staying removed) are properly transfered on upgrade. Special care then
> also needs to persist until after Bullseye release with further changes
> to avoid breaking any of the previous before everyone has upgraded.

Sounds bad, like I will have to take ownership of files, but will not be
able to edit them until next release.

> (Fortunately skipping releases aren't supported on Debian, but for the
> benefit of potential downstream distros you might want to ensure this
> for a longer time and hold back on modifications that might break the
> upgrade/handover of the conffiles.)

Even scarier.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#672361: bootlogd: escape sequences should be filtered out

[Dmitry Bogatov]

[2019-08-12 17:45] Jesse Smith 
> >> I tried it and the "head", "cat" and "tail" commands mangle the lines
> >> of the log file when escape sequences are not escaped. Output from
> >> "less" is clean though and looks correct.
> > Interesting. Can you please send text that shows this behaviour?

> Certainly. Attached is a file with the last 20 lines of the
> /var/boot/log file on a test machine. When I view the log with "less"
> the output looks normal. When I run the file through "head" "tail" or
> "cat" the "[ ok" part of the message line appears at the beginning of
> the text. This happens in both the text console and in a virtual
> terminal window.

Ah, everything is clear now. Log file contains following escape
sequence:

   [ 1 G

It moves cursor to first column of terminal, so text after displaces
text (timestamp) at beginning of line.

On other hand, `less -R' do not interpret cursor movement sequences
(quote from less(1)):

For the purpose of keeping track of screen appearance, ANSI
color escape sequences are assumed to not move the cursor.

If you use `less -r', output will be same as with `head', but I expect
`less' get confused on scrolling.

Cursor movement control sequences are okay for presentation, but are
very fragile to be stored and manipulated in any way.

I already filed bug to src:lsb to avoid control sequences more complex
than coloring.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#934650: buster-pu: package open-infrastructure-compute-tools/20190301-lts2-1~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2019-08-13 at 00:58 +0200, Daniel Baumann wrote:
> unfortunatlly I did a rebase error when preparing the upload for
> buster, so one necessary 'case' statement got removed that shouldn't.
> 
> The effect of the missing 'case' statement is that when containers
> are started, they will be automatically shutdown after the systemd
> unit timeout is reached when calling 'systemd-nspawn --keep-unit
> [...]' the second time (which should be only called once, the second
> time the script is executed it should be noop for systemd-nspawn).

Please go ahead.

Regards,

Adam

Bug#933828: ncbi-tools6/6.1.20170106+dfsg1-0+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2019-08-03 at 23:27 -0400, Aaron M. Ucko wrote:
> Thorsten Alteholz from the FTP Master team recently pointed out a
> couple of long-standing copyright-related issues with ncbi-tools6:
> some data files turned out to contain non-free portions, and
> debian/copyright didn't mention some third-party code I'd previously
> overlooked.  I've addressed these issues in unstable with ncbi-tools6
> 6.1.20170106+dfsg1-1.
> 
> Thorsten asked me to upload fixes to (old)stable as well, so I've
> drafted uploads targeting both releases per
> https://salsa.debian.org/med-team/ncbi-tools6/tree/stretch
> https://salsa.debian.org/med-team/ncbi-tools6/tree/buster
> and the attached debdiffs.
> 
> NB: I left stretch at source format 1.0 for now to keep changes to a
> minimum, which means it will need an .orig.tar.gz rather than the
> identically numbered .orig.tar.xz we have in unstable.  If that
> discrepancy is a problem, I can cherry-pick more changes; please let
> me know.

I think it ends up being OK, but let's see. :-)

Please go ahead with the stretch upload.

Regards,

Adam

Bug#934706: Long description insufficient to understand what package does

[Sam Hartman]

package: node-lodash
version: 4.17.11+dfsg-4


The entire description is:
Description-en: Lo-dash is a Node.js utility library   
 Lo-dash is a Node.js utility library delivering   
 consistency, customization, performance, & extras.
 .
 Node.js is an event-based server-side JavaScript engine.  


That description is marketing material; it does not actually allow me to
understand what functionality node-lodash provides or whether it would
be useful for my application.
I think describing briefly in a paragraph or two what sort of utilities
are provided would make this description much more consistent with what
we typically expect for the Debian archive.

--Sam

Bug#930603: libdockapp-dev: pkg-config file Requires xext without dependency on libxext-dev

[Andreas Metzler]

On 2019-06-16 "Torrance, Douglas"  wrote:
> On Sun, Jun 16, 2019 at 7:30 AM Andreas Metzler 
> mailto:ametz...@bebt.de>> wrote:
>> /usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc:
>> Requires: x11 xext xpm

>> Therefore anything build-depending on libdockapp-dev and using pkg-config
>> to locate the library will FTBFS unless it has a direct b-d on
>> libxext-dev.

>> I think the error is in the pkg-config file, not in the Debian package.
>> Since the headers of libdockapp-dev do not #include (and therefore expose)
>> headers from libxext-dev the pkg-config should have (at most)
>> Libs.private: -lext
>> instead of the requires.

> This was fixed in git upstream a while ago [1], but there hasn't been
> a new release yet.  I'll work on that soon.

Hello Douglas,

the respective patch moves "Requires: x11 xext xpm" to Requires.private.
That does not really fix the bug. pkg-config --cflags requires that not
only Requires but also Requires.private are is resolvable (even when
--static is not present) i.e. xext.pc would still need to be present.

I think this would be the correct fix:
- @echo 'Requires.private: x11 xext xpm' >> $@
+ @echo 'Requires.private: x11 xpm' >> $@
+ @echo 'Libs.private: -lext' >> $@

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#934705: RM: sysbench [x32 sparc64 sh4 m68k hppa armhf alpha] -- ROM; build-dependencies unavailable

[JCF Ploemen]

Package: ftp.debian.org
Severity: normal

Please remove the sysbench package for the architectures listed above.

Recent versions of sysbench require libck which isn't available on
these archs. See https://bugs.debian.org/921506


Thanks!


pgpRxrQ7b_Jhy.pgp
Description: OpenPGP digital signature

Bug#934311: ncbi-tools6/6.1.20170106+dfsg1-0+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2019-08-11 at 22:40 -0400, Aaron M. Ucko wrote:
> [Switching to Buster version of this request, which got the new
> number.]
> 
> "Adam D. Barratt"  writes:
[...]
> At any rate, I've just uploaded 6.1.20170106+dfsg1-2 to unstable with
> the autopkgtest regression fix, and folded that fix into my proposed
> 6.1.20170106+dfsg1-0+deb10u1 stable update, which now has the
> attached
> debdiff.  (I've also pushed these changes to my buster branch on
> salsa.)

Please go ahead; thanks.

Regards,

Adam

Bug#934673: libgit2-glib ftbfs with meson.build:148:2: ERROR: Assert failed: libgit2 ssh support was requested, but not found. Use -Dssh=false to build without it

[Pirate Praveen]

On 2019, ഓഗസ്റ്റ് 13 4:37:35 PM IST, Simon McVittie  wrote:
>On Tue, 13 Aug 2019 at 14:14:01 +0530, Pirate Praveen wrote:
>> When building with sbuild,
>
>Is ccache preinstalled in the chroot you used?

Yes.

>> #include 
>> int
>> main(int argc, const char *argv[])
>> {
>> git_libgit2_init ();
>> return ((git_libgit2_features() & GIT_FEATURE_SSH) != 0)
>? 0
>> : 1;
>> }
>
>If you compile this small program yourself, does it work and exit 0?

I will try it later and confirm.

>> Compiler stderr:
>>  ccache: error: Failed to create directory
>> /sbuild-nonexistent/.ccache/tmp: Permission denied
>
>If my guess about the root cause is correct, then this will affect
>every
>package that builds with Meson and does not reset HOME in its packaging
>(but many GNOME packages need a working HOME for their build-time
>tests,
>so they reset it in debian/rules, as seen in for example glib2.0).

Yes, makes sense, #933799 is also the same issue.

>Perhaps Meson should not automatically use ccache if $HOME is not
>writeable, or perhaps the dh build system for Meson should explicitly
>disable it in this situation.

Yes, this should be fixed at dh level.

>smcv

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

Bug#934589: udev: net.ifnames is wrongly imported as a property for any/all devices

[Michael Biebl]

Am 13.08.19 um 18:07 schrieb quidame:
> 
> 
> On 13/08/2019 17:44, Michael Biebl wrote:
>>
>> --export says
>>
>>   -x, --export
>>Print output as key/value pairs. Values are enclosed in
>> single quotes. This takes effects only when --query=property or
>> --device-id-of-file=FILE is
>>specified.
>>
>> It doesn't claim that this is a shell parseable format which can be run
>> through eval, so I don't think you can rely on that.
> 
> The --export option has been implemented to be shell parseable. The
> bugfix https://bugzilla.redhat.com/show_bug.cgi?id=644330 claims:

That's not the official systemd bug tracker though and I can't find
anything in the official documentation supporting that the output of
--export needs to be ready to be passed to eval.
Could you ask upstream about that and ask for clarification?

If so, this should be promimently documented so udev rules authors know
that they can't set arbitrary keys.

-- 
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#873520: Check for bad distribution in d/changelog only when changes file is signed

[Felix Lechner]

Hi Chris,

On Tue, Aug 13, 2019 at 9:10 AM Felix Lechner
 wrote:
>
> When the changes file is unsigned, which is part of the
> normal workflow for those using 'dch', the tag is not issued.

Did we get that logic right? Should Lintian perhaps complain instead
when analysing a changes file---which is clearly intended for
upload---versus a dsc file that can hold sources at any stage?

Kind regards
Felix

Bug#934702: RFP: yggdrasil -- End-to-end encrypted IPv6 networking to connect worlds.

[Null]

Package: wnpp
Severity: wishlist

* Package name: yggdrasil
Version: 0.3.6
Upstream Author: Arceliar, neilalexander, aparcar
* URL: https://github.com/yggdrasil-network/yggdrasil-go
* License: LGPLv3
Programming Lang: Go
Description: End-to-end encrypted IPv6 networking to connect worlds.

Yggdrasil is a proof-of-concept to explore a wholly different approach to 
network routing. Whereas current computer networks depend heavily on very 
centralised design and configuration, Yggdrasil breaks this mould by making use 
of a global spanning tree to form a scalable IPv6 encrypted mesh network.
The official website of Yggdrasil where it is written how to add an unofficial 
repository for Debian: 
https://yggdrasil-network.github.io/installation-linux-deb.html