Bug#987956: libgcrypt20: ECDH decryption fails with "gpg: public key decryption failed: Invalid object" error message

[NIIBE Yutaka]

On Sun, 02 May 2021 19:47:15 +0200 "Xavier G."  wrote:
> Package: libgcrypt20
> Version: 1.8.7-4
> Severity: important
> 
> Dear Maintainer,
> 
> After a full-upgrade in Sid on 2021-05-02, `gpg --decrypt somefile.gpg` fails:
> 
>   gpg: encrypted with 256-bit ECDH key, ID [hopefully irrelevant]
>   gpg: public key decryption failed: Invalid object
>   gpg: decryption failed: No secret key
[...] 
> The second patch is precisely about returning "Invalid object" /
> GPG_ERR_INV_OBJ in some case related to GnuPG and ECDH decryption.

Sorry, it's my fault.

Fixed in the upstream repo.  It's tracked by:

https://dev.gnupg.org/T5423
-- 

Bug#987013: Release goal proposal: Remove Berkeley DB

[Matthias Klose]

On 5/5/21 8:51 PM, Niko Tyni wrote:
> On Fri, Apr 16, 2021 at 08:29:52PM +0200, Bastian Blank wrote:
>> On Fri, Apr 16, 2021 at 05:04:03PM +0200, Marco d'Itri wrote:
> 
>>> And then all the packages currently depending on libdb5.3 will need to 
>>> implement, or at least document, a transition strategy.
>>
>> My first goal would be to drop it from base packages, so not every
>> system out there needs to have it installed.
> 
> Hi, please note that there's a number of indirect users of libdb via
> interpreter packages - at least Perl, presumably Python too.
> 
> Given perl gets installed on almost all systems, this seems to to be
> on the path to the first goal.
> 
> For the perl core, the libdb5.3 bindings are exposed with the DB_File
> module. I think this is the only place but have not cross-checked that.
> (The libberkeleydb-perl package is an entirely separate matter AIUI.)
> 
> I see 110 source packages in Debian matching DB_File. The list will
> need to be inspected manually to weed out false positives. The remaining
> packages need to be changed before perl can drop its libdb5.3 dependency.
> I suppose this will also need a long list of Breaks declarations on the
> perl side.
> 
> Then there's user code too. I also think we'll need at least a dumper
> utility so that users can migrate their data manually when they discover
> their program no longer works after upgrading.

For Python, the dbm/ndbm.py module, based on the _dbm extension is also
affected.  You can build the _dbm extension using libgdbm-compat-dev, however
that changes the on-disk format, and the license used (likely the new one should
be moved into the python3-gdbm package).

Matthias

Bug#988119: micro-evtd: "/etc/init.d/micro-evtd stop" broken (world-writable pid file)

[Ryan Tandy]

The status file is also world writable.

$ ls -l /run/micro-evtd.*
-rw-rw-rw- 1 root root  4 May  5 22:32 /run/micro-evtd.pid
-rw-rw-rw- 1 root root 39 May  5 22:33 /run/micro-evtd.status

Bug#988083: unblock: micro-evtd/3.4-6

[Ryan Tandy]

I'm sorry, I belatedly noticed another issue with micro-evtd.

#988119: the daemon creates its pid and status files with mode 666, 
start-stop-daemon doesn't like that and refuses to stop the daemon.


I don't know what the appropriate severity is for that one. If it's RC I 
can make another upload to fix it.


Sorry for the noise.

Bug#988121: postgresql-13: reduce Build-Depends

[Helmut Grohne]

Source: postgresql-13
Version: 13.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

Making postgresql cross buildable likely is a longer story, but there
are already pieces that are readily applicable today.

The immediate issue is that its Build-Depends are not cross-satisfiably.
There are multiple reasons for this one of which is libio-pty-perl. I've
grepped through the sources for /io..?pty/i and found only occurences
used in tests. I've performed a nocheck build with this dependency
dropped and it worked. Unfortunately, since postgresql is not
reproducible, we cannot validate a nocheck build against a regular
build. Given these findings, I think it is a fair compromise to annotate
libio-pty-perl . Do you agree?

Beyond this, I figured that libipc-run-perl can be dropped when passing
--disable-tap-tests, which seems fine during nocheck. Unfortunately,
postgresql embeds its configure flags in pg_config and others. Varying
configure flags therefore make postgresql unreproducible. Would it be
sensible to delete configure flags from pg_config?

In general, making postgresql reproducible would help a lot in further
reducing its Build-Depends as automated tools can tell you which
dependencies are unused in that case.

So can we just annotate libio-pty-perl for now?

Helmut
diff --minimal -Nru postgresql-13-13.2/debian/changelog 
postgresql-13-13.2/debian/changelog
--- postgresql-13-13.2/debian/changelog 2021-02-10 17:33:55.0 +0100
+++ postgresql-13-13.2/debian/changelog 2021-05-06 06:53:00.0 +0200
@@ -1,3 +1,10 @@
+postgresql-13 (13.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate libio-pty-perl dependency . (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 06 May 2021 06:53:00 +0200
+
 postgresql-13 (13.2-1) unstable; urgency=medium
 
   * New upstream version.
diff --minimal -Nru postgresql-13-13.2/debian/control 
postgresql-13-13.2/debian/control
--- postgresql-13-13.2/debian/control   2021-01-29 13:35:42.0 +0100
+++ postgresql-13-13.2/debian/control   2021-05-06 06:52:59.0 +0200
@@ -20,7 +20,7 @@
  gdb ,
  gettext,
  libicu-dev,
- libio-pty-perl,
+ libio-pty-perl ,
  libipc-run-perl,
  libkrb5-dev,
  libldap2-dev,

Bug#988120: jigdo-file: Fails to re-use its own cache file and misses files in mounted ISO image

[Pascal]

Package: jigdo-file
Version: 0.8.0-1
Severity: normal
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

Jigdo version is now 0.8.0.1 for bullseye testing and 0.7.3.5 for buster
stable.

We can use jigdo for downloading ISOs from the servers and it works fine for
both versions.

The problem with version 0.8.0.1 is when we want to make ISOs from a previous
(bigger) image.

For a precise example we have a big BD ISO image :
debian-10.7.0-amd64-BD-1.iso, mounted on /media/user/ (or /mnt/cdrom/).
>From that big one, we want to make up the 5 first DVD ISOs
debian-10.7.0-amd64-DVD-1.iso to debian-10.7.0-amd64-DVD-5.iso.

With Jigdo 0.7.3.5 everything works perfectly fine. Jigdo reads the big mounted
BD-1 image. It writes a "jigdo-file-cache.db" cache info data file at the first
reading of the BD-1 image, so that it does not need to re-read BD-1 next times.
So the making up of DVD-2 to DVD-5 is very quick.
Of course Jigdo finds everything it needs in BD-1 to make DVD-1 to DVD-5,
without having to connect to the servers (Internet). And that is the point
(what we want), to be able to do that, in case we don't have access to
Internet.

But with Jigdo 0.8.0.1 :
- First jigdo does not even seem to re-use the jigdo-file-cache.db (by the way
twice bigger with 0.8.0.1 than with 0.7.3.5) it has created the first time. So
Jigdo has to read and analyse BD-1 all over again every time. And it is very,
but vry long, as it seems the checking method (for every *.deb file) is
different with Jigdo 0.8.0.1.
- And second, jigdo fails to recognize some existing files in BD-1. For
instance, DVD-1 and 2 are fine but for DVD-3 Jigdo fails to fetch
/pool/contrib/b/b43-fwcutter/b43-fwcutter_019-4+deb10u1_amd64.deb in BD-1 and
has to fetch it on the servers. For DVD-4 Jigdo fails to fetch
/pool/contrib/a/alsa-tools/alsa-firmware-loaders_1.1.7-1_amd64.deb. I did not
try DVD-5 (so irritatingly slow!) but from a previous try that I made two
months ago, I think I remember there were more than one *.deb file missing.

So these little bugs are very saddening because Jigdo is such a beautiful and
useful tool. This little guy can really do a great job and I wish it would be
on DVD-1, regardless of actual usage statistics.

Cordially,
Pascal.


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
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 jigdo-file depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-11
ii  libdb5.3 5.3.28+dfsg1-0.8
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libstdc++6   10.2.1-6
ii  wget 1.21-1+b1
ii  zlib1g   1:1.2.11.dfsg-2

jigdo-file recommends no packages.

jigdo-file suggests no packages.

Bug#863620: Re : 24 Hours

[E.E.PU 105 RUE LEMERCIER PARIS 17]

> 
> Hello,
> 
> 
> 
> 
> Are you interested in Bitcoin Trade? Invest £ 220 and earn £ 2,000 in 24 
> hours (1 day). Ask me how!
> 
> 
> 
> 
> Contact me now on Whatsapp: +44 7868 688520
> 
> 
> 
> 
> Le 0/0521, "E7"  <> a écrit :
> > Je vous tiens au courant.
> > 
> > Le 0/0521, 4" arisr a écrit :
> > > 
> > >  
> > >  
> > > 
> > > 
> > >  
> > >  
> > > mon autotest est négatif.
> > >  
> > > Tu nous diras si ton PCR est + ; il se peut qu'il ne le soit pas. Ce n'e
> > > 
> > > 
> > > 
> > >  
> > >  
> > >  
> > > 
> > > 
> > >De : BROCHAN
> > > 
> > > Envoyé : mercredi
> > > 
> > > À : Ce
> > > 
> > > Cc : E.E.PU 105 RUE LEMERCIER PARIS 17; brochant
> > > 
> > > Objet : Re: autotest positif
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
>  
> 
--
N Navarrodirectrice
école élémentaire
105 Lemercier 17è
01 46 27 31 60

Bug#985428: mirror submission for mirror.sabay.com.kh

[Sabay Mirrors]

Hello,

Any news about our mirror submission ?

Thanks,



Nicolas Renault
Infrastructure Automation Engineer
+855 (0)96 948 5325
www.sabay.com

Bug#922815: What is the current workaround?

[Kurt Fitzner]

Installing rcconf also installs sysv-rc, insserv, and startpar. 
Installing initscripts also installs sysv-rc, insserv, and startpar . 
If neither of those scenarios make sense without sysvinit installed,
then yes, it clearly should be dependency somewhere.  If insserv is not
relevant on a systemd system, then please put in a conflicts. 

As far as how it is even useful, honestly, I am not an expert on systemd
(who is?).  I had previously understood that rcconf on modern Debian
systems interfaced with systemd through some sort of compatibility
layer.  The way that "sudo service lighttpd start" and "sudo systemctl
start lighttpd" both do the same thing.  This seems not to be the case. 
I don't know what all is involved under the hood for rcconf or Debian's
init systems, nor should I have to.  I should know what tools are
available and expect that they will work.  And if tool A is not
compatible with initsystem B, then it's not unreasonable to expect that
trying to install A when B is there will run into a conflict somewhere. 

So yes, if this is a nonsensical combination, please do put in the
dependencies and conflicts that will enforce that for whatever packages
you maintain. 

Thank-you. 

On 2021-05-05 00:20, Thorsten Glaser wrote:

> On Tue, 4 May 2021, Kurt Fitzner wrote:
> 
>> I just tried to install rcconf on a Debian testing sytem.  Since rcconf
> 
> How is rcconf even useful on a nōn-sysvinit+sysv-rc system?
> 
> Maybe rcconf should depend on that or conflict with all others?
> 
> bye,
> //mirabilos

Bug#988119: micro-evtd: "/etc/init.d/micro-evtd stop" broken (world-writable pid file)

[Ryan Tandy]

Package: micro-evtd
Version: 3.4-5
Severity: normal

I just noticed while testing 3.4-6, that stopping the daemon doesn't work:

May 05 19:32:22 LS-GL2B6 systemd[1]: Stopping LSB: Daemon for Linkstation/Kuro 
micro controller...
May 05 19:32:23 LS-GL2B6 micro-evtd[578]: Stopping Daemon for Linkstation/Kuro 
micro controller: micro-evtd
May 05 19:32:23 LS-GL2B6 micro-evtd[587]: start-stop-daemon: matching on 
world-writable pidfile /var/run/micro-evtd.pid is insecure
May 05 19:32:23 LS-GL2B6 systemd[1]: micro-evtd.service: Control process 
exited, code=exited, status=2/INVALIDARGUMENT
May 05 19:32:23 LS-GL2B6 systemd[1]: micro-evtd.service: Failed with result 
'exit-code'.
May 05 19:32:23 LS-GL2B6 systemd[1]: micro-evtd.service: Unit process 563 
(micro-evtd) remains running after unit stopped.
May 05 19:32:23 LS-GL2B6 systemd[1]: Stopped LSB: Daemon for Linkstation/Kuro 
micro controller.

According to the man page of start-stop-daemon, this would affect the version 
in buster as well.

Bug#988089: [debian-mysql] Bug#988089: mariadb-server: MariaDB uninstalled on dist-upgrade Debian 10 -> 11

[Otto Kekäläinen]

Thanks for reporting!

We constantly test updates from older distros and MariaDB versions in
our Salsa-CI pipeline, and it does not show the symptoms your system
had.

Would it be possible for you to provide exact steps on how to
reproduce this in a Docker image or virtual machine?

If it only happens on one machine and cannot be reproduced, we can't
help much. Therefore steps to reproduce are very important.

Bug#988118: unblock: md4c/0.4.7-2

[Patrick Franz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: patfr...@gmail.com

Please unblock package md4c

[ Reason ]
It fixes CVE-2021-30027 affecting bullseye.
See Security tracker at [1].

[ Impact ]
A malformed Markdown documenta malformed Markdown document can allow
attackers to trigger the use of uninitialised memory and thereby
cause a denial of service.
See Security tracker at [1].

[ Tests ]
The upstream issue tracker [2] provides an example document which
can trigger the bug.
The issue is marked as fixed upstream though no automated tests
cover the issue.

[ Risks ]
The package is a key package, i.e. a dependency of libqt5gui5 which
in turn is a dependency of a plethora of packages.
The changes are not too extensive though not trivial. I am not
familiar with the source code to determine whether the changes
cause any other risks.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
Security Tracker:
  [1] https://security-tracker.debian.org/tracker/CVE-2021-30027
Upstream Issue Tracker:
  [2] https://github.com/mity/md4c/issues/155

unblock md4c/0.4.7-2

diff -Nru md4c-0.4.7/debian/changelog md4c-0.4.7/debian/changelog
--- md4c-0.4.7/debian/changelog 2020-12-30 09:21:56.0 +0100
+++ md4c-0.4.7/debian/changelog 2021-05-03 15:21:36.0 +0200
@@ -1,3 +1,10 @@
+md4c (0.4.7-2) unstable; urgency=medium
+
+  * Cherry-pick commit to handle CVE-2021-30027 which can cause a denial
+of service (Closes: #987799).
+
+ -- Patrick Franz   Mon, 03 May 2021 15:21:36 +0200
+
 md4c (0.4.7-1) unstable; urgency=medium
 
   * New upstream release (0.4.7).
diff -Nru md4c-0.4.7/debian/patches/fix_CVE-2021-30027.patch 
md4c-0.4.7/debian/patches/fix_CVE-2021-30027.patch
--- md4c-0.4.7/debian/patches/fix_CVE-2021-30027.patch  1970-01-01 
01:00:00.0 +0100
+++ md4c-0.4.7/debian/patches/fix_CVE-2021-30027.patch  2021-05-03 
15:21:36.0 +0200
@@ -0,0 +1,87 @@
+Description: Fix CVE-2021-30027
+ md_analyze_line in md4c.c in md4c 0.4.7 allows attackers
+ to trigger use of uninitialized memory, and cause 
+ a denial of service via a malformed Markdown document.
+Author: upstream
+Forwarded: not-needed
+
+---
+ src/md4c.c | 24 +++-
+ 1 file changed, 15 insertions(+), 9 deletions(-)
+
+--- a/src/md4c.c
 b/src/md4c.c
+@@ -5864,7 +5864,7 @@ md_analyze_line(MD_CTX* ctx, OFF beg, OFF* p_end,
+ 
+ /* Check whether we are Setext underline. */
+ if(line->indent < ctx->code_indent_offset  &&  pivot_line->type == 
MD_LINE_TEXT
+-&&  (CH(off) == _T('=') || CH(off) == _T('-'))
++&&  off < ctx->size  &&  ISANYOF2(off, _T('='), _T('-'))
+ &&  (n_parents == ctx->n_containers))
+ {
+ unsigned level;
+@@ -5877,7 +5877,10 @@ md_analyze_line(MD_CTX* ctx, OFF beg, OFF* p_end,
+ }
+ 
+ /* Check for thematic break line. */
+-if(line->indent < ctx->code_indent_offset  &&  ISANYOF(off, 
_T("-_*"))  &&  off >= hr_killer) {
++if(line->indent < ctx->code_indent_offset
++&&  off < ctx->size  &&  off >= hr_killer
++&&  ISANYOF(off, _T("-_*")))
++{
+ if(md_is_hr_line(ctx, off, , _killer)) {
+ line->type = MD_LINE_HR;
+ break;
+@@ -5941,7 +5944,7 @@ md_analyze_line(MD_CTX* ctx, OFF beg, OFF* p_end,
+ {
+ /* Noop. List mark followed by a blank line cannot interrupt 
a paragraph. */
+ } else if(pivot_line->type == MD_LINE_TEXT  &&  n_parents == 
ctx->n_containers  &&
+-(container.ch == _T('.') || container.ch == _T(')'))  
&&  container.start != 1)
++ISANYOF2_(container.ch, _T('.'), _T(')'))  &&  
container.start != 1)
+ {
+ /* Noop. Ordered list cannot interrupt a paragraph unless the 
start index is 1. */
+ } else {
+@@ -5982,7 +5985,9 @@ md_analyze_line(MD_CTX* ctx, OFF beg, OFF* p_end,
+ }
+ 
+ /* Check for ATX header. */
+-if(line->indent < ctx->code_indent_offset  &&  CH(off) == _T('#')) {
++if(line->indent < ctx->code_indent_offset  &&
++off < ctx->size  &&  CH(off) == _T('#'))
++{
+ unsigned level;
+ 
+ if(md_is_atxheader_line(ctx, off, >beg, , )) {
+@@ -5993,7 +5998,7 @@ md_analyze_line(MD_CTX* ctx, OFF beg, OFF* p_end,
+ }
+ 
+ /* Check whether we are starting code fence. */
+-if(CH(off) == _T('`') || CH(off) == _T('~')) {
++if(off < ctx->size  &&  ISANYOF2(off, _T('`'), _T('~'))) {
+ if(md_is_opening_code_fence(ctx, off, )) {
+ line->type = MD_LINE_FENCEDCODE;
+ line->data = 1;
+@@ -6002,7 +6007,8 @@ md_analyze_line(MD_CTX* ctx, OFF beg, OFF* p_end,
+   

Bug#975555: sshguard on buster does not work.

[Trent W. Buck]

Pat Suwalski wrote:
> Package: sshguard
>
> Upon upgrading to buster, sshguard in all of my deployments has stopped
> working.
>
> I suspect this line in the Debian changelog:
>
>   * debian/sshguard.service, Use nft instead iptables.
>
> There doesn't seem to be any obvious way to change this back to iptables.

Debian 10 defaults to nftables, and iptables(8) is a backcompat wrapper:

bash5$ mmdebstrap --quiet buster /dev/null --include=iptables 
--customize-hook='chroot $1 readlink -f /usr/sbin/iptables'
/usr/sbin/xtables-nft-multi

sshguard should Just Work even if your main firewall is still using xtables 
directly.
Linux will happily operate with some firewall rules in xtables, and some 
firewall rules in nft --- but it can be VERY hard to debug!

If you want iptables(8) to use xtables instead of nft,
configure it via update-alternatives.

If you want sshguard to use ipset(8) or iptables(8) instead of nft(8),
change this line in /etc/sshguard/sshguard.conf:

BACKEND="/usr/lib/x86_64-linux-gnu/sshg-fw-nft-sets"

Bug#988114: shim-signed fails to install and remove

[Norbert Preining]

Hi Steve,

> I *think* I might see what's going on here. Did you switch your system
> to using EFI by hand at some point? On a system installed via d-i

Buuhhh, not that I am aware off. AFAIR (but this is quite some time ago)
I installed it from a installer iso dumped onto an USB stick.

> etc., I would expect to see grub-efi-amd64 installed. And that's the

Hmm, should I install it? It seems that grub works properly atm, so
touching these kind of things is always scary for me.

Best

Norbert

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

Bug#988114: shim-signed fails to install and remove

[Steve McIntyre]

On Thu, May 06, 2021 at 09:24:34AM +0900, Norbert Preining wrote:
>Hi Steve,
>
>> Hmmm. Do you have an EFI system here?
>
>Yes.
>$ efibootmgr
>BootCurrent: 0001
>Timeout: 1 seconds
>BootOrder: 0001,0002,,0009,0004,000A,000B
>Boot* Windows Boot Manager
>Boot0001* grub
>Boot0002* rEFInd Boot Manager
>Boot0004  Hard Drive
>Boot0009* debian
>Boot000A  Hard Drive
>Boot000B  USB Floppy
>$

Thanks for the debug information, it's really helpful!

I *think* I might see what's going on here. Did you switch your system
to using EFI by hand at some point? On a system installed via d-i
etc., I would expect to see grub-efi-amd64 installed. And that's the
package that would normally hold the grub debconf settings that shim
is looking for...

>> What does "dpkg -l '*grub*'"
>
>un  grub(no description available)
>un  grub-cloud-amd64(no description available)
>ii  grub-common   2.04-18  amd64GRand Unified Bootloader 
>(common files)
>un  grub-coreboot   (no description available)
>ii  grub-customizer   5.1.0-3  amd64GUI to configure GRUB2 and 
>BURG
>un  grub-doc(no description available)
>un  grub-efi(no description available)
>un  grub-efi-amd64  (no description available)
>ri  grub-efi-amd64-bin2.04-18  amd64GRand Unified Bootloader, 
>version 2 (EFI-AMD64 modules)
>ii  grub-efi-amd64-signed 1+2.04+18amd64GRand Unified Bootloader, 
>version 2 (amd64 UEFI signed by Debian)
>un  grub-efi-arm(no description available)
>un  grub-efi-arm64  (no description available)
>un  grub-efi-ia32   (no description available)
>un  grub-efi-ia64   (no description available)
>un  grub-emu(no description available)
>un  grub-ieee1275   (no description available)
>un  grub-legacy (no description available)
>un  grub-legacy-doc (no description available)
>un  grub-linuxbios  (no description available)
>un  grub-pc (no description available)
>un  grub-uboot  (no description available)
>un  grub-xen(no description available)
>un  grub-yeeloong   (no description available)
>un  grub2   (no description available)
>ii  grub2-common  2.04-18  amd64GRand Unified Bootloader 
>(common files for version 2)

In the longer term, I think we'll need to add a trigger for something
like "grub-efi-install" to make things quicker, but I'm trying to
minimise the impact of the shim changes I'm making this close to
release. So for now I'm going to add extra fallback code to deal with
db_get failing, and that should fix this bug.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?

Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs

[Thorsten Glaser]

On Wed, 5 May 2021, Felix Lechner wrote:

> > X: klibc source: non-consecutive-debian-revision 2.0.8-6 -> 2.0.8-6.1
> 
> Where may I find your NMU for klibc, please?

I haven’t uploaded it yet, let’s give bwh a chance to do it first ;)
Attached.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"Format: 3.0 (quilt)
Source: klibc
Binary: libklibc-dev, libklibc, klibc-utils
Architecture: linux-any
Version: 2.0.8-6.1
Maintainer: Debian Kernel Team 
Uploaders: Ben Hutchings , maximilian attems 
Homepage: https://git.kernel.org/cgit/libs/klibc/klibc.git
Standards-Version: 4.1.2
Vcs-Browser: https://salsa.debian.org/kernel-team/klibc
Vcs-Git: https://salsa.debian.org/kernel-team/klibc.git
Build-Depends: debhelper-compat (= 12), linux-libc-dev, m4 [sparc]
Build-Conflicts: ccache
Package-List:
 klibc-utils deb libs optional arch=linux-any
 libklibc deb libs optional arch=linux-any
 libklibc-dev deb libdevel optional arch=linux-any
Checksums-Sha1:
 eaa050b663783e1278c9038a76c21a605af701c9 472200 klibc_2.0.8.orig.tar.xz
 2ca3434380de25cc6b9aa9080fc5feb5752f484c 26008 klibc_2.0.8-6.1.debian.tar.xz
Checksums-Sha256:
 4e48f1398cfe3ce0b6df55ce6e70acf54fc8488e3aea3fb3610ee1622d9cb436 472200 klibc_2.0.8.orig.tar.xz
 0f02c2c6767c2cd4282dcca1065d8d5e99e46614c9628b261b8e0c92f3cfe0cd 26008 klibc_2.0.8-6.1.debian.tar.xz
Files:
 bdd05bf16fce534e7a49d98644cdec87 472200 klibc_2.0.8.orig.tar.xz
 da02991a022086b2f2e6faebc4b96809 26008 klibc_2.0.8-6.1.debian.tar.xz


klibc_2.0.8-6.1.debian.tar.xz
Description: application/xz

Bug#988114: shim-signed fails to install and remove

[Norbert Preining]

Hi Steve,

> Hmmm. Do you have an EFI system here?

Yes.
$ efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0002,,0009,0004,000A,000B
Boot* Windows Boot Manager
Boot0001* grub
Boot0002* rEFInd Boot Manager
Boot0004  Hard Drive
Boot0009* debian
Boot000A  Hard Drive
Boot000B  USB Floppy
$

> What does "dpkg -l '*grub*'"

un  grub(no description available)
un  grub-cloud-amd64(no description available)
ii  grub-common   2.04-18  amd64GRand Unified Bootloader 
(common files)
un  grub-coreboot   (no description available)
ii  grub-customizer   5.1.0-3  amd64GUI to configure GRUB2 and 
BURG
un  grub-doc(no description available)
un  grub-efi(no description available)
un  grub-efi-amd64  (no description available)
ri  grub-efi-amd64-bin2.04-18  amd64GRand Unified Bootloader, 
version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed 1+2.04+18amd64GRand Unified Bootloader, 
version 2 (amd64 UEFI signed by Debian)
un  grub-efi-arm(no description available)
un  grub-efi-arm64  (no description available)
un  grub-efi-ia32   (no description available)
un  grub-efi-ia64   (no description available)
un  grub-emu(no description available)
un  grub-ieee1275   (no description available)
un  grub-legacy (no description available)
un  grub-legacy-doc (no description available)
un  grub-linuxbios  (no description available)
un  grub-pc (no description available)
un  grub-uboot  (no description available)
un  grub-xen(no description available)
un  grub-yeeloong   (no description available)
un  grub2   (no description available)
ii  grub2-common  2.04-18  amd64GRand Unified Bootloader 
(common files for version 2)

Best

Norbert

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

Bug#928525: Confirming

[Trent W. Buck]

gi1242+debianb...@gmail.com wrote:
> Confirming I have this problem too. My /etc/sshguard/sshguard.conf has
> 
> LOGREADER="LANG=C /bin/journalctl -afb -p info -n1 -o cat 
> SYSLOG_FACILITY=4 SYSLOG_FACILITY=10"
> 
> The example provided by upstream has
> 
> LOGREADER="LANG=C journalctl -afb -p info -n1 -t sshd -t sendmail -o cat"
> 
> Changing it to this makes the problem go away. (Since I use postfix, I
> used  "-t postfix/smtpd" instead of sendmail.)

I just woke up, but
I think the (unstated) underlying issue is that sshguard reads logs from 
*ITSELF* and
considers those grounds for blocking?

The suggested fix is now only looking at log events for OpenSSH and 
sendmail/postfix.
This will disable sshguard protection for other services (I personally care 
about dovecot imapd):

enum service {
SERVICES_ALL= 0,//< anything
SERVICES_SSH= 100,  //< ssh
SERVICES_SSHGUARD   = 110,  //< SSHGuard
SERVICES_UWIMAP = 200,  //< UWimap for imap and pop daemon
SERVICES_DOVECOT= 210,  //< dovecot
SERVICES_CYRUSIMAP  = 220,  //< cyrus-imap
SERVICES_CUCIPOP= 230,  //< cucipop
SERVICES_EXIM   = 240,  //< exim
SERVICES_SENDMAIL   = 250,  //< sendmail
SERVICES_POSTFIX= 260,  //< postfix
SERVICES_OPENSMTPD  = 270,  //< OpenSMTPD
SERVICES_COURIER= 280,  //< Courier IMAP/POP
SERVICES_FREEBSDFTPD= 300,  //< ftpd shipped with FreeBSD
SERVICES_PROFTPD= 310,  //< ProFTPd
SERVICES_PUREFTPD   = 320,  //< Pure-FTPd
SERVICES_VSFTPD = 330,  //< vsftpd
SERVICES_COCKPIT= 340,  //< cockpit management dashboard
SERVICES_CLF_UNAUTH = 350,  //< HTTP 401 in common log format
SERVICES_CLF_PROBES = 360,  //< probes for common web services
SERVICES_CLF_WORDPRESS  = 370,  //< WordPress logins in common log 
format
SERVICES_OPENVPN= 400,  //< OpenVPN
};

The "CLF" ones are also ignored by Debian's default config due to lacking 
something like

FILES="/var/log/nginx/access.log 
/var/log/apache2/over_vhosts_something_something.log"

This is because they match NSCA "common log format" entries which (normally) go 
to a dedicated file, not journal/syslog.

Systemd doesn't support something like "journalctl _UNIT!=sshguard.service".
Until it does, I think the suggested -t approach is probably the clearest & 
safest, but
needs an exhaustive list, which can be a pain.
If I had a good answer, I'd have already filed a bug about this! :-(


PPS: I also had a go at patching in ".d dropin directory" support, but it 
doesn't work quite right:

---
- hosts: all
  tasks:
- name: sshguard config
  tags: firewall, sshguard
  block:
  # FIXME: file a bug in Debian asking for native 
/etc/sshguard/sshguard.conf.d/foo.conf "dropin" support.
  # FIXME: by default sshguard reads from SYSLOG_FACILITY=AUTH|AUTHPRIV,
  #i.e. it's reading from the journald equivalent of auth.log.
  #HOWEVER, at a minimum, tinysshd logs to 
SYSLOG_FACILITY=DAEMON.
  #We need to verify that the journalctl policy actually 
matches what we expect.
  # FIXME: debian sshguard doesn't journalctl --system by default, so
  #it will unnecessarily scan logs from per-user journals.
  # FIXME: will journalctl show logs from systemd containers?
  #i.e. without -M is it -M  or -M  ?
  #I suspect the answer is "you need --merge", BLERGH.
  #
  # FIXME: note that scanning nginx is only useful if nginx is actually 
doing password auth!
  #
  # FIXME: if we can sensibly match all relevant services, adding e.g.
  #  -t ssh -t dovecot -t postfix@-
  #to the journalctl command will be clear (*and* slightly 
faster?)
  - file: dest=/etc/systemd/system/sshguard.service.d state=directory  
# sigh, no "make-parent-dirs: true"?
  - copy:
  dest: 
/etc/systemd/system/sshguard.service.d/cyber-sshguard-conf-pseudo-dropin.conf
  content: |
# /etc/sshguard.conf is sourced by a sh script.
# It doesn't have dropins built-in, so rather than adding ". 
/etc/sshguard.conf",
# we can load the options in here.
# NOTE: due to the load order,
# entries in /etc/sshguard.conf entries will "win" over dropins 
:-(
[Service]
EnvironmentFile=-/etc/sshguard/sshguard.conf
EnvironmentFile=-/etc/sshguard/sshguard.conf.d/*.conf
  - file: dest=/etc/sshguard/sshguard.conf.d state=directory  # sigh, 
no "make-parent-dirs: true"?
  - name: Ensure sshguard reads sees nginx (not JUST ssh/dovecot)
copy:
  

Bug#988117: flatpak: Resolved, please close.

[Oliver Schode]

Package: flatpak
Followup-For: Bug #988117

Sorry, turns out flatpak fish is bound to the SDK runtime, which I didn't want
to install. There is no bug.

Regards

Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs

[Felix Lechner]

Hi,

On Wed, May 5, 2021 at 12:57 PM Thorsten Glaser  wrote:
>
> X: klibc source: non-consecutive-debian-revision 2.0.8-6 -> 2.0.8-6.1

Where may I find your NMU for klibc, please?

I believe the issue your are seeing was fixed in this unreleased commit:


https://salsa.debian.org/lintian/lintian/-/commit/f7f4ac033fcc0939fe26ac59732878c7ad46be3b

Please have a look at Lintian's new website, which shows tags
generated by our development version. I cannot see any NMU related
tags there. [1]

Kind regards
Felix Lechner

[1] https://lintian.debian.net/tags/non-consecutive-debian-revision

Bug#979668: pulseeffects: please build with rnnoise plugin

[Paul Wise]

On Sun, 10 Jan 2021 00:58:21 +0300 Roman Lebedev wrote:

> It would appear that rnnoise itself isn't packaged in Debian presently,
> though.

rnnoise was trained using proprietary data, more details here:

https://bugs.debian.org/980839

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#988117: flatpak: Some flatpaks unusable with /bin linked

[Oliver Schode]

Package: flatpak
Version: 1.10.2-1
Severity: normal
Tags: upstream

Hi!

I'm reporting this for flatpak even though point of failure and error
message refer to bubblewrap (here 0.4.1-3), but it's clearly more of a
flatpak (or flathub) issue. Some of their packages cannot be started
once /bin is a link to /usr/bin, as is by now the installation default I
think.

To give an example, let's say I'm pulling in the fish shell, single
partition scenario, then doing the obvious:

flatpak run com.visualstudio.code.tool.fish

I'll just get an exec error for /bin/sh: no such file

There a good reasons for generally not using CLI apps via flatpak to
begin with, but that's not the point of this report of course.

Regards,
Oliver

Bug#988114: shim-signed fails to install and remove

[Steve McIntyre]

On Thu, May 06, 2021 at 07:58:45AM +0900, Norbert Preining wrote:
>Hi Steve,
>
>thanks for the quick response!
>
>On Wed, 05 May 2021, Steve McIntyre wrote:
>> Could you add "set -x" to the postinst and postrm scripts please? That
>
>The postrm script ends with
>
>+ which grub-install
>+ OPTIONS=
>+ db_get grub2/force_efi_extra_removable
>+ _db_cmd GET grub2/force_efi_extra_removable
>+ _db_internal_IFS=
>
>+ IFS=
>+ printf %s\n GET grub2/force_efi_extra_removable
>+ IFS=
>
>+ read -r _db_internal_line
>+ IFS=
>
>+ RET=10 grub2/force_efi_extra_removable doesn't exist
>+ return 10

Hmmm. Do you have an EFI system here? What does "dpkg -l '*grub*'"
say, please? Trying to work out how that debconf setting might not be
available.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#988116: ITP: libdecor-0.1 -- client-side decoration library for Wayland

[Christian Rauch]

Package: wnpp
Owner: Christian Rauch 
Severity: wishlist

* Package name: libdecor-0.1
  Version : 0.1.0
  Upstream Author : Jonas Ådahl 
Christian Rauch 
* URL : https://gitlab.gnome.org/jadahl/libdecoration
* License : MIT
  Programming Lang: C
  Description : client-side decoration library for Wayland

"libdecor" is a library that can be used by Wayland clients to implement
client-side window decorations. Client-side decorations are needed on
Wayland if the compositor/server does not support server-side
decorations (such as mutter/GNOME Shell).
This library is mainly intended to be used by applications or frameworks
which do not use a toolkit that already implements client-side
decorations (such as GTK or Qt). Candidates for this are SDL, GLFW,
Blender, and any other pure OpenGL application.

SDL intends to adapt "libdecor" once a 0.1 release has been tagged:
https://github.com/libsdl-org/SDL/pull/4068. At this point, "libdecor"
will become a dependency.

I am already maintaining an Ubuntu ppa at:
https://launchpad.net/~christianrauch/+archive/ubuntu/libdecoration
but would like to upstream the package into Debian.

Since this is my first time packaging a library for Debian, I could use
support from a co-maintainer who is familiar with Wayland. Potentially,
the maintainer for SDL would be a suitable match to better coordinate
the dependency tracking.
The package itself is easy to maintain, but it could become a dependency
for many other packages in the future.
I will also need a sponsor to upload the package.

Bug#988114: shim-signed fails to install and remove

[Norbert Preining]

Hi Steve,

thanks for the quick response!

On Wed, 05 May 2021, Steve McIntyre wrote:
> Could you add "set -x" to the postinst and postrm scripts please? That

The postrm script ends with

+ which grub-install
+ OPTIONS=
+ db_get grub2/force_efi_extra_removable
+ _db_cmd GET grub2/force_efi_extra_removable
+ _db_internal_IFS=

+ IFS=
+ printf %s\n GET grub2/force_efi_extra_removable
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=10 grub2/force_efi_extra_removable doesn't exist
+ return 10

Best

Norbert

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

Bug#758035: Intersolar Europe 2021 Visitors Info List

[James Brown]

Hello,


I understand that you were one of the Exhibitors in the show

Intersolar Europe
21 - 23 Jul 2021
Exhibition Munich, Munich, Germany

Are you interested in acquiring the Attendee's info? (27,000 Contacts)


Attendee's information fields: Company Name, Company URL, Contact Names, Title, 
Phone Number, Email Address.


Let me know your thoughts so that I can send the cost and additional 
information.

We are looking forward to hearing from you!

Note: If the attendee's info is not relevant to you please reply with your 
Target Market and Geography, we have all types of target market available

Best Regards,
James Brown
Marketing Executive

Bug#922815: What is the current workaround?

[Thorsten Glaser]

On Wed, 5 May 2021, Kurt Fitzner wrote:

> So yes, if this is a nonsensical combination, please do put in the
> dependencies and conflicts that will enforce that for whatever packages
> you maintain. 

I don’t maintain *any* of these packages. I just learnt that
such a thing as rcconf exists at all and wondered about its
description. Why don’t you ask the rcconf maintainer about this?

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

Bug#988115: erlang-p1-xmpp: Crashs with Ejabberd 21.01

[pitchum]

Package: erlang-p1-xmpp
Version: 1.5.2-2
Severity: important

Dear Maintainer,

after upgrading ejabberd to version 21.01 from Bullseye (Debian testing) I
started to see crashes in the logs and some users (not all users) reported
some weird behaviours (receiving the same room invitation again and again,
even after accepting or refusing the invitation).

This problem has been reported upstream in [3524] but the fix will be available
in ejabberd 21.04. As a workaround I have backported the [patch] from
erlang-xmpp 1.5.3 and it has been working fine for a few weeks now.

Could you also include this patch?
I hope it's not too late to have this bugfix included in Debian Bullseye. 


[3524]:https://github.com/processone/ejabberd/issues/3524
[patch]:https://github.com/processone/xmpp/commit/0de31e95

-- System Information:
Debian Release: 10.9
  APT prefers stable
  APT policy: (800, 'stable'), (90, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages erlang-p1-xmpp depends on:
ii  erlang-asn1 1:23.2.6+dfsg-1
ii  erlang-base [erlang-abi]1:23.2.6+dfsg-1
ii  erlang-crypto   1:23.2.6+dfsg-1
ii  erlang-idna 6.1.1-3
ii  erlang-p1-stringprep1.0.24-3
ii  erlang-p1-tls   1.1.11-2
ii  erlang-p1-utils 1.0.21-3
ii  erlang-p1-xml   1.1.45-3
ii  erlang-p1-zlib  1.0.9-3
ii  erlang-syntax-tools 1:23.2.6+dfsg-1
ii  erlang-unicode-util-compat  0.7.0-3
ii  libc6   2.31-9

erlang-p1-xmpp recommends no packages.

erlang-p1-xmpp suggests no packages.

-- no debconf information

Bug#988114: shim-signed fails to install and remove

[Steve McIntyre]

Hi Norbert,

On Thu, May 06, 2021 at 07:30:07AM +0900, Norbert Preining wrote:
>Package: shim-signed
>Version: 1.35+15.4-4
>Severity: normal
>X-Debbugs-Cc: norb...@preining.info
>
>The recent update of shim-signed (-2 to -4) breaks in strange way: I
>cannot install it:
>
>Performing actions...
>Setting up shim-signed:amd64 (1.35+15.4-4) ...
>dpkg: error processing package shim-signed:amd64 (--configure):
> installed shim-signed:amd64 package post-installation script subprocess 
> returned error exit status 10
>Errors were encountered while processing:
> shim-signed:amd64
>E: Sub-process /usr/bin/dpkg returned an error code (1)
>Setting up shim-signed:amd64 (1.35+15.4-4) ...
>dpkg: error processing package shim-signed:amd64 (--configure):
> installed shim-signed:amd64 package post-installation script subprocess 
> returned error exit status 10
>Errors were encountered while processing:
> shim-signed:amd64
>Press Return to continue, 'q' followed by Return to quit.
>
>
>Nor can I uninstall it:
>
>Performing actions...
>(Reading database ... 1078484 files and directories currently installed.)
>Removing shim-signed:amd64 (1.35+15.4-4) ...
>dpkg: error processing package shim-signed:amd64 (--remove):
> installed shim-signed:amd64 package post-removal script subprocess returned 
> error exit status 10
>dpkg: too many errors, stopping
>Errors were encountered while processing:
> shim-signed:amd64
>Processing was halted because there were too many errors.
>E: Sub-process /usr/bin/dpkg returned an error code (1)

Could you add "set -x" to the postinst and postrm scripts please? That
should help with some clue as to what's failing here.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead

Bug#937234: pam-python: Python2 removal in sid/bullseye

[Holger Levsen]

On Wed, May 05, 2021 at 04:55:06PM +0200, Dominik George wrote:
> @Mike, @Petter: Did you realise that pam-python is AGPL? It means that
> we cannot provide terminal servers or netbooting in Debian Edu without
> placing a prominent link to pam-python's sources on the desktop…
 
The pam-python website (http://pam-python.sourceforge.net/) also grants 
an additional permission "The copyright holders grant you an additional
permission under Section 7 of the GNU Affero General Public License,
version 3, exempting you from the requirement in Section 6 of the GNU
General Public License, version 3, to accompany Corresponding Source with
Installation Information for the Program or any work based on the Program.
You are still required to comply with all other Section 6 requirements to
provide Corresponding Source."


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

 & everyday for future too.


signature.asc
Description: PGP signature

Bug#988114: shim-signed fails to install and remove

[Norbert Preining]

Package: shim-signed
Version: 1.35+15.4-4
Severity: normal
X-Debbugs-Cc: norb...@preining.info

The recent update of shim-signed (-2 to -4) breaks in strange way: I
cannot install it:

Performing actions...
Setting up shim-signed:amd64 (1.35+15.4-4) ...
dpkg: error processing package shim-signed:amd64 (--configure):
 installed shim-signed:amd64 package post-installation script subprocess 
returned error exit status 10
Errors were encountered while processing:
 shim-signed:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up shim-signed:amd64 (1.35+15.4-4) ...
dpkg: error processing package shim-signed:amd64 (--configure):
 installed shim-signed:amd64 package post-installation script subprocess 
returned error exit status 10
Errors were encountered while processing:
 shim-signed:amd64
Press Return to continue, 'q' followed by Return to quit.


Nor can I uninstall it:

Performing actions...
(Reading database ... 1078484 files and directories currently installed.)
Removing shim-signed:amd64 (1.35+15.4-4) ...
dpkg: error processing package shim-signed:amd64 (--remove):
 installed shim-signed:amd64 package post-removal script subprocess returned 
error exit status 10
dpkg: too many errors, stopping
Errors were encountered while processing:
 shim-signed:amd64
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)


No further reporting.

Best



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

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

Versions of packages shim-signed depends on:
ii  grub-efi-amd64-bin 2.04-18
ii  grub2-common   2.04-18
ii  shim-helpers-amd64-signed  1+15.4+2
ii  shim-signed-common 1.35+15.4-4

Versions of packages shim-signed recommends:
pn  secureboot-db  

shim-signed suggests no packages.

-- no debconf information

Bug#943425: [klibc] Bug#943425: Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use

[Thorsten Glaser]

tags 943425 + patch
tags 988027 + patch
thanks

Dixi quod…

>Patches for klibc upstream git attched; I’m currently trying to test
>them, will report.

This was really tricky given we can’t install patched B-Ds on
porterboxen, but I managed. I can confirm this fixes my issue.

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
--- klibc-2.0.8/debian/changelog2021-04-30 03:05:23.0 +0200
+++ klibc-2.0.8/debian/changelog2021-05-05 21:38:31.0 +0200
@@ -1,3 +1,11 @@
+klibc (2.0.8-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix sig{set,long}jmp always saves the signal mask (Closes: #988027)
+  * [s390x] Fix {set,long}jmp registers to save (Closes: #943425)
+
+ -- Thorsten Glaser   Wed, 05 May 2021 21:38:31 +0200
+
 klibc (2.0.8-6) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru 
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
 
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
--- 
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
  1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
  2021-05-05 21:38:31.0 +0200
@@ -0,0 +1,71 @@
+From ba9cce08553cb49fe077485b13ae99548bb2da5c Mon Sep 17 00:00:00 2001
+From: mirabilos 
+Date: Wed, 5 May 2021 21:02:37 +0200
+Subject: [PATCH 1/2] [klibc] sig{set,long}jmp: do not ignore sigsetjmp's
+ second argument
+
+Save and restore the signal mask only if that argument is nonzero,
+as required by the standards.  (Closes: Debian #988027)
+
+Signed-off-by: mirabilos 
+---
+ usr/include/setjmp.h   | 7 ++-
+ usr/klibc/CAVEATS  | 3 +--
+ usr/klibc/siglongjmp.c | 3 ++-
+ 3 files changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/usr/include/setjmp.h b/usr/include/setjmp.h
+index abebccde..5916cd8a 100644
+--- a/usr/include/setjmp.h
 b/usr/include/setjmp.h
+@@ -27,6 +27,7 @@ __extern __noreturn longjmp(jmp_buf, int);
+ struct __sigjmp_buf {
+   jmp_buf __jmpbuf;
+   sigset_t __sigs;
++  unsigned char __sigs_saved;
+ };
+ 
+ typedef struct __sigjmp_buf sigjmp_buf[1];
+@@ -34,7 +35,11 @@ typedef struct __sigjmp_buf sigjmp_buf[1];
+ #define sigsetjmp(__env, __save) \
+ ({ \
+   struct __sigjmp_buf *__e = (__env); \
+-  sigprocmask(0, NULL, &__e->__sigs); \
++  if (__save) { \
++sigprocmask(0, NULL, &__e->__sigs); \
++__e->__sigs_saved = 1; \
++  } else \
++__e->__sigs_saved = 0; \
+   setjmp(__e->__jmpbuf); \
+ })
+ 
+diff --git a/usr/klibc/CAVEATS b/usr/klibc/CAVEATS
+index 5e991cb7..39949c28 100644
+--- a/usr/klibc/CAVEATS
 b/usr/klibc/CAVEATS
+@@ -13,8 +13,7 @@ Compiling with -O0 is more likely to work on gcc 3.
+ setjmp()/longjmp():
+ ---
+ setjmp() and longjmp() *do not* save signal state.  sigsetjmp() and
+-siglongjmp() *do* save the signal mask -- regardless of the value of
+-the extra argument.
++siglongjmp() *do* save the signal mask if the extra argument is nonzero.
+ 
+ The standards actually state that if you pass longjmp() a final value
+ of zero the library should change that to a 1!  Presumably the reason
+diff --git a/usr/klibc/siglongjmp.c b/usr/klibc/siglongjmp.c
+index 31042cbd..45f4e400 100644
+--- a/usr/klibc/siglongjmp.c
 b/usr/klibc/siglongjmp.c
+@@ -10,6 +10,7 @@
+ 
+ __noreturn siglongjmp(sigjmp_buf buf, int retval)
+ {
+-  sigprocmask(SIG_SETMASK, >__sigs, NULL);
++  if (buf->__sigs_saved)
++  sigprocmask(SIG_SETMASK, >__sigs, NULL);
+   longjmp(buf->__jmpbuf, retval);
+ }
+-- 
+2.31.1
+
diff -Nru 
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
 
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
--- 
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
  1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
  2021-05-05 21:38:31.0 +0200
@@ -0,0 +1,76 @@
+From fc5a53932ee56d61a9fd8db75784e9f39ca474a3 Mon Sep 17 00:00:00 2001
+From: mirabilos 
+Date: Wed, 5 May 2021 21:26:33 +0200
+Subject: [PATCH 2/2] [klibc] {set,long}jmp [s390x]: save/restore the correct
+ registers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The s390x ABI actually has FPU registers f8‥f15, not f1/f3/f5/f7,
+to be saved. (Closes: Debian #943425)
+
+Signed-off-by: mirabilos 
+---
+ usr/include/arch/s390/klibc/archsetjmp.h |  2 +-
+ usr/klibc/arch/s390/setjmp.S | 24 

Bug#988113: ddccontrol: new upstream release

[Paul Wise]

Package: ddccontrol
Severity: wishlist

There is a new upstream release available, please update to it:

https://github.com/ddccontrol/ddccontrol/releases/tag/0.5.2

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#987332: aprx automatically starts up with really bad default config

[Hibby]

Hi all,

I had a quick look at the code - config.c carries a validate_callsign_input() 
function, which I think we could patch a check in to cause the program to exit 
with an incorrect callsign for APRS-IS error.

Alternatively, it’s checking for a 6 character callsign, so we could make 
N0CALL-1  longer by a character or two in the config to force an error.

Do either of these seem like a reasonable way to force an error, or will this 
just end up with the failed upgrades we want to avoid?

—
Hibby
MM0RFN

Bug#987904: openstack-dashboard: fails to upgrade from buster if python3-cloudkitty-dashboard was installed and removed before the upgrade

[Andreas Beckmann]

Control: found -1 3:14.0.2-3+deb10u2
Control: retitle -1 openstack-dashboard: fails to (re-)configure after a plugin 
was removed but not purged

On 05/05/2021 22.19, Thomas Goirand wrote:

Thanks a lot for opening this bug, this brings light into a major defect
of the Horizon plugin packaging.

What happens is that the various python3-FOO- packages are
installing files in /etc/openstack-dashboard/enable. As they are in
/etc, they are CONFFILEs, and they aren't removed when the package is
removed, only when the package is actually purged.

When Horizon ugprades, it starts its "collecstatic" dance, meaning that
it loads its settings, and therefore, tries to load whatever is
described in /etc/openstack-dashboard/enable. And it fails because the
actual code, called from the "enable" folder, is gone (since the plugin
was removed).



So this actually is a bug in the plugins, that should have, to begin
with, removed the files they own in /etc/openstack-dashboard/enable
during the removal. I don't think this bug can be counted in Horizon itself.


That explains pretty clear what is going on here.
So the 5 install-remove-distupgrade-install buster->bullseye
tests actually found a nice bug ;-)

Easier receipe to reproduce (tested in buster, probably works in bullseye, too)

DEBIAN_FRONTEND=noninteractive apt-get install python3-cloudkitty-dashboard
dpkg -r python3-cloudkitty-dashboard
DEBIAN_FRONTEND=noninteractive dpkg-reconfigure openstack-dashboard


Now, I'm unsure what to do. These plugins should be fixed in Bullseye,
though the issue you reported is with packages from Buster. So the
various plugin packages must be fixed in Buster for this bug to be closed.


I have no idea how this could be fixed in the plugins ...
The conffiles must not be touched (e.g. deleted or edited) upon
removal, otherwise things will explode (or just not work any
more) after reinstall.

I quickly tried guarding the import:

--- /usr/lib/python3/dist-packages/openstack_dashboard/utils/settings.py.orig   
2021-05-05 21:13:28.789477232 +
+++ /usr/lib/python3/dist-packages/openstack_dashboard/utils/settings.py
2021-05-05 21:05:39.617000280 +
@@ -127,7 +127,11 @@
 
 if config.get('AUTO_DISCOVER_STATIC_FILES', False):

 for _app in _apps:
+  try:
 module = import_module(_app)
+  except ModuleNotFoundError:
+print("NOT INSTALLED:", _app)
+  else:
 base_path = os.path.join(module.__path__[0], 'static/')
 file_discovery.populate_horizon_config(horizon_config,
base_path)

which works, but there are more locations to be fixed.
Could still be easier than fixing all the plugins now.

Next failure is

NOT INSTALLED: cloudkittydashboard
Traceback (most recent call last):
  File "/usr/share/openstack-dashboard/manage.py", line 23, in 
execute_from_command_line(sys.argv)
  File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 364, in execute_from_command_line
utility.execute()
  File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 338, in execute
django.setup()
  File "/usr/lib/python3/dist-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 85, in 
populate
app_config = AppConfig.create(entry)
  File "/usr/lib/python3/dist-packages/django/apps/config.py", line 94, in 
create
module = import_module(entry)
  File "/usr/lib/python3.7/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1006, in _gcd_import
  File "", line 983, in _find_and_load
  File "", line 965, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'cloudkittydashboard'

That can be solved with

--- /usr/lib/python3/dist-packages/django/apps/registry.py.orig 2021-05-05 
21:22:03.673994464 +
+++ /usr/lib/python3/dist-packages/django/apps/registry.py  2021-05-05 
21:24:41.910153200 +
@@ -82,7 +82,11 @@
 if isinstance(entry, AppConfig):
 app_config = entry
 else:
+  try:
 app_config = AppConfig.create(entry)
+  except ModuleNotFoundError:
+print("NOT INSTALLED:", entry)
+continue
 if app_config.label in self.app_configs:
 raise ImproperlyConfigured(
 "Application labels aren't unique, "

And with that patched as well, openstack-dashboard.postinst
at least no longer fails.
But I have no idea if it is still working.
Nor what else it might break.
Not even what it is ;-)


What do you suggest then? Should I attempt to fix the plugins in both
Buster and Bullseye they?


That needs to be fixed (or at least worked around) 

Bug#988112: unblock: gfsview/20121130+dfsg-7

[Anton Gladky]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

please unblock package gfsview

Upload gfsview/20121130+dfsg-7 fixes RC-bug #987935.
I have enabled ci-pipelines to ensure the package functionality,
and now all tests are green [1]. Diff is attached.

[1] https://salsa.debian.org/science-team/gfsview/-/pipelines

unblock gfsview/20121130+dfsg-7


Best regards

Anton

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmCTAXcRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wZocA/+O/2XDkjko0feJZzyA3WKmh3qymptclOi
jQU3RacssdCCvxlmQ0fusea6LJ0uC/779rZ8ps3dZ87+7zE5ZBeS6V/oo8rExgmO
uPE9Mjnt5sttzKCECpFD19O4DvGZF03JTFRvU2QpGJT4NPAgldmmwk8C2DJU+AM8
GWz9UTq2qIZ36znMNbgoKixqcPYklxgbD4ruAkaT9AGlv9+eEnzJL5RIuxb6YSBU
mn6np/tg/iXog7ZWgHgtYGkvzXpxctdDOYlxZ++UzcIL4Ro2vpdRnOXw1gn8ZJbP
0b5vK0I4HGrZuhlHOIdayGKjfTjNXlDM86UMjtlXTFzbMBBJTAdieBBlFEvfCfF3
EOBRLh1YMwk8n39oonxQuxs0svI2BywXO9u/eIlXU2PyMkfNKaVB3vCojV18ei/D
Ny7e+w6Jn7mkS5sQyELMy5cISA3G85Wg/lIL1HPr1WUioTvXYGv3XNfJivSoCT+v
vMwY2WC+wtYLE669gxeNIIw+K1H1z/8UYfOg9Pr3OvI+LxKcyUtGeTxx5ZPE0WUy
EgWNCezdFhqQWsD7rLw030n7Fbp4UlifTEtSCbX9Q0bZ4fcCq7tvPKMs4fFswugz
HEB6Y5y4lJy+MI72xO/ATzKCZgECqtQ3mGg7t9SisYrUZyC4id83XIKUZpjYUqAe
8vF0qAoKW14=
=Kv+6
-END PGP SIGNATURE-
diff --git a/debian/.gitlab-ci.yml b/debian/.gitlab-ci.yml
new file mode 100644
index 000..26871b9
--- /dev/null
+++ b/debian/.gitlab-ci.yml
@@ -0,0 +1,2 @@
+include:
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
diff --git a/debian/changelog b/debian/changelog
index 74725fa..1f11cf2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gfsview (20121130+dfsg-7) unstable; urgency=medium
+
+  * Team upload.
+  * [9fb3053] Add .gitlab-ci.yml
+  * [634d5c0] Link against X11. (Closes: #987935)
+
+ -- Anton Gladky   Wed, 05 May 2021 22:03:32 +0200
+
 gfsview (20121130+dfsg-6) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/02_use_system_gl2ps.patch 
b/debian/patches/02_use_system_gl2ps.patch
index 02c99c4..3f384f1 100644
--- a/debian/patches/02_use_system_gl2ps.patch
+++ b/debian/patches/02_use_system_gl2ps.patch
@@ -2,10 +2,10 @@ Description: use packaged gl2ps instead of embedded.
 Author: Anton Gladky 
 Last-Update: 2014-05-08
 
-Index: gfsview-snapshot-121130/Makefile.am
+Index: gfsview-20121130+dfsg/Makefile.am
 ===
 gfsview-snapshot-121130.orig/Makefile.am
-+++ gfsview-snapshot-121130/Makefile.am
+--- gfsview-20121130+dfsg.orig/Makefile.am
 gfsview-20121130+dfsg/Makefile.am
 @@ -26,12 +26,10 @@ if HAVE_GTK
INTERACTIVE = view
  endif
@@ -20,10 +20,10 @@ Index: gfsview-snapshot-121130/Makefile.am
m4
  
  if DARCS_CONTROLLED
-Index: gfsview-snapshot-121130/batch/Makefile.am
+Index: gfsview-20121130+dfsg/batch/Makefile.am
 ===
 gfsview-snapshot-121130.orig/batch/Makefile.am
-+++ gfsview-snapshot-121130/batch/Makefile.am
+--- gfsview-20121130+dfsg.orig/batch/Makefile.am
 gfsview-20121130+dfsg/batch/Makefile.am
 @@ -10,17 +10,15 @@ noinst_LTLIBRARIES = librender2D.la libr
  
  librender2D_la_SOURCES = render.c render.h
@@ -44,10 +44,10 @@ Index: gfsview-snapshot-121130/batch/Makefile.am
  
  bin_PROGRAMS = gfsview-batch2D gfsview-batch3D
  
-Index: gfsview-snapshot-121130/gl/gfsgl.h
+Index: gfsview-20121130+dfsg/gl/gfsgl.h
 ===
 gfsview-snapshot-121130.orig/gl/gfsgl.h
-+++ gfsview-snapshot-121130/gl/gfsgl.h
+--- gfsview-20121130+dfsg.orig/gl/gfsgl.h
 gfsview-20121130+dfsg/gl/gfsgl.h
 @@ -23,7 +23,7 @@
  
  #include 
@@ -57,10 +57,10 @@ Index: gfsview-snapshot-121130/gl/gfsgl.h
  
  #ifdef __cplusplus
  extern "C" {
-Index: gfsview-snapshot-121130/view/Makefile.am
+Index: gfsview-20121130+dfsg/view/Makefile.am
 ===
 gfsview-snapshot-121130.orig/view/Makefile.am
-+++ gfsview-snapshot-121130/view/Makefile.am
+--- gfsview-20121130+dfsg.orig/view/Makefile.am
 gfsview-20121130+dfsg/view/Makefile.am
 @@ -26,23 +26,20 @@ SRC = \
glade/mangled_interface.c glade/interface.h \
glade/callbacks.c glade/callbacks.h \
@@ -72,7 +72,7 @@ Index: gfsview-snapshot-121130/view/Makefile.am
  gfsview2D_SOURCES = $(SRC) gfkgl2D.h
  gfsview2D_CFLAGS = @SN_CFLAGS@ @GTK_CFLAGS@ @GERRIS2D_CFLAGS@
 -gfsview2D_LDADD = -L$(top_builddir)/gl2ps -lgl2ps \
-+gfsview2D_LDADD = -lgl2ps \
++gfsview2D_LDADD = -lgl2ps -lX11 \
-L$(top_builddir)/gl -lgfsgl2D \
  @SN_LIBS@ @GTK_LIBS@ @GERRIS2D_LIBS@
 -gfsview2D_DEPENDENCIES = $(top_builddir)/gl2ps/libgl2ps.la 
$(top_builddir)/gl/libgfsgl2D.la
@@ -80,17 +80,17 @@ Index: gfsview-snapshot-121130/view/Makefile.am
  gfsview3D_SOURCES = $(SRC) 

Bug#988111: RFP: celestia -- Celestia is a free 3D astronomy program

[Nathan A. Stine]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: nathan.st...@gmail.com

* Package name: celestia
  Version : 1.6.2
  Upstream Author : Celestia Development Team
* URL : https://github.com/CelestiaProject/Celestia/
* License : GPL v2 (some assets may be non-free).
  Programming Lang: C++
  Description : Celestia is a free 3D astronomy program.

This was a package that was in Debian previously (jessie), but was removed in
#809916 due to dead upstream. It seems that upstream is now alive and well at
the github link above.

Some of the data files may be non-free. The project at
https://github.com/CelestiaProject/CelestiaContent states GPL 2.0, but shows
some other licenses that may not be DFSG-compliant. The jessie package did
split some of these resources into a nonfree package, so if nothing has changed
in terms of licensing there may need to be a similar package if warranted.

Bug#987985: Bug in Redis-server Package

[Benjamin Kuhl]

At an earlier point im setting the kay-value like this,

    const ok = await RedisServer.setValue(ip, '1', 'EX', 15);

Where the variable ip is something like

"2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15"

This seems to work, but i only get the error when im changing the 
key-value as i wrote. When im trying to access the entry and change the 
number '1' to '2' and set 'KEEPTTL'.



Am 05.05.21 um 17:16 schrieb Chris Lamb:

Hi Benjamin,


I cant remember exactly, but the last days there was an update for
redis-server and before this update it worked perfect. Cant say directly
which version it was, but it was the version before the actually one.

No problem. I'm trying to reproduce this locally -- looking at the
traceback in your original bug report, are you doing the equivalent
of:

   $ redis-cli set "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15" "2" 
KEEPTTL

?

You mention "I set a key value with a lifetime of 15 seconds" but I
don't see that in the traceback.


Regards,

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

Bug#986472: gretl: broken symlink: /usr/share/gretl/examples -> ../doc/gretl-doc/examples

[Dirk Eddelbuettel]

Andreas,

On 9 April 2021 at 23:40, Andreas Beckmann wrote:
| On 09/04/2021 23.23, Dirk Eddelbuettel wrote:
| 
| > | The --doc-main-package option can be used when the
| > | auto-detection is insufficient or to reset the path to its previous
| > | value if there is a reason to diverge from Debian policy recommendation.
| 
| > Spot on.  What is most expedient way to correct this? dh_movefiles?
| 
| --doc-main-package gretl-doc

I just fiddled with this for about two hours and four or more build attempts
on the new gretl upstream, and I am not getting it sorted out.  Error now

dh_installdocs: error: --doc-main-package should be used with -p

and I used various combinations of

dh_installdocs -a --doc-main-package $(docpack)   
dh_installdocs --doc-main-package $(docpack)   
dh_installdocs -a --doc-main-package -p $(docpack)   
dh_installdocs --doc-main-package -p$(docpack)   

where $(docpack) == gretl-doc  to no avail.

Is there a working debian/rules I could look at?

Dirk

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

Bug#985681: linux-cpupower: Fix Pkg Power tracking on Zen

[Salvatore Bonaccorso]

Hi

This has now been fixed upstream with 
https://git.kernel.org/linus/301b1d3a9104f4f3a8ab4171cf88d0f55d632b41

I'm going probably to cherry-pick the commit, but in case you can/want
to double check (again I know, but there was some followup) the issue
for you that would be great.

Regards,
Salvatore

Bug#987332: aprx automatically starts up with really bad default config

[Dave Hibberd]

Hi all,

I'm filing a report upstream currently, but there's a lack of activity so let's 
not hold our collective breath.

I'll take a wee dig into the program and see if I can find a point where it 
parses the config file to exit on N0CALL-1.

Couple of questions:
  * Debian Janitor has given us some updates and there's a 2.9.0+dfsg-3 sat 
UNRELEASED. Will we see any issues from this being added to the distro at this 
stage if combined with a fix?
  * Is exiting gracefully if N0CALL-1 is found going to cause a failed upgrade?

-- 
  Hibby
  MM0RFN

On Sun, 25 Apr 2021, at 7:42 PM, Apostolos Kefalas wrote:
> On Sun, 2021-04-25 at 17:54 +0300, Heikki Hannikainen wrote:
> > 
> > 
> > > I think it should be possible to detect the "N0CALL" configurations on
> > > upgrade and disable the service, thus reaching the same state as with my
> > > above change for new installs.
> > 
> > Right, something like a grep for the bad "^mycall\s+N0CALL-1" would be a 
> > suitable trigger.
> > 
> >- Hessu
> > 
> IMHO this check should be done by aprx and if mycall is not configured should
> exit properly.
> 
> I would open an issue at https://github.com/PhirePhly/aprx/issues
> 
> 

Bug#985220: velocity: CVE-2020-13936

[Salvatore Bonaccorso]

Hi Andreas,

Thanks for raising the problem.

On Wed, May 05, 2021 at 10:04:46PM +0200, Andreas Beckmann wrote:
> Followup-For: Bug #985220
> 
> Hi,
> 
> CVE-2020-13936 is fixed in stretch-security but not buster, making
> upgrades difficult since stetch-security has a newer version than buster.
> Please upload the fix to buster, too.
> 
>  velocity | 1.7-4| jessie   | source, all
>  velocity | 1.7-5| stretch  | source, all
>  velocity | 1.7-5| buster   | source, all
>  velocity | 1.7-5+deb9u1 | stretch-security | source, all
>  velocity | 1.7-6| bullseye | source, all
>  velocity | 1.7-6| sid  | source, all

This issue itself won't warrant a DSA for buster, but ideally a fix
goes in via the next buster point release or a later one if possible.

Regards,
Salvatore

Bug#964274: ruby-websocket-extensions: CVE-2020-7663

[Salvatore Bonaccorso]

Hi Andreas,

On Wed, May 05, 2021 at 09:57:09PM +0200, Andreas Beckmann wrote:
> Followup-For: Bug #964274
> 
> Hi,
> 
> CVE-2020-7663 is fixed in stretch-security but not buster, making
> upgrades difficult since stetch-security has a newer version than buster.
> Please upload the fix to buster, too.
> 
>  ruby-websocket-extensions | 0.1.2-1| stretch  | source, all
>  ruby-websocket-extensions | 0.1.2-1| buster   | source, all
>  ruby-websocket-extensions | 0.1.2-1+deb9u1 | stretch-security | source, all
>  ruby-websocket-extensions | 0.1.5-1| bullseye | source, all
>  ruby-websocket-extensions | 0.1.5-1| sid  | source, all

Thanks for raising the issue. In fact this issue won't warrant a DSA
for buster, so a fix goes ideally in via one of the upcoming point
releases.

Regards,
Salvatore

Bug#988110: spice-html5: version 0.3, with revised UI and minor bug fixes

[Eric Desrochers]

Package: spice-html5
Version: spice-html5 0.3.0 is out
Severity: normal
X-Debbugs-Cc: eric.desroch...@canonical.com

Dear Maintainer,

Version 0.3, released 6 months ago, has revised UI and minor bug fixes.

Some of them are:
* A new visual layout
* More visible supprot for ctrl-alt-delete
* Tuning of behaviour of streaming videos
* A fix for an unresponsive GDM.

Release note:
https://gitlab.freedesktop.org/spice/spice-html5/-/releases

Bug#988103: [Pkg-javascript-devel] Bug#988103: node-require-from-string FBFS in buster: test failures

[Yadd]

Le 05/05/2021 à 20:00, Adrian Bunk a écrit :
> Source: node-require-from-string
> Version: 2.0.1-1
> Severity: serious
> Tags: ftbfs
> Control: close -1 2.0.2-1
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/node-require-from-string.html
> 
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/build/node-require-from-string-2.0.1'
> mocha -R spec
> 
> 
>   ✓ should accept only string as code
>   ✓ should require from string
>   1) should accept filename
>   ✓ should work with relative require in file
>   ✓ should have appended and preppended paths
>   2) should have meaningful error message
>   ✓ should cleanup parent.children
> 
>   5 passing (23ms)
>   2 failing
> 
>   1) should accept filename:
>  bug.js:1

Even using `npm install`, these subtests fail. In 2.0.2, these tests are
ignored by patch.

Bug#988109: mqtt-client: CVE-2019-0222

[Salvatore Bonaccorso]

Hi

Thanks for raising this problem.

On Wed, May 05, 2021 at 10:12:34PM +0200, Andreas Beckmann wrote:
> Source: mqtt-client
> Version: 1.14-1
> Severity: serious
> Tags: security
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: fixed -1 1.14-1+deb9u1
> 
> Hi,
> 
> CVE-2019-0222 is fixed in stretch-security but not buster, making
> upgrades difficult since stretch-security has a newer version than
> buster.
> Please upload the fix to buster, too.
> 
>  mqtt-client | 1.14-1| stretch  | source
>  mqtt-client | 1.14-1| buster   | source
>  mqtt-client | 1.14-1+deb9u1 | stretch-security | source
>  mqtt-client | 1.16-1| bullseye | source
>  mqtt-client | 1.16-1| sid  | source

FWIW, the issue will not warrant a DSA, so a fix for it for buster
should go via an upcoming point release.

Regards,
Salvatore

Bug#987904: openstack-dashboard: fails to upgrade from buster if python3-cloudkitty-dashboard was installed and removed before the upgrade

[Thomas Goirand]

On 5/1/21 9:58 PM, Andreas Beckmann wrote:
> Package: openstack-dashboard
> Version: 3:18.6.2-3
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + python3-cloudkitty-dashboard python3-ironic-ui 
> python3-magnum-ui python3-neutron-fwaas-dashboard 
> python3-neutron-vpnaas-dashboard python3-octavia-dashboard 
> python3-sahara-dashboard python3-zaqar-ui
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'buster'.
> Actually I installed python3-cloudkitty-dashboard in buster, then removed
> (but not purged) only python3-cloudkitty-dashboard again (keeping all
> dependencies installed). Then the upgrade to 'bullseye' fails.
> 
> This also happens when doing the same with various -dashboard and -ui 
> packages.

Hi Andreas,

Thanks a lot for opening this bug, this brings light into a major defect
of the Horizon plugin packaging.

What happens is that the various python3-FOO- packages are
installing files in /etc/openstack-dashboard/enable. As they are in
/etc, they are CONFFILEs, and they aren't removed when the package is
removed, only when the package is actually purged.

When Horizon ugprades, it starts its "collecstatic" dance, meaning that
it loads its settings, and therefore, tries to load whatever is
described in /etc/openstack-dashboard/enable. And it fails because the
actual code, called from the "enable" folder, is gone (since the plugin
was removed).

If it was to be done again, I probably wouldn't have put the
/etc/openstack-dashboard/enable folder under /etc, but maybe under
/var/lib/openstack-dashboard or something. (Note that I wasn't the one
that designed things this way, it's a co-maintainer, but that's probably
irrelevant...)

So this actually is a bug in the plugins, that should have, to begin
with, removed the files they own in /etc/openstack-dashboard/enable
during the removal. I don't think this bug can be counted in Horizon itself.

Now, I'm unsure what to do. These plugins should be fixed in Bullseye,
though the issue you reported is with packages from Buster. So the
various plugin packages must be fixed in Buster for this bug to be closed.

What do you suggest then? Should I attempt to fix the plugins in both
Buster and Bullseye they?

Cheers,

Thomas Goirand (zigo)

Bug#972828: Not dead

[Julien Puydt]

Hi,

the project is not dead, I still want to package it, but it still
relies on an unreleased 'flint' library, so it's not suitable for
experimental yet.

JP

Bug#988109: mqtt-client: CVE-2019-0222

[Andreas Beckmann]

Source: mqtt-client
Version: 1.14-1
Severity: serious
Tags: security
User: debian...@lists.debian.org
Usertags: piuparts
Control: fixed -1 1.14-1+deb9u1

Hi,

CVE-2019-0222 is fixed in stretch-security but not buster, making
upgrades difficult since stretch-security has a newer version than
buster.
Please upload the fix to buster, too.

 mqtt-client | 1.14-1| stretch  | source
 mqtt-client | 1.14-1| buster   | source
 mqtt-client | 1.14-1+deb9u1 | stretch-security | source
 mqtt-client | 1.16-1| bullseye | source
 mqtt-client | 1.16-1| sid  | source


Andreas

Bug#985220: velocity: CVE-2020-13936

[Andreas Beckmann]

Followup-For: Bug #985220

Hi,

CVE-2020-13936 is fixed in stretch-security but not buster, making
upgrades difficult since stetch-security has a newer version than buster.
Please upload the fix to buster, too.

 velocity | 1.7-4| jessie   | source, all
 velocity | 1.7-5| stretch  | source, all
 velocity | 1.7-5| buster   | source, all
 velocity | 1.7-5+deb9u1 | stretch-security | source, all
 velocity | 1.7-6| bullseye | source, all
 velocity | 1.7-6| sid  | source, all

Andreas

Bug#988108: gitlab: Repeated issues resolving dependencies on upgrade

[Maximilian Stein]

Package: gitlab
Version: 13.9.6+ds1-1~fto10+1
Severity: important

Dear Maintainer,

unfortunately, I have repeatedly issues when upgrading gitlab to a new
version. My system is basically as recommended in the Debian Wiki with
Buster as basis plus Backports and Fasttrack. However, I am often
running in a situation that packages are actually *too new* and Gitlab
fails configuring because it expects a certain version of a package in
its Gemfile.

E.g., to upgrade to Gitlab version 13.9.6+ds1-1~fto10+1 today, I
iteratively *downgraded* ruby packages, re-run the Gitlab
installation, which then failed because another package was too new,
and so on. Finally, for 13.9.6+ds1-1~fto10+1, I needed to downgrade
these packages:

* ruby-autoprefixer-rails=10.2.4.0+dfsg1+~cs14.2.17-1
* ruby-devise-two-factor=3.1.0-2~bpo10+1
* ruby-fog-google=1.12.1-1~fto10+1
* ruby-discordrb-webhooks=3.3.0-1
* ruby-ruby-magic-static=0.3.5-1
* ruby-gitlab-labkit=0.15.0-1~fto10+2
* ruby-batch-loader=1.4.1+dfsg.1-3
* ruby-gitlab-experiment=0.4.9-1~fto10+1
* ruby-lockbox=0.3.5-2~bpo10+1
* ruby-rotp=2.1.1+dfsg-1

Of course, I need to hold them all, since they'd be upgraded
automatically otherwise.

One solution I could think of would be to provide a dependency-package
with hard version requirements. So, in contrast to
gitlab-apt-pin-preferences, such a package would directly depend on
all Gitlab-dependencies in their correct version for a particular
version of Gitlab. That way, I'd only need to pin a single package and
get a reproducible working installation. What do you think about that?

Best,
Maximilian

Bug#964274: ruby-websocket-extensions: CVE-2020-7663

[Andreas Beckmann]

Followup-For: Bug #964274

Hi,

CVE-2020-7663 is fixed in stretch-security but not buster, making
upgrades difficult since stetch-security has a newer version than buster.
Please upload the fix to buster, too.

 ruby-websocket-extensions | 0.1.2-1| stretch  | source, all
 ruby-websocket-extensions | 0.1.2-1| buster   | source, all
 ruby-websocket-extensions | 0.1.2-1+deb9u1 | stretch-security | source, all
 ruby-websocket-extensions | 0.1.5-1| bullseye | source, all
 ruby-websocket-extensions | 0.1.5-1| sid  | source, all

Andreas

Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs

[Thorsten Glaser]

Package: lintian
Version: 2.104.0
Followup-For: Bug #942013
X-Debbugs-Cc: t...@mirbsd.de

This bug is still pertinent:

X: klibc source: non-consecutive-debian-revision 2.0.8-6 -> 2.0.8-6.1
N:
P: non-consecutive-debian-revision



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

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

Versions of packages lintian depends on:
ii  binutils2.35.2-2
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdigest-sha-perl  6.02-1+b3
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012001-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.22-3
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.1-4
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.35.2-2
pn  libtext-template-perl  

-- no debconf information

Bug#943425: [klibc] Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use

[Ben Hutchings]

On Wed, 2021-05-05 at 20:24 +0200, Ben Hutchings wrote:
> On Wed, 2021-05-05 at 17:32 +, Thorsten Glaser wrote:
> [...]
> > > > > @klibc list: as indicated earlier, I can provide a patch if needed
> > > > > (though it should be obvious).
> > 
> > hpa, maks, bwh: any of you taking these two or should I send patches
> > and possibly NMU klibc in Debian?
> 
> Please send patches.  If you have a test base that could catch bugs

test *case*

> like this (without writing lists of registers in the test itself), that
> would be really useful.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.


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

Bug#988106: mutt: CVE-2021-32055

[Salvatore Bonaccorso]

Source: mutt
Version: 2.0.5-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:neomutt 20201127+dfsg.1-1.1
Control: retitle -2 neomutt: CVE-2021-32055

Hi,

The following vulnerability was published for mutt (respectively
neomutt):

CVE-2021-32055[0]:
| Mutt 1.11.0 through 2.0.x before 2.0.7 (and NeoMutt 2019-10-25 through
| 2021-05-04) has a $imap_qresync issue in which imap/util.c has an out-
| of-bounds read in situations where an IMAP sequence set ends with a
| comma. NOTE: the $imap_qresync setting for QRESYNC is not enabled by
| default.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-32055
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32055
[1] 
https://github.com/neomutt/neomutt/commit/fa1db5785e5cfd9d3cd27b7571b9fe268d2ec2dc
[2] 
https://gitlab.com/muttmua/mutt/-/commit/7c4779ac24d2fb68a2a47b58c7904118f40965d5

Regards,
Salvatore

Bug#988105: apt-file: could --installed become an (interesting) option?

[Patrice Duroux]

Package: apt-file
Version: 3.2.2
Severity: wishlist

Dear Maintainer,

I don't if this could be possible, interesting and intentionally equivalent:

apt-file --installed search|find  = dpkg-query -S 

Thanks,
Patrice

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/12 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 apt-file depends on:
ii  apt  2.2.3
ii  libapt-pkg-perl  0.1.40
ii  liblist-moreutils-perl   0.430-2
ii  libregexp-assemble-perl  0.36-1.1
ii  perl 5.32.1-4

apt-file recommends no packages.

apt-file suggests no packages.

Bug#987947: unblock: gtk+3.0/3.24.24-4

[Simon McVittie]

Control: tags -1 - moreinfo
Control: retitle -1 unblock: gtk+3.0/3.24.24-4

On Tue, 04 May 2021 at 22:19:49 +0200, Sebastian Ramacher wrote:
> On 2021-05-02 14:13:56 +0100, Simon McVittie wrote:
> > I'd like to update gtk+3.0 in bullseye to pick up an assortment of fixes
> > from upstream.
> 
> The patches look reasonable to me, so please go ahead and remove the
> moreinfo tag once the new version is available in unstable.

Uploaded, and built on all release architectures.

Thanks,
smcv

Bug#988093: rsyslog: should use separate entries for each log file in /etc/logrotate.d/rsyslog

[Vincent Lefevre]

On 2021-05-05 19:38:27 +0200, Michael Biebl wrote:
> Am 05.05.2021 um 19:27 schrieb Vincent Lefevre:
> > On 2021-05-05 19:12:24 +0200, Michael Biebl wrote:
> > > Am 05.05.2021 um 18:39 schrieb Vincent Lefevre:
> > > > This issue needs to be fixed anyway. If logrotate doesn't provide such
> > > > a facility, the fix could be done in rsyslog via a locking mechanism
> > > > to avoid the race (the /usr/lib/rsyslog/rsyslog-rotate script would
> > > > hold the lock until it knows that the SIGHUP has been processed).
> > > 
> > > Signals are asynchronous, I don't see how such a script could be 
> > > implemented
> > > robustly.
> > 
> > rsyslogd gives information when it has received a SIGHUP, e.g.
> > 
> > May 05 18:34:05 zira rsyslogd[1700043]: [origin software="rsyslogd" 
> > swVersion="8.2102.0" x-pid="1700043" x-info="https://www.rsyslog.com;] 
> > rsyslogd was HUPed
> > 
> 
> I'm not sure what you are trying to suggest here. Can you elaborate? Or even
> better send a patch?

The idea is the following:

/usr/lib/rsyslog/rsyslog-rotate puts a lock, and once the lock is
acquired, it sends the SIGHUP. When it sees that the SIGHUP has
been processed[*], it releases the lock.

[*] Currently one can see in the logs that rsyslogd processed the
signal. This is done in tools/rsyslogd.c:

/* This function processes a HUP after one has been detected. Note that this
 * is *NOT* the sighup handler. The signal is recorded by the handler, that 
record
 * detected inside the mainloop and then this function is called to do the
 * real work. -- rgerhards, 2008-10-22
 * Note: there is a VERY slim chance of a data race when the hostname is reset.
 * We prefer to take this risk rather than sync all accesses, because to the 
best
 * of my analysis it can not really hurt (the actual property is 
reference-counted)
 * but the sync would require some extra CPU for *each* message processed.
 * rgerhards, 2012-04-11
 */
static void
doHUP(void)
{
char buf[512];

if(ourConf->globals.bLogStatusMsgs) {
snprintf(buf, sizeof(buf),
 "[origin software=\"rsyslogd\" " "swVersion=\"" VERSION
 "\" x-pid=\"%d\" x-info=\"https://www.rsyslog.com\;] 
rsyslogd was HUPed",
 (int) glblGetOurPid());
errno = 0;
logmsgInternal(NO_ERRCODE, LOG_SYSLOG|LOG_INFO, (uchar*)buf, 0);
}

queryLocalHostname(); /* re-read our name */
ruleset.IterateAllActions(ourConf, doHUPActions, NULL);
modDoHUP();
lookupDoHUP();
errmsgDoHUP();
}

As said, this is not done in the signal handler, but after, so that
a second SIGHUP sent later should not be lost.

However, getting information in the log is not practical. Since the
rsyslogd daemon and the /usr/lib/rsyslog/rsyslog-rotate script come
from the same package, something better could be done.

For instance, the lock could be a file "/run/rsyslogd-hup.lock",
created with length 0. When the daemon has processed a SIGHUP, it
could write to this lock file (if existing). Once the rsyslog-rotate
script notices that the length is not 0, it removes the lock and
quits.

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

Bug#987013: Release goal proposal: Remove Berkeley DB

[Niko Tyni]

On Fri, Apr 16, 2021 at 08:29:52PM +0200, Bastian Blank wrote:
> On Fri, Apr 16, 2021 at 05:04:03PM +0200, Marco d'Itri wrote:

> > And then all the packages currently depending on libdb5.3 will need to 
> > implement, or at least document, a transition strategy.
> 
> My first goal would be to drop it from base packages, so not every
> system out there needs to have it installed.

Hi, please note that there's a number of indirect users of libdb via
interpreter packages - at least Perl, presumably Python too.

Given perl gets installed on almost all systems, this seems to to be
on the path to the first goal.

For the perl core, the libdb5.3 bindings are exposed with the DB_File
module. I think this is the only place but have not cross-checked that.
(The libberkeleydb-perl package is an entirely separate matter AIUI.)

I see 110 source packages in Debian matching DB_File. The list will
need to be inspected manually to weed out false positives. The remaining
packages need to be changed before perl can drop its libdb5.3 dependency.
I suppose this will also need a long list of Breaks declarations on the
perl side.

Then there's user code too. I also think we'll need at least a dumper
utility so that users can migrate their data manually when they discover
their program no longer works after upgrading.
-- 
Niko Tyni   nt...@debian.org

Bug#988100: mmdebstrap: squashfs image lack security capabilities (e.g. for /bin/ping)

[Jonas Smedegaard]

Quoting Johannes Schauer Marin Rodrigues (2021-05-05 19:37:16)
> Quoting Jonas Smedegaard (2021-05-05 18:56:56)
> > > Though I'm afraid this is not a change that will make it unto bullseye
> > > unless you have special friends in the release team. ;)
> > As I understand it, packages still get accepted when a) they are non-core 
> > and
> > b) has a testsuite - after a 20-day migration delay.
> 
> According to https://release.debian.org/bullseye/freeze_policy.html you are
> right!
> 
> Feel free to NMU mmdebstrap and put your patch into the packaging git. Reason
> for my unavailability in in Message-ID
> 161288154975.4161408.13592461751760341766@localhost on
> debian-priv...@lists.debian.org.

Sorry, I don't follow d-private, but respect your choice of keeping that 
private.  Just sincerely hope that whatever keeps you away from Debian 
is something pleasant.


> The patch should probably look something like this:
> 
> @@ -5461,10 +5461,8 @@ sub main() {
>  '-c',
>  '--exclude=./dev'
>  );
> -# tar2sqfs and genext2fs do not support extended attributes
> -if ($format eq "squashfs") {
> -warning "tar2sqfs does not support extended attributes";
> -} elsif ($format eq "ext2") {
> +# genext2fs does not support extended attributes
> +if ($format eq "ext2") {
>  warning "genext2fs does not support extended attributes";
>  } else {
>  push @taropts, '--xattrs';

@Benjamin: Will you have the honour?  You seem more expert in using 
mmdebstrap and therefore more likely to catch flaws in this than me...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#988016: prboom-plus: Segmentation fault on Wayland

[Fabian Greffrath]

Control: tags -1 confirmed upstream
Control: forwarded -1 
https://www.doomworld.com/forum/topic/31039-prboom-plus-ver-2514/?page=123=comments#comment-2301968

Am Montag, dem 03.05.2021 um 20:51 +0200 schrieb Chris via Pkg-games-
devel:
> On sway WM with "xwayland" disabled, prboom-plus seems to work fine, I
> can configure options and play a game. However, once I quit, I get
> the error:

Yes, we are currently trying to nail this down on the Doomworld forum:

https://www.doomworld.com/forum/topic/31039-prboom-plus-ver-2514/?page=123=comments#comment-2301968

 - Fabian



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

Bug#988104: zram-tools: Service Zram fails to start due to writing acces

[Louis Sajous]

Package: zram-tools
Version: 0.3.3.1-1
Severity: important

Zram does not start when I launch my computer :

root@PC:~# systemctl status zramswap.service
[zramswap[4580]: /usr/sbin/zramswap: ligne 53 : echo: erreur d'écriture :
Périphérique ou ressource occupé]

It refers to lign 53 which is :
echo -n "${ALGO}" > /sys/block/zram0/comp_algorithm || elog "setting
compression algo to ${ALGO}"

When I try to write in this file, it fails :
root@PC:~# echo -n "lz4" > /sys/block/zram0/comp_algorithm
-bash: echo: erreur d'écriture : Périphérique ou ressource occupé

root@PC:~# ls -al /sys/block/zram0/comp_algorithm
-rw-r--r-- 1 root root 4096  5 mai   20:09 /sys/block/zram0/comp_algorithm
root@PC:~# ls -al /sys/devices/virtual/block/zram0/comp_algorithm
-rw-r--r-- 1 root root 4096  5 mai   20:09
/sys/devices/virtual/block/zram0/comp_algorithm
root@PC:~# echo $UID
0
root@PC:~# mount
[sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)]

I can't modify or delete this particular file, and Zram can't start without
modifying it.

Sorry for the french in the messages and for the quality of my report, it's
only my second.


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

Kernel: Linux 5.10.0-6-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 zram-tools depends on:
ii  bc  1.07.1-2+b2

Bug#943425: [klibc] Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use

[Ben Hutchings]

On Wed, 2021-05-05 at 17:32 +, Thorsten Glaser wrote:
[...]
> > > > @klibc list: as indicated earlier, I can provide a patch if needed
> > > > (though it should be obvious).
> 
> hpa, maks, bwh: any of you taking these two or should I send patches
> and possibly NMU klibc in Debian?

Please send patches.  If you have a test base that could catch bugs
like this (without writing lists of registers in the test itself), that
would be really useful.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.


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

Bug#988103: node-require-from-string FBFS in buster: test failures

[Adrian Bunk]

Source: node-require-from-string
Version: 2.0.1-1
Severity: serious
Tags: ftbfs
Control: close -1 2.0.2-1

https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/node-require-from-string.html

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/node-require-from-string-2.0.1'
mocha -R spec


  ✓ should accept only string as code
  ✓ should require from string
  1) should accept filename
  ✓ should work with relative require in file
  ✓ should have appended and preppended paths
  2) should have meaningful error message
  ✓ should cleanup parent.children

  5 passing (23ms)
  2 failing

  1) should accept filename:
 bug.js:1
module.exports = 
   ^

SyntaxError: Unexpected end of input
  at Module._compile (internal/modules/cjs/loader.js:723:23)
  at requireFromString (index.js:28:4)
  at test/index.js:22:3
  at getActual (assert.js:567:5)
  at Function.throws (assert.js:679:24)
  at Context. (test/index.js:21:9)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:354:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:560:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:366:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
  at Immediate._onImmediate (/usr/lib/nodejs/mocha/lib/runner.js:334:5)

  2) should have meaningful error message:

  AssertionError [ERR_ASSERTION]: should contain (:1:69) in stack
  + expected - actual

  -false
  +true
  
  at Context. (test/index.js:52:10)
  at callFn (/usr/lib/nodejs/mocha/lib/runnable.js:354:21)
  at Test.Runnable.run (/usr/lib/nodejs/mocha/lib/runnable.js:346:7)
  at Runner.runTest (/usr/lib/nodejs/mocha/lib/runner.js:442:10)
  at /usr/lib/nodejs/mocha/lib/runner.js:560:12
  at next (/usr/lib/nodejs/mocha/lib/runner.js:356:14)
  at /usr/lib/nodejs/mocha/lib/runner.js:366:7
  at next (/usr/lib/nodejs/mocha/lib/runner.js:290:14)
  at Immediate._onImmediate (/usr/lib/nodejs/mocha/lib/runner.js:334:5)



make[1]: *** [debian/rules:13: override_dh_auto_test] Error 2

Bug#943425: Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use

[Thorsten Glaser]

Hi Andreas,

>>> Jessica Clarke brought out docs saying f8‥f15 must be saved, the
>>> other FPU registers not:
>
>I can confirm this. It is f8-f15 for the z/Architecture (64 bit).

thanks!

>It is f1, f3, f5, f7 for the ESA
>architecture (32 bit) which is still supported by Glibc and GCC.

Is this what we know as s390 in Debian? (klibc saves f4 and f6 there
currently. If so, this also needs to change.)

>>> … GCC chooses to allocate an FPU register for a pointer value.
>
>GCC will put integer values into vector registers for
>auto-vectorization or for spilling. We also use call-clobbered FPRs as
>save slots for GPRs in leaf-functions if can get rid of allocating a
>stack frame that way.

Ah, interesting. Thanks!

>The vector registers are call-clobbered - exactly for the reason of
>setjmp / longjmp. Only f8-f15 need to be saved.

Right.

>You can find the latest version of our ABI here:
>https://github.com/IBM/s390x-abi/releases/download/v1.5/lzsabi_s390x.pdf
>
>However, it is still lacking the vector ABI extension. I wrote a
>document for that which we use internally and we are working on
>integrating it into the publicly available version.

OK, thanks for the information!

>>> @klibc list: as indicated earlier, I can provide a patch if needed
>>> (though it should be obvious).

hpa, maks, bwh: any of you taking these two or should I send patches
and possibly NMU klibc in Debian?

Thanks,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#988086: Exim delivery process crashes on each mail with NULL-pointer

[Andreas Metzler]

Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=2733

On 2021-05-05 halfdog  wrote:
[...]
> What a weird coincidence that the 4.94-19
> seemed to crash exactly around that part of code that seemed
> to related to CVE-2020-28007.

Hello,

thank you for the very helpful bug report that made the issue easy to
reproduce.

The breakage is caused by the relevant change in -18/-19 (Pull patches
to temporarily add an option to turn taint errors into warnings.)

I have forwarded it upstream.

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

Bug#988093: rsyslog: should use separate entries for each log file in /etc/logrotate.d/rsyslog

[Michael Biebl]

Am 05.05.2021 um 19:27 schrieb Vincent Lefevre:

On 2021-05-05 19:12:24 +0200, Michael Biebl wrote:

Am 05.05.2021 um 18:39 schrieb Vincent Lefevre:

This issue needs to be fixed anyway. If logrotate doesn't provide such
a facility, the fix could be done in rsyslog via a locking mechanism
to avoid the race (the /usr/lib/rsyslog/rsyslog-rotate script would
hold the lock until it knows that the SIGHUP has been processed).


Signals are asynchronous, I don't see how such a script could be implemented
robustly.


rsyslogd gives information when it has received a SIGHUP, e.g.

May 05 18:34:05 zira rsyslogd[1700043]: [origin software="rsyslogd" swVersion="8.2102.0" 
x-pid="1700043" x-info="https://www.rsyslog.com;] rsyslogd was HUPed



I'm not sure what you are trying to suggest here. Can you elaborate? Or 
even better send a patch?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#988100: mmdebstrap: squashfs image lack security capabilities (e.g. for /bin/ping)

[Johannes Schauer Marin Rodrigues]

Quoting Jonas Smedegaard (2021-05-05 18:56:56)
> > Though I'm afraid this is not a change that will make it unto bullseye
> > unless you have special friends in the release team. ;)
> As I understand it, packages still get accepted when a) they are non-core and
> b) has a testsuite - after a 20-day migration delay.

According to https://release.debian.org/bullseye/freeze_policy.html you are
right!

Feel free to NMU mmdebstrap and put your patch into the packaging git. Reason
for my unavailability in in Message-ID
161288154975.4161408.13592461751760341766@localhost on
debian-priv...@lists.debian.org.

The patch should probably look something like this:

@@ -5461,10 +5461,8 @@ sub main() {
 '-c',
 '--exclude=./dev'
 );
-# tar2sqfs and genext2fs do not support extended attributes
-if ($format eq "squashfs") {
-warning "tar2sqfs does not support extended attributes";
-} elsif ($format eq "ext2") {
+# genext2fs does not support extended attributes
+if ($format eq "ext2") {
 warning "genext2fs does not support extended attributes";
 } else {
 push @taropts, '--xattrs';


Thanks!

cheers, josch

signature.asc
Description: signature

Bug#988093: rsyslog: should use separate entries for each log file in /etc/logrotate.d/rsyslog

[Vincent Lefevre]

On 2021-05-05 19:12:24 +0200, Michael Biebl wrote:
> Am 05.05.2021 um 18:39 schrieb Vincent Lefevre:
> > This issue needs to be fixed anyway. If logrotate doesn't provide such
> > a facility, the fix could be done in rsyslog via a locking mechanism
> > to avoid the race (the /usr/lib/rsyslog/rsyslog-rotate script would
> > hold the lock until it knows that the SIGHUP has been processed).
> 
> Signals are asynchronous, I don't see how such a script could be implemented
> robustly.

rsyslogd gives information when it has received a SIGHUP, e.g.

May 05 18:34:05 zira rsyslogd[1700043]: [origin software="rsyslogd" 
swVersion="8.2102.0" x-pid="1700043" x-info="https://www.rsyslog.com;] rsyslogd 
was HUPed

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

Bug#986623: tuxmath: Segfaults on startup

[Holger Levsen]

control: tags -1 pending
thanks

https://salsa.debian.org/tux4kids-pkg-team/tuxmath/-/merge_requests/1 has
a fix which I intend to upload shortly.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#954321: duplicate bug cleanup

[Noah Meyerhans]

Control: unarchive 964596
Control: forcemerge 964596 954321 
Control: archive 964596

This was resolved with the release of the Debian 10.5 AMIs for AWS last
year.  The issue was tracked in #964596, so I'll merge this bug with
that one...

noah



signature.asc
Description: PGP signature

Bug#988093: rsyslog: should use separate entries for each log file in /etc/logrotate.d/rsyslog

[Michael Biebl]

Am 05.05.2021 um 18:39 schrieb Vincent Lefevre:

On 2021-05-05 15:46:17 +0200, Michael Biebl wrote:

Unfortunately this is not a good idea and we actually went the other way
just recently.
For some background see #720096

If there was a way to issue a single postrotate after all log files have
been processed, then we could split the rules up. But unfortunately ttbomk
logrotate doesn't provide such a facility.


This issue needs to be fixed anyway. If logrotate doesn't provide such
a facility, the fix could be done in rsyslog via a locking mechanism
to avoid the race (the /usr/lib/rsyslog/rsyslog-rotate script would
hold the lock until it knows that the SIGHUP has been processed).



Signals are asynchronous, I don't see how such a script could be 
implemented robustly.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#988102: python-libnacl: failing in tests on 32 bit systems

[Ritesh Raj Sarraf]

Package: python-libnacl
Version: 1.7.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source
User: de...@lists.apertis.org
Usertags: apertis-ftbfs
X-Debbugs-Cc: de...@lists.apertis.org


Dear Maintainer,

Your package fails to build, so far on 32 bit systems. It is failing in
one of the tests.

The build failure snippet is below

***

dh_auto_test: warning: Compatibility levels before 10 are deprecated (level 9 
in use)
I: pybuild base:232: cd 
/srv/build/python-libnacl-1.7.2/.pybuild/cpython3_3.9_libnacl/build; python3.9 
-m nose -v tests
test_gcm_aead (unit.test_aead.TestAEAD) ... ok
test_ietf_aead (unit.test_aead.TestAEAD) ... ok
test_auth_rejects_wrong_lengths (unit.test_auth_verify.TestAuthVerify) ... ok
test_auth_verify (unit.test_auth_verify.TestAuthVerify) ... ok
test_auth_verify_rejects_wrong_key_lengths 
(unit.test_auth_verify.TestAuthVerify) ... ok
test_onetimeauth_rejects_wrong_lengths (unit.test_auth_verify.TestAuthVerify) 
... ok
test_onetimeauth_verify (unit.test_auth_verify.TestAuthVerify) ... ok
test_onetimeauth_verify_rejects_wrong_key_lengths 
(unit.test_auth_verify.TestAuthVerify) ... ok
test_key_blake (unit.test_blake.TestBlake) ... ok
test_keyless_blake (unit.test_blake.TestBlake) ... ok
test_publickey (unit.test_dual.TestDual) ... ok
test_secretkey (unit.test_dual.TestDual) ... ok
test_sign (unit.test_dual.TestDual) ... ok
test_publickey (unit.test_public.TestPublic) ... ok
test_secretkey (unit.test_public.TestPublic) ... ok
test_secret_box (unit.test_raw_auth_sym.TestSecretBox) ... ok
test_secret_box_easy (unit.test_raw_auth_sym_easy.TestSecretBox) ... ok
test_key_generichash (unit.test_raw_generichash.TestGenericHash) ... ok
test_keyless_generichash (unit.test_raw_generichash.TestGenericHash) ... ok
test_hash (unit.test_raw_hash.TestHash) ... ok
test_box (unit.test_raw_public.TestPublic) ... ok
test_box_seal (unit.test_raw_public.TestPublic) ... ok
test_boxnm (unit.test_raw_public.TestPublic) ... ok
test_gen (unit.test_raw_public.TestPublic) ... ok
test_scalarmult_rejects_wrong_length (unit.test_raw_public.TestPublic) ... ok
test_crypto_kdf_derive_from_key (unit.test_raw_random.TestRandomBytes) ... 
Aborted (core dumped)
E: pybuild pybuild:353: test: plugin distutils failed with: exit code=134: cd 
/srv/build/python-libnacl-1.7.2/.pybuild/cpython3_3.9_libnacl/build; python3.9 
-m nose -v tests
dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit 
code 13
make: *** [debian/rules:7: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Command `dpkg-buildpackage --changes-option=-DDistribution=bullseye` failed.
gbp:error: '/home/rrs/bin/gbp-pbuilder' failed: it exited with 2

***

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

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

Versions of packages python-libnacl depends on:
ii  libsodium23  1.0.18-1
pn  python   

python-libnacl recommends no packages.

python-libnacl suggests no packages.

Bug#988100: mmdebstrap: squashfs image lack security capabilities (e.g. for /bin/ping)

[Jonas Smedegaard]

Quoting Johannes Schauer Marin Rodrigues (2021-05-05 18:37:35)
> Hi,
> 
> Quoting Benjamin Drung (2021-05-05 18:17:23)
> > /bin/ping (from iputils-ping) uses the security capabilities to allow users
> > to use the program:
> > 
> > ```
> > $ getcap /bin/ping
> > /bin/ping cap_net_raw=ep
> > ```
> > 
> > When generating a squashfs images with mmdebstrap, these security
> > capabilities are lost. Example for a minimal chroot on Debian unstable:
> > 
> > ```
> > $ apt install -y bdebstrap mmdebstrap squashfs-tools-ng
> > $ mkdir -p ~/.ssh
> > $ touch ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
> > $ bdebstrap -c /usr/share/doc/bdebstrap/examples/Debian-buster-live.yaml 
> > --packages iputils-ping -n example2
> > [...]
> > W: tar2sqfs does not support extended attributes
> > [...]
> > $ rdsquashfs -x /bin/ping example2/root.squashfs
> > $
> > ```
> > 
> > Adding `push @taropts, '--xattrs';` after the tar2sqfs warning line 5355
> > will produce a squashfs image that contains the security capabilities:
> > 
> > ```
> > $ rdsquashfs -x /bin/ping example2/root.squashfs
> > security.capability=0x01020020
> > ```
> > 
> > This test was done on Debian unstable and Debian bullseye with mmdebstrap
> > 0.7.5-2 and squashfs-tools-ng 1.0.4-1.
> 
> interesting! As you can see from the warning in line 5355, extended attributes
> used to not work with tar2sqfs and it's awesome if that's working now!
> 
> Though I'm afraid this is not a change that will make it unto bullseye unless
> you have special friends in the release team. ;)

Sure?

As I understand it, packages still get accepted when a) they are 
non-core and b) has a testsuite - after a 20-day migration delay.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#937234: pam-python: Python2 removal in sid/bullseye

[Petter Reinholdtsen]

[Dominik George]
> @Mike, @Petter: Did you realise that pam-python is AGPL?

According to https://bugs.debian.org/578650 > it was Eclipse
Public License v1.0 when it was initially registered.  I was not aware
of any relicencing, but see the d/copyright file now say AGPL.  No idea
when the change happened.

I am not aware that AGPL have such effect on desktop systems either, but
that is unrelated to your question.

> If the latter fails, we should either rewrite such a module under a
> less restrictie licence, or rewrite libpam-mklocaluser in C or Rust,
> or get rid of the need for libpam-mklocaluser (probably by using
> sssd).

I believe there is also a small pam module in debian-edu-config to ask
people to change passwords using the web interface.

-- 
Happy hacking
Petter Reinholdtsen

Bug#988093: rsyslog: should use separate entries for each log file in /etc/logrotate.d/rsyslog

[Vincent Lefevre]

On 2021-05-05 15:46:17 +0200, Michael Biebl wrote:
> Unfortunately this is not a good idea and we actually went the other way
> just recently.
> For some background see #720096
> 
> If there was a way to issue a single postrotate after all log files have
> been processed, then we could split the rules up. But unfortunately ttbomk
> logrotate doesn't provide such a facility.

This issue needs to be fixed anyway. If logrotate doesn't provide such
a facility, the fix could be done in rsyslog via a locking mechanism
to avoid the race (the /usr/lib/rsyslog/rsyslog-rotate script would
hold the lock until it knows that the SIGHUP has been processed).

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

Bug#988100: mmdebstrap: squashfs image lack security capabilities (e.g. for /bin/ping)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Benjamin Drung (2021-05-05 18:17:23)
> /bin/ping (from iputils-ping) uses the security capabilities to allow users
> to use the program:
> 
> ```
> $ getcap /bin/ping
> /bin/ping cap_net_raw=ep
> ```
> 
> When generating a squashfs images with mmdebstrap, these security
> capabilities are lost. Example for a minimal chroot on Debian unstable:
> 
> ```
> $ apt install -y bdebstrap mmdebstrap squashfs-tools-ng
> $ mkdir -p ~/.ssh
> $ touch ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
> $ bdebstrap -c /usr/share/doc/bdebstrap/examples/Debian-buster-live.yaml 
> --packages iputils-ping -n example2
> [...]
> W: tar2sqfs does not support extended attributes
> [...]
> $ rdsquashfs -x /bin/ping example2/root.squashfs
> $
> ```
> 
> Adding `push @taropts, '--xattrs';` after the tar2sqfs warning line 5355
> will produce a squashfs image that contains the security capabilities:
> 
> ```
> $ rdsquashfs -x /bin/ping example2/root.squashfs
> security.capability=0x01020020
> ```
> 
> This test was done on Debian unstable and Debian bullseye with mmdebstrap
> 0.7.5-2 and squashfs-tools-ng 1.0.4-1.

interesting! As you can see from the warning in line 5355, extended attributes
used to not work with tar2sqfs and it's awesome if that's working now!

Though I'm afraid this is not a change that will make it unto bullseye unless
you have special friends in the release team. ;)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#988094: Patch redux

[Kurt Fitzner]

It appears the patch didn't survive some of the editing I did in 
reportbug.   Here it is:


--- chkservice-master/src/chk-systemd.cpp	2020-01-16 01:13:08.0 
-0400
+++ chkservice-patched/src/chk-systemd.cpp	2020-01-16 10:21:25.0 
-0400

@@ -517,20 +517,27 @@
   }

   char *names[ids->size()];

   for (auto id : (*ids)) {
-names[i] = (char *) id.c_str();
+const char *name = id.c_str();
+char *copy = new char[strlen(name)+ 1];
+strcpy(copy, name);
+names[i] =copy;
 i++;
   }
   names[i] = NULL;

   try {
 applyUnitState("EnableUnitFiles", names, STATE_FLAGS_ENABLE);
   } catch (std::string ) {
+for (i; i < 0; --i)
+   delete names[i];
 throw err;
   }
+  for (i; i < 0; --i)
+ delete names[i];
 }

 void ChkBus::disableUnits(std::set *ids) {
   int i = 0;

@@ -539,21 +546,28 @@
   }

   char *names[ids->size()];

   for (auto id : (*ids)) {
-names[i] = (char *) id.c_str();
+const char *name = id.c_str();
+char *copy = new char[strlen(name)+ 1];
+strcpy(copy, name);
+names[i] =copy;
 i++;
   }

   names[i] = NULL;

   try {
 applyUnitState("DisableUnitFiles", names, STATE_FLAGS_DISABLE);
   } catch (std::string ) {
+for (i; i < 0; --i)
+   delete names[i];
 throw err;
   }
+  for (i; i < 0; --i)
+ delete names[i];
 }

 void ChkBus::enableUnit(const char *name) {
   try {
 std::set id;

Bug#988101: golang-testify: failing tests on armhf

[Ritesh Raj Sarraf]

Source: golang-testify
Version: 1.6.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
User: de...@lists.apertis.org
Usertags: apertis-ftbfs
X-Debbugs-Cc: de...@lists.apertis.org

Dear Maintainer,

While preparing the pacakge for a derivative distribution, I have come
to notice that the package's (some of the) tests, fail on the armhf
architecture.

The build failure snippet is below. I also noticed that the same has
been seen on the reproducible builds too.



=== RUN   TestBoolAssertionFunc
=== RUN   TestBoolAssertionFunc/true
=== RUN   TestBoolAssertionFunc/false
--- PASS: TestBoolAssertionFunc (0.00s)
--- PASS: TestBoolAssertionFunc/true (0.00s)
--- PASS: TestBoolAssertionFunc/false (0.00s)
=== RUN   TestErrorAssertionFunc
=== RUN   TestErrorAssertionFunc/noError
=== RUN   TestErrorAssertionFunc/error
--- PASS: TestErrorAssertionFunc (0.00s)
--- PASS: TestErrorAssertionFunc/noError (0.00s)
--- PASS: TestErrorAssertionFunc/error (0.00s)
PASS
ok  github.com/stretchr/testify/require 0.823s
=== RUN   TestPassedReturnsTrueWhenAllTestsPass
--- PASS: TestPassedReturnsTrueWhenAllTestsPass (0.00s)
=== RUN   TestPassedReturnsFalseWhenSomeTestFails
--- PASS: TestPassedReturnsFalseWhenSomeTestFails (0.00s)
=== RUN   TestSuiteRequireTwice
=== RUN   TestSuiteRequireTwice
=== RUN   TestSuiteRequireTwice/TestRequireOne
suite_test.go:42: 
Error Trace:suite_test.go:42
Error:  Not equal: 
expected: 1
actual  : 2
Test:   TestSuiteRequireTwice/TestRequireOne
=== RUN   TestSuiteRequireTwice/TestRequireTwo
suite_test.go:47: 
Error Trace:suite_test.go:47
Error:  Not equal: 
expected: 1
actual  : 2
Test:   TestSuiteRequireTwice/TestRequireTwo
--- FAIL: TestSuiteRequireTwice (0.03s)
--- FAIL: TestSuiteRequireTwice/TestRequireOne (0.01s)
--- FAIL: TestSuiteRequireTwice/TestRequireTwo (0.00s)
--- PASS: TestSuiteRequireTwice (0.03s)
=== RUN   TestSuiteRecoverPanic
=== RUN   TestPanicInSetupSuite
suite.go:63: test panicked: oops in setup suite
goroutine 21 [running]:
runtime/debug.Stack(0x842dbc, 0x2f5ab0, 0x390fc0)
/usr/lib/go-1.15/src/runtime/debug/stack.go:24 +0x78
github.com/stretchr/testify/suite.failOnPanic(0x904e00)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite.go:63
 +0x3c
panic(0x2f5ab0, 0x390fc0)
/usr/lib/go-1.15/src/runtime/panic.go:969 +0x158
github.com/stretchr/testify/suite.(*panickingSuite).SetupSuite(0x915260)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite_test.go:63
 +0x38
github.com/stretchr/testify/suite.Run(0x904e00, 0x3966d8, 0x915260)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite.go:118
 +0x45c
github.com/stretchr/testify/suite.TestSuiteRecoverPanic.func1(0x904e00)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite_test.go:108
 +0x40
testing.tRunner(0x904e00, 0x35343c)
/usr/lib/go-1.15/src/testing/testing.go:1123 +0xc8
created by testing.(*T).Run
/usr/lib/go-1.15/src/testing/testing.go:1168 +0x220
--- FAIL: TestPanicInSetupSuite (0.01s)
=== RUN   TestPanicInSetupTest
=== RUN   TestPanicInSetupTest/Test
suite.go:63: test panicked: oops in setup test
goroutine 23 [running]:
runtime/debug.Stack(0x89ed64, 0x2f5ab0, 0x390fc8)
/usr/lib/go-1.15/src/runtime/debug/stack.go:24 +0x78
github.com/stretchr/testify/suite.failOnPanic(0x904fc0)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite.go:63
 +0x3c
panic(0x2f5ab0, 0x390fc8)
/usr/lib/go-1.15/src/runtime/panic.go:969 +0x158
github.com/stretchr/testify/suite.(*panickingSuite).SetupTest(0xa19940)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite_test.go:69
 +0x38
github.com/stretchr/testify/suite.Run.func1(0x904fc0)

/srv/build/golang-testify-1.6.1/obj-arm-linux-gnueabihf/src/github.com/stretchr/testify/suite/suite.go:148
 +0x460
testing.tRunner(0x904fc0, 0xa33b30)
/usr/lib/go-1.15/src/testing/testing.go:1123 +0xc8
created by testing.(*T).Run
/usr/lib/go-1.15/src/testing/testing.go:1168 +0x220
--- FAIL: TestPanicInSetupTest (0.01s)
--- FAIL: TestPanicInSetupTest/Test (0.00s)
=== RUN   

Bug#988100: mmdebstrap: squashfs image lack security capabilities (e.g. for /bin/ping)

[Benjamin Drung]

Package: mmdebstrap
Version: 0.7.5-2
Severity: important

Hi,

/bin/ping (from iputils-ping) uses the security capabilities to allow
users to use the program:

```
$ getcap /bin/ping
/bin/ping cap_net_raw=ep
```

When generating a squashfs images with mmdebstrap, these security
capabilities are lost. Example for a minimal chroot on Debian unstable:

```
$ apt install -y bdebstrap mmdebstrap squashfs-tools-ng
$ mkdir -p ~/.ssh
$ touch ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
$ bdebstrap -c /usr/share/doc/bdebstrap/examples/Debian-buster-live.yaml 
--packages iputils-ping -n example2
[...]
W: tar2sqfs does not support extended attributes
[...]
$ rdsquashfs -x /bin/ping example2/root.squashfs
$
```

Adding `push @taropts, '--xattrs';` after the tar2sqfs warning line 5355
will produce a squashfs image that contains the security capabilities:

```
$ rdsquashfs -x /bin/ping example2/root.squashfs
security.capability=0x01020020
```

This test was done on Debian unstable and Debian bullseye with
mmdebstrap 0.7.5-2 and squashfs-tools-ng 1.0.4-1.

-- 
Benjamin Drung

Senior DevOps Engineer and Debian & Ubuntu Developer
Compute Platform Operations

1&1 IONOS SE | Greifswalder Str. 207 | 10405 Berlin | Deutschland
E-Mail: benjamin.dr...@ionos.com | Web: www.ionos.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498

Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke


Member of United Internet

Bug#988094: reportbug: chkservice fails to control certain services

[Kurt Fitzner]

Package: chkservice
Version: 0.3-1
Severity: important
Tags: patch upstream

The chkservice systemd TUI is intended to be able to start, stop, enable, and
disable services as a front-end for systemctl.  On certain services, it fails
to be able to enable or disable them, showing the errors:

Failed: Invalid argument
 or
Failed: Connection reset by peer

Notably, one service that chkservice fails to be able to enable or disable on
my Debian Testing (bullseye) system is lighttpd

This appears to be a known upstream bug as reported here:
https://github.com/linuxenko/chkservice/issues/12

There also appears to be a forked version with a correction here:
https://github.com/nufeng74/chkservice

I've tested the patch and is appears to work.  Recommend adopting this patch
into Debian.  It appears to be minor enough to justify a change for testing
to get into Debian 11.

The problem appears to be caused by c_str temporary pointers.  I'm not 100%
sure there aren't security implications to this.

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 chkservice depends on:
ii  libc62.31-11
ii  libgcc-s1 [libgcc1]  10.2.1-6
ii  libncurses6  6.2+20201114-2
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-5
ii  libtinfo66.2+20201114-2

chkservice recommends no packages.

chkservice suggests no packages.

-- no debconf information

Bug#988099: prometheus-node-exporter: diskstat collector doesn't seem to provide metrics

[Juergen Richtsfeld]

Package: prometheus-node-exporter
Version: 1.1.2+ds-1+b1
Severity: normal
X-Debbugs-Cc: juergen.richtsf...@gmx.at

Dear Maintainer,

I tried to get disk (filesystem) i/o metrics like
node_disk_read_time_seconds_total from the diskstats collector but it
doesn't seem to provide any (there is not a single metric having a name
starting with node_disk). I don't find errors in the log (there is none)
and in the journal. I already tried to get rid of the default
diskstats.ignored-devices but this didn't help.


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 prometheus-node-exporter depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.31-11

Versions of packages prometheus-node-exporter recommends:
ii  dbus 1.12.20-2
ii  prometheus-node-exporter-collectors  0+git20210115.7d89f19-1

prometheus-node-exporter suggests no packages.

-- Configuration Files:
/etc/default/prometheus-node-exporter changed:
ARGS="--collector.diskstats.ignored-devices=\"\" 
--collector.filesystem.ignored-mount-points=\"^/(dev|proc|run|sys|mnt|var/lib/docker/.+)($|/)\""


-- no debconf information

Bug#987045: skypeforlinux fails to start using supplied profile

[Reiner Herrmann]

Hi Phil,

On Wed, May 05, 2021 at 03:41:43PM +0200, phil.night...@gmail.com wrote:
> Disable /var/cache/home/nightowl/chromium (requested 
> /home/nightowl/.cache/chromium)
> Disable /var/cache/home/nightowl/keepassxc (requested 
> /home/nightowl/.cache/keepassxc)
> Disable /var/cache/home/nightowl/mozilla (requested 
> /home/nightowl/.cache/mozilla)
> Error: tmpfs outside $HOME is only available for root
> Error: proc 7050 cannot sync with peer: unexpected EOF
> Peer 7051 unexpectedly exited with status 1

the problem seems to be related to your specific setup.
Somehow your ~/.cache/ is inside /var/cache (by using symlinks?)?

The skypeforlinux profile includes the electron profile, which has the
line:  private-cache
This asks firejail to create a private cache (~/.cache) directory, which
is implemented by mounting a tmpfs directory over the original .cache
directory.
But as your .cache directory is not actually inside your home directory,
firejail refuses to do that, because non-root users are not allowed to
mount tmpfs directories outside their home.

To keep your cache setup you can try the following:
Create a file /etc/firejail/skypeforlinux.local and add the following
line into it:

ignore private-cache

This will ask firejail while reading the profiles to ignore the
"private-cache" setting. It should then no longer try to mount a
tmpfs over it.
(This will also cause your cache to be no longer private, i.e.
skypeforlinux could read other cached files.)

Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#987985: Bug in Redis-server Package

[Chris Lamb]

Hi Benjamin,

> I cant remember exactly, but the last days there was an update for
> redis-server and before this update it worked perfect. Cant say directly
> which version it was, but it was the version before the actually one.

No problem. I'm trying to reproduce this locally -- looking at the
traceback in your original bug report, are you doing the equivalent
of:

  $ redis-cli set "2a02:908:531:e6e0:42b0:76ff:fea4:d7cb, 162.158.93.15" "2" 
KEEPTTL

?

You mention "I set a key value with a lifetime of 15 seconds" but I
don't see that in the traceback.


Regards,

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

Bug#926792: [cppreference-doc] Please update to last upstream version

[Jonathan Rubenstein]

Control: block 926792 by 810942

On Sat, 25 Apr 2020 14:01:45 +0300 Povilas Kanapickas  
wrote> New version requires https://github.com/peterbe/premailer in order to

build documentation for QtCreator

Looks like there's an ITP for that, but it hasn't yet been adopted.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810942

I'd still love to see this package get updated (after bullseye is 
released of course, since we're still in the freeze), so that it can be 
mirrored by the many Debian mirrors around the world.


Thank you for the had work you and your contributors put into this project.


Best Regards,

Jonathan Rubenstein
jrub...@gmail.com

Bug#988092: ITP: libweupnp-java -- tiny UPnP Java client library

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 
X-Debbugs-Cc: debian-de...@lists.debian.org, jvalle...@mailbox.org, 
su...@medhas.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libweupnp-java
  Version : 0.1.4
  Upstream Author : Alessandro Bahgat Shehata 
* URL : http://bitletorg.github.io/weupnp/
* License : LGPL-2.1+
  Programming Lang: Java
  Description : tiny UPnP Java client library

Weupnp is a lightweight Java library, released under the LGPL licence,
designed to implement the UPnP (Universal Plug and Play) protocol to
handle port mappings on Gateway Devices.

It is a dependency of jitsi-videobridge (ITP - #757769). I intend to
maintain it in the Java packaging team.

This package was removed from Debian before, so I will start from the
previous packaging repository and check for any bugs that were
archived at time of removal.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmCSeQkWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICA09EADULHyUxXvMEeMqk7xO4xcxwXBZ
sEyM5quVl1i/pQqCvbqrKzJj2D86qoNF+GDj9zEdejN02FJFxQh9yw7NEelbPiQv
7nlQqKa+SD5056XNK5W7/fw87SlybHW/M9QPg3ICNUuYmCN8dgOGp0CtDw6lsqzr
dUCbGiM5zjcbV9K1IMFjIB5mw5eQ4HSy/vpAApmk2jZ5Mujyu3MGo+4B7+tmUx+V
x5PWG9P0g+v09Vapl+SPPVVrUGOKYCbITlkk0Tz7K7VeLNoDL0eGyn8X9Uoe6rVH
IHCSnhzm9T3Xm240Ba98m0MbgjaxXLj4ajyB9qZ58/pw4hlhslh4z07h7i+fSIfy
bHQYYBfM1x40MtOBRUbzQVxg/hv2xFX0EvGoWWyrvNb2sCf2oHIh5t+MKMTN7gkl
a/dQ/H8B1/K42gN95zGtPv2KfsKxWFRM/SnYzAWWtt02mnotCB1G91GSwVn14GxU
nKOPhfV6cGeR9MHd3nsUtL6reBOyB+eM1dSzN08OIRMZrIKShEkJbmpOVsqLpxz4
M9bjb92Ov5LE7YzbGhFOgB+HZ1jbuhwQPSJB7azDn7MSOuNBplTo8jviVW/QQOh9
L8iHWjXwEbWtkLb46odH1bgbd0s0QiHroBPpDn6Ogdjorsy36bLBb3DiPa/+BgQC
d4zo08HecrNsMaXdfA==
=xT3g
-END PGP SIGNATURE-

Bug#937234: pam-python: Python2 removal in sid/bullseye

[Dominik George]

Hi,

> I wonder what the state of this issue is.
> 
> I looked at the code and somehow it has a few hints on (at least
> partial?) Python 3 compatibility.
> 
> Russell, can you give me a short update on how far this got? Can we
> somehow get to the goal of making this fully work with Python 3? Maybe
> even for bullseye…

Never mind, I just realised that pam-python is licensed under AGPL
and is thus not suitable for Debian Edu IMHO.

@Mike, @Petter: Did you realise that pam-python is AGPL? It means that
we cannot provide terminal servers or netbooting in Debian Edu without
placing a prominent link to pam-python's sources on the desktop…

@Russell: Can you please relicence pam-python under a less insane
licence?

If the latter fails, we should either rewrite such a module under
a less restrictie licence, or rewrite libpam-mklocaluser in C or Rust,
or get rid of the need for libpam-mklocaluser (probably by using
sssd).

Looking forward to everyone's thoughts,
Nik

Bug#931553: wireshark-dev idl2wrs now supports Python3

[Balint Reczey]

Control: fixed -1 3.2.0-1

On Tue, May 4, 2021 at 10:48 PM Gerald Combs  wrote:
>
> This bug should be fixed in Wireshark 3.2 and later as described at 
> https://gitlab.com/wireshark/wireshark/-/issues/15865.

True, thanks!

-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#987980: Fwd: Re: Bug#987980: ITP: infamous-plugins -- Infamous Plugins is a collection of open-source LV2 plugins

[Henrique de Moraes Holschuh]

Forwarding list-only reply to the bug report... sorry about that!

- Original message -
From: Henrique de Moraes Holschuh 
To: debian-de...@lists.debian.org
Subject: Re: Bug#987980: ITP: infamous-plugins --  Infamous Plugins is a 
collection of open-source LV2 plugins
Date: Monday, May 03, 2021 15:45

Hello Fernando,

On Mon, May 3, 2021, at 03:32, Fernando Toledo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Fernando Toledo 
> 
> * Package name: infamous-plugins

Please consider a prefix for the source package and binary package name, maybe 
lv2- or lv2-audio- or something else more suitable...

After all, lv2 is not the only thing with infamous plugins out there ;-)

-- 
  Henrique de Moraes Holschuh 

Bug#988097: pipewire-bin: /etc/pipewire/pipewire.conf includes version, causing conflict on every update

[Julian Andres Klode]

Package: pipewire
Version: 0.3.26-1
Severity: normal
X-Debbugs-Cc: j...@debian.org

Changing any setting in pipewire.conf will cause a conffile prompt on
any upstream version upgrade as the file embeds the version.

The version should be removed.

-- System Information:
Debian Release: 11.0
  APT prefers impish
  APT policy: (500, 'impish'), (500, 'hirsute-updates'), (500, 
'hirsute-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0-16-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.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 pipewire depends on:
ii  init-system-helpers  1.60
ii  libpipewire-0.3-modules  0.3.26-1
ii  pipewire-bin 0.3.26-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#988086: Exim delivery process crashes on each mail with NULL-pointer

[halfdog]

Also 4.94.2-1 crashes, e.g. calling "exim4 -qff":

(gdb) bt
#0  0x55ebf469d87c in log_open_already_exim (name=0x7ffcc589d560 "")
at log.c:288
#1  0x55ebf469dadf in log_open_as_exim (name=name@entry=0x7ffcc589d560 "")
at log.c:416
#2  0x55ebf469de8d in open_log (fd=fd@entry=0x55ebf476aed0 , 
type=type@entry=0, tag=tag@entry=0x0) at log.c:552
#3  0x55ebf469e86b in open_logs () at log.c:1512
#4  0x55ebf46f61e8 in appendfile_transport_setup (tblock=0x55ebf675a688, 
addrlist=, dummy=, uid=, 
gid=, errmsg=0x55ebf6764908) at appendfile.c:238
#5  0x55ebf466cc6d in deliver_local (addr=addr@entry=0x55ebf6764838, 
shadowing=shadowing@entry=0) at deliver.c:2322
#6  0x55ebf4677bc9 in do_local_deliveries () at deliver.c:3015
#7  deliver_message (id=id@entry=0x55ebf675ad21 "1ldz84-0001x1-8V", 
forced=forced@entry=1, give_up=give_up@entry=0) at deliver.c:7209
#8  0x55ebf46a7f9f in queue_run (start_id=start_id@entry=0x0, 
stop_id=stop_id@entry=0x0, recurse=recurse@entry=0) at queue.c:662
#9  0x55ebf465aac9 in main (argc=2, cargv=) at exim.c:4715

Bug#988093: rsyslog: should use separate entries for each log file in /etc/logrotate.d/rsyslog

[Michael Biebl]

control: tags -1 + moreinfo

Am 05.05.2021 um 12:59 schrieb Vincent Lefevre:

Package: rsyslog
Version: 8.2102.0-2
Severity: wishlist

rsyslog should use separate entries for each log file in
/etc/logrotate.d/rsyslog.


Unfortunately this is not a good idea and we actually went the other way 
just recently.

For some background see #720096

If there was a way to issue a single postrotate after all log files have 
been processed, then we could split the rules up. But unfortunately 
ttbomk logrotate doesn't provide such a facility.

Bug#986515: siconos: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && make -j1 test "ARGS=-E 'COLLECTION|collection|python_test_lcp|dr_iso1|ContactTest'" ARGS\+=-j1 returned exit code 2

[Tobias Frost]

Source: siconos
Followup-For: Bug #986515

As per dicussion in this thread:
https://lists.debian.org/debian-mentors/2021/04/msg00105.html

TL;DR: Several people sucessfuly built siconos, so this was probably a glitch.

Please feel-free to raise severity again, if you are still able to reproduce it.


(Leaving up to the maintainer to close the bug or reduce its severity further;
for now, reducing it to important to avoid autoremoval kicking in)

Bug#988052: dpkg-cross: does not convert path to dynamic loader in linker scripts

[Helmut Grohne]

Control: severity -1 serious

On Tue, May 04, 2021 at 01:03:16PM +0200, Aurelien Jarno wrote:
> When dpkg-cross converts a native package into a cross package, it moves
> around libraries updating symlinks. It most notably moves the dynamic
> loader, but doesn't update the path in the content of linker scripts
> like /usr/lib/$(MULTIARCH)/libc.so.
> 
> For example on armhf the dynamic loader is move from:
>   /lib/arm-linux-gnueabihf/ld-2.31.so
> to 
>   /usr/arm-linux-gnueabihf/lib/ld-2.31.so
> 
> However this path is not updated in libc.so script, which is changed
> from:
>   GROUP ( /lib/arm-linux-gnueabihf/libc.so.6 
> /usr/lib/arm-linux-gnueabihf/libc_nonshared.a  AS_NEEDED ( 
> /lib/ld-linux-armhf.so.3 ) )
> to 
>   GROUP ( /usr/arm-linux-gnueabihf/lib/libc.so.6 
> /usr/arm-linux-gnueabihf/lib/libc_nonshared.a  AS_NEEDED ( 
> /lib/ld-linux-armhf.so.3 ) )
> 
> The path in AS_NEEDED should also be updated.

The main purpose of dpkg-cross is converting library packages and
basically the only library it really needs to work on to be useful is
glibc. It now fails at this task, which essentially makes dpkg-cross
unusable. As such, I'm upgrading the severity to serious. This really
needs to be fixed in bullseye.

I've looked into dpkg-cross and the fix_ldscripts sub in particular. I
have to admit that I'm quite puzzled about how it behaves differently on
multiarch vs non-multiarch packages as well as how it identifies them.
I'll explain my understanding and propose a solution below. Review and
tesing welcome.

dpkg-cross identifies packages as "multiarch" if they carry a Multi-Arch
stanza or put any file on a multiarchy path (such as
/usr/include/ or /usr/lib/). Once identified as
"multiarch" dpkg-cross and the ldscript fixer in particular work
differently. It seems as if dpkg-cross does not consider that packages
may be "partially multiarch" (i.e. using multiarch and non-multiarch
paths). In particular, glibc is partially multiarch and dpkg-cross fails
to handle this. Please tell if there is a mistake in this logic somehow.

The fix_ldscript sub does not fix up non-multiarch paths inside
ldscripts if a package is identified as being "multiarch". In the case
of libc6-dev, this results in the dynamic loader path not being fixed.
In particular, it only ever fixes non-multiarch multilib paths, but
never fixes plain non-multiarch paths (such as /lib without a triplet),
which is precisely the case relevant to glibc. It does however move the
library paths inside the package. I have no explanation for this
inconsistency.

As a minimally invasive solution (until we understand why multiarch is
handled differently here), I propose handling the dynamic loader
specially and fixing it up regardless of whether the package is
multiarch. I'm attaching a patch to this end. It only fixes /lib,
/lib32, /lib64 and /libx32 as no other multilib ever contained a dynamic
loader.

The difficult part here is finding a solution that does not break
anything. I've practically observed the issue for various gcc-10 and
gcc-11 based bootstrap sequences and they all fail finding the
unconverted loader while linking libc.so into libgcc during gcc stage3.
For gcc-10/arm64, I've locally verified that the patch fixes the issue.
I'm running various combinations on jenkins with it now to see how it
fixes other combinations.

My preference here is not reverthing the glibc/2.31-12 change that
introduced this regression and rather fix up dpkg-cross.

Replies to this mail that point out errors or indicate their absence are
welcome.

Helmut

Bug#987833: r-cran-openmx: FTBFS on mips due to a variable called 'mips'

[Joshua N Pritikin]

On Wed, May 05, 2021 at 09:38:03AM +0200, Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Joshua Pritikin 
> 
> Hi Joshua,
> 
> here is another instance of the mips variable.  It would be great
> if you could fix this in your next release.

Yeah, will do

Bug#988095: unblock: pev/0.81-3

[Petter Reinholdtsen]

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

https://tracker.debian.org/pkg/pev >

Please unblock package pev version 0.81-3 used by lintian.  It include a
patch from upstream to fix the RC issue
https://bugs.debian.org/987959 >.

While looking at the package I noticed a CI failure on s390x, most
likely because the gzip-win32 package there do not include gzip.exe, and
adjusted the autopkgtest to try to make sure this is the case.  This is
not RC as such, but I included it anyway as the CI results is a key part
of the migration process these days.

As the issue is RC, the package is used by lintian which is fairly
important in Debian, and 20 days from now might be after the release of
Bullseye, I decided to file a unblock request even thought it might not
be needed.

This is the complete patch between 0.81-2 and 0.81-3:

diff --git a/debian/changelog b/debian/changelog
index e11e3ed..94b091e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+pev (0.81-3) unstable; urgency=medium
+
+  * QA upload.
+  * Avoid off-by-one error in libpe pe_utils_str_widechar2ascii()
+(Closes: #987959)
+  * Extended autopkgtest to report if the Windows EXE file is missing.
+
+ -- Petter Reinholdtsen   Wed, 05 May 2021 14:09:18 +0200
+
 pev (0.81-2) unstable; urgency=medium
 
   * QA upload.
diff --git a/debian/patches/0001-widechar-off-by-one.patch 
b/debian/patches/0001-widechar-off-by-one.patch
new file mode 100644
index 000..d5eedab
--- /dev/null
+++ b/debian/patches/0001-widechar-off-by-one.patch
@@ -0,0 +1,24 @@
+From 5737a97c57be175333fc0c6f51bb2cdd7101c17e Mon Sep 17 00:00:00 2001
+From: Jardel Weyrich 
+Date: Mon, 18 Jan 2021 22:03:49 -0300
+Subject: [PATCH] utils: Fix off-by-one error in pe_utils_str_widechar2ascii.
+Bug-Debian: https://bugs.debian.org/987959
+Origin: 
https://github.com/merces/libpe/commit/5737a97c57be175333fc0c6f51bb2cdd7101c17e
+
+---
+ utils.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/utils.c b/utils.c
+index bd2da84..f05ba67 100644
+--- a/lib/libpe/utils.c
 b/lib/libpe/utils.c
+@@ -132,7 +132,7 @@ char *pe_utils_str_array_join(char *strings[], size_t 
count, char delimiter) {
+ 
+ void pe_utils_str_widechar2ascii(char *output, const char *widechar, size_t 
length) {
+   // quick & dirty UFT16 to ASCII conversion
+-  for (size_t p = 0; p <= length; p++) {
++  for (size_t p = 0; p < length; p++) {
+   memcpy(output + p, (uint16_t *)(widechar) + p, 1);
+   }
+ }
diff --git a/debian/patches/series b/debian/patches/series
index e69de29..35c0990 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-widechar-off-by-one.patch
diff --git a/debian/tests/test-runs b/debian/tests/test-runs
index d99db19..675d4ec 100755
--- a/debian/tests/test-runs
+++ b/debian/tests/test-runs
@@ -20,14 +20,23 @@ else
 VALGRIND=
 fi
 
-if $VALGRIND pesec /usr/share/win32/gzip.exe | grep ASLR; then
+TESTEXE="/usr/share/win32/gzip.exe"
+
+# Detect problem on s390x
+if [ ! -e "$TESTEXE" ] ; then
+echo "error: missing gzip.exe.  No such file in gzip-win32?"
+dpkg -L gzip-win32
+exit 1
+fi
+
+if $VALGRIND pesec "$TESTEXE" | grep ASLR; then
 echo "success: pesec reported ASLR status"
 else
 echo "error: pesec did not report ASLR status"
 retval=1
 fi
 
-if $VALGRIND pehash /usr/share/win32/gzip.exe | grep sha256:; then
+if $VALGRIND pehash "$TESTEXE" | grep sha256:; then
 echo "success: pehash reported ASLR status"
 else
 echo "error: pehash did not report ASLR status"

-- 
Happy hacking
Petter Reinholdtsen

Bug#987959: pev: peres affected by off-by-one error in libpe

[Petter Reinholdtsen]

I've asked upstream if this is a security issue, and if so, what its CVE
is, in https://github.com/merces/libpe/issues/34 >.

As far as I can tell, it is writing past the assigned buffer, which
might be a security issue.

-- 
Happy hacking
Petter Reinholdtsen

Bug#988086: Exim delivery process crashes on each mail with NULL-pointer

[halfdog]

Adam D. Barratt writes:
> On Wed, 2021-05-05 at 11:07 +, halfdog wrote:
>> This is weird: I have only bullseye/bullseye-updates/bullseye-
>> security
>> in my sources list. I applied all updates on 2nd of May with
>> no Exim package available. Then after the 21nails disclosure
>> I run the updates (timestamps in UTC):
>> 
>> 2021-05-02 07:05:31 status installed initramfs-tools:all 0.140
>> ...
>> 2021-05-04 16:49:48 upgrade exim4-daemon-light:amd64 4.94-17 4.94-19
>> 
>> But there is no transaction for 4.94-19 in PTS between these
>> two dates, next is
> > 
>> [2021-05-05] exim4 4.94-19 MIGRATED to testing (Debian testing
>> watch) 
>
> The "testing watch" script only runs daily, in the early morning UTC.
> The 4.94-19 package actually migrated on the morning of the 4th (again
> UTC):
>
> 20210504101451|control-suite|dak|added|testing|exim4 4.94-19 source
>
> The upload including the 21nails fixes is:
>
> 20210504134823|process-upload|dak|ACCEPT|exim4_4.94.2-1_multi.changes

Thanks, that explains the timeline.

I am now at

ii  exim4-daemon-light4.94.2-1   amd64
lightweight Exim MTA (v4) daemon

At least it does not segfault on locally generated messages as
the 4.94-19 package did. What a weird coincidence that the 4.94-19
seemed to crash exactly around that part of code that seemed
to related to CVE-2020-28007.

Regards,
hd

Bug#988086: Exim delivery process crashes on each mail with NULL-pointer

[Adam D. Barratt]

On Wed, 2021-05-05 at 11:07 +, halfdog wrote:
> This is weird: I have only bullseye/bullseye-updates/bullseye-
> security
> in my sources list. I applied all updates on 2nd of May with
> no Exim package available. Then after the 21nails disclosure
> I run the updates (timestamps in UTC):
> 
> 2021-05-02 07:05:31 status installed initramfs-tools:all 0.140
> ...
> 2021-05-04 16:49:48 upgrade exim4-daemon-light:amd64 4.94-17 4.94-19
> 
> But there is no transaction for 4.94-19 in PTS between these
> two dates, next is
> 
> [2021-05-05] exim4 4.94-19 MIGRATED to testing (Debian testing
> watch) 

The "testing watch" script only runs daily, in the early morning UTC.
The 4.94-19 package actually migrated on the morning of the 4th (again
UTC):

20210504101451|control-suite|dak|added|testing|exim4 4.94-19 source

The upload including the 21nails fixes is:

20210504134823|process-upload|dak|ACCEPT|exim4_4.94.2-1_multi.changes

Regards,

Adam

Bug#988059: shim-signed fails to install on non-EFI system

[Steve McIntyre]

On Wed, May 05, 2021 at 12:52:55PM +0200, Joergen Haegg wrote:
>
>
>> Out of curiosity - do you know how you had shim-signed installed in
>> the first place? I wouldn't expect it to be automatically installed
>> unless you're on an EFI system.
>
>No. I searched the logs for apt & dpkg, but I couldn't find
>any install date so it has been on the system for more than one year.
>I'm almost sure I didn't install it myself, unless it came
>as a dependency from some other package. :-)
>
>The installation on this machine has been going through several hardware
>replacements so it could have been more than 10 years ago.
>(Or whenever EFI was introduced.)
>
>
>dpkg.log: 2021-05-04 06:04:00 upgrade shim-signed:amd64 
>1.33+15+1533136590.3beb971-7 1.34+15.4-2
>
>history.log:
>Start-Date: 2021-05-04  06:03:56
>Commandline: /usr/bin/unattended-upgrade
>Upgrade: libphonon4qt5-data:amd64 (4:4.11.1-3, 4:4.11.1-4), 
>libphonon4qt5-4:amd64 (4:4.11.1-3, 4:4.11.1-4), shim-signed:amd64 
>(1.33+15+1533136590.3beb971-7, 1.34+15.4-2), phonon4qt5:amd64 (4:4.11.1-3, 
>4:4.11.1-4), shim-signed-common:amd64 (1.33+15+1533136590.3beb971-7, 
>1.34+15.4-2), shim-unsigned:amd64 (15.4-2, 15.4-3)
>Error: Sub-process /usr/bin/dpkg returned an error code (1)
>End-Date: 2021-05-04  06:04:02
>
>
>That's all I could find, sorry.

No worries, thanks for checking! And thanks for running unstable and
reporting this bug in the first place. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Rarely is anyone thanked for the work they did to prevent the
 disaster that didn’t happen.”
   -- Mikko Hypponen (https://twitter.com/mikko/)