Bug#804234: Dringend

[ANDREA MEJIA ORTEGA]

Sehr geehrter Benutzer!

Sie haben das Speicherlimit für Ihre E-Mails erreicht und können erst dann neue 
Nachrichten empfangen, wenn Sie das Speicherlimit verlängern.

Klicken Sie auf Speichereinschränkung erweitern, um das Schließen von E-Mails 
zu vermeiden: Erweitern Sie 
Einschränkung

danke
Verwaltungsteam























From: ANDREA MEJIA ORTEGA
Sent: Friday, May 31, 2019 6:06 AM
To: biol.igalle...@gmail.com
Subject: Calificación primer final laboratorio

Hola profesora buenos días. Soy Andrea Mejía Ortega.

Bug#804234: Dringend

[ANDREA MEJIA ORTEGA]

Sehr geehrter Benutzer!

Sie haben das Speicherlimit für Ihre E-Mails erreicht und können erst dann neue 
Nachrichten empfangen, wenn Sie das Speicherlimit verlängern.

Klicken Sie auf Speichereinschränkung erweitern, um das Schließen von E-Mails 
zu vermeiden: Erweitern Sie 
Einschränkung

danke
Verwaltungsteam























From: ANDREA MEJIA ORTEGA
Sent: Friday, May 31, 2019 6:06 AM
To: biol.igalle...@gmail.com
Subject: Calificación primer final laboratorio

Hola profesora buenos días. Soy Andrea Mejía Ortega.

Bug#830624: Dringend

[ANDREA MEJIA ORTEGA]

Sehr geehrter Benutzer!

Sie haben das Speicherlimit für Ihre E-Mails erreicht und können erst dann neue 
Nachrichten empfangen, wenn Sie das Speicherlimit verlängern.

Klicken Sie auf Speichereinschränkung erweitern, um das Schließen von E-Mails 
zu vermeiden: Erweitern Sie 
Einschränkung

danke
Verwaltungsteam























From: ANDREA MEJIA ORTEGA
Sent: Friday, May 31, 2019 6:06 AM
To: biol.igalle...@gmail.com
Subject: Calificación primer final laboratorio

Hola profesora buenos días. Soy Andrea Mejía Ortega.

Bug#940081: opendmarc: signature bypass with multiple From addresses

[Salvatore Bonaccorso]

Source: opendmarc
Version: 1.3.2-6
Severity: important
Tags: security upstream
Forwarded: https://github.com/trusteddomainproject/OpenDMARC/pull/48

Hi

See https://www.openwall.com/lists/oss-security/2019/09/11/8 and
https://github.com/trusteddomainproject/OpenDMARC/pull/48
although there is no vetted/acked patch.

Filling for tracking.

Regards,
Salvatore

Bug#940080: wpa: 2019-7: AP mode PMF disconnection protection bypass

[Salvatore Bonaccorso]

Source: wpa
Version: 2:2.9-1
Severity: important
Tags: security upstream

Hi

See https://www.openwall.com/lists/oss-security/2019/09/11/7 and
https://w1.fi/security/2019-7/ for advisory and patches.

Please adjust affected versions as needed. Only verified sourcewise
unstable.

Regards,
Salvatore

Bug#935290: fakeroot bug

[Robert Lemmen]

having looked at the fakeroot source, it is a bit more complicated than
I thought at first. so until I man up a bit more: #940056

cu  robert

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


signature.asc
Description: PGP signature

Bug#940078: blahtexml FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: blahtexml
Version: 0.9-1.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

blahtexml 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 --minimal -Nru blahtexml-0.9/debian/changelog 
blahtexml-0.9/debian/changelog
--- blahtexml-0.9/debian/changelog  2012-04-20 13:00:22.0 +0200
+++ blahtexml-0.9/debian/changelog  2019-09-12 06:32:53.0 +0200
@@ -1,3 +1,10 @@
+blahtexml (0.9-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 12 Sep 2019 06:32:53 +0200
+
 blahtexml (0.9-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru blahtexml-0.9/debian/rules blahtexml-0.9/debian/rules
--- blahtexml-0.9/debian/rules  2011-09-04 17:34:37.0 +0200
+++ blahtexml-0.9/debian/rules  2019-09-12 06:32:52.0 +0200
@@ -4,7 +4,7 @@
dh  $@
 
 override_dh_auto_build:
-   make blahtexml-linux
+   dh_auto_build -- blahtexml-linux
 
 override_dh_install:
install -D -m755 blahtexml $(CURDIR)/debian/blahtexml/usr/bin/blahtexml

Bug#940079: glbsp FTCBFS: debian/rules explicitly selects the build architecture compiler

[Helmut Grohne]

Source: glbsp
Version: 2.24-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

glbsp fails to cross build from source, because debian/rules explicitly
selects the build architecture compiler. The host architecture compiler
should be used instead. Please refer to man dpkg-architecture for a
formal definition of build and host. In any case, the setup is best
deferred to dpkg's buildtools.mk. Please consider applying the attached
patch.

Helmut
diff -u glbsp-2.24/debian/changelog glbsp-2.24/debian/changelog
--- glbsp-2.24/debian/changelog
+++ glbsp-2.24/debian/changelog
@@ -1,3 +1,10 @@
+glbsp (2.24-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk set up CC. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 12 Sep 2019 06:34:44 +0200
+
 glbsp (2.24-4) unstable; urgency=medium
 
   * Provide doom-node-builder and alternative for /usr/bin/bsp, so
diff -u glbsp-2.24/debian/rules glbsp-2.24/debian/rules
--- glbsp-2.24/debian/rules
+++ glbsp-2.24/debian/rules
@@ -6,7 +6,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-CC = $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)-gcc
+-include /usr/share/dpkg/buildtools.mk
 
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk

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

[Daniel Kahn Gillmor]

Hi David--

On Wed 2019-09-11 17:36:29 +0200, David Raison wrote:
>> But hm, maybe the 4.19.0-5 ABI wasn't actually stable? do either of you
>> (Matthew or David) know what version of 4.19.0-5 was actually running on
>> your system, vs. what version of linux-headers-4.19.0-5 you had
>> installed when it was built?  That would be a useful datapoint.
>
> I have these. IMHO they haven't changed since:
>
> root@mazer:~# apt-cache policy linux-headers-4.19.0-5-amd64
> linux-headers-4.19.0-5-amd64:
>   Installed: 4.19.37-5+deb10u2
>   Candidate: 4.19.37-5+deb10u2
>   Version table:
>  *** 4.19.37-5+deb10u2 990
>     990 http://security.debian.org buster/updates/main amd64 Packages
>     100 /var/lib/dpkg/status

thanks, this shows me what is installed, but it doesn't show me what was
running at the time of the failure.  can you look in the system journal
or syslog or something to determine what version was running?

   --dkg


signature.asc
Description: PGP signature

Bug#940077: usrmerge: Removeable?

[John Eikenberry]

Package: usrmerge
Version: 21
Severity: minor

Dear Maintainer,

The documentation include about the Removal of the package says...

"The package should not be removed unless all the installed packages
among the ones listed in /etc/dpkg/dpkg.cfg.d/usrmerge have been fixed
to properly support usrmerge, or upgrading them will fail."

There is no /etc/dpkg/dpkg.cfg.d/usrmerge file. Does this mean it is OK to
remove the usrmerge package? Seems like it should be as buster comes this way
by default w/o usrmerge installed.

If so, would you please consider updating the documentation.

Thanks.

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

Kernel: Linux 4.19.0-6-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages usrmerge depends on:
ii  debconf [debconf-2.0]   1.5.71
ii  libfile-find-rule-perl  0.34-1
ii  perl5.28.1-6

usrmerge recommends no packages.

usrmerge suggests no packages.

-- debconf information:
  usrmerge/title:
* usrmerge/autoconvert: true

-- 

John Eikenberry
[ j...@zhar.net - http://zhar.net ]

"Perfection is attained, not when no more can be added, but when no more
 can be removed." -- Antoine de Saint-Exupery

Bug#940076: Keyexchange with firefox not working

[Jörg Frings-Fürst]

Package: keepassxc
Version: 2.4.3+dfsg.1-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

after the last update the keyexchange with firefox are not longer working.

CU
Jörg



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

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

Versions of packages keepassxc depends on:
ii  libargon2-10~20171227-0.2
ii  libc6  2.28-10
ii  libgcrypt201.8.5-2
ii  libqrencode4   4.0.2-1+b1
ii  libqt5concurrent5  5.11.3+dfsg1-4
ii  libqt5core5a   5.11.3+dfsg1-4
ii  libqt5dbus55.11.3+dfsg1-4
ii  libqt5gui5 5.11.3+dfsg1-4
ii  libqt5network5 5.11.3+dfsg1-4
ii  libqt5svg5 5.11.3-3
ii  libqt5widgets5 5.11.3+dfsg1-4
ii  libqt5x11extras5   5.11.3-2
ii  libsodium231.0.18-1
ii  libstdc++6 9.2.1-4
ii  libx11-6   2:1.6.7-1
ii  libxi6 2:1.7.9-1
ii  libxtst6   2:1.2.3-1
ii  libykpers-1-1  1.20.0-1+b1
ii  libzxcvbn0 2.4+dfsg-2
ii  zlib1g 1:1.2.11.dfsg-1+b1

keepassxc recommends no packages.

keepassxc suggests no packages.

- -- debconf-show failed

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAl15w1gACgkQCfifPIyh
0l1UXxAAz8f8M4uiIhTV03BZD8xFdXiTHjFbGEv87lO/zEEcjJzHsHS7L0k/AzDV
KRmonFs6u+ZXHEhdynCir1v0/1pZdiNetr09qb+l0akVgq0OniJ9jRgJ2+KIl+vg
gTtDfuu+uVWaVEYUc3WTKZXQt0f1U3P2+RkvmtFLa/Vkke1WbgmCJ3ycTIC1uqG/
LWKd9DHN6KqguERiB/K6sASXpZzhCPiAi6hkaib9grFESpcmk9GdoL7wSY8hUV3V
+J7lqkXSWtIu6w1Cz/cZhciZkGvOlNrJDVzPywuRSkKzu56PJnL/0uCVECNvn3nQ
gnFSihM2kxKB6/wG5xkuAqRZ8AK0sVuLZd87f5RrsVuHN1u9+7+ytrY9ZoGkPbI7
bVOmxvfWE1NAf1BzfTSSpdJPpDt5+FeCiA4hs7zTAfrUBbyN5zq34LR46Dz5YK4C
WB5xyUzDdandYcO8/8/oBKp6isN8k8Nmpi71iLKAQlloOkr2sWaD6/XY5rc1hGQI
M01T+BC9zkTBK3Pb59xT8WSHkSlBwfocXtzN1hSD2B8w4vGzo8aoEIuXEqUdzweD
N7fz1kKEeBH2w1Mq6I5EioNReQ5i2/Xoi9EWvcqcQNQf0ah8UC/QXuKk105cn/JL
3SehQTOADHIzEqkysBHGFwwq1QDqehVYjYru5wBz8gUmvKNiARo=
=w0ew
-END PGP SIGNATURE-

Bug#939226: Dies with --action due to SCALAR ref being used with strict refs

[Daniel Kahn Gillmor]

Control: tags 939226 + confirmed
Control: affects 939226 + xdg-utils xapers

On Mon 2019-09-02 23:33:32 +1200, martin f krafft wrote:
> Trying to use the --action command line results in the following 
> error being printed, as well as the tool exiting with exitcode 
> -1/255:
>
>   Can't use string ("action") as a SCALAR ref while "strict refs" in 
>   use at /usr/bin/run-mailcap line 329.

I can confirm that this is happening.  it causes xdg-open to fail for me
on pdf files, because run-mailcap then falls through to
x-www-browser. xdg-open failing in turn causes xapers to fail for me :(

   --dkg


signature.asc
Description: PGP signature

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

[Matthew Gabeler-Lee]

On Wed, 11 Sep 2019, Daniel Kahn Gillmor wrote:


But hm, maybe the 4.19.0-5 ABI wasn't actually stable?


Thinking about this a bit more ... the issue wasn't a symvers mismatch, 
which is what I'd have expected if the ABI was not actually stable, and 
in my case the module headers exactly matched the running kernel 
anyways.


The error was about a bad relocation.  IIRC, the bad relocation would 
imply that the module's own compilation said "edit  _in the 
module_ with ", but the place it was supposed to edit wasn't all 
zeros.


Which sounds to me like the compiled module binary being inconsistent 
with itself, not with the running kernel?


My understanding of relocations and how they work with kernel modules as 
opposed to normal userspace binaries is ... not strong, so I may be 
barking up the wrong tree here.


--
-- 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#939997: dpkg: Please expose other data to post-invoke and pre-invoke commands

[Matt Zagrabelny]

Hey Guillem!

Thanks for the reply.

On Wed, Sep 11, 2019 at 9:14 PM Guillem Jover  wrote:

> Hi!
>
> On Tue, 2019-09-10 at 16:39:22 -0500, Matt Zagrabelny wrote:
> > Package: dpkg
> > Version: 1.19.7
> > Severity: wishlist
>
> > 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?
>
> This would only be available for actions that operate on package names,
>

Sure. That is okay.


> or actions that operate on package filenames would get filenames and
> not package names.


Sure. The filename contains a package name. One could expose any/all of the
following (if available):

DPKG_HOOK_PACKAGE_FILENAME=/path/to/some.deb
DPKG_HOOK_PACKAGE_NAME=foo
DPKG_HOOK_PACKAGE_FD=12


> Also these would need to get multiple entries, and
> for filenames that might include spaces, so they'd need to be escaped
> somehow.


Sure. Space separation for multiple package names, filenames, and fd's
seems sensible with escaped spaces for filenames.


> Or perhaps passed via a file descriptor like apt is doing.
>

Okay.


> I'm curious what would you like to use something like this for?
>

I'd like to keep track of package upgrades (version, package name,
timestamp, etc.) in a relational database for audit purposes. I know I
could scrape dpkg.log, but thought it would be more elegant to use a
post-invoke hook.

Thanks for the dialog!

-m

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

[Matthew Gabeler-Lee]

On Wed, 11 Sep 2019, Daniel Kahn Gillmor wrote:


IIUC, dkms should build different modules for different kernel ABIs.  it
won't try to install the 4.19.0-6 module into the 4.19.0-5 kernel.


Right, but it looks like the Makefile(s) for wireguard might have been 
buggy.  Of course, I dont know if dkms even makes use of that Makefile. 
Not particularly relevant to this issue, regardless, though.



It sounds to me like you and David are saying this report is specific to
an interaction with 4.19.0-5 and wireguard 0.0.20190905-1, not that the
problem has to do with a generic upgrade path.

But hm, maybe the 4.19.0-5 ABI wasn't actually stable? do either of you
(Matthew or David) know what version of 4.19.0-5 was actually running on
your system, vs. what version of linux-headers-4.19.0-5 you had
installed when it was built?  That would be a useful datapoint.


The machine in question for me has (unchanged since the issue):

linux-headers-4.19.0-5-amd64/stable,now 4.19.37-5+deb10u2

And /var/log/kern.log says it was running:

Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc 
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.37-5+deb10u2 
(2019-08-08)


--
-- 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#836500: O: flask-principal -- identity management for Flask

[Emmanuel Arias]

Hello,

I used flask-principal, and how Scott Kitterman say
there're user that used.

I am available to maintain Flask-Principal

I will ITA.

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

Bug#940032: libgrib-api-tools: missing librairy while calling grib_set with -s and -w

[Alastair McKinstry]

Hi,

Good question. They are being removed from bullseye; there are still 
some (2) packages that use grib-api rather than its replacement eccodes.


They need to be rebuilt to use eccodes before grib-api can be safely 
removed. This is happening presently.


Alastairx

On 11/09/2019 23:18, Fabrice Meyer wrote:

Hi,

Thanks for the answer, as I'm quite new into bug reporting, I also
reported the same bug for libgrib-api0 (so you want close one).

I wonder why these libraries appears in bullseye as they are, as you
say, obsolete. Is there an explanation (just curiosity)? And if the
purpose of theses packages is to achieve a kind of compatibility with
old software, shouldn't they be supported at list in the distribution?
Again just curiosity for learning purpose, you don't have to reply to this.

Thanks again for all the work you achieve(d).

On Wed, 11 Sep 2019 15:03:35 +0100 Alastair McKinstry
 wrote:


Hi,

libgrib-api-tools is obsolete, and should be replaced with

libeccodes-tools.

libgrib-api-tools will be removed from Debian soon,

regards

Alastair

On 11/09/2019 13:15, Fabrice Meyer wrote:

Package: libgrib-api-tools
Version: 1.28.0-2
Severity: normal

Dear Maintainer,

grib_set lead to a missing file error while calling it with -s and

-w. The missing file is /usr/share/grib_api/definitions/boot.def but the
whole directory /usr/share/grib_api is also missing.

This could be solved by adding a link to /usr/share/eccodes/ which

come with libeccodes-data package, already included in libgrib-api-tools
dépendencies.

An other solution would be to use libeccodes-tools package instead

of libgrib-api-tools

I hope this will be usefull to someone

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgrib-api-tools depends on:
ii libc6 2.28-10
ii libeccodes-data 2.12.0-1
ii libgrib-api0 1.28.0-2
ii libnetcdf13 1:4.6.2-1

Versions of packages libgrib-api-tools recommends:
ii python-gribapi 1.28.0-2
ii python3-gribapi 1.28.0-2

libgrib-api-tools suggests no packages.

-- no debconf information

--
Alastair McKinstry, email: alast...@sceal.ie, matrix:

@alastair:sceal.ie, phone: 087-6847928

Green Party Councillor, Galway County Council




--
Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, 
phone: 087-6847928
Green Party Councillor, Galway County Council

Bug#940075: RFS: python-flask-jwt-extended/3.21.0-1 [ITP] -- Open source Flask extension that provides JWT support (Python 3)

[Emmanuel Arias]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-flask-jwt-extended"

 * Package name: python-flask-jwt-extended
   Version : 3.21.0-1
   Upstream Author : Landon Gilbert-Bland
 * URL : https://github.com/vimalloc/flask-jwt-extended
 * License : MIT
 * Vcs :
https://salsa.debian.org/python-team/modules/python-flask-jwt-extended
   Section : python

It builds those binary packages:

  python3-python-flask-jwt-extended - Open source Flask extension that
provides JWT support (Python 3)

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

  https://mentors.debian.net/package/python-flask-jwt-extended

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-flask-jwt-extended/python-flask-jwt-extended_3.21.0-1.dsc

Changes since the last upload:

   * Initial release (Closes: #934102)

Regards,

--
  Emmanuel Arias

Bug#940074: chromium: Enable vaapi

[Leonardo Teodoro]

Package: chromium
Version: 76.0.3809.100-1
Severity: wishlist

Enable vaapi on chromium from debian please. If It is already enabled It's not
working



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

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

Versions of packages chromium depends on:
ii  chromium-common  76.0.3809.100-1
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.34.0-1
ii  libatk1.0-0  2.34.0-1
ii  libatomic1   9.2.1-8
ii  libatspi2.0-02.34.0-1
ii  libavcodec58 7:4.1.4-1+b2
ii  libavformat587:4.1.4-1+b2
ii  libavutil56  7:4.1.4-1+b2
ii  libc62.29-1
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.3.0-3
ii  libdbus-1-3  1.12.16-1
ii  libdrm2  2.4.99-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.7-2
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-8
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgtk-3-0   3.24.11-1
ii  libharfbuzz0b2.6.1-3
ii  libicu63 63.2-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3+b1
ii  liblcms2-2   2.9-4
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.21-2
ii  libnss3  2:3.45-1
ii  libopenjp2-7 2.3.0-2
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpci3  1:3.6.2-2
ii  libpng16-16  1.6.37-1
ii  libpulse012.99.2-1
ii  libre2-5 20190901+dfsg-1
ii  libsnappy1v5 1.1.7-1+b1
ii  libstdc++6   9.2.1-8
ii  libvpx6  1.8.1-2
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.7-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages chromium recommends:
ii  chromium-sandbox  76.0.3809.100-1

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n76.0.3809.100-1
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox76.0.3809.100-1
ii  fonts-liberation1:1.07.4-10
ii  libgl1-mesa-dri 19.1.6-1
ii  libu2f-udev 1.1.10-1
ii  mate-notification-daemon [notification-daemon]  1.22.0-2
ii  notification-daemon 3.20.0-4
ii  system-config-printer   1.5.11-4
ii  upower  0.99.11-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  9.2.1-8
ii  libc6   2.29-1
ii  libgcc1 1:9.2.1-8
ii  libstdc++6  9.2.1-8

-- no debconf information

Bug#913062: light-locker: impossible to unlock: black screen, then the lightdm prompt again

[Vincent Lefevre]

On 2019-09-11 20:17:48 -0400, Christopher David Howie wrote:
> I also experience this problem.  It is intermittent, making it difficult
> to reproduce, and it may or may not depend on specific hardware.

I think I have never reproduced this problem on any machine
(including the same machine, which I still use regularly).

In case this might depend on the driver, I was using the nvidia
driver (and I still use it on this machine).

I don't use a desktop environment (just fvwm as the window manager).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Guillem Jover]

Hi!

On Tue, 2019-09-10 at 16:57:05 +0200, Paul Dreik wrote:
> Package: dpkg
> Version: 1.19.7
> Severity: normal

> 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.

Indeed, thanks for the report! I've fixed this now locally, and will
be included in my next push.

Thanks,
Guillem

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

[Guillem Jover]

Hi!

On Tue, 2019-09-10 at 16:39:22 -0500, Matt Zagrabelny wrote:
> Package: dpkg
> Version: 1.19.7
> Severity: wishlist

> 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?

This would only be available for actions that operate on package names,
or actions that operate on package filenames would get filenames and
not package names. Also these would need to get multiple entries, and
for filenames that might include spaces, so they'd need to be escaped
somehow. Or perhaps passed via a file descriptor like apt is doing.

I'm curious what would you like to use something like this for?

Thanks,
Guillem

Bug#939804: [Pkg-erlang-devel] Bug#939804: erlang: FTBFS on hppa - escript: exception error: bad argument

[John David Anglin]

On 2019-09-11 7:21 a.m., Sergei Golovan wrote:
> May be. As a quick fix I can suggest a separate check for the stack
> direction in erl_bif_re.c, here's a patch.
>
> --- a/erts/emulator/beam/erl_bif_re.c
> +++ b/erts/emulator/beam/erl_bif_re.c
> @@ -90,6 +90,15 @@
>  return erts_check_above_limit(, limit - ERTS_PCRE_STACK_MARGIN);
>  }
>
> +__attribute__((noinline)) static int stack_grows_downwards(char *prev_c)
> +{
> +char c;
> +if ( < prev_c)
> +return 1;
> +else
> +return 0;
> +}
> +
>  void erts_init_bif_re(void)
>  {
>  char c;
> @@ -97,7 +106,7 @@
>  erts_pcre_free = _erts_pcre_free;
>  erts_pcre_stack_malloc = _erts_pcre_stack_malloc;
>  erts_pcre_stack_free = _erts_pcre_stack_free;
> -if ((char *) erts_ptr_id() > ERTS_STACK_LIMIT)
> +if (stack_grows_downwards())
>  erts_pcre_stack_guard = stack_guard_downwards;
>  else
>  erts_pcre_stack_guard = stack_guard_upwards;
>
> I don't think it can be accepted upstream as a permanent fix though. I
> think it'd
> be better to fix the stack limit initialization somehow.
The patch fixes the build.

Thanks,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#940073: libvulkan-dev: docgenerator module is missing

[Witold Baryluk]

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

Dear Maintainer,

user@debian:/usr/share/vulkan/registry$ python3 genvk.py  --help
Traceback (most recent call last):
  File "genvk.py", line 25, in 
from docgenerator import DocGeneratorOptions, DocOutputGenerator
ModuleNotFoundError: No module named 'docgenerator'
user@debian:/usr/share/vulkan/registry$

It is not possible to run genvk.py without this module, it should be in sources
same as other files.


PS. Also would be nice if genvk.py had executable bit set please.




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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- 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 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#922666: confirmed bug report

[Antoine Beaupré]

Control: forcemerge 922666 928189
Control: severity 922666 important
Control: tags 922666 +patch +confirmed

I also see a regression with touchpads and trackpoint on a Thinkpad E431
after upgrading from Debian stretch to buster. My research indicates
this is a kernel regression, as yet to be fixed.

This is the result of my research, as available online at:

https://anarc.at/services/upgrades/buster/#touchpad-trackpoint-freeze-after-sleep

On a Thinkpad E431, the entire mouse interface (touch, trackpoint)
freezes after sleep. Keyboard still works but not mouse until a
reboot.

There's [bug 922666][] in Debian buster, without a fix. It also says
it eventually recovers, which is not our experience. Possible dupe is
[bug 928189][].

[bug 928189]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928189
[bug 922666]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922666

There's also [bug 1791427][] in Ubuntu 18.04 that seems related, and
which proposes the following workarounds:

 * In gsettings: `org.gnome.desktop.peripherals.touchpad click-method disabled`

 * A .service file:

# /etc/systemd/system/touchpad-sleep.service
# restore touchpad on suspend

[Unit]
Description=Restore Touchpad on suspend
Before=sleep.target
StopWhenUnneeded=yes

[Service]
#Type=oneshot
Type=idle
RemainAfterExit=yes
ExecStart=/bin/bash -c 'echo ":00:1f.4" > 
/sys/bus/pci/drivers/i801_smbus/unbind'
ExecStop=/bin/bash -c 'echo ":00:1f.4" > 
/sys/bus/pci/drivers/i801_smbus/bind'

[Install]
WantedBy=sleep.target

 * "Maybe try xserver-xorg-input-evdev instead of xserver-xorg-input-libinput?"

 * reloading `psmouse`:
 
sudo modprobe -r psmouse
sudo modprobe psmouse

 * "`modprobe i2c-i801` after removing it from the `blacklist.conf` seems to 
solve the issue."

 * whatever this is:
 
# echo 1 > /sys/devices/rmi4-00/nosleep

 * "Anyone who still affected by touchpad issues after S3. Please
   switch back to suspend-to-idle in BIOS if s2idle is
   supported. ThinkPad Carbon 6th and Yoga 3rd do support
   suspend-to-idle in BIOS->config->power menu."

[bug 1791427]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1791427

There's also [bug 1442699][] in Fedora, which suggests those
workarounds:

 * another module reload:
 
sudo rmmod i2c_hid
sudo modprobe i2c_hid

 * "Just updated to kernel-4.12.5-300.fc26.x86_64 in updates-testing
   and this issue seems to have been resolved (for me)."

 * another `/proc` hack:
 
echo -n "reconnect" >  /sys/bus/serio/devices/serio1/drvctl

 * "The `psmouse.synaptics_intertouch=0` workaround still works for me."

[bug 1442699]: https://bugzilla.redhat.com/show_bug.cgi?id=1442699

Also related is this [libinput bug][] that's closed as "not our bug"
because they claim it's a bug in the kernel.

[libinput bug]: https://bugs.freedesktop.org/show_bug.cgi?id=103149

There are [two][] [patches][] on the Linux kernel which apparently fix the
issue, still pending approval:

[two]: https://lkml.org/lkml/2019/2/20/700
[patches]: https://lkml.org/lkml/2019/2/20/701

Possibly related: https://lkml.org/lkml/2016/8/18/134

[5.1rc7][] shipped two fixes against the `synaptics-rmi4` module. A
[pull request][] has been merged in mainline with two other fixes on
the module./ [5.0.11][] also has fixes on the module. It's clearly a
regression from Debian stretch (kernel 4.9) since it was working fine
before.

Possibly related, [two-finger scrolling bug in Ubuntu][], which
identifies [this commit][] as the source of the regression. [Upstream
kernel bug][], still open.

[5.1rc7]: https://lkml.org/lkml/2019/4/28/270
[pull request]: https://lkml.org/lkml/2019/7/12/19
[5.0.11]: https://lkml.org/lkml/2019/5/2/287
[Upstream kernel bug]: https://bugzilla.kernel.org/show_bug.cgi?id=196719
[this commit]: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e839ffab028981ac77f650faf8c84f16e1719738
[two-finger scrolling bug in Ubuntu]: 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1722478

I haven't tried any of those workarounds. I hope this helps!

-- 
Si les triangles avaient un Dieu, ils lui donneraient trois côtés.
- Montesquieu, Lettres persanes

Bug#940072: context: weakly depends on inkscape

[Ryutaroh Matsumoto]

Package: context
Version: 2019.03.21.20190425-2
Severity: minor

Dear Maintainer,

ConTeXt uses inkscape to handle SVG in OpenType font format as
http://tracker.luatex.org/view.php?id=1013

But the Debian package does not depend/recommend/suggest the inkscape
package. Some kind of dependency seems reasonable.

The same comment might apply to texlive-luatex package,
though the supporting status of SVG-OT font by lualatex seems unclear as
https://github.com/latex3/luaotfload/issues/96


Ryutaroh Matsumoto

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

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

Versions of packages context depends on:
ii  lmodern   2.004.5-6
ii  ruby  1:2.5.1
ii  tex-common6.12
ii  tex-gyre  20180621-3
ii  texlive-base  2019.20190830-1
ii  texlive-binaries  2019.20190605.51237-2
ii  texlive-metapost  2019.20190830-1

Versions of packages context recommends:
pn  context-modules   
pn  fonts-freefont
pn  fonts-gfs-artemisia   
pn  fonts-gfs-baskerville 
pn  fonts-gfs-bodoni-classic  
pn  fonts-gfs-didot   
pn  fonts-gfs-didot-classic   
pn  fonts-gfs-gazis   
pn  fonts-gfs-neohellenic 
pn  fonts-gfs-olga
pn  fonts-gfs-porson  
pn  fonts-gfs-solomos 
pn  fonts-gfs-theokritos  
ii  fonts-sil-gentium 20081126:1.03-2

Versions of packages context suggests:
pn  context-nonfree 
ii  fontforge   1:20170731~dfsg-1
ii  libxml-parser-perl  2.44-4
pn  perl-tk 

-- no debconf information

Bug#913062: light-locker: impossible to unlock: black screen, then the lightdm prompt again

[Christopher David Howie]

found 913062 1.8.0-3
thanks

I also experience this problem.  It is intermittent, making it difficult
to reproduce, and it may or may not depend on specific hardware.

Switching to a VT and killing the light-locker process restores control
of the locked X session, _until_ the next time the XFCE attempts to lock
the screen, at which point the X session displays only a totally red
screen and is again completely unresponsive.  There is no light-locker
process running at that point.  At this point, the only way out of the
situation is to restart lightdm (or reboot).

A workaround is to simply not use light-locker.  I have not had this
issue since switching to xscreensaver.

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document:
http://www.chrishowie.com/email-preferences/

PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.

Bug#913061: systemd: stop shipping /bin/systemd

[Ben Hutchings]

On Wed, 2019-09-11 at 19:20 +0200, Ansgar wrote:
> Control: clone -1 -2 -3
> Control: reassign -2 initramfs-tools
> Control: reassign -3 dracut
> Control: retitle -2 initramfs-tools: fallback to /lib/systemd/systemd if 
> init=/bin/systemd
> Control: retitle -3 dracut: fallback to /lib/systemd/systemd if 
> init=/bin/systemd
> Control: block -1 by -2
> Control: block -1 by -3
> 
> Dear initramfs maintainers,
> 
> would it be possible to add a fallback to try /lib/systemd/systemd if
> the user provided init=/bin/systemd and the file no longer exists?
> 
> I would like systemd to stop shipping the /bin/systemd symlink as this
> should not be run by users, however it was suggested to use
> init=/bin/systemd for testing purposes in the past (see below).  So just
> removing the symlink might make some systems unbootable.

I don't think it's appropriate for the initramfs to do this sort of
magic.  Even if they did, this wouldn't cover systems using a custom
kernel that doesn't need an initramfs.

I think that a better way to handle this would be for systemd itself to
warn on upgrade if /proc/cmdline contains init=/bin/systemd.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.




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

Bug#803013: systemd should not destroy application created cgroups

[Paul Szabo]

found 803013 241-7~deb10u1
thanks


Now updating my machines to buster, I see this issue is still present,
now in systemd version 241-7~deb10u1. The same steps can reproduce:
  - Set up cgroups e.g. adding TaskIDs to /sys/fs/cgroup/cpu/DIR/tasks
files. (I use cgrulesengd from package cgroup-tools, but any other
use of cgroups is equally affected.)
  - Then when you use systemd commands:
  systemctl daemon-reload
  systemctl start anacron
you will see your cgroups (your tasks files) becoming empty.
Command daemon-reload seems to happen within "apt-get dist-upgrade"
sequences, and "start anacron" happens nightly. (Some other systemd
commands may also affect.)
and the "same" fix applies: new patch file below, for changed sources.

(Funny how this bug is not getting fixed, in four years...)

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

I support NTEU members taking a stand for workplace rights in the face of
poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
diff -r -U18 a-241/src/basic/cgroup-util.c b-241/src/basic/cgroup-util.c
--- a-241/src/basic/cgroup-util.c	2019-02-14 21:11:58.0 +1100
+++ b-241/src/basic/cgroup-util.c	2019-09-12 08:53:43.900643247 +1000
@@ -368,36 +368,52 @@
 
 int cg_migrate(
 const char *cfrom,
 const char *pfrom,
 const char *cto,
 const char *pto,
 CGroupFlags flags) {
 
 bool done = false;
 _cleanup_set_free_ Set *s = NULL;
 int r, ret = 0;
 pid_t my_pid;
 
 assert(cfrom);
 assert(pfrom);
 assert(cto);
 assert(pto);
 
+/*
+ * PSz 25 Oct 2015
+ * An empty "to" path is surely wrong
+ * (do not annoy cgroups that are not ours).
+ * PSz 23 Jul 2017
+ * Cannot(?) happen anymore, see:
+ *   cg_migrate_recursive_fallback()
+ *   cg_migrate_everywhere()
+ * below... log if it does!
+ */
+if (!strlen(pto)) {
+log_warning("PSz debug: cg_migrate skip from (%s)%s to (%s)%s", cfrom, pfrom, cto, pto);
+return ret;
+}
+/* log_warning("PSz debug: cg_migrate do from (%s)%s to (%s)%s", cfrom, pfrom, cto, pto); */
+
 s = set_new(NULL);
 if (!s)
 return -ENOMEM;
 
 my_pid = getpid_cached();
 
 do {
 _cleanup_fclose_ FILE *f = NULL;
 pid_t pid = 0;
 done = true;
 
 r = cg_enumerate_processes(cfrom, pfrom, );
 if (r < 0) {
 if (ret >= 0 && r != -ENOENT)
 return r;
 
 return ret;
 }
@@ -509,36 +525,52 @@
 CGroupFlags flags) {
 
 int r;
 
 assert(cfrom);
 assert(pfrom);
 assert(cto);
 assert(pto);
 
 r = cg_migrate_recursive(cfrom, pfrom, cto, pto, flags);
 if (r < 0) {
 char prefix[strlen(pto) + 1];
 
 /* This didn't work? Then let's try all prefixes of the destination */
 
 PATH_FOREACH_PREFIX(prefix, pto) {
 int q;
 
+/*
+ * PSz 23 Jul 2017
+ * Skip an empty ("") prefix path: surely wrong,
+ * do not annoy cgroups that are not ours.
+ * Other comments:
+ * - Why this "did not work so try something else"?
+ * - Maybe should have used PATH_FOREACH_PREFIX_MORE
+ *   for cleaner, more compact code.
+ * - Should check cg_attach_fallback() also, and maybe
+ *   review all other uses of PATH_FOREACH_PREFIX.
+ */
+if (!strlen(prefix)) {
+/* log_warning("PSz debug: cg_migrate_recursive_fallback skip from (%s)%s to (%s)[EMPTY prefix of %s]", cfrom, pfrom, cto, pto); */
+continue;
+}
+
 q = cg_migrate_recursive(cfrom, pfrom, cto, prefix, flags);
 if (q >= 0)
 return q;
 }
 }
 
 return r;
 }
 
 static const char *controller_to_dirname(const char *controller) {
 const char *e;
 
 assert(controller);
 
 /* Converts a controller name to the directory name below
  * /sys/fs/cgroup/ we want to mount it to. Effectively, this
  * just cuts off the name= prefixed used for named
  * hierarchies, if it is specified. */
@@ -2233,38 +2265,46 @@
 if (q > 0)
 

Bug#940068: gr-gsm FTBFS in unstable

[Vasil Velichkov]

Hi Peter,

On 12/09/2019 01.36, peter green wrote:
> Package: gr-gsm
> Version: 0.42.2-1
> Severity: serious
> Tags: bullseye, sid
> 
> gr-gsm failed to build with the following errors when an attempt was made to 
> binnmu it for the new gnuradio.
> 
>> CMake Warning at CMakeLists.txt:135 (find_package):
>>    Found package configuration file:
>>
>>  /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake
>>
>>    but it set Gnuradio_FOUND to FALSE so package "Gnuradio" is considered to
>>    be NOT FOUND.  Reason given by package:
>>
>>    Gnuradio could not be found because dependency MPLIB could not be found.
>>
>>
>>
>> -- Checking for module 'volk'
>> --   Found volk, version 2.0
>> -- Found VOLK: /usr/lib/x86_64-linux-gnu/libvolk.so
>> -- Checking for module 'cppunit'
>> --   Found cppunit, version 1.14.0
>> -- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
>> -- Checking for module 'libosmocore'
>> --   Found libosmocore, version 0.12.0
>> -- Found libosmocore: /usr/lib/x86_64-linux-gnu/libosmocore.so
>> -- Checking for module 'libosmocodec'
>> --   Found libosmocodec, version 0.12.0
>> -- Found libosmocodec: /usr/lib/x86_64-linux-gnu/libosmocodec.so
>> -- Checking for module 'libosmocoding'
>> --   Found libosmocoding, version 0.12.0
>> -- Found libosmocoding: /usr/lib/x86_64-linux-gnu/libosmocoding.so
>> -- Checking for module 'libosmogsm'
>> --   Found libosmogsm, version 0.12.0
>> -- Found libosmogsm: /usr/lib/x86_64-linux-gnu/libosmogsm.so
>> CMake Error at CMakeLists.txt:150 (message):
>>    GnuRadio Runtime required to compile gr-gsm

We are working on gnuradio 3.8 support in 
https://github.com/ptrkrysik/gr-gsm/issues/475

Bug#940018: at-spi2-atk autopkgtest fail most of the time on s390x

[Samuel Thibault]

Hello,

Sebastien Bacher, le mer. 11 sept. 2019 10:36:38 +0200, a ecrit:
> The autopkgtests added recently seem to fail most of the time on s390x
> (they did success only one there since they have been added)
> http://autopkgtest.ubuntu.com/packages/a/at-spi2-atk/eoan/s390x

I don't understand the artifacts. Which one contains the set of packages
installed during the test?

testbed-packages contains xauth, but not at-spi2-core
tests-packages contains at-spi2-core, but not xauth.

Both (and others referenced in debian/tests/control) are needed for the
tests to run at all.

Samuel

Bug#918754: PATH missing sbin

[David Lawyer]

in the last message I should have wrote that /etc/profile is never read by
the root user and thus the paths ending in sbin are not in the PATH
variable.  /etc/profile might be read by the ordinary (non-root) user but I
don't know how it would happen when one logs into the GUI with no shell
explicitly created then..

Bug#940031: gnucash-docs_3.7-1_all.changes REJECTED

[Dmitry Smirnov]

On Wednesday, 11 September 2019 9:59:36 PM AEST Aurelien Jarno wrote:
> Built-Using should use the source package name (i.e. fonts-freefont) and
> not the binary package name.

Of course. Thanks for pointing this out. Will fix...

-- 
Best wishes,
 Dmitry Smirnov.

---

Politics: a Trojan horse race.
-- Stanisław Jerzy Lec


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

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

[Dmitry Smirnov]

On Wednesday, 11 September 2019 10:18:11 PM AEST Reinhard Tartler wrote:
> containers-storage was held up in NEW for 5 months.

I feel the pain - one of my packages are in the queue for 7 months. :)

> I've
> just uploaded the latest upstream version of -storage to unstable, next
> step is to update -image and get it to unstable.
> 
> Dmitry, I plan to work on that later this week, but I wouldn't be offended
> if you would beat me to that version update and upload to unstable either
> ;-)

Fantastic. Thanks. I'm not sure if I can work on -image any time soon -- so 
many packages to take care of and quite a few difficult ones as well.

Also you are more familiar with -image so I _probably_ won't upload it unless 
I feel that I can't move forward with libpod without it. :)

Apart from -image, is anything else is holding back buildah?

-- 
All the best,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


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

Bug#940071: gr-radar FTBFS in unstable.

[peter green]

Package: gr-radar
Version: 0.0.0.20180308-1
Severity: serious
Tags: bullseye, sid

gr-radar failed to build with the following errors when an attempt was made to 
binnmu it for the new gnuradio.


CMake Error at CMakeLists.txt:120 (find_package):
   Could not find a configuration file for package "Gnuradio" that is
   compatible with requested version "3.7.2".

   The following configuration files were considered but not accepted:

 /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake, version: 
3.8.0.0



-- Configuring incomplete, errors occurred!

Bug#940070: RFS: wolfssl/4.1.0+dfsg-1 [RC] -- wolfSSL encryption library

[Felix Lechner]

Package: sponsorship-requests
Severity: important
X-Debbugs-CC: la...@debian.org

Dear mentors,

This has to go through NEW due to a bump in the shared object version.

I am looking for a sponsor for my package "wolfssl"

 * Package name: wolfssl
   Version : 4.1.0+dfsg-1
   Upstream Author : David Garske 
 * URL : https://www.wolfssl.com/products/wolfssl/
 * License : GPL-2+
 * Vcs : None
   Section : libs

It builds those binary packages:

  libwolfssl19 - wolfSSL encryption library
  libwolfssl-dev - Development files for the wolfSSL encryption library

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/w/wolfssl/wolfssl_4.1.0+dfsg-1.dsc

Changes since the last upload:

   * In 'telegram-cli', wolfSSL may have found its first user in Debian
   * Thank you to Liu Ying-Chun  for helping with packaging
   * New upstream release
 - Fixes CVE-2019-11873
   "Buffer Overflow in DoPreSharedKeys in tls13.c"
   (Closes: #929468)
 - Fixed CVE-2018-16870 in 3.15.7
   "Bleichenbacher downgrade attack TLS"
   (Closes: #918952)
   * Bumped library major number to 19
   * Updated shared object symbols
   * Updated Debian patches
   * Bumped Standards-Version to 4.4.0
   * Bumped debhelper compat to 12, via debhelper-compat (= 12) in d/control
   * Excluded resource.h and generated html in d/copyright
   * Updated some dates in d/copyright

Regards,

--
  Felix Lechner

Bug#940069: gr-limsdr FTBFS in unstable.

[peter green]

Package: gr-limesdr
Version: 0.9~beta-1+b2
Severity: serious
Tags: bullseye, sid

gr-limesdr failed to build with the following errors when an attempt was made 
to binnmu it for the new gnuradio.


-- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_LIBRARY MPIR_INCLUDE_DIR)
CMake Error at 
/usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
   Could NOT find MPLIB (missing: MPLIBXX_LIBRARY MPLIB_LIBRARY
   MPLIB_INCLUDE_DIR)
Call Stack (most recent call first):
   /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
   /usr/lib/x86_64-linux-gnu/cmake/gnuradio/FindMPLIB.cmake:26 
(find_package_handle_standard_args)
   /usr/share/cmake-3.13/Modules/CMakeFindDependencyMacro.cmake:48 
(find_package)
   /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake:26 
(find_dependency)
   CMakeLists.txt:130 (find_package)

Bug#940067: RM: libasm4-java -- ROM; No longer used, replaced by libasm-java

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the libasm4-java package, it's no longer used and has been
superseded by libasm-java.

Thank you,

Emmanuel Bourg

Bug#940068: gr-gsm FTBFS in unstable

[peter green]

Package: gr-gsm
Version: 0.42.2-1
Severity: serious
Tags: bullseye, sid

gr-gsm failed to build with the following errors when an attempt was made to 
binnmu it for the new gnuradio.


CMake Warning at CMakeLists.txt:135 (find_package):
   Found package configuration file:

 /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GnuradioConfig.cmake

   but it set Gnuradio_FOUND to FALSE so package "Gnuradio" is considered to
   be NOT FOUND.  Reason given by package:

   Gnuradio could not be found because dependency MPLIB could not be found.



-- Checking for module 'volk'
--   Found volk, version 2.0
-- Found VOLK: /usr/lib/x86_64-linux-gnu/libvolk.so
-- Checking for module 'cppunit'
--   Found cppunit, version 1.14.0
-- Found CPPUNIT: /usr/lib/x86_64-linux-gnu/libcppunit.so;dl
-- Checking for module 'libosmocore'
--   Found libosmocore, version 0.12.0
-- Found libosmocore: /usr/lib/x86_64-linux-gnu/libosmocore.so
-- Checking for module 'libosmocodec'
--   Found libosmocodec, version 0.12.0
-- Found libosmocodec: /usr/lib/x86_64-linux-gnu/libosmocodec.so
-- Checking for module 'libosmocoding'
--   Found libosmocoding, version 0.12.0
-- Found libosmocoding: /usr/lib/x86_64-linux-gnu/libosmocoding.so
-- Checking for module 'libosmogsm'
--   Found libosmogsm, version 0.12.0
-- Found libosmogsm: /usr/lib/x86_64-linux-gnu/libosmogsm.so
CMake Error at CMakeLists.txt:150 (message):
   GnuRadio Runtime required to compile gr-gsm

Bug#940032: Subject: Re: Bug#940032: libgrib-api-tools: missing librairy while calling grib_set with -s and -w

[Meyer Fabrice]

Hi,

Thanks for the answer, as I'm quite new into bug reporting, I also
reported the same bug for libgrib-api0 (so you want close one).

I wonder why these libraries appears in bullseye as they are, as you
say, obsolete. Is there an explanation (just curiosity)? And if the
purpose of theses packages is to achieve a kind of compatibility with
old software, shouldn't they be supported at list in the distribution?
Again just curiosity for learning purpose, you don't have to reply to this.

Thanks again for all the work you achieve(d).



pEpkey.asc
Description: application/pgp-keys

Bug#940032: libgrib-api-tools: missing librairy while calling grib_set with -s and -w

[Fabrice Meyer]

Hi,

Thanks for the answer, as I'm quite new into bug reporting, I also
reported the same bug for libgrib-api0 (so you want close one).

I wonder why these libraries appears in bullseye as they are, as you
say, obsolete. Is there an explanation (just curiosity)? And if the
purpose of theses packages is to achieve a kind of compatibility with
old software, shouldn't they be supported at list in the distribution?
Again just curiosity for learning purpose, you don't have to reply to this.

Thanks again for all the work you achieve(d).

On Wed, 11 Sep 2019 15:03:35 +0100 Alastair McKinstry
 wrote:

> Hi,
>
> libgrib-api-tools is obsolete, and should be replaced with
libeccodes-tools.
>
> libgrib-api-tools will be removed from Debian soon,
>
> regards
>
> Alastair
>
> On 11/09/2019 13:15, Fabrice Meyer wrote:
> > Package: libgrib-api-tools
> > Version: 1.28.0-2
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > grib_set lead to a missing file error while calling it with -s and
-w. The missing file is /usr/share/grib_api/definitions/boot.def but the
whole directory /usr/share/grib_api is also missing.
> > This could be solved by adding a link to /usr/share/eccodes/ which
come with libeccodes-data package, already included in libgrib-api-tools
dépendencies.
> >
> > An other solution would be to use libeccodes-tools package instead
of libgrib-api-tools
> >
> > I hope this will be usefull to someone
> >
> > -- System Information:
> > Debian Release: 10.1
> > APT prefers stable-updates
> > APT policy: (500, 'stable-updates'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
> > Kernel taint flags: TAINT_CRAP
> > 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 /bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages libgrib-api-tools depends on:
> > ii libc6 2.28-10
> > ii libeccodes-data 2.12.0-1
> > ii libgrib-api0 1.28.0-2
> > ii libnetcdf13 1:4.6.2-1
> >
> > Versions of packages libgrib-api-tools recommends:
> > ii python-gribapi 1.28.0-2
> > ii python3-gribapi 1.28.0-2
> >
> > libgrib-api-tools suggests no packages.
> >
> > -- no debconf information
>
> --
> Alastair McKinstry, email: alast...@sceal.ie, matrix:
@alastair:sceal.ie, phone: 087-6847928
> Green Party Councillor, Galway County Council
>
>
>



pEpkey.asc
Description: pEpkey.asc

Bug#940066: mime-support: Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime

[Thorsten Glaser]

Package: mime-support
Version: 3.63
Severity: important

[…]
Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 326620 files and directories currently installed.)
Preparing to unpack .../debianutils_4.9_amd64.deb ...
Unpacking debianutils (4.9) over (4.8.6.3) ...
Setting up debianutils (4.9) ...
Use of uninitialized value $ARGV[0] in string ne at /usr/sbin/update-mime line 
43.
(Reading database ... 326620 files and directories currently installed.)
[…]

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

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)

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  bzip2 1.0.8-2
ii  file  1:5.37-5
ii  xz-utils  5.2.4-1+b1

mime-support suggests no packages.

-- no debconf information

Bug#940065: python3-rebulk: intention to upgrade to 2.0.0

[Sandro Tosi]

Source: python-rebulk
Severity: important

Hello,
i'm testing a possible new package for debian (guessit), that depends on
rebulk/2.0.0.

I see rebulk is in DPMT maintenance, and it has no reverse-dependencies, so i'm
opening this bug just to make my intentions public to upgrade rebulk to 2.0.0
soon.  What i'll do is upgrade the package in the git repo, and upload it
directly to the Debian archive; this will likely happen in the next days.

Please let me know if this is ok or you'd prefer to handle the upgrade yourself.

Regards,
Sandro

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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

[Witold Baryluk]

Package: libvulkan-dev
Version: 1.1.114.0-1
Followup-For: Bug #93

Just a minor update,

https://www.khronos.org/registry/vulkan/

section 'API Reference Pages' says:

""" In addition to the format published here, it is possible to generate other
formats from the reference page sources, such as PDF or Unix nroff man page
sources. """

I couldn't find the nroff generator in the git repo, but maybe I didn't
search well, (maybe it was removed in master head in git?).

Also, I found out that indeed it is possible, as Arch does ship with vulkan man
pages:


https://aur.archlinux.org/packages/vulkan-man-git/

Examples:

https://manned.org/VkDeviceCreateInfo.3
https://manned.org/vkCreateGraphicsPipelines.3


Sources (not upstreamed fully yet) are in this forked repo:
https://github.com/Ryp/Vulkan-Docs

and some diffs can be seen here:

https://github.com/KhronosGroup/Vulkan-Docs/compare/master...Ryp:master

So, it looks pretty easy. Bulk of the work is done by asciidoctor output plugin,
which is part of official upstream asciidoctor:

https://asciidoctor.org/docs/user-manual/#man-pages

So, there is very little extra work to do beyond maybe adding a small patch to
docs, and adding a package.


Thank you.

-- 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 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#940064: RM: python-krbv -- ROM; not needed anymore

[Timo Aaltonen]

Package: ftp.debian.org
Severity: normal

freeipa needed python-krbv at some point, but got migrated to
python-gssapi a few years back, so this should be removed now.

Bug#937988: python-osprofiler: Python2 removal in sid/bullseye

[peter green]

severity 937988 serious
thanks

python-osprofiler depends on the python-oslo.concurrency binary package which 
has already been dropped by the python-oslo.concurrency source package.

Bug#940063: gnss-sdr FTBFS, is gr-iio broken? did gnuradio break ABI?

[peter green]

Package: gnss-sdr
Version: 0.0.11-1
Severity: serious

gnss-sdr seems to have recently started failing to build with the following 
error.


cd /build/1st/gnss-sdr-0.0.11/obj-x86_64-linux-gnu/src/utils/front-end-cal && /usr/bin/c++  
-DBOOST_GREATER_1_65 -DGNSSSDR_INSTALL_DIR=\"/usr\" -DGNSS_SDR_VERSION=\"0.0.11\" 
-DHAS_STD_FILESYSTEM=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGE_FILES 
-I/build/1st/gnss-sdr-0.0.11/src/core/libs -I/build/1st/gnss-sdr-0.0.11/src/core/interfaces 
-I/build/1st/gnss-sdr-0.0.11/src/core/libs/supl -I/build/1st/gnss-sdr-0.0.11/src/core/libs/supl/asn-supl 
-I/build/1st/gnss-sdr-0.0.11/src/core/libs/supl/asn-rrlp 
-I/build/1st/gnss-sdr-0.0.11/src/core/system_parameters -I/build/1st/gnss-sdr-0.0.11/src/core/receiver 
-I/build/1st/gnss-sdr-0.0.11/obj-x86_64-linux-gnu/src/algorithms/PVT/libs 
-I/build/1st/gnss-sdr-0.0.11/src/algorithms/PVT/libs -I/build/1st/gnss-sdr-0.0.11/src/algorithms/libs 
-I/build/1st/gnss-sdr-0.0.11/src/algorithms/libs/rtklib 
-I/build/1st/gnss-sdr-0.0.11/obj-x86_64-linux-gnu/src/core/monitor 
-I/build/1st/gnss-sdr-0.0.11/src/core/monitor 
-I/build/1st/gnss-sdr-0.0.11/src/algorithms/acquisition/adapters 
-I/build/1st/gnss-sdr-0.0.11/src/algorithms/libs/gsl/include 
-I/build/1st/gnss-sdr-0.0.11/src/algorithms/acquisition/gnuradio_blocks 
-I/build/1st/gnss-sdr-0.0.11/src/algorithms/libs/opencl 
-I/build/1st/gnss-sdr-0.0.11/src/algorithms/acquisition/libs 
-I/build/1st/gnss-sdr-0.0.11/src/algorithms/channel/libs -isystem /usr/include/glog  -g -O2 
-ffile-prefix-map=/build/1st/gnss-sdr-0.0.11=. -fstack-protector-strong -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -fvisibility-inlines-hidden   -Wall -Wextra -pthread 
-std=c++2a -o CMakeFiles/front-end-cal.dir/main.cc.o -c 
/build/1st/gnss-sdr-0.0.11/src/utils/front-end-cal/main.cc
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libgnuradio-iio.so: undefined reference to 
`gr::analog::sig_source::make(double, gr::analog::gr_waveform_t, double, 
double, float, float)'
collect2: error: ld returned 1 exit status


I first saw this in raspbian bullseye, but it's also happening on the Debian reproducible 
builds site, the precise error quoted above was taken from a "reproducible 
builds" build for amd64.

This kind of looks like gnuradio broke ABI and therefore broke gr-iio, but i'm 
not by any means an expert on how different gnuradio bits fit together.

Bug#747362: tuxguitar: java sound api cannot be loaded

[Emmanuel Bourg]

Control: retitle -1 tuxguitar: Java Sound API cannot be loaded with GCJ
Control: tags -1 + wontfix
Control: close -1

The gnu.javax.sound package appears in the stacktrace, so this issue was
with GCJ, and it's gone now.

Bug#940061: ITP: r-bioc-dada2 -- sample inference from amplicon sequencing data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-dada2 -- sample inference from amplicon sequencing data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-dada2
  Version : 1.12.1
  Upstream Author : Benjamin Callahan 
* URL : https://bioconductor.org/packages/dada2/
* License : LGPL-3
  Programming Lang: GNU R
  Description : sample inference from amplicon sequencing data
 The dada2 package contributes to software workflows to interpret
 sequencing data from microbiota - the relative abundance of
 bacterial and/or yeast, typically measured in the gut.
 It infers exact amplicon sequence
 variants (ASVs) from high-throughput amplicon sequencing data,
 replacing the coarser and less accurate OTU clustering approach.
 The dada2 pipeline takes as input demultiplexed fastq files, and
 outputs the sequence variants and their sample-wise abundances
 after removing substitution and chimera errors. Taxonomic
 classification is available via a native implementation of the RDP
 naive Bayesian classifier, and species-level assignment to 16S
 rRNA gene fragments by exact matching.

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

Bug#939339: munin-node: systemd hardening hurts the df plugin

[Stig Sandbeck Mathisen]

 writes:

> yes, there were also a few issues raised and a few questions asked via IRC.
> The difference between executing "munin-run" and deploying the plugin in a 
> real
> environment can be an annoying source of confusion.
> But the hardening directives can be of really good use, since they prevent
> misbehaving or insecure plugins from causing damage.
>
> Thus I am not sure, how we should proceed.
>
> At the moment I see the following options:
> A) make these hardening flags configurable via debconf during
>installation/upgrade
>(I would need to investigate, how systemd units can be configured properly)
> B) disable hardening flags and mention their activation in README.Debian
> C) keep the hardening flags and somehow allow "munin-run" to use the same set
>of hardening flags, that the munin-node service uses.
>(or something along these lines - it feels really complicated)
>
> Any other opinions?

The hardening options in systemd have boolean as well as other values
special for each setting. The ProtectHome= systemd unit parameter also
takes "read-only", which _should_ allow monitoring to check filesystem
usage. See man:systemd.exec(5).

Since the job of munin-node is to do filesystem monitoring as default,
and the /home filesystem is often useful to monitor, I'd suggest
"read-only" as a new value for ProtectHome= in munin-node.service. If it
works. :)

(I'm probably responsible for the current value of ProtectHome= in
munin-node.service, to be honest.)

-- 
Stig Sandbeck Mathisen
Trust the Computer, the Computer is your Friend

Bug#939171: xdeb.desc: split out binary-is-wrong-architecture.desc

[Felix Lechner]

Control: tags -1 + patch

[Copying Lintian maintainers to indicate resolution.]

Hi Aaron,

On Sun, Sep 1, 2019 at 6:17 PM Felix Lechner  wrote:
>
> If the bug remains open, I will send you a patch.

Attached please find a patch that seems to resolve the issue locally.

Another small update was to invoke your check script via the new 'always' facet.

Kind regards
Felix Lechner


lintian-profile-new-layout.patch.xz
Description: application/xz

Bug#940060: asterisk: CVE-2019-15297: AST-2019-004: Crash when negotiating for T.38 with a declined stream

[Salvatore Bonaccorso]

Source: asterisk
Version: 1:16.2.1~dfsg-2
Severity: important
Tags: security upstream
Forwarded: https://issues.asterisk.org/jira/browse/ASTERISK-28495
Control: found -1 1:16.2.1~dfsg-1+deb10u1
Control: found -1 1:16.2.1~dfsg-1

Hi,

The following vulnerability was published for asterisk.

CVE-2019-15297[0]:
| res_pjsip_t38 in Sangoma Asterisk 13.21-cert4, 15.7.3, and 16.5.0
| allows an attacker to trigger a crash by sending a declined stream in
| a response to a T.38 re-invite initiated by Asterisk.


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-15297
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15297
[1] https://issues.asterisk.org/jira/browse/ASTERISK-28495
[2] https://downloads.asterisk.org/pub/security/AST-2019-004.html

Please adjust the affected versions in the BTS as needed.



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

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

Bug#939543: wordpress: 5.2.3 fixes several XSS and other security bugs

[Salvatore Bonaccorso]

Hi!

On Wed, Sep 11, 2019 at 08:44:11PM +1000, Craig Small wrote:
> That took longer than expected but I submitted 7 CVE ID requests into MITRE
> tonight.  I'm having trouble matching the changesets to the vulnerabilities
> (I know 3 of them only) which will make backporting harder.

So it looks all those got assigned:

CVE-2019-16217
CVE-2019-16218
CVE-2019-16219
CVE-2019-16220
CVE-2019-16221
CVE-2019-16222
CVE-2019-16223

Can upstream be conviced in some way to share more information on the
needed isolated fixes?

Regards,
Salvatore

Bug#940059: buster-pu: package publicsuffix/20190904.1802-0+deb10u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian buster.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in buster is attached.

This proposed release is also available at the
"publicsuffix_debian/20190904.1802-0+deb10u1" tag on the "debian/buster" branch 
at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to buster.



../publicsuffix_20190415.1030-1_20190904.1802-0+deb10u1.debdiff.gz
Description: Binary data

Bug#929203: lighttpd: PIDFile= references path below legacy directory /var/run

[Marc Haber]

On Sun, May 19, 2019 at 11:01:21AM +0200, Olaf van der Spek wrote:
> May 19 10:56:32 buster systemd[1]: /lib/systemd/system/lighttpd.service:6: 
> PIDFile= references path below legacy directory /var/run/, updating 
> /var/run/lighttpd.pid → /run/lighttpd.pid; please update the unit file 
> accordingly.

To make things worse, whatever creates this log message doesn't take a
drop-in into account, so simply doing systmctl edit lighttpd and adding
the appropriate new PIDFile line doesn't get rid of the messages :-(

Greetings
Marc

Bug#940058: httpie: CVE-2019-10751

[Salvatore Bonaccorso]

Source: httpie
Version: 0.9.8-2
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerability was published for httpie.

CVE-2019-10751[0]:
| All versions of the HTTPie package prior to version 1.0.3 are
| vulnerable to Open Redirect that allows an attacker to write an
| arbitrary file with supplied filename and content to the current
| directory, by redirecting a request from HTTP to a crafted URL
| pointing to a server in his or hers control.

The issue is demostrable via the poc in [1].

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-10751
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10751
[1] https://snyk.io/vuln/SNYK-PYTHON-HTTPIE-460107

Regards,
Salvatore

Bug#940057: qemu 4.1: qxl driver does not resize display / received empty monitor config

[Stefan Pietsch]

Package: qemu
Version: 1:4.1-1+b1
Severity: normal

QEMU 4.1 has a problem when using the vga qxl driver.

$ qemu-system-x86_64 -machine accel=kvm \
-m 1024 -cdrom grml64-full_2018.12.iso -vga qxl \
-spice port=,disable-ticketing



Connect with the Spice viewer and start Grml in Graphical Mode.

$ remote-viewer spice://127.0.0.1: --spice-debug

Now resize with "xrandr -s 1680x1050".

### remote-viewer debug output ###

(remote-viewer:27616): GSpice-DEBUG: 21:43:36.601: spice-channel.c:2926 test 
cap 0 in 0x1: yes
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.601: spice-util.c:270 
spice_make_scancode:  scancode 28
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.601: spice-util.c:270 
spice_make_scancode: release scancode 28
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.610: channel-cursor.c:542 
cursor-4:0: cursor_handle_reset, init_done: 1
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.610: channel-display.c:1951 
display-2:0: 0: FIXME primary destroy, but is display really disabled?
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.610: spice-widget.c:3046 0:0 
cursor_reset
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.610: channel-cursor.c:542 
cursor-4:0: cursor_handle_reset, init_done: 0
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.610: spice-widget.c:1926 0:0 
focus_out_event
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.611: spice-widget.c:1860 0:0 
leave_event
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.611: spice-widget.c:945 0:0 
ungrab keyboard
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.611: spice-widget.c:1860 0:0 
leave_event
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.611: spice-widget.c:3046 0:0 
cursor_reset
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.611: spice-widget.c:496 0:0 
grab_broken (implicit: 0, keyboard: 1)
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.611: spice-widget.c:498 0:0 
grab_broken (SpiceDisplay::GdkWindow 0x560258aaec60, event->grab_window: (nil))
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.611: spice-widget.c:1536 0:0 
release_keys
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.640: channel-display.c:1909 
surface flags: 1
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.640: channel-display.c:947 
display-2:0: Create primary canvas
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.640: channel-cursor.c:387 
cursor-4:0: set_cursor: flags 1, size 0
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.640: spice-widget.c:300 0:0 
update monitor area
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.640: spice-widget.c:2573 0:0 
update area +0+0 1024x768
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.640: spice-widget.c:2599 0:0 
primary: 1680x1050
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.640: spice-widget.c:1300 0:0 
recalc geom monitor: 0:0, guest +0+0:1024x768, window 1024x768, zoom 1
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.640: spice-widget.c:1890 0:0 
focus_in_event
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.641: spice-channel.c:2926 test 
cap 1 in 0x1052: yes
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.653: spice-widget.c:1845 0:0 
enter_event
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.653: spice-widget.c:867 0:0 grab 
keyboard
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.654: spice-widget.c:1845 0:0 
enter_event
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.657: channel-display.c:1123 
display-2:0: display_handle_mark
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.660: spice-widget.c:2852 0:0 
widget mark: 1, display 0x560258d60680
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.661: decode-glz.c:352 
decode_header: 1680x1050, id 17193, ref 17187
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.670: channel-display.c:1975 
display-2:0: received empty monitor config
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.670: decode-glz.c:352 
decode_header: 1680x1050, id 17194, ref 17189
(remote-viewer:27616): GSpice-DEBUG: 21:43:36.684: decode-glz.c:352 
decode_header: 1680x1050, id 17195, ref 17192

### remote-viewer debug output ###



If you disconnect the Spice viewer and try to reconnect the viewer only shows 
the text "Connected to graphic server".

### remote-viewer debug output ###

(remote-viewer:27738): GSpice-DEBUG: 21:51:40.422: spice-widget.c:300 0:0 
update monitor area
(remote-viewer:27738): GSpice-DEBUG: 21:51:40.422: spice-widget.c:313 0:0 
update monitor: no monitor 0
(remote-viewer:27738): GSpice-DEBUG: 21:51:40.422: spice-channel.c:2926 test 
cap 1 in 0x1052: yes
(remote-viewer:27738): GSpice-DEBUG: 21:51:40.422: spice-widget.c:317 0:0 
waiting until MonitorsConfig is received
(remote-viewer:27738): GSpice-DEBUG: 21:51:40.422: spice-channel.c:2926 test 
cap 1 in 0x1052: yes
(remote-viewer:27738): GSpice-DEBUG: 21:51:40.422: spice-channel.c:1298 
inputs-3:0: channel up, state 3
(remote-viewer:27738): GSpice-DEBUG: 21:51:40.422: channel-base.c:81 main-1:0: 
spice_channel_handle_notify -- warn!!! #0: keyboard channel is insecure
(remote-viewer:27738): GSpice-DEBUG: 21:51:40.429: channel-display.c:1975 
display-2:0: received empty monitor config

Bug#936081: New upstream 0.7.0 available

[Birger Schacht]

Hi,

On 9/11/19 8:16 PM, Guido Günther wrote:
> Hi,
> On Wed, Sep 11, 2019 at 06:27:46PM +0200, Birger Schacht wrote:
>> Hi Guido,
>>
>> I've seen you have already started updating the packge for 0.7.0. If
>> there is anything I can do to help, feel free to say so! I would not now
>> how to handle the soname bump though- the so_version was changed from
>> 3.4.1 to 3.5.1...
> 
> i think checking debian/copyright and  uploading that thing is what's
> left. Since the sonome doesn't change the major version i think we're
> good to go.
> 
>> FYI I've also created a team on tracker (team+swa...@tracker.debian.org)
>> and started to set the maintainer address to the team address. If you
>> want to do that for wlroots to, feel free to do so ;)
> 
> sure. in case you want to handle the above feel free to do that too.
> Cheers,

I've updated d/copyright and made some small adjustments:
[be3aa96] d/control: add libpng-dev to build-depends (for
examples/screencopy.c)
[f972935] d/control: Set maintainer to team address and move Guido to
uploaders
[1f69b85] d/control: Bump Standards-Version

I've also added myself to uploaders, to make lintian happy (because the
changelog entry was done by me).
I can not do the upload though, because I'm not a DM/DD - I guess you,
Guido, or someone else would have to sponsor it ;)

cheers,
Birger

Bug#931855: rpc.rquotad takes 100% CPU

[Mark Hymers]

On Tue, 30, Jul, 2019 at 02:24:23PM +0200, Michael Meskes spoke thus..
> Can you try if this patch fixes the problem? That way we could make
> sure there is not something else at play on your system. If it does, we
> should see if we can get an update into a point release.

Hi Michael,

I've just hit this bug in buster and tested the patch and it works.  I'd
like to prepare an update for stable (as it's already fixed in 4.05 in
unstable), would that be ok?

Thanks,

Mark

-- 
Mark Hymers 


signature.asc
Description: PGP signature

Bug#927939: closed by Timo Aaltonen (fixed in 1.4.1.4-1)

[Salvatore Bonaccorso]

Control: fixed -1 1.4.1.5-1

Hi

For the benefit of other reviewers. This fix was first reverted
upstream as it introoduced regressions. That confused me when you
closed the entry today.

Whilst the commit was applied, it got later on again reverted:

https://pagure.io/389-ds-base/c/f35ad37100ab5915445d6d37f8921dd46f83656e

Ahh, but then it got fixed correctly with

https://pagure.io/389-ds-base/c/f20e982c68a700b5ba2c41e5b6f3cdeb5fcb5fab

So indeed fixed in unstable.

Regards,
Salvatore

Bug#940056: fakeroot does not fake statx()

[Robert Lemmen]

Package: fakeroot
Version: 1.23-1
Severity: normal

Howdie!

we noticed a problem when building rakudo (seed #935290), which turns
out to be a combination of a newer version of libuv, which replaces many
stat() calls with statx() ones, and building under fakeroot. fakeroot
does wrap the stat() calls, so that files of unknown users are treated
as root:root, amongth them /build where the package is being put for
building by pbuilder etc. the rakudo build, a handful of turtles down,
tries to determine whether a directory is writable, which it does
through perl6 and therefore libuv1. Since this is now using statx(), and
since statx() is not wrapped by fakeroot, this returns the actual owner
of these files outside the chroot (uid 1234 in my case), so that check
fails. 

It would be great if fakeroot would also wrap statx() to support these
cases. I guess it is only a matter of time until some other tool starts
using statx() instead of stat(), sio this would not only benfit our own
build.

The bug report report mentioned above has a small statx() wrapper
program (compile with g++ even though it looks like C, it was late),
which shows the problem easily when run under fakeroot:

mkdir foodir
sudo chown 1234:1234 foodir
fakeroot work/statx/st foodir
> statx test against foodir...
> returned 0
> uid is 1234  <- uid as reported by statx()
> stat returned 0
> stat uid is 0<- uid as reported by stat()

thanks  robert

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

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

Versions of packages fakeroot depends on:
ii  libc62.28-10
ii  libfakeroot  1.23-1

fakeroot recommends no packages.

fakeroot suggests no packages.

-- no debconf information

Bug#939339: munin-node: systemd hardening hurts the df plugin

[devel]

Hello,


thank you for your suggestion!


Am Tue, 03 Sep 2019 17:11:55 +0200
schrieb Ferenc Wágner :

> Today I noticed that my /home mount is not graphed by the df plugin
> against my expectations.  After too much debugging I realized that the
> ProtectHome=true setting in /lib/systemd/system/munin-node.service
> causes the problem.  After overriding it, the missing graph reappeared.
> Please consider dropping this directive from the unit file.

yes, there were also a few issues raised and a few questions asked via IRC.
The difference between executing "munin-run" and deploying the plugin in a real
environment can be an annoying source of confusion.
But the hardening directives can be of really good use, since they prevent
misbehaving or insecure plugins from causing damage.

Thus I am not sure, how we should proceed.

At the moment I see the following options:
A) make these hardening flags configurable via debconf during
   installation/upgrade
   (I would need to investigate, how systemd units can be configured properly)
B) disable hardening flags and mention their activation in README.Debian
C) keep the hardening flags and somehow allow "munin-run" to use the same set
   of hardening flags, that the munin-node service uses.
   (or something along these lines - it feels really complicated)

Any other opinions?

Cheers,
Lars

Bug#940019: cups: No more options for remote shared printers

[Brian Potkin]

On Wed 11 Sep 2019 at 10:34:12 +0200, Vincent Danjean wrote:

>   Hi,

Hello Vincent,

Thank you for your report.

>   Since my last upgrade of cups on my laptop, I do not see any options
> for remote printers.

Well, you do. But what you get is unexpected. :)

>  It affects me both at home (where I can access to
> the cups server and can change something if need be) and at work (where
> I do not have any access to the server). Both servers (at home and at
> work) do not change. On my laptop, it worked with cups 2.2.10 (not sure
> with 2.2.12). My home server is running cups 2.2.1-8+deb9u4 (stretch)

The servers are not the problem. The home printer might be, but we will
explore thet at another time.
 
>   At work, the printers are discovered by cups-browsed as they are not
> on the local network and a 'BrowsePoll print.work.domain:631' line
> is required. At home, I've a linux server with cups that talk to a
> local printer through a propriatory driver (Brother DCP-9020CDW printer)
>   I will talk about the situation at home (where I can access the server).

The work situation likely requires a separate bug report. So we will put
it on one side for the present.

> On the server, I see all options provided be the driver:
> server $ lpoptions -l -p brother

I set up a print queue with these Brother DCP-9020CDW drivers by using
'dpkg -i' with the two packages provided. It was automatically named
DCP9020CDW. How did you get the queue name to be "brother"?

> PageSize/Media Size: *A4 Letter Legal Executive A5 A6 B5 JISB5 JISB6 EnvDL 
> EnvC5 Env10 EnvMonarch Br3x5 FanFoldGermanLegal EnvPRC5Rotated Postcard 
> EnvYou4 EnvChou3 210x270mm 195x270mm 184x260mm 197x273mm
> BRDuplex/Two-Sided: DuplexTumble *DuplexNoTumble None
> BRInputSlot/Paper Source: *AutoSelect Tray1 Manual
> BRResolution/Print Quality: *600dpi 600x2400dpi
> BRMonoColor/Color / Mono: *Auto FullColor Mono
> BRMediaType/Media Type: *Plain Thin Thick Thicker BOND Env EnvThick EnvThin 
> Recycled Label Glossy PostCard
> BRColorMatching/Color Mode: *Normal Vivid None
> BRGray/Improve Gray Color: OFF *ON
> BREnhanceBlkPrt/Enhance Black Printing: *OFF ON
> BRTonerSaveMode/Toner Save Mode: *OFF ON
> BRImproveOutput/Improve Print Output: *OFF BRLessPaperCurl BRFixIntensity
> BRSkipBlank/Skip Blank Page: *OFF ON
> BRBrightness/Brightness: -20 -19 -18 -17 -16 -15 -14 -13 -12 -11 -10 -9 -8 -7 
> -6 -5 -4 -3 -2 -1 *0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> BRContrast/Contrast: -20 -19 -18 -17 -16 -15 -14 -13 -12 -11 -10 -9 -8 -7 -6 
> -5 -4 -3 -2 -1 *0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> BRRed/Red: -20 -19 -18 -17 -16 -15 -14 -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 
> -2 -1 *0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> BRGreen/Green: -20 -19 -18 -17 -16 -15 -14 -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 
> -3 -2 -1 *0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> BRBlue/Blue: -20 -19 -18 -17 -16 -15 -14 -13 -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 
> -2 -1 *0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
> BRSaturation/Saturation: -20 -19 -18 -17 -16 -15 -14 -13 -12 -11 -10 -9 -8 -7 
> -6 -5 -4 -3 -2 -1 *0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

I get this too. We agree at this point.
 
> It was the same on my laptop before the new versions of cups.
> But now:
> laptop $ lpoptions -l -p brother
> PageSize/Page Size: Custom.WIDTHxHEIGHT 11x14 11x17 13x19 16x20 16x24 2A 4A 
> 8x10 8x12 A0 A1 A2 A3 *A4 A5 AnsiA AnsiB AnsiC AnsiD AnsiE ArchA ArchB ArchC 
> ArchD ArchE C0 C1 C2 C3 C4 C5 Env10 EnvC5 EnvDL EnvMonarch Executive ISOB0 
> ISOB1 ISOB2 ISOB3 ISOB4 ISOB5 JISB0 JISB1 JISB2 JISB3 JISB4 JISB5 Ledger 
> Legal Letter RA0 RA1 RA2 RA3 RA4 SRA0 SRA1 SRA2 SRA3 SRA4 SuperA SuperB 
> TabloidExtra Tabloid
> Resolution/Output Resolution: 150dpi *300dpi 600dpi 1200dpi 2400dpi

Being "the same" is (I think) part of the issue. It shouldn't have been.
The server is probed over IPP and CUPS generates a PPD for a discovered
queue. This is not the same PPD seen from the server. cups-browsed is
supposed to use the same PPD generator as CUPS (via cups-filters), so
should produce the same PPD. I also get this disparity when cups version
2.2.8-5 is used.

For the moment, I am inclined to see the issue as concerning cups-filters.

> And nothing more.
> I cannot choose the DuplexMode, the gray/color, ...
> These was presented to me in a 'Advanced' tab of the standard cups gtk dialog 
> (for example with evince)
> 
> http://localhost:631/printers/ reports:
> brother   Brother DCP-9020CDW @ serverBrother DCP-9020CDW 
> CUPS, driverless, cups-filters 1.25.5
> 
> At work, we have big canon printers, and I cannot choose the staple mode, ... 
> anymore.
> It is really blocking for me: I have to log (ssh) to another computer
> still in stretch to print my PDF :-(

Possibly a different issue. I am unlikely to treat it here.

> For info:
> 
> laptop $ cat /etc/cups/cups-browsed.conf | egrep -v '^(#| *$)' 
> 

Bug#940053: FWIW, they just pushed out 2019.09.12 which has the fixes

[shirish शिरीष]

Dear Roger,

Please see https://github.com/ytdl-org/youtube-dl/releases/tag/2019.09.12

and specifically this PR
https://github.com/ytdl-org/youtube-dl/commit/bf1317d257d13188601c837c983830355c6203e5

which is part of the temporary solution.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#936081: New upstream 0.7.0 available

[Guido Günther]

Hi,
On Wed, Sep 11, 2019 at 06:27:46PM +0200, Birger Schacht wrote:
> Hi Guido,
> 
> I've seen you have already started updating the packge for 0.7.0. If
> there is anything I can do to help, feel free to say so! I would not now
> how to handle the soname bump though- the so_version was changed from
> 3.4.1 to 3.5.1...

i think checking debian/copyright and  uploading that thing is what's
left. Since the sonome doesn't change the major version i think we're
good to go.

> FYI I've also created a team on tracker (team+swa...@tracker.debian.org)
> and started to set the maintainer address to the team address. If you
> want to do that for wlroots to, feel free to do so ;)

sure. in case you want to handle the above feel free to do that too.
Cheers,
 -- Guido

> 
> cheers,
> Birger
> 

Bug#940043: [git-buildpackage/master] pq: Don't bubble up FileNotFoundException

[Guido Günther]

tag 940043 pending
thanks

Date:   Wed Sep 11 11:00:18 2019 -0700
Author: Guido Günther 
Commit ID: fef81e25b1efeffdfe88d240c70cb7526e8d5c41
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=fef81e25b1efeffdfe88d240c70cb7526e8d5c41
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=fef81e25b1efeffdfe88d240c70cb7526e8d5c41

pq: Don't bubble up FileNotFoundException

Closes: #940043

  

Bug#940055: ruby-asciidoctor-pdf: Please package the latest version (1.5.0~beta.4)

[Boyuan Yang]

Package: ruby-asciidoctor-pdf
Version: 1.5.0~alpha.17.dev-6
Severity: normal
X-Debbugs-CC: kei...@keithp.com

Dear ruby-asciidoctor-pdf maintainer,

Upstream has released some new upstream releases for ruby-asciidoctor-pdf.
Please consider packaging it in Debian.

Thanks,
Boyuan Yang

Bug#940054: comgt FTCBFS: upstream Makefile hard codes cc

[Helmut Grohne]

Source: comgt
Version: 0.32-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

comgt fails to cross build from source, because the upstream Makefile
hard codes the build architecture compiler cc. Please consider applying
the attached patch to make it substitutable.

Helmut
--- comgt-0.32.orig/Makefile
+++ comgt-0.32/Makefile
@@ -71,8 +71,8 @@
 
 
 comgt: comgt.o
-	cc comgt.o $(LDFLAGS) -o comgt
+	$(CC) comgt.o $(LDFLAGS) -o comgt
 
 comgt.o: comgt.c comgt.h
-	cc comgt.c $(CFLAGS) 
+	$(CC) comgt.c $(CFLAGS) 
 

Bug#940053: Please update to a new version as it arrives as websites are failing

[shirish शिरीष]

Package: youtube-dl
Version: 2019.09.01-1
Severity: normal

Dear Maintainer,
Seems youtube.com has changed their behavior again and hence sites are
failing. From yesterday haven't been able to download a single video.
You can see a litany of complaints at
https://github.com/ytdl-org/youtube-dl/issues on it. Please do it as
soon as you can.

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

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

Versions of packages youtube-dl depends on:
ii  python33.7.3-1
ii  python3-pkg-resources  41.2.0-1

Versions of packages youtube-dl recommends:
ii  ca-certificates  20190110
ii  curl 7.65.3-1
ii  ffmpeg   7:4.1.4-1+b2
ii  mpv  0.29.1-1
ii  phantomjs2.1.1+dfsg-2+b1
ii  python3-pyxattr  0.6.1-1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2
ii  wget 1.20.3-1+b1

youtube-dl suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#940052: onscripter FTCBFS: uses build architecture build tools

[Helmut Grohne]

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

onscripter fails to cross build from source, because it uses build
architecture build tools. In debian/rules, pkg-config is hard coded.
Seeding pkg-config from dpkg's buildtools.mk is the common way to fix
that. Please consider applying the attached patch.

Helmut
diff --minimal -Nru onscripter-20190819/debian/changelog 
onscripter-20190819/debian/changelog
--- onscripter-20190819/debian/changelog2019-08-20 11:01:43.0 
+0200
+++ onscripter-20190819/debian/changelog2019-09-11 19:04:38.0 
+0200
@@ -1,3 +1,10 @@
+onscripter (20190819-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Seed build tools from dpkg's buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 11 Sep 2019 19:04:38 +0200
+
 onscripter (20190819-1) unstable; urgency=low
 
   [ Helmut Grohne  ]
diff --minimal -Nru onscripter-20190819/debian/rules 
onscripter-20190819/debian/rules
--- onscripter-20190819/debian/rules2019-08-20 11:01:43.0 +0200
+++ onscripter-20190819/debian/rules2019-09-11 19:04:37.0 +0200
@@ -64,8 +64,8 @@
 
 # Use lua if it is installed
 ifneq (,$(DEB_LUA_FLAG))
-CONFINCS += `pkg-config --cflags lua5.2`
-CONFLIBS += `pkg-config --libs lua5.2`
+CONFINCS += `$(PKG_CONFIG) --cflags lua5.2`
+CONFLIBS += `$(PKG_CONFIG) --libs lua5.2`
 CONFDEFS += -DUSE_LUA
 CONFEXT_OBJS += LUAHandler.o
 endif

Bug#913061: systemd: stop shipping /bin/systemd

[Ansgar]

Control: clone -1 -2 -3
Control: reassign -2 initramfs-tools
Control: reassign -3 dracut
Control: retitle -2 initramfs-tools: fallback to /lib/systemd/systemd if 
init=/bin/systemd
Control: retitle -3 dracut: fallback to /lib/systemd/systemd if 
init=/bin/systemd
Control: block -1 by -2
Control: block -1 by -3

Dear initramfs maintainers,

would it be possible to add a fallback to try /lib/systemd/systemd if
the user provided init=/bin/systemd and the file no longer exists?

I would like systemd to stop shipping the /bin/systemd symlink as this
should not be run by users, however it was suggested to use
init=/bin/systemd for testing purposes in the past (see below).  So just
removing the symlink might make some systems unbootable.

Ansgar

Michael Biebl writes:
>> Running `systemd` in an interactive shell is not a good idea.  To
>> avoid this happening by accident, the /bin/systemd ->
>> /lib/systemd/systemd symlink should no longer be shipped.
>> 
>> Documentation such as [1] still suggests to use `init=/bin/systemd`
>> which would result in non-bootable systems.  (The initramfs might be
>> able to catch this and run /lib/systemd/systemd instead in most cases
>> as unbootable systems are not nice.)
>
> Continuing to ship the symlink is kinda cheap and I'm indeed a bit
> worried that this change might cause unbootable systems.
> We could either add some maintscript code to abort the upgrade if a
> installation is detected that uses init=/bin/systemd (e.g. by checking
> /proc/cmdline).
> But your initramfs idea might indeed by nicer. The initramfs should
> probably output a big, fat warning if it is found that the old
> /bin/systemd symlink is used, so people will migrate to the "new"
> location eventually.
>
> Could you file a bug report against initramfs-tools and block this one
> with it? I guess attaching a working patch for initramfs-tools will
> speed up the process :-)

Done so now, also for dracut.

Bug#940049: ITP: pd.build-cmake-module -- Pure Data CMake Module

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU) 

* Package name: pd.build-cmake-module
  Version : 0.1
  Upstream Author : Pierre Guillot
* URL : https://github.com/pierreguillot/pd.build
* License : GPL-3
  Programming Lang: CMake
  Description : Pure Data CMake Module

 Pure Data (also known as Pd) is a real-time graphical programming environment
 for audio and graphics processing.
 It can be easily extended with so called 'externals'
 .
 This package contains a CMake Module for building such externals.

This package is part of the ongoing attempt to package the Pure Data microcosm
for Debian (and a prerequisite of the update of the src:jsusfx package).
I intend to maintain the package under the multimedia-team umbrella.

Bug#776833: diffpdf: Homepage field incorrect or not relevant anymore?

[Martin Kimmerle]

On Mon, 02 Feb 2015 11:13:49 +0100 Johannes Schauer  
> I visited http://www.qtrac.eu/diffpdf.html, the URL in the Homepage

field and found a commercial, proprietary tool for Windows only.


Correct, but there's still a website for the open source edition:
http://www.qtrac.eu/diffpdf-foss.html

FWIW, I've created a list of DiffPDF-FOSS forks:
https://gitlab.com/snippets/1894101
would be great if those could be merged somehow..

cheers, Martin

Bug#917238: NMU ongoing

[Gianfranco Costamagna]

Hello, I uploaded the following NMU in deferred/5

G.
diff -Nru ndpi-2.6/debian/changelog ndpi-2.6/debian/changelog
--- ndpi-2.6/debian/changelog   2019-01-16 10:48:34.0 +0100
+++ ndpi-2.6/debian/changelog   2019-09-11 18:37:11.0 +0200
@@ -1,3 +1,16 @@
+ndpi (2.6-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * debian/patches/662.patch:
+- make the build reproducible (Closes: #929609)
+  * debian/patches/aea91781aa476589361e16ece6aa6c10102e0f33.patch:
+- fix armhf failure with upstream patch (Closes: #917238)
+  * debian/patches/cross.patch:
+- Patch from Helmut Grohne  to fix FTCBFS on
+  cross-builds (Closes: #939286)
+
+ -- Gianfranco Costamagna   Wed, 11 Sep 2019 
18:37:11 +0200
+
 ndpi (2.6-3) unstable; urgency=medium
 
   * Add packet-direction.patch and quic.patch to fix big-endian-related bugs.
diff -Nru ndpi-2.6/debian/patches/662.patch ndpi-2.6/debian/patches/662.patch
--- ndpi-2.6/debian/patches/662.patch   1970-01-01 01:00:00.0 +0100
+++ ndpi-2.6/debian/patches/662.patch   2019-09-11 18:37:11.0 +0200
@@ -0,0 +1,27 @@
+From e91123e17a6ebe2cb1f718aa3e44edb10b707779 Mon Sep 17 00:00:00 2001
+From: "Bernhard M. Wiedemann" 
+Date: Thu, 24 Jan 2019 14:21:06 +0100
+Subject: [PATCH] Use ChangeLog date instead of build date
+
+in order to make builds reproducible.
+See https://reproducible-builds.org/ for why this is good.
+
+This date call works with GNU date and BSD date.
+Also use UTC/gmtime to be independent of timezone.
+---
+ configure.seed | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.seed b/configure.seed
+index 1aa68f17..006e6d97 100644
+--- a/configure.seed
 b/configure.seed
+@@ -30,7 +30,7 @@ if test -d ".git"; then :
+  GIT_RELEASE="${PACKAGE_VERSION}-${GIT_NUM}-${GIT_TAG}"
+ else
+  GIT_RELEASE="${PACKAGE_VERSION}"
+- GIT_DATE=`date`
++ GIT_DATE=`date -u -r CHANGELOG.md`
+ fi
+ 
+ AC_DEFINE_UNQUOTED(NDPI_GIT_RELEASE, "${GIT_RELEASE}", [GIT Release])
diff -Nru 
ndpi-2.6/debian/patches/aea91781aa476589361e16ece6aa6c10102e0f33.patch 
ndpi-2.6/debian/patches/aea91781aa476589361e16ece6aa6c10102e0f33.patch
--- ndpi-2.6/debian/patches/aea91781aa476589361e16ece6aa6c10102e0f33.patch  
1970-01-01 01:00:00.0 +0100
+++ ndpi-2.6/debian/patches/aea91781aa476589361e16ece6aa6c10102e0f33.patch  
2019-09-11 18:37:11.0 +0200
@@ -0,0 +1,79 @@
+From aea91781aa476589361e16ece6aa6c10102e0f33 Mon Sep 17 00:00:00 2001
+From: emanuele-f 
+Date: Thu, 29 Aug 2019 14:50:17 +0200
+Subject: [PATCH] Fix alignment issue on IPv6 structs
+
+---
+ src/include/ndpi_define.h.in   |  2 +-
+ src/include/ndpi_typedefs.h| 11 +++
+ src/lib/protocols/mdns_proto.c |  5 +++--
+ 3 files changed, 11 insertions(+), 7 deletions(-)
+
+diff --git a/src/include/ndpi_define.h.in b/src/include/ndpi_define.h.in
+index 4d269607..ce4c4cc6 100644
+--- a/src/include/ndpi_define.h.in
 b/src/include/ndpi_define.h.in
+@@ -250,7 +250,7 @@
+ 
+ /** macro to compare 2 IPv6 addresses with each other to identify the 
"smaller" IPv6 address  */
+ #define NDPI_COMPARE_IPV6_ADDRESS_STRUCTS(x,y)  \
+-  u_int64_t *)(x))[0]) < (((u_int64_t *)(y))[0]) || ( (((u_int64_t 
*)(x))[0]) == (((u_int64_t *)(y))[0]) && (((u_int64_t *)(x))[1]) < (((u_int64_t 
*)(y))[1])) )
++  ((x.u6_addr.u6_addr64[0] < y.u6_addr.u6_addr64[0]) || 
((x.u6_addr.u6_addr64[0] == y.u6_addr.u6_addr64[0]) && (x.u6_addr.u6_addr64[1] 
< y.u6_addr.u6_addr64[1])))
+ 
+ #define NDPI_NUM_BITS  512
+ 
+diff --git a/src/include/ndpi_typedefs.h b/src/include/ndpi_typedefs.h
+index 0db1ccf9..4e231434 100644
+--- a/src/include/ndpi_typedefs.h
 b/src/include/ndpi_typedefs.h
+@@ -250,27 +250,30 @@ struct ndpi_iphdr {
+ /* +++ IPv6 header +++ */
+ /* rfc3542 */
+ 
++PACK_ON
+ struct ndpi_in6_addr {
+   union {
+ u_int8_t   u6_addr8[16];
+ u_int16_t  u6_addr16[8];
+ u_int32_t  u6_addr32[4];
++u_int64_t  u6_addr64[2];
+   } u6_addr;  /* 128-bit IP6 address */
+-};
++} PACK_OFF;
+ 
++PACK_ON
+ struct ndpi_ip6_hdrctl {
+   u_int32_t ip6_un1_flow;
+   u_int16_t ip6_un1_plen;
+   u_int8_t ip6_un1_nxt;
+   u_int8_t ip6_un1_hlim;
+-};
++} PACK_OFF;
+ 
+-/* PACK_ON */
++PACK_ON
+ struct ndpi_ipv6hdr {
+   struct ndpi_ip6_hdrctl ip6_hdr;
+   struct ndpi_in6_addr ip6_src;
+   struct ndpi_in6_addr ip6_dst;
+-} /* PACK_OFF */;
++} PACK_OFF;
+ 
+ /* +++ TCP header +++ */
+ 
+diff --git a/src/lib/protocols/mdns_proto.c b/src/lib/protocols/mdns_proto.c
+index 75eab720..388376e1 100644
+--- a/src/lib/protocols/mdns_proto.c
 b/src/lib/protocols/mdns_proto.c
+@@ -121,8 +121,9 @@ void ndpi_search_mdns(struct ndpi_detection_module_struct 
*ndpi_struct, struct n
+   }
+ #ifdef NDPI_DETECTION_SUPPORT_IPV6
+   if(packet->iphv6 != NULL) {
+-  const u_int32_t *daddr = packet->iphv6->ip6_dst.u6_addr.u6_addr32;
+-  if(daddr[0] == htonl(0xff02) 

Bug#936081: New upstream 0.7.0 available

[Birger Schacht]

Hi Guido,

I've seen you have already started updating the packge for 0.7.0. If
there is anything I can do to help, feel free to say so! I would not now
how to handle the soname bump though- the so_version was changed from
3.4.1 to 3.5.1...

FYI I've also created a team on tracker (team+swa...@tracker.debian.org)
and started to set the maintainer address to the team address. If you
want to do that for wlroots to, feel free to do so ;)

cheers,
Birger

Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1

[Dmitry Bogatov]

control: severity -1 +normal

[2019-09-10 10:21] Jonathan Wiltshire 
> >> The x.y there was a remnant from Debian sarge times.
> > 
> > Up until squeeze I have seen it show x.y.z, then from wheezy to
> > stretch I see only x.y, but it does seem new behaviour in buster to
> > only show x.
> > 
> > $ ansible '*' -i inventories/testing -a 'lsb_release -d' | grep ^Descr | 
> > sort -u
> > Description:Debian GNU/Linux 10 (buster)
> > Description:Debian GNU/Linux 8.11 (jessie)
> > Description:Debian GNU/Linux 9.10 (stretch)
>
> This stems from lsb_release switching to reading the cross-distro
> standard file, /usr/lib/os-release:
>
> | $ cat /etc/debian_version
> | 10.1
> | $ cat /usr/lib/os-release
> | PRETTY_NAME="Debian GNU/Linux 10 (buster)"
> | NAME="Debian GNU/Linux"
> | VERSION_ID="10"
> | VERSION="10 (buster)"

As pointed by maintainer of base-files, this format of
/usr/lib/os-release is with us for some time (just checked on stretch
box).

In theory, I can revert #914287, but is it good thing? Actually, I fail
to see the whole point of `lsb_release` command. You can't squash all
information in your /etc/apt/sources.list into two digits.

This said, I feel current behaviour more logical. LSB pretends to
provide cross-distributions interface, so reading /usr/lib/os-release
feels more natural than /etc/debian_release.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#935607: lintian: classify "Starting $DESC" in init.d scripts

[Dmitry Bogatov]

control: tags -1 -moreinfo

[2019-09-08 21:26] "Chris Lamb" 
> > unwanted and to be fixed.
>
> ... but, unless I'm missing something you can surely do that now
> almost trivially using codesearch.debian.net and certainly much
> quicker, independetly and with less hassle than introducing two new
> Lintian tags, etc.
>
> I thus suggest you do that and come back to this bug when you/we have
> a concrete implementation plan.

I should have thought about it myself. Codesearch gives following
result:

 1. search for literal `Starting $DESC' gives three pages of init
scripts. Majority (but not overwhelming, around 2/3) of them do
/not/ check for $VERBOSE.

Not very representative, given there is ~1300 services in Debian.

 2. search for `log_daemon_msg "Starting' gives 85 pages, with around 2/3
(eyeball estimate) not checking for $VERBOSE. This search covers 850
init scripts, which is rather good part.

 3. search for literal `"Starting ' gives hundred of pages, most of them
false-positive (logging in C code).

Not unanimous, but I believe that *checking* for $VERBOSE should be
marked as deprecated.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#918538: [Pkg-freeipa-devel] Bug#918538: Please fully switch to python3

[Timo Aaltonen]

On 11.9.2019 19.14, Laurent Bigonville wrote:
> On 7/01/19 13:02, Timo Aaltonen wrote:
>> On 7.1.2019 11.14, Laurent Bigonville wrote:
>>> Source: dogtag-pki
>>> Version: 10.6.8-2
>>> Severity: normal
>>>
>>> Hi,
>>>
>>> Are there any reasons why part of the generated packages are still
>>> using python2?
>> Yes, py2 version of dogtag is needed for freeipa, which can't switch
>> over to py3 before everything it depends on is ported, and the last
>> remaining bit is samba (which then needs talloc ported)
>>
> FTR samba has been ported to python3 and uploaded in unstable yesterday

cool, I noticed that experimental got it recently, and uploaded freeipa
there (got through NEW today), so now I can sort things out in sid.


-- 
t

Bug#736681:

[Boris Verkhovskiy]

I put it here https://salsa.debian.org/boris-guest/fonts-source-code-pro

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

[Reinhard Tartler]

On 9/11/19 12:51 AM, Dmitry Smirnov wrote:
> What's holding this back? Package looks good and builds successfully in 
> "experimental". Shall we upload please?

containers-storage was held up in NEW for 5 months. In the mean time, several
new upstream versions have been released for both packages. I've just uploaded
the latest upstream version of -storage to unstable, next step is to update 
-image
and get it to unstable.

Dmitry, I plan to work on that later this week, but I wouldn't be offended if 
you
would beat me to that version update and upload to unstable either ;-)

-rt

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

[Reinhard Tartler]

On 9/11/19 12:09 AM, Dmitry Smirnov wrote:
> 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 for the offer, I've just uploaded your changes, along with a new 
upstream version, to unstable.

-rt

Bug#918538: [Pkg-freeipa-devel] Bug#918538: Please fully switch to python3

[Laurent Bigonville]

On 7/01/19 13:02, Timo Aaltonen wrote:

On 7.1.2019 11.14, Laurent Bigonville wrote:

Source: dogtag-pki
Version: 10.6.8-2
Severity: normal

Hi,

Are there any reasons why part of the generated packages are still
using python2?

Yes, py2 version of dogtag is needed for freeipa, which can't switch
over to py3 before everything it depends on is ported, and the last
remaining bit is samba (which then needs talloc ported)


FTR samba has been ported to python3 and uploaded in unstable yesterday

Bug#940048: nagios-plugins-contrib: debsecan in the "recommends" should be moved to "suggests"

[Gabriel Filion]

Package: nagios-plugins-contrib
Version: 24.20190301
Severity: normal

Hi,

Ever since the package version in buster, debsecan gets installed
automatically when you let "recommends" install.
It also means that it gets installed automatically during a dist-upgrade to
buster.

This means that root starts receiving emails daily from that tool even though
one is not using debsecan or expecting to use check_debsecan.

I would argue that because of those automatic emails getting sent out by
default, debsecan should be moved out to the "suggests" section of this
package.

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

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

nagios-plugins-contrib depends on no packages.

Versions of packages nagios-plugins-contrib recommends:
ii  bind9-host 1:9.11.5.P4+dfsg-5
ii  binutils   2.31.1-16
ii  curl   7.64.0-4
pn  debsecan   
ii  file   1:5.35-4
pn  freeipmi-tools 
ii  libc6  2.28-10
pn  libdata-validate-domain-perl   
pn  libdata-validate-ip-perl   
ii  libdate-manip-perl 6.76-1
pn  libdbd-mysql-perl  
ii  libio-socket-ssl-perl  2.060-3
ii  libipc-run-perl20180523.0-1
ii  liblocale-gettext-perl 1.07-3+b4
pn  liblwp-useragent-determined-perl   
pn  libmail-imapclient-perl
pn  libmemcached11 
pn  libmemcachedutil2  
pn  libmonitoring-plugin-perl | libnagios-plugin-perl  
pn  libnet-cups-perl   
ii  libnet-dns-perl1.19-1
ii  libnet-dns-sec-perl1.11-1
ii  libnet-smtp-ssl-perl   1.04-1
pn  libnet-smtp-tls-perl   
pn  libnet-smtpauth-perl   
pn  libnet-snmp-perl   
ii  libnet-ssleay-perl 1.85-2+b1
ii  libreadonly-perl   2.050-1
pn  libredis-perl  
ii  libsocket-perl 2.029-1
ii  libtimedate-perl   2.3000-2
pn  libvarnishapi2 
pn  libwebinject-perl  
ii  libxml-simple-perl 2.25-1
pn  libyaml-syck-perl  
ii  lsof   4.91+dfsg-1
pn  nagios-plugins-basic   
ii  openssl1.1.1c-1
ii  perl   5.28.1-6
ii  python 2.7.16-1
pn  python-pymongo 
ii  ruby   1:2.5.1
ii  snmp   5.7.3+dfsg-5
ii  whois  5.4.3

Versions of packages nagios-plugins-contrib suggests:
pn  backuppc   
pn  cciss-vol-status   
pn  expect 
ii  libsys-virt-perl   5.0.0-1
pn  moreutils  
pn  mpt-status 
pn  nagios-plugin-check-multi  
pn  percona-toolkit
pn  perl-doc   
ii  python2.7  2.7.16-2
pn  smstools   

Bug#736681:

[Boris Verkhovskiy]

I wrote a Debian package for this font. What is the correct way to submit it?

Bug#908088: xfce4-panel: systray icon background corrupt after upgrade to GTK 3.24 if display compositing disabled

[Kevin Locke]

On Sun, 2018-09-09 at 11:10 +1200, Ben Caradoc-Davies wrote:
> On 08/09/2018 16:52, Michael Biebl wrote:
>> This was indeed tested with compositing enabled.
>> So a GTK 3.24 / compositing related problem?
> 
> It is starting to look like it is. Is this the right package for this bug or
> should I reassign it to another package? gtk+3.0, perhaps? The bug is not
> limited to just nm-applet.

I just encountered this issue as well.  It is being tracked by XFCE at
https://bugzilla.xfce.org/show_bug.cgi?id=14577  It may be a
regression of https://gitlab.gnome.org/GNOME/gtk/issues/1280 that
occurred in GTK sometime between 3.22.30 and 3.24.8.

Cheers,
Kevin

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

[David Raison]

On 11/09/2019 17:30, Daniel Kahn Gillmor wrote:
>
> It sounds to me like you and David are saying this report is specific to
> an interaction with 4.19.0-5 and wireguard 0.0.20190905-1, not that the
> problem has to do with a generic upgrade path.
>
> But hm, maybe the 4.19.0-5 ABI wasn't actually stable? do either of you
> (Matthew or David) know what version of 4.19.0-5 was actually running on
> your system, vs. what version of linux-headers-4.19.0-5 you had
> installed when it was built?  That would be a useful datapoint.


I have these. IMHO they haven't changed since:

root@mazer:~# apt-cache policy linux-headers-4.19.0-5-amd64
linux-headers-4.19.0-5-amd64:
  Installed: 4.19.37-5+deb10u2
  Candidate: 4.19.37-5+deb10u2
  Version table:
 *** 4.19.37-5+deb10u2 990
    990 http://security.debian.org buster/updates/main amd64 Packages
    100 /var/lib/dpkg/status

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

[Daniel Kahn Gillmor]

Over on https://bugs.debian.org/939845, On Wed 2019-09-11 00:26:18 -0400, 
Matthew Gabeler-Lee wrote:
> 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!

i totally agree that this is bad.  Please see
https://bugs.debian.org/913446 for the discussion Fabian (in cc) and i
had around trying to make this robust.  Sorry that we haven't succeeded
in avoiding all the sharp edges, hopefully we can get the particular
breakage figured out.

Note that if you don't want any attempt to reload the module, you can
always just install wireguard-dkms and wireguard-tools directly, and
leave the wireguard metapackage uninstalled.

Regards,

   --dkg


signature.asc
Description: PGP signature

Bug#940034: elogind and the release team block

[Adam Borowski]

On Wed, Sep 11, 2019 at 09:15:58AM -0400, Sam Hartman wrote:
> I reached out to jcristau to talk about his block hint.
> Based on our IRC discussion, it sounds like he was having trouble
> bringing himself to remove the hint presumably because he doesn't think
> the broader issue was being dealt with.

> The systemd maintainers are telling you that you need to provide
> libpam-systemd.

We _did_ use libpam-systemd in the past.  This code was working and tested,
by January 2018 (using consolekit not elogind by then), then a different
version (with elogind), well-tested in Devuan then finally submitted in
November 2018.  The difference is the point the alternative happens at:

PROGRAM -> policykit -> libpam-XXX -> logind

A)
PROGRAM -> policykit-systemd -> libpam-systemd -> systemd
|
`> policykit-elogind -> libpam-elogind -> elogind

B)
PROGRAM -> policykit-systemd -> libpam-systemd -> systemd
 |
 `> libpam-elogind -> elogind

C)
PROGRAM -> policykit-systemd -> libpam-systemd -> systemd
   |
   `> elogind

The Jan 2018 version used A; the Nov 2018 version used C.  Another debated
option was B with dlopen.  Finally (shortly before Buster freeze), it was
requested to make libelogind fully ABI-compatible with libsystemd -- which
elogind's upstream helped implement, but that version was not allowed into
Buster.  And now, we have that replacement problem.

Thus... which way do you want?

> Actually, they would prefer that you create an elogind that mirrors
> enough of the interfaces that you can just use libpam-systemd.  You said
> that would not work, explaining that elogind for example doesn't have a
> concept of slices.  You never clearly articulated why it couldn't
> emulate slices enough to pacify libpam-systemd.  I don't know if it is
> just that work hasn't been done or if it would be a bad idea for some
> reason.

Making elogind implement every single feature of systemd would effectively
make it systemd.  That's not the point.

If I had infinite tuits, I'd implement a clean unix-logind that stubs the
API to good old POSIX functionality -- if you type "who" on a 1990s' system,
you'll already get the same thing the logind idea reimplements.  Unlike
elogind which is a trimmed copy of systemd, that'd make slices completely
out of question.  Same applies to any logind for non-Linux or non-GNU.

I'd say we want the stubs to be as lean as possible (for simplicity, less
moving parts, smaller attack surface, etc), rather than to implement every
single add-on.  If I wanted systemd, I know where to find it (although it
doesn't even boot on my main desktop).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

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

[Daniel Kahn Gillmor]

Control: tags 939845 + moreinfo

On Wed 2019-09-11 00:33:19 -0400, Matthew Gabeler-Lee wrote:
> 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.

IIUC, dkms should build different modules for different kernel ABIs.  it
won't try to install the 4.19.0-6 module into the 4.19.0-5 kernel.

It sounds to me like you and David are saying this report is specific to
an interaction with 4.19.0-5 and wireguard 0.0.20190905-1, not that the
problem has to do with a generic upgrade path.

But hm, maybe the 4.19.0-5 ABI wasn't actually stable? do either of you
(Matthew or David) know what version of 4.19.0-5 was actually running on
your system, vs. what version of linux-headers-4.19.0-5 you had
installed when it was built?  That would be a useful datapoint.

it looks like there were 8 different debian releases that claim this
ABI:

https://snapshot.debian.org/binary/linux-image-4.19.0-5-amd64/
https://snapshot.debian.org/binary/linux-headers-4.19.0-5-amd64/

If anyone has time to dig further, it would be great to try to replicate
this problem in a minimalist VM and report back which versions seem to
tickle the issue.

 --dkg


signature.asc
Description: PGP signature

Bug#940047: gdm_shell in remote window will make application windows black

[Dag Nygren]

Package: gnome-shell
Version: 3.30.2-9 (Debian 10)

Starting gnome_shell to a remote X window server will
blacken out any application window displayed in the server.
The same will also happen for any application invoked from
the gnome_shell session

Screenshots attached of the problem attached,

Steps to reproduce:
1. Start remote X-server with TCP access enabled
2. Go to machine running Debian 10 (fully default install)
3. set DISPLAY variable to point to remote server
4. Run xterm
   (screenshot 1)
5. Start gdm_shell and the xterm window will be blacked out
   (screenshot 2)

This problem appeared in an installation using XDMCP and GDM3
protocol remote terminals and worked fine with Debian 9

I traced it down to gnome_shell using a plain Xorg server
just to simplify debugging the problem

Best Regards

-- 
Dag Nygren   email: d...@newtech.fi
Oy Espoon NewTech Ab phone: +358 9 8024910
Träsktorpet 3   Mobile: +358 400 426312
02360 ESBO
FINLAND

Bug#940046: elpa-org: fails to autoload orgstruct-mode

[David Bremner]

Package: elpa-org
Version: 9.2.3+dfsg-1
Severity: normal

1) emacs -q
2) M-x elpa-org

result:

command-execute: Autoloading file 
/usr/share/emacs/site-lisp/elpa/org-9.2.3/org.elc failed to define function 
orgstruct-mode



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

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

Versions of packages elpa-org depends on:
ii  elpa-htmlize1.54-3
ii  emacsen-common  3.0.4

Versions of packages elpa-org recommends:
ii  emacs  1:26.1+1-3.3
ii  emacs-gtk [emacs]  1:26.1+1-3.3

Versions of packages elpa-org suggests:
pn  ditaa  
pn  org-mode-doc   
ii  texinfo6.6.0.dfsg.1-2
ii  texlive-fonts-recommended  2019.20190830-1
ii  texlive-latex-extra2019.20190830-1

-- no debconf information

Bug#940034: elogind and the release team block

[Sam Hartman]

> "Adam" == Adam Borowski  writes:

Adam> On Wed, Sep 11, 2019 at 09:15:58AM -0400, Sam Hartman wrote:
>> I reached out to jcristau to talk about his block hint.  Based on
>> our IRC discussion, it sounds like he was having trouble bringing
>> himself to remove the hint presumably because he doesn't think
>> the broader issue was being dealt with.

>> The systemd maintainers are telling you that you need to provide
>> libpam-systemd.

Adam> We _did_ use libpam-systemd in the past.  This code was
Adam> working and tested, by January 2018 (using consolekit not
Adam> elogind by then), then a different version (with elogind),
Adam> well-tested in Devuan then finally submitted in November 2018.
Adam> The difference is the point the alternative happens at:

As Mark pointed out I meant libsystemd0.
That is, to make the convergance point the dbus APIs etc.

--Sam

Bug#940045: systemd mount command for overlayfs seems incorrect

[Paul Thomas]

Package: systemd
Version: 241-5
Severity: normal

We're trying to create a home.mount file for mounting an overlayfs.
The contents of the file is here:
 [Unit]
 Description=Mount home overlay
 After=mkdirs.service
 Before=local-fs.target

 [Mount]
 Where=/home
 What=overlay
 Type=ovarlay
 Options=lowerdir=/home,upperdir=/tmp/home,workdir=/tmp/home_work

systemd then tries to execute this command:
 /bin/mount overlay /home -t ovarlay -o
lowerdir=/home,upperdir=/tmp/home,workdir=/tmp/home_work
This command fails, it also fails when I try to execute this manually as well.

The correct command should be:
 mount -t overlay overlay -o
lowerdir=/home,upperdir=/tmp/home,workdir=/tmp/home_work /home

Other fs types like tmpfs seem to be fine.

-- Package-specific info:

-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.2.0-rt1-00011-g939b52f8ff17 (SMP w/4 CPU cores; PREEMPT)
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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-4
ii  libapparmor1 2.13.2-10
ii  libaudit11:2.8.4-3
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.1.0-5
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.7-4
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-4
ii  libkmod2 26-1
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.3.1-5
ii  libseccomp2  2.3.3-4
ii  libselinux1  2.8-1+b1
ii  libsystemd0  241-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.16-1
ii  libpam-systemd  241-5

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
pn  initramfs-tools  
ii  udev 241-5

-- no debconf information

Bug#932003: ITP: mypyc -- Mypy to Python C Extension Compile

[Andrej Shadura]

On 11/09/2019 16:00, Michael Crusoe wrote:
> Thanks Andrej!
> 
> I recently learned that mypyc is being rolled into the main mypy package
> upstream, so I'm holding off for the next release of mypy

Thanks for letting me know. When that happens, ping me if you need a
review or something.

Meanwhile, I have prepared a merge request to provide better manpages
for mypy: https://salsa.debian.org/med-team/mypy/merge_requests/1

Please consider to merge it if you’re not unhappy with the way I do it :)

-- 
Cheers,
  Andrej

Bug#939181: [Help] Re: Bug#939181: cycle: Python2 removal in sid/bullseye

[Andrey Rahmatullin]

On Wed, Sep 11, 2019 at 04:12:34PM +0200, Andreas Tille wrote:
> Control: tags -1 help
> 
> On Wed, Sep 11, 2019 at 09:33:54AM -0300, Antonio Terceiro wrote:
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > ~[100]$ cycle
> >   File "/usr/bin/cycle", line 29
> > if lang_find:
> > ^
> > TabError: inconsistent use of tabs and spaces in indentation
> 
> Argh.  That's fixed via autopep8 in Git[1] now.  However, when calling
> cycle I get
> 
> $ cycle
> Traceback (most recent call last):
>   File "/usr/bin/cycle", line 12, in 
> from dialogs import *
>   File "/usr/share/cycle/dialogs.py", line 8, in 
> from cal_year import cycle, Val
>   File "/usr/share/cycle/cal_year.py", line 9, in 
> from dialogs import Note_Dlg
> ImportError: cannot import name 'Note_Dlg' from 'dialogs' 
> (/usr/share/cycle/dialogs.py)
There are circular imports in the code so you most likely broke that by
reordering imports in various files.
"from cal_year import *; from dialogs import *" works, the reverse
doesn't, so the /usr/bin/cycle code is definitely problematic, not sure
about other changes.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#940044: gimp: fails to open file

[jaume mila]

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

Dear Maintainer,

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

   * What led up to the situation? everytime I open a file.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? this happens after I upgraded the OS.
   * What was the outcome of this action? program crashes and quits.
   * What outcome did you expect instead? opening the file for edition.

-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2019.4
Codename:   kali-rolling
Architecture: x86_64

Kernel: Linux 5.2.0-kali2-amd64 (SMP w/4 CPU cores)
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.6.1-2
ii  libheif1 1.5.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.0-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-5+b1
ii  librsvg2-2   2.44.14-1
ii  libstdc++6   9.2.1-4
ii  libtiff5 4.0.10+git190818-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-3.1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gimp-python   
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information

-- attached bug report below

```
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 13143 - Thread 13143 #

[New LWP 13144]
[New LWP 13145]
[New LWP 13146]
[New LWP 13147]

Bug#932003: ITP: mypyc -- Mypy to Python C Extension Compile

[Michael Crusoe]

Thanks Andrej!

I recently learned that mypyc is being rolled into the main mypy package
upstream, so I'm holding off for the next release of mypy

--
Michael R. Crusoe
Co-founder & Lead,
Common Workflow Language project
m...@commonwl.org

On Wed, Sep 11, 2019, 21:40 Andrej Shadura 
wrote:

> Hi,
>
> On Sat, 13 Jul 2019 18:29:45 +0200 "Michael R. Crusoe"
>  wrote:
> > Package: wnpp
> > Severity: wishlist
> >
> > Subject: ITP: mypyc -- Mypy to Python C Extension Compile
> > Package: wnpp
> > Owner: Michael R. Crusoe 
> > Severity: wishlist
> >
> > * Package name: mypyc
> >   Version : 0.0.git.20190713T1002.833151a+ds1
> >   Upstream Author : Copyright: © 2017-2018 Jukka Lehtosalo and
> contributors
> > * URL : http://www.mypy-lang.org/
> > * License : Expat
> >   Programming Lang: C
> >   Description : Mypy to Python C Extension Compile
> >  *Mypyc is (mostly) not yet useful for general Python development.*
> >  .
> >  Mypyc is a compiler that compiles mypy-annotated, statically typed
> >  Python modules into CPython C extensions. Currently our primary focus
> >  is on making mypy faster through compilation -- the default mypy wheels
> >  are compiled with mypyc.  Compiled mypy is about 4x faster than
> >  without compilation.
> >  .
> >  Mypyc compiles what is essentially a Python language variant using
> "strict"
> >  semantics. This means (among some other things):
> >  .
> >   * Most type annotations are enforced at runtime (raising ``TypeError``
> on
> > mismatch)
> >  .
> >   * Classes are compiled into extension classes without ``__dict__``
> > (much, but not quite, like if they used ``__slots__``)
> >  .
> >   * Monkey patching doesn't work
> >  .
> >   * Instance attributes won't fall back to class attributes if undefined
> >  .
> >   * Metaclasses not supported
> >  .
> >   * Also there are still a bunch of bad bugs and unsupported features :)
> >  .
> >  Compiled modules can import arbitrary Python modules, and compiled
> modules
> >  can be used from other Python modules.  Typically mypyc is used to only
> >  compile modules that contain performance bottlenecks.
> >  .
> >  You can run compiled modules also as normal, interpreted Python
> >  modules, since mypyc targets valid Python code. This means that
> >  all Python developer tools and debuggers can be used.
> >  .
> >  This package provides the command-line interface.
> >
> > Remark: This package is maintained by Debian Med Packaging Team at
> >https://salsa.debian.org/med-team/mypy
>
> I’m going to review this; if you need a sponsor, I can do, just let me
> know.
>
> --
> Cheers,
>   Andrej
>

Bug#916026: bootchart2: diff for NMU version 0.14.4-3.1

[Boyuan Yang]

Control: tags 916026 + patch
Control: tags 916026 + pending

Dear maintainer,

I've prepared an NMU for bootchart2 (versioned as 0.14.4-3.1) and
uploaded it to DELAYED/8. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru bootchart2-0.14.4/debian/bootchart2.lintian-overrides bootchart2-
0.14.4/debian/bootchart2.lintian-overrides
--- bootchart2-0.14.4/debian/bootchart2.lintian-overrides   2012-12-12
15:25:52.0 -0500
+++ bootchart2-0.14.4/debian/bootchart2.lintian-overrides   2019-09-11
10:19:48.0 -0400
@@ -1,2 +1,4 @@
 # it's intentional, indeed.
 bootchart2: package-contains-empty-directory lib/bootchart/tmpfs/
+# Broken as provided by upstream, keep as is
+bootchart2: init.d-script-depends-on-all-virtual-facility
etc/init.d/bootchart-done required-start
diff -Nru bootchart2-0.14.4/debian/changelog bootchart2-
0.14.4/debian/changelog
--- bootchart2-0.14.4/debian/changelog  2012-12-12 15:25:52.0 -0500
+++ bootchart2-0.14.4/debian/changelog  2019-09-11 10:19:53.0 -0400
@@ -1,3 +1,23 @@
+bootchart2 (0.14.4-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
++ Bump Standards-Version to 4.4.0.
++ Update Vcs-* fields to use git package repo under Salsa Debian
+  group.
++ Use secure URI in homepage field.
+  * debian/patches: Add patch 0006 from upstream to fix FTBFS against
+glibc 2.28. (Closes: #916026)
+  * debian/watch: Correctly monitor GitHub upstream.
+  * debian/copyright:
++ Use secure URI.
+- Delete fields for missing files.
+  * debian/bootchart2.lintian-overrides: Add lintian override for
+init.d-script-depends-on-all-virtual-facility (suppress warning
+for now).
+
+ -- Boyuan Yang   Wed, 11 Sep 2019 10:19:53 -0400
+
 bootchart2 (0.14.4-3) unstable; urgency=low
 
   * Added missing dependency on lsb-base (>= 3.0-6). Thanks to Adam D.
diff -Nru bootchart2-0.14.4/debian/control bootchart2-0.14.4/debian/control
--- bootchart2-0.14.4/debian/control2012-12-12 15:25:52.0 -0500
+++ bootchart2-0.14.4/debian/control2019-09-11 10:13:22.0 -0400
@@ -6,10 +6,10 @@
 Build-Depends:
  debhelper (>= 8~)
  , python (>= 2.6.6-3~)
-Standards-Version: 3.9.3
-Homepage: http://github.com/mmeeks/bootchart
-Vcs-Git: git://git.debian.org/collab-maint/bootchart2.git
-Vcs-Browser: http://git.debian.org/?p=collab-maint/bootchart2.git
+Standards-Version: 4.4.0
+Homepage: https://github.com/mmeeks/bootchart
+Vcs-Git: https://salsa.debian.org/debian/bootchart2.git
+Vcs-Browser: https://salsa.debian.org/debian/bootchart2
 X-Python-Version: >= 2.6
 
 Package: bootchart2
diff -Nru bootchart2-0.14.4/debian/copyright bootchart2-
0.14.4/debian/copyright
--- bootchart2-0.14.4/debian/copyright  2012-12-12 15:25:52.0 -0500
+++ bootchart2-0.14.4/debian/copyright  2019-09-11 10:15:28.0 -0400
@@ -1,5 +1,6 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Source: http://github.com/mmeeks/bootchart
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: bootchart2
+Source: https://github.com/mmeeks/bootchart
 
 Files: *
 Copyright: © Anders Norgaard 
@@ -32,10 +33,6 @@
 Copyright: © 2010-2012, David Paleino 
 License: GPL-2+
 
-Files: debian/manpages/*
-Copyright: © 2011, Francesca Ciceri 
-License: GPL-2+
-
 License: GPL-2+
  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
diff -Nru bootchart2-0.14.4/debian/patches/0006-include-sys-sysmacros.h-for-
major-minor-makedev.patch bootchart2-0.14.4/debian/patches/0006-include-sys-
sysmacros.h-for-major-minor-makedev.patch
--- bootchart2-0.14.4/debian/patches/0006-include-sys-sysmacros.h-for-major-
minor-makedev.patch 1969-12-31 19:00:00.0 -0500
+++ bootchart2-0.14.4/debian/patches/0006-include-sys-sysmacros.h-for-major-
minor-makedev.patch 2019-09-11 09:59:14.0 -0400
@@ -0,0 +1,23 @@
+From: Mike Frysinger 
+Date: Thu, 21 Apr 2016 00:19:32 -0400
+Subject: include sys/sysmacros.h for major/minor/makedev
+
+These funcs are defined in the sys/sysmacros.h header, not sys/types.h.
+Linux C libraries are updating to drop the implicit include, so we need
+to include it explicitly.
+---
+ collector/collector.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/collector/collector.c b/collector/collector.c
+index 7a746f8..5ca4cd6 100644
+--- a/collector/collector.c
 b/collector/collector.c
+@@ -33,6 +33,7 @@
+ #include "common.h"
+ 
+ #include 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru bootchart2-0.14.4/debian/patches/series bootchart2-
0.14.4/debian/patches/series
--- bootchart2-0.14.4/debian/patches/series 2012-12-12 15:25:52.0
-0500
+++ bootchart2-0.14.4/debian/patches/series 2019-09-11 09:59:14.0
-0400
@@ -3,3 +3,4 @@
 0002-pybootchartgui-skip-malformed-taskstats-lines.patch
 

Bug#940043: git-buildpackage: gbp pq switch gives Traceback when on wrong branch

[Andreas Rönnquist]

Package: git-buildpackage
Version: 0.9.15
Severity: normal

Dear Maintainer,

When having a gbp repo, with Debian packaging in debian/master, when being in
the master branch, where I have upstream development, if I by mistake want to
do something like gbp pq switch (Which of course should be done from
debian/master) - I get a traceback.

It would be nice if it didn't give a traceback, but simply a errormessage that
it expects you to be on another branch for that to work.

gusnan@debian-buildsystem:~/kod/packaging/allegro5/allegro5 [master]> gbp pq 
switch --verbose
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/patch-queue/master']
gbp:info: No pq branch found, importing patches
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/patch-queue/master']
Traceback (most recent call last):
  File "/usr/bin/gbp", line 149, in 
sys.exit(supercommand())
  File "/usr/bin/gbp", line 145, in supercommand
return module.main(args)
  File "/usr/lib/python3/dist-packages/gbp/scripts/pq.py", line 498, in main
switch_pq(repo, current, options)
  File "/usr/lib/python3/dist-packages/gbp/scripts/pq.py", line 395, in
switch_pq
maybe_import_pq(repo, branch, options)
  File "/usr/lib/python3/dist-packages/gbp/scripts/pq.py", line 383, in
maybe_import_pq
import_pq(repo, branch, options)
  File "/usr/lib/python3/dist-packages/gbp/scripts/pq.py", line 374, in
import_pq
options.upstream_tag)
  File "/usr/lib/python3/dist-packages/gbp/scripts/pq.py", line 306, in
import_quilt_patches
maintainer = get_maintainer_from_control(repo)
  File "/usr/lib/python3/dist-packages/gbp/scripts/common/pq.py", line 280, in
get_maintainer_from_control
with open(control, encoding='utf-8') as f:
FileNotFoundError: [Errno 2] No such file or directory:
'/home/gusnan/kod/packaging/allegro5/allegro5/debian/control'

Thanks for all your work on gbp, it's a brilliant tool.

-- Andreas Rönnquist
gus...@debian.org


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

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.19.6
ii  git1:2.23.0-1
ii  man-db 2.8.7-3
ii  python33.7.3-1
ii  python3-dateutil   2.7.3-3
ii  python3-pkg-resources  41.2.0-1
ii  sensible-utils 0.0.12

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.88
ii  pbuilder  0.230.4
ii  pristine-tar  1.46
ii  python3-requests  2.21.0-1

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-3
ii  sudo 1.8.27-1+b1
ii  unzip6.0-25

-- no debconf information

Bug#940034: elogind and the release team block

[Mark Hindley]

Julien,

On Wed, Sep 11, 2019 at 03:07:51PM +0100, Mark Hindley wrote:
> I would hope we can all accept those. If so, there is no requirement for a
> manual block: at the moment there are RC bugs which prevent migration. If or
> when they are resolved migration can occur based on the release teams policy 
> in
> effect at that time.

I see you have removed the block whilst I was writing this.

Thank you.

Mark