Bug#975343: clevis encrypt tang fails with "Key derivation key not available!"

[Christoph Biedl]

Control: reassign 975343 tang 7-1
Control: tags 975343 upstream
Control: retitle 975343 tang: Race condition between keygen and update, 
resulting in "Key derivation key not available!"
Control: severity 975343 important

Dominique Dumont wrote...

> $ echo foo | clevis encrypt tang '{"url": "http://192.168.1.14"}' > bar.txt
> The advertisement contains the following signing keys:
>
> jvCF5[...]8s5A
>
> Do you wish to trust these keys? [ynYN] y
> Key derivation key not available!

Okay, here's the story: tangd-keygen creates two files in /var/db/tang/, the
second one containing '(...)"key_ops":["deriveKey"](...)'. In parallel,
tangd-update takes all the files in that directory to build (among
other) /var/cache/tang/default.jws. Now if tangd-keygen hasn't finished
the job yet, the second one is not taken into account, and this happens
on slower hardware.

Possibly upstream was in the assumption the multiple After=... in
tangd.socket are being started serialized, not in parallel.

You can check your situation using the following command:

jq -r .payload 

signature.asc
Description: PGP signature

Bug#970725: cups-client: lpoptions fails to get printer options

[Didier 'OdyX' Raboud]

Control: tags -1 +pending

Le dimanche, 22 novembre 2020, 19.29:54 h CET Brian Potkin a écrit :
> found 970725 2.3.3op1-106-ga72b0140e-1
> thanks
> 
> It is not too surprising to still find the described behaviour in
> the experimental version of cups-client as it contains the patch
> "Make lpoptions list a printer's options correctly also when CUPS
> is running on an alternative port".

You're right. This patch was in the Ubuntu fork (to work best in Ubuntu snaps 
I guess), which I imported.

So I forwarded to (the new) upstream there
https://github.com/OpenPrinting/cups/pull/39

… where it got put to doubt by Michael Sweet (upstream author).

So I'll remove it from unstable and experimental.

Cheers,

OdyX

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

Bug#858275: make source tarballs closer to upstream structure

[Hans-Christoph Steiner]

This comes from the upstream code structure.  We've discussed making 
custom source tarballs to work around this.  The idea is to use the 
'repo' tool with a custom manifest.xml to check out just the git repos 
that are actually used by the Debian packages.  Then use as much of the 
upstream build system as possible.

Bug#945508: try upstream

[Hans-Christoph Steiner]

Have you tried upstream binaries?  It might be that this version of 
fastboot is too old for your device.

Bug#915762: wishlist

[Hans-Christoph Steiner]

Control: severity -1 wishlist

Bug#975460: fontforge: FTBFS on i386 [patch]

[Anthony Fok]

On Sun, Nov 22, 2020 at 12:27 PM Gianfranco Costamagna
 wrote:
>
> BTW the macro was DEB_HOST_MULTIARCH, as you already know
> G.

Thank you Gianfranco!

Sorry for my delay in getting the fix uploaded.
There is another FTBFS issue with binary-indep (build all), as well as
some Lintian errors and warnings, that I would like to solve too
before upload.  I think I am finally almost ready to upload
1:20201107~dfsg-2, hopefully in an hour or so?  :-)

Cheers,
Anthony

> On Sun, 22 Nov 2020 19:47:34 +0100 Gianfranco Costamagna 
>  wrote:
> > looks like fixed already in git:
> > https://salsa.debian.org/fonts-team/fontforge/commit/c52b395bda57c305
> >
> > Closing.
> >
> > G.
> >
> > On Sun, 22 Nov 2020 16:23:54 +0100 Gianfranco Costamagna 
> >  wrote:
> > > Source: fontforge
> > > Version: 1:20201107~dfsg-1
> > > Severity: serious
> > > tags: patch
> > >
> > >
> > > Hello, to fix the build failure I think debian/libfontforge4.install 
> > > should contain this line:
> > > usr/lib/${DEB_BUILD_MULTIARCH}
> > >
> > > Full patch:
> > >
> > > --- fontforge-20201107~dfsg/debian/changelog2020-11-18 
> > > 09:42:18.0 +0100
> > > +++ fontforge-20201107~dfsg/debian/changelog2020-11-22 
> > > 15:24:41.0 +0100
> > > @@ -1,3 +1,9 @@
> > > +fontforge (1:20201107~dfsg-1.1) UNRELEASED; urgency=medium
> > > +
> > > +  * Fix i386 build (Closes: #-1)
> > > +
> > > + -- Gianfranco Costamagna   Sun, 22 Nov 2020 
> > > 15:24:41 +0100
> > > +
> > >  fontforge (1:20201107~dfsg-1) unstable; urgency=medium
> > >
> > >[ Jonas Smedegaard ]
> > > diff -Nru fontforge-20201107~dfsg/debian/libfontforge4.install 
> > > fontforge-20201107~dfsg/debian/libfontforge4.install
> > > --- fontforge-20201107~dfsg/debian/libfontforge4.install2020-11-17 
> > > 10:15:18.0 +0100
> > > +++ fontforge-20201107~dfsg/debian/libfontforge4.install2020-11-22 
> > > 15:24:40.0 +0100
> > > @@ -1 +1 @@
> > > -usr/lib/${DEB_HOST_GNU_TYPE}
> > > +usr/lib/${DEB_BUILD_MULTIARCH}
> > >
> > >
> >
> >
>

Bug#975478: [Pkg-puppet-devel] Bug#975478: Use libmariadb-dev instead of legacy libmariadbclient-dev

[Otto Kekäläinen]

Hello!

The package libmariadbclient-dev was a real binary package in Debian
Stretch and has been an empty transitional package already since the
Buster release. So you can safely change libmariadbclient-dev ->
libmariadb-dev in both Buster and Bullseye.

See 
https://packages.debian.org/search?keywords=libmariadbclient-dev&searchon=names&suite=all§ion=all

Bug#975620: RFA: sgmllib3k -- Python 3 port of Python 2's sgmllib

[Misha Gusarov]

Package: wnpp
Severity: normal

I request an adopter for the sgmllib3k package. The package is
frozen, so it does not require much maintenance, but I don't
do a good job maintaining Debian packaging for it and uploading.

The package description is:
 sgmllib was dropped from the Python standard library in Python 3. This
 package provides a port of the library to Python 3.

Bug#975619: RFA: mueller -- Mueller English/Russian dictionary in dict format

[Misha Gusarov]

Package: wnpp
Severity: normal

I request an adopter for the mueller package. I no longer
use Debian regularly, so I don't do a good job maintaining
it.

The package description is:
 Electronic version of the English/Russian dictionary by V. K. Mueller,
 release 7.
 .
 This package contains the dictionary in dict format.

Bug#975460: wrong patch

[Matthias Klose]

the patch is wrong, it's DEB_HOST_MULTIARCH

Bug#975618: RFA: archmage -- CHM (Compiled HTML) Decompressor

[Misha Gusarov]

Package: wnpp
Severity: normal

I request an adopter for archmage. I no longer use Debian
regularly, so I don't do a good job maintaining it.

Bug#975617: RFA: libssh2 -- SSH2 client-side library

[Misha Gusarov]

Package: wnpp
Severity: normal

I request an adopter for the libssh2 package. I no longer
use Debian regularly, so I don't do a good job maintaining
it.

The package description is:
 libssh2 is a client-side C library implementing the SSH2 protocol.
 It supports regular terminal, SCP and SFTP (v1-v5) sessions;
 port forwarding, X11 forwarding; password, key-based and
 keyboard-interactive authentication.
 .
 This package contains the runtime library.

Bug#975616: buster-pu: package neomutt/neomutt_20180716+dfsg.1-1+deb10u2

[Antonio Radici]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: j...@inutil.org, car...@debian.org

(Please provide enough information to help the release team
to judge the request efficiently. E.g. by filling in the
sections below.)

[ Reason ]
Same as bugs.debian.org/975514, except that one is for mutt, this one for
neomutt. The patch is the same and it addresses the same CVE (CVE-2020-28896).

Security team is aware, they suggested to go through the route of buster-updates
rather than DSA for this particular issue.

debdiff is attached, I've also done an upload already.

[ Impact ]
Prevent login information to be sent over an encrypted connection when certain
conditions happen.

[ Tests ]
(What automated or manual tests cover the affected code?)

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, alternatives available.)

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in (old)stable
  [*] the issue is verified as fixed in unstable

[ Changes ]
See the "Reason" section.

[ Other info ]
(Anything else the release team should know.)

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

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.utf8, LC_CTYPE=en_IE.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru neomutt-20180716+dfsg.1/debian/changelog 
neomutt-20180716+dfsg.1/debian/changelog
--- neomutt-20180716+dfsg.1/debian/changelog2020-06-20 07:42:44.0 
+0200
+++ neomutt-20180716+dfsg.1/debian/changelog2020-11-24 07:55:28.0 
+0100
@@ -1,3 +1,11 @@
+neomutt (20180716+dfsg.1-1+deb10u2) buster; urgency=medium
+
+  * debian/patches:
++ security/CVE-2020-28896.patch: handle the relevant CVE to stop sending
+  login information over an encrypted connections in certain conditions.
+
+ -- Antonio Radici   Tue, 24 Nov 2020 07:55:28 +0100
+
 neomutt (20180716+dfsg.1-1+deb10u1) buster-security; urgency=high
 
   * debian/patches:
diff -Nru neomutt-20180716+dfsg.1/debian/patches/security/CVE-2020-28896.patch 
neomutt-20180716+dfsg.1/debian/patches/security/CVE-2020-28896.patch
--- neomutt-20180716+dfsg.1/debian/patches/security/CVE-2020-28896.patch
1970-01-01 01:00:00.0 +0100
+++ neomutt-20180716+dfsg.1/debian/patches/security/CVE-2020-28896.patch
2020-11-24 07:55:28.0 +0100
@@ -0,0 +1,39 @@
+From 04b06aaa3e0cc0022b9b01dbca2863756ebbf59a Mon Sep 17 00:00:00 2001
+From: Kevin McCarthy 
+Date: Mon, 16 Nov 2020 10:20:21 -0800
+Subject: [PATCH] Ensure IMAP connection is closed after a connection error.
+
+During connection, if the server provided an illegal initial response,
+Mutt "bailed", but did not actually close the connection.  The calling
+code unfortunately relied on the connection status to decide to
+continue with authentication, instead of checking the "bail" return
+value.
+
+This could result in authentication credentials being sent over an
+unencrypted connection, without $ssl_force_tls being consulted.
+
+Fix this by strictly closing the connection on any invalid response
+during connection.  The fix is intentionally small, to ease
+backporting.  A better fix would include removing the 'err_close_conn'
+label, and perhaps adding return value checking in the caller (though
+this change obviates the need for that).
+
+This addresses CVE-2020-28896.  Thanks to Gabriel Salles-Loustau for
+reporting the problem, and providing test cases to reproduce.
+---
+ imap/imap.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/imap/imap.c
 b/imap/imap.c
+@@ -1110,9 +1110,9 @@
+ 
+ #ifdef USE_SSL
+ err_close_conn:
+-  imap_close_connection(idata);
+ #endif
+ bail:
++  imap_close_connection(idata);
+   FREE(&idata->capstr);
+   return -1;
+ }
diff -Nru neomutt-20180716+dfsg.1/debian/patches/series 
neomutt-20180716+dfsg.1/debian/patches/series
--- neomutt-20180716+dfsg.1/debian/patches/series   2020-06-20 
07:42:44.0 +0200
+++ neomutt-20180716+dfsg.1/debian/patches/series   2020-11-24 
07:55:28.0 +0100
@@ -4,3 +4,4 @@
 misc/smime.rc.patch
 security/CVE-2020-14093.patch
 security/handle-starttls.patch
+security/CVE-2020-28896.patch

Bug#975615: gnunet: Help needed to maintain GNUnet

[Bertrand Marc]

Package: gnunet
Severity: serious
X-Debbugs-Cc: bm...@debian.org

I would like to pass over the maintainance of the GNUnet package (see #964314).

In the meantime, it wouldn't make sense to have the outdated 0.13.1 version in 
Stable,
so this bug is severity serious to prevent it from migrating to Testing.

If you would like to take over and package GNUnet 0.14, please be my guest.

Cheers,
Bertrand

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

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

Versions of packages gnunet depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-4
ii  libcurl3-gnutls7.72.0-1
pn  libextractor3  
ii  libgcrypt201.8.7-2
ii  libgnutls-dane03.6.15-4
ii  libgnutls303.6.15-4
ii  libidn2-0  2.3.0-4
ii  libjansson42.13.1-1
ii  libltdl7   2.4.6-14
ii  libmariadb31:10.3.24-2
pn  libmicrohttpd12
ii  libogg01.3.2-1+b1
ii  libopus0   1.3.1-0.1
pn  libpq5 
ii  libpulse0  13.0-5
ii  libsodium231.0.18-1
ii  libsqlite3-0   3.33.0-1
ii  libunistring2  0.9.10-4
ii  libzbar0   0.23.1-2+b1
ii  lsb-base   11.1.0
ii  netbase6.2
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gnunet recommends:
pn  libnss3-tools  
ii  openssl1.1.1h-1

Versions of packages gnunet suggests:
pn  miniupnpc  
pn  texlive

Bug#974995: Raising severity and offering to NMU package

[Bertrand Marc]

Dear Simon,

If you can find the time, please do. Otherwise, I'll probably remove GNUnet 
from testing myself (it is currently RFA).

Cheers,
Bertrand

Le 23/11/2020 à 20:15, Simon Josefsson a écrit :
> severity 975030 serious
> severity 974997 serious
> severity 974996 serious
> severity 974995 serious
> severity 974994 serious
> severity 974993 serious
> thanks
>
> It was suggested to me on IRC that the severity of this could be
> serious because the build-dependency libidn2-0-dev is going to be
> removed from Debian.  I'm volunteering to do NMU these packages to fix
> the bug, and could look into that in a couple of weeks -- if you give
> me permission to do it before, I'd start directly.  If I'm mistaken
> that this is not a valid justification for a serious bug, downgrade the
> bug and let me know, as I'm not sure what the best way to get an
> obsolete deprecated transition package removed from Debian when build-
> deps remain.
>
> /Simon
>

Bug#968381: typo in bug title

[Paolo Cavallini]

bashtop: seems superceded by Python-based pbytop
should be
bashtop: seems superceded by Python-based bpytop
-- 
Paolo Cavallini
www.faunalia.eu - QGIS.org
training, support, development on QGIS, PostGIS and more

Bug#975614: calibre not working with python3.8

[GT]

Package: calibre
Version: 5.5.0+dfsg-3
Severity: important

Dear Maintainer,

The last version of calibre is not working again

calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 20, in 
sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 73, in calibre
main(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 509, in main
app, opts, args = init_qt(args)
  File "/usr/lib/calibre/calibre/gui2/main.py", line 122, in init_qt
app = Application(args, override_program_name=override,
windows_app_uid=MAIN_APP_UID)
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 885, in __init__
from calibre_extensions import progress_indicator
ImportError: /usr/lib/calibre/calibre/plugins/progress_indicator.so: undefined
symbol: _Py_FatalErrorFunc

apt policy calibre
calibre:
  Installé : 5.5.0+dfsg-3
  Candidat : 5.5.0+dfsg-3
 Table de version :
 *** 5.5.0+dfsg-3 500
500 https://cdn-aws.deb.debian.org/debian sid/main amd64 Packages
500 https://cdn-aws.deb.debian.org/debian sid/main i386 Packages
100 /var/lib/dpkg/status
 5.5.0+dfsg-1 990
990 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 Packages
990 https://cdn-aws.deb.debian.org/debian bullseye/main i386 Packages
 3.39.1+dfsg-3 500
500 https://cdn-aws.deb.debian.org/debian buster/main amd64 Packages
500 https://cdn-aws.deb.debian.org/debian buster/main i386 Packages
 2.75.1+dfsg-1 500
500 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Packages
500 https://cdn-aws.deb.debian.org/debian stretch/main i386 Packages

debian:~$ python --version
Python 3.8.6
debian:~$ python3 --version
Python 3.8.6




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

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

Versions of packages calibre depends on:
ii  calibre-bin  5.5.0+dfsg-3
ii  dpkg 1.20.5
ii  fonts-liberation 1:1.07.4-11
ii  imagemagick  8:6.9.11.24+dfsg-1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.24+dfsg-1+b2
ii  libjpeg-turbo-progs  1:2.0.5-1.1
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-1+b1
ii  poppler-utils20.09.0-3
ii  python3  3.8.6-1
ii  python3-apsw 3.32.2-r1-1+b1
ii  python3-bs4  4.9.3-1
ii  python3-chardet  3.0.4-7
ii  python3-chm  0.8.6-2+b2
ii  python3-css-parser   1.0.4-2
ii  python3-cssselect1.1.0+ds-1
ii  python3-cssutils 1.0.2-3
ii  python3-dateutil 2.8.1-4
ii  python3-dbus 1.2.16-4
ii  python3-feedparser   5.2.1-3
ii  python3-html2text2020.1.16-1
ii  python3-html5-parser 0.4.9-3+b2
ii  python3-html5lib 1.1-2
ii  python3-lxml 4.6.1-1
ii  python3-markdown 3.3.3-1
ii  python3-mechanize1:0.4.5-2
ii  python3-msgpack  0.6.2-1+b1
ii  python3-netifaces0.10.9-0.2+b2
ii  python3-pil  8.0.1-1
ii  python3-pkg-resources50.3.0-1
ii  python3-pygments 2.3.1+dfsg-4
ii  python3-pyparsing2.4.7-1
ii  python3-pyqt55.15.1+dfsg-2+b3
ii  python3-pyqt5.qtsvg  5.15.1+dfsg-2+b3
ii  python3-pyqt5.qtwebengine5.15.1-1+b1
ii  python3-pyqt5.sip12.8.1-1+b1
ii  python3-regex0.1.20200714-1+b1
ii  python3-routes   2.4.1-2
ii  python3-zeroconf 0.26.1-1
ii  xdg-utils1.1.3-2

Versions of packages calibre recommends:
pn  python3-dnspython  
ii  udisks22.9.1-2

Versions of packages calibre suggests:
ii  python3-openssl   19.1.0-2
pn  python3-unrardll  

-- no debconf information

Bug#975613: android-libboringssl: adb crashes with "invalid pointer" error

[Legimet ‎]

Package: android-libboringssl
Version: 10.0.0+r36-1
Severity: normal

After upgrading to the latest version of this package, adb no longer
works, as it crashed with the following error:

* daemon not running; starting now at tcp:5037
ADB server didn't ACK
Full server startup log: /tmp/adb.1000.log
Server had pid: 19240
--- adb starting (pid 19240) ---
adb I 11-24 00:46:53 19240 19240 main.cpp:57] Android Debug Bridge
version 1.0.39
adb I 11-24 00:46:53 19240 19240 main.cpp:57] Version 1:8.1.0+r23-8
adb I 11-24 00:46:53 19240 19240 main.cpp:57] Installed as
/usr/lib/android-sdk/platform-tools/adb
adb I 11-24 00:46:53 19240 19240 main.cpp:57]
adb I 11-24 00:46:53 19240 19240 adb_auth_host.cpp:416] adb_auth_init...
adb I 11-24 00:46:53 19240 19240 adb_auth_host.cpp:174] read_key_file
'/home/legimet/.android/adbkey'...
munmap_chunk(): invalid pointer

* failed to start daemon
adb: unable to connect for root: cannot connect to daemon

Bug#975333: msmtp: AppArmor profile breaks --file, logfile, and passwordeval

[Simon Deziel]

On 2020-11-21 4:02 a.m., Martin Lambers wrote:

On Fri, 20 Nov 2020 10:35:00 -0500, Simon Deziel wrote:

A big problem is that users do not know where to look if they get an
unexplainable "permission denied" error. Almost nobody knows that
AppArmor interferes.

A working AppArmor profile would have to allow reading, writing and
executing arbitrary files, which would make it pretty much useless.

I therefore propose to either remove the AppArmor profile or
restrict it to the msmtp-mta package, so that most users can
continue using msmtp as expected.


I'd like to propose to continue shipping the Apparmor profile but have
it disabled by default. This way it would be an (easy) opt-in
procedure for those who want the additional security and not even a
concern for others. Presumably, those opting in would be more savvy
with Apparmor and should in theory not send you as many bug reports.

Would that work for you?


Yes, an opt-in approach seems ideal.


Here's the proposal:

https://salsa.debian.org/kolter/msmtp/-/merge_requests/16

I appreciate your work on securing msmtp; it's just that the current 
approach causes problems. The threat scenario is a malicious SMTP 
server trying to trigger a bug in msmtp, right?


Another use case is to limit transitions between Apparmor confined apps. 
If you lockdown a daemon (like apache2) with Apparmor, you can still 
permit it to send emails by allowing it to execute msmtp in its own profile.



For that case, I
thought about adding seccomp() after the configuration is initialized
(file read, logfile opened, passwords acquired) but before connecting
to the SMTP server. Msmtp would still need memory allocation and
temporary file usage. When TLS is involved, things are more complex.
GnuTLS requires a long list of syscalls to work properly [1], and
that list will probably change with future versions, so using
seccomp() here seems complex, fragile and hard to maintain.

Something like OpenBSDs pledge() would be simpler, but still require 
knowledge about the requirements of GnuTLS.
seccomp() seems brittle and overly complex when compared with pledge()'s 
simplistic beauty. One can hope though [1].


Regards,
Simon


[1] https://github.com/seccomp/libseccomp/issues/71

Bug#975600: New upstream release 1.12.0

[Bill Blough]

Hi Roger,

Thanks for the reminder.  1.12 is currently setting in experiemental.
I expect to be filing a transition request in the next week or two.

Best regards,
Bill




On Mon, Nov 23, 2020 at 10:56:39PM +, Roger Leigh wrote:
> Package: xalan
> Version: 1.11-9
> 
> Hi Bill,
> 
> This was mentioned on the upstream mailing list earlier in the year.  Just 
> opening a bug to track this.
> 
> New upstream release 1.12 was made a few months back 
> (https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0).  This could 
> be packaged to replace the decade-old 1.11 release.  Note that the new 
> release brings with it a new CMake-based build system to match Xerces-C.  All 
> the configuration options of the old build system are exposed via CMake 
> options.  It's all documented in the manual: 
> https://apache.github.io/xalan-c/build.html
> 
> Kind regards,
> Roger

-- 
GPG: 5CDD 0C9C F446 BC1B 2509  8791 1762 E022 7034 CF84

Bug#824954: flash-kernel: GRUB? via U-Boot?

[Elliott Mitchell]

There may be several distinct bugs involved with #824954.  For one, I
suspect `grub-install`'s behavior needs to change if EFI variables aren't
supported.  I use this as a flag which could distinguish installation on
top of a full EFI implementation (perhaps Tianocore-derived), versus
U-Boot's rather primative EFI implementation.

Notably right now `grub-install` tries to install to
/boot/efi/EFI/debian by default.  This is appropriate for a full EFI
implementation where boot entries can be added by adding variables.  Yet
with U-Boot's limited implementation, the files must go in EFI/BOOT
(--bootloader-id=BOOT).

Right now I'm simply trying to figure out what others have done to reuse
it for my own purposes.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#975558: Add public domain to copyright types

[Anatoli Babenia]

On Tue, 24 Nov 2020 at 02:33, Craig Small  wrote:
>
> It's not used a lot because its a bit vague.  All three of us could write 
> some license that we think is public domain but it is worded differently. The 
> problem for dh-make is, which one is the "right" one?
>
> For GPL-2 for example, there is a canonical version of the license.  SPDX 
> lists several licenses that have public domain in their name.

SPDX Legal Team tries to handle PD with copyright law, and explains
that they want to treat each public domain dedication as sepate
implicit licenses
https://wiki.spdx.org/view/Legal_Team/Decisions/Dealing_with_Public_Domain_within_SPDX_Files
However, everything that is said also applies to GPL in countries
where software licenses have no formal status.

If we agree that public domain dedication is not a license, but a will
of an author, then enforcing SPDX, which doesn't have a mechanism for
copyright opt out, will filter out public domain software from package
repositories.

> dh-make already has a blank license and a custom license (where you feed it 
> the copyright file). I'm not convinced putting in a best-guess for public 
> domain license will be helpful.

Bug#975594: RFS: capbattleship/1.0~alpha4-1 -- Sink your enemy before he gets you!

[Fabien Givors (Debian)]

Le 24/11/2020 à 00:26, Paul Wise a écrit :

On Mon, Nov 23, 2020 at 10:26 PM Fabien Givors wrote:


capbattleship - Sink your enemy before he gets you!


I would encourage you to use a more descriptive summary and also avoid
non-inclusive language. I think the summary you used in the ITP was
better for both of these suggestions.


Oh, right, thanks. I should be more careful about that.

I updated the short description, new version of the package should be 
there by now:


dget -x
https://mentors.debian.net/debian/pool/main/c/capbattleship/capbattleship_1.0~alpha4-2.dsc

--
captnfab

Bug#948712: Returned mail: see transcript for details

[Elliott Mitchell]

reopen 948712
quit

There should be a rather obvious use case where absent /boot/firmware is
quite appropriate.  For someone needing a copy of the firmware, but using
other tools to build the boot area.

Notably one might use raspi-firmware to retrieve start*.elf/fixup*.dat.
Then add u-boot-rpi for second stage bootloader.  Next grub-efi-arm* for
third stage.  Lastly flash-kernel to glue all the pieces together.

Not one of these requires the existance of /boot/firmware.  In fact, not
one of these needs the installation of dosfstools.

Perhaps the raspi-firmware package should be split into pieces so as to
allow merely installing the actually required portions?

(raspi-firmware-bin which depends upon: raspi1-firmware-bin,
raspi2-firmware-bin, raspi3-firmware-bin, and raspi4-firmware-bin?)


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#975593: python-mapnik: FTBFS against boost_1.74

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/mapnik/python-mapnik/issues/236

Hi Anton,

Thanks for reporting this issue, it's been forwarded upstream.

Kind Regards,

Bas

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

Bug#975611: ITP: r-cran-mathjaxr -- GNU R package for 'Mathjax' use in Rd files

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-mathjaxr
  Version : 1.0-1
  Upstream Author : Wolfgang Viechtbauer
* URL or Web page : https://github.com/wviechtb/mathjaxr
* License : GPL-3
  Description : GNU R package for 'Mathjax' use in Rd files

This package is now a build-dependency of package 'rgl' which has been in
Debian since 2004.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#975609: libc6.1:alpha not coinstallable with libc6:i386 due to /lib/ld-linux.so.2

[Witold Baryluk]

Package: libc6.1
Version: 2.31-3
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

# apt install zstd:alpha
...
...
The following NEW packages will be installed:
  gcc-10-base:alpha libc6.1:alpha libcrypt1:alpha libgcc-s1:alpha 
libidn2-0:alpha liblz4-1:alpha liblzma5:alpha libstdc++6:alpha 
libunistring2:alpha
  zlib1g:alpha zstd:alpha
...
...
Do you want to continue? [Y/n] 
Preconfiguring packages ...
Selecting previously unselected package gcc-10-base:alpha.
(Reading database ... 744802 files and directories currently installed.)
Preparing to unpack .../00-gcc-10-base_10.2.0-18_alpha.deb ...
Unpacking gcc-10-base:alpha (10.2.0-18) ...
Selecting previously unselected package libgcc-s1:alpha.
Preparing to unpack .../01-libgcc-s1_10.2.0-18_alpha.deb ...
Unpacking libgcc-s1:alpha (10.2.0-18) ...
Selecting previously unselected package libc6.1:alpha.
Preparing to unpack .../02-libc6.1_2.31-3_alpha.deb ...
Unpacking libc6.1:alpha (2.31-3) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-vYR8wY/02-libc6.1_2.31-3_alpha.deb (--unpack):
 trying to overwrite '/lib/ld-linux.so.2', which is also in package libc6:i386 
2.31-4
Selecting previously unselected package libcrypt1:alpha.
Preparing to unpack .../03-libcrypt1_1%3a4.4.17-1_alpha.deb ...
Unpacking libcrypt1:alpha (1:4.4.17-1) ...
Selecting previously unselected package libunistring2:alpha.
Preparing to unpack .../04-libunistring2_0.9.10-4_alpha.deb ...
Unpacking libunistring2:alpha (0.9.10-4) ...
Selecting previously unselected package libidn2-0:alpha.
Preparing to unpack .../05-libidn2-0_2.3.0-4_alpha.deb ...
Unpacking libidn2-0:alpha (2.3.0-4) ...
Selecting previously unselected package liblz4-1:alpha.
Preparing to unpack .../06-liblz4-1_1.9.2-2_alpha.deb ...
Unpacking liblz4-1:alpha (1.9.2-2) ...
Selecting previously unselected package liblzma5:alpha.
Preparing to unpack .../07-liblzma5_5.2.4-1+b1_alpha.deb ...
Unpacking liblzma5:alpha (5.2.4-1+b1) ...
Selecting previously unselected package libstdc++6:alpha.
Preparing to unpack .../08-libstdc++6_10.2.0-18_alpha.deb ...
Unpacking libstdc++6:alpha (10.2.0-18) ...
Selecting previously unselected package zlib1g:alpha.
Preparing to unpack .../09-zlib1g_1%3a1.2.11.dfsg-2_alpha.deb ...
Unpacking zlib1g:alpha (1:1.2.11.dfsg-2) ...
Selecting previously unselected package zstd:alpha.
Preparing to unpack .../10-zstd_1.4.5+dfsg-4_alpha.deb ...
Unpacking zstd:alpha (1.4.5+dfsg-4) over (1.4.5+dfsg-4) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-vYR8wY/02-libc6.1_2.31-3_alpha.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)
#


(please don't ask why).


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf, mips64el, ppc64el, m68k, sparc64, 
alpha

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

Bug#975597: libxft2: fonts-noto-color-emoji causes protocol error in libxft

[Tobias Diedrich]

Package: libxft2
Version: 2.3.2-2
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

libxft seems to have a known issue where color emojis cause it crash the
app with an X11 protocol error, e.g.:
X Error of failed request:  BadLength (poly request too large or internal Xlib 
length error) Major opcode of failed request:
139 (RENDER) Minor opcode of failed request:  20 (RenderAddGlyphs) Serial 
number of failed request:  2961 Current serial number
in output stream:  2970

It looks like there is an unmerged upstream patch available:
https://gitlab.freedesktop.org/xorg/lib/libxft/-/merge_requests/1

Can we get this patch included in the libxft2 package?

Cheers,
Tobias

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

Kernel: Linux 5.4.78 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libxft2 depends on:
ii  libc6   2.31-4
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-4
ii  libx11-62:1.6.12-1
ii  libxrender1 1:0.9.10-1

libxft2 recommends no packages.

libxft2 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHsEARECADsWIQRxaBGQN9IG6CSWJyjmr+x6msfgvAUCX7wz4x0ccmFubWErZGVi
aWFuYnRzQHRkaWVkcmljaC5kZQAKCRDmr+x6msfgvD1ZAJ9KQzfuzrlVOCOF6tCx
aOc752qr4wCeMZLV51R5/6KQ+pDu2Gna+YlFQo8=
=SeAR
-END PGP SIGNATURE-

Bug#975595: TAG: pcnfsd -- RPC Server That Supports ONC Clients

[Zombie Ryushu]

Package: pcnfsd
Severity: RFP

RPC server that supports ONC clients on PC (DOS, OS/2, Macintosh, and
other) systems.

Bug#975608: libapache2-mod-python: cgi.escape() is not in python 3.9

[peterc]

Package: libapache2-mod-python
Version: 3.5.0-1+b1
Severity: important

Dear Maintainer,

A fresh install on sid, and whenever mod_python is invoked
I see a server failure:
In the Apache2 log is:
  File "/usr/lib/python3/dist-packages/mod_python/psp.py", line 28, in 
\nfrom cgi import escape
[Tue Nov 24 12:23:01.095592 2020] [:error] [pid 112599:tid 140109003720448] 
[client ::1:34224] PythonHandler ertos: ImportError: cannot import name 
'escape' from 'cgi' (/usr/lib/python3.9/cgi.py)


escape() is now available in the html module instead of the cgi module.

This looks like it has been fixed upstream.

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

Kernel: Linux 5.9.0-3-cloud-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libapache2-mod-python depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.46-2
ii  libc6   2.31-4
ii  libpython3.93.9.0-5
ii  python3 3.9.0-3

libapache2-mod-python recommends no packages.

Versions of packages libapache2-mod-python suggests:
pn  libapache2-mod-python-doc  

-- no debconf information

Bug#975594: RFS: capbattleship/1.0~alpha4-1 -- Sink your enemy before he gets you!

[Fabien Givors (Debian)]

Package: sponsorship-requests
Severity: wishlist

Dear all,

I am looking for a sponsor for my package "capbattleship":

 * Package name: capbattleship
   Version : 1.0~alpha4-1
   Upstream Author : Fabien Givors 
 * URL : https://capbattleship.tuxfamily.org/
 * License : CC0-1.0, CC-BY-4.0, MIT
 * Vcs : https://salsa.debian.org/captnfab-guest/capbattleship
   Section : games

I wish to maintain this package inside the Debian Games Team.

It builds those binary packages:

  capbattleship - Sink your enemy before he gets you!

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/capbattleship/capbattleship_1.0~alpha4-1.dsc


Changes for the initial release:

 capbattleship (1.0~alpha4-1) unstable; urgency=medium
 .
   * Update to new upstream version 1.0~alpha4
   * .desktop and icon now installed by upstream (via setup.py)

Regards,

--
captnfab

Bug#956804: tomcat9: No way to set CATALINA_OPTS as catalina.sh environment variable

[Emmanuel Bourg]

Le 2020-04-15 14:35, Radosław Józwik a écrit :


there is no way to set CATALINA_OPTS environment variable to be used
by catalina.sh
startup script. As described in catalina.sh source:

#   CATALINA_OPTS   (Optional) Java runtime options used when the 
"start",

#   "run" or "debug" command is executed.

It is working in tomcat8 package from Debian 9 by setting CATALINA_OPTS
in /etc/default/tomcat8.


Hi Radosław, you should use JAVA_OPTS instead of CATALINA_OPTS in 
/etc/default/tomcat9 as documented in the file. I don't think 
CATALINA_OPTS has ever been intended to be supported in 
/etc/default/tomcat.


Emmanuel Bourg

Bug#975607: libgit2-28: relative paths in alternates mishandled when nested

[Eric Wong]

Package: libgit2-28
Version: 0.28.3+dfsg.1-1~bpo10+1
Severity: normal
Tags: upstream

Dear Maintainer,

I've noticed libgit2 fails to handle relative paths for
alternates properly when a relative path is nested from
within another alternate.  Regular git(1) works fine
(as shown in the attached script).

I initially hit this in some Inline::C (Perl) code, but the Ruby
"rugged" library hits it, too.

I've attached a small Ruby script which reliably reproduces it
with the "ruby-rugged" gem.  I chose Ruby for this bug report
since I expect libgit2 maintainers to be familiar with it.

More detailed info is in the comments of the attached script.

This also affects libgit2-27 (0.27.7+dfsg.1-0.2) in buster in
addition to buster-backports.

This is an upstream bug, please forward as appropriate.

I will never use the upstream GitHub bug tracker due to their
Terms-of-Service, JavaScript CAPTCHA requirement, and it being
non-free software.

Thank you.

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

Versions of packages libgit2-28 depends on:
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u3
ii  libgssapi-krb5-2   1.17-3+deb10u1
ii  libhttp-parser2.8  2.8.1-1
ii  libk5crypto3   1.17-3+deb10u1
ii  libkrb5-3  1.17-3+deb10u1
ii  libmbedcrypto3 2.16.0-1
ii  libmbedtls12   2.16.0-1
ii  libmbedx509-0  2.16.0-1
ii  libssh2-1  1.8.0-2.1
ii  zlib1g 1:1.2.11.dfsg-1

libgit2-28 recommends no packages.

libgit2-28 suggests no packages.

-- no debconf information




lg2-alternate-bug.rb
Description: application/ruby

Bug#969684: trackballs: please upgrade to guile-3.0 soon, if feasible

[Rob Browning]

Here with current bullseye, the three patches above allow the package to
at least build against guile-3.0.  Please consider upgrading soon.
We're still planning to try to remove guile-2.2 before the freeze.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#969684: [PATCH 1/3] Add headers for memset, strncpy, etc.

[Rob Browning]

---
 src/animatedCollection.cc | 1 +
 src/flag.cc   | 2 ++
 src/fountain.cc   | 2 ++
 src/goal.cc   | 2 ++
 src/guile.cc  | 1 +
 src/highScore.cc  | 1 +
 src/settings.cc   | 1 +
 src/weather.cc| 2 ++
 8 files changed, 12 insertions(+)

diff --git a/src/animatedCollection.cc b/src/animatedCollection.cc
index 2b90be0..cff826c 100644
--- a/src/animatedCollection.cc
+++ b/src/animatedCollection.cc
@@ -23,6 +23,7 @@
 /* For std::sort, std::nth_element */
 #include 
 
+#include 
 #include 
 
 static int AC_DEBUG = 0;
diff --git a/src/flag.cc b/src/flag.cc
index 74b4161..bbedb0b 100644
--- a/src/flag.cc
+++ b/src/flag.cc
@@ -24,6 +24,8 @@
 #include "player.h"
 #include "sound.h"
 
+#include 
+
 Flag::Flag(Real x, Real y, int points, int visible, Real radius)
 : Animated(Role_OtherAnimated, 1) {
   scoreOnDeath = points;
diff --git a/src/fountain.cc b/src/fountain.cc
index 85a7f7c..68e7973 100644
--- a/src/fountain.cc
+++ b/src/fountain.cc
@@ -23,6 +23,8 @@
 #include "player.h"
 #include "settings.h"
 
+#include 
+
 Fountain::Fountain(const Coord3d &pos, double randomSpeed, double radius, 
double strength)
 : Animated(Role_OtherAnimated, 1),
   randomSpeed(randomSpeed),
diff --git a/src/goal.cc b/src/goal.cc
index b55e1e5..0070c0b 100644
--- a/src/goal.cc
+++ b/src/goal.cc
@@ -24,6 +24,8 @@
 #include "map.h"
 #include "player.h"
 
+#include 
+
 Goal::Goal(Real x, Real y, int rotate, char *nextLevel) : Flag(x, y, 1000, 1, 
0.2) {
   strncpy(this->nextLevel, nextLevel, sizeof(this->nextLevel));
   this->rotate = rotate;
diff --git a/src/guile.cc b/src/guile.cc
index ade906b..655cf65 100644
--- a/src/guile.cc
+++ b/src/guile.cc
@@ -55,6 +55,7 @@
 
 #include 
 #include 
+#include 
 
 /* Object coordinates are shifted by DX/DY relative to map coordinates in the 
API
  * Thus, a flag, ball, etc. placed at (222,225) will appear at (222+DX,225+DY)
diff --git a/src/highScore.cc b/src/highScore.cc
index 2b6da98..a1d05cc 100644
--- a/src/highScore.cc
+++ b/src/highScore.cc
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 static char highScorePath[256];
diff --git a/src/settings.cc b/src/settings.cc
index e9c2a1a..4e6478b 100644
--- a/src/settings.cc
+++ b/src/settings.cc
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 extern double timeDilationFactor;
 
diff --git a/src/weather.cc b/src/weather.cc
index a72de8b..1fd340a 100644
--- a/src/weather.cc
+++ b/src/weather.cc
@@ -24,6 +24,8 @@
 #include "player.h"
 #include "settings.h"
 
+#include 
+
 Weather::Weather() {
   if (Settings::settings->gfx_details <= 2) max_weather_particles = 500;
   if (Settings::settings->gfx_details == 3) max_weather_particles = 1000;
-- 
2.29.2

Bug#969684: [PATCH 2/3] Support Guile 3.0

[Rob Browning]

---
 cmake/FindGuile.cmake | 13 -
 src/guile.h   |  2 +-
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/cmake/FindGuile.cmake b/cmake/FindGuile.cmake
index 8b93daa..3dd670b 100644
--- a/cmake/FindGuile.cmake
+++ b/cmake/FindGuile.cmake
@@ -2,15 +2,18 @@
 # Note: `guile-config` ultimately calls pkg-config anyway
 # Nothing gets marked `advanced` since there aren't that many variables
 
-find_program(GUILE_SNARF NAMES guile-snarf guile-snarf2.2 guile-snarf2.0)
+find_program(GUILE_SNARF NAMES guile-snarf guile-snarf-3.0 guile-snarf2.2 
guile-snarf2.0)
 
 # PkgConfig is only there to provide hints
 find_package(PkgConfig)
 pkg_check_modules(PC_GUILE QUIET guile)
 if (NOT PC_GUILE_FOUND)
-  pkg_check_modules(PC_GUILE QUIET guile-2.2)
+  pkg_check_modules(PC_GUILE QUIET guile-3.0)
   if (NOT PC_GUILE_FOUND)
-pkg_check_modules(PC_GUILE QUIET guile-2.0)
+pkg_check_modules(PC_GUILE QUIET guile-2.2)
+if (NOT PC_GUILE_FOUND)
+  pkg_check_modules(PC_GUILE QUIET guile-2.0)
+endif(NOT PC_GUILE_FOUND)
   endif(NOT PC_GUILE_FOUND)
 endif(NOT PC_GUILE_FOUND)
 
@@ -19,9 +22,9 @@ set(GUILE_DEFINITIONS ${PC_GUILE_CFLAGS_OTHER})
 
 find_path(GUILE_INCLUDE_DIR libguile.h
   HINTS ${PC_GUILE_INCLUDEDIR} ${PC_GUILE_INCLUDE_DIRS}
-  PATH_SUFFIXES guile guile/2.2 guile/2.0)
+  PATH_SUFFIXES guile guile/3.0 guile/2.2 guile/2.0)
 
-find_library(GUILE_LIBRARY NAMES guile guile-2.2 guile-2.0
+find_library(GUILE_LIBRARY NAMES guile guile-3.0 guile-2.2 guile-2.0
  HINTS ${PC_GUILE_LIBDIR} ${PC_GUILE_LIBRARY_DIRS} )
 
 include(FindPackageHandleStandardArgs)
diff --git a/src/guile.h b/src/guile.h
index 26484fb..d1ec12d 100644
--- a/src/guile.h
+++ b/src/guile.h
@@ -21,7 +21,7 @@
 #ifndef GUILE_H
 #define GUILE_H
 
-#include 
+#include 
 
 void initGuileInterface();
 SCM smobAnimated_make(class Animated* a);
-- 
2.29.2

Bug#969684: [PATCH 3/3] Update debian/control for guile-3.0

[Rob Browning]

---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index c84c21c..4348162 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends:
  cmake,
  debhelper (>= 11),
  gettext,
- guile-2.2-dev,
+ guile-3.0-dev,
  libsdl2-dev,
  libsdl2-image-dev,
  libsdl2-mixer-dev,
-- 
2.29.2

Bug#975606: git filter-branch: preserve unchanged signed commits/tags

[Andreas Beckmann]

Package: git
Severity: wishlist
Tags: upstream patch

One of the annoying features of 'git filter-branch' is that it needlessly
rewrites signed commits (and signed tags) even if they would have no other
changes applied to them. That of course causes all their children to be
rewitten for the new parent commit, and so on.

The attached patch works for me as it reduces the amount of rewrites to
the commits that actually need changes to be applied (and their
descendants).

* if the only difference between the old and new commit object is the
  lack of the signature, continue using the old one
* if a tag has both old and new name and underlying old and new commit
  sha1 matching, don't attempt to rewrite the tag

* both cases could be made conditional on a new command line flag
  s.t. default behavior does not change
* the skipped tag rewrite could be wrong in the case
tag2 --> tag1 --> commit0
  where commit0 and tag2 are unmodified but tag1 got rewritten:
  tag2 should be rewritten to point directly to commit0


Andreas
--- /usr/lib/git-core/git-filter-branch 2020-04-20 02:19:12.0 +0200
+++ /home/anbe/bin/git-my-filter-branch 2020-11-23 17:12:40.598592535 +0100
@@ -463,6 +463,21 @@
workdir=$workdir /bin/sh -c "$filter_commit" "git commit-tree" \
"$tree" $parentstr < ../message > ../map/$commit ||
die "could not write rewritten commit"
+   if true
+   then
+   read newcommit < ../map/$commit
+   if test "$commit" != "$newcommit"
+   then
+   git cat-file commit "$newcommit" >../newcommit ||
+   die "Cannot read new commit $newcommit"
+   if sed -e '0,/^$/{/^gpgsig -BEGIN PGP 
SIGNATURE-$/,/^ -END PGP SIGNATURE-$/d}' ../commit | \
+   cmp -s - ../newcommit
+   then
+   echo "preserving unchanged signed commit 
$commit"
+   echo "$commit" > ../map/$commit
+   fi
+   fi
+   fi
 done <../revs
 
 # If we are filtering for paths, as in the case of a subdirectory
@@ -560,6 +575,10 @@
new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
die "tag name filter failed: $filter_tag_name"
 
+   if true; then
+   [ "$ref" = "$new_ref" ] && [ "$sha1" = "$new_sha1" ] && 
continue
+   fi
+
echo "$ref -> $new_ref ($sha1 -> $new_sha1)"
 
if [ "$type" = "tag" ]; then

Bug#974993: Raising severity and offering to NMU package

[Simon Josefsson]

severity 975030 serious
severity 974997 serious
severity 974996 serious
severity 974995 serious
severity 974994 serious
severity 974993 serious
thanks

It was suggested to me on IRC that the severity of this could be
serious because the build-dependency libidn2-0-dev is going to be
removed from Debian.  I'm volunteering to do NMU these packages to fix
the bug, and could look into that in a couple of weeks -- if you give
me permission to do it before, I'd start directly.  If I'm mistaken
that this is not a valid justification for a serious bug, downgrade the
bug and let me know, as I'm not sure what the best way to get an
obsolete deprecated transition package removed from Debian when build-
deps remain.

/Simon



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

Bug#975576: RFS: secondfaqtor/1.2.0-1 [ITP] -- Two-Factor Authenticator

[Andrew Sachen]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "secondfaqtor":

* Package name    : secondfaqtor
  Version : 1.2.0-1
  Upstream Author : Andrew Sachen 
* URL             : 
https://realityripple.com/Software/Applications/SecondFactor/For-Linux/

* License         : Public Domain
* Vcs : https://github.com/RealityRipple/SecondFaqtor
  Section         : contrib/utils

It builds those binary packages:

  secondfaqtor - Two-Factor Authenticator

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/contrib/s/secondfaqtor/secondfaqtor_1.2.0-1.dsc


Changes for the initial release:

  secondfaqtor (1.2.0-1) unstable; urgency=low
  .
  * Removed QT4 support

(Additional change history available from 
https://repo.realityripple.com/debian/all/secondfaqtor_1.2.0-1_all.changelog 
for reference)


Please be aware that this package requires Gambas 3.15. At present, 
Buster only has Gambas 3.12 packages. Therefore, this package should 
only be included in Bullseye and beyond, unless Buster's Gambas package 
is updated to 3.15 or newer.


Also, please note that this package was built using the built-in Gambas 
packaging system on Arch Linux, and may contain archaic (or even 
"ancient") standards.


Regards,

--
- Andrew Sachen
 - RealityRipple Software
 [ https://realityripple.com ]

Bug#975478: [Pkg-puppet-devel] Bug#975478: Use libmariadb-dev instead of legacy libmariadbclient-dev

[Thomas Goirand]

On 11/22/20 7:17 PM, Otto Kekäläinen wrote:
> Package: puppet-module-puppetlabs-mysql
> 
> Hello!
> 
> I noticed the source package has references to libmariadbclient-dev:
> https://salsa.debian.org/search?search=libmariadbclient-dev&project_id=6453&group_id=2572
> 
> This is a deprecated package and you should instead use
> libmariadb-dev[1] or libmariadb-dev-compat if you need to build
> something old that does not find the correct soname otherwise.
> 
> I am not sure if the params.pp is relevant in Debian, but filing this
> just in case.
> 
> Thanks!
> 
> 1: https://packages.debian.org/search?keywords=libmariadb-dev

Hi Otto,

Thanks a lot for this helpful bug report.

It is relevant to Debian. If you read it, you can see:

  case $::osfamily {
[...]
  'Debian': {
if $provider == 'mariadb' {
  $client_dev_package_name = 'libmariadbclient-dev'
  $daemon_dev_package_name = 'libmariadbd-dev'

As I would prefer this puppet module to work with both Buster and
Bullseye, I have to ask: is 'libmariadb-dev' replacing
'libmariadbclient-dev' in both Buster and Bullseye, or only in Bullseye?
Will Bullseye continue to have 'libmariadbclient-dev' as a transition
package for Bullseye (in which case, we may fix the package only after
Bullseye is released)?

Cheers,

Thomas Goirand (zigo)

Bug#975558: Add public domain to copyright types

[Craig Small]

Thanks for the analysis, it was basically what I was thinking about but
hadn't got around to working out a way of describing the problem with
public domain.


On Tue, 24 Nov 2020 at 05:06, Baptiste Beauplat  wrote:

> I'm somewhat unsure about adding this license to dh-make because the
> Public domain license does not seems to be a wildly used choice for
> writing software.
>
It's not used a lot because its a bit vague.  All three of us could write
some license that we think is public domain but it is worded differently.
The problem for dh-make is, which one is the "right" one?

For GPL-2 for example, there is a canonical version of the license.  SPDX
lists several licenses that have public domain in their name.

A quick search on https://sources.debian.org show that barely ~1000
> packages mention "public-domain" in they copyright and most of the time,
> it only apply to a small part of the source code.
>
My guess is they all look different too.


> It would make sense to me to only ship most common licenses in dh-make,
> and thus skip the public domain license. What do you think?
>
dh-make already has a blank license and a custom license (where you feed it
the copyright file). I'm not convinced putting in a best-guess for public
domain license will be helpful.

 - Craig

Bug#975594: RFS: capbattleship/1.0~alpha4-1 -- Sink your enemy before he gets you!

[Paul Wise]

On Mon, Nov 23, 2020 at 10:26 PM Fabien Givors wrote:

>capbattleship - Sink your enemy before he gets you!

I would encourage you to use a more descriptive summary and also avoid
non-inclusive language. I think the summary you used in the ITP was
better for both of these suggestions.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#975601: golang-1.15-go: leaking file descriptors

[Sander van Grieken]

Please disregard the above bugreport. 
I found the issue was caused elsewhere almost immediately after upgrading..
Sorry for the noise :)

Sander

Bug#975591: Canonical method to locally disable an init script?

[Thorsten Glaser]

On Mon, 23 Nov 2020, Jesse Smith wrote:

> I'm the upstream insserv maintainer. The insserv program already has a

This is probably for http://bugs.debian.org/975591 then.

> flag for disabling warnings like the ones you are seeing. The "-q" or
> "--silent" flag should prevent the warnings about runlevels from being

Adding that flag would maybe make sense for the manual-disable
call. But the warning is also output during package installations,
where you most definitively do NOT want to silence any warnings.

> Ask them to pass the "--silent" flag to insserv and the warnings should
> disappear.

Too much would disappear there, though.

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

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

Bug#975605: drawing: Please uplift to v0.6.3

[David Mohammed]

Package: drawing
Version: 0.4.13-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: fossfree...@ubuntu.com

Dear Maintainer,


 v0.6.3 has been tagged for sometime now upstream.  Please consider uplifting 
the version in the Debian archive.

Note - I am happy to work on a debdiff for this if it helps.  Just ask!

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

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

Versions of packages drawing depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gir1.2-gtk-3.0   3.24.23-2
ii  python3  3.9.0-3
ii  python3-gi-cairo 3.38.0-1+b1

drawing recommends no packages.

drawing suggests no packages.

-- no debconf information

Bug#975558: Add public domain to copyright types

[Anatoli Babenia]

Nice. I tried to use Packages Search to get a list of public domain
packages, but https://packages.debian.org/index doesn't search
licenses.

Using 
https://codesearch.debian.net/search?q=public-domain+path%3Adebian%2Fcopyright&literal=0
gives "5310 files grepped (2321 results)". Not sure if that means that
2321 out of 5310 packages contain public domain code.

>From the DFSGLicenses FAQ my use case can be solved with placing this
text into `debian/copyright`.

Copyright: Anatoli Babenia
License: public-domain

As for inclusion in `dh-make`, I think that there should be a simple
way for people to state their will for copyright opt-out for their source
code. Telling people to use different copyright laws that don't provide
opt-out mechanisms to opt-out from those laws looks wrong. WTFPL,
CC-0, Unlicense are all products of that approach that are not
guaranteed to work. Requiring authors to write explanations why they
place their code in public domain looks like a lack of trust to me. I
would state that overcomplicating such a simple thing as public domain
is not in the interests of people who chose to share their code this way.

Bug#975604: RM: protonvpn-cli -- ROM; no longer maintained

[Francisco Vilmar Cardoso Ruviaro]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,
Please, remove the protonvpn-cli from unstable because it is an upstream 
request.
I transcribe below one of our emails:

"Hello Francisco,

My name is ***OMITTED*** and I work at Proton Technologies AG on ProtonVPN as a
linux client developer.
We're in the process of releasing the official CLI client, which is superseding
the current Community contributed one, which will therefore, become obsolete and
no longer maintained nor supported. We are going to host our own
Debian|CentOS|XXX repository, so that users can receive updates in the moment we
are releasing them. After the new client is going to be stable enough we intend
to apply for having it included into the official Debian repositories.
As of the moment, we kindly ask you to remove the present CLI from the official
repository in order to avoid versioning conflicts.

Best regards,
***OMITTED***"

Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00



signature.asc
Description: OpenPGP digital signature

Bug#975603: New upstream release 1.12.0

[Roger Leigh]

Package: xalan-c
Version: 1.11-9

Hi Bill,

This was mentioned on the upstream mailing list earlier in the year.  Just 
opening a bug to track this.

New upstream release 1.12 was made a few months back 
(https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0).  This could be 
packaged to replace the decade-old 1.11 release.  Note that the new release 
brings with it a new CMake-based build system to match Xerces-C.  All the 
configuration options of the old build system are exposed via CMake options.  
It's all documented in the manual: https://apache.github.io/xalan-c/build.html

Kind regards,
Roger

Bug#975602: golang-github-seccomp-libseccomp-golang-dev: Please backport upstream patch adding ActKillProcess and ActKillThread

[Reinhard Tartler]

Package: golang-github-seccomp-libseccomp-golang-dev
Severity: normal
X-Debbugs-Cc: Reinhard Tartler 

For packaging a newer upstream version of buildah, the following upstream patch 
is required:

https://github.com/seccomp/libseccomp-golang/commit/24f29379854785de68bbd44630cc093b22b4dc29

Otherwise the build of buildah fails with:

src/github.com/containers/buildah/chroot/seccomp.go:37:11: undefined: 
seccomp.ActKillProcess




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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#975601: golang-1.15-go: leaking file descriptors

[Sander van Grieken]

Package: golang-1.15-go
Version: 1.15.5-2
Severity: important
X-Debbugs-Cc: san...@outrightsolutions.nl

Dear Maintainer,

Since upgrading from 1.15.2-1 to 1.15.5-2 today on Debian Testing I'm seeing a
steady increase of used file descriptors when running lnd
(github.com/lightningnetwork/lnd).

I tested first without, then with a recompile of lnd against 1.15.5-2, but the
problem is present in both cases.

Downgrading to 1.15.2-1 resolves the issue.

nov 23 12:57:44 host lnd[1689]: 2020-11-23 12:57:43.930 [ERR] BTCN: Can't
accept connection: accept tcp [::]:9735: accept4: too many open files
...snip...
nov 23 12:57:44 host lnd[1689]: 2020-11-23 12:57:43.931 [ERR] BTCN: Can't
accept connection: accept tcp [::]:9735: accept4: too many open files
nov 23 12:58:14 host systemd-journald[289]: Suppressed 93628 messages from
lnd.service




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (750, 'testing'), (700, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages golang-1.15-go depends on:
pn  golang-1.15-src  
ii  libc62.31-4

Versions of packages golang-1.15-go recommends:
ii  g++ 4:10.2.0-1
ii  gcc 4:10.2.0-1
ii  libc6-dev   2.31-4
ii  pkg-config  0.29.2-1

Versions of packages golang-1.15-go suggests:
pn  bzr | brz
ii  ca-certificates  20200601
ii  git  1:2.29.2-1
pn  mercurial
ii  subversion   1.14.0-3+b1

Bug#975600: New upstream release 1.12.0

[Roger Leigh]

Package: xalan
Version: 1.11-9

Hi Bill,

This was mentioned on the upstream mailing list earlier in the year.  Just 
opening a bug to track this.

New upstream release 1.12 was made a few months back 
(https://github.com/apache/xalan-c/releases/tag/Xalan-C_1_12_0).  This could be 
packaged to replace the decade-old 1.11 release.  Note that the new release 
brings with it a new CMake-based build system to match Xerces-C.  All the 
configuration options of the old build system are exposed via CMake options.  
It's all documented in the manual: https://apache.github.io/xalan-c/build.html

Kind regards,
Roger

Bug#975599: ITP: golang-github-manifoldco-promptui -- Interactive prompt for command-line applications

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-manifoldco-promptui
  Version : 0.8.0-1
  Upstream Author : Manifold
* URL : https://github.com/manifoldco/promptui
* License : BSD-3-clause
  Programming Lang: Go
  Description : Interactive prompt for command-line applications

 promptui Interactive prompt for command-line applications.
 .
 Promptui is a library providing a simple interface to create
 command-line prompts for go. It can be easily integrated
 into spf13/cobra (https://github.com/spf13/cobra), urfave/cli
 (https://github.com/urfave/cli) or any cli go application.

This is a new dependency for github.com/containers/image

Bug#975520: [Pkg-net-snmp-devel] Bug#975520: snmp: Performance refression for snmp commands since .index files removal

[Craig Small]

On Mon, 23 Nov 2020 at 20:33,  wrote:

> Package: snmp
> Version: 5.7.3+dfsg-5+deb10u1
> Severity: normal
>
> Since last snmp release 5.7.3+dfsg-5+deb10u1, we detected performance
> regressions on snmpget/walk/bulkwalk (probably all commands). We bisected
> the regression to this patch:
>
> https://github.com/net-snmp/net-snmp/commit/4fd9a450444a434a993bc72f7c3486ccce41f602

Hi,
  Do you know if snmp v5.8 has this same issue? The reason for this is
there may be something else assisting with it and its easier to report this
upstream if it is the current version has the same problem.

I know 5.8 doesn't use that cache, I'm not 100% sure if there is something
else helping fix the problem.

Maybe there could be a way of doing this cache as a per-user thing (under
~/.snmp/* perhaps)?

 - Craig

Bug#972901: fixed in nvidia-graphics-drivers 450.80.02-1

[mando]

Dear maintainers,

The problem is now solved. It turns out that some of these updates were 
not yet available in my previous message.


It's now compiling and working fine with the following packages.

(mando@aldur) (~) $ dpkg -l | grep nvidia
ii  glx-alternative-nvidia 1.2.0  amd64    
allows the selection of NVIDIA as GLX provider
ii  libgl1-nvidia-glvnd-glx:amd64 450.80.02-1    
amd64    NVIDIA binary OpenGL/GLX library (GLVND variant)
ii  libglx-nvidia0:amd64 450.80.02-1    amd64    
NVIDIA binary GLX library
ii  libnvidia-cbl:amd64 450.80.02-1    amd64    
NVIDIA binary Vulkan ray tracing (cbl) library
ii  libnvidia-cfg1:amd64 450.80.02-1    amd64    
NVIDIA binary OpenGL/GLX configuration library
ii  libnvidia-compiler:amd64 450.80.02-1    amd64    
NVIDIA runtime compiler library
ii  libnvidia-glcore:amd64 450.80.02-1    amd64    
NVIDIA binary OpenGL/GLX core libraries
ii  libnvidia-glvkspirv:amd64 450.80.02-1    
amd64    NVIDIA binary Vulkan Spir-V compiler library
ii  libnvidia-ml1:amd64 450.80.02-1    amd64    
NVIDIA Management Library (NVML) runtime library
ii  libnvidia-ptxjitcompiler1:amd64 450.80.02-1    
amd64    NVIDIA PTX JIT Compiler
ii  libnvidia-rtcore:amd64 450.80.02-1    amd64    
NVIDIA binary Vulkan ray tracing (rtcore) library
ii  nvidia-alternative 450.80.02-1    amd64    
allows the selection of NVIDIA as GLX provider
ii  nvidia-installer-cleanup 20151021+12    amd64    
cleanup after driver installation with the nvidia-installer
ii  nvidia-kernel-common 20151021+12    amd64    
NVIDIA binary kernel module support files
ii  nvidia-kernel-dkms 450.80.02-1    amd64    
NVIDIA binary kernel module DKMS source
ii  nvidia-kernel-support 450.80.02-1    amd64    
NVIDIA binary kernel module support files
ii  nvidia-legacy-check 450.80.02-1    amd64    
check for NVIDIA GPUs requiring a legacy driver
ii  nvidia-modprobe 450.66-1   amd64    utility 
to load NVIDIA kernel modules and create device nodes
ii  nvidia-opencl-common 450.80.02-1    amd64    
NVIDIA OpenCL driver - common files
ii  nvidia-opencl-icd:amd64 450.80.02-1    amd64    
NVIDIA OpenCL installable client driver (ICD)
ii  nvidia-persistenced 450.57-1   amd64    
daemon to maintain persistent software state in the NVIDIA driver
ii  nvidia-settings 450.80.02-1    amd64    tool for 
configuring the NVIDIA graphics driver
ii  nvidia-smi 450.80.02-1    amd64    NVIDIA System 
Management Interface
ii  nvidia-support 20151021+12    amd64    NVIDIA 
binary graphics driver support files
ii  nvidia-vdpau-driver:amd64 450.80.02-1    
amd64    Video Decode and Presentation API for Unix - NVIDIA driver
ii  nvidia-vulkan-common 450.80.02-1    amd64    
NVIDIA Vulkan driver - common files
ii  nvidia-vulkan-icd:amd64 450.80.02-1    amd64    
NVIDIA Vulkan installable client driver (ICD)
ii  xserver-xorg-video-nvidia 450.80.02-1    
amd64    NVIDIA binary Xorg driver


Thanks, best regards

Bug#975598: ITP: plasma-systemmonitor -- System monitor for the Plasma desktop

[Aurélien COUDERC]

Package: wnpp
Severity: wishlist
Owner: Aurélien COUDERC 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: plasma-systemmonitor
  Version : 5.20.0
  Upstream Author : Plasma Developers 
* URL : https://apps.kde.org/en/plasma-systemmonitor
* Licenses: GPL-2 or GPL-3 or any later version
accepted by the membership of KDE e.V.
LGPL-2.1 or LGPL-3 or any later version
accepted by the membership of KDE e.V.
  Programming Lang: C++, QML
  Description : System monitor for the Plasma desktop

Plasma System Monitor provides an interface for monitoring system sensors,
process information and other system resources.


The package will be maintained under the Debian Qt/KDE Maintainers
team’s umbrella.

Bug#975596: dput-ng: traceback with ssh-upload when python3-gssapi is installed

[Vagrant Cascadian]

Package: dput-ng
Version: 1.25+deb10u1
Severity: normal

Thanks for maintaining dput-ng!

I've been uploading packages to Debian for years with this method, but
it stopped working when I installed another package which pulled in
python3-gssapi, and seems to work again when I remove python3-gssapi (or
at least, gets further in the process).


$ torsocks dput --debug --debug ssh-upload ../guix_1.2.0-1_source.changes
[DEBUG] 1606168132.471922: (load_config) Loading configuration: profiles
DEFAULT
[TRACE] 1606168132.472011: (load_config) Checking for configuration:
skel/
[TRACE] 1606168132.472100: (load_config) Checking -
skel//profiles/DEFAULT.json
[TRACE] 1606168132.472217: (get_config) name: DEFAULT - {} / {'default':
{}, 'configs': ['skel/'], 'config_cleanup': False}
[DEBUG] 1606168132.472305: (load_config) Loading configuration: profiles
DEFAULT
[TRACE] 1606168132.472378: (load_config) Checking for configuration:
/usr/share/dput-ng/
[TRACE] 1606168132.472457: (load_config) Checking -
/usr/share/dput-ng//profiles/DEFAULT.json
[TRACE] 1606168132.472544: (get_config) name: DEFAULT - {} / {'default':
{}, 'configs': ['/usr/share/dput-ng/'], 'config_cleanup': False}
[DEBUG] 1606168132.472609: (load_config) Loading configuration: profiles
DEFAULT
[TRACE] 1606168132.472663: (load_config) Checking for configuration:
/etc/dput.d/
[TRACE] 1606168132.472716: (load_config) Checking -
/etc/dput.d//profiles/DEFAULT.json
[DEBUG] 1606168132.472907: (load_config) Loading configuration: metas
boring
[TRACE] 1606168132.472968: (load_config) Checking for configuration:
/usr/share/dput-ng/
[TRACE] 1606168132.473025: (load_config) Checking -
/usr/share/dput-ng//metas/boring.json
[TRACE] 1606168132.473091: (load_config) Checking for configuration:
/etc/dput.d/
[TRACE] 1606168132.473145: (load_config) Checking -
/etc/dput.d//metas/boring.json
[TRACE] 1606168132.473300: (load_config) Checking for configuration:
/home/vagrant/.dput.d
[TRACE] 1606168132.473344: (load_config) Checking -
/home/vagrant/.dput.d/metas/boring.json
[TRACE] 1606168132.473410: (load_config) Checking for configuration:
skel/
[TRACE] 1606168132.473463: (load_config) Checking -
skel//metas/boring.json
[TRACE] 1606168132.473535: (load_config) Ignoring key allow_dcut for
boring (False)
[TRACE] 1606168132.473609: (get_config) name: DEFAULT - {'allow_dcut':
False, 'allow_unsigned_uploads': False, 'allowed_distributions':
'(?!UNRELEASED)', 'default_host_main': '', 'full_upload_log': False,
'hash': 'sha1', 'interface': 'cli', 'login': '*', 'meta': 'boring',
'method': 'ftp', 'passive_ftp': True, 'post_upload_command': '',
'pre_upload_command': '', 'run_lintian': False, 'scp_compress': True,
'allowed-distribution': {}, 'codenames': None, 'hooks':
['allowed-distribution', 'checksum', 'suite-mismatch', 'gpg']} /
{'default': {}, 'configs': ['/etc/dput.d/'], 'config_cleanup': False}
[DEBUG] 1606168132.473837: (preload) Skipping file /etc/dput.cf: Not
accessible
[DEBUG] 1606168132.473920: (load_config) Loading configuration: profiles
DEFAULT
[TRACE] 1606168132.473972: (load_config) Checking for configuration:
/home/vagrant/.dput.d
[TRACE] 1606168132.474026: (load_config) Checking -
/home/vagrant/.dput.d/profiles/DEFAULT.json
[TRACE] 1606168132.474098: (get_config) name: DEFAULT - {} / {'default':
{}, 'configs': ['/home/vagrant/.dput.d'], 'config_cleanup': False}
[DEBUG] 1606168132.474262: (preload) Skipping file
/home/vagrant/.dput.cf: Not accessible
[TRACE] 1606168132.474577: (get_config) Loading entry ssh-upload
[DEBUG] 1606168132.474633: (load_config) Loading configuration: profiles
ssh-upload
[TRACE] 1606168132.474692: (load_config) Checking for configuration:
skel/
[TRACE] 1606168132.474747: (load_config) Checking -
skel//profiles/ssh-upload.json
[TRACE] 1606168132.474817: (get_config) name: ssh-upload - {} /
{'default': {}, 'configs': ['skel/'], 'config_cleanup': False}
[TRACE] 1606168132.474872: (get_config) {'name': 'ssh-upload'}
[TRACE] 1606168132.474934: (get_config) Rewrote to:
[TRACE] 1606168132.474983: (get_config) {'name': 'ssh-upload'}
[DEBUG] 1606168132.475040: (load_config) Loading configuration: profiles
ssh-upload
[TRACE] 1606168132.475090: (load_config) Checking for configuration:
/usr/share/dput-ng/
[TRACE] 1606168132.475142: (load_config) Checking -
/usr/share/dput-ng//profiles/ssh-upload.json
[TRACE] 1606168132.475210: (get_config) name: ssh-upload - {} /
{'default': {}, 'configs': ['/usr/share/dput-ng/'], 'config_cleanup':
False}
[TRACE] 1606168132.475261: (get_config) {'name': 'ssh-upload'}
[TRACE] 1606168132.475321: (get_config) Rewrote to:
[TRACE] 1606168132.475369: (get_config) {'name': 'ssh-upload'}
[DEBUG] 1606168132.475425: (load_config) Loading configuration: profiles
ssh-upload
[TRACE] 1606168132.475475: (load_config) Checking for configuration:
/etc/dput.d/
[TRACE] 1606168132.475526: (load_config) Checking -
/etc/dput.d//profiles/ssh-upload.json
[DEBUG] 1606168132.475678: (load_config) Loading configuration: metas
debian
[TRACE] 1606168132.

Bug#975343: clevis encrypt tang fails with "Key derivation key not available!"

[Christoph Biedl]

Control: tags 975343 confirmed

Dominique Dumont wrote...

> When using tang on armhf, clevis fails:
> 
> $ echo foo | clevis encrypt tang '{"url": "http://192.168.1.14"}' > bar.txt
> The advertisement contains the following signing keys:
> 
> jvCF5[...]8s5A
> 
> Do you wish to trust these keys? [ynYN] y
> Key derivation key not available!

That's bad. The cause is probably tang, and also in buster. I'll do more
checks and will act according to my findings.

Thanks for reporting,

Christoph


signature.asc
Description: PGP signature

Bug#975570: ITP: capbattleship -- Sink your enemy! - A (pretty) pirate battleship board game.

[Fabien Givors (Debian)]

Package: wnpp
Severity: wishlist
Owner: Fabien Givors 
X-Debbugs-Cc: debian-de...@lists.debian.org, f+deb...@chezlefab.net

* Package name: capbattleship
  Version : 1.0~alpha2
  Upstream Author : Fabien Givors and Damien Monteillard 


* URL : https://capbattleship.tuxfamily.org/
* License : MIT (code) + CC-BY-4.0 (music) + CC0-1.0 (artworks)
  Programming Lang: Python3 + Pygame
  Description : Sink your enemy! - A (pretty) pirate battleship 
board game.


Capbattleship is a pirate themed modern implementation of the classic 
turn-based

battleship board-game, featuring amazing graphics and cool music.

I beleive this package should be included in Debian because:
- it's more graphical and accessible to children
- there is an imersive pirate theme
- it has very little dependencies

I would like to maintain this package inside the Debian Games Team.

I am looking for a sponsor.

Bug#733622: bogofilter: Crash on several emails with realloc(): invalid next size

[Maxime Arthaud]

On Thu, 7 May 2020 16:19:11 +0200 Matthias Andree 
 wrote:

> https://sourceforge.net/p/bogofilter/bugs/116/#52a0
>
> i. e. this was fixed 91 commits before bogofilter-1.2.5.rc1. I don't
> know if the commit (Git cd33fc00802a75fe7b3b8a967bf879f7bc33c320) works
> standalone or only in context, and I'm not researching this because for
> me as upstream maintainer, this is done with the 1.2.5 release.
>
> => I think someone should package 1.2.5 for sid/unstable... more than
> half a year after its release.


I'm still seeing these errors 6 months later. Is something preventing it 
from being pushed on buster?



Best regards,

--
Maxime Arthaud

Bug#975593: python-mapnik: FTBFS against boost_1.74

[Anton Gladky]

Package: python-mapnik
Version: 1:0.0~20200224-7da019cf9-2
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

/usr/include/boost/spirit/home/karma/nonterminal/rule.hpp:140:9: error: static 
assertion failed: Const/reference qualifiers on Karma rule attribute are 
meaningless
  140 | BOOST_STATIC_ASSERT_MSG(
  | ^~~
error: command '/usr/bin/c++' failed with exit code 1

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/python-mapnik_0.0~20200224-7da019cf9-2_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+8J9YRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wZ0YxAAmZvzsgAVA8mkgzStbF/gCqavZ1zBYUQm
byC0mKUvGIPDvma9L1fxa3S/49vdTkkPnRdMx21KYcjmHVArg5SJ08uqQdF4X4EN
uQbBrw0skFemSQR+zWoWBWcmERQRipJTuKHyGm6U7ttpn5zxj4GNtxVGgOrMZRS7
jzhpoXJ3l3agQkqmAq3BJLxUaFZNpqJcWoqm8YjhVjD9cfPus7cYxKJKKnj0PlqP
/Z1fw9CqgfRoNu8Jn2stp/eKql8rwWnF8CvRFpuEBx/1jpVyXMJUevJ8AaXc10Ga
HSLw4VaD7kObGgZXpWTsdk0i65L2gXkpraNaq9ZjKbV85v9bf+kIfxZUoBQ1uV3E
l5NWlqd0xmVclIlzSSNdPKsR9W+Sac1j1+iSTHecYmvEGUYAfnwc4JQE4N+XIT5B
X725LBI60fgQTnNO2u+WyzHM8u0BBFEzcuLsgkiI4XJiNeQHPF2pJHJK1cVWpQZX
z6jDJwjRUI9c1xBhx19ZUrBYyGTgOZkLihW6+DP6QEGfF2acXLongRH1pT5A7CcF
VKyqP/sS5ueljiqgEUyoe8Nn+T/oyF4jPjMwmAw3YB7ZBqWqfR7TnCbP+C2sio2I
rWoW8kDlOLhkR1VMQk3O3xjoMSGc78bBZvZQGTglor5Cz9jf23l+qQ7XS7rv/fte
H5w/EeS8LCM=
=rPNd
-END PGP SIGNATURE-

Bug#975592: pdns-recursor: FTBFS against boost_1.74

[Anton Gladky]

Package: pdns-recursor
Version: 4.3.5-1
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

/usr/include/boost/mpl/aux_/preprocessed/gcc/placeholders.hpp:42:16: note:   
‘mpl_::_2’
   42 | typedef arg<2> _2;
  |^~
webserver.cc: In member function ‘void WebServer::registerWebHandler(const 
string&, WebServer::HandlerFunction)’:
webserver.cc:199:74: error: ‘_1’ was not declared in this scope

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/pdns-recursor_4.3.5-1_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+8JvIRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wZ7NRAAhBsT+LJ1Uzw+CgxVNJb+E2lQl6iNkIuP
jPDFFcYMJEhgRP/cFaB9rdRXKAF7FMICiInPPgN/JNrYO50gM0ZV9LOoczJHIrwg
hyVi/ejgkMLWrVHgPiWKGjoQj7cWqlX8ruljjL+8lmL2o/rPYjpRRME+eohja2rC
gFwfOnw6VsJ0BCDBJAbD5I+e9AEx5GjGKFO0eY7phF6yZndxfI1jx+Awog7tYtHs
NcvMC26hFZDueOlUcwNugvfUfHaBZtdG4YGMIz5Wr2bZ6n0s6BPF5INYjvDHWcWY
SK3FfZw+UzcPpW/qTGlfLigYAz+eWG1NQ/y6u63Fj4ulGRZlb8DQs2Sr/r9TmhTM
2j+577owjFRkzrhOauvcJLOd3hwDG2if7iwtf/ku7BbfaH/YynG0zHSFQ86jfIPR
fyEwl+8zIhv0vrvEckBzeplJO0Wdf2xv+0iNrqbCdhTP7b60XDauLAd/Yxt2EQiZ
m9TviA4QIo2+hRnUqH/YNSCM+97vcXgZDbxH+QeZeK1iPHpkYp/fxc+wWeXgRljH
vtZW/MOSN6KcpCvSJFn6r3OY7whJzHf8ZXn6zrJ3+s+YhWRr8JWZ0a1sqAvGTOk4
IjnrOMisoPUp3JD4xzJUcEdjQ2hF8McGLGTSTbQxWmRM+ruMVE2lbehYVqCyaM9I
WiRCQ/UtFDg=
=2Uj5
-END PGP SIGNATURE-

Bug#975591: insserv: warns too loudly when local admin disables a script (…overrides LSB defaults…)

[Thorsten Glaser]

Package: insserv
Version: 1.21.0-1
Severity: wishlist
X-Debbugs-Cc: t...@mirbsd.de, pkg-systemd-maintain...@lists.alioth.debian.org

Cc’ing init-system-helpers maintainer address, as
parts of this probably affect it as well.

From a discussion on debian-init-diversity, using…

sudo /usr/sbin/update-rc.d -f $initscriptname disable

… is the “correct” way for the local administrator
to disable the init script. This, however, causes
loud warnings not only running that command, but
during package upgrades as well:

insserv: warning: current start runlevel(s) (empty) of script 
`rng-tools-debian' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
`rng-tools-debian' overrides LSB defaults (0 1 6).
insserv: warning: current start runlevel(s) (empty) of script 
`rng-tools-debian' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
`rng-tools-debian' overrides LSB defaults (0 1 6).

First, this warning is shown twice each, which is
probably a (cosmetic) bug.

Second, this warning shouldn’t be shown if a local
administrator has (deliberately) disabled a script.

If you think that, as Lorenzo said, it’s important
telling the admin that their local setup differs
from maintainer defaults, then please special-case
the “admin specifically disabled the script manually”
case from others, and issue a message e.g. like:

insserv: reminder: the script “rng-tools-debian” was disabled by the local 
administrator.

(And also please do *not* use the grave accent ‘`’
for anything. That’s typographically just wrong.)

If at all. Other tools don’t periodically warn if
the local administrator changes a configuration
file.



If, however, update-rc.d disable is _not_ the current
“proper” way of disabling an init script locally, then
please document which it is. People recently adviced
using update-rc.d remove instead, which doesn’t survive
package upgrades and therefore isn’t stable enough.
(Probably best to document these in the update-rc.d(8)
manpage anyway, and which survive package upgrades.)


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

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

Versions of packages insserv depends on:
ii  libc6  2.31-4

insserv recommends no packages.

Versions of packages insserv suggests:
pn  bootchart2  

-- no debconf information

Bug#975590: pdns: FTBFS against boost_1.74

[Anton Gladky]

Package: pdns
Version: 4.3.1-1
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

ixfrdist-web.cc: In constructor ‘IXFRDistWebServer::IXFRDistWebServer(const 
ComboAddress&, const NetmaskGroup&, const string&)’:
ixfrdist-web.cc:35:90: error: ‘_1’ was not declared in this scope
   35 |   d_ws->registerWebHandler("/metrics", 
boost::bind(&IXFRDistWebServer::getMetrics, this, _1, _2));
  |  

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/pdns_4.3.1-1_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+8JkYRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wbeJw//f5wTz+7LIZOsJD2RXVTR2cEJudqNOihw
IDnu7kqgCG+C6s7qNLu7cKqai+4b0xWHkGYyynfkrv0OFg7xKrhrewo42jVClcnP
DHiyA/fHO14u88+G+jWaU7GJ0oKPW+0wQWZE+5TER3xLRk1gQIAzzyBubUsdzXec
WLGBZVd0bd/J9fopE/bnqkxNmlvcOTquhO/h3ysddr9Dcp9uz6Af4FKygqFd1ePn
aPOlj+rmV3HFyQL6IT9odmIo2UPGG0jH3t9LVHRMd7YkOY94L/Wi+GNNIXDXHIT/
LASRWMU1he2i4i/z1tMdOByZMMAHJ6mQ1KUudMRiAIy/1iuHGsqr8Qf2zUDzGWES
S+7y/YnUpA3EIKontpin7zLh353Zwx3uz0LB8v64XpFvkBpt/FCDA9XSJ9AH9pzB
5GlzH5hpyC9y3nn0HTTGF1jCLxtOFWrs4BRfCFeLkKh5rg/lTai2WpPmIUI1FWt+
KcNMHJL0q9pI0fFYGSD9aUZN/1vt9p9kmEFvxuWCU4vOwclq2l2FhsdAcgpgcDfv
odrsdrN6ADfAjWdEPHoSoUnkbmkGuls44QQQcrXEJkPBA2ARbveVtmbmrOJsu8vz
/JEPQZX2hfBC5v4nO7L+i8NsWqO+XT0cRU4gRxgxGZX8SlZ20eGWXT31c7tJN6i+
akuHeBx5Rno=
=oyJb
-END PGP SIGNATURE-

Bug#975589: transition: gnat-10

[Nicolas Boulenguez]

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

Hello.

The gcc-$V source package builds the Ada compiler (gnat-$V) and
companion libraries (libgnat-$V and libgnat_util-$V).
The default Ada compiler is selected by the gnat package.
In unstable, gnat Depends: gnat-9.
In experimental, gnat Depends: gnat-10.

Ada libraries have specific requirements.
* They must Build-Depend: gnat-$V (in addition to gnat).
* Each -dev package name carries a version, similar to the shared
  object version for lib packages.  Most changes in the source require
  a renaming of the -dev package, and a source upload of all reverse
  dependencies.
In order to reduce the number of such transitions, many unrelated
changes, like new upstream releases, are introduced with a libgnat
transition and tested in experimental.

Ben file:

title = "gnat-10";
is_affected = .depends ~ "libgnat-8" | .depends ~ "libgnat-9" | .depends ~ 
"libgnat-10";
is_good = .depends ~ "libgnat-10";
is_bad  = .depends ~ "libgnat-8" | .depends ~ "libgnat-9";

The affected source packages are:

adabrowse
adacgi
adacontrol
adasockets
ahven
anet
asis
dbusada
dh-ada-library
gprbuild
libalog
libaunit
libaws
libflorist
libgmpada
libgnatcoll
libgnatcoll-bindings
libgtkada
liblog4ada
libncursesada
libtemplates-parser
libtexttools
libxmlada
libxmlezout
pcscada
plplot

libgnatcoll-db/21.0.0-3 fails to build on mipsel in experimental, and
sometimes on mips64el (#971018, reported at
https://lists.debian.org/debian-mips/2020/09/msg00010.html).
It won't migrate from unstable to testing.
19.2-3 in testing depends on gnat/9 and will block the transition.
Please remove libgnatcoll-db/19.2-3 from testing.

gnat-gps is removed from testing and RC-buggy in unstable because it
depends on python2 (and libgnatcoll-python below).
Version 19.2-3 in unstable does not build with gnat-10, and fixing
this would be wasted work.
Version 20 is not ready, and won't be part of next release anyways, so
the best option is probably to remove it from unstable for now.  It
needs a passage through the NEW queue anyways for unrelated reasons.
Please remove gnat-gps/19.2-3 from unstable.

libgnatcoll-python is removed from testing and RC-buggy in unstable
because it depends on python2 (upstream is working on this).
For now, it builds with gnat-10 and python2 in experimental.
It won't be part of next release, but can be updated like normal
packages and should not prevent the migration of other packages.

These packages mention no versioned -dev.  They will only need a
rebuild once their dependencies are available in unstable.
nmumusic123_16.6-1 . ANY . -m 'Rebuild with gnat-10)'
nmu   topal_80-1   . ANY . -m 'Rebuild with gnat-10)'
nmu whitakers-words_0.2020.10.27-1 . ANY . -m 'Rebuild with gnat-10)'

The gcc-$V and ghdl packages Build-Depend on an explicit gnat version,
but not on the default compiler.
They are not affected.

The ada-reference-manual package requires an Ada compiler for an
intermediate documentation formatter.
It is not affected.

When would a reupload to unstable be appropriate?

Bug#975588: openms: FTBFS against boost_1.74

[Anton Gladky]

Package: openms
Version: 2.5.0+cleaned1-5
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[  0%] Building CXX object 
src/openswathalgo/CMakeFiles/OpenSwathAlgo.dir/source/OPENSWATHALGO/ALGO/Scoring.cpp.o
cd /<>/obj-x86_64-linux-gnu/src/openswathalgo && /usr/bin/c++ 
-DBOOST_ALL_NO_LIB -DOpenSwathAlgo_EXPORTS 
-I/<>/src/openswathalgo/include 
-I/<>/obj-x86_64-linux-gnu/src/openswathalgo/include 
-I/<>/src/openswathalgo/thirdparty/MIToolbox/include 
-I/<>/src/openswathalgo/thirdparty/MIToolbox/src -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -O3 -DNDEBUG -fPIC 
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra 
-Wno-non-virtual-dtor -Wno-unknown-pragmas -Wno-long-long -Wno-unused-function 
-Wno-variadic-macros -fPIC -o 
CMakeFiles/OpenSwathAlgo.dir/source/OPENSWATHALGO/ALGO/Scoring.cpp.o -c 
/<>/src/openswathalgo/source/OPENSWATHALGO/ALGO/Scoring.cpp
/<>/src/openswathalgo/source/OPENSWATHALGO/ALGO/Scoring.cpp: In 
function ‘std::vector OpenSwath::Scoring::computeRank(const 
std::vector&)’:
/<>/src/openswathalgo/source/OPENSWATHALGO/ALGO/Scoring.cpp:268:12:
 error: ‘sort’ is not a member of ‘std’; did you mean ‘sqrt’?
  268 |   std::sort(v_sort.begin(), v_sort.end());
  |^~~~
  

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/openms_2.5.0+cleaned1-5_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+8JXsRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYoYQ//TKkScf0L06uJCoZIrgH3VbEaH6Feksij
Xpeh3bZYBvriZNIZ1RLFw03r5KlXwxoabenmJgSN5GhxntYijNshe2PhiTHQAdBq
RND4q1Rtgzor462lP/RyrweE3vrQHe9gkMULjxjERm/FmAkAXmxqh/mPZ67aQr9U
EEtS6cXoZdK6cZNwNwaAFHXzGkjnAkb7W6m5bpEryJLm5AbJKVK1wqI0KNuiu9NO
xQtjQRcMdwejZB8H8szWYPzQZFLhTHAVoQQ8pODC9qa2jUagOn4hTMvEVjiDmCG8
Zjrz8H3DJAZD0dzCLZjRNgxz24K73gk1PZnaPJr7u3TlScYKt8sIhwPMwQcwmCWv
FM7DxV6JABzHYt9k8TLGGCL7jzraMRm76S5Cq88AIQbnMuqcoRVilTql1SqnWGeP
aTIVRWUXltQHpnxyIDrgozWe2u6L8rKuq4MuNFe2Z/DnWE0NY0eQrprnRAiawOm2
zWQlbYHx3+V+Tjn74Dnbgykz/UO63jNew/I/lfWw/GdMBWmJNF6rGCccNAEBbkG1
y1ocj5Ya6/gwp6aUtGJLHL2uF8UF71K2fymycgqyaUzr+aarCSresQgdlHOF4qJW
3GgEwusgWng4Jryq3bhZ9pB8IY7WDpd8x3/74XB8zm7f8kdda89ufL9SsMGE6+XS
crtQhA7s4Hc=
=GwY7
-END PGP SIGNATURE-

Bug#975587: odil: FTBFS against boost_1.74

[Anton Gladky]

Package: odil
Version: 0.12.0-2
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[  1%] Building CXX object src/CMakeFiles/libodil.dir/odil/Association.cpp.o
cd /<>/build/src && /usr/bin/c++ -DBOOST_ALL_NO_LIB 
-DBOOST_ATOMIC_DYN_LINK -DBOOST_CHRONO_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK 
-DBOOST_FILESYSTEM_DYN_LINK -DBOOST_LOG_DYN_LINK -DBOOST_REGEX_DYN_LINK 
-DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -Dlibodil_EXPORTS 
-I/<>/src -I/usr/include/jsoncpp -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -fPIC   -D 
BOOST_ASIO_SEPARATE_COMPILATION -D ODIL_MAJOR_VERSION=0 -D BOOST_ALL_DYN_LINK 
-o CMakeFiles/libodil.dir/odil/Association.cpp.o -c 
/<>/src/odil/Association.cpp
In file included from /<>/src/odil/Reader.h:19,
 from /<>/src/odil/Association.cpp:36:
/<>/src/odil/endian.h:12:10: fatal error: boost/detail/endian.hpp: 
No such file or directory
   12 | #include 
  |  ^   ^

Maybe just changing the header to  can fix the 
problem.


It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/odil_0.12.0-2_unstable_boost.log


Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+8JM4RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYEXw//WrXkywu3Fl9jUaw3kulM7zF4s0x0nhk1
pPrGhN0ipCIpvgBSLKz4O82COmuMx0d5db+fbJVDw2Jm7N/1ycU6EYVKbgHBlT+N
YP18ilUZA4V7nsu9UjcFzeKVTDdY80LlbGD2gCgBtTPCQxtRPCLZBU2WCodV774f
xu9/5C37hFtHoVS5u1bR/wzSyWv678yM6xrbXWJPIEwUgsgqWiLpjzIGJrFiUiP8
4wGObkxDfZkr7m7AnVJgJEYdqhWSxH+ViI4al1+VpXoMROJcdVyYG9CqKXkzh5bF
kawTMBlWUU3zHFtbQ7O+Z+nLKeEpbtUFAsJiqgTU+M2yXtI0Tvqwgq75lL4I1nKX
Yt3uOraHl7pCcRewppdlueGvfxPBMGZrOtRQfVWB8zGEpUmAEZF8aXAu9C5uJ54p
Pjs6ip9LQ9KJC2tONqtE6Jf6qFJ6KrGFGgInFiehfWQyxG02PyTVBq3vHONg1eRv
nrMXoBobbInDhpo8rgSfzkl/aV9H1+kf4CKnYQOx8FlgoKnyqM+iBS6aDoqbybR4
htRq7swINsFCQ1Oe/f8BsUQj+Nd783bjQf66q0X0xZRJn+HxqlPFjzPpuzh1KTIc
EyeaW3l6ITV7x0/MaGQ6cPyZuzWNWQGvKTPz9C0B3QC3l1gpafrqkrl5FC9etKrC
/yl8NTR1pIc=
=VDRg
-END PGP SIGNATURE-

Bug#958344:

[Yoon Khe]

Thirded.

Bug#651587: GIMP non-stable release supports GTK 3

[John Scott]

Control: tags -1 fixed-upstream

GIMP 2.99.2 was released a few weeks ago and brings GTK 3. The primary 
showstoppers appear to be rapid memory leaks on Wayland and giving time for 
the API to solidify.

Seeing as they mostly need help searching and researching bugs I would gladly 
give it a go if someone made an upload to experimental. 2.99.4 may be just 
around the corner: https://gitlab.gnome.org/GNOME/gimp/-/milestones/10

For these development releases they're also making tarballs:
https://download.gimp.org/mirror/pub/gimp/v2.99/

https://www.gimp.org/news/2020/11/06/gimp-2-99-2-released/#gtk3-based-ui

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

Bug#975586: ITP: golang-github-leemcloughlin-jdn -- Julian Day Numbers for Golang Go

[Chris Keller]

Package: wnpp
Severity: wishlist
Owner: Chris Keller 

* Package name: golang-github-leemcloughlin-jdn
  Version : 0.0~git20201102.6f88db6-1
  Upstream Author : Lee McLoughlin 
* URL : https://github.com/leemcloughlin/jdn
* License : Expat
  Programming Lang: Go
  Description : Julian Day Numbers for Go

 Julian Day Numbers for Go

Bug#975585: vsftpd: FTBFS on hurd-i386

[Svante Signell]

Source: vsftpd
Version: 3.0.3-12
Severity: important
Tags: ftbfs, patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

vsftpd fails to install due to usage of a ps -C in vsftpd.init, which
does not exist for GNU/Hurd. The attached patch,
debian_vsftpd.init.patch, fixes this problem. The patch uses pidof
instead of ps; therefore an added build dependency of sysvinit-utils is
needed. That patch is also attached as debian_control.patch.

Due to the non-installability of vsftpd.init the build dependencies of
pycurl-7.43.0.6-4 fails, making that package no buildable.

Thanks!
--- a/debian/control	2019-03-06 07:52:35.0 +0100
+++ b/debian/control	2020-11-23 17:48:25.0 +0100
@@ -7,7 +7,8 @@
  libcap2-dev [linux-any],
  libpam0g-dev,
  libssl-dev,
- libwrap0-dev
+ libwrap0-dev,
+ sysvinit-utils
 Standards-Version: 4.3.0
 Homepage: http://vsftpd.beasts.org/
 
--- a/debian/vsftpd.init	2019-03-06 07:51:33.0 +0100
+++ b/debian/vsftpd.init	2020-11-23 12:23:30.0 +0100
@@ -51,7 +51,7 @@
 		while [ ${n} -le 5 ]
 		do 
 			_PID="$(if [ -e /var/run/vsftpd/vsftpd.pid ]; then cat /var/run/vsftpd/vsftpd.pid; fi)"
-			if ps -C vsftpd | grep -qs "${_PID}"
+			if `pidof vsftpd | tr '' '\n' | grep -oqs "${_PID}"`
 			then
 break
 			fi
@@ -59,7 +59,7 @@
 			n=$(( $n + 1 ))
 		done
 
-		if ! ps -C vsftpd | grep -qs "${_PID}"
+		if `! pidof vsftpd | tr '' '\n' | grep -oqs "${_PID}"`
 		then
 			log_warning_msg "vsftpd failed - probably invalid config."
 			exit 1

Bug#975584: consul: CVE-2020-28053

[Salvatore Bonaccorso]

Source: consul
Version: 1.7.4+dfsg1-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/hashicorp/consul/issues/9240
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for consul.

CVE-2020-28053[0]:
| HashiCorp Consul and Consul Enterprise 1.2.0 up to 1.8.5 allowed
| operators with operator:read ACL permissions to read the Connect CA
| private key configuration. Fixed in 1.6.10, 1.7.10, and 1.8.6.


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-2020-28053
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28053
[1] https://github.com/hashicorp/consul/issues/9240

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#972256: ccache: please add symlink for emcc (emscripten)

[Joel Rosdahl]

Hi Jonas,

I've had a quick look at emcc now. I don't feel comfortable adding a ccache
symlink for it without some kind of evaluation of how emcc's options interact
when using the "-c" mode -- a symlink in /usr/lib/ccache would signal that
ccache officially supports emcc, which it doesn't (yet).

>From "emcc --help" I see that the following options take an argument, which is
something that ccache would need to be taught about to work properly:

--closure
--js-transform
--llvm-opts
--memory-init-file
--minify
--output_eol
--source-map-base
--valid-abspath
-s

On the other hand, perhaps none of these are applicable (or used in practice)
when using "-c", but that's not something I can rule out.

This option definitely isn't compatible with ccache since it changes the output
filename:

--default-obj-ext

These options take an argument that refers to an input file which ccache should
read and hash separately as part of the input:

--embed-file
--exclude-file
--extern-post-js
--extern-pre-js
--js-library
--post-js
--pre-js
--preload-file
--shell-file

Again, maybe none of those are applicable when using "-c" but I can't really
tell.

These produce another output file which would need to be cached by ccache:

-gseparate-dwarf
--emit-symbol-map

They don't seem to have any effect when using "-c", though?

Some environment variables (EMMAKEN_CFLAGS, EMCC_CLOSURE_ARGS) maybe also need
special treatment?

Regards,
Joel

On Thu, 15 Oct 2020 at 12:39, Jonas Smedegaard  wrote:
>
> Package: ccache
> Version: 3.7.12-1
> Severity: normal
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> The emcc command part of emscripten supports ccache:
> https://github.com/emscripten-core/emscripten/issues/11974
>
> Please ship the Debian ccache package with symlink for emcc.
>
>  - Jonas
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+IJmQACgkQLHwxRsGg
> ASHfYQ/8DGUQ8OMRwT2w/SSnFpkTghr0TkNbEb45YwAY8xuSL0oAQR5+roQ313Nj
> oBGBovDd1lDa/D3uOuCfcLkNxH3C4s0hvZ/fh38XU1QN9F2HZWfkzpvaL5FGbt7+
> GbRtwxPRAu8NwJkwvecQKKRNEAyS/pLdQ1U04ephVjDsNh4dTn7nS2pEOUfO/Dwo
> 6UiU+FMupQDq0EaSPpakczFSZRRdtaBuBYkBuHVkMUild3GVrQZr5pOFogF+S823
> hsnvMmkmaZ1PEpOueU0iD8Yvj8k2EO5nT5iN3+b9vm/o2HezKDNC1YchhjmBjjxL
> oQF1TOeAl+E5WZDKx/9TVgpnXqSLWbANyoICzMCpumfLSYNm/88TraFd8AE7eLSc
> O1BZkXId4Rb3ZwCbucMz+rWo8lHvFMaUuCTuQuXLwCE7ieFhhcNuvg62NEw9c7lt
> E896UwlcGVcEvaao1vvLobeaTO+NY+a0CqdQO8Oipe8VSMP9MG+iKezNferJwbXa
> K8lof9cYe9inTgchdQXUOPPEEkT3Y/Eii1Mh4sDxaMphFct9y+CNwRHz5xjZLW5N
> nZSZlr+Z0SRe2s0J6XfyfBkXzx/VicDwLnji8i5/ENZCiShraabl6v6wGtPltOMJ
> +9AcRB7MneolTxFSaGN37T+ARpYNgPEu3NolS0d2BJEJai4wxf4=
> =DEVw
> -END PGP SIGNATURE-
>

Bug#975583: ITP: wsjtx-go -- Golang binding for the WSJT-X amateur radio software's UDP interface

[Chris Keller]

Package: wnpp
Severity: wishlist
Owner: Chris Keller 

* Package name: wsjtx-go
  Version : 1.1.0-1
  Upstream Author : Chris Keller 
* URL : https://github.com/k0swe/wsjtx-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Golang binding for the WSJT-X amateur radio
software's UDP interface

 Golang binding for the WSJT-X amateur radio software's UDP communication
 interface. This library supports receiving and sending all WSJT-X message
 types up through WSJT-X v2.3.0.
 .
 This is meant to be a fairly thin binding
 API, so familiarity with WSJT-X's NetworkMessage.hpp
 
(https://sourceforge.net/p/wsjt/wsjtx/ci/8f99fcce/tree/Network/NetworkMessage.hpp)
 is recommended.

Bug#973481: status ITP: please -- Please, a sudo clone with regex support, done

[Geert Stappers]

Packaged by Ed Neville
Uploaded by sylves...@debian.org

The package is now in NEW

Bug#975582: mypaint: MyPaint does not start

[bluecat]

Package: mypaint
Version: 2.0.1-1+b1
Severity: important
X-Debbugs-Cc: blue...@netc.eu

Dear Maintainer,

Since last update MyPaint cannot start.

Here is the error I get:
mypaint
INFO: mypaint: Installation layout: conventional POSIX-like structure with
prefix '/usr'
Traceback (most recent call last):
  File "/usr/bin/mypaint", line 293, in 
= get_paths()
  File "/usr/bin/mypaint", line 241, in get_paths
from lib import fileutils
  File "/usr/lib/mypaint/lib/fileutils.py", line 25, in 
import lib.helpers
  File "/usr/lib/mypaint/lib/helpers.py", line 25, in 
from . import mypaintlib
  File "/usr/lib/mypaint/lib/mypaintlib.py", line 13, in 
from . import _mypaintlib
ImportError: cannot import name '_mypaintlib' from 'lib'
(/usr/lib/mypaint/lib/__init__.py)

Thanks for your work !



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

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

Versions of packages mypaint depends on:
ii  gir1.2-gtk-3.0  3.24.23-2
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-16
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-5
ii  libglib2.0-02.66.2-1
ii  libgomp110.2.0-16
ii  liblcms2-2  2.9-4+b1
ii  libmypaint-1.5-11.6.0-1+b1
ii  libpng16-16 1.6.37-3
ii  librsvg2-bin2.50.1+dfsg-1
ii  libstdc++6  10.2.0-16
ii  mypaint-brushes 2.0.2+ds1-1
ii  mypaint-data2.0.1-1
ii  python3 3.8.6-1
ii  python3-distutils   3.8.6-1
ii  python3-gi  3.38.0-1+b1
ii  python3-gi-cairo3.38.0-1+b1
ii  python3-numpy   1:1.19.4-1

Versions of packages mypaint recommends:
ii  mypaint-data-extras  2.0.1-1
ii  shared-mime-info 2.0-1

mypaint suggests no packages.

-- no debconf information

Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

[Damyan Ivanov]

-=| Sam Hartman, 23.11.2020 10:02:34 -0500 |=-
> Here's a patch that I believe will get libapache-mod-auth-kerb 
> working with the latest krb5.  I'll go upload a krb5 that fixes the 
> breaks relationship.

Thank you, Sam.

> I'd appreciate it if someone who actually uses 
> libapache-mod-auth-kerb will test this patch.
> If it gets tested, I'll NMU.  If not, I'll ask the release team to
> remove libapache-mod-auth-kerb from testing.

I'll try to find time to test the patch tomorrow (UTC+02).

About removing auth-kerb from testing, this may be not so bad. I see 
Fedora have removed it, with auth-gssapi as a functional replacement. 
I plan to test that too at some point.


-- Damyan

Bug#975580: packagekit: segfault at 8 ip 000055afca94a631 sp 00007fff94cece20 error 4 in packagekitd[55afca948000+24000]

[Patrice Duroux]

with more debug symbols if it helps:

   PID: 1513 (packagekitd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Mon 2020-11-23 21:03:37 CET (27s ago)
  Command Line: /usr/libexec/packagekitd
Executable: /usr/libexec/packagekitd
 Control Group: /system.slice/packagekit.service
  Unit: packagekit.service
 Slice: system.slice
   Boot ID: ef4e5b9b9ea14f4793dac364b40ddb98
Machine ID: be351e757dc049ffa300ddbaf0f4856a
  Hostname: kos-moceratops
   Storage: 
/var/lib/systemd/coredump/core.packagekitd.0.ef4e5b9b9ea14f4793dac364b40ddb98.1513.160616181700.zst
   Message: Process 1513 (packagekitd) of user 0 dumped core.

Stack trace of thread 1513:
#0  0x559d84972631 pk_dbus_get_uid (packagekitd + 0xe631)
#1  0x559d8498bd5d pk_engine_is_proxy_unchanged 
(packagekitd + 0x27d5d)
#2  0x7fa6784adf1e call_in_idle_cb (libgio-2.0.so.0 + 
0x10af1e)
#3  0x7fa67862cadf g_main_dispatch (libglib-2.0.so.0 + 
0x51adf)
#4  0x7fa67862ce88 g_main_context_iterate (libglib-2.0.so.0 
+ 0x51e88)
#5  0x7fa67862d17b g_main_loop_run (libglib-2.0.so.0 + 
0x5217b)
#6  0x559d84971d21 main (packagekitd + 0xdd21)
#7  0x7fa677fc6cca __libc_start_main (libc.so.6 + 0x26cca)
#8  0x559d84971eea _start (packagekitd + 0xdeea)

Stack trace of thread 1514:
#0  0x7fa67809335f __GI___poll (libc.so.6 + 0xf335f)
#1  0x7fa67862ce1e g_main_context_poll (libglib-2.0.so.0 + 
0x51e1e)
#2  0x7fa67862cf3f g_main_context_iteration 
(libglib-2.0.so.0 + 0x51f3f)
#3  0x7fa67862cf91 glib_worker_main (libglib-2.0.so.0 + 
0x51f91)
#4  0x7fa678655dfd g_thread_proxy (libglib-2.0.so.0 + 
0x7adfd)
#5  0x7fa67816dea7 start_thread (libpthread.so.0 + 0x8ea7)
#6  0x7fa67809dd4f __clone (libc.so.6 + 0xfdd4f)

Stack trace of thread 1515:
#0  0x7fa67809335f __GI___poll (libc.so.6 + 0xf335f)
#1  0x7fa67862ce1e g_main_context_poll (libglib-2.0.so.0 + 
0x51e1e)
#2  0x7fa67862d17b g_main_loop_run (libglib-2.0.so.0 + 
0x5217b)
#3  0x7fa6784be746 gdbus_shared_thread_func 
(libgio-2.0.so.0 + 0x11b746)
#4  0x7fa678655dfd g_thread_proxy (libglib-2.0.so.0 + 
0x7adfd)
#5  0x7fa67816dea7 start_thread (libpthread.so.0 + 0x8ea7)
#6  0x7fa67809dd4f __clone (libc.so.6 + 0xfdd4f)

Bug#975581: src:org-mode-doc: fails to migrate to testing for too long: non-free source package not autobuild

[Paul Gevers]

Source: org-mode-doc
Version: 9.3-1
Severity: serious
Control: close -1 9.4.0-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

You uploaded the latest version of org-mod-doc as a source only. That's
the required way for the main archive, however, non-free packages aren't
automatically autobuild. You'll have to get it added to the list:
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-free-buildd
or upload the binaries yourself.

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:org-mode-doc
in its current version in unstable has been trying to migrate for 60
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=org-mode-doc




signature.asc
Description: OpenPGP digital signature

Bug#975580: packagekit: segfault at 8 ip 000055afca94a631 sp 00007fff94cece20 error 4 in packagekitd[55afca948000+24000]

[Patrice Duroux]

Package: packagekit
Version: 1.2.1-1
Severity: normal

Dear Maintainer,

I do not know how to start but here is what coredumpctl says:

   PID: 1532 (packagekitd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Mon 2020-11-23 19:22:23 CET (1h 21min ago)
  Command Line: /usr/libexec/packagekitd
Executable: /usr/libexec/packagekitd
 Control Group: /system.slice/packagekit.service
  Unit: packagekit.service
 Slice: system.slice
   Boot ID: 67b186ff451545cfa816a3e6dc84b9ef
Machine ID: be351e757dc049ffa300ddbaf0f4856a
  Hostname: kos-moceratops
   Storage:
/var/lib/systemd/coredump/core.packagekitd.0.67b186ff451545cfa816a3e6dc84b9ef.1532.160615574300.zst
   Message: Process 1532 (packagekitd) of user 0 dumped core.

Stack trace of thread 1532:
#0  0x55afca94a631 pk_dbus_get_uid (packagekitd + 0xe631)
#1  0x55afca963d5d n/a (packagekitd + 0x27d5d)
#2  0x7f9ff012cf1e n/a (libgio-2.0.so.0 + 0x10af1e)
#3  0x7f9ff02abadf g_main_context_dispatch
(libglib-2.0.so.0 + 0x51adf)
#4  0x7f9ff02abe88 n/a (libglib-2.0.so.0 + 0x51e88)
#5  0x7f9ff02ac17b g_main_loop_run (libglib-2.0.so.0 +
0x5217b)
#6  0x55afca949d21 main (packagekitd + 0xdd21)
#7  0x7f9fefc45cca __libc_start_main (libc.so.6 + 0x26cca)
#8  0x55afca949eea _start (packagekitd + 0xdeea)

Stack trace of thread 1534:
#0  0x7f9fefd1235f __poll (libc.so.6 + 0xf335f)
#1  0x7f9ff02abe1e n/a (libglib-2.0.so.0 + 0x51e1e)
#2  0x7f9ff02ac17b g_main_loop_run (libglib-2.0.so.0 +
0x5217b)
#3  0x7f9ff013d746 n/a (libgio-2.0.so.0 + 0x11b746)
#4  0x7f9ff02d4dfd n/a (libglib-2.0.so.0 + 0x7adfd)
#5  0x7f9fefdecea7 start_thread (libpthread.so.0 + 0x8ea7)
#6  0x7f9fefd1cd4f __clone (libc.so.6 + 0xfdd4f)

Stack trace of thread 1533:
#0  0x7f9fefd1235f __poll (libc.so.6 + 0xf335f)
#1  0x7f9ff02abe1e n/a (libglib-2.0.so.0 + 0x51e1e)
#2  0x7f9ff02abf3f g_main_context_iteration
(libglib-2.0.so.0 + 0x51f3f)
#3  0x7f9ff02abf91 n/a (libglib-2.0.so.0 + 0x51f91)
#4  0x7f9ff02d4dfd n/a (libglib-2.0.so.0 + 0x7adfd)
#5  0x7f9fefdecea7 start_thread (libpthread.so.0 + 0x8ea7)
#6  0x7f9fefd1cd4f __clone (libc.so.6 + 0xfdd4f)


Do I need to install some specific dbgsym packages to get it more?

Thanks,
Patrice



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

Kernel: Linux 5.9.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages packagekit depends on:
ii  init-system-helpers 1.59
ii  libappstream4   0.12.11-1
ii  libapt-pkg6.0   2.1.11
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-18
ii  libglib2.0-02.66.3-1
ii  libglib2.0-bin  2.66.3-1
ii  libgstreamer1.0-0   1.18.1-1
ii  libpackagekit-glib2-18  1.2.1-1
ii  libpolkit-gobject-1-0   0.105-29
ii  libsqlite3-03.33.0-1
ii  libstdc++6  10.2.0-18
ii  libsystemd0 246.6-4
ii  policykit-1 0.105-29

Versions of packages packagekit recommends:
ii  packagekit-tools  1.2.1-1
ii  systemd   246.6-4

Versions of packages packagekit suggests:
ii  appstream  0.12.11-1

-- no debconf information

Bug#975579: src:xorg-server: fails to migrate to testing for too long: FTBFS on mips*el

[Paul Gevers]

Source: xorg-server
Version: 2:1.20.8-2
Severity: serious
Tags: sid bullseye ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

Your package fails to build from source on mips*el.

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:xorg-server
in its current version in unstable has been trying to migrate for 61
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=xorg-server



signature.asc
Description: OpenPGP digital signature

Bug#975578: cups-browsed: segfault at 0 ip 00000000f7b5637c sp 00000000ffab2890 (NULL pointer deref)

[Thorsten Glaser]

Package: cups-browsed
Version: 1.28.5-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de

Nov 23 20:34:11 tglase vmunix: [12181565.392373] cups-browsed[19303]: segfault 
at 0 ip f7b5637c sp ffab2890 error 6 in 
libcupsfilters.so.1.0.0[f7b3a000+24000]
Nov 23 20:34:11 tglase vmunix: [12181565.392385] Code: 48 89 ef 31 c0 e8 04 4c 
fe ff e9 0f ff ff ff 0f 1f 80 00 00 00 00 8b 7c 24 44 4c 89 f6 e8 8c 47 fe ff 
c7 44 24 58 01 00 00 00 <67> c6 00 00 e9 02 de ff ff 0f 1f 00 8b 7c 24 44 ba 29 
00 00 00 8d

Installing the necessary dbgsym packages and unpacking the source shows
this to clearly be a NULL pointer dereference (more below the backtrace):



tglase@tglase:/tmp/cups-filters-1.28.5 $ gdb /usr/sbin/cups-browsed ~/c-b.core
GNU gdb (Debian 10.1-1+b1) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnux32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/cups-browsed...
Reading symbols from 
/usr/lib/debug/.build-id/61/b1dea4178595f657692de37d747568dd7f89a8.debug...
[New LWP 19303]
[New LWP 19305]
[New LWP 19304]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnux32/libthread_db.so.1".
Core was generated by `/usr/sbin/cups-browsed'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xf7b5637c in ppdCreateFromIPP2 (buffer=buffer@entry=0xffab54c0 
"/tmp/04b675fbcfcbf",
bufsize=bufsize@entry=8192, response=, 
make_model=make_model@entry=0x0, pdl=pdl@entry=0x0,
color=color@entry=1, duplex=1, conflicts=0x0, sizes=0x56d66b70, 
default_pagesize=0x0,
default_cluster_color=0x0) at cupsfilters/ppdgenerator.c:2227
2227  *suffix = '\0';
[Current thread is 1 (Thread 0xf67b2a00 (LWP 19303))]
(gdb) set pagination 0
(gdb) print suffix
$1 = 0x0
(gdb) bt full
#0  0xf7b5637c in ppdCreateFromIPP2 (buffer=buffer@entry=0xffab54c0 
"/tmp/04b675fbcfcbf", bufsize=bufsize@entry=8192, response=, 
make_model=make_model@entry=0x0, pdl=pdl@entry=0x0, color=color@entry=1, 
duplex=1, conflicts=0x0, sizes=0x56d66b70, default_pagesize=0x0, 
default_cluster_color=0x0) at cupsfilters/ppdgenerator.c:2227
tbottom = '\000' 
ttop = '\000' 
twidth = '\000' , "\230j\230\367", '\000' , 
"\307\305jV\000\000\000\000p5\253\377\000\000\000\000\220\065\253\377\000\000\000\000X\000\000\000\000\000\000\000\240\305jV\000\000\000\000\300\066\253\377\000\000\000\000\fޖ\367\000\000\000\000=\000\000\000\000\000\000\000\006\242eV\000\000\000\000\360\066\253\377\000\000\000\000\f"...
ppdsizename = 
"\235<\b\000\000\000\000\000`\321\306V\000(\000_\000\000\000\000\000\000\000\000\063o\255\367",
 '\000' , 
"\001\000\000\000\000\000\000\000\f\000\000\000\000\000\000\000+\254\230\367\000\000\000\000\255\a\360\367\000\000\000\000ç\230\367\000\000\000\000`\321\325V\000\000\000\000ç\230\367",
 '\000' , 
"(\000_\000\000\000\000\000\000\000\000\004S\325V\000(\000_"
tright = '\000' 
ippsizename = 
suffix = 0x0
tleft = "\240\354\325V\000\000\000\000 
\353\325V\000\000\000\000x,\253\377\000\000\000\000\220\374\325V\000\000\000\000\263\016\274_\000\000\000\000!\272\000\000\000\000\000\000\263\016\274_\000\000\000\000!\272\000\000\000\000\000\000p\371\325V\260X\262V\000\000\000\000\000\000\000\000\220\336\362\367\310\066\253\377\000\000\000\000\000\000\000\000
 H\325V", '\000' 
tlength = '\000' , 
"\020Y\262V\315\377\377\377\063\000\000\000 
\000\000\000\307\305jV\000\000\000\000\v\000\000\000\002\000\000\000\305\305jV\000\000\000\000\264\006\000\000\000\000\000\000\022\242eV\307\305jV\000\000\000\000\002\000\000\000\020\242eV\000\000\000\000\264\006\000\000\000\000\000\000\000\000\000\000\022\242eV",
 '\000' , 
"(\000\000\000\060\000\000\000\240\067\253\377\340\066\253\377", '\000' 
, 
"\060\000\000\000\060\000\000\000\020<\253\377\020;\253\377", '\000' 
all_borderless = 1
fp = 0x56d62e70
printer_sizes = 
size = 
attr = 
attr2 = 
defattr = 0x0
quality = 
x_dim = 
y_dim = 
media_col = 
media_size = 
make = "Zebra\000ZPL Label Printer\000`^\257V\000\000\000\000 
^\257V\000\000\000\000ç\230\367\000\000\000\000\304ԱV\000\000\000\000+\254\230\367",
 '\000' , 
"+\254\230\367\000\000\000\000\000\367\325V\000\000\000\000\034\367\325V\000(\000_\304ԱV",
 '\000' , 
"p\371\325V\000\000\000\000\177p\255\

Bug#975577: kde-plasma-desktop: Desktop File Rename Text Selection Context Menu not Working

[Andy]

Package: kde-plasma-desktop
Severity: normal
X-Debbugs-Cc: winningfl...@gmail.com


Hello debian gurus,

No right click text selection context menu after right clicking and selecting 
rename on any file or folder on the KDE desktop.

I reported this to package "kde-plasma-desktop" because that is usually how I 
install plasma but this happens regardless of how I install the plasma desktop.

reproduce;
 - default install from "firmware-bullseye-DI-alpha2-amd64-netinst.iso"
 - during tasksel: unselect gnome, select KDE.
 - complete installation and boot into kde.

 - create new file on desktop.
 - right click on file and select rename.
 - right click and try to copy text from filename.

 right click menu is not working

Additional info;1
does not work with full install from D2 installer
does not work with minimal install with sddm & kde-plasma-desktop
does not work with debian-live-testing-amd64-kde+nonfree from 2020-11-16

works in dolphin filemanager in desktop directory
works in Kubuntu 20.10

Same results on hardware and in VM.

Thank you


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

Kernel: Linux 5.9.0-2-amd64 (SMP w/8 CPU threads)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kde-plasma-desktop depends on:
pn  kde-baseapps  
ii  plasma-desktop4:5.19.5-4
ii  plasma-workspace  4:5.19.5-5
ii  udisks2   2.9.1-2
pn  upower

Versions of packages kde-plasma-desktop recommends:
ii  kwin-x11  4:5.19.5-3
ii  sddm  0.19.0-2
ii  xserver-xorg  1:7.7+21

Versions of packages kde-plasma-desktop suggests:
pn  kdeconnect  

Bug#975554: udev and systemd version should always be in sync

[Michael Biebl]

Am Montag, den 23.11.2020, 19:43 +0100 schrieb Ansgar:
> Michael Biebl writes:
> 
> 
> > > Maybe udev should have
> > > "Breaks: systemd (!= ${binary:Version})"?  But I'm not sure if
> > > that
> > > might result in apt suggesting to remove udev instead.
> > 
> > Shouldn't this be the other way around, i.e. systemd having a
> > Breaks: udev (...) to force udev being upgraded along side.
> 
> Not sure.  I would hope udev having "Breaks: systemd (!=
> ${binary:Version})" and systemd having "Breaks: udev (!=
> ${binary:Version})" to behave similar


Not quite. Keep in mind that you upgraded systemd and the old (i.e on
dist-upgrades the buster version of) udev doesn't have such a Breaks.


> > Have you tested the other combination as well (udev 247 + systemd
> > 246)?
> 
> No, just new systemd with old udev.  And not intentionally, but just
> because I ran `apt -t experimental install systemd` or such.
> 
> > v247 is a bit of a special case with the (incompatible) sticky udev
> > tags change. And maybe restricting it to that version is
> > sufficient.
> > 
> > I guess I'd be fine if we had systemd with a Breaks: udev (<< 247~)
> > dependency.
> 
> That's probably fine given you would like to be able to test having
> systemd/udev not in sync.  I don't have a strong opinion on this.
> 
> Mostly the packages should be in sync either way (as any suite should
> contain the same version of systemd & udev), just when one installs
> systemd from a suite with non-standard priority like experimental or
> backports one might get out-of-sync.  Or when something else blocks
> one
> of the two updates.

In generally I agree that udev and systemd should be in sync (version
and architecture wise). Both is not easy to achieve afaics with the
given Debian mechanisms.

Michael




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

Bug#776688: xtables-addons-source: Depends upon latest binutils, but fails to depend; other cross-building issues

[Jeremy Sowden]

On Fri, 30 Jan 2015 17:37:53 -0800 Elliott Mitchell wrote:
> The subject line mostly says it all, but some more detail of note.
> There appear to be multiple places where the line "LDFLAGS =
> -Wl,-z,relro" is included.  This works with the latest versions of the
> binutils package (2.22-8), but fails with the currently available
> versions of the cross binutils (binutils-mipsel-linux-gnu, 2.20.1-16).
> I've yet to ascertain where all of these are located, this looks like
> the only major problem for cross-building.

I suspect this was a teething problem related to package hardening.  It
should work correctly now.  Certainly the current mipsel binutils
supports the relevant linker flags.

> Several of the Makefiles included in /usr/src/xtables-addons.tar.bz2
> also contain explicit references to the x86 compiler/linker, which is
> inappropriate for an all architecture package.  I suspect this is
> simply a case that those are accidentally packaged and do no real
> harm, but they do confuse things.
>
> Additionally, all the libxt_* files included in
> /usr/src/xtables-addons.tar.bz2 are source files for building the
> userspace portion (xtables-addons-common), but these are uneeded for
> building kernel modules.

I've recently stripped out all the userspace source from the -dkms and
-source packages to fix problems with reproducible builds, so these
issues should be resolved in the next upload.

J.


signature.asc
Description: PGP signature

Bug#973326: double-conversion: Misbuild with -O3: DoubleToStringConverter::DoubleToStringConverter() constructor dropped from exported symbols

[Thorsten Glaser]

Hi vorlon,

> attached patch.

I’d have used PREPEND, not APPEND, for -O2. You already STRIP -O3,
so if dpkg-buildflags contains something like -Os or -Og it would
still be honoured with PREPEND.

But it’s almost certainly not worth changing this again; just for
the future, maybe?

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#972968: Patch available

[Christian Britz]

https://marc.info/?l=linux-bluetooth&m=160378222632366&w=2 fixes the 
problem for me.

Bug#975575: Please remove huge fonts-noto-extra package (~325MB) from supertuxkart-data depends

[Mantas Kriaučiūnas Baltix]

Package: supertuxkart
Version: 1.2+ds-1

I've noticed lack of free space after updating supertuxkart to 1.2
package and after little research noticed, that supertuxkart 1.2
package depends on huge (~325MB size) fonts-noto-extra!!!
Please remove huge fonts-noto-extra package (330MB) from
supertuxkart-data depends (if supertuxkart really depends on few small
fonts from huge fonts-noto-extra package then include these font files
directly to supertuxkart-data package) or at least use recommends
instead of depends, because didn't noticed any problems with
supertuxkart 1.2 when playing without installed fonts-noto-extra
package (dpkg --force-depends -P fonts-noto-extra ).
Also it would be nice to remove fonts-noto-ui-extra (61MB size) from
depends for the same reason - supertuxkart works without any issue
when playing without installed fonts-noto-ui-extra package.

Thanks for maintaining,
Mantas

--
Prekyba kompiuteriais su Linux OS - http://tinklas.eu/prekyba
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje -
http://baltix.eu
Mantas Kriaučiūnas
Use Baltix GNU/Linux OS ! http://launchpad.net/baltix

Bug#847962: rng-tools: Patch to fix the broken FIPS 140-2 runs test

[Diederik de Haas]

On Sat, 24 Jan 2015 20:46:02 +1030 Ron  wrote:
> Tags: patch
> 
> And if reportbug --attach actually worked, the git-format-patch export
> should be included in this mail.  There's a full description of the
> bugs in the commit message of it.

Hi Ron,

Can you submit your patch as a PR here: https://github.com/nhorman/rng-tools/
pulls ?

I could do it, but it would make much more sense that you'd do it.

Diederik

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

Bug#945824: [python3-numpy] Depends on python3.8 and python3.7

[Vincent Lefevre]

On 2020-11-23 19:33:18 +0100, Ralf Jung wrote:
> On 23.11.20 16:21, Sandro Tosi wrote:
> >> But now it depends on both python3.8:any and python3.9:any.
> > 
> > and this will continue to be the case for as long as we have 2
> > supported python3 versions.
> 
> But why do all of your users have to install two Python versions just because
> you support both of them? It seems to me the way to express that both versions
> are supported would be a dependency on python 3.8 *or* python 3.9.

I agree. And FYI, about the usual dependencies against libraries,
they are necessary, because even if the library is not used in
usual cases, the library is needed to avoid a link failure when
starting the application. But for Python, I suppose that this
is different: a python3-numpy user with Python 3.9 will be able
to use python3-numpy with Python 3.9 even if Python 3.8 is not
installed, won't he?

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

Bug#975574: libgs9: possible ABI breakage with testing/bullseyes version (9.52.1~dfsg-1)

[Patrice Duroux]

Package: libgs9
Version: 9.53.3~dfsg-5
Severity: normal

Dear Maintainer,

Regarding #975387 I suspect an ABI breakage with libgs9.
The original trouble concerns GNOME Evince based on libspectre and not able to
open PS files.

Thanks,
Patrice

ps: My apologies to Jonas for my private email on this concern.



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

Kernel: Linux 5.9.0-3-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgs9 depends on:
ii  libc62.31-4
ii  libcups2 2.3.3-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.2+dfsg-4
ii  libgs9-common9.53.3~dfsg-5
ii  libidn11 1.33-2.4
ii  libijs-0.35  0.35-15
ii  libjbig2dec0 0.19-1
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  liblcms2-2   2.9-4+b1
ii  libopenjp2-7 2.3.1-1
ii  libpaper11.1.28+b1
ii  libpng16-16  1.6.37-3
ii  libtiff5 4.1.0+git191117-2
ii  poppler-data 0.4.10-1
ii  zlib1g   1:1.2.11.dfsg-2

libgs9 recommends no packages.

libgs9 suggests no packages.

-- no debconf information

Bug#975554: udev and systemd version should always be in sync

[Ansgar]

Michael Biebl writes:
> Am Montag, den 23.11.2020, 15:38 +0100 schrieb Ansgar:
> As mentioned in another MR [1], the imho most "elegant" way would be an
> artifical libsystemd0 dependency in udev.

Ah, yes, I remember you asked about something like this, but couldn't
find where :)

> Breaks and Conflicts have a tendency to cause weird results, so I'd
> like to avoid them as much as possible.

I agree; people uninstalling udev by accident is probably not good...

>> Maybe udev should have
>> "Breaks: systemd (!= ${binary:Version})"?  But I'm not sure if that
>> might result in apt suggesting to remove udev instead.
>
> Shouldn't this be the other way around, i.e. systemd having a
> Breaks: udev (...) to force udev being upgraded along side.

Not sure.  I would hope udev having "Breaks: systemd (!=
${binary:Version})" and systemd having "Breaks: udev (!=
${binary:Version})" to behave similar.

> Have you tested the other combination as well (udev 247 + systemd
> 246)?

No, just new systemd with old udev.  And not intentionally, but just
because I ran `apt -t experimental install systemd` or such.

> v247 is a bit of a special case with the (incompatible) sticky udev
> tags change. And maybe restricting it to that version is sufficient.
>
> I guess I'd be fine if we had systemd with a Breaks: udev (<< 247~)
> dependency.

That's probably fine given you would like to be able to test having
systemd/udev not in sync.  I don't have a strong opinion on this.

Mostly the packages should be in sync either way (as any suite should
contain the same version of systemd & udev), just when one installs
systemd from a suite with non-standard priority like experimental or
backports one might get out-of-sync.  Or when something else blocks one
of the two updates.

Ansgar

Bug#945824: [python3-numpy] Depends on python3.8 and python3.7

[Ralf Jung]

On 23.11.20 16:21, Sandro Tosi wrote:
>> But now it depends on both python3.8:any and python3.9:any.
> 
> and this will continue to be the case for as long as we have 2
> supported python3 versions.

But why do all of your users have to install two Python versions just because
you support both of them? It seems to me the way to express that both versions
are supported would be a dependency on python 3.8 *or* python 3.9.

; Ralf

Bug#974009: debhelper: please document that dh_installsystemd ignores unit failures in maintainer scripts

[Michael Biebl]

Hi Ferenc

On Mon, 09 Nov 2020 00:40:31 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?= 
 wrote:
> Package: debhelper
> Version: 12.1.1
> Severity: minor
> 
> Dear Maintainer,
> 
> I was surprised that a daemon start failure during install did not stop
> dpkg from exiting with a successful exit status.  After much digging I
> found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766194#22, which
> explains the asymmetry with dh_installinit.  While I'd find an option
> for this more appropriate than different behavior, I also feel like the
> current state merits some much more prominent documentation at least.
> Please consider addig it to the respective compat level as well.

I'm not sure there is an asymmetry with sysvinit, on the contrary.
The "not-fail-on-failures" in dh-systemd (and later dh_installsystemd)
was modelled after sysvinit where SysV init scripts typically have an
"exit 0" at the end of the init script, thus basically ignoring any
error in the init script.

systemd/systemctl internally is more strict, that's why we picked the
"|| true" approach to mimic the old sysvinit behaviour.

Obviously, we could change that to be more picky and abort if a service
fails to start. Question is: do we want that? And if so, why?


Regards,
Michael


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

Bug#975562: odd no-op in debian patch

[Antoine Beaupré]

On 2020-11-23 13:49:23, Joey Hess wrote:
> Antoine Beaupré wrote:
>> --- a/etckeeper
>> +++ b/etckeeper
>> @@ -54,6 +54,10 @@ fi
>>  if [ ! -z "$AVOID_SPECIAL_FILE_WARNING" ]; then
>> export AVOID_SPECIAL_FILE_WARNING
>>  fi
>> +if [ -z "$LANG" ]; then
>> +# Default to UTF8 encoding, if unset
>> +export LANG=C.UTF-8
>> +fi
>
> That is rather problimatic, bear in mind that etckeeper can run things
> like interactive git commits and editors, which could be translated.
>
> Also, LANG only influences sort order when LC_COLLATE is not set.
>
> I guess my commit 4bc7ebe6d29d83df9b86e1be64e696d4d2a70947 upstream
> probably fixes whatever this was trying to fix in a better way, although
> it's hard to be sure without an explanation of what the actual problem
> was.
>
>>  # Make sure sort always sorts in same order.
>> -LANG=C
>> +LANG=C.UTF-8
>
> Why would it matter whether it handles unicode characters or not, if the
> point is sort stability?

Those are all good questions, which would be better directed at the
original patch author.

In other words, I have no idea. :)

a.

-- 
Prolétaires de tous les pays, qui lave vos chaussettes?
- Audrey Lorde

Bug#975573: golang-github-containernetworking-plugins: Please upgrade to upstream version v0.8.7 or later

[Reinhard Tartler]

Source: golang-github-containernetworking-plugins
Severity: wishlist
X-Debbugs-Cc: lib...@packages.debian.org

Please upgrade the package. This is necessary for packaging libpod 2.1.

I'm currently getting this compilation failure:

# github.com/containers/libpod/libpod
src/github.com/containers/libpod/libpod/networking_linux.go:519:3: cannot use 
ctr.config.ContainerNetworkConfig.PortMappings (type 
[]"github.com/containers/libpod/vendor/github.com/cri-o/ocicni/pkg/ocicni".PortMapping)
 as type 
[]"github.com/containers/podman/vendor/github.com/cri-o/ocicni/pkg/ocicni".PortMapping
 in field value


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#975572: linux: Enable mxc4005 driver

[Vivia Nikolaidou]

Source: linux
Severity: wishlist
X-Debbugs-Cc: n.vi...@gmail.com

The mxc4005 module is disabled by default, so the accelerometer in my tablet
doesn't work unless I manually build the module. Tablet is Chuwi Hi10 X.


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

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

Bug#975553: suckless-tools: Windows lose focus when they are interrupted by dmenu

[Cédric Hannotier]

Package: suckless-tools
Version: 45-1
Severity: important

Dear Maintainer,

Focused window looses input focus when interrupted by dmenu.
It affects some WM.
This was already reported on i3 side [1] and on suckless side [2].
It was fixed by commit db6093f6ec1bb884f7540f2512935b5254750b30 [3].

Could you backport that commit or, (better IMO) update dmenu to
version 5.0 (released on 2020/09/02) [4] ?

[1] https://github.com/i3/i3/issues/3528
[2] https://lists.suckless.org/dev/1902/33272.html
[3] 
https://git.suckless.org/dmenu/commit/db6093f6ec1bb884f7540f2512935b5254750b30.html
[4] 
https://git.suckless.org/dmenu/commit/1a13d0465d1a6f4f74bc5b07b04c9bd542f20ba6.html

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages suckless-tools depends on:
ii  libc6   2.31-4
ii  libcap2-bin 1:2.44-1
ii  libfontconfig1  2.13.1-4.2
ii  libpam0g1.3.1-5
ii  libx11-62:1.6.12-1
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxrandr2  2:1.5.1-1
ii  libxss1 1:1.2.3-1

suckless-tools recommends no packages.

Versions of packages suckless-tools suggests:
pn  dwm 
ii  stterm  0.8.4-1
pn  surf

-- no debconf information

Best regards
-- 

Cédric Hannotier

Bug#975505: Please package v3.0.5 or newer

[Dmitry Shachnev]

Control: reassign -1 wnpp
Control: retitle -1 RFP: mathjax3 -- math rendering engine for browsers, 
implemented in TypeScript
Control: merge 963684 -1

Hi Nicholas!

On Sun, Nov 22, 2020 at 10:27:43PM -0500, Nicholas D Steeves wrote:
> Dear MathJax maintainers,
>
> Debian's MathJax is out of date (2.7.9), and I've noticed that some packages
> have had to start to resort to bundling a 3.x release.  Please package
> v3.0.5 or newer.

MathJax v3 is a complete rewrite of MathJax, and it is incompatible with
MathJax v2 [1].

So MathJax v3 needs to be packaged as a new source and binary package,
therefore this bug is RFP, not a request for upgrade.

Actually, an RFP was already filed, so I am merging this bug into that.

I am not going to do it myself because I don't have any nodejs or typescript
skills (the source code [2] is using them now), but if you or someone else
who reads this believes they can handle it, please do it.

[1]: https://docs.mathjax.org/en/latest/upgrading/v2.html
[2]: https://github.com/mathjax/MathJax-src

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#975558: Add public domain to copyright types

[Baptiste Beauplat]

Sorry Anatoli,

I forgot to include you in my reply.

On 11/23/20 7:02 PM, Baptiste Beauplat wrote:

Hi Anatoli,

On 11/23/20 4:49 PM, Anatoli Babenia wrote:

I could not find any examples on how to make public domain
packaged in Debian. Would be nice if `dh_make` supported it
with `--copyright pd` option.


The way to handle public-domain work is described in those two documents:

https://wiki.debian.org/DFSGLicenses#Public_Domain
https://dep-team.pages.debian.net/deps/dep5/#public-domain

I'm somewhat unsure about adding this license to dh-make because the 
Public domain license does not seems to be a wildly used choice for 
writing software.


A quick search on https://sources.debian.org show that barely ~1000 
packages mention "public-domain" in they copyright and most of the time, 
it only apply to a small part of the source code.


Another point is that, per DEP5, an explanation is required when using 
the public domain license. That is case specific and cannot be generated 
by dh-make.


It would make sense to me to only ship most common licenses in dh-make, 
and thus skip the public domain license. What do you think?




--
Baptiste Beauplat - lyknode



OpenPGP_signature
Description: OpenPGP digital signature