Bug#922842: #922842 ITP: golang-github-containers-image -- Work with containers' images

[Dmitry Smirnov]

What's holding this back? Package looks good and builds successfully in 
"experimental". Shall we upload please?

Thanks.

-- 
Regards,
 Dmitry Smirnov

---

In theory, there is no difference between theory and practice. But, in
practice, there is.
-- Jan L. A. van de Snepscheut


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

Bug#940007: gitlab: CVE-2019-16170: Project Template Functionality Could Be Used to Access Restricted Project Data

[Salvatore Bonaccorso]

Source: gitlab
Version: 11.8.10+dfsg-1
Severity: grave
Tags: security upstream
Control: found -1 12.0.8-2
Control: found -1 12.0.8-1

Hi,

The following vulnerability was published for gitlab.

CVE-2019-16170[0]:
|Project Template Functionality Could Be Used to Access Restricted
|Project Data

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-16170
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16170
[1] 
https://about.gitlab.com/2019/09/10/critical-security-release-gitlab-12-dot-2-dot-5-released/

Regards,
Salvatore

Bug#935290: moar digging

[Robert Lemmen]

...and it's fakeroot! it does ld_preload to map file user ids, and doing
that it fakes stat calls, but not statx!

regards  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: PGP signature

Bug#940006: libodb-qt FTCBFS: uses the build architecture qmake

[Helmut Grohne]

Source: libodb-qt
Version: 2.4.0-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libodb-qt fails to cross build from source, because it detects the build
architecture pkg-config using AC_PATH_PROG. It should be using
AC_PATH_TOOL. Please consider applying the attached patch.

Helmut
--- libodb-qt-2.4.0.orig/m4/libqt.m4
+++ libodb-qt-2.4.0/m4/libqt.m4
@@ -43,7 +43,7 @@
 libqt_lib_names="Qt5Core QtCore5 QtCore Qt4Core QtCore4"
 libqt_pkg_names="Qt5Core QtCore"
 
-AC_PATH_PROG([pkg_config],[pkg-config])
+AC_PATH_TOOL([pkg_config],[pkg-config])
 
 AC_MSG_CHECKING([for QtCore])
 

Bug#940005: Please package 3.33.91 or remove Geary from Debian

[Michael Gratton]

On Tue, 10 Sep, 2019 at 22:23, Jason Crain  
wrote:

On Wed, Sep 11, 2019 at 01:52:07PM +1000, Michael Gratton wrote:
 Although a great number of features and important bug fixes have 
gone in to
 the last few major releases, the current version of Geary currently 
packaged
 in Debian is still 0.12, which will be 2 years and 3 major releases 
behind

 when 3.34.0 is released late next week.


0.12.4 was release August 2018, one year ago, which doesn't seem that
bad, especially considering that the later releases happened during or
after the Buster freeze.


The 0.12.x releases contains only small, specific fixes that were able 
to be backported from 0.13 with no or minimal code changes. Many, many 
more important fixes have gone into 0.13, 3.32 and the upcoming 3.34 
releases that are missing from 0.12.x.


As the maintainer, I can assure you it's quite bad.

//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 

Bug#939845: modprobe: ERROR: could not insert 'wireguard': Exec format error

[Matthew Gabeler-Lee]

Package: wireguard-dkms
Version: 0.0.20190905-1
Followup-For: Bug #939845

Same problem here.

Seems pretty normal to install updates before activating a new kernel

I notice that systems that have hand-configured wireguard intefaces, the
upgrade scripts won't reload the module, but systems just using
wg-quick@.service do.

Having a system update disable a network interface and fail to restore it is
... bad.  Luckily I wasn't accessing the systems in question over that vpn!

This item from /var/log/kern.log looks like it might be useful in tracing
down the issue:

module: x86/modules: Skipping invalid relocation target, existing value is 
nonzero for type 1, loc fdbe1c28, val c14f00a6

This item from the git log for the new releae also seems like it might be
related, though unlikely:

https://git.zx2c4.com/WireGuard/commit/?id=dcca03f27879701d7377109517176a3aae86619f
> Makefile: allow specifying kernel release
> This makes depmod work when building/installing the module for a kernel
> other than the currently running one.

Not sure if the common dkms scripts might be passing the KERNELRELEASE var
in a way that is messing up the build?  In fairness, that seems ... unlikely
to be the cause of an invalid relocation, and more likely to _fix_ having
built the module for the new kernel before booting it :)

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages wireguard-dkms depends on:
ii  dkms  2.6.1-4
ii  perl  5.28.1-6

Versions of packages wireguard-dkms recommends:
ii  wireguard-tools  0.0.20190905-1

wireguard-dkms suggests no packages.

-- no debconf information

Bug#921949: #921949 ITP: golang-github-containers-storage -- Go library for handling how containers are stored on disk

[Dmitry Smirnov]

Looks like this bug report can be closed as the package has arrived in 
"experimental".

Reinhard, do you mind if I upload it to "unstable" with my recent changes?

Thanks.

-- 
Best wishes,
 Dmitry Smirnov.

---

Under observation, we act less free, which means we effectively are less
free.
-- Edward Snowden


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

Bug#939845: modprobe: ERROR: could not insert 'wireguard': Exec format error

[Matthew Gabeler-Lee]

On Wed, 11 Sep 2019, Matthew Gabeler-Lee wrote:


Not sure if the common dkms scripts might be passing the KERNELRELEASE var
in a way that is messing up the build?  In fairness, that seems ... unlikely
to be the cause of an invalid relocation, and more likely to _fix_ having
built the module for the new kernel before booting it :)


Small addendum: indeed the module built for the new kernel while running 
the old kernel indeed loaded correctly after booting into 4.19.0-6 -- I 
did not need to rebuild the dkms module after rebooting.  It was, 
ironically, only the module built for the _running_ kernel that was bad.


--
-- Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Bug#940005: Please package 3.33.91 or remove Geary from Debian

[Jason Crain]

On Wed, Sep 11, 2019 at 01:52:07PM +1000, Michael Gratton wrote:
> Although a great number of features and important bug fixes have gone in to
> the last few major releases, the current version of Geary currently packaged
> in Debian is still 0.12, which will be 2 years and 3 major releases behind
> when 3.34.0 is released late next week.

0.12.4 was release August 2018, one year ago, which doesn't seem that
bad, especially considering that the later releases happened during or
after the Buster freeze.

Bug#940005: Please package 3.33.91 or remove Geary from Debian

[Michael Gratton]

Package: geary

Hi,

I've just released Geary 3.33.91, which is basically a code complete 
release of Geary 3.34.0.


Although a great number of features and important bug fixes have gone 
in to the last few major releases, the current version of Geary 
currently packaged in Debian is still 0.12, which will be 2 years and 3 
major releases behind when 3.34.0 is released late next week.


So, please update Geary to 3.33.91. If that is not possible, then 
remove it from Debian altogether, because the currently packaged 
version is doing more harm than good.


Thanks,
//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 

Bug#909309: clipit: workaround for the issue

[Dave]

 Downgrading to oldstable version 1.4.2-1.2 makes hotkeys work again.

 I've put this package on hold in my system, so it doesn't get automatically
updated.  It gets annoying having to always downgrade this after updates.

 Cheers,
 dave

Bug#940004: nmu: isl

[Matthias Klose]

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

Please binNMU these packages for the recent isl upload to unstable:

that only affects various gcc packages. the native and cross compilers are 
uploaded, the -mipsen packages are in unstable only, and stuck in NEW, the 
remaining one is


gcc-mingw-w64

Pinged the maintainer too.

Bug#940003: nmu: rebuild packages for binutils 2.32.51.x

[Matthias Klose]

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

Please binNMU these packages for the recent binutils upload to unstable:

naev 0.7.0-2
wcc 0.0.2+dfsg-3 (amd64 only)
looking-glass 0+b1-1

Bug#939147: happened again with gcc-9-cross-ports

[Matthias Klose]

On 10.09.19 21:39, Matthias Klose wrote:

Source-only uploads to NEW are not allowed.

binary:gm2-9-powerpc-linux-gnu is NEW.
binary:gm2-9-powerpc64-linux-gnu is NEW.
binary:gm2-9-sh4-linux-gnu is NEW.
binary:gm2-9-x86-64-linux-gnux32 is NEW.
binary:libgm2-0-powerpc-cross is NEW.
binary:libgm2-0-ppc64-cross is NEW.
binary:libgm2-0-sh4-cross is NEW.
binary:libgm2-0-x32-cross is NEW.
binary:libgm2-9-dev-powerpc-cross is NEW.
binary:libgm2-9-dev-ppc64-cross is NEW.
binary:libgm2-9-dev-sh4-cross is NEW.
binary:libgm2-9-dev-x32-cross is NEW.


sorry, these were packages in the control file, but not in the upload.  This is 
now fixed.


The gcc-7-source removal is still real, although now superseded by the gcc-7 
7.4.0-12 upload.

Bug#940002: wireguard-dkms: kernel module fails to build for kernel 4.19.72

[Celejar]

Package: wireguard-dkms
Version: 0.0.20190905-1
Severity: important

Installation fails for kernel version 4.19.72, self-built (on a
different, Stable system) from vanilla kernel.org sources:

Building module:
cleaning build area...
make -j4 KERNELRELEASE=4.19.72-lila -C /lib/modules/4.19.72-lila/build 
M=/var/lib/dkms/wireguard/0.0.20190905/build...(bad exit status: 2)
Error! Bad return status for module build on kernel: 4.19.72-lila (x86_64)
Consult /var/lib/dkms/wireguard/0.0.20190905/build/make.log for more 
information.

make.log attached.

-- 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_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wireguard-dkms depends on:
ii  dkms  2.7.1-4
ii  perl  5.28.1-6

Versions of packages wireguard-dkms recommends:
ii  wireguard-tools  0.0.20190905-1

wireguard-dkms suggests no packages.

-- no debconf information
DKMS make.log for wireguard-0.0.20190905 for kernel 4.19.72-lila (x86_64)
Tue 10 Sep 2019 10:10:55 PM EDT
make: Entering directory '/usr/src/linux-headers-4.19.72-lila'
  CC [M]  /var/lib/dkms/wireguard/0.0.20190905/build/main.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190905/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190905/build/device.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20190905/build/peer.o
In file included from ./include/linux/compat.h:16,
 from ./include/linux/ethtool.h:17,
 from ./include/linux/netdevice.h:41,
 from ./include/linux/icmpv6.h:13,
 from 
/var/lib/dkms/wireguard/0.0.20190905/build/compat/compat.h:876,
 from :
./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory
   28 | #include/* for struct sockaddr.  */
  |  ^~
compilation terminated.
In file included from ./include/linux/compat.h:16,
 from ./include/linux/ethtool.h:17,
 from ./include/linux/netdevice.h:41,
 from ./include/linux/icmpv6.h:13,
 from 
/var/lib/dkms/wireguard/0.0.20190905/build/compat/compat.h:876,
 from :
./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory
   28 | #include/* for struct sockaddr.  */
  |  ^~
compilation terminated.
In file included from ./include/linux/compat.h:16,
 from ./include/linux/ethtool.h:17,
 from ./include/linux/netdevice.h:41,
 from ./include/linux/icmpv6.h:13,
 from 
/var/lib/dkms/wireguard/0.0.20190905/build/compat/compat.h:876,
 from :
./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory
   28 | #include/* for struct sockaddr.  */
  |  ^~
compilation terminated.
make[1]: *** [scripts/Makefile.build:303: 
/var/lib/dkms/wireguard/0.0.20190905/build/noise.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: *** [scripts/Makefile.build:303: 
/var/lib/dkms/wireguard/0.0.20190905/build/main.o] Error 1
make[1]: *** [scripts/Makefile.build:303: 
/var/lib/dkms/wireguard/0.0.20190905/build/peer.o] Error 1
In file included from ./include/linux/compat.h:16,
 from ./include/linux/ethtool.h:17,
 from ./include/linux/netdevice.h:41,
 from ./include/linux/icmpv6.h:13,
 from 
/var/lib/dkms/wireguard/0.0.20190905/build/compat/compat.h:876,
 from :
./include/linux/if.h:28:10: fatal error: sys/socket.h: No such file or directory
   28 | #include/* for struct sockaddr.  */
  |  ^~
compilation terminated.
make[1]: *** [scripts/Makefile.build:303: 
/var/lib/dkms/wireguard/0.0.20190905/build/device.o] Error 1
make: *** [Makefile:1519: _module_/var/lib/dkms/wireguard/0.0.20190905/build] 
Error 2
make: Leaving directory '/usr/src/linux-headers-4.19.72-lila'

Bug#939893: lime-forensics: autopkgtest regression

[Eriberto Mota]

Em seg, 9 de set de 2019 às 17:23, Paul Gevers  escreveu:
>
> Source: lime-forensics
> Version: 1.8.1-2
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: regression
>
> Dear maintainers,
>
> With a recent upload of lime-forensics the autopkgtest of lime-forensics
> fails in testing when that autopkgtest is run with the binary packages
> of lime-forensics from unstable. It passes when run with only packages
> from testing. In tabular form:
>passfail
> lime-forensics from testing1.8.1-2
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report. Is your test
> broken with a stretch host kernel? If your need isolation-machine,
> please specify that restriction in your autopkgtest declaration:
> """
>
> isolation-machine
> The test wants to interact with the kernel, reboot the machine, or
> other things which fail in a simple schroot and even a container.
> Those tests need to be run in their own machine/VM (e. g.
> autopkgtest-virt-qemu or autopkgtest-virt-null). When running the
> test in a virtualization server which does not provide this it will
> be skipped.
> """
>
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it? If needed, please
> change the bug's severity.
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=lime-forensics
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/l/lime-forensics/2914894/log.gz
>
> Setting up lime-forensics-dkms (1.8.1-2) ...
> Loading new lime-forensics-1.8.1-2 DKMS files...
> It is likely that 4.9.0-8-amd64 belongs to a chroot's host
> Building for
> Setting up autopkgtest-satdep (0) ...
> Processing triggers for systemd (242-5) ...
> Processing triggers for libc-bin (2.28-10) ...
> (Reading database ... 12759 files and directories currently installed.)
> Removing autopkgtest-satdep (0) ...
> autopkgtest [22:18:11]: test command1: /usr/lib/dkms/dkms-autopkgtest
> autopkgtest [22:18:11]: test command1: [---
> dpkg: dependency problems prevent removal of dkms:
>  lime-forensics-dkms depends on dkms (>= 2.1.0.0).
>
> dpkg: error processing package dkms (--remove):
>  dependency problems - not removing
> Errors were encountered while processing:
>  dkms
> I: Installing binary package lime-forensics-dkms
> Reading package lists...
> Building dependency tree...
> Reading state information...
> lime-forensics-dkms is already the newest version (1.8.1-2).
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> tar: Cowardly refusing to create an empty archive
> Try 'tar --help' or 'tar --usage' for more information.
> autopkgtest [22:18:13]: test command1: ---]
>


>From #939982:

-
Hi Eriberto,

Thanks for talking about the issues you have, I could not have guessed.

On 10-09-2019 17:53, Eriberto Mota wrote:
> I was using a test over a DKMS package (lime-forensics). I removed
> all tests[1] because Debian wasn't process it (adding a Neutral tag)
> and to close the bug #935543. Now I have a regression in my
> package[2][3]. However, I no longer maintain a test. I think it is a
> bug in debci. How to proceed to avoid a regression after removing all
> tests?

This is not an issue with debci, as that just runs tests on behalf of
other entities. The culprit here is britney, the migration software of
the release team, hence filing a bug against it. The problem is that the
migration software *seems* (I haven't checked properly yet) to trigger
even in the case that all tests are removed. Because autopkgtest (the
software) is by default configured to try and call autodep8 if no tests
are found, you package was tested with tests from autodep8, while in
your case that is inappropriate as they fail. You have no way of telling
the infrastructure that. As britney considering neutral-to-fail a
regression your package is flagged as such. I see that's nothing you can
solve so I'll ignore the failure.

> [1] 
> https://salsa.debian.org/pkg-security-team/lime-forensics/commit/d7d4c79ae7ea55c5d64cc6103d3745e199056284
> [2] https://ci.debian.net/packages/l/lime-forensics/
> [3]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939893

Paul
-

Thanks a lot Paul. As a temporary workaround, I uploaded a new package
to 1-day/delay queue, with the changes shown here[1].

[1] 
https://salsa.debian.org/pkg-security-team/lime-forensics/commit/0ca063ea176c51b2c4dbe0005f275443f9f0c458

Cheers,

Eriberto

Bug#934974: u-boot: usb start fails on sheevaplug in u-boot 2019.01

[Rick Thomas]

I have a sheevaplug that has been on the shelf for a couple years because it 
appeared to be bricked.  I decided to try to unbrick it to see if I could help 
with these tests.  Unfortunately when I plug it in and connect it to a PC 
running Debian Buster with the micro-USB cable, there is no device /dev/ttyUSB* 
.  I've tried the same thing with an OpenRD box and the device appears as 
expected then.

If I ignore that problem and try to connect with opencd, I get the following 
error messages:

$ openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s 
/usr/share/openocd/scripts
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 
'transport select '.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain 
connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 2000 kHz
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Error: no device found
Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 
'SheevaPlug JTAGKey FT2232D B', serial '*' at bus location '*'

Can anybody help me figure out what to do next?

Thanks!
Rick

> On Sep 5, 2019, at 10:58 AM, Jan Hahne  wrote:
> 
> I was able to unbrick mine with these instructions:
> https://www.newit.co.uk/forum/index.php/topic,2835.0.html
> https://tadeubento.com/2018/sheevaplug-2018-unbrick/
> 

Bug#940001: Source: python-foo + Binary: python3-foo + Binary: python-foo-common -> bad

[Steve Langasek]

Package: autodep8
Version: 0.18
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear maintainers,

In Ubuntu, I discovered when dropping python2 support from python-os-api-ref
that autodep8 has some bugginess in how it decides what versions of python
to run tests for.  (The python-os-api-ref Debian maintainer also found this,
but handled it by adding manual tests; we have not synced the Debian
solution because it's a new upstream version of the package and we're in
feature freeze.)

Specifically, python-os-api-ref has the following setup:

Source: python-os-api-ref

Binary: python-os-api-ref-common

Binary: python3-os-api-ref

The correct module to test imports of is os_api_ref, of course, not
os_api_ref_common; and it should be tested only for python3.

The attached patch fixes this, and also adds a test case for this situation.
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru autodep8-0.18/support/python/generate 
autodep8-0.18ubuntu2/support/python/generate
--- autodep8-0.18/support/python/generate   2019-01-30 11:17:41.0 
-0800
+++ autodep8-0.18ubuntu2/support/python/generate2019-09-10 
15:16:56.0 -0700
@@ -13,10 +13,12 @@
 py3_package=python3-$module
 fi
 
-source_package=$(grep-dctrl -n -s Source -F Source -r '^pypy-.*$' 
debian/control || true)
-if [ -n "$source_package" ] ; then
-module=${source_package#pypy-}
-pypy_package=pypy-$module
+if [ -z "$module" ]; then
+source_package=$(grep-dctrl -n -s Source -F Source -r '^pypy-.*$' 
debian/control || true)
+if [ -n "$source_package" ] ; then
+module=${source_package#pypy-}
+pypy_package=pypy-$module
+fi
 fi
 
 # Try binary package(s)
@@ -39,7 +41,7 @@
 fi
 
 # Try binary package(s)
-if [ -z "$source_package" ] ; then
+if [ -z "$pypy_package" ]; then
 binary_packages=$(grep-dctrl -n -s Package -F Package -r '^pypy-.*$' 
debian/control || true)
 if [ -n "$binary_packages" ] ; then
 for binary_package in $binary_packages ; do
diff -Nru autodep8-0.18/test/python_test.sh 
autodep8-0.18ubuntu2/test/python_test.sh
--- autodep8-0.18/test/python_test.sh   2019-01-30 11:17:41.0 -0800
+++ autodep8-0.18ubuntu2/test/python_test.sh2019-09-10 15:16:41.0 
-0700
@@ -85,6 +85,14 @@
   assertTrue 'have pypy test' 'grep --quiet "pypy -c" stdout'
 }
 
+test_python_ignore_py2_non_module() {
+  has 'debian/control' 'Source: python-foo\n\nPackage: 
python-foo-common\n\nPackage: python3-foo'
+  check_run autodep8
+  assertTrue 'get upstream name' 'grep --quiet "import foo;" stdout'
+  assertFalse 'dont have py2 test' 'grep --quiet "pyversions" stdout'
+  assertTrue 'have py3 test' 'grep --quiet "py3versions" stdout'
+}
+
 test_Testsuite_autopkgtest_pkg_python() {
   has debian/control "Testsuite: autopkgtest-pkg-python"
   check_run autodep8

Bug#388689: tr: no UTF-8 support

[Witold Baryluk]

Package: coreutils
Followup-For: Bug #388689

Hi,

17 years later and this is still not fixed, and had half a dozen of
duplicats in BTS.

$ echo "Zażółć gęślą jaźń" | tr [:lower:] [:upper:]
ZAżółć GęśLą JAźń
$

Wrong.

This is pretty serious deficiency of tr IMHO. And there should be some
push to upstread any patches that fixes at least SOME tools in coreutils.



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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libselinux1  2.9-2+b2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#940000: coreutils: Default time format is not suitable in some locales.

[Witold Baryluk]

Package: coreutils
Version: 8.30-3+b1
Severity: normal

Dear Maintainer,

I don't know exactly how to formulate the problem, but this certainly feels 
wrong:

user@debian:~$ echo $TZ $TZNAME; ls -l /etc/localtime ; cat /etc/timezone ; 
date; TZ=Europe/Zurich date; date --iso-8601=seconds; date --rfc-333=seconds; 
date --rfc-email; date;

lrwxrwxrwx 1 root root 33 Sep 11 00:01 /etc/localtime -> 
/usr/share/zoneinfo/Europe/Zurich
Europe/Zurich
Wed 11 Sep 2019 12:42:33 AM CEST
Wed 11 Sep 2019 12:42:33 AM CEST
2019-09-11T00:42:33+02:00
2019-09-11 00:42:33+02:00
Wed, 11 Sep 2019 00:42:33 +0200
Wed 11 Sep 2019 12:42:33 AM CEST
user@debian:~$ 


Nobody writes "12:42 AM" in Europe. In fact it might be a bug in date.
Because I think most people would interpret 12:42 AM, as just 12:42, not
00:42.

I think it should be one of these three instead:

Wed 11 Sep 2019 00:42:33 AM CEST
Wed 10 Sep 2019 12:42:33 PM CEST   // yes, PM
Wed 11 Sep 2019 00:42:33 CEST   // 24 hour format, without silly AM, PM.


Cheers,
Witold





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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.53-4
ii  libattr1 1:2.4.48-4
ii  libc62.28-10
ii  libselinux1  2.9-2+b2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#933078: runit: forced-rescan feature

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-34
Followup-For: Bug #933078

>> `kill -14 1`
>
> Fire-and-forget -- yes.

I'm doing some live testing on my box before sending a refreshed patch
to init-system-helpers maintainers: sadly this is not working as I expect.

I've added a runit-force-rescan sub to update-rc.d

sub runit_force_rescan {
if (-f "/run/runit.stopit") {
system("kill", "-14", "1");
system("sleep", "1.5");
}
}

and without the `sleep 1.5` i'm still running into
an error on postinst stage (example with openssh-server)

Unpacking openssh-server (1:8.0p1-6) ...
Setting up openssh-server (1:8.0p1-6) ...
insserv: Script rsync has overlapping Default-Start and Default-Stop runlevels 
(2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: Script lvm2 has overlapping Default-Start and Default-Stop runlevels 
(S) and (S). This should be fixed.
warning: ssh: unable to open supervise/ok: file does not exist
invoke-rc.d: initscript ssh, action "restart" failed.
dpkg: error processing package openssh-server (--configure):
 installed openssh-server package post-installation script subprocess returned 
error exit status 1
Processing triggers for man-db (2.8.7-3) ...
Errors were encountered while processing:
 openssh-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

So there is still a lag of 1.5 seconds from the moment runsvdir
detects a new directory and the moment the runsv process create
the ok pipe.
Also, i'm afraid this lag may be affected from the filesystem type
and the hardware, so i need to keep a workaround like (1)
in place.
I'm waiting to test with a service that links the supervise directory
into run (there is none currently), maybe it helps?
Any hope to further reducing this lag?

(1) 
https://salsa.debian.org/debian/init-system-helpers/merge_requests/10/diffs?commit_id=df19096f36689dfe62a8bec3550bd39e7782065a


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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.28-10
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-34

runit suggests no packages.

-- Configuration Files:
/etc/runit/3 changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/runit/invoke-run (from runit package)

Bug#939999: libvulkan-dev: Please include manpages for all library functions, structs, extensions

[Witold Baryluk]

Package: libvulkan-dev
Version: 1.1.114.0-1
Severity: wishlist


The upstream do have both a general Vulkan spec text plus all the
functions description, but the functions and structures / types
documentation is also available as "manual pages", i.e.

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkGetPhysicalDeviceFeatures.html

https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/vkCreateDisplayModeKHR.html

etc.

It can also be found via this page:

https://vulkan.lunarg.com/doc/sdk/1.1.114.0/windows/apispec.html

where they are kind of bundled together.

They already look man-like to me.

These are all generated afaik from common source somewhere, and should be
very easy to generate nroff (or troff/groff) / man files and include in
the package. PS. Make sure they are compressed. man supports .Z, .z and
.gz, and automatically decompresses them. (I have 18380 .gz files in my
/usr/share/man directory, and zero uncompcressed files).

I think this is the source for all these docs, both a specification and
man pages:

https://github.com/KhronosGroup/Vulkan-Docs

It appears that most of the documentation and spec is written in
asciidoctor, and could be transformed to proper format.

I am not sure where exactly the text for this html pages comes from, as
they contain way more descriptions than just what is in the registry
/usr/share/vulkan/registry/vk.xml , which only provide short comments for
each member of struct or argument, but not full documentation and
explanation of semantics, or valid usages. In fact the registry doesn't
provide any comments or descriptions about functions, only about fields
in types (structs).

AFAIK, it would be fine to bundle these man pages in libvulkan-dev
package, without needing separate package.

With possibly separate libvulkan-doc for the full spec text, tutorials
and examples from SDK.

Similar generated docs:

https://devdocs.io/vulkan/
https://vulkan.lunarg.com/doc/view/1.0.30.0/linux/vkspec.chunked/ch04s01.html

Any way, considering how complex and explicit the spec is, with its
number of input, output structs, functions and extensions, it make sense
to have it more accessible from terminal (or other man viewer or IDE that
can link to man pages) quickly without using Internet or Google. ;)

Cheers,
Witold



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

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

Versions of packages libvulkan-dev depends on:
ii  libvulkan1  1.1.114.0-1

libvulkan-dev recommends no packages.

libvulkan-dev suggests no packages.

-- no debconf information

Bug#939998: systemd-logind: Assert due to insufficient function return checks

[Guillem Jover]

Source: systemd
Source-Version: 241-7~deb10u1
Severity: important
Tags: upstream patch buster

Hi!

We hit an assert in logind from the latest systemd package in buster:

  systemd-logind coredumped: in log_assert_failed_realm  ... at 
../src/basic/log.c:795

Investiaging from the following stack trace:

,---
# gdb -c 
core.systemd-logind.0.4c92c46cf794487eb1df36acdfa8d37e.363.156802452000 
/lib/systemd/systemd-logind
[…]
Reading symbols from /lib/systemd/systemd-logind...Reading symbols from 
/usr/lib/debug/.build-id/67/1f5fd985d111ef7cca8db8d01c5175738b0ec6.debug...done.
done.
[New LWP 363]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/lib/systemd/systemd-logind'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
set = {__val = {8589950979, 0, 17179869308, 0, 0, 0, 4096, 255, 
18446744073709551615, 0, 1024, 140109258535907, 4294967295, 4096, 
94012397244720, 140109259796384}}
pid = 
tid = 
ret = 
#1  0x7f6dba8f9535 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x5580f5dcb87e, sa_sigaction 
= 0x5580f5dcb87e}, sa_mask = {__val = {17, 94012397097648, 
13205360909752802304, 206158430240, 94012369043465, 2943, 94012369067104, 2, 
94012369067104, 
  94012397040272, 140109256346163, 0, 0, 0, 140109257989088, 
94012369057967}}, sa_flags = 0, sa_restorer = 0x5580f5dcb8af}
sigs = {__val = {32, 0 }}
#2  0x7f6dba69508a in log_assert_failed_realm (realm=, 
text=0x5580f5dcb8af "pid > 1", file=0x5580f5dc8009 
"../src/login/logind-dbus.c", line=2943, func=0x5580f5dcdc60 
<__PRETTY_FUNCTION__.15284> "manager_start_scope")
at ../src/basic/log.c:795
No locals.
#3  0x5580f5dbc282 in manager_start_scope (job=0x5580f7889330, 
error=0x7ffe8737fb60, more_properties=0x5580f78c1820, 
requires_mounts_for=0x5580f787ceb0 "/root", after=0x7ffe8737f970, 
wants=0x7ffe8737f950, 
description=0x7ffe8737f8d0 "Session 342 of user root", slice=0x5580f787b290 
"user-0.slice", pid=0, scope=0x5580f78ad360 "session-342.scope", 
manager=0x5580f7865c50) at ../src/login/logind-session.c:638
m = 0x0
reply = 0x0
i = 
r = 
m = 
reply = 
i = 
r = 
__PRETTY_FUNCTION__ = 
#4  session_start_scope (s=s@entry=0x5580f78892b0, 
properties=properties@entry=0x5580f78c1820, error=error@entry=0x7ffe8737fb60) 
at ../src/login/logind-session.c:640
scope = 
description = 0x7ffe8737f8d0 "Session 342 of user root"
_ptr_ = 
r = 
__PRETTY_FUNCTION__ = "session_start_scope"
__func__ = "session_start_scope"
_ptr_ = 
#5  0x5580f5dc2a6d in session_start (s=, 
properties=, error=, s=, 
properties=, error=) at 
../src/login/logind-session.c:682
r = 
r = 
__func__ = "session_start"
__PRETTY_FUNCTION__ = "session_start"
#6  0x5580f5db4f1a in method_create_session (message=0x5580f78c1820, 
userdata=, error=0x7ffe8737fb60) at 
../src/login/logind-dbus.c:860
service = 0x5580f787e9d4 "sshd"
type = 0x5580f787e9e0 "tty"
class = 0x5580f787e9e8 "user"
cseat = 0x5580f787e9fc ""
tty = 0x5580f787ea08 ""
display = 0x5580f787ea10 ""
remote_user = 0x5580f787ea1c ""
remote_host = 0x5580f787ea24 "<…REDACTED…>"
desktop = 0x0
id = 0x5580f78b82b0 "342"
session = 0x5580f78892b0
audit_id = 342
m = 
user = 0x5580f78a2490
seat = 
leader = 2973
uid = 0
remote = 1
vtnr = 0
t = 
c = SESSION_USER
r = 1
__PRETTY_FUNCTION__ = "method_create_session"
__func__ = "method_create_session"
#7  0x7f6dba708767 in method_callbacks_run (found_object=0x7ffe8737fc17, 
require_fallback=, c=, m=0x5580f78c1820, 
bus=0x5580f7868c00) at ../src/libsystemd/sd-bus/bus-objects.c:403
slot = 0x5580f786abf0
error = {name = 0x0, message = 0x0, _need_free = 0}
signature = 
u = 0x5580f7865c50
r = 
error = 
signature = 
u = 
r = 
__PRETTY_FUNCTION__ = 
slot = 
__unique_prefix_A8 = 
#8  object_find_and_run (bus=0x5580f7868c00, m=0x5580f78c1820, p=, require_fallback=false, found_object=0x7ffe8737fc17) at 
../src/libsystemd/sd-bus/bus-objects.c:1266
n = 0x5580f786aba0
vtable_key = {path = 0x5580f787e928 "/org/freedesktop/login1", 
interface = 0x5580f787e960 "org.freedesktop.login1.Manager", member = 
0x5580f787e948 "CreateSession", parent = 0x5580f7868c88, last_iteration = 
4152790016, 
  vtable = 

Bug#919877: fixed by 1.7.1-3 upload

[Cédric Boutillier]

Control: fixed -1 ruby-sprite-factory/1.7.1-3

Hi,

This failing test is skipped by a patch since 1.7.1-3. The package now
builds fine. I am therefore closing this bug.

Cheers,

Cédric

Bug#874003: Fixed by both #70 and #75

[Stefan Monnier]

> I tried both of the fixes mentioned in messages #70 and #75. They both
> worked for me. Thanks everyone!

I just bumped into this bug on Debian stable (I suspect that it appeared
when I updated from 10.0 to 10.1).  I had

# cat /home//.config/xfce4/helpers.rc
FileManager=nautilus

#

and after removing this file the problem seems to be fixed.

I also have the file `/usr/share/applications/exo-file-manager.desktop`
which belongs to the `exo-utils` package, but I haven't verified if
removing it (which leaving the /home//.config/xfce4/helpers.rc in
place) fixes the problem.


Stefan

Bug#935290: some more digging

[Robert Lemmen]

I did some more digging on this, no real solution but perhaps its' worth
anything:

- our problem can be tracked down to src/io/fileops.c in moarvm, where
  MVM_file_is_writable tries to work out whether the file can be written
  to, which it decides that it can't because th call into libuv returns
  uid 1234 on my box rather than 0 as expected
- libuv 1.30.1 relative to 1.24 changes src/unix/fs.c and switches to
  callgin statx() rather than stat() 
- putting some more debug into libuv shows that indeed statx() returns
  uid 1234, a call to stat() directly afterwards does correctly return 0
- even outside libuv and moar, the simple code below shows the two different
  uid values when executed against
  /build/rakudo-2019.07.1/debian/rakudo/usr/lib/perl6/core, 1234 from
  statx() and 0 from stat()
- doing a pbuilder login, followed by mkdir and then calling the code
  below does however *not* cause the problem, we get 0 in both cases
- calling the code below during build on a file in the build directory 
  shows the same problem as the .../core
- calling the code below on during build / does not show the problem
- calling against /build/ and anything below does exhibit the problem
- I would therefore assume that git-pbuilder does something when
  creating/mouinting /build/ that throws statx() off track, but not
  stat(), which gets exposed by a newer libuv1. 
- this concludes my digging for today, if anyone knows where that
  /build/ directory gets created when running gbp buildpackage --git-pbuilder
  then please let me know!!

regards  robert

#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv) {
printf("statx test against %s...\n", argv[1]);

struct statx sbuf;
int ret = statx(AT_FDCWD, argv[1], AT_STATX_SYNC_AS_STAT, 0xFFF, );
printf("returned %i\n", ret);
printf("uid is %i\n", sbuf.stx_uid);

struct stat sbuf2;
ret = stat(argv[1], );
printf("stat returned %i\n", ret);
printf("stat uid is %i\n", sbuf2.st_uid);

return 0;

}

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: PGP signature

Bug#939997: dpkg: Please expose other data to post-invoke and pre-invoke commands

[Matt Zagrabelny]

Package: dpkg
Version: 1.19.7
Severity: wishlist

Greetings,

I would like to access other meta data (besides DPKG_HOOK_ACTION) when running
various pre/post-invoke commands.

Would you consider exposing:

DPKG_HOOK_PACKAGE_NAME

That contains the package name?

Thank you!

-m


-- Package-specific info:

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

Kernel: Linux 5.2.0-2-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=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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-1
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  2.9-2+b2
ii  tar  1.30+dfsg-6+b1
ii  zlib1g   1:1.2.11.dfsg-1+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.3
pn  debsig-verify  

-- no debconf information

Bug#939303: matplotlib2: FTBFS unsatisfied b-d

[Rebecca N. Palmer]

Control: tags -1 patch

The dependency chain involved is

matplotlib2 -> python-mpltoolkits.basemap -> python-pyproj, python-pyshp

where all but the first no longer exist as Python 2 packages (and pyproj 
has also moved to a Python 3 only new upstream version).


Searching the code suggests that matplotlib2 no longer uses basemap 
(doc/pyplots/plotmap.py no longer even exists), and hence that a fix is 
to simply remove the build-dependency:


diff --git a/debian/control b/debian/control
index 65917e83..fd7795fc 100644
--- a/debian/control
+++ b/debian/control
@@ -27,7 +27,6 @@ Build-Depends: debhelper (>= 7),
python-kiwisolver,
python-kiwisolver-dbg,
python-mock,
-   python-mpltoolkits.basemap ,
python-nose,
python-numpy,
python-numpy-dbg,

The package builds and passes autopkgtests with this, but that's all the 
testing it's had.  (The build-time tests are skipped with TypeError: 
object of type 'MarkDecorator' has no len().  I suspect this is an 
unrelated incompatibility with the current version of pytest, but 
haven't investigated.)

Bug#931304: [PATCH] hid2hci: Fix udev rules for linux-4.14+

[Dan Streetman]

From: Ville Syrjälä 

Since commit 1455cf8dbfd0 ("driver core: emit uevents when
device is bound to a driver") the kernel started emitting
"bind" and "unbind" uevents which confuse the hid2hci
udev rules.

The symptoms on an affected machine (Dell E5400 in my case)
include bluetooth devices not appearing and udev hogging
the cpu as it's busy processing a constant stream of these
"bind"+"unbind" uevents.

Change the udev rules not do anything except for "add" and
"change" events. This seems to cure my machine at least.

v2: Don't mess up "change" (Zbyszek)
Fix up the commit message a bit

Closes: #931304
Origin: upstream, https://lore.kernel.org/patchwork/patch/1021109/

---
 tools/hid2hci.rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hid2hci.rules b/tools/hid2hci.rules
index db6bb03d2..5c7208af7 100644
--- a/tools/hid2hci.rules
+++ b/tools/hid2hci.rules
@@ -1,6 +1,6 @@
 # do not edit this file, it will be overwritten on update
 
-ACTION=="remove", GOTO="hid2hci_end"
+ACTION!="add|change", GOTO="hid2hci_end"
 SUBSYSTEM!="usb*", GOTO="hid2hci_end"
 
 # Variety of Dell Bluetooth devices - match on a mouse device that is
-- 
2.20.1

Bug#691407: closed by Christian Göttsche (Re: logrotate(8) does not mention all reasons for ignoring included files)

[Roger Lynn]

On 10/09/2019 17:05, Christian Göttsche wrote:

To better document this in the man page, I created
https://github.com/logrotate/logrotate/pull/265


Thank you. Also must not be group writeable. This is what caught me out 
(making the file group writeable in the first place was an accident).


Roger

Bug#939996: RFS: irony-mode/1.3.1-3~bpo10+1

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: normal

Dear mentors (CCing Gianfranco who helped make this possible with llvm bpo),

I am looking for a sponsor for my package "irony-mode".  My motivation
for maintaining the backport is thus: a Debian user on the upstream
bugtracker had difficulty making 1.3.1-1 (version in stable which uses
libclang 7) work with a newer version of libclang (installed à la
frankenDebian).  So let's provide an official solution!

Package name: irony-mode
Version : 1.3.1-3~bpo10+1
URL : https://github.com/Sarcasm/irony-mode/
License : GPL-3+
Vcs : https://salsa.debian.org/emacsen-team/irony-mode
Section : editors

It builds these binary packages:

  elpa-irony - Emacs C/C++ minor mode powered by libclang
  irony-server - Emacs C/C++ minor mode powered by libclang (server)
  irony-mode - Transition Package, irony-mode to elpa-irony

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

  https://mentors.debian.net/package/irony-mode

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/irony-mode/irony-mode_1.3.1-3~bpo10+1.dsc

Changes since the last upload:

   * Rebuild for buster-backports.
 .
 irony-mode (1.3.1-3) unstable; urgency=medium
 .
   [ Nicholas D Steeves ]
   * Switch to debhelper-compat 12.
   * Build against libclang-8.
 .
   [ David Bremner ]
   * Team upload
   * Rebuild with quilt patches
 .
 irony-mode (1.3.1-2) unstable; urgency=medium
 .
   * Team upload.
   * Rebuild with current dh-elpa

Regards,
Nicholas

Bug#929967: #929967 CMake: use TBBConfig instead of FindTBB

[D. Barbier]

tags 929967 patch
thanks

Hello,

Here is a patch to fix this issue.  It replaces FindTBB.cmake by
TBBConfig.cmake.
diff --git a/debian/libtbb-dev.install b/debian/libtbb-dev.install
index 8f44bd13..6deacb46 100755
--- a/debian/libtbb-dev.install
+++ b/debian/libtbb-dev.install
@@ -3,4 +3,4 @@ include/tbb			usr/include
 build/linux_*_release/lib*.so	usr/lib/${DEB_HOST_MULTIARCH}
 debian/tbb.pc			usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig
 cmake/*usr/share/cmake/Modules
-debian/cmake/*			usr/share/cmake/Modules
+build/linux_*_release/TBBConfig*.cmake			usr/lib/${DEB_HOST_MULTIARCH}/cmake/TBB
diff --git a/debian/rules b/debian/rules
index 872d4207..966be016 100755
--- a/debian/rules
+++ b/debian/rules
@@ -58,6 +58,13 @@ override_dh_auto_build-arch:
 	-e "s/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g" \
 		debian/tbb.pc.in > debian/tbb.pc
 	dh_auto_build -- $(BUILD_FLAGS)
+	# Build cmake config files
+	cmake -DINSTALL_DIR=$(wildcard build/linux_*_release) \
+	  -DSYSTEM_NAME=Linux \
+	  -DTBB_VERSION_FILE=include/tbb/tbb_stddef.h \
+	  -DLIB_REL_PATH="../../" \
+	  -DINC_REL_PATH="../../../../include" \
+	  -P cmake/tbb_config_installer.cmake
 
 override_dh_auto_build-indep:
 	$(MAKE) doxygen

Bug#931574: nftables: kernel BUG at lib/list_debug.c:53

[Tim Düsterhus]

Vincent,
Maintainers,

Am 17.07.19 um 19:32 schrieb Vincent Tondellier:
> I think it's fixed by this patch:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/plain/releases/4.19.38/netfilter-nf_tables-fix-set-double-free-in-abort-pat.patch
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=203039
> 
> There were some critical bugfixes for nftables in 4.19.38 and 4.19.44,
> but buster is still using 4.19.37.
> 
> I tried building a vanilla 4.19.59 and excepting a (harmless ?) warning
> ("WARNING: CPU: 0 PID: 176 at net/netfilter/nf_tables_api.c:3588
> nft_set_destroy+0x45/0x50 [nf_tables]) when the nf_tables_set module
> is not loaded before using nftables, everything seems to work fine.
> 

I've re-attempted the upgrade after the point release. With Linux
4.19.67-2 I'm still seeing the issue. The backtrace is slightly
different, though. `nf_tables_rule_destroy` no longer appears. Instead
it's `nf_tables_rule_release` now.

> Sep 10 20:53:35 buster-test kernel: list_del corruption. prev->next should be 
> 9dbc3505, but was 02880f78
> Sep 10 20:53:35 buster-test kernel: [ cut here ]
> Sep 10 20:53:35 buster-test kernel: kernel BUG at lib/list_debug.c:53!
> Sep 10 20:53:35 buster-test kernel: invalid opcode:  [#1] SMP PTI
> Sep 10 20:53:35 buster-test kernel: CPU: 0 PID: 394 Comm: nft Tainted: P  
>  OE 4.19.0-6-amd64 #1 Debian 4.19.67-2
> Sep 10 20:53:35 buster-test kernel: Hardware name: Hetzner vServer, BIOS 
> 2017 11/11/2017
> Sep 10 20:53:35 buster-test kernel: RIP: 
> 0010:__list_del_entry_valid.cold.1+0x34/0x4c
> Sep 10 20:53:35 buster-test kernel: Code: ae c9 9e e8 78 96 d0 ff 0f 0b 48 c7 
> c7 c8 ae c9 9e e8 6a 96 d0 ff 0f 0b 48 89 f2 48 89 fe 48 c7 c7 88 ae c9 9e e8 
> 56 96 d0 ff <0f> 0b 48 89 fe 48 c7 c7 50 ae c9 9e e8 45 96 d0 ff 0f 0b 90 90 
> 90
> Sep 10 20:53:35 buster-test kernel: RSP: 0018:b031804bb968 EFLAGS: 
> 00010246
> Sep 10 20:53:35 buster-test kernel: RAX: 0054 RBX: 
> 9dbc35e56260 RCX: 
> Sep 10 20:53:35 buster-test kernel: RDX:  RSI: 
> 9dbc3aa166b8 RDI: 9dbc3aa166b8
> Sep 10 20:53:35 buster-test kernel: RBP: 9dbc3505 R08: 
> 01c4 R09: 0007
> Sep 10 20:53:35 buster-test kernel: R10: 0738 R11: 
> 9f3f26ed R12: 
> Sep 10 20:53:35 buster-test kernel: R13: b031804bb9f8 R14: 
> 000c R15: 9dbc353386c8
> Sep 10 20:53:35 buster-test kernel: FS:  7f1eafda3200() 
> GS:9dbc3aa0() knlGS:
> Sep 10 20:53:35 buster-test kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Sep 10 20:53:35 buster-test kernel: CR2: 7f49072a8114 CR3: 
> 76502004 CR4: 003606f0
> Sep 10 20:53:35 buster-test kernel: DR0:  DR1: 
>  DR2: 
> Sep 10 20:53:35 buster-test kernel: DR3:  DR6: 
> fffe0ff0 DR7: 0400
> Sep 10 20:53:35 buster-test kernel: Call Trace:
> Sep 10 20:53:35 buster-test kernel:  nf_tables_unbind_set+0x64/0xa0 
> [nf_tables]
> Sep 10 20:53:35 buster-test kernel:  nf_tables_rule_release+0x56/0x90 
> [nf_tables]
> Sep 10 20:53:35 buster-test kernel:  nf_tables_newrule+0x5c1/0x970 [nf_tables]
> Sep 10 20:53:35 buster-test kernel:  ? unmap_page_range+0x851/0xa60
> Sep 10 20:53:35 buster-test kernel:  nfnetlink_rcv_batch+0x4aa/0x660 
> [nfnetlink]
> Sep 10 20:53:35 buster-test kernel:  ? vmap_page_range_noflush+0x26e/0x380
> Sep 10 20:53:35 buster-test kernel:  ? refcount_inc_checked+0x5/0x30
> Sep 10 20:53:35 buster-test kernel:  ? apparmor_capable+0x6b/0xc0
> Sep 10 20:53:35 buster-test kernel:  ? nla_parse+0x31/0xe0
> Sep 10 20:53:35 buster-test kernel:  nfnetlink_rcv+0x10c/0x141 [nfnetlink]
> Sep 10 20:53:35 buster-test kernel:  netlink_unicast+0x181/0x210
> Sep 10 20:53:35 buster-test kernel:  netlink_sendmsg+0x204/0x3d0
> Sep 10 20:53:35 buster-test kernel:  sock_sendmsg+0x36/0x40
> Sep 10 20:53:35 buster-test kernel:  ___sys_sendmsg+0x295/0x2f0
> Sep 10 20:53:35 buster-test kernel:  ? mem_cgroup_commit_charge+0x7a/0x560
> Sep 10 20:53:35 buster-test kernel:  ? mem_cgroup_try_charge+0x86/0x190
> Sep 10 20:53:35 buster-test kernel:  ? refcount_inc_checked+0x5/0x30
> Sep 10 20:53:35 buster-test kernel:  ? apparmor_capable+0x6b/0xc0
> Sep 10 20:53:35 buster-test kernel:  ? security_capable+0x35/0x50
> Sep 10 20:53:35 buster-test kernel:  ? release_sock+0x19/0x90
> Sep 10 20:53:35 buster-test kernel:  __sys_sendmsg+0x57/0xa0
> Sep 10 20:53:35 buster-test kernel:  do_syscall_64+0x53/0x110
> Sep 10 20:53:35 buster-test kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> Sep 10 20:53:35 buster-test kernel: RIP: 0033:0x7f1eb011b914
> Sep 10 20:53:35 buster-test kernel: Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff 
> ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 
> 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 

Bug#925738: libcec: diff for NMU version 4.0.4+dfsg1-2.1

[Boyuan Yang]

Control: tags 925738 + patch
Control: tags 925738 + pending

Dear maintainer,

I've prepared an NMU for libcec (versioned as 4.0.4+dfsg1-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru libcec-4.0.4+dfsg1/debian/changelog libcec-
4.0.4+dfsg1/debian/changelog
--- libcec-4.0.4+dfsg1/debian/changelog 2019-03-08 07:21:44.0 -0500
+++ libcec-4.0.4+dfsg1/debian/changelog 2019-09-10 15:17:57.0 -0400
@@ -1,3 +1,12 @@
+libcec (4.0.4+dfsg1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild against gcc 9.
+  * debian/libcec4.symbols: Refresh symbols again.
+(Closes: #925738)
+
+ -- Boyuan Yang   Tue, 10 Sep 2019 15:17:57 -0400
+
 libcec (4.0.4+dfsg1-2) unstable; urgency=medium
 
   [ Balint Reczey ]
diff -Nru libcec-4.0.4+dfsg1/debian/libcec4.symbols libcec-
4.0.4+dfsg1/debian/libcec4.symbols
--- libcec-4.0.4+dfsg1/debian/libcec4.symbols   2019-03-08 07:21:44.0
-0500
+++ libcec-4.0.4+dfsg1/debian/libcec4.symbols   2019-09-10 15:17:04.0
-0400
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 4.0.4+dfsg1-2~ amd64
+# SymbolsHelper-Confirmed: 4.0.4+dfsg1-2.1~ amd64
 libcec.so.4 libcec4 #MINVER#
  CECDestroy@Base 2.1.4
  CECInitialise@Base 2.1.4
@@ -389,7 +389,6 @@
  _ZN3CEC13CCECProcessorD2Ev@Base 2.1.4
  _ZN3CEC13CCECTypeUtils14GetMaskForTypeENS_15cec_device_typeE@Base 2.1.4
  _ZN3CEC13CCECTypeUtils8ToStringENS_10cec_opcodeE@Base 2.1.4
- _ZN3CEC13CCECTypeUtils8ToStringENS_19cec_logical_addressE@Base 2.1.4
  _ZN3CEC13CCECTypeUtils8ToStringENS_21cec_user_control_codeE@Base 3.0.1
  _ZN3CEC15CAdapterFactory11GetInstanceEPKct@Base 2.1.4
  _ZN3CEC15CAdapterFactory12FindAdaptersEPNS_11cec_adapterEhPKc@Base 2.1.4
@@ -1009,7 +1008,6 @@
  _ZNK3CEC7CLibCEC18GetAdapterVendorIdEv@Base 2.1.4
  _ZNK3CEC7CLibCEC19GetAdapterProductIdEv@Base 2.1.4
  _ZNKSt5ctypeIcE8do_widenEc@Base 4.0.2
- (optional=templinst)
_ZNSt11_Deque_baseIN3CEC11cec_commandESaIS1_EE17_M_initialize_mapEm@Base
4.0.4+dfsg1-2~
  (optional=templinst|arch=armel riscv64)
_ZNSt15_Sp_counted_ptrIDnLN9__gnu_cxx12_Lock_policyE1EE10_M_disposeEv@Base
3.1.0
  (optional=templinst|arch=!armel !riscv64)
_ZNSt15_Sp_counted_ptrIDnLN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
3.0.1
  (optional=templinst|arch=armel riscv64)
_ZNSt15_Sp_counted_ptrIPN3CEC10CCECClientELN9__gnu_cxx12_Lock_policyE1EE10_M_destroyEv@Base
3.1.0
@@ -1051,6 +1049,7 @@
  (optional=templinst)
_ZNSt8_Rb_treeIN3CEC10cec_opcodeESt4pairIKS1_St6vectorINS0_11cec_commandESaIS5_EEESt10_Select1stIS8_ESt4lessIS1_ESaIS8_EE8_M_eraseEPSt13_Rb_tree_nodeIS8_E@Base
2.1.4
  (optional=templinst)
_ZNSt8_Rb_treeIN3CEC19cec_logical_addressESt4pairIKS1_PNS0_13CCECBusDeviceEESt10_Select1stIS6_ESt4lessIS1_ESaIS6_EE17_M_emplace_uniqueIJS2_IS1_S5_S2_ISt17_Rb_tree_iteratorIS6_EbEDpOT_@Base
4.0.3+dfsg1-1~
  (optional=templinst)
_ZNSt8_Rb_treeIN3CEC19cec_logical_addressESt4pairIKS1_PNS0_13CCECBusDeviceEESt10_Select1stIS6_ESt4lessIS1_ESaIS6_EE8_M_eraseEPSt13_Rb_tree_nodeIS6_E@Base
2.1.4
+ (optional=templinst)
_ZNSt8_Rb_treeIN3CEC19cec_logical_addressESt4pairIKS1_St10shared_ptrINS0_10CCECClientEEESt10_Select1stIS7_ESt4lessIS1_ESaIS7_EE17_M_emplace_uniqueIJS2_IS1_S6_S2_ISt17_Rb_tree_iteratorIS7_EbEDpOT_@Base
4.0.4+dfsg1-2.1~
  (optional=templinst)
_ZNSt8_Rb_treeIN3CEC19cec_logical_addressESt4pairIKS1_St10shared_ptrINS0_10CCECClientEEESt10_Select1stIS7_ESt4lessIS1_ESaIS7_EE5eraseERS3_@Base
3.0.1
  (optional=templinst)
_ZNSt8_Rb_treeIN3CEC19cec_logical_addressESt4pairIKS1_St10shared_ptrINS0_10CCECClientEEESt10_Select1stIS7_ESt4lessIS1_ESaIS7_EE8_M_eraseEPSt13_Rb_tree_nodeIS7_E@Base
3.0.1
  (optional=templinst)
_ZNSt8_Rb_treeImSt4pairIKmPN3CEC28CCECAdapterMessageQueueEntryEESt10_Select1stIS5_ESt4lessImESaIS5_EE17_M_emplace_uniqueIJS0_ImS4_S0_ISt17_Rb_tree_iteratorIS5_EbEDpOT_@Base
4.0.4+dfsg1-2~


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

Bug#939904: systemd should ship resolvconf symlink in some package

[Daniel Kahn Gillmor]

On Tue 2019-09-10 08:54:35 +0200, Michael Biebl wrote:
> wouldn't it be better if wireguard calls resolvctl directly?
> Then it knows exactly what kind of behaviour it'll get.
>
> You're right about the resolvconf.1 man page. We should not ship that in
> the systemd man page since we don't ship the resolvconf symlink either
> (for obvious reasons).

Hm, Jason (wireguard upstream, cc'ed here) seems to believe strongly in
the resolvconf interface.  he writes [0]:

>> The standard interface for modifying DNS on Linux is resolvconf. It is for
>> this reason that systemd added the compatibility layer. Debian should
>> install the proper symlink. WireGuard upstream will support the standard
>> mechanism of resolvconf.

fwiw, I don't understand the vehemence of his allegiance to this
interface, especially given the amount of trouble its different
implementations have caused him (and others) in the past, but *shrug*
i'd also prefer not to diverge from the version of wg-quick that he's
shipping upstream, unless someone from the systemd team wants to supply
a patch that they think is a reliable fix for the linux bash
implementation [1].

Is the resolvectl interface stable as documented?

So for wireguard's purposes, it would be good to figure out how to get
some debian package that ships the symlink in question (i understand why
you can't ship the symlink by default in the systemd package -- it would
conflict with the other implementations of resolvconf).

Is there a chance that the systemd source would generate such a package
(one that enables systemd-resolved, and supplies the symlinks to the
binary and the manpage)?

If not, feel free to close this bug with an explanation of why that's
not acceptable.

Thanks for your work in maintaining systemd.

 --dkg

[0] https://lists.zx2c4.com/pipermail/wireguard/2019-September/004521.html
[1] 
https://salsa.debian.org/debian/wireguard/blob/debian/master/src/tools/wg-quick/linux.bash


signature.asc
Description: PGP signature

Bug#939995: libltcsmpte: no reverse dependencies - remove from the archive?

[Sebastian Ramacher]

Package: src:libltcsmpte
Version: 0.4.4-1
Severity: serious
Tags: sid bullseye

libltcsmpte currently does not have any reverse dependencies in the
archive. So, do we still need the package to be in the archive? If not,
I'd suggest to remove it.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#939994: mailscripts: use https instead of http

[Daniel Kahn Gillmor]

Package: mailscripts
Version: 0.10-1
Severity: wishlist
Tags: patch

It's 2019, please use https!

Thanks for maintaining mailscripts.

 --dkg

diff --git a/email-extract-openpgp-certs b/email-extract-openpgp-certs
index 2a95748..03b7753 100755
--- a/email-extract-openpgp-certs
+++ b/email-extract-openpgp-certs
@@ -13,7 +13,7 @@
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see .
+# along with this program.  If not, see .
 
 '''Extract all OpenPGP certificates from an e-mail message
 
diff --git a/maildir-import-patch b/maildir-import-patch
index a17c6cb..f69a5e6 100755
--- a/maildir-import-patch
+++ b/maildir-import-patch
@@ -15,7 +15,7 @@
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see .
+# along with this program.  If not, see .
 
 import os
 import sys
diff --git a/mailscripts.el b/mailscripts.el
index 0198a3c..f7a7d58 100644
--- a/mailscripts.el
+++ b/mailscripts.el
@@ -17,7 +17,7 @@
 ;; GNU General Public License for more details.
 
 ;; You should have received a copy of the GNU General Public License
-;; along with this program.  If not, see .
+;; along with this program.  If not, see .
 
 ;;; Code:
 
diff --git a/mbox2maildir b/mbox2maildir
index 351a37c..e2f8e23 100755
--- a/mbox2maildir
+++ b/mbox2maildir
@@ -15,7 +15,7 @@
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see .
+# along with this program.  If not, see .
 
 # Credits:
 
diff --git a/mdmv b/mdmv
index c81e52d..fa1533f 100755
--- a/mdmv
+++ b/mdmv
@@ -15,7 +15,7 @@
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see .
+# along with this program.  If not, see .
 
 import os
 import sys
diff --git a/notmuch-extract-patch/LICENSE b/notmuch-extract-patch/LICENSE
index 94a9ed0..e600086 100644
--- a/notmuch-extract-patch/LICENSE
+++ b/notmuch-extract-patch/LICENSE
@@ -1,7 +1,7 @@
 GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
 
- Copyright (C) 2007 Free Software Foundation, Inc. 
+ Copyright (C) 2007 Free Software Foundation, Inc. 
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 
@@ -645,7 +645,7 @@ the "copyright" line and a pointer to where the full notice is found.
 GNU General Public License for more details.
 
 You should have received a copy of the GNU General Public License
-along with this program.  If not, see .
+along with this program.  If not, see .
 
 Also add information on how to contact you by electronic and paper mail.
 
@@ -664,11 +664,11 @@ might be different; for a GUI interface, you would use an "about box".
   You should also get your employer (if you work as a programmer) or school,
 if any, to sign a "copyright disclaimer" for the program, if necessary.
 For more information on this, and how to apply and follow the GNU GPL, see
-.
+.
 
   The GNU General Public License does not permit incorporating your program
 into proprietary programs.  If your program is a subroutine library, you
 may consider it more useful to permit linking proprietary applications with
 the library.  If this is what you want to do, use the GNU Lesser General
 Public License instead of this License.  But first, please read
-.
+.
diff --git a/notmuch-extract-patch/notmuch-extract-patch b/notmuch-extract-patch/notmuch-extract-patch
index df87a6c..cfd4464 100755
--- a/notmuch-extract-patch/notmuch-extract-patch
+++ b/notmuch-extract-patch/notmuch-extract-patch
@@ -15,7 +15,7 @@
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program.  If not, see .
+# along with this program.  If not, see .
 
 import mailbox
 import sys
diff --git a/notmuch-import-patch b/notmuch-import-patch
index ea61634..5a8e589 100755
--- a/notmuch-import-patch
+++ b/notmuch-import-patch
@@ -15,7 +15,7 @@
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public 

Bug#939993: mailscripts: adopt printmimestructure from notmuch

[Daniel Kahn Gillmor]

Package: mailscripts
Version: 0.10-1
Severity: wishlist
Tags: patch

Hi!

notmuch has held the `printmimestructure` utility in its source repo for
a half-dozen years, but we've never shipped it and made it accessible to
non-developers.

It's pretty handy for debugging e-mail formatting issues and writing
specifications about e-mail, so i want to contribute it to mailscripts.

I've imported the original history from the notmuch repo, cleaned up the
source a little bit, renamed it `email-print-mime-structure` (to match
the "conventions" we're starting to establish in mailscripts), and added
a manpage for it.

This is on the "email-print-mime-structure" branch at
https://salsa.debian.org/dkg/mailscripts.git -- maybe you can merge from
there directly?

I'm attaching a monolithic patch here, but the series on that branch is
a more sensible thing to merge, as it preserves history and some
justifications in the commit messages that could be handy in future code
archeology.

Please adopt!  If you don't want me to maintain it in mailscrits, i'll
continue keeping it in the `notmuch` tree, but i'd really rather it be
easier for others to get at.

See also:

  https://salsa.debian.org/dkg/mailscripts/merge_requests/2

(if you want to put mailscripts into a shared repo on salsa, i'd be
happy to make merge requests against it directly for things like this,
let me know what workflow you prefer)

  --dkg

diff --git a/Makefile b/Makefile
index 48cb2fa..352f6f0 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,7 @@
 MANPAGES=mdmv.1 mbox2maildir.1 \
 	notmuch-slurp-debbug.1 notmuch-extract-patch.1 maildir-import-patch.1 \
 	email-extract-openpgp-certs.1 \
+	email-print-mime-structure.1 \
 	notmuch-import-patch.1
 
 all: $(MANPAGES)
@@ -10,5 +11,6 @@ clean:
 
 %.1: %.1.pod
 	pod2man --section=1 --date="Debian Project" --center="User Commands" \
+		--utf8 \
 		--name=$(subst .1,,$@) \
 		$^ $@
diff --git a/debian/control b/debian/control
index 8667a6c..6d3a54f 100644
--- a/debian/control
+++ b/debian/control
@@ -55,3 +55,7 @@ Description: collection of scripts for manipulating e-mail on Debian
  maildir-import-patch -- import a git patch series into a maildir
  .
  notmuch-import-patch -- import a git patch series into notmuch
+ .
+ email-print-mime-structure -- tree view of a message's MIME structure
+ .
+ email-extract-openpgp-certs -- extract OpenPGP certificates from a message
diff --git a/debian/mailscripts.install b/debian/mailscripts.install
index d6f69f5..99216c1 100644
--- a/debian/mailscripts.install
+++ b/debian/mailscripts.install
@@ -5,3 +5,4 @@ maildir-import-patch /usr/bin
 notmuch-import-patch /usr/bin
 notmuch-extract-patch/notmuch-extract-patch /usr/bin
 email-extract-openpgp-certs /usr/bin
+email-print-mime-structure /usr/bin
diff --git a/debian/mailscripts.manpages b/debian/mailscripts.manpages
index ab761b2..6d7cb30 100644
--- a/debian/mailscripts.manpages
+++ b/debian/mailscripts.manpages
@@ -5,3 +5,4 @@ maildir-import-patch.1
 notmuch-import-patch.1
 notmuch-extract-patch.1
 email-extract-openpgp-certs.1
+email-print-mime-structure.1
diff --git a/email-print-mime-structure b/email-print-mime-structure
new file mode 100755
index 000..7adeb2b
--- /dev/null
+++ b/email-print-mime-structure
@@ -0,0 +1,77 @@
+#!/usr/bin/env python3
+# -*- coding: utf-8 -*-
+
+# Copyright (C) 2019 Daniel Kahn Gillmor
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or (at
+# your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+'''
+This script reads a MIME message from stdin and produces a treelike
+representation on it stdout.
+
+Example:
+0 dkg@alice:~$ printmimestructure < 'Maildir/cur/1269025522.M338697P12023.monkey,S=6459,W=6963:2,Sa'
+└┬╴multipart/signed 6546 bytes
+ ├─╴text/plain inline 895 bytes
+ └─╴application/pgp-signature inline [signature.asc] 836 bytes
+0 dkg@alice:~$
+
+If you want to number the parts, i suggest piping the output through
+something like "cat -n"
+'''
+import email
+import sys
+
+def print_part(z, prefix):
+fname = '' if z.get_filename() is None else ' [' + z.get_filename() + ']'
+cset = '' if z.get_charset() is None else ' (' + z.get_charset() + ')'
+disp = z.get_params(None, header='Content-Disposition')
+if (disp is None):
+disposition = ''
+else:
+disposition = ''
+for d in disp:
+if d[0] in [ 'attachment', 'inline' ]:
+disposition = ' ' + d[0]
+if z.is_multipart():
+nbytes = 

Bug#939992: ips FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: ips
Version: 4.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ips fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that is using dh_auto_build.
Please consider applying the attached patch.

Helmut
diff -u ips-4.0/debian/changelog ips-4.0/debian/changelog
--- ips-4.0/debian/changelog
+++ ips-4.0/debian/changelog
@@ -1,3 +1,10 @@
+ips (4.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 10 Sep 2019 22:09:36 +0200
+
 ips (4.0-1) unstable; urgency=low
 
   * New upstream version
diff -u ips-4.0/debian/control ips-4.0/debian/control
--- ips-4.0/debian/control
+++ ips-4.0/debian/control
@@ -2,7 +2,7 @@
 Section: admin 
 Priority: extra
 Maintainer: Michael Meskes 
-Build-Depends: debhelper (>= 5), quilt (>= 0.40), libncurses5-dev, libxt-dev
+Build-Depends: debhelper (>= 7), quilt (>= 0.40), libncurses5-dev, libxt-dev
 Standards-Version: 3.8.4
 
 Package: ips
diff -u ips-4.0/debian/rules ips-4.0/debian/rules
--- ips-4.0/debian/rules
+++ ips-4.0/debian/rules
@@ -23,10 +23,7 @@
 
 build-stamp: configure-stamp 
dh_testdir
-
-   # Add here commands to compile the package.
-   $(MAKE) 
-
+   dh_auto_build
touch $@
 
 clean: unpatch

Bug#939991: the tracker page lists binaries which are in the control file, but not in the archive

[Matthias Klose]

Package: tracker.debian.org

the tracker page lists binaries (on the lower left side) which are in the 
control file, but not in the archive.  Seen with the gcc-9-cross-ports package, 
where some packages were in the control file, accepted in an upload which went 
through NEW.   Yes, that's a mistake, but these packages were never in the 
archive. So maybe check, if binary packages are really in the archive?


Seen when trying to upload a source only gcc-9-cross-ports, which was correctly 
rejected.


Source-only uploads to NEW are not allowed.

binary:gm2-9-powerpc-linux-gnu is NEW.
binary:gm2-9-powerpc64-linux-gnu is NEW.
binary:gm2-9-sh4-linux-gnu is NEW.
binary:gm2-9-x86-64-linux-gnux32 is NEW.
binary:libgm2-0-powerpc-cross is NEW.
binary:libgm2-0-ppc64-cross is NEW.
binary:libgm2-0-sh4-cross is NEW.
binary:libgm2-0-x32-cross is NEW.
binary:libgm2-9-dev-powerpc-cross is NEW.
binary:libgm2-9-dev-ppc64-cross is NEW.
binary:libgm2-9-dev-sh4-cross is NEW.
binary:libgm2-9-dev-x32-cross is NEW.

The second gcc-9-cross-ports-10 upload not listing these in the control file was 
correctly accepted.

Bug#939990: bird: CVE-2019-16159

[Salvatore Bonaccorso]

Source: bird
Version: 1.6.7-1
Severity: grave
Tags: security upstream
Forwarded: 
http://trubka.network.cz/pipermail/bird-users/2019-September/013718.html
Control: found -1 1.6.6-1

Hi,

The following vulnerability was published for bird.

CVE-2019-16159[0]:
| BIRD Internet Routing Daemon 1.6.x through 1.6.7 and 2.x through 2.0.5
| has a stack-based buffer overflow. The BGP daemon's support for RFC
| 8203 administrative shutdown communication messages included an
| incorrect logical expression when checking the validity of an input
| message. Sending a shutdown communication with a sufficient message
| length causes a four-byte overflow to occur while processing the
| message, where two of the overflow bytes are attacker-controlled and
| two are fixed.


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-16159
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16159
[1] http://trubka.network.cz/pipermail/bird-users/2019-September/013722.html
[2] http://trubka.network.cz/pipermail/bird-users/2019-September/013720.html
[3] http://trubka.network.cz/pipermail/bird-users/2019-September/013718.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#939989: transition: gdal

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: block -1 by 939872 939891 931944
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html

For the Debian GIS team I'd like to transition to GDAL 3.x. This is the
next step in the major update of the GIS stack after PROJ 6.

All reverse dependencies rebuilt successfully with GDAL 3.0.1 from
experimental as summarized below, except fiona, mysql-workbench & vtk7.

The fiona issue is actually related to GDAL 3, mysql-workbench FTBFS due
to gcc-9 & -Werror, and vtk7 hasn't been updated for PROJ 6 yet.

libgdal-grass doesn't need a binNMU as the 3.0.1 version will be
uploaded to unstable instead.


Transition: gdal

 libgdal20 (2.4.2+dfsg-1+b2) -> libgdal26 (3.0.1+dfsg-1~exp3)

The status of the most recent rebuilds is as follows.

 dans-gdal-scripts   (0.24-3) OK
 fiona   (1.8.6-2)FTBFS (#939872)
 gazebo  (9.6.0-2)OK
 gmt (5.4.5+dfsg-2)   OK
 libcitygml  (2.0.9-2)OK
 libosmium   (2.15.2-1)   OK
 mapcache(1.8.0-1)OK
 mapnik  (3.0.22+ds1-1)   OK
 mapproxy(1.12.0-1)   OK
 mapserver   (7.4.1-1)OK
 mysql-workbench (8.0.17+dfsg-1)  FTBFS (#939891)
 ncl (6.6.2-1)OK
 node-srs(0.4.8+dfsg-4)   OK
 octave-mapping  (1.2.1-4)OK
 openorienteering-mapper (0.8.4-2)OK
 openscenegraph  (3.2.3+dfsg1-3)  OK
 pdal(2.0.1+ds-1) OK
 pgsql-ogr-fdw   (1.0.8-1)OK
 pktools (2.6.7.6+ds-2)   OK
 postgis (2.5.3+dfsg-1)   OK
 pprepair(0.0~20170614-dd91a21-3) OK
 prepair (0.7.1-3)OK
 python-django   (2:2.2.5-1)  OK
 qmapshack   (1.13.1-1)   OK
 r-cran-mi   (1.0-7)  OK
 r-cran-rgdal(1.4-4-1)OK
 r-cran-sf   (0.7-7+dfsg-1)   OK
 r-cran-tmvtnorm (1.4-10-3)   OK
 rasterio(1.0.28-1)   OK
 sumo(1.1.0+dfsg1-1)  OK
 vtk6(6.3.0+dfsg2-3)  OK
 vtk7(7.1.1+dfsg1-12) FTBFS (#931944)

 cloudcompare(2.10.3-3)   OK
 grass   (7.8.0-1)OK
 opencv  (3.2.0+dfsg-6)   OK
 openscenegraph-3.4  (3.4.1+dfsg1-5)  OK
 osmcoastline(2.2.4-1)OK
 pyosmium(2.15.3-1)   OK

 libgdal-grass   (2.4.2-3 / 3.0.1-1~exp3) FTBFS / OK
 osgearth(2.10.2+dfsg-1)  OK
 otb (6.6.1+dfsg-3)   OK
 qgis(3.4.11+dfsg-2)  OK
 saga(7.3.0+dfsg-1)   OK


Kind Regards,

Bas

Bug#939988: libonig: CVE-2019-16163

[Salvatore Bonaccorso]

Source: libonig
Version: 6.9.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/kkos/oniguruma/issues/147

Hi,

The following vulnerability was published for libonig.

CVE-2019-16163[0]:
| Oniguruma before 6.9.3 allows Stack Exhaustion in regcomp.c because of
| recursion in regparse.c.


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-16163
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16163
[1] https://github.com/kkos/oniguruma/issues/147
[2] 
https://github.com/kkos/oniguruma/commit/4097828d7cc87589864fecf452f2cd46c5f37180

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#933002: docker.io: CVE-2019-13139

[Adam D. Barratt]

On Sun, 2019-08-18 at 16:22 +0100, Adam D. Barratt wrote:
> On Sun, 2019-08-18 at 16:56 +0200, Arnaud Rebillout wrote:
> > * The bug you want to fix in stable must be fixed in unstable
> >   already (and not waiting in NEW or the delayed queue)
> > 
> > My issue with this particular bug (#933002) is that for now,
> > docker.io  doesn't build in unstable. It will take a while before
> > it
> > builds again,  as there was changes in the dependency tree.
> > 
> > On the other hand, fixing this bug in stable is just a matter of 
> > importing the patch from upstream and rebuilding the package.
> > 
> > So how am I supposed to handle that? Waiting for docker.io to be
> > fixed  and built again in unstable will delay the fix in stable for
> > weeks, I  don't think it's a good option.
> 
> Nevertheless, that is the case I'm afraid. Updates to stable via
> proposed-updates are not appropriate for urgent security updates -
> that is what the security archive is for.

For the record, this fix became part of DSA 4521.

> Looking at 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=docker.io
> , there doesn't appear to be a bug filed for the build failure, so
> there's no indication of what the issues are, nor what needs to be
> done to fix them.

and it looks like the build failures got fixed.

Regards,

Adam

Bug#939147: happened again with gcc-9-cross-ports

[Matthias Klose]

Source-only uploads to NEW are not allowed.

binary:gm2-9-powerpc-linux-gnu is NEW.
binary:gm2-9-powerpc64-linux-gnu is NEW.
binary:gm2-9-sh4-linux-gnu is NEW.
binary:gm2-9-x86-64-linux-gnux32 is NEW.
binary:libgm2-0-powerpc-cross is NEW.
binary:libgm2-0-ppc64-cross is NEW.
binary:libgm2-0-sh4-cross is NEW.
binary:libgm2-0-x32-cross is NEW.
binary:libgm2-9-dev-powerpc-cross is NEW.
binary:libgm2-9-dev-ppc64-cross is NEW.
binary:libgm2-9-dev-sh4-cross is NEW.
binary:libgm2-9-dev-x32-cross is NEW.

Bug#935304: #935304: Remove wontfix tag

[Svante Signell]

tags 935304 -wontfix
thanks

Bug#874950: New version stable?

[Shengjing Zhu]

(CC previous sponsor as well)

Hi,

On Thu, Aug 29, 2019 at 5:36 PM Shengjing Zhu  wrote:
>
> Hi Diego,
>
> On Wed, Jul 24, 2019 at 12:32 AM Shengjing Zhu  wrote:
> >
> > On Mon, 22 Jul 2019 01:09:00 -0300 Diego Sarzi  wrote:
> > > Thank you Shenging Zhy for the contribution.
> > >
> > > Can you tell me how is the stability of keepassx with its modifications,
> > > referring to QT4 for QT5?
> > >
> > > Can we use it for the unstable version?
> > >
> >
> > Hi, I see you adopt this package. That's great.
> >
> > I don't know the stability. But I have used this version after I
> > uploaded it experimental, and didn't have any problem.
>
> As keepassx will be removed from testing at 02 Sept, what's the plan
> for you to upload the qt5 version? Do you need sponsor? I'm glad to
> help.
>

This bug is RC and keepassx will be removed in 2 days.
But I haven't received your response.
So I'm going to NMU keepassx in DELAY/2-day, please tell me I should
cancel it or speed it up.

The full changelog can be seen at
https://salsa.debian.org/debian/keepassx/compare/8da06bb...66024d9

Thanks.

--
Shengjing Zhu

Bug#939987: postgresql-hll is broken with glibc 2.29-1

[Paul Gevers]

Package: postgresql-hll
Severity: serious
Forwarded: https://github.com/citusdata/postgresql-hll/issues/67

Conform the discussion on IRC (below) I am going to remove
postgresql-hll from bullseye as the glibc transition has started. This
bug is to keep it out of bullseye until the package is fixed.

Paul

2019-09-04 on #debian-release

[20:45:52]  Myon: how does
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/postgresql-hll/2871470/log.gz
look to you?
[20:46:08]  it's the failure in unstable with glibc from
experimental
[20:46:35]  would that remain an issue if we start the glibc
transition?
[20:47:46]  (I don't the failure will go away with a retry will it?)
[20:59:43]  elbrus: oh so that landed in Debian now. Ubuntu has
already had that problem for a while. Unfortunately
https://github.com/citusdata/postgresql-hll/issues/67 is dormant
[21:00:13]  Myon: still in experimental
[21:00:38]  nod
[21:01:03]  but a transition slot was requested
[21:01:05]  so experimental "migrations" are being tested like
testing now?
[21:01:22]  more or less
[21:01:24]  yes
[21:01:25]  nice
[21:01:38]  still not cronned due to "issues"
[21:02:11]  I don't have a plan for that problem - it's a niche
package, so it's not really much of an issue
[21:02:15] 
https://lists.debian.org/debian-devel/2019/09/msg00014.html
[21:02:36]  can you disable the test then?
[21:03:26]  I'd rather prefer if you could put the package on
ignore, or remove it from testing
[21:03:37]  because that looks like real breakage, not just in the
test
[21:04:00]  but I haven't even glanced at the problem
[21:05:27]  a, ok, I'll remove it when the transition starts than



signature.asc
Description: OpenPGP digital signature

Bug#939986: linux-image-5.2.0-2-amd64: hostapd always crashes nl80211_get_reg_do in nl80211 module

[nozzy123nozzy]

Package: src:linux
Version: 5.2.9-2
Severity: grave

Dear Maintainer,

I found hostapd always crashes nl80211_get_reg_do in nl80211 module of
this version of kernel.This cause hostapd always fails to start as wifi
ap.

The hostapd which I used is 
ii  hostapd2:2.9-1  amd64  

The hostapd always shows errors as below,
 -here
$ sudo /usr/sbin/hostapd -P /run/hostapd.pid /etc/hostapd/hostapd.conf
Configuration file: /etc/hostapd/hostapd.conf
rfkill: WLAN soft blocked
wlp5s0: Could not connect to kernel driver
Using interface wlp5s0 with hwaddr 28:16:ad:e9:10:c9 and ssid
"debianspot"
Failed to set beacon parameters
wlp5s0: Could not connect to kernel driver
Interface initialization failed
wlp5s0: interface state UNINITIALIZED->DISABLED
wlp5s0: AP-DISABLED 
wlp5s0: Unable to setup interface.
wlp5s0: interface state DISABLED->DISABLED
wlp5s0: AP-DISABLED 
wlp5s0: CTRL-EVENT-TERMINATING 
hostapd_free_hapd_data: Interface wlp5s0 wasn't started
nl80211: deinit ifname=wlp5s0 disabled_11b_rates=0
   here-
Does anyone fix this problem? 

Takahide Nojima

-- Package-specific info:
** Version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 root=UUID=f8dd9a0a-8954-4faa-
afe8-ecda81deca67 ro quiet apparmor=1 security=apparmor

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[ 2651.785561] WARNING: CPU: 2 PID: 6111 at net/wireless/nl80211.c:6859
nl80211_get_reg_do+0x1fc/0x210 [cfg80211]
[ 2651.785562] Modules linked in: ppp_deflate bsd_comp ppp_async
crc_ccitt ppp_generic slhc fuse rfcomm xt_MASQUERADE
nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype
nft_compat xt_conntrack br_netfilter overlay cmac cdc_acm bridge stp
llc cpufreq_powersave cpufreq_userspace cpufreq_conservative bnep
nfnetlink_log intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
kvm_intel arc4 kvm irqbypass nf_log_ipv4 nf_log_common crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel nft_log pktcdvd btusb snd_soc_skl
btrtl btbcm btintel snd_soc_skl_ipc bluetooth snd_soc_sst_ipc iwlmvm
snd_soc_sst_dsp snd_hda_codec_hdmi mac80211 snd_hda_ext_core nft_limit
snd_soc_acpi_intel_match snd_hda_codec_realtek snd_hda_codec_generic
ledtrig_audio snd_soc_acpi snd_soc_core snd_compress binfmt_misc
uvcvideo snd_hda_intel iwlwifi joydev nls_ascii videobuf2_vmalloc
nls_cp437 videobuf2_memops videobuf2_v4l2 snd_hda_codec drbg
videobuf2_common vfat aesni_intel cfg80211 fat ansi_cprng snd_hda_core
nft_ct
[ 2651.785583]  videodev sg ecdh_generic aes_x86_64 crypto_simd cryptd
ecc glue_helper snd_hwdep tpm_tis intel_th_gth intel_th_pci snd_pcm
media efi_pstore tpm_tis_core intel_cstate wdat_wdt intel_uncore
snd_timer pcspkr intel_wmi_thunderbolt serio_raw intel_rapl_perf
efivars watchdog snd mei_me intel_th rtsx_pci_ms intel_pch_thermal
soundcore memstick idma64 mei tpm hid_multitouch rfkill rng_core
nft_masq pcc_cpufreq battery evdev intel_hid ac sparse_keymap
nf_tables_set acpi_pad nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 nf_tables nfnetlink efivarfs ip_tables x_tables autofs4
ext4 crc16 mbcache jbd2 sr_mod cdrom raid10 raid456 async_raid6_recov
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c
crc32c_generic raid1 raid0 multipath linear md_mod intel_ishtp_hid uas
usb_storage scsi_mod hid_generic i915 rtsx_pci_sdmmc mmc_core
i2c_designware_platform i2c_designware_core i2c_algo_bit crc32c_intel
drm_kms_helper xhci_pci nvme xhci_hcd psmouse drm nvme_core
[ 2651.785612]  i2c_i801 usbcore rtsx_pci intel_ish_ipc intel_ishtp
i2c_hid intel_lpss_pci intel_lpss hid mfd_core usb_common wmi button
video
[ 2651.785618] CPU: 2 PID: 6111 Comm: hostapd Tainted:
GW 5.2.0-2-amd64 #1 Debian 5.2.9-2
[ 2651.785619] Hardware name: VAIO Corporation VJZ131/VAIO, BIOS
R1194SA 01/25/2017
[ 2651.785633] RIP: 0010:nl80211_get_reg_do+0x1fc/0x210 [cfg80211]
[ 2651.785634] Code: ff 48 89 ef e8 c5 a5 b1 cc b8 a6 ff ff ff eb 89 eb
ef b8 97 ff ff ff eb 80 e8 70 04 5b cc 48 c7 c7 08 18 d1 c0 e8 b2 81 61
cc <0f> 0b 48 89 ef e8 9a a5 b1 cc b8 ea ff ff ff e9 5b ff ff ff 0f 1f
[ 2651.785635] RSP: 0018:a43e4468bac8 EFLAGS: 00010246
[ 2651.785636] RAX: 0024 RBX:  RCX:
0006
[ 2651.785637] RDX:  RSI: 0092 RDI:
921d36b17680
[ 2651.785638] RBP: 921cdd6a1b00 R08: f394 R09:
0004
[ 2651.785638] R10:  R11: 0001 R12:
a43e4468bb50
[ 2651.785639] R13: 921d33e89014 R14: 0001 R15:
921d33f54300
[ 2651.785640] FS:  7effb5d22540() GS:921d36b0()
knlGS:
[ 2651.785641] CS:  0010 DS:  ES:  CR0: 80050033
[ 2651.785641] CR2: 55c4855c86d8 CR3: 0001a5ef8003 CR4:
003606e0
[ 2651.785642] Call Trace:
[ 2651.785648]  ? _cond_resched+0x15/0x30
[ 

Bug#930451: fabric: please consider uploading the latest version

[Luca Boccassi]

Control: blocks 930451 by 935108

On Mon, 19 Aug 2019 16:47:39 +0100 Luca Boccassi <
bl...@debian.org
> wrote:
> On Wed, 12 Jun 2019 22:44:28 +0100 Luca Boccassi <
> 
bl...@debian.org

> > wrote:
> > Source: fabric
> > Version: 1.14.0-1
> > Severity: wishlist
> > Blocks: 930413
> > 
> > Dear Maintainer,
> > 
> > Please consider uploading the latest version of fabric, 2.4.0:
> > 
> > 
> 
https://github.com/fabric/fabric/releases/tag/2.4.0

> 
> > 
> > Among other things, it's a requirement for azure-cli which I'd like
> to
> > upload in the next few weeks.
> > 
> > I'd be happy to help and do the work myself if you are short on
time.
> > 
> > Thank you for your work on this package!
> 
> Dear Maintainer,
> 
> Since I am currently blocked by this, unless there are objections
I'll
> start working on an NMU shortly. I'll post the debdiff here before
any
> upload, and use a long DELAYED queue if the nmu is to go ahead.
> 
> Thank you!

The new version of fabric requires a new version of python3-invoke.

-- 
Kind regards,
Luca Boccassi


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

Bug#939985: Correction

[Lucas Ferrari de Oliveira]

I wrote DID work, but the correct is DIDN'T WORK.

Lucas Ferrari de Oliveira

Bug#939985: Gimp: crashes when I try open or create an image

[Lucas Ferrari de Oliveira]

Package: gimp
Version: 2.10.8-2+b1
Severity: important

Dear Maintainer,

  The Gimp crashed when I try open or create an image.
  I try reinstall and did work.


GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-
languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-
gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-
libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror --with-
arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-
driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-
gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6)

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Falha de segmentação

Stack trace:
```
/usr/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7f8c68aa8f98]
gimp-2.10(+0xd1590)[0x559704d0b590]
gimp-2.10(+0xd19b8)[0x559704d0b9b8]
gimp-2.10(+0xd2029)[0x559704d0c029]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f8c67fa1730]
gimp-2.10(gimp_gegl_mask_is_empty+0x91)[0x5597050f6411]
gimp-2.10(+0x3b7810)[0x559704ff1810]
gimp-2.10(+0x42ec18)[0x559705068c18]
gimp-2.10(+0x3d5b50)[0x55970500fb50]
gimp-2.10(+0x42f2aa)[0x5597050692aa]
gimp-2.10(gimp_drawable_set_buffer_full+0x1cb)[0x55970500e9bb]
gimp-2.10(gimp_drawable_set_buffer+0x11d)[0x55970500ef9d]
gimp-2.10(gimp_drawable_new+0x106)[0x55970500f296]
gimp-2.10(gimp_layer_new+0x90)[0x55970506c4d0]
gimp-2.10(gimp_image_new_from_template+0x281)[0x55970504b9c1]
gimp-2.10(+0x116cc3)[0x559704d50cc3]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f8c6826ce8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x27555)[0x7f8c68280555]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7f8c682894ae]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f8c68289b6f]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f8c6826ce8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x27555)[0x7f8c68280555]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7f8c682894ae]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f8c68289b6f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8de25)[0x7f8c68c55e25]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f8c6826ce8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x276a4)[0x7f8c682806a4]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd8e)[0x7f8c682894ae]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f8c68289b6f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8cd69)[0x7f8c68c54d69]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x1331eb)[0x7f8c68cfb1eb]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x19d)[0x7f8c6826ce8d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x26dad)[0x7f8c6827fdad]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x47b)[0x7f8c68288b9b]
/usr/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f8c68289b6f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x249cac)[0x7f8c68e11cac]
/usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0(gtk_propagate_event+0xac)[0x7f8c68cf948c]
/usr/lib/x86_64-linux-
gnu/libgtk-x11-2.0.so.0(gtk_main_do_event+0x2eb)[0x7f8c68cf987b]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5bbac)[0x7f8c68b6cbac]
/usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2ae)[0x7f8c681869ee]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ec88)[0x7f8c68186c88]
/usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f8c68186f82]

Bug#939984: metview, FTBFS on 32-bit, narrowing conversions.

[peter green]

Package: metview
Version: 5.6.1-3
Severity: serious

It seems metview has recently started to fail to build on 32-bit,


/<>/atlas/src/tests/mesh/test_halo.cc: In function 'void 
atlas::test::traced_test_105(std::string&, int&, int)':
/<>/atlas/src/tests/mesh/test_halo.cc:142:40: error: narrowing 
conversion of '607990293346953216' from 'long long int' to 'long int' [-Wnarrowing]
   142 |  681187136435794030};
   |^
/<>/atlas/src/tests/mesh/test_halo.cc:157:60: error: narrowing 
conversion of '717939789677242368' from 'long long int' to 'long int' [-Wnarrowing]
   157 |  865001091216722323, 901706783667184769};
   |^
/<>/atlas/src/tests/mesh/test_halo.cc:172:80: error: narrowing 
conversion of '681187136204365458' from 'long long int' to 'long int' [-Wnarrowing]
   172 |  938197934089563136, 938197934125563136, 
938197934161563136};
   |
^
/<>/atlas/src/tests/mesh/test_halo.cc:188:40: error: narrowing 
conversion of '681187136281508315' from 'long long int' to 'long int' [-Wnarrowing]
   188 |  865001091628150894};
   |^
/<>/atlas/src/tests/mesh/test_halo.cc:201:80: error: narrowing 
conversion of '865001091473865179' from 'long long int' to 'long int' [-Wnarrowing]
   201 |  865001091628150894, 901706784087184768, 
938197934341563136};

I first noticed this in raspbian, but it's happening on the Debian reproducible 
builds site for i386 sid and armhf bullseye* too, so I don't think it's 
raspbian specific.

* i386 bullseye has not been tested by reproducible builds, i386 sid is showing 
a successful build on reproducible builds, but that success is older than the 
two failures.

Bug#939983: error: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers'

[Thorsten Glaser]

Package: libvirt-daemon
Version: 5.6.0-2
Severity: serious
Justification: unusable, no working workaround

tglase@tglase:~ $ alias wirrsh
wirrsh='virsh -c qemu:///system'
tglase@tglase:~ $ wirrsh start MirBSD
error: Failed to start domain MirBSD
error: Unable to read from '/sys/fs/cgroup/unified/machine/cgroup.controllers': 
No such file or directory

This might be related to #935734, but the workaround from there, to add…
cgroup_controllers = [ ]
… to /etc/libvirt/qemu.conf, does not work any more.

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

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

Versions of packages libvirt-daemon depends on:
ii  libblkid1   2.34-0.1
ii  libc6   2.28-10
ii  libcap-ng0  0.7.9-2+b1
ii  libdbus-1-3 1.12.16-1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libfuse22.9.9-2
ii  libgcc1 1:9.2.1-7
ii  libgnutls30 3.6.9-4
ii  libnetcf1   1:0.2.8-1+b2
ii  libparted2  3.2-26
ii  libpcap0.8  1.9.0-2
ii  libpciaccess0   0.14-1
ii  libselinux1 2.9-2+b2
ii  libudev1242-7
ii  libvirt05.6.0-2
ii  libxml2 2.9.4+dfsg1-7+b3tarent1

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3tarent1
ii  netcat-openbsd  1.203-2
ii  qemu1:4.1-1+b1

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
ii  libvirt-daemon-system  5.6.0-2
pn  numad  

-- no debconf information

Bug#939982: britney: triggers tests even when all tests are removed; potentially causing autodep8 to be called

[Paul Gevers]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: britney

Hi Eriberto,

Thanks for talking about the issues you have, I could not have guessed.

On 10-09-2019 17:53, Eriberto Mota wrote:
> I was using a test over a DKMS package (lime-forensics). I removed
> all tests[1] because Debian wasn't process it (adding a Neutral tag)
> and to close the bug #935543. Now I have a regression in my
> package[2][3]. However, I no longer maintain a test. I think it is a
> bug in debci. How to proceed to avoid a regression after removing all
> tests?

This is not an issue with debci, as that just runs tests on behalf of
other entities. The culprit here is britney, the migration software of
the release team, hence filing a bug against it. The problem is that the
migration software *seems* (I haven't checked properly yet) to trigger
even in the case that all tests are removed. Because autopkgtest (the
software) is by default configured to try and call autodep8 if no tests
are found, you package was tested with tests from autodep8, while in
your case that is inappropriate as they fail. You have no way of telling
the infrastructure that. As britney considering neutral-to-fail a
regression your package is flagged as such. I see that's nothing you can
solve so I'll ignore the failure.

> [1] 
> https://salsa.debian.org/pkg-security-team/lime-forensics/commit/d7d4c79ae7ea55c5d64cc6103d3745e199056284
> [2] https://ci.debian.net/packages/l/lime-forensics/
> [3]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939893

Paul



signature.asc
Description: OpenPGP digital signature

Bug#935503: gnucash: HBCI/FinTS module not ready for PSD2, will not work after 14 September 2019

[Felix Geyer]

On Fri, 23 Aug 2019 12:08:10 +0200 Matthias Merz  wrote:

Package: gnucash
Version: 1:3.6-1
Severity: important

Dear Maintainer,

German legislation requires some changes to HBCI, rendering the HBCI
interface of gnucash 3.6-1 in Debian mostly useless due to missing
requirements.

As mentioned in #934905, libaqbanking provides support to pass a
registration code starting with versions 5.8.1 (and maybe 5.7.9) -
both not yet in debian.

Also upstream gnucash (git "maint" branch) provides necessary patches
to accomplish this. (see around
https://github.com/Gnucash/gnucash/commit/100ef2a01decda3ed54cf7204ae38bfd8766521d
for details)


Steps to silence the warnings in the HBCI dialog:

- Compile libaqbanking 5.8.1 (using the upstream tarball and the
  contents of libaqbanking_5.7.8-3.debian.tar.xz with small
  modifications to exported symbols), resulting in 5.8.1~matthias1

- build gnucash git maint branch against new libaqbanking-dev_5.8.1 -
  resulting in gnucash 1:3.6-2~matthias1 which is mentioned below.

Yet unknown: whether this allows the "strong authentication"
(two-factor with a TAN) probably required starting Sept. 14.
Legislation allows some exceptions, but still unclear, which German
bank will require which steps.


This bugreport is filed mostly to request - if possible - a solution
for buster, maybe via backports for a to-be-released 3.6.2, maybe via
stable-updates (if possible at all)?


I have already pushed libaqbanking 5.8.2 to unstable.
gnucash 3.7 has been released containing the mentioned commit.
It would be nice to get 3.7 into unstable soon since having the fix available
in testing is a perquisite to fixing it in stable.

Cheers,
Felix

Bug#939427: O: rsnapshot -- local and remote filesystem snapshot utility

[Gabriel F. T. Gomes]

Hi, I would like to adopt it.

Have you had any problems with it that you would like to share with the
future maintainer?


Cheers,
Gabriel

On Wed, 04 Sep 2019 21:29:45 +0200 g...@iroqwa.org wrote:
> Package: wnpp
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I intend to orphan the rsnapshot package.
> 
> The package description is:
>  rsnapshot is an rsync-based filesystem snapshot utility. It can take
>  incremental backups of local and remote filesystems for any number of
>  machines. rsnapshot makes extensive use of hard links, so disk space is
>  only used when absolutely necessary.
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wEKkPHGd1aUBpcm9x
> d2Eub3JnAAoJEJmGUYuaqqCl6FYP/0CfLsmUDBz1VY/DE+YX/zxdUcFyTVl8MKNo
> DpYDrZH6zNeC1CZd5m24AOZgR69/1rwTNth66oZihTrvbao6gYB0ZuCItwnI7oZM
> qQdT/cNi3qJrIgixo4/hmiOtc3Gk7EpQ419uLpS8sD2QZco1P+UXDnQLoF4LTco4
> 2DTCigxw9VxN2mWRvhwcOA4JTjaRJofC5d3Luia5GkvaMmK6llHgsAQrMnK8zS8L
> iXZ9HL93kFSxd+hDUEvyIWlld/JJHm3P7tmYkkDOFGdJrJH0jIYDVnm1kVIgyTt5
> JcCWsMiA9KG0/FeuJcEkpSOnWn8WMe+so6Sdz+yZklywLhaXd+blAYdmdR8q8cEf
> NEwFvrBxKTdmMBMSlGkNdG4emeALUcoIbBt8kDBrRSgSh3pWRWshZNdnwFQtczrb
> yP2x8GOkG8Ew74R7OFTn4frfoD6WFpg+51sukzAhH5okBbu6m0pVGxEMaR+hWIzU
> czQrZpNIfSr1gbB8DxlEOR1+NSEbUA56vYxKN99M0VTzgW/g18hCnL77UsWeMgYy
> LXQ2OBo3GjkJ95m4jl9E6Er5Y2CL/QmDNTkaE/750tZO2psBOzkIwVmWFk0bcH+e
> T3T/uygsE0BphhUeurTPO6NQWJzmsQqh4uypTRmPKMv6VSAt4jvD7zKxPWYvHmq2
> q8ZZjyqU
> =5PpI
> -END PGP SIGNATURE-
> 
> 

Bug#939970: lightdm: Restart, Suspend, Hibernate, Shut Down all greyed out with elogind

[Mark Hindley]

On Tue, Sep 10, 2019 at 05:03:37PM +0200, Vincent Lefevre wrote:
> Package: lightdm
> Version: 1.26.0-5
> Severity: important
> 
> I have a machine still using sysvinit, and systemd-shim has been
> replaced by elogind for such machines. The dependencies have been
> updated in lightdm 1.26.0-4. But after the upgrade (which did not
> output any warning about a regression), Restart, Suspend, Hibernate,
> Shut Down are now all greyed out.

Vincent,

I believe this is the same as the bug I submitted #932047.

You might like to try the pam configuration fix I have there?

Thanks

Mark

Bug#848134: xfce4-terminal: Weird buffering problem

[Egmont Koblinger]

A very similar (perhaps the same, perhaps not) problem has been
reported at https://unix.stackexchange.com/q/509773 .

As per the answer given there, it might be a video card driver problem
recently fixed at https://bugs.freedesktop.org/show_bug.cgi?id=110214
.

Bug#939980: RM: libccss -- ROM; dead upstream

[Ying-Chun Liu (PaulLiu)]

Package: ftp.debian.org
Severity: wishlist


This package was part of Moblin project.

And Moblin becomes MeeGo. And then MeeGo becomes Tizen.

This package seems to not be used anymore in Tizen. And I see no reason
to revive Moblin.


Recently, this package fails to build against latest gtk-doc. (#939954)

Yeah it is a doc error and easy to be fixed. But I just don't see a
reason to keep this library anymore.


This library is a css parser. I think libhtmlcxx-dev might be a
replacement. I know libccss is better integrated with gtk2 or cairo. But
it is just dead upstream and seems no future to me.


So this library was used for the CSS engine for GTK2. In my opinion, if
people really want to use CSS engine, they can try to move to GTK3.
Sorry this is a bad statement but just like python2 we've already got
rid of that in Bullseye. And there will be some end of life for GTK2
someday. When things move on we have to just say goodbye to these old,
outdated libraries. Adrian already suggests us to remove this library in
Jessie (#728890). But we still tries to keep this library in good shape,
in Stretch, in Buster. Just because it still works good, works as its
purpose and might have some out-of-Debian apps depends on this. But not
anymore even it just needs a very easy fix.


So let's remove this library and move on. And anyone who wants to bring
this library back just bring it back.

Or you can reply to this e-mail to say that you are still using this
then I'm willing to continue maintain it and fix it and take back the RM
before ftp-master really removes this package.


Yours,
Paul




signature.asc
Description: OpenPGP digital signature

Bug#918905: logrotate fails to start becauset OVS is not started yet

[Christian Göttsche]

> Control: reassign -1 openvswitch-switch
> Control: notfound -1 3.14.0-4
> Control: affects -1 logrotate
>
> logrotate failed cause the openvswitch postrotate invocation failed.
> The definition is in /etc/logrotate.d/openvswitch-switch, which is
> part of the package openvswitch-switch.
>
> Please share the content of your /etc/logrotate.d/openvswitch-switch.

Also sending to submitter...

Bug#936551: Please port to Python3 (#569)

[Erik Garrison]

Hi Andreas,

Thanks for you work on supporting freebayes in Debian. I thought that we
have a patch in that does port freebayes (it's supporting scripts at least)
to python3. I should check that this is completed. It should be easy enough
to use 2to3 if there is anything left to clean up. I can tag a new release
then.

On Tue, Sep 10, 2019, 09:34 Andreas Tille  wrote:

> Hello,
> the Debian Med team is maintaining freebayes for official Debian. The
> recently released Debian 10 was the last Debian release featuring Python2
> since this programming language is EOL. If you are interested that we
> continue to maintain freebayes in official Debian (and that users of other
> modern distributions will have no problems to install freebayes on their
> systems) I'd recommend you port your code to Python3. The 2to3 tool might
> be of great help here. I have seen some commits about Python3
> compatibility. It would be great if you could tag a new release if the
> conversion might be finished.
> Kind regards, Andreas.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 
> .
>


-- 
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/ekg/freebayes/issues/569#issuecomment-529868736

Bug#912585: logrotate: Logrotate seems to disable ufw Firewall

[Christian Göttsche]

> Control: tags -1 moreinfo
>
> Can you please explain more clearly what happened and what you expected.
> Also logrotate does not ship the rotation config file
> /etc/logrotate.d/ufw, ufw does.
> I do not see how logrotate would disable ufw.

Also sending to submitter...

Bug#934132: Unblock elogind 241.3-1+debian1 migration to bullseye

[Mark Hindley]

On Thu, Sep 05, 2019 at 06:44:26PM +0100, Mark Hindley wrote:
> Julien,
> 
> On Tue, Sep 03, 2019 at 09:03:42PM +0100, Mark Hindley wrote:
> > Control: severity 934491 serious
> > 
> > On Tue, Sep 03, 2019 at 09:34:51PM +0200, Julien Cristau wrote:
> > > Anyway, I guess if #934491 is upgraded to RC then I can drop the block
> > > hint.
> 
> #934491 is now RC, would you please remove your block hint for elogind.

Julien,

I am sorry to just keep asking, however in the absence of any action or response
from you, I am unsure what else I can do.

In accordance with your offer of a week ago, and in the light of #934491 now
being RC, would you please remove your block hint for elogind.

Thank you.

Mark

Bug#924716: cron: SE Linux support uses obsolete API and gets wrong results

[Laurent Bigonville]

On Sat, 16 Mar 2019 20:59:21 +1100 Russell Coker  
wrote:


Hello,

>
> Mar 16 20:36:39 xev cron[14032]: (rjc) ENTRYPOINT FAILED (crontabs/rjc)
> Mar 16 20:36:39 xev cron[14032]: (torrent) ENTRYPOINT FAILED 
(crontabs/torrent)

> Mar 16 20:36:39 xev cron[14032]: (test) ENTRYPOINT FAILED (crontabs/test)
>
> When I restart crond (or run crontab for a user) on a system with the 
"strict"
> configuration of SE Linux policy (user roles other than unconfined_r) 
I see

> the above in the cron log.
>
> In file included from user.c:34:
> /usr/include/selinux/flask.h:5:2: warning: #warning "Please remove 
any #include's of this header in your source code." [-Wcpp]
> #warning "Please remove any #include's of this header in your source 
code."

> ^~~
> /usr/include/selinux/flask.h:6:2: warning: #warning "Instead, use 
string_to_security_class() to map the class name to a value." [-Wcpp]
> #warning "Instead, use string_to_security_class() to map the class 
name to a value."

> ^~~
> In file included from user.c:35:
> /usr/include/selinux/av_permissions.h:1:2: warning: #warning "Please 
remove any #include of this header in your source code." [-Wcpp]

> #warning "Please remove any #include of this header in your source code."
> ^~~
> /usr/include/selinux/av_permissions.h:2:2: warning: #warning 
"Instead, use string_to_av_perm() to map the permission name to a 
value." [-Wcpp]
> #warning "Instead, use string_to_av_perm() to map the permission name 
to a value."

> ^~~
>
> When I compile the cron package I see the above. The above is the 
cause of

> the incorrect processing of entry points.
>
> The following patch fixes these problems.
>
> Please note that the bug means that when the cron package that is 
currently in

> testing is run with the SE Linux libraries in testing it checks for
> execute_no_trans permission not entrypoint. It is unlikely that a hostile
> party could create a crontab file with a context for which 
execute_no_trans is
> allowed without having the ability to get elevated privileges in 
other ways,

> but it can't be theoretically impossible.
>
> I can't be certain that there are no security implications of the bug 
so I


> think that getting this fix into Buster is important.

Please find here an other patch based on Russell's one.

The changes compared to the original patch are the fact that I'm 
cleaning context_list in case of error and I'm also using 
security_deny_unknown() to check whether we should allow the access in 
case the class or the permission is not defined.


Russel do you think you could check if this is still OK?

Are there any other comment?

Kind regards,

Laurent Bigonville

diff -u cron-3.0pl1/user.c cron-3.0pl1/user.c
--- cron-3.0pl1/user.c
+++ cron-3.0pl1/user.c
@@ -31,8 +31,6 @@
 #ifdef WITH_SELINUX
 #include 
 #include 
-#include 
-#include 
 #include 
 
 static int get_security_context(char *name, int crontab_fd, security_context_t
@@ -108,13 +106,35 @@
 	* permission check for this purpose.
 	*/
 
+	security_class_t tclass = string_to_security_class("file");
+	if (!tclass) {
+		log_it(name, getpid(), "Failed to translate security class file", tabname);
+		freeconary(context_list);
+		if (security_deny_unknown() == 0) {
+			return 0;
+		} else {
+			return -1;
+		}
+	}
+
+	access_vector_t bit = string_to_av_perm(tclass, "entrypoint");
+	if (!bit) {
+		log_it(name, getpid(), "Failed to translate av perm entrypoint", tabname);
+		freeconary(context_list);
+		if (security_deny_unknown() == 0) {
+			return 0;
+		} else {
+			return -1;
+		}
+	}
+
 	for (i = 0; i < list_count; i++) {
 		retval = security_compute_av(context_list[i],
 		 file_context,
-		 SECCLASS_FILE,
-		 FILE__ENTRYPOINT,
+		 tclass,
+		 bit,
 		 );
-		if (!retval && ((FILE__ENTRYPOINT & avd.allowed) == FILE__ENTRYPOINT)) {
+		if(!retval && ((bit & avd.allowed) == bit)) {
 			*rcontext = strdup(context_list[i]);
 			freecon(file_context);
 			freeconary(context_list);

Bug#939824: add meta package

[Sebastian Andrzej Siewior]

On September 9, 2019 10:03:13 AM UTC, Matus UHLAR - fantomas 
 wrote:
>Please, add meta package pointing to current libclamunrar.

Do you have an example how that should look like? I can't add package to main 
which has a recommends or depends on a package in contrib or non-free, see:
  
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_is_100_free_software


-- 
Sebastian

Bug#504333: logrotate ignores files with date 1904-1-1 in /var/lib/logrotate/status

[Christian Göttsche]

Control: tags -1 - fixed-upstream

> Control: tags -1 moreinfo unreproducible
>
> The timestamp in the state file stands for the last attempt to rotate
> the file (see https://github.com/logrotate/logrotate/issues/223), so
> an update of it is fine.
>
> In message #27 logrotate probably did not show any error cause the
> option 'daily' was used; when forcing a rotation (--force) an error
> message is also shown in subsequently runs.

This time also sending to the submitter...

Bug#939979: wget manual lists --bind-dns-address but the option appears to no longer exist

[Simon Waters]

Package: wget
Version: 1.20.1-1.1
Severity: minor

Dear Maintainer,

man wget lists --bind-dns-address
But when I try to use it
wget: unrecognized option '--bind-dns-address=127.0.0.1'

Both the DNS server options are missing by the looks of it, build flag?
 --bind-dns-address and --dns-servers

After careful reading it doesn't do what I wanted anyway, but I flagged
it as a bug.


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

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

Versions of packages wget depends on:
ii  libc6 2.28-10
ii  libgnutls30   3.6.7-4
ii  libidn2-0 2.0.5-1
ii  libnettle63.4.1-1
ii  libpcre2-8-0  10.32-5
ii  libpsl5   0.20.2-2
ii  libuuid1  2.33.1-0.1
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages wget recommends:
ii  ca-certificates  20190110

wget suggests no packages.

-- no debconf information

Bug#939978: buster-pu: package flightcrew/0.7.2+dfsg-13+deb10u1

[François Mazen]

Subject: buster-pu: package flightcrew/0.7.2+dfsg-13+deb10u1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: normal

Hello,

I would like to update the flightcrew package in Buster release.

The goal is to fix the CVE-2019-13241.

Please find attached the debdiff.

Best Regards,
François


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/16 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
From 1ee41f78678f520402823b1524e02cba5c5d0d88 Mon Sep 17 00:00:00 2001
From: Francois Mazen 
Date: Tue, 10 Sep 2019 09:27:47 +0200
Subject: [PATCH] Fix CVE-2019-13241

---
 debian/changelog |  6 ++
 debian/patches/fix-CVE-2019-13241.diff   | 58 ++
 debian/patches/series|  1 +
 debian/source/include-binaries   |  1 +
 debian/tests/CVE-2019-13241  | 28 
 debian/tests/CVE-2019-13241_zip-slip.zip | Bin 0 -> 545 bytes
 debian/tests/control |  2 ++
 7 files changed, 96 insertions(+)
 create mode 100644 debian/patches/fix-CVE-2019-13241.diff
 create mode 100644 debian/source/include-binaries
 create mode 100644 debian/tests/CVE-2019-13241
 create mode 100644 debian/tests/CVE-2019-13241_zip-slip.zip
 create mode 100644 debian/tests/control

diff --git a/debian/changelog b/debian/changelog
index b6a222f..dd9a681 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+flightcrew (0.7.2+dfsg-13+deb10u1) buster; urgency=high
+
+  * Fix CVE-2019-13241 for buster.
+
+ -- Francois Mazen   Sun, 08 Sep 2019 21:55:23 +0200
+
 flightcrew (0.7.2+dfsg-13) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --git a/debian/patches/fix-CVE-2019-13241.diff b/debian/patches/fix-CVE-2019-13241.diff
new file mode 100644
index 000..5357d6a
--- /dev/null
+++ b/debian/patches/fix-CVE-2019-13241.diff
@@ -0,0 +1,58 @@
+Description: fix CVE-2019-13241
+Author: Francois Mazen 
+
+
+--- a/src/zipios/src/zipextraction.cpp
 b/src/zipios/src/zipextraction.cpp
+@@ -63,6 +63,43 @@
+ fs::create_directory( filepath );
+ }
+ 
++void CheckPathTraversalVulnerability(const fs::path& root_folder,  const fs::path& file_path)
++{
++
++fs::path canonical_path = fs::weakly_canonical(file_path);
++fs::path canonical_root_path = fs::weakly_canonical(root_folder);
++
++fs::path::iterator root_iterator = canonical_root_path.begin();
++fs::path::iterator path_iterator = canonical_path.begin();
++bool isDifferenceFound = false;
++while(!isDifferenceFound &&
++  root_iterator != canonical_root_path.end() &&
++  path_iterator != canonical_path.end())
++{
++if((*root_iterator) != (*path_iterator))
++{
++isDifferenceFound = true;
++}
++else
++{
++++root_iterator;
++++path_iterator;
++}
++}
++
++if(!isDifferenceFound &&
++   root_iterator != canonical_root_path.end() &&
++   path_iterator == canonical_path.end())
++{
++// We reached the end of the path without iterating the whole root.
++isDifferenceFound = true;
++}
++
++if(isDifferenceFound)
++{
++throw InvalidStateException( "Corrupt epub detected with local file path: " + file_path.string()) ;
++}
++}
+ 
+ void ExtractZipToFolder( const fs::path _to_zip, const fs::path _to_folder )
+ {
+@@ -75,6 +112,7 @@
+ 
+ fs::path new_file_path = path_to_folder / (*it)->getName();
+ 
++CheckPathTraversalVulnerability(path_to_folder, new_file_path);
+ CreateFilepath( new_file_path );
+ WriteEntryToFile( *stream, new_file_path );
+ }
diff --git a/debian/patches/series b/debian/patches/series
index dd411b2..f8c0cdb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ disable_filesystem3_overload
 modify_cmake_for_debian
 reproducible-build
 use_random_unique_tmp_path
+fix-CVE-2019-13241.diff
diff --git a/debian/source/include-binaries b/debian/source/include-binaries
new file mode 100644
index 000..5b216eb
--- /dev/null
+++ b/debian/source/include-binaries
@@ -0,0 +1 @@
+debian/tests/CVE-2019-13241_zip-slip.zip
diff --git a/debian/tests/CVE-2019-13241 b/debian/tests/CVE-2019-13241
new file mode 100644
index 000..baac7e0
--- /dev/null
+++ b/debian/tests/CVE-2019-13241
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+# Check the CVE-2019-13241 vulnerability.
+# See https://security-tracker.debian.org/tracker/CVE-2019-13241
+# Author: Francois Mazen 
+
+EVIL_FILE=/tmp/evil.txt
+
+if [ -f "$EVIL_FILE" ]; then
+echo "$EVIL_FILE exists, removing it."
+rm -f $EVIL_FILE
+else 
+echo 

Bug#691407: closed by Christian Göttsche (Re: logrotate(8) does not mention all reasons for ignoring included files)

[Christian Göttsche]

To better document this in the man page, I created
https://github.com/logrotate/logrotate/pull/265

Bug#915301: logrotate.8: Some style and formatting changes in the manual

[Christian Göttsche]

> Control: tags -1 pending
> Control: forwarded -1 https://github.com/logrotate/logrotate/pull/264
>
> Thanks for the patch. I forwarded it to upstream (see
> https://github.com/logrotate/logrotate/pull/264).

Re-sending, this time also to the submitter ...

Could you please take a look at
https://github.com/logrotate/logrotate/pull/264, as I am not an expert
writing man pages.
Thanks.

Bug#939976: After unattended Upgrade of openssh-server from Release 1:7.4p1-10+deb9u6 to 1:7.4p1-10+deb9u7 no more Public Key Auth if 8K key is used

[Jürgen Kuri]

Package: openssh-server
Severity: normal
Tags: stretch


Steps to Reproduce:
1) Have a Debian Stretch amd64 in place

2) Have the packages openssh-* of previous release 1:7.4p1-10+deb9u6 installed:

   apt install openssh-server=1:7.4p1-10+deb9u6 
openssh-sftp-server=1:7.4p1-10+deb9u6 openssh-client=1:7.4p1-10+deb9u6

3) Have an 8k and a 16k ssh-key pair in place and install the public key on the 
test system

4) Login with the 8k private key: ssh -i /home/myhome/.ssh/id_rsa_8k

   Result: login successful with public key authentication

5) Login with the 16k private key: ssh -i /home/myhome/.ssh/id_rsa_16k

   Result: login successful with public key authentication

6) upgrade openssh-* packages to current release 1:7.4p1-10+deb9u7:

   apt install openssh-server=1:7.4p1-10+deb9u7 
openssh-sftp-server=1:7.4p1-10+deb9u7 openssh-client=1:7.4p1-10+deb9u7

7) Login with the 8k private key: ssh -i /home/myhome/.ssh/id_rsa_8k

   Result: login fails: Permission denied (publickey).

8) 5) Login with the 16k private key: ssh -i /home/myhome/.ssh/id_rsa_16k

   Result: login successful with public key authentication


Colleagues of mine use 4k key pairs which works fine with the current openssh-* 
release 1:7.4p1-10+deb9u7


Please have a look.

Thank you,

Jürgen

Bug#939977: gimp: Crashes on Create with segmentation fault

[Jonathan R.]

Package: gimp
Version: 2.10.8-2+b1
Severity: important

Dear Maintainer,


Updated all installed Debian 9 packages. Opened gimp 2.10 and attempted to
create a new blank file or open existing .xcf, causing segmentation fault.

When running from CL, error is

gimp: fatal error: Segmentation fault
26  ../sysdeps/unix/sysv/linux/read.c: No such file or directory.
gimp: Gimp-Core-CRITICAL: gimp_item_get_ID: assertion 'GIMP_IS_ITEM (item)'
failed

(script-fu:2600): LibGimpBase-WARNING **: 11:52:25.445: script-fu:
gimp_wire_read(): error
Segmentation fault

Debug info as follows:

```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-
languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-
gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-
libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror --with-
arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-
driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-
gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6)

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 1262 - Thread 1262 #

[New LWP 1263]
[New LWP 1265]
[New LWP 1266]
[New LWP 1267]
[New LWP 1268]
[New LWP 1269]
[New LWP 1280]
[New LWP 1284]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7ffc5a632350, fd=15) at
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id  Frame
* 1Thread 0x7f141aeefe00 (LWP 1262) "gimp"__libc_read (nbytes=256,
buf=0x7ffc5a632350, fd=15) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7f1419f3b700 (LWP 1263) "gmain"   0x7f141cc4a819 in
__GI___poll (fds=0x561bb8bdb8b0, nfds=2, timeout=1708) at
../sysdeps/unix/sysv/linux/poll.c:29
  3Thread 0x7f141973a700 (LWP 1265) "gdbus"   0x7f141cc4a819 in
__GI___poll (fds=0x561bb8bf2f80, nfds=2, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
  4Thread 0x7f140b387700 (LWP 1266) "async"   syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7f140ab86700 (LWP 1267) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7f140a385700 (LWP 1268) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  7Thread 0x7f1409b84700 (LWP 1269) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7f13feffe700 (LWP 1280) "pool-gimp"   syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7f13fcffa700 (LWP 1284) "swap writer" syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 9 (Thread 0x7f13fcffa700 (LWP 1284)):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
No locals.
#1  0x7f141cf6195f in g_cond_wait () from /usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0
No symbol table info available.
#2  0x7f141d40c0cd in ?? () from /usr/lib/x86_64-linux-gnu/libgegl-0.4.so.0
No symbol table info available.
#3  0x7f141cf3f89d in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#4  0x7f141cd26fa3 in start_thread (arg=) at
pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139723825719040,
-8952938668077518606, 140721824931646, 140721824931647, 139723825719040, 0,
9072286255938629874, 9072778610287538418}, mask_was_saved = 0}}, priv = {pad =
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, 

Bug#939975: rauc: Testsuite makes rauc FTBFS on all archs

[Uwe Kleine-König]

Package: rauc
Version: 1.1-1
Severity: serious
Tags: fixed-upstream patch
Justification: FTBFS on all archs

Hello,

rauc 1.1-1 failed on all arches that don't cheat by not using nocheck:

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

I talked to upstream and four commits are needed. Some are already in
upstream's master, two are still waiting in a pull request on github[1].

I prepared an MR on salsa which adds all necessary commits on top of
1.1-1:

https://salsa.debian.org/debian/rauc/merge_requests/6

If time to work on this is a problem for you I can prepare and upload an
NMU with these changes. Just tell me ...

Best regards
Uwe

[1] https://github.com/rauc/rauc/pull/476

Bug#939974: osmo-trx FTBFS: undefined reference to symbol '_ZN5boost6system16generic_categoryEv'

[Helmut Grohne]

Source: osmo-trx
Version: 0.4.0-1
Severity: serious
Tags: ftbfs

osmo-trx fails to build from source in unstable and bullseye:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/osmo-trx.html
| /bin/bash ../libtool  --tag=CXX   --mode=link g++ -lpthread -I/usr/include/ 
-I/usr/include/ -I/usr/include/ -g -O2 
-ffile-prefix-map=/build/1st/osmo-trx-0.4.0=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o 
osmo-trx-uhd osmo_trx_uhd-osmo-trx.o ./device/uhd/libdevice.la 
libtransceiver_common.la ../Transceiver52M/arch/x86/libarch.la ../GSM/libGSM.la 
../CommonLibs/libcommon.la -lfftw3f -ltalloc -losmocore -ltalloc -losmoctrl 
-losmogsm -losmocore -ltalloc -losmovty -losmocore -luhd 
| libtool: link: g++ -I/usr/include/ -I/usr/include/ -I/usr/include/ -g -O2 
-ffile-prefix-map=/build/1st/osmo-trx-0.4.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -Wl,--as-needed -o 
osmo-trx-uhd osmo_trx_uhd-osmo-trx.o  ./device/uhd/.libs/libdevice.a 
./.libs/libtransceiver_common.a ../Transceiver52M/arch/x86/.libs/libarch.a 
../GSM/.libs/libGSM.a ../CommonLibs/.libs/libcommon.a -lpthread -lfftw3f 
/usr/lib/x86_64-linux-gnu/libosmoctrl.so 
/usr/lib/x86_64-linux-gnu/libosmogsm.so -ltalloc 
/usr/lib/x86_64-linux-gnu/libosmovty.so 
/usr/lib/x86_64-linux-gnu/libosmocore.so -luhd
| /usr/bin/ld: ./device/uhd/.libs/libdevice.a(UHDDevice.o): undefined reference 
to symbol '_ZN5boost6system16generic_categoryEv'
| /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0: error 
adding symbols: DSO missing from command line
| collect2: error: ld returned 1 exit status
| make[4]: *** [Makefile:641: osmo-trx-uhd] Error 1
| make[4]: Leaving directory '/build/1st/osmo-trx-0.4.0/Transceiver52M'
| make[3]: *** [Makefile:740: all-recursive] Error 1
| make[3]: Leaving directory '/build/1st/osmo-trx-0.4.0/Transceiver52M'
| make[2]: *** [Makefile:507: all-recursive] Error 1
| make[2]: Leaving directory '/build/1st/osmo-trx-0.4.0'
| make[1]: *** [Makefile:438: all] Error 2
| make[1]: Leaving directory '/build/1st/osmo-trx-0.4.0'
| dh_auto_build: make -j15 returned exit code 2
| make: *** [debian/rules:12: build] Error 255
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

While reproducible uses pbuilder, I also see the issue locally in
sbuild.

Helmut

Bug#939973: tiger: lin001w does not recognize usrmerge

[Benoit Friry]

Package: tiger
Version: 1:3.2.4~rc1-2
Severity: normal

Dear Maintainer,

I did migrate "all in /usr" with usrmerge package.
After the migration, all my files are in /usr, and there are links from
/lib to /usr/lib, /bin to /usr/bin and /sbin to /usr/sbin.

lin001w reports files found through links in root as files that do not
belong to any packages.

Best regards,
Benoit

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

Kernel: Linux 5.2.0-2-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)

Versions of packages tiger depends on:
ii  binutils   2.32.51.20190821-2
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.28-10
ii  net-tools  1.60+git20180626.aebd88e-1
ii  ucf3.0038+nmu1

Bug#939972: ITP: r-other-wgcna -- Weighted Correlation Network Analysis

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-other-wgcna -- Weighted Correlation Network Analysis
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-other-wgcna
  Version : 1.67
  Upstream Author : Peter Langfelder 
* URL : https://cran.r-project.org/package=WGCNA
* License : GPL-2+
  Programming Lang: GNU R
  Description : Weighted Correlation Network Analysis
 Functions necessary to perform Weighted Correlation Network Analysis
 on high-dimensional data as originally described in Horvath and Zhang
 (2005)  and Langfelder and Horvath (2008)
 . Includes functions for rudimentary data
 cleaning, construction of correlation networks, module identification,
 summarization, and relating of variables and modules to sample
 traits. Also includes a number of utility functions for data manipulation
 and visualization.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-wgcna

Bug#939076: (no subject)

[Piotr Jurkiewicz]

The bug also affects me. Results in no network access after boot.

Sep 10 12:46:52 sonata systemd[1]: Reached target Network.
Sep 10 12:46:52 sonata systemd[1]: Reached target Network is Online.
Sep 10 12:46:52 sonata kernel: bnx2x :01:00.2: firmware: failed to 
load bnx2x/bnx2x-e2-7.13.11.0.fw (-2)
Sep 10 12:46:52 sonata kernel: firmware_class: See 
https://wiki.debian.org/Firmware for information about missing firmware
Sep 10 12:46:52 sonata kernel: bnx2x :01:00.2: Direct firmware load 
for bnx2x/bnx2x-e2-7.13.11.0.fw failed with error -2
Sep 10 12:46:52 sonata kernel: bnx2x: 
[bnx2x_func_hw_init:6002(eno3)]Error loading firmware
Sep 10 12:46:52 sonata kernel: bnx2x: [bnx2x_nic_load:2730(eno3)]HW init 
failed, aborting

Bug#939971: runit: Export NAME and add a VERBOSE option to invoke-run

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-34
Severity: normal
Tags: patch

Hi,
as discussed in #935958 it's inconvenient to print messages like
'starting foo' or 'stopping foo' by default, as they are written to
the service log. 

The attached patch does the following:
* add support for a VERBOSE option to invoke run: the 
  value is sourced from /etc/default/runit file 
  (off by default) and can be overridden for each service 
  placing a file in /etc/sv//conf/

* export the NAME variable in invoke-run

* add a system-wide file to be sourced for runit services

the verbose option should be tested in runscripts like

if [ "$VERBOSE" = 1 ]; then
echo "runsv: starting $NAME..."
fi

I'm not sure using /etc/default path (rather than /etc/runit) is
appropriate; file there are usually meant for daemons but there are
exceptions (I have a Grub directory there).

Lorenzo 


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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.28-10
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-34

runit suggests no packages.

-- Configuration Files:
/etc/runit/3 changed [not included]

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/runit/invoke-run (from runit package)
>From 354706b5eac44d35814eb584c1b0272995f441ff Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Tue, 10 Sep 2019 16:31:53 +0200
Subject: [PATCH] invoke-run: add verbose option and export NAME

Export `NAME` variable and add a `VERBOSE` option into
invoke-run interpreter.
Also add a runit default file for system wide setting about
runit services.
---
 debian/contrib/lib/invoke-run | 8 
 debian/runit.default  | 4 
 2 files changed, 12 insertions(+)
 create mode 100644 debian/runit.default

diff --git a/debian/contrib/lib/invoke-run b/debian/contrib/lib/invoke-run
index b3b0c55..b0f6ef6 100755
--- a/debian/contrib/lib/invoke-run
+++ b/debian/contrib/lib/invoke-run
@@ -31,6 +31,8 @@ case "${runscript}" in
 esac
 readonly runscript service
 
+export NAME=$service
+
 if [ -f "/etc/sv/${service}/.meta/installed" ] ; then
readonly installed="/usr/share/runit/meta/${service}/installed"
# uninstalled, but not purged. See #929693 and commit [4c485b]
@@ -49,6 +51,12 @@ if [ -r "/etc/default/${service}" ] ; then
set +a -u
 fi
 
+if [ -r /etc/default/runit ]; then
+set -a
+. /etc/default/runit
+set +a
+fi
+
 readonly initscript="/etc/init.d/${service}"
 readonly noreplace="/usr/share/runit/meta/${service}/noreplace"
 
diff --git a/debian/runit.default b/debian/runit.default
new file mode 100644
index 000..26d057e
--- /dev/null
+++ b/debian/runit.default
@@ -0,0 +1,4 @@
+# system wide setting for runit services
+
+# print runsv messages about starting and stopping the service
+VERBOSE=0
-- 
2.23.0

Bug#939863: [debian-mysql] Bug#939863: mariadb-server-10.3: won't start without libjemalloc1 from jessie

[Cory Petkovsek]

Mystery solved. I had upgraded two different servers from debian mysql
5.6 and oracle mysql 5.7 to mariadb-10.3. The packages were drop in
replacements, but when I removed libjemalloc1, mariadb wouldn't start
because my former DBA had put this in my.cnf:

[mysqld_safe]
socket  = /var/run/mysqld/mysqld.sock
nice= 0
malloc-lib = /usr/lib/x86_64-linux-gnu/libjemalloc.so.1

Commenting that line out, or putting in libjemalloc2 and changing it
to .so.2 both work fine.

Thanks for looking at it and sorry for the trouble. This can be closed.

Bug#939970: lightdm: Restart, Suspend, Hibernate, Shut Down all greyed out with elogind

[Vincent Lefevre]

Package: lightdm
Version: 1.26.0-5
Severity: important

I have a machine still using sysvinit, and systemd-shim has been
replaced by elogind for such machines. The dependencies have been
updated in lightdm 1.26.0-4. But after the upgrade (which did not
output any warning about a regression), Restart, Suspend, Hibernate,
Shut Down are now all greyed out.

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.16-1
ii  debconf [debconf-2.0]  1.5.73
ii  libaudit1  1:2.8.5-2
ii  libc6  2.29-1
ii  libgcrypt201.8.5-2
ii  libglib2.0-0   2.60.6-2
ii  libpam-elogind [logind]241.3-1+debian1
ii  libpam0g   1.3.1-5
ii  libxcb11.13.1-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.6-1
ii  lsb-base   11.1.0

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+19

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.11-1
ii  xserver-xephyr   2:1.20.4-1

-- Configuration Files:
/etc/lightdm/lightdm.conf changed:
[LightDM]
[Seat:*]
greeter-hide-users=false
[XDMCPServer]
[VNCServer]


-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm

Bug#939969: dpkg-buildflags sets C++ incompatible warning implicit-function-declaration if qa=+all is used

[Paul Dreik]

Package: dpkg
Version: 1.19.7
Severity: normal

Dear Maintainer,

I use dpkg-buildflags in my continuous integration script, to make
sure my software (rdfind, available in debian) will build ok when the official
rdfind package is built. I count the warnings during build, and error out if
it is nonzero. This works fine in buster.

This will however fail with g++-9, which warns when using 
-Werror=implicit-function-declaration
on C++ programs.

To reproduce:
export DEB_BUILD_MAINT_OPTIONS="qa=+all"
touch empty.cpp
g++-9 $(dpkg-buildflags --get CXXFLAGS) -c empty.cpp
# outputs a warning from g++

Reading the manpage for dpkg-buildflags, it says CXXFLAGS is the same as 
CFLAGS. I think
that is unfortunate. I would expect CXXFLAGS to be C++ specific.

Thanks,
Paul

-- Package-specific info:
System tainted due to merged-usr-via-symlinks.

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8), 
LANGUAGE=sv_SE.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 dpkg depends on:
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  2.9-2+b2
ii  tar  1.30+dfsg-6+b1
ii  zlib1g   1:1.2.11.dfsg-1+b1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.3
pn  debsig-verify  

-- no debconf information

Bug#939927: [debian-mysql] Bug#939927: mariadb-server-10.1 Cannot complete the upgrade package

[Александр Воробьев]

Previous upgrade (successfull) was mariadb 10.1.38  (16.05.2019)

I have now upgraded Debian from Stretch to Buster (and MariaDB-server 10.3). It 
solved my problem

-- 
С уважением,
Воробьев Александр
Создание и поддержка сайтов https://va-soft.ru/



10.09.2019, 16:31, "Otto Kekäläinen" :
> Control: tags -1 moreinfo
>
> Hello!
>
> What version were you upgrading from?
>
> Our testing pipeline includes upgrade testing and such an error is not
> visible in our tests
> (https://salsa.debian.org/mariadb-team/mariadb-10.1/pipelines/67361).
>
> Please describe what your system looks like or if you can give us
> steps on how to reproduce this it would be even better.

Bug#939967: stretch-pu: package flightcrew/0.7.2+dfsg-9+deb9u1

[François Mazen]

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

Hello,

I would like to update the flightcrew package in Stretch release.

The goal is to fix the CVE-2019-13241.

Please find attached the debdiff.

Best Regards,
François

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/16 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
From 24d531e5efce69f77b85d8c16aef2a099e9f143c Mon Sep 17 00:00:00 2001
From: Francois Mazen 
Date: Tue, 10 Sep 2019 16:28:31 +0200
Subject: [PATCH] Fix CVE-2019-13241.

---
 debian/changelog |  6 ++
 debian/patches/fix-CVE-2019-13241.diff   | 59 +++
 debian/patches/series|  1 +
 debian/source/include-binaries   |  1 +
 debian/tests/CVE-2019-13241  | 28 
 debian/tests/CVE-2019-13241_zip-slip.zip | Bin 0 -> 545 bytes
 debian/tests/control |  2 ++
 7 files changed, 97 insertions(+)
 create mode 100644 debian/patches/fix-CVE-2019-13241.diff
 create mode 100644 debian/source/include-binaries
 create mode 100644 debian/tests/CVE-2019-13241
 create mode 100644 debian/tests/CVE-2019-13241_zip-slip.zip
 create mode 100644 debian/tests/control

diff --git a/debian/changelog b/debian/changelog
index f602446..511639c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+flightcrew (0.7.2+dfsg-9+deb9u1) stretch; urgency=medium
+
+  * Fix CVE-2019-13241 for stretch release.
+
+ -- Francois Mazen   Tue, 10 Sep 2019 15:34:26 +0200
+
 flightcrew (0.7.2+dfsg-9) unstable; urgency=medium
 
   * d/copyright: claim copyright for the 2017.
diff --git a/debian/patches/fix-CVE-2019-13241.diff b/debian/patches/fix-CVE-2019-13241.diff
new file mode 100644
index 000..98019d0
--- /dev/null
+++ b/debian/patches/fix-CVE-2019-13241.diff
@@ -0,0 +1,59 @@
+Description: fix CVE-2019-13241
+Author: Francois Mazen 
+
+
+--- a/src/zipios/src/zipextraction.cpp
 b/src/zipios/src/zipextraction.cpp
+@@ -63,6 +63,44 @@
+ fs::create_directory( filepath );
+ }
+ 
++void CheckPathTraversalVulnerability(const fs::path& root_folder,  const fs::path& file_path)
++{
++
++fs::path canonical_path = fs::weakly_canonical(file_path);
++fs::path canonical_root_path = fs::weakly_canonical(root_folder);
++
++fs::path::iterator root_iterator = canonical_root_path.begin();
++fs::path::iterator path_iterator = canonical_path.begin();
++bool isDifferenceFound = false;
++while(!isDifferenceFound &&
++  root_iterator != canonical_root_path.end() &&
++  path_iterator != canonical_path.end())
++{
++if((*root_iterator) != (*path_iterator))
++{
++isDifferenceFound = true;
++}
++else
++{
++++root_iterator;
++++path_iterator;
++}
++}
++
++if(!isDifferenceFound &&
++   root_iterator != canonical_root_path.end() &&
++   path_iterator == canonical_path.end())
++{
++// We reached the end of the path without iterating the whole root.
++isDifferenceFound = true;
++}
++
++if(isDifferenceFound)
++{
++throw InvalidStateException( "Corrupt epub detected with local file path: " + file_path.string()) ;
++}
++}
++
+ 
+ void ExtractZipToFolder( const fs::path _to_zip, const fs::path _to_folder )
+ {
+@@ -75,6 +113,7 @@
+ 
+ fs::path new_file_path = path_to_folder / (*it)->getName();
+ 
++CheckPathTraversalVulnerability(path_to_folder, new_file_path);
+ CreateFilepath( new_file_path );
+ WriteEntryToFile( *stream, new_file_path );
+ }
diff --git a/debian/patches/series b/debian/patches/series
index dd411b2..f8c0cdb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ disable_filesystem3_overload
 modify_cmake_for_debian
 reproducible-build
 use_random_unique_tmp_path
+fix-CVE-2019-13241.diff
diff --git a/debian/source/include-binaries b/debian/source/include-binaries
new file mode 100644
index 000..5b216eb
--- /dev/null
+++ b/debian/source/include-binaries
@@ -0,0 +1 @@
+debian/tests/CVE-2019-13241_zip-slip.zip
diff --git a/debian/tests/CVE-2019-13241 b/debian/tests/CVE-2019-13241
new file mode 100644
index 000..baac7e0
--- /dev/null
+++ b/debian/tests/CVE-2019-13241
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+# Check the CVE-2019-13241 vulnerability.
+# See https://security-tracker.debian.org/tracker/CVE-2019-13241
+# Author: Francois Mazen 
+
+EVIL_FILE=/tmp/evil.txt
+
+if [ -f "$EVIL_FILE" ]; then
+echo "$EVIL_FILE exists, removing it."
+rm -f $EVIL_FILE
+else 
+echo "$EVIL_FILE does 

Bug#939968: sagan: Please package upstream release 1.2.1 or newer

[Jonas Smedegaard]

Package: sagan
Version: 1.2.0-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream has released 1.2.1 (and a later 1.2.2 as well) which supports a
JSON source format, interesting for a use case of mine.

Please package 1.2.1 or newer for Debian.

Kind regards, and thanks for maintaining the Debian sagan package,

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl13tWcACgkQLHwxRsGg
ASFM0hAAqQs2J51OFTFrLw+tHP50iGDeSqrFv2kAh+aG8UJA5eVZOw+38YL2OIrt
4WQIQ0QESwcr/x99pqb2GoyAE2m8SSOi3WOGfFPlvpCx8Wtj0gyteAJH2tQw1+v6
NvgeCLYDD74XEpwn9ZmV6TzyumGybYtiMqOsVEb50Gn3xsz/QNTwIUSlg4MhRNVu
tbmtmp5AbrWHzMBBdkqbVHBWEgh4mwKR1MD+ex4Ruqt04jmLLP6dtA1V1Ctco8+R
Kc5wlA2Vg5L4AyZbJuNCrZYzpNtS2WXDHPbfsKoNK4rmK5bFth2/U3BT2/YMnf6r
e4P10asOZXNZ2ZCWL5jGNoDdCtBFSbdhR8/d8KTvBiVvi0mTsseDaB4th3eCDpa5
Z7ufNGoOwnR5F18xIZigdtESliFHAcYugS7HSrFizUY23XY6Es2AjSC2l1CD2IRr
gRmcd/rB6jkfKBchOnrzRiM0s94Shcc9sJ1+jCCtMUMtDsiMWdjPWaUclE1rU70P
di9FBU9jaEL4Dwfcl0xnGo0yBMsVx+B2QaHx0cKtOK//vl+NFpfThlutWKh/jCih
x2gLbJbEB4IOW8fvDALoFrAk+YYDxkjri6wo02IkdPfTAl/17Ad4hURme4MoLZW4
Ubs6Yjk7JMftRgjECdlBUaydZKak+tUdLkfFypQzFS+SeUO36jU=
=2Tvu
-END PGP SIGNATURE-

Bug#939966: sagan: diff for NMU version 1.2.0-1.1

[Jonas Smedegaard]

Package: sagan
Version: 1.2.0-1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for sagan (versioned as 1.2.0-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards,

 - Jonas

diff -Nru sagan-1.2.0/debian/changelog sagan-1.2.0/debian/changelog
--- sagan-1.2.0/debian/changelog2018-07-05 14:52:54.0 +0200
+++ sagan-1.2.0/debian/changelog2019-09-10 16:15:15.0 +0200
@@ -1,3 +1,14 @@
+sagan (1.2.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch cherry-picked upstream
+to remove duplicate rule file in sagan.yaml.
+Closes: Bug#933239.
+  * Fix postinst script redirection to silence stderr as intended.
+Closes: Bug#908241. Thanks to Nicolas Jeannerod and Ralf Treinen.
+
+ -- Jonas Smedegaard   Tue, 10 Sep 2019 16:15:15 +0200
+
 sagan (1.2.0-1) unstable; urgency=medium
 
   * New upstream version 1.2.0
diff -Nru sagan-1.2.0/debian/patches/fix_duplicate_rule_file.patch 
sagan-1.2.0/debian/patches/fix_duplicate_rule_file.patch
--- sagan-1.2.0/debian/patches/fix_duplicate_rule_file.patch1970-01-01 
01:00:00.0 +0100
+++ sagan-1.2.0/debian/patches/fix_duplicate_rule_file.patch2019-09-10 
16:06:44.0 +0200
@@ -0,0 +1,19 @@
+Description: Remove duplicate rule file in sagan.yaml
+Origin: upstream, https://github.com/beave/sagan/commit/52386ed
+Author: Champ Clark III 
+Bug: https://github.com/beave/sagan/issues/118
+Bug-Debian: https://bugs.debian.org/933239
+Forwarded: yes
+Last-Update: 2019-09-10
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/etc/sagan.yaml
 b/etc/sagan.yaml
+@@ -689,7 +689,6 @@
+   - $RULE_PATH/windows-owa.rules
+   - $RULE_PATH/windows.rules
+   - $RULE_PATH/windows-sysmon.rules
+-  - $RULE_PATH/windows-security.rules
+   - $RULE_PATH/wordpress.rules
+   - $RULE_PATH/xinetd.rules
+   - $RULE_PATH/yubikey.rules
diff -Nru sagan-1.2.0/debian/patches/series sagan-1.2.0/debian/patches/series
--- sagan-1.2.0/debian/patches/series   2018-04-29 15:24:28.0 +0200
+++ sagan-1.2.0/debian/patches/series   2019-09-10 15:58:31.0 +0200
@@ -0,0 +1 @@
+fix_duplicate_rule_file.patch
diff -Nru sagan-1.2.0/debian/postinst sagan-1.2.0/debian/postinst
--- sagan-1.2.0/debian/postinst 2018-04-29 15:46:11.0 +0200
+++ sagan-1.2.0/debian/postinst 2019-09-10 16:10:18.0 +0200
@@ -5,7 +5,7 @@
 add_sysuser()
 {
if ! getent passwd sagan >/dev/null; then
-   adduser --system --disabled-login --no-create-home --home 
/nonexistent --ingroup adm sagan 2>&1 > /dev/null
+   adduser --system --disabled-login --no-create-home --home 
/nonexistent --ingroup adm sagan > /dev/null 2>&1
fi
 }
 

Bug#773192: disable DSA key generation by default

[Colin Watson]

On Mon, Dec 15, 2014 at 12:49:40PM +, Safar, Stefan wrote:
>Version: all

The version is relevant - you can't just say "all".  What version did
you encounter this bug in?

>During installation (or maybe the first startup, i’m not sure), the
>openssh-server generates 1024bit DSA keys.

As far as I can tell, no, it doesn't.  In a fresh unstable chroot:

  # apt install openssh-server
  [...]
  Setting up openssh-server (1:8.0p1-6) ...
  
  Creating config file /etc/ssh/sshd_config with new version
  Creating SSH2 RSA key; this may take some time ...
  3072 SHA256:CTOaHgFdYim5rV+9TsQNjcxXnghR4n0R7MQT0VkxClY root@niejwein (RSA)
  Creating SSH2 ECDSA key; this may take some time ...
  256 SHA256:yxBciZ3liGRuAIlZl0r06z0q4PWZJoQNd9/4yMwm/10 root@niejwein (ECDSA)
  Creating SSH2 ED25519 key; this may take some time ...
  256 SHA256:uAi+rvto2sRR7+OIM9tP5RWqVW1/M1elBv0Rchnw4Js root@niejwein (ED25519)
  [...]
  # ls -l /etc/ssh
  total 596
  -rw-r--r-- 1 root root 577325 Aug 28 10:53 moduli
  -rw-r--r-- 1 root root   1565 Aug 28 10:53 ssh_config
  -rw--- 1 root root505 Sep 10 14:59 ssh_host_ecdsa_key
  -rw-r--r-- 1 root root175 Sep 10 14:59 ssh_host_ecdsa_key.pub
  -rw--- 1 root root399 Sep 10 14:59 ssh_host_ed25519_key
  -rw-r--r-- 1 root root 95 Sep 10 14:59 ssh_host_ed25519_key.pub
  -rw--- 1 root root   2602 Sep 10 14:59 ssh_host_rsa_key
  -rw-r--r-- 1 root root567 Sep 10 14:59 ssh_host_rsa_key.pub
  -rw-r--r-- 1 root root   3250 Aug 28 10:53 sshd_config

The packaging will only generate a DSA host key if you have a HostKey
line in /etc/ssh/sshd_config which explicitly requires it; there is no
such line in the default configuration.

>This bug is somehow related to
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481133 , but it’s not a
>duplicate.

However, I think it likely is a duplicate of #823827, which was fixed in
1:7.2p2-6 (before stretch).  This is why it's relevant which version you
encountered this bug in and whether you have any local customisations,
because if it's a more recent version than that then we need to
investigate further.

Regards,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#939863: [debian-mysql] Bug#939863: mariadb-server-10.3: won't start without libjemalloc1 from jessie

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello!

MariaDB 10.3 is built against libjemalloc-dev which points to the
latest libjemalloc version in the distro:
https://salsa.debian.org/mariadb-team/mariadb-10.3/blob/master/debian/control#L19

Official build logs for ams64
(https://buildd.debian.org/status/package.php?p=mariadb-10.3=buster)
shows:
   Setting up libjemalloc2:amd64 (5.1.0-3) ...
   Setting up libjemalloc-dev (5.1.0-3) ...

The core server package however does not end up depending on
libjemalloc directly:
https://packages.debian.org/buster/mariadb-server-core-10.3

I was not able to reproduce the situation you copy-pasted. Please
provide more information, ideally steps on how to reproduce the
situation you have in for example a clean Docker container so that it
is easy to test by developers.

Bug#939866: [debian-mysql] Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41

[Otto Kekäläinen]

The mariadb-10.3 duplicate if this was filed as bug #939819

Bug#939573: Acknowledgement (userv: provide systemd service file)

[Matthew Vernon]

Hi,

If userv is to spawn long-running processes, and it is desired that they
survive the restarting of userv, then we'll also need KillMode set to
process (rather than the default "control-group"), e.g.:

[Unit]
Description=User services (security boundary) daemon
After=syslog.target remote-fs.target

[Service]
Type=forking
ExecStartPre=/bin/sh -c 'test -d /var/run/userv || mkdir -m700
/var/run/userv'
ExecStart=/usr/local/sbin/uservd -daemon
KillMode=process

[Install]
WantedBy=multi-user.target

Regards,

Matthew


-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

Bug#939927: [debian-mysql] Bug#939927: mariadb-server-10.1 Cannot complete the upgrade package

[Otto Kekäläinen]

Control: tags -1 moreinfo

Hello!

What version were you upgrading from?

Our testing pipeline includes upgrade testing and such an error is not
visible in our tests
(https://salsa.debian.org/mariadb-team/mariadb-10.1/pipelines/67361).

Please describe what your system looks like or if you can give us
steps on how to reproduce this it would be even better.

Bug#939965: buster-pu: package flightcrew/0.7.2+dfsg-13+deb10u1

[François Mazen]

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

Hello,

I would like to update the flightcrew package in Buster release.

The goal is to fix the CVE-2019-13241.

Please find attached the debdiff.

Best Regards,
François


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/16 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
From 1ee41f78678f520402823b1524e02cba5c5d0d88 Mon Sep 17 00:00:00 2001
From: Francois Mazen 
Date: Tue, 10 Sep 2019 09:27:47 +0200
Subject: [PATCH] Fix CVE-2019-13241

---
 debian/changelog |  6 ++
 debian/patches/fix-CVE-2019-13241.diff   | 58 ++
 debian/patches/series|  1 +
 debian/source/include-binaries   |  1 +
 debian/tests/CVE-2019-13241  | 28 
 debian/tests/CVE-2019-13241_zip-slip.zip | Bin 0 -> 545 bytes
 debian/tests/control |  2 ++
 7 files changed, 96 insertions(+)
 create mode 100644 debian/patches/fix-CVE-2019-13241.diff
 create mode 100644 debian/source/include-binaries
 create mode 100644 debian/tests/CVE-2019-13241
 create mode 100644 debian/tests/CVE-2019-13241_zip-slip.zip
 create mode 100644 debian/tests/control

diff --git a/debian/changelog b/debian/changelog
index b6a222f..dd9a681 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+flightcrew (0.7.2+dfsg-13+deb10u1) buster; urgency=high
+
+  * Fix CVE-2019-13241 for buster.
+
+ -- Francois Mazen   Sun, 08 Sep 2019 21:55:23 +0200
+
 flightcrew (0.7.2+dfsg-13) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --git a/debian/patches/fix-CVE-2019-13241.diff b/debian/patches/fix-CVE-2019-13241.diff
new file mode 100644
index 000..5357d6a
--- /dev/null
+++ b/debian/patches/fix-CVE-2019-13241.diff
@@ -0,0 +1,58 @@
+Description: fix CVE-2019-13241
+Author: Francois Mazen 
+
+
+--- a/src/zipios/src/zipextraction.cpp
 b/src/zipios/src/zipextraction.cpp
+@@ -63,6 +63,43 @@
+ fs::create_directory( filepath );
+ }
+ 
++void CheckPathTraversalVulnerability(const fs::path& root_folder,  const fs::path& file_path)
++{
++
++fs::path canonical_path = fs::weakly_canonical(file_path);
++fs::path canonical_root_path = fs::weakly_canonical(root_folder);
++
++fs::path::iterator root_iterator = canonical_root_path.begin();
++fs::path::iterator path_iterator = canonical_path.begin();
++bool isDifferenceFound = false;
++while(!isDifferenceFound &&
++  root_iterator != canonical_root_path.end() &&
++  path_iterator != canonical_path.end())
++{
++if((*root_iterator) != (*path_iterator))
++{
++isDifferenceFound = true;
++}
++else
++{
++++root_iterator;
++++path_iterator;
++}
++}
++
++if(!isDifferenceFound &&
++   root_iterator != canonical_root_path.end() &&
++   path_iterator == canonical_path.end())
++{
++// We reached the end of the path without iterating the whole root.
++isDifferenceFound = true;
++}
++
++if(isDifferenceFound)
++{
++throw InvalidStateException( "Corrupt epub detected with local file path: " + file_path.string()) ;
++}
++}
+ 
+ void ExtractZipToFolder( const fs::path _to_zip, const fs::path _to_folder )
+ {
+@@ -75,6 +112,7 @@
+ 
+ fs::path new_file_path = path_to_folder / (*it)->getName();
+ 
++CheckPathTraversalVulnerability(path_to_folder, new_file_path);
+ CreateFilepath( new_file_path );
+ WriteEntryToFile( *stream, new_file_path );
+ }
diff --git a/debian/patches/series b/debian/patches/series
index dd411b2..f8c0cdb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ disable_filesystem3_overload
 modify_cmake_for_debian
 reproducible-build
 use_random_unique_tmp_path
+fix-CVE-2019-13241.diff
diff --git a/debian/source/include-binaries b/debian/source/include-binaries
new file mode 100644
index 000..5b216eb
--- /dev/null
+++ b/debian/source/include-binaries
@@ -0,0 +1 @@
+debian/tests/CVE-2019-13241_zip-slip.zip
diff --git a/debian/tests/CVE-2019-13241 b/debian/tests/CVE-2019-13241
new file mode 100644
index 000..baac7e0
--- /dev/null
+++ b/debian/tests/CVE-2019-13241
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+# Check the CVE-2019-13241 vulnerability.
+# See https://security-tracker.debian.org/tracker/CVE-2019-13241
+# Author: Francois Mazen 
+
+EVIL_FILE=/tmp/evil.txt
+
+if [ -f "$EVIL_FILE" ]; then
+echo "$EVIL_FILE exists, removing it."
+rm -f $EVIL_FILE
+else 
+echo "$EVIL_FILE does not exist"
+fi
+
+echo "Opening the evil 

Bug#939605: [Pkg-javascript-devel] Bug#939605: Support lerna multiple packages

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 10 12:59:33 AM IST, Xavier  wrote:
>Hi,
>
>how can plg-js know which is the main package here ?

May be add 'lerna' to debian and group options in watch to indicate it is 
managed by lerna and like in acorn discussion don't have a main package.

Add debian/nodejs/packages file to list the sub modules we want.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#939964: libdazzle: none

[Andreas Henriksson]

Source: libdazzle
Severity: important
Control: block 939500 by -1

Hello,

The libdazzle package fails to build with the new gtk-doc-tools 1.32 (currently 
in experimental). This is the relevant build log snippet:

ERROR: Error in gtkdoc helper script:

ERROR: ['gtkdoc-mkhtml', 
'--path=/build/libdazzle-3.30.2/doc:/build/libdazzle-3.30.2/obj-x86_64-linux-gnu/doc',
 'libdazzle', '../dazzle-docs.sgml'] failed with status 6
../xml/dzl-shortcuts-shortcut.xml:162: parser error : Entity 'rt' not defined
A single shortcut: ctlaltdeletehttps://gitlab.gnome.org/GNOME/gtk-doc/commit/97541700fe55bf5ba1522773dd242a4598cac187
"... As a notable change we don't output empty tree_index files anymore."

Suggestions on how to fix:
- remove the lines including the non-existant (formerly empty) file
- add additional markup with the  tag to add info that will be 
used when the include is not available.

Regards,
Andreas Henriksson

Bug#939963: FTBFS with OCaml 4.08.0 (num)

[Stéphane Glondu]

Package: src:orpie
Version: 1.5.2-2
Severity: important

Dear Maintainer,

Your package orpie FTBFS with OCaml 4.08.0 because it depends on the
"num" library, which used to be shipped with OCaml 4.05.0, but is now
shipped separately. Full build log:

  https://ocaml.debian.net/transitions/ocaml-4.08.0/pool/orpie.log

Please depend on libnum-ocaml-dev, which is the name of the new
package. Note that libnum-ocaml-dev is also provided by the version of
OCaml currently in unstable (4.05.0), as a compatibility measure.

Note also that there might be other errors with OCaml 4.08.0 (a common
issue is -safe-string being the default). You can check that your
package builds fine with the following repository:

  https://ocaml.debian.net/transitions/ocaml-4.08.0/


Cheers,

-- 
Stéphane


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

Kernel: Linux 5.2.0-2-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

Bug#914336: netperfmeter: bogus debian/tests/control file

[Thomas Dreibholz]

Hi,

Den 22.11.2018 13:15, skrev Paul Gevers:
> Source: netperfmeter
> Version: 1.8.0-1
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: issue
> 
> Dear maintainer,
> 
> Recently you added (or at least you tried to add) an autopkgtest to you
> package. However, the current content of debian/tests/control is bogus.
> 
> Please read the spec [1] and adapt the control file or drop the file if
> you didn't intent to add a test.

The problem is solved in the latest upstream version 1.8.5. I created an
updated package on the mentors server:
https://mentors.debian.net/package/netperfmeter . It requires a Debian
sponsor to upload it.

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#939923: mono ftbfs in unstable (still calling python)

[Joseph Shields]

Y’know, I _did_ test this, but I suspect the 2-year-old builder tarball may 
have had some legacy stuff in it… like Python 2.

> On Sep 10, 2019, at 3:57 AM, Matthias Klose  wrote:
> 
> Package: src:mono
> Version: 5.18.0.240+dfsg-4
> Severity: serious
> Tags: sid bullseye
> 
> https://buildd.debian.org/status/package.php?p=mono
> 
> Making all in mini
> make[2]: Entering directory '/<>/mono/mini'
> echo "#define FULL_VERSION \"Debian $(dpkg-parsechangelog 
> -l../../debian/changelog | grep ^Vers | cut -d\  -f2)\"" > version.h
> python ./genmdesc.py TARGET_ARM64 . cpu-arm64.h arm64_cpu_desc ./cpu-arm64.md
> /bin/bash: python: command not found
> make[2]: *** [Makefile:2964: cpu-arm64.h] Error 127
> make[2]: *** Waiting for unfinished jobs
> 

Bug#939962: FTBFS with OCaml 4.08.0 (safe strings)

[Stéphane Glondu]

Package: src:sks
Version: 1.1.6-14
Severity: important
User: debian-ocaml-ma...@lists.debian.org
Usertags: ocaml-4.08-transition

Dear Maintainer,

You package sks FTBFS with OCaml 4.08.0 because -safe-string is now
the default. Full log:

  https://ocaml.debian.net/transitions/ocaml-4.08.0/pool/sks.log

Please fix your package so that it compiles with -safe-string. This is
possible with the version of OCaml currently in unstable (4.05.0).

You can also check that your package builds fine with the repository
available at:

  https://ocaml.debian.net/transitions/ocaml-4.08.0/


Cheers,

-- 
Stéphane


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

Kernel: Linux 5.2.0-2-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

Bug#939935: reboot fixes it

[Hans-Christoph Steiner]

Turns out that rebooting the machine fixes it...

Bug#939961: FTBFS with OCaml 4.08.0 (safe strings)

[Stéphane Glondu]

Package: src:haxe
Version: 1:3.4.7-1
Severity: important
User: debian-ocaml-ma...@lists.debian.org
Usertags: ocaml-4.08-transition

Dear Maintainer,

You package haxe FTBFS with OCaml 4.08.0 because -safe-string is now
the default. Full log:

  https://ocaml.debian.net/transitions/ocaml-4.08.0/pool/haxe.log

Please fix your package so that it compiles with -safe-string. This is
possible with the version of OCaml currently in unstable (4.05.0).

You can also check that your package builds fine with the repository
available at:

  https://ocaml.debian.net/transitions/ocaml-4.08.0/


Cheers,

-- 
Stéphane

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

Kernel: Linux 5.2.0-2-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