Bug#992478: autopkgtest logs, pass and fail

[Paul Gevers]

Hi Kip,

On 03-02-2022 22:48, Kip Warner wrote:

On Thu, 2022-02-03 at 13:37 +0100, Paul Gevers wrote:

I ran across this issue again. Just a sanity check, you did take care
of this, right?

"""
rw-build-tree


Hey Paul,

Yes, indeed. The test's Restrictions stanza is as follows: rw-build-
tree, build-needed, allow-stderr, isolation-container.


Sorry, that was not what I meant. I spotted rw-build-tree and noticed in 
the description that *you* have to take care of things if you use this 
restriction. Did you do that?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004951: Not displaying attachments that contain a slash (/) in their name

[Carsten Schoenert]

Hello Erik,

Am 04.02.22 um 08:48 schrieb Erik Thiele:
...

As you see something is wrong when receiving attachments that contain a
slash (/) in their name.

When you investigate thunderbird with strace like this:

strace - thunderbird working.eml 2>strace_working.txt
then click on the attachment and quit thunderbird

then do

strace - thunderbird not_working.eml 2>strace_not_working.txt
then click on the attachment and quit thunderbird

then do:
grep pdf strace_working.txt |grep open
you will see:
[pid 17250] openat(AT_FDCWD, "/tmp/doc.pdf", O_WRONLY|O_CREAT...

compare this to:
grep pdf strace_not_working.txt |grep open
you will see no try of even saving the attachment.


The way I created the not-working email with a text editor may seem
the source of the problem, but it isn't. I regularly get emails with
slashes in attachment names. I simply did not find a way to create such
an email with commandline tools. All seem to dislike slashes in
attachment names. But since I am regularly receiving this kind of
emails in real life, there must be some (non-unix?) mail program
creating such (bad) attachments.


in no way a backslash character is a valid character for filenames no 
matter which OS you are. And normally any application wouldn't need to 
take care about such invalid strings of filenames. So I would not 
consider this a "real" issue within Thunderbird.


Even on Windows a backslash isn't a valid character for filenames. Some 
guy has collected some information about invalid characters on Windows 
systems within this GitHub gist.


https://gist.github.com/doctaphred/d01d05291546186941e1b7ddc02034d3

The next Thunderbird version did some more improvements on work around 
such attachments which have invalid filenames. Might be your problem 
with broken attachments filenames is then mostly gone away.


https://bugzilla.mozilla.org/show_bug.cgi?id=1747977

If not you should move over to the Mozilla Bugtracker and open a report 
there. Within the Debian packaging there is quite nothing we can do 
about that, nor should we because this needs to get fixed upstream first.



--
Regards
Carsten

Bug#989560: Bug #989560 solved by update?

[Elliott Mitchell]

Nothing further has been heard.  Was bug #989560 resolved by updating to
the GRUB 2.04 packages?  Possibly as part of upgrading to bullseye?

The provided information looks like what one might expect from trying to
load Xen on ARM via GRUB 2.02.  As such I'm left suspecting this was
resolved by updating.


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

Bug#1004993: virt-viewer: severe memory leak

[Nathan Dorfman]

Package: virt-viewer
Version: 7.0-2
Severity: normal
X-Debbugs-Cc: nd...@rtfm.net

Dear Maintainer,

Using the remote-viewer command to connect via SPICE to a VM running on the
local host:

remote-viewer spice://localhost:5901

VM and host are both running bullseye with the MATE desktop. There are two
1900x1200 monitors, and I'm using both of them in full-screen mode with
remote-viewer.

At first, memory usage, as reported by `ps -o rss`, is stable, staying under
800MB for the first 22 hours or so. After that, it begins to rise rapidly,
reaching 10GB another 13 hours or so later.

A gnuplot image of the RSS (in kilobytes) over time: 

https://rtfm.net/ndorf/remote-viewer-rss.png

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

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

Versions of packages virt-viewer depends on:
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-13+deb11u2
ii  libcairo-gobject2   1.16.0-5
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.66.8-1
ii  libgovirt2  0.3.7-2
ii  libgtk-3-0  3.24.24-4
ii  libgtk-vnc-2.0-01.0.0-1
ii  libgvnc-1.0-0   1.0.0-1
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  librest-0.7-0   0.8.1-1.1
ii  libsoup2.4-12.72.0-2
ii  libspice-client-glib-2.0-8  0.39-1
ii  libspice-client-gtk-3.0-5   0.39-1
ii  libvirt-glib-1.0-0  3.0.0-1
ii  libvirt07.0.0-3
ii  libxml2 2.9.10+dfsg-6.7

virt-viewer recommends no packages.

Versions of packages virt-viewer suggests:
ii  netcat-openbsd [netcat]  1.217-3
ii  netcat-traditional [netcat]  1.10-46

-- no debconf information

Bug#1004919: ITP: kmscon -- Simple terminal emulator based on Kernel Mode Setting

[nick black]

Victor Westerhuis left as an exercise for the reader:
> Package: wnpp
> Severity: wishlist
> Owner: Victor Westerhuis 
> X-Debbugs-Cc: debian-de...@lists.debian.org

i've also forked this, and have been working on it a bit over
the past year:

 https://github.com/dankamongmen/kmscon

if the other fork is more active, i'm happy to fold my changes
into it, but they definitely ought go in there. the most
important thing i recall doing was fixing the cursor location
report to use the proper order for coordinates.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Bug#1002165: isbnlib: diff for NMU version 3.9.3-1.2

[Adrian Bunk]

Control: tags 1002165 + patch
Control: tags 1002165 + pending

Dear maintainer,

I've prepared an NMU for isbnlib (versioned as 3.9.3-1.2) and uploaded 
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru isbnlib-3.9.3/debian/changelog isbnlib-3.9.3/debian/changelog
--- isbnlib-3.9.3/debian/changelog	2019-10-04 02:46:17.0 +0300
+++ isbnlib-3.9.3/debian/changelog	2022-02-05 07:29:00.0 +0200
@@ -1,3 +1,11 @@
+isbnlib (3.9.3-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for compatibility with Python 3.10.
+(Closes: #1002165)
+
+ -- Adrian Bunk   Sat, 05 Feb 2022 07:29:00 +0200
+
 isbnlib (3.9.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru isbnlib-3.9.3/debian/patches/0001-fix-61.patch isbnlib-3.9.3/debian/patches/0001-fix-61.patch
--- isbnlib-3.9.3/debian/patches/0001-fix-61.patch	1970-01-01 02:00:00.0 +0200
+++ isbnlib-3.9.3/debian/patches/0001-fix-61.patch	2022-02-05 07:26:11.0 +0200
@@ -0,0 +1,28 @@
+From 11d0092cb0fb3d177817e3a302918f54db97ba72 Mon Sep 17 00:00:00 2001
+From: Alexandre Conde 
+Date: Mon, 21 Oct 2019 09:18:55 +0100
+Subject: fix #61
+
+---
+ isbnlib/_imcache.py | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/isbnlib/_imcache.py b/isbnlib/_imcache.py
+index de126d0..deb599f 100644
+--- a/isbnlib/_imcache.py
 b/isbnlib/_imcache.py
+@@ -1,7 +1,10 @@
+ # -*- coding: utf-8 -*-
+ """Read and write to a dict-like cache."""
+ 
+-from collections import MutableMapping
++try:
++from collections.abc import MutableMapping
++except ImportError:  # PY27
++from collections import MutableMapping
+ 
+ 
+ class IMCache(MutableMapping):
+-- 
+2.20.1
+
diff -Nru isbnlib-3.9.3/debian/patches/series isbnlib-3.9.3/debian/patches/series
--- isbnlib-3.9.3/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ isbnlib-3.9.3/debian/patches/series	2022-02-05 07:29:00.0 +0200
@@ -0,0 +1 @@
+0001-fix-61.patch

Bug#1004992: ITS: speex

[Boyuan Yang]

Source: speex
Version: 1.2~rc1.2-1.1
Severity: important
X-Debbugs-CC: r...@debian.org

Dear package speex maintainer in Debian,

After looking into the package you maintain (speex, 
https://tracker.debian.org/pkg/speex), I found that this package
received no maintainer updates in the past 8 years and was not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package according to section 5.12 in Debian's Developers'
Reference [1].

My current plan is to package the latest upstream release (1.2.0),
clean up packaging and co-maintain this package in Debian Multimedia Team to
allow possible external contribution.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(Feb. 25, 2022) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#874257: Fixed now?

[Andrew Ruthven]

Hey,

I have tested rt-dump-metadata against a copy of our production
installation which has a large number of CustomFields running RT 4.4.4.
This appears to work correctly now.

Cheers,
Andrew
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud: | This space intentionally left blank
https://catalystcloud.nz |

Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress

[Noah Meyerhans]

Control: reassign -1 src:dpkg
Control: severity -1 wishlist

> root@debian:~# ls -l `which ping`
> -rwxr-xr-x 1 root root 77432 Aug 23 19:08 /usr/bin/ping
> root@debian:~# getcap `which ping`
> /usr/bin/ping cap_net_raw=ep
> root@debian:~#
> 
> 
> This looks like a limitation that would only be possible to solve by
> dpkg and extending tar / cpio probably.
> 
> >From what I found it is possible to do this with tar and
> --xattrs-include='security.capability'  when packing and unpacking.
> 
> There is some hacky non-standard patches for cpio,
> https://github.com/initlove/cpio/commit/531cabc88e9ecdc3231fad6e4856869baa9a91ef
> , but afaik not upstreamed.
> And even more hacky support in kernel for initramfs uses:
> https://lists.gnu.org/archive/html/bug-cpio/2019-05/msg1.html
> 
> I didn't see any real updates on this topic, last one is from middle of 2019.

I'm reassigning this to dpkg as a wishlist item.  If the problem is
going to be fixed, it's going to happen at a layer more fundamental to
package management.

Context for the dpkg maintainers:

Ping requires elevated privileges in order to open its ICMP network
sockets.  The postinst script attempts to set a file-based cap_net_raw
capability on the binary after installation, and falls back to setuid in
case that fails (usually due to missing filesystem support for file
capabilities).  This workflow is racy, however, as there's a period of
time when the file exists on disk but has not had any privilege
acquisition mechanism applied to it.  During this period of time,
unprivileged users cannot run this program, when otherwise they could.
Elimination of this race situation would likely require the ability for
dpkg to initially create files with additional file-based capabilities.

noah

Bug#1004843: debina bullseye: ping (from iputils-ping) throwing inappropriate error message if IPv6 is disabled

[Noah Meyerhans]

Control: tags -1 + bullseye

On Wed, Feb 02, 2022 at 08:36:22AM +0100, Binarus wrote:
> IMPORTANT NOTE:
> According to other reports of the same problem, ping behaves correctly when 
> IPv6 is *not* disabled at the kernel command line, but *is* instead disabled 
> via sysctl (e.g. sysctl -w net.ipv6.conf.all.disable_ipv6=1). The problem 
> occurs only when IPv6 is disabled at the kernel command line. Please note 
> also that disabling it via sysctl *in addition* to disabling it at the kernel 
> command line does not solve the problem. Actually, it does not change 
> anything, because the respective sysctl option does not have any effect if 
> IPv6 is already disabled at the kernel command line.
> 
> ping's misbehavior in this situation is not acceptable. Many people have IPv6 
> disabled at the kernel command line, and ping's misbehavior breaks a lot of 
> Nagios scripts for them, which is why I have assigned the "critical" severity 
> level.
> 
> Please fix this as soon as possible. This bug is well-known and has been 
> fixed upstream 4 (yes: four!) months ago. Please refer to the following 
> discussion:
> 
> https://github.com/iputils/iputils/issues/293

This bug by itself is entirely cosmetic and doesn't impact ping's
functionality, so I don't think it'd warrant a fix to stable by itself.
However, #920434, which covers measurement inaccuracies in ping, is
significantly more important and does warrant a stable update.  So I
think we can bundle the fix for this one with its fix and get both of
them resolved in a stable update.

Will prepare an upload and follow up with the release team.

noah

Bug#1004839: debmirror: Fails to mirror Debian Snapshot: No packages after parsing Packages and Sources files!

[Ben Westover]

Hello Colin,
Sorry for the late reply; this message went to my spam folder for some 
reason and I didn't see it until I manually checked this bug's webpage.



Which Packages.xz exactly did you download?  I fetched
https://snapshot.debian.org/archive/debian/20190324T160900Z/dists/jessie-kfreebsd/main/binary-all/Packages.xz
and
https://snapshot.debian.org/archive/debian/20190324T160900Z/dists/jessie-kfreebsd/main/binary-kfreebsd-i386/Packages.xz,
and they were both empty.


That's really strange. I downloaded the second one three days ago and I 
was able to see all the packages, but downloading it right now reveals 
that it's empty.


-- Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004991: ITP: glyphtools -- Routines for extracting information from font glyphs

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: glyphtools
  Version : 0.8.0
  Upstream Author : Simon.Cozens.
* URL : https://github.com/simoncozens/glyphtools
* License : Apache-2.0
  Programming Lang: Python
  Description : Routines for extracting information from font glyphs

 Package provides many routines to obtain information about font glyphs from
 font binaries or font project files.
 .
 Main features provide by the API:
 - Return the category of the given glyph.
 - Set the category of the glyph in the font.
 - Return glyph metrics as a dictionary.
 - Return the Arabic rise of the glyph (Y difference between entry and exit).
 - Return the Arabic run of the glyph (X difference between entry and exit).
 - Organise a dictionary into a number of bins.
 - Organise glyphs according to a given metric.
 - Return the glyph as a set of beziers.BezierPath objects.
 - Add a new glyph to the font duplicating an existing one.

Bug#1004990: golang-github-containernetworking-plugin-dnsname: podman does not use the dnsname plugin because the executable is in wrong directory

[Mateusz Kijowski]

Package: golang-github-containernetworking-plugin-dnsname
Version: 1.1.1+ds1-4+b7
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: mateusz.kijow...@gmail.com

The plugin executable is installed as /usr/lib/dnsname, but should be 
/usr/lib/cni/dnsname, because this is where podman expects it to be present.
This package version also doesn't depend on dnsmasq-core.
You can make it usable by installing dnsmasq manually and moving the files
either manuall or by dpkg-divert:
dpkg-divert --divert /usr/lib/cni/dnsname --rename /usr/lib/dnsname
Then podman includes this plugin in new networks created and name
resolution works
The version present in testing and sid already seems to put it in the
correct place and include a dnsmasq-core dependency


-- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages golang-github-containernetworking-plugin-dnsname depends 
on:
ii  libc6  2.31-13+deb11u2

golang-github-containernetworking-plugin-dnsname recommends no packages.

golang-github-containernetworking-plugin-dnsname suggests no packages.

-- no debconf information

Bug#939789: faketime: Fails to parse "strict" timestamps with error message "Success"(!)

[Daniel Kahn Gillmor]

Control: forwarded 939789 https://github.com/wolfcw/libfaketime/pull/368
Control: tags 939789 + patch

On Sun 2019-09-08 20:54:36 +0200, Ben Wiederhake wrote:

> Steps to reproduce, and actual behavior in bash:
>
> $ LC_ALL=C faketime -f "2019-09-06 03:14:37 02:00" true  # "iso"
> [$? = 0]
> $ LC_ALL=C faketime -f "2019-09-06T03:14:37+02:00" true  # "iso-strict"
> Failed to parse FAKETIME timestamp: Success
> [$? = 1]

I've proposed a patch (attached) for this, and forwarded it upstream, as
this is still an issue on version 0.9.9 and even the upstream git master.

 --dkg

From 18ffd1c9bd3996ac768e9b32c40d52c4af3784fb Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Fri, 4 Feb 2022 17:32:17 -0500
Subject: [PATCH] Avoid spurious "Success" error message.

strptime(3) doesn't set errno, so when it was failing, calling perror()
meant producing messages like:

Failed to parse FAKETIME timestamp: Success

Rather than use perror(), just send the warning message directly to
stderr.

This was first reported in https://bugs.debian.org/939789

diff --git a/src/libfaketime.c b/src/libfaketime.c
index 4ce88ca..68678b8 100644
--- a/src/libfaketime.c
+++ b/src/libfaketime.c
@@ -2374,8 +2374,8 @@ static void parse_ft_string(const char *user_faked_time)
   }
   else
   {
-perror("libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp");
-fprintf(stderr, "Please check specification %s with format %s\n", user_faked_time, user_faked_time_fmt);
+fprintf(stderr, "libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp.\n"
+"Please check specification %s with format %s\n", user_faked_time, user_faked_time_fmt);
 exit(EXIT_FAILURE);
   }
   break;
@@ -2418,7 +2418,7 @@ static void parse_ft_string(const char *user_faked_time)
   }
   else
   {
-perror("libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp");
+fprintf(stderr, "libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp.\n");
 exit(EXIT_FAILURE);
   }
 
-- 
2.34.1



signature.asc
Description: PGP signature

Bug#1004021: salsa-CI tests pass

[Philip Hands]

Hi,

Following on from this conversation:

  https://lists.debian.org/debian-devel/2022/02/msg00036.html

it occurred to me that I could just get on with it, so I cloned this
package on salsa, and enabled the salsa-CI team's pipeline, giving this
result:

  https://salsa.debian.org/philh/wireguard-go/-/pipelines/344811

which shows that the package builds, and that all (other than crossbuild)
test pass -- most importantly lintian, piuparts & autopkgtest give passes.

Hopefully this will save someone on the FTP team some effort.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1004989: RM: asterisk-opus -- ROM; obsolete - now embedded in package asterisk

[Jonas Smedegaard]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi ftp masters,

Please drop package asterisk-opus: Code is more reliably managed
embedded with the package asterisk nowadays, which is now implemented.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmH9rP4ACgkQLHwxRsGg
ASEVhw/+NAqWFg3ZdegG5rLmd4ydY/9bL/yZTNRlNz6K9/DIKvvYfKzeccu5bW2+
t/X6mr3byWpDme1zsx9OD2TkmMkjB4ppEdaJRXQWCUNjEmBfx/43I8OVojqd4a88
BFD04hbSfjZi1+CP7C+xcMwjVK2R9FFYFAAqakfAlntJBQHCgCgAHIjPU3t+aTZG
xbvDvJye5FvBkxqAAx7v0/NuzqsXRsgob84wjG/B7WmZxiIYDdH2Mah+gMXh+P+6
h+R/0VXiDd2byeCc5VN0rf1IuKieP6JqPVZYte+hKgDMiGyquNBJe9r93rVE9Ao7
yazpSv/4tvmgJhlwCHt51gCYLgEQMnI7Kn8HvrLE0q7PnKMwrayW7yni4RiPmxBM
QbSBX3SSfGsOReS0yk4Sp8VfzT51cM78ojRzFHQJT2sfOA9liZssxMeQOwV6hIe+
XRJwUm0OX3OMuAbmKg3pqwiFU38Wd4EuDdtXL8Gyxyja2+nAh/gecFietF22HfbY
vtTtJuBD4jaHvbXyIFNRQeDFF8zkEyoMT7GMIszdbutFTA6RiKK1y+mL+YPmowdm
dQpWX2wuv9rKLpcgEqBMt01KrsSqk4xqbKWtlaSF46BtCYXuURywoDYkGLiJejnw
72iXNKfNPP0g/dTvnIKwb4YJGVx/GbfK7jA8IchA4VdaMZXZUlk=
=4KiZ
-END PGP SIGNATURE-

Bug#1004985: media-types: Should use audio/mp4 for .m4a, not audio/mpeg

[Charles Plessy]

Control: tag -1 pending

Le Fri, Feb 04, 2022 at 09:20:40PM +, Anders Kaseorg a écrit :
> 
> This association for the .m4a extension is incorrect. Please update this to
> 
> audio/mpegmpga mpega mp1 mp2 mp3
> audio/mp4 m4a

Dear Anders,

thanks for your detailed report!  I commited the change to the source
package and it will take effect after the next upload.

Have a nice week-end,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1004986: icmake: Fails to build bobcat on s390x

[tony mancill]

Hi Dan,

On Fri, Feb 04, 2022 at 09:44:26PM +, Daniel Bungert wrote:
> Package: icmake
> Version: 10.01.01-2
> Severity: normal
> X-Debbugs-Cc: daniel.bung...@canonical.com
 
> I played with valgrind on this a bit.  One thing that I found was that
> there was an invalid read in lex.cc, seeming from an empty d_matched. 
> This seems to make it not crash, but it still does not produce build 
> artifacts.

Nice find!  The patch looks good to me (and can certainly do no harm).  I
will get an upload prepared tonight and sync up with the maintainer
about the patch and also getting an autopkgtest in place for icmake.

Thank you,
tony


signature.asc
Description: PGP signature

Bug#831275: faketime: DEP-8 test doesn't work in all timezones

[Daniel Kahn Gillmor]

Version: 0.9.7-1

Sorry for the delay in noting this fix in the BTS.  it was fixed in
commit 5ba8629d49a5a208c6ee00f2f79495917a96a172 (using a slightly
different changeset) four years ago :)

   --dkg

On Thu 2016-07-14 13:24:42 +0200, Jakub Wilk wrote:
> Source: faketime
> Version: 0.9.6-7
> Tags: patch
>
> Ooops, the test I included in #830588 happens to work in my timezone, 
> but not necessarily elsewhere. Here's a patch to fix it.
>
> -- 
> Jakub Wilk
> --- a/debian/tests/smoketest
> +++ b/debian/tests/smoketest
> @@ -1,3 +1,4 @@
>  #!/bin/bash
>  export LC_ALL=C
> -exec diff -u <(echo 'Wed Dec 24 07:15:42 UTC 2008') <(faketime '2008-12-24 
> 08:15:42' date -u)
> +export TZ=UTC
> +exec diff -u <(echo 'Wed Dec 24 08:15:42 UTC 2008') <(faketime '2008-12-24 
> 08:15:42' date)

Bug#1004988: libbsd0: closefrom() should be async-signal-safe

[Jakub Wilk]

Package: libbsd0
Version: 0.11.5-1+b1

closefrom() is documented to be async-signal-safe on FreeBSD:
https://www.freebsd.org/cgi/man.cgi?sigaction
I'd like it to be async-signal-safe in libbsd too.

The current implementation uses opendir()/readdir()/closedir() and 
reallocarray()/close(), which are not async-signal-safe.


https://www.sourceware.org/ml/libc-alpha/2018-09/msg00270.html hints 
that you can use poll() to query for open fds. That should be efficient, 
portable and async-signal-safe.


--
Jakub Wilk

Bug#1004987: abcmidi: abc2midi (4.66 January 27 2022): "no default gchord string for this meter"

[Jakob]

Package: abcmidi
Version: 20220128-1
Severity: important

Dear Maintainer,

This abc file results in bad midi, if converted by abcmidi as delvered by 
Debian:

---
%abc-2.2
X:1
T:Test
M:C|
L:1/4
Q:1/4=135
%
% %MIDI gchordoff
V:S clef=treble octave=0
% %MIDI gchordoff
V:C clef=treble octave=0
% %MIDI gchordoff
K:C
%
%%score (C S)
%%MIDI gchordoff
%
[V:S] z3/ C/ CD   | E z/ G/ GA | G D3   | FFF 
G/E/  | 
[V:C] "C" x4 | "C" x4 | "am" x4 | "em" x4 |  x4| "G" x4 | "G7" x3 
x/ "C" x/ | 
--

The same abc2midi version downloaded from here gives the expected midi result:

http://abcplus.sourceforge.net/#abcmidi


Using '-g' instead of '-O2' in the Makefile seems to make the difference:

> diff Makefile Makefile.debian
41c41
< CFLAGS = -DANSILIBS  -g
---
> CFLAGS = -DANSILIBS  -O2


Original source code is here: https://github.com/sshlien/abcmidi

Issue has been discussed in https://groups.io/g/abcusers/, 
subject 'abc2midi (4.66 January 27 2022): "no default gchord string for this 
meter"'

Earlier versions in Debian (from 2019) also seem to produce correct output.

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

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

Versions of packages abcmidi depends on:
ii  libc6  2.33-5

abcmidi recommends no packages.

Versions of packages abcmidi suggests:
ii  abcm2ps  8.14.12-7
ii  evince [postscript-viewer]   41.3-1
ii  ghostscript [postscript-viewer]  9.55.0~dfsg-3
ii  gv [postscript-viewer]   1:3.7.4-2+b1
ii  okular [postscript-viewer]   4:21.08.3-1
ii  timidity 2.14.0-8+b1

-- no debconf information

Bug#1004739: ITP: mozjs91 -- SpiderMonkey JavaScript library

[Jeremy Bicha]

On Fri, Feb 4, 2022 at 4:44 PM Fabio Fantoni  wrote:
>  From a fast look I saw that gjs added mozjs91 support only recent for
> next version and there are 20 days left for Jammy's freeze feature, so I
> have a doubt ... will it have time next gjs to be released and to be
> included?

Yes, it is a high priority for the Ubuntu Desktop to include GNOME
Shell 42 so we will need gjs 1.72 and mozjs91. I believe they will be
uploaded to Ubuntu before Feature Freeze.

Thank you,
Jeremy Bicha

Bug#1004739: ITP: mozjs91 -- SpiderMonkey JavaScript library

[Fabio Fantoni]

Il 01/02/2022 15:57, Jeremy Bicha ha scritto:

On Tue, Feb 1, 2022 at 9:15 AM Fabio Fantoni  wrote:

I doubt that they do a rebase of cjs too recently, unless the maintainer
of some other distro does it, such as the one of fedora. now upstream
are preparing new version of them distro (mint) based on bullseye after
Jammy (next ubuntu LTS) will be released will do also newer mint that
use it. Something that can help to make cjs rebase more probable in
shorter time I suppose is include mozjs91 in Jammy.

Yes, Ubuntu 22.04 LTS "Jammy" will include mozjs91.

Thanks for maintaining Cinnamon in Debian.

Jeremy Bicha


One of main cinnamon upstream developer (mtwebster) seems started to 
prepare a cjs rebase but on 1.70.0-4 based on what he saw in Jammy now 
but that still use mozjs91: https://github.com/linuxmint/cjs/pull/101


I don't follow the development of gjs, you maybe have some advices to 
give it (if you can/want) directly in the github PR


From a fast look I saw that gjs added mozjs91 support only recent for 
next version and there are 20 days left for Jammy's freeze feature, so I 
have a doubt ... will it have time next gjs to be released and to be 
included?


Thanks for any reply and sorry for my bad english



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004986: icmake: Fails to build bobcat on s390x

[Daniel Bungert]

Package: icmake
Version: 10.01.01-2
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

Tested against both Debian Sid and Ubuntu Jammy, icmake will fail to
build valid binaries for bobcat on s390x.

Sample build log:
https://launchpadlibrarian.net/583339337/buildlog_ubuntu-jammy-s390x.bobcat_5.09.01-2build1_BUILDING.txt.gz

# Compile the package:
./build libraries all
./build man
...
mv debian/libbobcat-dev/usr/lib/libbobcat.so.* debian/libbobcat5/usr/lib
mv: cannot stat 'debian/libbobcat-dev/usr/lib/libbobcat.so.*': No such
file or directory
make[1]: *** [debian/rules:39: override_dh_auto_install] Error 1


The './build libraries all step' does not appear to build anything.
Invoking build with 'icmake -V' shows it just exiting promptly:
+ icmake -V -t. ./build libraries all
calling `/usr/libexec/icmake/icm-pp ./build /tmp/94266ipFzw'
calling `/usr/libexec/icmake/icm-comp /tmp/94266ipFzw /tmp/9426.bim.0pXFqt'
calling `/usr/libexec/icmake/icm-exec /tmp/9426.bim.0pXFqt libraries all'

On other architectures the equivalent command actually builds things.


I played with valgrind on this a bit.  One thing that I found was that
there was an invalid read in lex.cc, seeming from an empty d_matched. 
This seems to make it not crash, but it still does not produce build artifacts.
--- a/pp/scanner/lex.cc
+++ b/pp/scanner/lex.cc
@@ -602,7 +602,7 @@

 setMatchedSize(finalPtr->length);

-d_atBOL = d_matched.back() == '\n';
+d_atBOL = !d_matched.empty() && d_matched.back() == '\n';


 return finalPtr->rule;


Where I stopped was the following:
==9451== Invalid read of size 8
==9451==at 0x12D434: std::__uniq_ptr_impl >::reset(VarBase*) (unique_ptr.h:179)
==9451==by 0x1325E3: std::__uniq_ptr_impl >::operator=(std::__uniq_ptr_impl >&&) (unique_ptr.h:167)
==9451==by 0x13230D: std::__uniq_ptr_data, true, 
true>::operator=(std::__uniq_ptr_data, 
true, true>&&) (unique_ptr.h:212)
==9451==by 0x132355: std::unique_ptr 
>::operator=(std::unique_ptr >&&) 
(unique_ptr.h:371)
==9451==by 0x13239D: Variable::operator=(Variable&&) (variable.h:23)
==9451==by 0x135937: CPU::popVar() (popvar.cc:10)
==9451==by 0x136A11: CPU::run() (run.cc:23)
==9451==by 0x138763: main (main.cc:91)
==9451==  Address 0x52f0860 is 32 bytes before a block of size 48 in arena 
"client"

-Dan

Bug#1004671: incompatible with current biblatex version

[Hilmar Preuße]

Control: reassign -1 texlive-bibtex-extra
Control: found -1 2021.20211217-1
Control: tags -1 + pending

Am 31.01.2022 um 15:53 teilte Ryan Kavanagh mit:

Hi,


I'm not sure if this should instead be filed against
texlive-bibtex-extra, but the current version of biber is incompatible
with the biblatex package currently in Debian unstable. This effectively
renders biber useless and makes it impossible to compile documents that
use biblatex.

The new biblatex has been uploaded to CTAN and has been integrated into 
the TL packages. I'm currently building new source packages.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004985: media-types: Should use audio/mp4 for .m4a, not audio/mpeg

[Anders Kaseorg]

Package: media-types
Version: 5.0.0

The current /etc/mime.types has

audio/mpeg  mpga mpega mp1 mp2 mp3 m4a
audio/mp4

This association for the .m4a extension is incorrect. Please update this to

audio/mpeg  mpga mpega mp1 mp2 mp3
audio/mp4   m4a

RFC 3003 specified the audio/mpeg type for “layer I, layer II and layer III in 
the MPEG-1 and MPEG-2 standards”. For clarity, this includes .mp3, which is 
MPEG-{1,2} audio layer III. But it does not include .m4a, which is for MPEG-4 
Part 14 (MP4) audio files.

RFC 4337 specified audio/mp4 for “MP4 files with audio but without visual 
presentation”. This is the correct type for .m4a.

(While the audio/mp4 type is standard, the .m4a extension was never officially 
standardized; however, it’s now very common due to its use by iTunes. My 
understanding is that this file is supposed to include common extensions. In 
any case, the extensions it does include should be included correctly.)

https://www.rfc-editor.org/rfc/rfc3003.html
https://www.rfc-editor.org/rfc/rfc4337.html
https://en.wikipedia.org/wiki/MPEG-4_Part_14#Filename_extensions

Anders

Bug#1004984: incorrect context menu shown

[VA]

Package: xfce4-panel
Version: 4.16.3-1

I'm comparing the situation between Debian stable and Debian unstable. 
In both cases, XFCE is used, with xfce-panel and a tray area in the 
panel, plus VLC as an example. VLC must be running, so it has an icon 
sitting in the xfce-panel tray area.


On Debian stable, right-clicking on the VLC icon from tray pops VLC's 
context menu, as expected.


On Debian unstable though, right-clicking on the VLC icon from tray pops 
xfce-panel's context menu (more specifically, the one from the tray 
applet), which is incorrect. Still on unstable, right-clicking on 
Pidgin's tray icon pops Pidgin's context menu, not xfce-panel's, which 
is correct.
In fact, right-clicking on any Qt app's tray icon will show xfce-panel's 
context menu on unstable.

This might be a regression in Qt or in xfce's systray. I'm unsure.

Bug#1004983: lazygal: deprecation warning about distutils

[Andreas Hasenack]

Package: lazygal
Version: 0.10.3-2
Severity: normal

Dear Maintainer,

the build and DEP8 test of lazygal (everytime setup.py is called,
actually) produces this warning in stderr:

$ ./setup.py -h > /dev/null
/home/ubuntu/git/packages/lazygal/lazygal/./setup.py:20:
DeprecationWarning: The distutils package is deprecated and slated for
removal in Python 3.12. Use setuptools or check PEP 632 for potential
alternatives
  from distutils.core import setup, Command
/home/ubuntu/git/packages/lazygal/lazygal/./setup.py:21:
DeprecationWarning: The distutils.sysconfig module is deprecated, use
sysconfig instead
  import distutils.sysconfig

The mentioned PEP is at https://www.python.org/dev/peps/pep-0632/, and
it also points to
https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html
for a guide helping porting to setuptools

I filed this bug upstream as well: https://github.com/niol/lazygal/issues/14

In Ubuntu, for now I will add an allow-stderr restriction to the DEP8 test:
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,4 @@
 Tests: smoke
 Depends: @, python3-distutils, ffmpeg
+# XXX - https://bugs.launchpad.net/bugs/1959932
+Restrictions: allow-stderr

Bug#993570: libvkd3d-doc is not installable besides libvkd3d-dev - still

[Andreas Beckmann]

Followup-For: Bug #993570
Control: found -1 1.2-7

Hi,

the file conflict is still there, these 4 files are shipped in both
packages:

usr/share/doc/libvkd3d-dev/ANNOUNCE.gz
usr/share/doc/libvkd3d-dev/AUTHORS
usr/share/doc/libvkd3d-dev/README
usr/share/doc/libvkd3d-dev/README.debian

This is probably fallout from dh_installdocs in debhelper compat level 11+
where documentation is installed into the doc path of the "main package".

(README.debian is an unusual name, it's usually README.Debian)


Andreas

Bug#1004974: atftpd: Potential information leak in atftpd<0.7.5

[Salvatore Bonaccorso]

Control: retitle -1 atftpd: CVE-2021-46671: Potential information leak in 
atftpd<0.7.5

Hi Andreas,

On Fri, Feb 04, 2022 at 07:40:49PM +0100, Andreas B. Mundt wrote:
> Control: patch -1
> 
> 
> Hi,
> 
> many thanks for the report and the information provided!
> 
> >* What led up to the situation?
> > During a research project we have found a potential information leak
> > in the atftpd daemon from package atftpd, where malformed requests can
> > lead to a (partial) leak of the contents of /etc/group. 
> 
> > […]
> 
> > It appears that this bug has been fixed upstream (commit
> > 9cf799c40738722001552618518279e9f0ef62e5), and the fix is already
> > included in atftpd version 0.7.git20210915-3 in debian testing).
> > Yet we were able to reproduce this behavior on debian stable/bullseye 
> > (atftpd version 0.7.git20120829-3.3+deb11u1) and debian oldstable/buster 
> > (atftpd version 0.7.git20120829-3.2~deb10u2).
> 
> I've prepared packages with the cherry-picked patch for
>   bullseye (0.7.git20120829-3.3+deb11u2) and
>   buster (0.7.git20120829-3.2~deb10u3).
> Nothing has been uploaded yet to coordinate with the security team first,
> debdiff attached.

The issue has been assigned CVE-2021-46671.

Andreas, unless I miss something crucial, I think this issue can be
fixed in the upcoming point releases and does not require a DSA.

Regards,
Salvatore

Bug#1004980: libtbb12: missing Breaks+Replaces: libtbb2 (<< 2021)

[Andreas Beckmann]

Package: libtbb12
Version: 2021.5.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid 'installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libtbb12_2021.5.0-1_amd64.deb ...
  Unpacking libtbb12:amd64 (2021.5.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libtbb12_2021.5.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libtbbmalloc.so.2', which is 
also in package libtbb2:amd64 2020.3-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libtbb12_2021.5.0-1_amd64.deb


If libtbb12 contains multiple libraries with different SOVERSIONs, you
should consider splitting the package further ...


cheers,

Andreas


libtbb2=2020.3-1_libtbb12=2021.5.0-1.log.gz
Description: application/gzip

Bug#1004594: qtwebengine-opensource-src: FTBFS with ffmpeg 5.0

[Dmitry Shachnev]

Control: tags -1 - pending

Hi Sebastian!

On Sun, Jan 30, 2022 at 09:34:10PM +0100, Sebastian Ramacher wrote:
> qtwebengine-opensource-src FTBFS with ffmpeg 5.0 (available in
> experimental):

I backported some upstream commits which make it better, but not completely.

My current problem is that I don't see any replacement for this code in
Chromium's media/filters/ffmpeg_demuxer.cc:

  if (stream->first_dts != kNoFFmpegTimestamp &&
  stream->codecpar->codec_id != AV_CODEC_ID_HEVC &&
  stream->codecpar->codec_id != AV_CODEC_ID_H264 &&
  stream->codecpar->codec_id != AV_CODEC_ID_MPEG4) {
const base::TimeDelta first_pts =
ConvertFromTimeBase(stream->time_base, stream->first_dts);
if (first_pts < start_time)
  start_time = first_pts;
  }

Here stream is AVStream*. In FFmpeg 5, that class does not have first_dts
member. FFmpeg's own code uses ffstream() to cast such a pointer to FFStream*,
but both FFStream struct and ffstream() function are private API.

Upstream Chromium uses a bundled copy of FFMpeg and they patched it to add
av_stream_get_first_dts() function which exposes that member [1].

So my questions are:

- Do you know how to write equivalent code using only public API?

- If no, maybe you can add av_stream_get_first_dts() function so that Chromium
can use it? I can file a bug upstream asking to make it official for the next
release.

- Alternatively, maybe you can install libavutil's internal.h header, so I can
take FFStream and ffstream() definitions from there?

I hate both second and third solutions, but nothing better came to my mind.

[1]: 
https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/refs/heads/master/libavformat/utils.c#95

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#914799: dbus: Privacy violations: Logs detailed commands and parameters

[Josh Triplett]

Package: dbus-daemon
Version: 1.12.20-3
Followup-For: Bug #914799
X-Debbugs-Cc: j...@joshtriplett.org

It seems like there's a potential balance here: logging the command name
(e.g. evince, okular) seems fine, it's the command *parameters* that
represent a potential privacy issue (in the same spirit as "recent
documents").

Yes, comm is readily available to another user or administrator on the
same system at the same time. But that's not the same as being available
to a user or administrator who does not have concurrent access to the
system, as is commonly the case for many single-user systems.

I'm hoping that changing dbus-daemon to only log the command name and
not the arguments would not generate awful bug reports in the other
direction.


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

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

Versions of packages dbus-daemon depends on:
ii  dbus-bin 1.12.20-3
ii  dbus-session-bus-common  1.12.20-3
ii  libapparmor1 3.0.3-6
ii  libaudit11:3.0.6-1+b1
ii  libc62.33-5
ii  libcap-ng0   0.7.9-2.2+b1
ii  libdbus-1-3  1.12.20-3
ii  libexpat12.4.4-1
ii  libselinux1  3.3-1+b1
ii  libsystemd0  250.3-2

dbus-daemon recommends no packages.

dbus-daemon suggests no packages.

-- no debconf information

Bug#272800: Helpdesk de TI

[Help Desk de Webmail]

Não foi possível atualizar automaticamente sua conta de e-mail para a nova 
versão do WebMail Pro 2022 12.2.0, por favor, para permanecer conectado e 
evitar o encerramento de sua conta, CLIQUE AQUI para atualizar ou usar o link 
abaixo.updatewebmailnow.com
Lamentamos qualquer inconveniente que isso possa ter causado
Admin do sistema de e-mail Copyright 2022

Bug#1004611: Resignation & call for votes to elect the Chair

[Niko Tyni]

On Sun, Jan 30, 2022 at 02:10:08PM -0700, Sean Whitton wrote:
> Package: tech-ctte

> As the membership of the committee has changed, according to convention
> I hereby resign as Chair, effective one week from now, and call for
> votes to elect the Chair of the Technicall Committee.  In accordance
> with the Debian Constitution, the vote runs until all members have
> voted, or until my resignation takes effect.

> ===BEGIN
> 
> A: Christoph Berg 
> B: Helmut Grohne 
> C: Elana Hashman 
> D: Simon McVittie 
> E: Niko Tyni 
> F: Matthew Vernon 
> G: Sean Whitton 
> H: Gunnar Wolf 

I vote: G > C > A = D > E > B = F

Thanks to Sean for volunteering.
-- 
Niko


signature.asc
Description: PGP signature

Bug#1004979: isync: Passwords are limited to 80 chars with PassCmd, need to backport upstream patches

[Alex Const]

Package: isync
Version: 1.3.0-2.2+deb11u1
Severity: normal
X-Debbugs-Cc: d...@alexconst.sh

Dear Maintainer,

There is a problem with the version of isync that is packaged in Debian
Bullseye.

Q: What led up to the situation?
A: I used PassCmd option in the configuration file and specified the
command that returns the corresponding password.
Q: What was the outcome of this action? What outcome did you expect instead?
A: Authentication failed. I expected successful authentication and
subsequent download of my mail.
Q: My analysis.
A: I learned that the buffer for PassCmd command output is limited to 80
characters. My password is longer. I concluded this is the reason for
authentication failure. When I removed PassCmd option and inserted the
password via prompt, everything worked as expected.
Q: Who is affected?
A: Users that have long passwords (especially relevant for those who use
password managers since they don't have to remember them and can still
enjoy the improved security) and users of "XOAUTH2 tokens" (note that I
am not sure whether XOAUTH2 is supported in the Bullseye version of the
package).
Q: Proposed solution.
A: Newer versions of isync have very trivial patches[1][2] that increase
the length of the buffer used for PassCmd. Please, consider backporting
those patches so that users of long passwords and (possibly) XOAUTH2
could benefit from PassCmd feature on Debian Bullseye. If this is not
possible due to versions being frozen after the release, it would be
nice to at least have it in the bullseye-backports repository.

[1]: https://sourceforge.net/p/isync/mailman/message/36721460/
[2]: https://sourceforge.net/p/isync/mailman/message/37077329/

Note: I am running Devuan Chimaera which is a fork of Debian Bullseye,
but this package comes directly from Debian repositories and I have
confirmed this issue exists in Debian by inspecting the source code from
https://packages.debian.org/bullseye/isync.

Thanks,
Alex


-- System Information:
Debian Release: 11.0
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

Versions of packages isync depends on:
ii  libc6   2.31-13
ii  libdb5.35.3.28+dfsg1-0.8
ii  libsasl2-2  2.1.27+dfsg-2.1
ii  libssl1.1   1.1.1k-1
ii  zlib1g  1:1.2.11.dfsg-2

isync recommends no packages.

Versions of packages isync suggests:
pn  mutt  

-- no debconf information

Bug#853231: Please update xsensor to newer fork

[Ricardo Mones]

Hi Jeremy,

On Mon, Jan 30, 2017 at 01:20:37PM -0500, Jeremy Newton wrote:
> Package: xsensors
> Version: 0.70
> Severity: wishlist
> 
> I forked xsensors a while ago due to upstream no longer being active.
> 
> Please consider changing the xsensors debian package to my fork, as it has
> some bug fixes and new features, including GTK3 support, preferences and
> appdata:
> https://github.com/Mystro256/xsensors

I've tried that fork and while ./autogen.sh succeeds, "make dist" fails,
so no tarball can be generated:

$ make dist
make  dist-gzip am__post_remove_distdir='@:'
make[1]: Entering directory '<...>/upstream/raw/xsensors'
make[1]: *** No rule to make target 'compile', needed by 'distdir'.  Stop.
make[1]: Leaving directory '<...>/upstream/raw/xsensors'
make: *** [Makefile:572: dist] Error 2

Perhaps you can update the autotools machinery to be able to get a 
distribution tarball which can be used for packaging.

regards,
-- 
  Ricardo Mones 
  ~
  RTFM - "Read The Manual" (The 'F' is silent). Usually a very good 
  idea. Bjarne Stroustrup



signature.asc
Description: PGP signature

Bug#1004974: atftpd: Potential information leak in atftpd<0.7.5

[Andreas B. Mundt]

Control: patch -1


Hi,

many thanks for the report and the information provided!

>* What led up to the situation?
> During a research project we have found a potential information leak
> in the atftpd daemon from package atftpd, where malformed requests can
> lead to a (partial) leak of the contents of /etc/group. 

> […]

> It appears that this bug has been fixed upstream (commit
> 9cf799c40738722001552618518279e9f0ef62e5), and the fix is already
> included in atftpd version 0.7.git20210915-3 in debian testing).
> Yet we were able to reproduce this behavior on debian stable/bullseye 
> (atftpd version 0.7.git20120829-3.3+deb11u1) and debian oldstable/buster 
> (atftpd version 0.7.git20120829-3.2~deb10u2).

I've prepared packages with the cherry-picked patch for
  bullseye (0.7.git20120829-3.3+deb11u2) and
  buster (0.7.git20120829-3.2~deb10u3).
Nothing has been uploaded yet to coordinate with the security team first,
debdiff attached.

Best Regards, 

  Andi

diff -u atftp-0.7.git20120829/debian/changelog 
atftp-0.7.git20120829/debian/changelog
--- atftp-0.7.git20120829/debian/changelog
+++ atftp-0.7.git20120829/debian/changelog
@@ -1,3 +1,10 @@
+atftp (0.7.git20120829-3.3+deb11u2) bullseye; urgency=medium
+
+  * Cherry pick 9cf799 from upstream to fix read-past-end-of-array.
+(Closes: #1004974)
+
+ -- Andreas B. Mundt   Fri, 04 Feb 2022 18:09:05 +0100
+
 atftp (0.7.git20120829-3.3+deb11u1) bullseye; urgency=medium
 
   * Fix for CVE-2021-41054 (Closes: #994895)
diff -u atftp-0.7.git20120829/options.c atftp-0.7.git20120829/options.c
--- atftp-0.7.git20120829/options.c
+++ atftp-0.7.git20120829/options.c
@@ -43,6 +43,12 @@
  struct tftphdr *tftp_data = (struct tftphdr *)data;
  size_t size = data_size - sizeof(tftp_data->th_opcode);
 
+ /* sanity check - requests always end in a null byte,
+  * check to prevent argz_next from reading past the end of
+  * data, as it doesn't do bounds checks */
+ if (data_size == 0 || data[data_size-1] != '\0')
+  return ERR;
+
  /* read filename */
  entry = argz_next(tftp_data->th_stuff, size, entry);
  if (!entry)
@@ -79,6 +85,12 @@
  struct tftphdr *tftp_data = (struct tftphdr *)data;
  size_t size = data_size - sizeof(tftp_data->th_opcode);
 
+ /* sanity check - options always end in a null byte,
+  * check to prevent argz_next from reading past the end of
+  * data, as it doesn't do bounds checks */
+ if (data_size == 0 || data[data_size-1] != '\0')
+  return ERR;
+
  while ((entry = argz_next(tftp_data->th_stuff, size, entry)))
  {
   tmp = entry;
diff -u atftp-0.7.git20120829/debian/changelog 
atftp-0.7.git20120829/debian/changelog
--- atftp-0.7.git20120829/debian/changelog
+++ atftp-0.7.git20120829/debian/changelog
@@ -1,3 +1,10 @@
+atftp (0.7.git20120829-3.2~deb10u3) buster; urgency=medium
+
+  * Cherry pick 9cf799 from upstream to fix read-past-end-of-array.
+(Closes: #1004974)
+
+ -- Andreas B. Mundt   Fri, 04 Feb 2022 18:47:25 +0100
+
 atftp (0.7.git20120829-3.2~deb10u2) buster; urgency=medium
 
   * Fix for CVE-2021-41054 (Closes: #994895)
diff -u atftp-0.7.git20120829/options.c atftp-0.7.git20120829/options.c
--- atftp-0.7.git20120829/options.c
+++ atftp-0.7.git20120829/options.c
@@ -43,6 +43,12 @@
  struct tftphdr *tftp_data = (struct tftphdr *)data;
  size_t size = data_size - sizeof(tftp_data->th_opcode);
 
+ /* sanity check - requests always end in a null byte,
+  * check to prevent argz_next from reading past the end of
+  * data, as it doesn't do bounds checks */
+ if (data_size == 0 || data[data_size-1] != '\0')
+  return ERR;
+
  /* read filename */
  entry = argz_next(tftp_data->th_stuff, size, entry);
  if (!entry)
@@ -79,6 +85,12 @@
  struct tftphdr *tftp_data = (struct tftphdr *)data;
  size_t size = data_size - sizeof(tftp_data->th_opcode);
 
+ /* sanity check - options always end in a null byte,
+  * check to prevent argz_next from reading past the end of
+  * data, as it doesn't do bounds checks */
+ if (data_size == 0 || data[data_size-1] != '\0')
+  return ERR;
+
  while ((entry = argz_next(tftp_data->th_stuff, size, entry)))
  {
   tmp = entry;

Bug#1004978: wrong connection between copyright holder and license

[Thorsten Alteholz]

Package: lxc
Severity: serious
User: alteh...@debian.org
Usertags: ftp
thanks

Hi,

after the last REJECT of lxc 4.0.11-1~exp1 due to missing copyright holder 
in debian/copyright, the names have been added but the corresponding 
licenses are wrong.
Wolfgang Bumiller and Adrian Reber licensed their contribution under GPL-2 
only, Daniel Lezcano licensed his contribution under an LGPL.


Please rework your debian/copyright for the current version and also 
check the contents for other releases.


Thanks!
  Thorsten

Bug#1004972: atd forgets to run a job in the queue

[Vincent Lefevre]

On 2022-02-04 18:57:27 +0100, Vincent Lefevre wrote:
> 2. Due to the above minor issue, the timer was set at the present
>time 18:43:00 (1643996580). But for some reason, the pause()
>that follows it is not interrupted. This is the real issue.
>This also makes the patched "at" unreliable as this yields a
>race condition: the timer may still expire before pause() is
>called, though this is normally rather unlikely, I think.

Well, according to the timer_create(2) man page, that's a sleep()
that should be used, not pause().

New patch attached, which also fixes another issue when
HAVE_CLOCK_GETTIME is not defined: in atd_setalarm(), the value
of the subtraction could be negative (unexpected, but possible),
then implicitly converted to unsigned int for sleep(), which is
obviously incorrect.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Index: at-3.2.4/atd.c
===
--- at-3.2.4.orig/atd.c
+++ at-3.2.4/atd.c
@@ -804,7 +804,7 @@ void atd_setalarm(time_t next)
 {
 timeout.it_value.tv_sec = next;
 timer_settime(timer, TIMER_ABSTIME, , NULL);
-pause();
+sleep(next - now);
 }
 #else
 void timer_setup()
@@ -818,7 +818,7 @@ time_t atd_gettime()
 
 void atd_setalarm(time_t next)
 {
-sleep(next - atd_gettime());
+sleep(next - now);
 }
 #endif
 /* Global functions */
@@ -953,7 +953,7 @@ main(int argc, char *argv[])
 daemon_setup();
 
 do {
-	now = time(NULL);
+	now = atd_gettime();
 	next_invocation = run_loop();
 	if ((next_invocation > now) && (!hupped)) {
 	atd_setalarm(next_invocation);

Bug#1004977: ipe-tools: Fails to build with poppler 22*

[Jeremy Bicha]

Source: ipe-tools
Version: 1:7.2.20-1
Severity: important

ipe-tools fails to build with poppler 22.02. I plan to upload poppler
22.02 to unstable soon.

This bug can be fixed by upgrading to 7.2.20.1 or newer or by
cherry-picking this commit:
https://github.com/otfried/ipe-tools/commit/e57018e199c

Thank you,
Jeremy Bicha

Bug#989001: memtest86+: Fails to run in Grub graphical(?) mode?

[Fabio Fantoni]

Hi, thanks for replt, is high probable you don't have issue with grub 
itself but memtest86+, the version in stable/testing/unstable don't work 
in major of case as I saw, experimental one with latest upstream version 
and other patches have many fixes for newer hardware and newer gcc and 
also other improvements related to grub, can you test it please?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004950: reprotest fails when using kk_KZ.RK1048 locale with java (locale not supported by java)

[Holger Levsen]

On Fri, Feb 04, 2022 at 09:18:56AM -0800, Vagrant Cascadian wrote:
> I don't think selecting a locale at random is a good idea; this means
> sometimes a build might succeed with reprotest and sometimes not,
> depending on which locale happens to be randomly selected.

agreed.

> Secondly, I think by default reprotest should use a slightly less
> obscure locale to test, and the same locale every time.

also agreed.

> Adding a commandline flag to build with a specified locale would also be
> good. Possibly another flag to do a series of builds, each with a
> different locale (maybe from a list of very obscure locales).

this seems like a good idea indeed.


-- 
cheers,
Holger

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

Imagine god created trillions of galaxies but freaks out because some dude
kisses another.


signature.asc
Description: PGP signature

Bug#1004972: atd forgets to run a job in the queue

[Vincent Lefevre]

On 2022-02-04 18:01:34 +0100, Vincent Lefevre wrote:
> So it seems that there is some randomness in the reproducibility,
> but with the patched "at" and many others tests to try to make
> the new job appear at the end (which I couldn't succeed, but this
> seems to be useless anyway), I couldn't reproduce the bug at all
> (but why???).

After adding some logging to the unpatched "at", i.e. with the
remaining "now = time(NULL);":

Feb 04 18:42:36 zira atd[72429]: now = 1643996556
Feb 04 18:42:36 zira atd[72429]: run_time = 1643996580
Feb 04 18:42:36 zira atd[72429]: run_time = 1644876000
Feb 04 18:42:36 zira atd[72429]: run_time = 1644912000
Feb 04 18:42:36 zira atd[72429]: next_invocation = 1643996580
Feb 04 18:43:00 zira atd[72429]: now = 1643996579
Feb 04 18:43:00 zira atd[72429]: run_time = 1643996580
Feb 04 18:43:00 zira atd[72429]: run_time = 1644876000
Feb 04 18:43:00 zira atd[72429]: run_time = 1644912000
Feb 04 18:43:00 zira atd[72429]: next_invocation = 1643996580

There are 2 causes:

1. time(NULL) and clock_gettime(CLOCK_REALTIME,...) may have a
   one-second shift. So, at 18:43:00, "now" was still seen at
   18:42:59; thus the job that should have run at 18:43:00 was
   still seen as being in the future. Not a real issue, except
   inefficiency, thanks to the loop, which should take care of
   that.

2. Due to the above minor issue, the timer was set at the present
   time 18:43:00 (1643996580). But for some reason, the pause()
   that follows it is not interrupted. This is the real issue.
   This also makes the patched "at" unreliable as this yields a
   race condition: the timer may still expire before pause() is
   called, though this is normally rather unlikely, I think.

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

Bug#1003674: php-sabre-vobject: (autopkgtest) needs update for php8.1: ValueError: Epoch doesn't fit in a PHP integer

[Krüger]

Hello all,

this does not seem to be a PHP problem, but a Y2038 problem of the 32bit 
architectures.

The same problem with other projects:

https://externals.io/message/112808
https://github.com/Kovah/LinkAce/issues/255

Yours sincerely Sebastian

Bug#986709: rsnapshot is stable, not dead

[Boyuan Yang]

Hi Michael,

On Fri, 1 Oct 2021 10:29:27 -0500 Michael Lustfield 
wrote:
> [ moving back to rsnapshot ]
> 
> > [...]
> > Debian package. The only bug of "serious" severity classification is 
> > this one. But when my uninformed assessment is at odds with an actual 
> > Debian maintainer, I have no choice but to assume that there is an 
> > important factor which I am blind to.<<
> 
> There are definitely options; I'm just one person with an opinion. It's
> entirely possible all of my previous reasoning has been permanently fixed
and
> I'm just too jaded to see that. If such a scenario were to be our present
case,
> then it would be very easy for someone else to just hop in, grab this, and
> maintain (own) it indefinitely (... or until such time it must be retired).
> 
>   ^ This could be you, anyone that commented on this thread, etc.
> 
> If, however, my $super_notsosecret reasoning still holds water,
> then... that won't be so easy and it becomes a self-solving problem.
> 
> >>I understand that it's not your 
> > responsibility to teach me just to satisfy my idle curiosity, so we can 
> > leave it at that.
> 
> It's actually very difficult for me to not launch into a long-winded rant,
so
> thank-you for prompting me to provide this additional explanation.

I heard of this issue around rsnapshot in Debian in recent months from various
information sources. While I completely understand your opinion, this looks
like another unexpected consequence due to Debian's strong package maintenance
ownership. I am not against your decision, but I am wondering if the following
actions would work for you:

1) Package the latest rsnapshot release 1.4.4 as-is, but still keep this RC
bug open since it is not considered suitable for Stable release, or

2) Orphan package rsnapshot since you find this software not maintainable, or

3) Remove it from Debian archive as you originally planned.

My personal thought is that some actions would be better than getting stuck
here, and I am also interested in the next step. At least I believe doing
nothing does not fall into the category of package maintenance.

Thanks,
Boyuan Yang


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

Bug#1003567: Please make a separate package for mistune 2.x

[Jerome Charaoui]

Le 2022-02-04 à 11 h 24, Nilesh Patra a écrit :

On 2/4/22 9:33 PM, Julian Gilbey wrote:

_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see 
/usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).

That seems like an eminently sensible solution to this problem.


But that'd lead to a number of mistune's embedded copies in a huge 
number of packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new 
version. When they do,

and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then 
all such packages would be

effected, and that honestly does not look like a good idea to me.


This is true, though there are only 7 reverse dependencies currently
in testing.


Yeah, in total the reverse-deps are 8 and there is one different 
reverse-build-dep (pasted at end of this mail)
But the problem is if these fall through the cracks, and close to the 
release we notice some

package is not looking nice.

Also, if you suppose that the upstreams are very slow, and we get to the 
new debian release with these things still

embedded, it'd be a real mess to upload fixes to stable, right...

I somehow do not understand the urgency of uploading this newer 
version, as the maintainer said:


| I intend to upload src:mistune 2.0.0 to unstable between March the
| 15th and April the 15th (depending on the progress of its
| reverse-dependencies).

We could simply wait a little more for the dust to settle, IMHO.


That would be a reasonable approach, but how long will it take for the
dust to settle?  With this major change, and no guidance from upstream
on how to migrate, and at least a number of upstream authors happy to
rely on setup.py having "mistune <1.0.0" in the install_requires
field, it might be several months or longer before things are fixed
upstream.
I think we could do this transition even a month or two before the soft 
freeze starts,
which is roughly an year from now (considering general trend timings of 
starting in feb in release year).

Situation might improve by then, I suppose.

If it does not, we could still go ahead with the older python3-mistune 
in the archive, I do not see
a huge problem there, except for maybe a few mistune uploads to stable 
if desired.



And what do we do when some packages have converted and
some haven't?


In such a case, we atleast will have a few examples to see how to go 
about doing the API changes the right way.
We could patch out at our end and send the changes upstream for review 
provided we are stuck in an unfortunate situation.


FWIW, there's a recent patch and PR for the lektor upstream which add 
mistune 2.x support, so for this particular project I don't think a 
separate package is necessary.


-- Jerome

Bug#1004975: gnome-shell: Feb 4 18:06:36 libinput error: client bug: timer event8 debounce short: scheduled expiry is in the past (-17ms), your system is too slow

[Tobias Koeck]

Package: gnome-shell
Version: 3.38.6-1~deb11u1
Severity: normal

Dear Maintainer,

I get frequently the following message in my /var/log/syslog

Feb  4 18:06:36 tron-nb gnome-shell[7388]: libinput error: client bug: timer 
event8 debounce short: scheduled expiry is in the past (-17ms), your system is 
too slow

It shows that the GUI won't react.

Greetings
Tobias

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

Kernel: Linux 5.16.0-trunk-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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 gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  evolution-data-server3.38.3-1
ii  gir1.2-accountsservice-1.0   0.6.55-3
ii  gir1.2-atspi-2.0 2.42.0-2~bpo11+1
ii  gir1.2-freedesktop   1.66.1-1+b1
ii  gir1.2-gcr-3 3.38.1-2
ii  gir1.2-gdesktopenums-3.0 3.38.0-2
ii  gir1.2-gdm-1.0   3.38.2.1-1
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gnomebluetooth-1.03.34.3-2
ii  gir1.2-gnomedesktop-3.0  3.38.5-3
ii  gir1.2-gstreamer-1.0 1.18.4-2.1
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-gweather-3.0  3.36.1-3
ii  gir1.2-ibus-1.0  1.5.23-2
ii  gir1.2-mutter-7  3.38.6-2~deb11u1
ii  gir1.2-nm-1.01.30.0-2
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-polkit-1.00.105-31+deb11u1
ii  gir1.2-rsvg-2.0  2.50.3+dfsg-1
ii  gir1.2-soup-2.4  2.72.0-2
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.66.2-1
ii  gnome-backgrounds3.38.0-1
ii  gnome-settings-daemon3.38.2-1
ii  gnome-shell-common   3.38.6-1~deb11u1
ii  gsettings-desktop-schemas3.38.0-2
ii  gstreamer1.0-pipewire0.3.19-4
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.33-1
ii  libcairo21.16.0-5
ii  libecal-2.0-13.38.3-1
ii  libedataserver-1.2-253.38.3-1
ii  libgcr-base-3-1  3.38.1-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libgirepository-1.0-11.66.1-1+b1
ii  libgjs0g 1.66.2-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.66.8-1
ii  libglib2.0-bin   2.66.8-1
ii  libgnome-autoar-0-0  0.2.4-3
ii  libgnome-desktop-3-193.38.5-3
ii  libgraphene-1.0-01.10.4+dfsg1-1
ii  libgtk-3-0   3.24.24-4
ii  libical3 3.0.9-2
ii  libjson-glib-1.0-0   1.6.2-1
ii  libmutter-7-03.38.6-2~deb11u1
ii  libnm0   1.30.0-2
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpolkit-agent-1-0  0.105-31+deb11u1
ii  libpolkit-gobject-1-00.105-31+deb11u1
ii  libpulse-mainloop-glib0  14.2-2
ii  libpulse014.2-2
ii  libsecret-1-00.20.4-2
ii  libsystemd0  250.3-2~bpo11+1
ii  libwayland-server0   1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxfixes3   1:5.0.3-2
ii  python3  3.9.2-3

Versions of packages gnome-shell recommends:
ii  bolt  0.9.1-1
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.38.2.1-1
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.38.4-1
ii  gnome-menus   3.36.0-1
ii  gnome-user-docs   3.38.2-1
ii  ibus  1.5.23-2
ii  

Bug#1004950: reprotest fails when using kk_KZ.RK1048 locale with java (locale not supported by java)

[Vagrant Cascadian]

On 2022-02-04, Fab Stz wrote:
> I have a CI job that runs reprotest. The project, at some time, makes calls to
> java. However this fails/crashes sometimes.
>
> By narrowing things down it always crashes when locale kk_KZ.RK1048 is in use.
>
> By searching further I discovered that kk_KZ.RK1048 locale/charset is not 
> supported by java [1]. Hence the crash:
>
> $ LC_ALL=kk_KZ.RK1048 java -version
> Error occurred during initialization of VM
> java.lang.IllegalArgumentException: Null charset name
> at java.nio.charset.Charset.lookup(java.base/Charset.java:455)
...
> $ LC_ALL=C java -version
> openjdk version "11.0.12" 2021-07-20
> OpenJDK Runtime Environment (build 11.0.12+7-post-Debian-2)
> OpenJDK 64-Bit Server VM (build 11.0.12+7-post-Debian-2, mixed mode, sharing)
>
>
> Expected behavior? That it works also with call to java? or maybe an option to
> disable this locale if java is used?
>
> [1]:
> https://docs.oracle.com/javase/8/docs/technotes/guides/intl/encoding.doc.html

Well, reprotest intentionally uses some obscure locales to find bugs
exactly like this...

That said, this points out two issues, and I'm considering making some
changes to locale handling for the "experiment" tests. Currently:

  loc = random.choice(['fr_CH.UTF-8', 'es_ES', 'ru_RU.CP1251', 'kk_KZ.RK1048', 
'zh_CN'])

I don't think selecting a locale at random is a good idea; this means
sometimes a build might succeed with reprotest and sometimes not,
depending on which locale happens to be randomly selected.

Secondly, I think by default reprotest should use a slightly less
obscure locale to test, and the same locale every time.

Adding a commandline flag to build with a specified locale would also be
good. Possibly another flag to do a series of builds, each with a
different locale (maybe from a list of very obscure locales).


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1004972: atd forgets to run a job in the queue

[Vincent Lefevre]

On 2022-02-04 17:27:37 +0100, Vincent Lefevre wrote:
> It seems to solve the bug, but this is surprising as these functions
> should be equivalent.
> 
> However, in my tests, atq showed:
> 
> 502 Mon Feb 14 23:00:00 2022 a vinc17
> 511 Fri Feb  4 17:10:00 2022 a vinc17
> 503 Tue Feb 15 09:00:00 2022 a vinc17
> 
> 512 Fri Feb  4 17:12:00 2022 a vinc17
> 502 Mon Feb 14 23:00:00 2022 a vinc17
> 503 Tue Feb 15 09:00:00 2022 a vinc17
> 
> 513 Fri Feb  4 17:24:00 2022 a vinc17
> 502 Mon Feb 14 23:00:00 2022 a vinc17
> 503 Tue Feb 15 09:00:00 2022 a vinc17
> 
> 514 Fri Feb  4 17:26:00 2022 a vinc17
> 502 Mon Feb 14 23:00:00 2022 a vinc17
> 503 Tue Feb 15 09:00:00 2022 a vinc17
> 
> i.e. in all these cases, the new job was not shown last by atq.
> I don't know whether this has an influence.

With the unpatched "at", for

522 Fri Feb  4 17:54:00 2022 a vinc17
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17

the job was taken into account. But for

523 Fri Feb  4 17:55:00 2022 a vinc17
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17

it isn't (and it is still in the queue at 18:01).

So it seems that there is some randomness in the reproducibility,
but with the patched "at" and many others tests to try to make
the new job appear at the end (which I couldn't succeed, but this
seems to be useless anyway), I couldn't reproduce the bug at all
(but why???).

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

Bug#1003567: Please make a separate package for mistune 2.x

[Pierre-Elliott Bécue]

Le 4 février 2022 16:57:59 GMT+01:00, Nilesh Patra  a écrit :
>On 2/4/22 9:18 PM, Julian Gilbey wrote:
>> Basically, the mistune upstream author has completely messed up on
>> this by making what is essentially a completely different package with
>> superficially similar functionality but the same name.
>
>True.
>  
>> [...]
>> _mistune.py within the Debian package,
>> and have nbconvert do "import nbconvert.filters._mistune as mistune"
>> (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
>> That seems like an eminently sensible solution to this problem.
>
>But that'd lead to a number of mistune's embedded copies in a huge number of 
>packages; since majority of
>the rev-deps (when I last checked) haven't adapted to this new version. When 
>they do,
>and it becomes a overhead to fix each one later.
>Even worse, if we discover a security problem sometime later, then all such 
>packages would be
>effected, and that honestly does not look like a good idea to me.
>
>I somehow do not understand the urgency of uploading this newer version, as 
>the maintainer said:
>
>| I intend to upload src:mistune 2.0.0 to unstable between March the
>| 15th and April the 15th (depending on the progress of its
>| reverse-dependencies).
>
>We could simply wait a little more for the dust to settle, IMHO.
>
>Regards,
>Nilesh
>

Because some packages I maintain depend on mistune 2.x and mistune 0.8.4 is, 
whether we like it or not, obsolete.

I can't really afford to wait for a year to try having mailman3 in testing 
again...
--
Pierre-Elliott Bécue
From my phone

Bug#1004972: atd forgets to run a job in the queue

[Vincent Lefevre]

On 2022-02-04 17:02:08 +0100, Vincent Lefevre wrote:
> Well, in the atd source, there are inconsistencies in the time
> functions. I can try to have a closer look and make a patch...

The attached patch solves an inconsistency by replacing a remaining
"time(NULL)" by "atd_gettime()". I suppose that this should have
been done in commit 6a3f0cd094717e098803f913e76a3499341cdaf3.

It seems to solve the bug, but this is surprising as these functions
should be equivalent.

However, in my tests, atq showed:

502 Mon Feb 14 23:00:00 2022 a vinc17
511 Fri Feb  4 17:10:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17

512 Fri Feb  4 17:12:00 2022 a vinc17
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17

513 Fri Feb  4 17:24:00 2022 a vinc17
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17

514 Fri Feb  4 17:26:00 2022 a vinc17
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17

i.e. in all these cases, the new job was not shown last by atq.
I don't know whether this has an influence.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Index: b/atd.c
===
--- a/atd.c
+++ b/atd.c
@@ -953,7 +953,7 @@ main(int argc, char *argv[])
 daemon_setup();
 
 do {
-	now = time(NULL);
+	now = atd_gettime();
 	next_invocation = run_loop();
 	if ((next_invocation > now) && (!hupped)) {
 	atd_setalarm(next_invocation);

Bug#1003567: Please make a separate package for mistune 2.x

[Nilesh Patra]

On 2/4/22 9:33 PM, Julian Gilbey wrote:

_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.


But that'd lead to a number of mistune's embedded copies in a huge number of 
packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new version. When 
they do,
and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then all such 
packages would be
effected, and that honestly does not look like a good idea to me.


This is true, though there are only 7 reverse dependencies currently
in testing.


Yeah, in total the reverse-deps are 8 and there is one different 
reverse-build-dep (pasted at end of this mail)
But the problem is if these fall through the cracks, and close to the release 
we notice some
package is not looking nice.

Also, if you suppose that the upstreams are very slow, and we get to the new 
debian release with these things still
embedded, it'd be a real mess to upload fixes to stable, right...
 

I somehow do not understand the urgency of uploading this newer version, as the 
maintainer said:

| I intend to upload src:mistune 2.0.0 to unstable between March the
| 15th and April the 15th (depending on the progress of its
| reverse-dependencies).

We could simply wait a little more for the dust to settle, IMHO.


That would be a reasonable approach, but how long will it take for the
dust to settle?  With this major change, and no guidance from upstream
on how to migrate, and at least a number of upstream authors happy to
rely on setup.py having "mistune <1.0.0" in the install_requires
field, it might be several months or longer before things are fixed
upstream.

I think we could do this transition even a month or two before the soft freeze 
starts,
which is roughly an year from now (considering general trend timings of 
starting in feb in release year).
Situation might improve by then, I suppose.

If it does not, we could still go ahead with the older python3-mistune in the 
archive, I do not see
a huge problem there, except for maybe a few mistune uploads to stable if 
desired.


And what do we do when some packages have converted and
some haven't?


In such a case, we atleast will have a few examples to see how to go about 
doing the API changes the right way.
We could patch out at our end and send the changes upstream for review provided 
we are stuck in an unfortunate situation.

Let me know what you'd think about this?

Regards,
Nilesh


Reverse-Depends
* giara [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x]
* iredis
* lektor
* lookatme
* matrix-mirage [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x]
* python3-flasgger
* python3-m2r
* python3-schema-salad

Reverse-Testsuite-Triggers
* markdown-it-py

Reverse-Build-Depends
* lektor
* lookatme
* markdown-it-py
* python-flasgger
* python-m2r
* python-schema-salad






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003567: Please make a separate package for mistune 2.x

[Nilesh Patra]

On 2/4/22 9:18 PM, Julian Gilbey wrote:

Basically, the mistune upstream author has completely messed up on
this by making what is essentially a completely different package with
superficially similar functionality but the same name.


True.
 

[...]
_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.


But that'd lead to a number of mistune's embedded copies in a huge number of 
packages; since majority of
the rev-deps (when I last checked) haven't adapted to this new version. When 
they do,
and it becomes a overhead to fix each one later.
Even worse, if we discover a security problem sometime later, then all such 
packages would be
effected, and that honestly does not look like a good idea to me.

I somehow do not understand the urgency of uploading this newer version, as the 
maintainer said:

| I intend to upload src:mistune 2.0.0 to unstable between March the
| 15th and April the 15th (depending on the progress of its
| reverse-dependencies).

We could simply wait a little more for the dust to settle, IMHO.

Regards,
Nilesh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#969188: RFP: duplicati -- user-friendly remote, encrypted, incremental backups; capable GUI via built-in local server

[Eriberto Mota]

In a very very very quick overview, this project seems to have several
files without source code or licensing, and some conflicting licenses.

Regards,

Eriberto

Bug#1003567: Please make a separate package for mistune 2.x

[Julian Gilbey]

On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote:
> On 2/4/22 9:18 PM, Julian Gilbey wrote:
> > Basically, the mistune upstream author has completely messed up on
> > this by making what is essentially a completely different package with
> > superficially similar functionality but the same name.
> 
> True.
> > [...]
> > _mistune.py within the Debian package,
> > and have nbconvert do "import nbconvert.filters._mistune as mistune"
> > (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
> > That seems like an eminently sensible solution to this problem.
> 
> But that'd lead to a number of mistune's embedded copies in a huge number of 
> packages; since majority of
> the rev-deps (when I last checked) haven't adapted to this new version. When 
> they do,
> and it becomes a overhead to fix each one later.
> Even worse, if we discover a security problem sometime later, then all such 
> packages would be
> effected, and that honestly does not look like a good idea to me.

This is true, though there are only 7 reverse dependencies currently
in testing.

> I somehow do not understand the urgency of uploading this newer version, as 
> the maintainer said:
> 
> | I intend to upload src:mistune 2.0.0 to unstable between March the
> | 15th and April the 15th (depending on the progress of its
> | reverse-dependencies).
> 
> We could simply wait a little more for the dust to settle, IMHO.

That would be a reasonable approach, but how long will it take for the
dust to settle?  With this major change, and no guidance from upstream
on how to migrate, and at least a number of upstream authors happy to
rely on setup.py having "mistune <1.0.0" in the install_requires
field, it might be several months or longer before things are fixed
upstream.  And what do we do when some packages have converted and
some haven't?

Best wishes,

   Julian

Bug#1004972: atd forgets to run a job in the queue

[Vincent Lefevre]

Well, in the atd source, there are inconsistencies in the time
functions. I can try to have a closer look and make a patch...

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

Bug#1004974: atftpd: Potential information leak in atftpd<0.7.5

[Johannes Krupp]

Package: atftpd
Version: 0.7.git20120829-3.3+deb11u1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: debian_f7b...@jkrupp.de, Debian Security Team 


Dear Maintainer,

   * What led up to the situation?
During a research project we have found a potential information leak in the 
atftpd daemon from package atftpd, where malformed requests can lead to a 
(partial) leak of the contents of /etc/group.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Sent the following (malformed) packet:
```
: 0001 006e 6574 6173 6369 6900 7473 697a  ...netascii.tsiz
0010: 6500 78  e.x
```

   * What was the outcome of this action?
A freshly started atfptd server replies with a packet containing contents of 
/etc/group
```
: 0006 7473 697a 6500 7831 3a0a 6269 6e3a  ..tsize.x1:.bin:
0010: 783a 323a 0a73 7973 3a78 3a33 3a0a 6164  x:2:.sys:x:3:.ad
0020: 6d3a 783a 343a 0a74 7479 3a78 3a35 3a0a  m:x:4:.tty:x:5:.
0030: 6469 736b 3a78 3a36 3a0a 6c70 3a78 3a37  disk:x:6:.lp:x:7
0040: 3a0a 6d61 696c 3a78 3a38 3a0a 6e65 7773  :.mail:x:8:.news
0050: 3a78 3a39 3a0a 7575 6370 3a78 3a31 303a  :x:9:.uucp:x:10:
0060: 0a6d 616e 3a78 3a31 323a 0a70 726f 7879  .man:x:12:.proxy
0070: 3a78 3a31 333a 0a6b 6d65 6d3a 783a 3135  :x:13:.kmem:x:15
0080: 3a0a 6469 616c 6f75 743a 783a 3230 3a0a  :.dialout:x:20:.
0090: 6661 783a 783a 3231 3a0a 766f 6963 653a  fax:x:21:.voice:
00a0: 783a 3232 3a0a 6364 726f 6d3a 783a 3234  x:22:.cdrom:x:24
00b0: 3a0a 666c 6f70 7079 3a78 3a32 353a 0a74  :.floppy:x:25:.t
00c0: 6170 653a 783a 3236 3a0a 7375 646f 3a78  ape:x:26:.sudo:x
00d0: 3a32 373a 0a61 7564 696f 3a78 3a32 393a  :27:.audio:x:29:
00e0: 0a64 6970 3a78 3a33 303a 0a77  2d64  .dip:x:30:.www-d
00f0: 6174 613a 783a  3a0a 6261 636b 7570  ata:x:33:.backup
0100: 3a78 3a33 343a 0a00  :x:34:..
```

   * What outcome did you expect instead?
No response or an error message from the server.

It appears that this bug has been fixed upstream (commit
9cf799c40738722001552618518279e9f0ef62e5), and the fix is already
included in atftpd version 0.7.git20210915-3 in debian testing).
Yet we were able to reproduce this behavior on debian stable/bullseye 
(atftpd version 0.7.git20120829-3.3+deb11u1) and debian oldstable/buster 
(atftpd version 0.7.git20120829-3.2~deb10u2).

Further, the issue appears to only occur when running atftpd in
standalone mode (--daemon, not via inetd), and only on the very first
request, as the buffer containing /etc/group data is overwritten by the
new request.

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

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

Versions of packages atftpd depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u2
ii  libpcre3   2:8.39-13
ii  libwrap0   7.6.q-31
ii  lsb-base   11.1.0
ii  tcpd   7.6.q-31
ii  update-inetd   4.51

Versions of packages atftpd recommends:
ii  rlinetd [inet-superserver]  0.9.3-1

Versions of packages atftpd suggests:
ii  logrotate  3.18.0-2

-- debconf information:
  atftpd/mcast_addr: 239.239.239.0-255
  atftpd/multicast: true
  atftpd/logfile: /var/log/atftpd.log
  atftpd/maxthread: 100
  atftpd/tftpd-timeout: 300
  atftpd/logtofile: false
  atftpd/tsize: true
  atftpd/ttl: 1
  atftpd/basedir: /srv/tftp
  atftpd/blksize: true
  atftpd/verbosity: 5 (LOG_NOTICE)
  atftpd/port: 69
  atftpd/mcast_port: 1758
  atftpd/use_inetd: true
  atftpd/retry-timeout: 5
  atftpd/timeout: true

Bug#993515: catch: FTBFS with glibc 2.34

[Drew Parsons]

Source: catch
Version: 1.12.1-1.1
Followup-For: Bug #993515
Control: tags -1 patch

Upstream prepared a patch for catch2, PR#2317
https://github.com/catchorg/Catch2/pull/2317

dolfin uses a vendored copy of the merged catch.hpp.  I prepared a
patch for it (attached), which could be adapted for the catch package.
Index: dolfin/test/unit/cpp/catch/catch.hpp
===
--- dolfin.orig/test/unit/cpp/catch/catch.hpp   2022-02-04 16:06:38.0 
+0100
+++ dolfin/test/unit/cpp/catch/catch.hpp2022-02-04 16:26:46.752782223 
+0100
@@ -6472,6 +6472,17 @@
 int id;
 const char* name;
 };
+
+// 32kb for the alternate stack seems to be sufficient. However, this value
+// is experimentally determines, so that's not guaranteed.
+#if defined(_SC_SIGSTKSZ_SOURCE) || defined(_GNU_SOURCE)
+// on glibc > 2.33 this is no longer constant, see
+// 
https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=85e84fe53699fe9e392edffa993612ce08b2954a;hb=HEAD
+static constexpr std::size_t sigStackSize = 32768;
+#else
+static constexpr std::size_t sigStackSize = 32768 >= MINSIGSTKSZ ? 32768 : 
MINSIGSTKSZ;
+#endif
+
 extern SignalDefs signalDefs[];
 SignalDefs signalDefs[] = {
 { SIGINT,  "SIGINT - Terminal interrupt signal" },
@@ -6487,7 +6498,7 @@
 static bool isSet;
 static struct sigaction oldSigActions 
[sizeof(signalDefs)/sizeof(SignalDefs)];
 static stack_t oldSigStack;
-static char altStackMem[SIGSTKSZ];
+static char altStackMem[sigStackSize];
 
 static void handleSignal( int sig ) {
 std::string name = "";
@@ -6507,7 +6518,7 @@
 isSet = true;
 stack_t sigStack;
 sigStack.ss_sp = altStackMem;
-sigStack.ss_size = SIGSTKSZ;
+sigStack.ss_size = sigStackSize;
 sigStack.ss_flags = 0;
 sigaltstack(, );
 struct sigaction sa = { 0 };
@@ -6538,7 +6549,7 @@
 bool FatalConditionHandler::isSet = false;
 struct sigaction 
FatalConditionHandler::oldSigActions[sizeof(signalDefs)/sizeof(SignalDefs)] = 
{};
 stack_t FatalConditionHandler::oldSigStack = {};
-char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
+char FatalConditionHandler::altStackMem[sigStackSize] = {};
 
 } // namespace Catch
 

Bug#1003567: Please make a separate package for mistune 2.x

[Julian Gilbey]

On Thu, Feb 03, 2022 at 11:34:26PM +0100, Pierre-Elliott Bécue wrote:
> Hi Michael,
> 
> > Since Mistune 2.0.0 regresses its support for standard markdown, I ask
> > that a separate package be made for mistune 2.x to give more time for 
> > mistune 0.8.x users to migrate to mistune 2.x or another library entirely.
> >
> > Cheers,
> 
> I'm not formally against it, but it's not really standard in my
> opinion. It'd lead to maintenance of two packages, probably on some long
> term (as it'd relieve the pressure to migrate for maintainers of
> reverse-deps of mistune).
> 
> Besides, having a source package named "mistune2" while upstream's
> package is named "mistune" adds also another layer of complexity.
> 
> I'd like to have some python team members' opinion on this, and I am not
> sure to be eager to do it as of now.

I agree that this sounds like a terrible idea.  What would the Python
module be called in a separate python3-mistune2 package be called?  If
it were called mistune, then python3-mistune2 would have to conflict
with python3-mistune (or "python3-mistune0.84" or similar), and there
would be little benefit.  If the module itself were renamed to
mistune2, then the Debian mistune package would be incompatible with
any other software requiring mistune.

Basically, the mistune upstream author has completely messed up on
this by making what is essentially a completely different package with
superficially similar functionality but the same name.

What the Debian nbconvert maintainers have done is to vendor mistune
0.8.4: they now include it as _mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.  Maybe
not ideal, but it will work until the upstream maintainers find a way
to work with mistune 2.0.x.

Best wishes,

   Julian

Bug#1004972: atd forgets to run a job in the queue

[Vincent Lefevre]

On 2022-02-04 16:31:17 +0100, Vincent Lefevre wrote:
> The job got run as soon as I submitted a new job. But again, this
> new job remained in the queue after the scheduled time. I'm wondering
> whether the cause is the existing jobs that are already in the queue,
> but scheduled later; there's possibly broken logic there.
> 
> This makes "at" completely unreliable.

This is a regression: downgrading to at 3.1.23-1.1 makes the
forgotten job run, and if I try again, I no longer get this
problem. But after upgrading again to at 3.2.4-2 and trying
again, the problem reappeared.

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

Bug#1004972: atd forgets to run a job in the queue

[Vincent Lefevre]

Control: severity -1 grave

The job got run as soon as I submitted a new job. But again, this
new job remained in the queue after the scheduled time. I'm wondering
whether the cause is the existing jobs that are already in the queue,
but scheduled later; there's possibly broken logic there.

This makes "at" completely unreliable.

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

Bug#1004973: can mingw-w64-tools be marked Multi-Arch: foreign?

[Helmut Grohne]

Package: mingw-w64-tools
Version: 8.0.0-1
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + fwupd-efi

fwupd-efi fails to cross build from source, because it gets an "Exec
format error" when running genpeimg. That suggests that mingw-w64-tools
maybe should be marked Multi-arch: foreign. Can you help me figure out
whether that is actually the right thing to do?

/usr/bin/i686-w64-mingw32-pkg-config
/usr/bin/i686-w64-mingw32-widl
/usr/bin/x86_64-w64-mingw32-pkg-config
/usr/bin/x86_64-w64-mingw32-widl

These are all triplet-prefixed. That qualifies them for Multi-Arch:
foreign.

/usr/bin/gendef
/usr/bin/genidl
/usr/bin/genpeimg
/usr/bin/mingw-genlib

These are not. I'm not into mingw. Can you tell me whether their
behaviour differs depending on which (Debian) architecture you run them
on? I suppose that since these all deal with windows files, they should
be fully independent of the (Debian) architecture these tools were built
for. Do you confirm?

If yes, please add "Multi-Arch: foreign" to this binary package.

Helmut

Bug#1004969: ITP: commandlines -- Python library for command line application development

[Johannes Schauer Marin Rodrigues]

Quoting Paulo Roberto Alves de Oliveira (aka kretcheu) (2022-02-04 15:34:44)
> * Package name: commandlines

Please don't call the source package "python-commandlines" or similar to
prevent polluting the global namespace with such a generic name.

signature.asc
Description: signature

Bug#1004965: -1: unknown option error from whiptail

[Joey Hess]

Colin Watson wrote:
> On Fri, Feb 04, 2022 at 09:24:25AM -0400, Joey Hess wrote:
> > -1: unknown option
> > debconf: whiptail output the above errors, giving up!
> 
> Hm, I *think* this can only happen if the height or width of the dialog
> computed by Debconf::FrontEnd::Dialog::showtext somehow ends up being
> negative, but I've never seen this happen.  How did you run into this?
> Do you have any idea how I might reproduce it?

Hmm, I know the height of the console was smaller than usual. My best
guess at dimensions were COLUMNS=55 LINES=11 or perhaps LINES=17

I'm not sure which package or template was involved, but I think it
involved checking the running kernel, or something like that, probably
in a trigger based on some other surrounding context I should have
included in the bug report but now only remember vaguely.

Sorry I don't have a clearer idea of how to reproduce it.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1004972: atd forgets to run a job in the queue

[Vincent Lefevre]

Package: at
Version: 3.2.4-2
Severity: important

At 14:01:50, I submitted a job to be run at 14:03 (thus more than
2 hours ago), but this job has not been run and it is still in the
queue:

$ atq
502 Mon Feb 14 23:00:00 2022 a vinc17
503 Tue Feb 15 09:00:00 2022 a vinc17
507 Fri Feb  4 14:03:00 2022 a vinc17

# ls -l /var/spool/cron/atjobs
total 24
-rwx-- 1 vinc17 daemon 7340 2022-01-26 10:44:09 a001f601a25048
-rwx-- 1 vinc17 daemon 7340 2022-01-26 10:44:16 a001f701a252a0
-rwx-- 1 vinc17 daemon 7287 2022-02-04 14:01:50 a001fb01a215ef

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages at depends on:
ii  libc6   2.33-5
ii  libpam-runtime  1.4.0-11
ii  libpam0g1.4.0-11
ii  libselinux1 3.3-1+b1
ii  lsb-base11.1.0

Versions of packages at recommends:
ii  postfix [mail-transport-agent]  3.6.4-1

at suggests no packages.

-- Configuration Files:
/etc/at.deny [Errno 13] Permission denied: '/etc/at.deny'

-- no debconf information

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

Bug#984897: Problems in a setup with two conflicting binary packages which share the same service name

[Santiago Garcia Mantinan]

Hi!

We had spoken about this problem and the possible fix and by that time, so
close to Bullseye release... it was not a good timing.

I guess now would be the right timing, before bookworm gets us again in a
bad timing situation again.

Do you need any more info on this?

Regards. 
-- 
Manty/BestiaTester -> http://manty.net

Bug#1004971: pythonpy: fix collections import under python 3.10+

[Andreas Hasenack]

Package: pythonpy
Version: 0.4.11b-3
Severity: normal

Dear Maintainer,

In python 3.10[1] deprecated aliases to Collections Abstract Base
Classes from the collections module have been removed. These imports
must be done from collections.abc.

This patch was provided by Daniel Franklin in a Launchpad bug comment[2]:
--- a/pythonpy/__main__.py
+++ b/pythonpy/__main__.py
@@ -13,7 +13,7 @@ signal(SIGPIPE,SIG_DFL)
 import argparse
 import json
 import re
-from collections import Iterable
+from collections.abc import Iterable

 try:
 from . import __version__


1. https://docs.python.org/3/whatsnew/3.10.html
2. https://bugs.launchpad.net/ubuntu/+source/pythonpy/+bug/1878935/comments/1

Bug#1004471: [Pkg-javascript-devel] Bug#1004471: Pending patch for terser-webpack-plugin in webpack 5 till a new upstream for node-terser is uploaded

[Jonas Smedegaard]

Hi Caleb,

Quoting Caleb Adepitan (2022-02-04 08:46:29)
> I just arrived at a working patch for terser-webpack-plugin to 
> circumvent breaking changes in node-terser 5 which is required by the 
> package. The available version of node-terser in debian is 4 which is 
> behind the terser package upstream.
> 
> This patch is an ad-hoc fix for the bug pending the node-terser 
> package is updated to a compatible version.

This _relates_ to NodeJS module terser, but is it most specifically tied 
to terser, webpack, or terser-webpack-plugin?

You post the above to bug#1004471 which is tied to Debian package 
node-terser, but your presented patch seems not for terser but for 
something else - webpack or terser-webpack-plugin.

Helpful if you can clarify further what fixes what (not only for what 
end goal).


 - 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#1004970: pcapy: builds for all python versions, but only tests default

[Graham Inggs]

Source: pcapy
Version: 0.11.5-1
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.10 python3-all-dev

Hi Maintainer

pcapy builds its extension for all Python versions, but only tests
against the default version.  This issue will become serious once
Python 3.10 becomes the default.

Regards
Graham

Bug#1004945: Please specify required version of Sphinx build-dep

[Dato Simó]

> I think >= 3.5 should be enough

It isn't. So we may as well go with bookworm's 4.3.

Thanks again!

-d

Bug#1004969: ITP: commandlines -- Python library for command line application development

[Paulo Roberto Alves de Oliveira (aka kretcheu)]

Package: wnpp
Severity: wishlist
Owner: "Paulo Roberto Alves de Oliveira (aka kretcheu)" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: commandlines
  Version : 0.4.1
  Upstream Author : Christopher Simpkins 
* URL : https://github.com/chrissimpkins/commandlines
* License : MIT/X
  Programming Lang: Python
  Description : Python library for command line application development

 Commandlines is a Python library for command line application development that
 supports command line argument parsing, command string validation testing, &
 application logic. It has no external dependencies and provides broad Python
 interpreter support for Python 2.6+, Python 3.3+, pypy, and pypy3.
 .
 The library supports application development with POSIX guideline compliant[*]
 command argument styles, the GNU argument style extensions to the POSIX
 guidelines (including long option syntax and variable position of options
 among arguments), and command suite style application arguments that include
 one or more sub-commands to the executable.

Bug#1004968:

[Andreas Hasenack]

Salsa PR at https://salsa.debian.org/med-team/sepp/-/merge_requests/1

Bug#1004965: -1: unknown option error from whiptail

[Colin Watson]

On Fri, Feb 04, 2022 at 09:24:25AM -0400, Joey Hess wrote:
> -1: unknown option
> debconf: whiptail output the above errors, giving up!

Hm, I *think* this can only happen if the height or width of the dialog
computed by Debconf::FrontEnd::Dialog::showtext somehow ends up being
negative, but I've never seen this happen.  How did you run into this?
Do you have any idea how I might reproduce it?

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1004968: sepp: py3.10 direct import of Mapping from collections does not work

[Andreas Hasenack]

Package: sepp
Version: 4.5.1+really4.5.1+dfsg-2
Severity: normal

Dear Maintainer,

Starting with python 3.10, directly importing Mapping from collections
does not work.

python 3.10[1] deprecated aliases to Collections Abstract Base Classes from
 the collections module have been removed. These imports must be done from
 collections.abc.

sepp does such an import in sepp/alignment.py, and I suggest the
following simple patch:
--- a/sepp/alignment.py
+++ b/sepp/alignment.py
@@ -26,7 +26,8 @@ import re

 from sepp.filemgr import open_with_intermediates

-from collections import Mapping
+
+from collections.abc import Mapping
 import copy
 from sepp import get_logger
 import io

I also filed an upstream bug at [2].

Cheers!


1. https://docs.python.org/3/whatsnew/3.10.html
2. https://github.com/smirarab/sepp/issues/117

Bug#968679: debci: self-service multipackage pinning does not work as documented

[Antonio Terceiro]

On Fri, Feb 04, 2022 at 01:25:32PM +0100, Drew Parsons wrote:
> On 2022-02-04 12:05, Antonio Terceiro wrote:
> > On Fri, Feb 04, 2022 at 01:02:58AM +0100, Drew Parsons wrote:
> ...
> > --add-apt-release=experimental is added twice to the autopkgtest
> > command line, and this generates warnings like
> > 
> > > W: Target Packages (non-free/binary-all/Packages) is configured
> > > multiple
> > > times in
> > > /etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1
> > > and
> > > /etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3
> > 
> > This is something that we need to fix, but doesn't the job work even
> > with those warnings?
> 
> 
> No, it gets marked as "tmpfail" and does not proceed.
> 
> e.g. 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pytest-mpi/18927884/log.gz
> at https://ci.debian.net/packages/p/pytest-mpi/unstable/amd64/
> 
> The error state is reported in the log as
> 
> autopkgtest [23:58:16]: ERROR: "sh -ec mkdir -p /etc/apt/preferences.d;
> PKGS=""; PKGS="$PKGS $(apt-cache showsrc pytest-mpi | awk '/^Package-List:/
> { show=1; next } (/^ / && show==1) { print $1; next } { show=0 }' |sort -u |
> tr '\n' ' ')"; printf "Package: $PKGS\nPin: release
> a=experimental\nPin-Priority: 995\n" >
> /etc/apt/preferences.d/autopkgtest-experimental; " failed with stderr "W:
> Target Sources (main/source/Sources) is configured multiple times in
> /etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:2 and
> /etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:4

ack. Indeed. I have a fix for this in git.


signature.asc
Description: PGP signature

Bug#1004967: mutt: sending a mail message with a newline character in subject yields garbage, possible header injection

[Vincent Lefevre]

Package: mutt
Version: 2.1.4-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/muttmua/mutt/-/issues/391
X-Debbugs-Cc: Debian Security Team 

When sending a mail message with a newline character (LF) in the
subject, one gets garbage.

For instance:

  echo test | mutt -s foo$'\n'bar $USER@localhost

One gets a mail with just "foo" in the subject and a body that starts
with "bar" and continues with some of the headers. I don't know how
this should be handled, but this shouldn't give garbage.

This can even be used to inject headers:

  echo test | mutt -s foo$'\n'Injected:\ bar $USER@localhost

Note: I don't think that the caller is required to sanitize the
subject. At least, this is not documented, so that this should not
be assumed.

-- Package-specific info:
Mutt 2.1.5+134 (92686e5d) vl-138565 (2022-02-02)
Copyright (C) 1996-2022 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 5.15.0-3-amd64 (x86_64)
ncurses: ncurses 6.3.20211021 (compiled with 6.3)
libidn: 1.38 (compiled with 1.38)

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-16' 
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-11 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib 
--enable-libphobos-checking=release --with-target-system-zlib=auto 
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet 
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 
--enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-11-PrvGcK/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-PrvGcK/gcc-11-11.2.0/debian/tmp-gcn/usr
 --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu 
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-16) 

Configure options: --prefix=/home/vinc17 --enable-debug --enable-pop 
--enable-imap --with-ssl --enable-compressed 
--with-exec-shell=/home/vinc17/bin/sh.screen --enable-gpgme 
--with-system-dotlock=/usr/bin/mutt_dotlock CC=gcc 'CFLAGS=-g -O3 -march=native 
-fsanitize=undefined -fno-sanitize-recover'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O3 -march=native 
-fsanitize=undefined -fno-sanitize-recover

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  -USE_SMTP  
+USE_SSL_OPENSSL  -USE_SSL_GNUTLS  -USE_SASL  -USE_GSASL  -USE_GSS  
+HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  -HAVE_LIBIDN2  +HAVE_GETSID  
-USE_HCACHE  
-USE_SIDEBAR  +USE_COMPRESSED  +USE_INOTIFY  
ISPELL="/usr/bin/ispell"
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/home/vinc17/share/mutt"
SYSCONFDIR="/home/vinc17/etc"
EXECSHELL="/home/vinc17/bin/sh.screen"
-MIXMASTER

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues

patch-20200424.vl.pretty_size.1
patch-20200505.vl.simplesearchkw.1
patch-20200424.pdmef.progress.vl.1
patch-20201129.vl.address_all_patt.1
patch-20201130.tamovl.sysdotlock.1

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked 

Bug#997933: me too

[Joey Hess]

Seeing this bug after upgrade. My imap server is dovecot.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1004965: -1: unknown option error from whiptail

[Joey Hess]

Package: debconf
Version: 1.5.79
Severity: normal

-1: unknown option
debconf: whiptail output the above errors, giving up!

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

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

Versions of packages debconf depends on:
ii  perl-base  5.32.1-6

Versions of packages debconf recommends:
ii  apt-utils 2.3.15
ii  debconf-i18n  1.5.79

Versions of packages debconf suggests:
pn  debconf-doc
pn  debconf-kde-helper 
pn  debconf-utils  
ii  libgtk3-perl   0.038-1
pn  libnet-ldap-perl   
ii  libterm-readline-gnu-perl  1.42-2
ii  perl   5.32.1-6
ii  whiptail   0.52.21-5+b1

-- debconf information excluded

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1004964: lbzip2: Current package (version 2.5-2.2) is empty besides /usr/share/doc folder. No binary.

[Marcus Jodorf]

Package: lbzip2
Version: 2.5-2.2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

current package is broken.
Executable is missing.

Best

Marcus Jodorf


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

Bug#968679: debci: self-service multipackage pinning does not work as documented

[Drew Parsons]

On 2022-02-04 12:05, Antonio Terceiro wrote:

On Fri, Feb 04, 2022 at 01:02:58AM +0100, Drew Parsons wrote:

...

--add-apt-release=experimental is added twice to the autopkgtest
command line, and this generates warnings like

W: Target Packages (non-free/binary-all/Packages) is configured 
multiple

times in
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 
and

/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3


This is something that we need to fix, but doesn't the job work even
with those warnings?



No, it gets marked as "tmpfail" and does not proceed.

e.g. 
https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pytest-mpi/18927884/log.gz

at https://ci.debian.net/packages/p/pytest-mpi/unstable/amd64/

The error state is reported in the log as

autopkgtest [23:58:16]: ERROR: "sh -ec mkdir -p /etc/apt/preferences.d; 
PKGS=""; PKGS="$PKGS $(apt-cache showsrc pytest-mpi | awk 
'/^Package-List:/ { show=1; next } (/^ / && show==1) { print $1; next } 
{ show=0 }' |sort -u | tr '\n' ' ')"; printf "Package: $PKGS\nPin: 
release a=experimental\nPin-Priority: 995\n" > 
/etc/apt/preferences.d/autopkgtest-experimental; " failed with stderr 
"W: Target Sources (main/source/Sources) is configured multiple times in 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:2 
and 
/etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:4

Bug#1004963: CVE-2020-21598 CVE-2020-21600 CVE-2020-21602

[Moritz Muehlenhoff]

Source: libde265
Version: 1.0.8-1
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2020-21602:
https://github.com/strukturag/libde265/issues/242

CVE-2020-21600:
https://github.com/strukturag/libde265/issues/243

CVE-2020-21598:
https://github.com/strukturag/libde265/issues/237

Bug#1004498:

[Thomas Koch]

see also this discussion:
https://lists.debian.org/debian-med/2022/02/msg9.html

Bug#1004962: protobuf-c: Please add debian/watch and autopkgtest

[Lukas Märdian]

Package: protobuf-c
Version: 1.3.3-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
X-Debbugs-Cc: sl...@ubuntu.com

Hello Robert,

in order to improve the maintainability of the protobuf-c package, you should
be adding a debian/watch file (to track new upstream versions) and an
autopkgtest in debian/tests/control.

In Ubuntu, the attached patch was applied to achieve the following:

  * Add d/watch and run the self tests as autopkgtest

Thanks for considering the patch.

Cheers,
  Lukas


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

Kernel: Linux 5.13.0-23-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru protobuf-c-1.3.3/debian/tests/control 
protobuf-c-1.3.3/debian/tests/control
--- protobuf-c-1.3.3/debian/tests/control   1970-01-01 01:00:00.0 
+0100
+++ protobuf-c-1.3.3/debian/tests/control   2022-02-04 12:27:42.0 
+0100
@@ -0,0 +1,3 @@
+Test-Command: dh_auto_configure; dh_auto_build; dh_auto_test
+Depends: @builddeps@
+Restrictions: allow-stderr
diff -Nru protobuf-c-1.3.3/debian/watch protobuf-c-1.3.3/debian/watch
--- protobuf-c-1.3.3/debian/watch   1970-01-01 01:00:00.0 +0100
+++ protobuf-c-1.3.3/debian/watch   2022-02-04 12:02:06.0 +0100
@@ -0,0 +1,3 @@
+version=4
+opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/-$1\.tar\.gz/ \
+  https://github.com/protobuf-c/protobuf-c/tags .*/v?(\d\S+)\.tar\.gz

Bug#941010: kdiff3: binary comparasion shows borked error dialog and then blocks

[MAG4 Piemonte]

Dear Maintainer, we can confirm the bug looks solved upgrading to Debian 11 
(that use kdiff3 1.8.5-1) ...
Regards!

Guido

Bug#774411: vyhrať ocenenie

[bank]

 Dostali ste list o svojom víťazstve, ktorý vás prevedie cez vašu
e-mailovú adresu 6,500 $?
1) Prevod z banky do banky.
2) Expresné doručenie ATM.

Bug#1004961: libwmf: please fix cross-test on i386

[Gianfranco Costamagna]

Source: libwmf
Version: 0.2.12-5
Tags:patch


Hello, calling pkg-config on "debian/tests/build" breaks cross-autopkgtesting. 
The following patch should properly fix the issue

diff -Nru libwmf-0.2.12/debian/changelog libwmf-0.2.12/debian/changelog
--- libwmf-0.2.12/debian/changelog  2022-01-25 09:16:35.0 +0100
+++ libwmf-0.2.12/debian/changelog  2022-02-04 12:07:59.0 +0100
@@ -1,3 +1,9 @@
+libwmf (0.2.12-5.1) unstable; urgency=medium
+
+  * Fix build on cross-autopkgtest-env (Closes: #-1)
+
+ -- Gianfranco Costamagna   Fri, 04 Feb 2022 
12:07:59 +0100
+
 libwmf (0.2.12-5) unstable; urgency=medium

   * Upload to unstable
diff -Nru libwmf-0.2.12/debian/tests/build libwmf-0.2.12/debian/tests/build
--- libwmf-0.2.12/debian/tests/build2022-01-25 09:16:35.0 +0100
+++ libwmf-0.2.12/debian/tests/build2022-02-04 12:07:57.0 +0100
@@ -35,6 +35,6 @@
 }
 EOF

-${CROSS_COMPILE}gcc -o wmf-api wmf-api.c $(pkg-config --cflags --libs libwmf)
+${CROSS_COMPILE}gcc -o wmf-api wmf-api.c $("${CROSS_COMPILE}pkg-config" 
--cflags --libs libwmf)
 test -x wmf-api
 echo "everything seems OK"

Bug#1004960: ITP: cmyt -- Matplotlib colormaps from the yt project

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
debian-as...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: cmyt
  Version : 1.0.4
  Upstream Author : Clement Robert
* URL : https://github.com/yt-project/cmyt
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Matplotlib colormaps from the yt project

cmyt integrates with matplotlib in a similar fashion to cmocean or cmasher

It is a new build dependency of the "yt" package. I will maintain it
within the Debian Python team. Salsa dir is

https://salsa.debian.org/python-team/packages/cmyt

Best regards

Ole

Bug#968679: debci: self-service multipackage pinning does not work as documented

[Antonio Terceiro]

On Fri, Feb 04, 2022 at 01:02:58AM +0100, Drew Parsons wrote:
> On 2022-02-02 19:21, Paul Gevers wrote:
> > > Followup-For: Bug #968679
> > > 
> > > This bug is still live.
> > > 
> > 
> > I just tried with:
> > 
> > src:pytest-mpi, src:python-sybil, experimental
> > 
> > and
> > 
> > src:pytest-mpi,src:python-sybil, experimental
> > 
> > Both worked.
> > 
> > Did you maybe miss this line on the page: """Note: each suite can be
> > only present once. please separate by line."""
> 
> 
> Well, no.  I even copied the lines you've given here, it's still
> failing to work, in the same way.
> Is it some kind of permissions configuration error, if it works for you and
> not for me?
> 
> This is the full debci output from the last attempt:
>
> autopkgtest [23:58:01]: starting date: 2022-02-03
> autopkgtest [23:58:01]: version 5.19
> autopkgtest [23:58:01]: host ci-worker13; command line: /usr/bin/autopkgtest
> --no-built-binaries '--setup-commands=echo '"'"'pytest-mpi
> unstable/amd64'"'"' > /var/tmp/debci.pkg 2>&1 || true'
> '--setup-commands=echo '"'"'Acquire::Retries "10";'"'"' >
> /etc/apt/apt.conf.d/75retry 2>&1 || true' --user debci --apt-upgrade
> --add-apt-release=experimental --pin-packages=experimental=src:pytest-mpi
> --add-apt-release=experimental --pin-packages=experimental=src:python-sybil
> --output-dir
> /tmp/tmp.K9p1hcSGlj/autopkgtest-incoming/unstable/amd64/p/pytest-mpi/18927884
> pytest-mpi -- lxc --sudo --name ci-034-e8032c86 autopkgtest-unstable-amd64
[...]

--add-apt-release=experimental is added twice to the autopkgtest
command line, and this generates warnings like

> W: Target Packages (non-free/binary-all/Packages) is configured multiple
> times in
> /etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:1 and
> /etc/apt/sources.list.d/autopkgtest-add-apt-release-experimental.list:3

This is something that we need to fix, but doesn't the job work even
with those warnings?


signature.asc
Description: PGP signature

Bug#1004956: graphviz: FTBFS: These bindings need PHP7

[Sebastiaan Couwenberg]

On Fri, 4 Feb 2022 10:41:23 + Niko Tyni  wrote:

Looking at the build history there, the PHP 8.1 transition seems to fit
the timeline.

It's actually swig that doesn't support PHP 8 yet, see:

 https://bugs.debian.org/1003479

Kind Regards,

Bas

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

Bug#1004959: ITP:php-dasprid-enum - PHP 7.1 enums

[Katharina Drexel]

Package: php-dasprid-enum

* Package name: php-dasprid-enum
  Upstream Author : Ben Scholzen 
* License : BSD-2-clause
  Description : PHP 7.1 enums
 It is a well known fact that PHP is missing a basic enum type, ignoring the
 rather incomplete SplEnum implementation which is only available as a PECL
 extension. There are also quite a few other userland enum implementations
 around, but all of them have one or another compromise. This library tries to
 close that gap as far as PHP allows it to.

Regards
Katharina

Bug#1004330: makes the package useless with PHP 8

[Francesco Potortì]

The most urgent thing now is to mark the current dokuwiki package and php8 as 
incompatible, so people don't keep falling here until a solution is out.

Bug#1004958: ITP: xraydb -- X-ray Reference Data

[Neil Williams]

Package: wnpp
Severity: wishlist
Owner: Neil Williams 
X-Debbugs-Cc: debian-de...@lists.debian.org, codeh...@debian.org

* Package name: xraydb
  Version : 4.4.7
  Upstream Author : Matthew Newville 
* URL : https://github.com/xraypy/XrayDB
* License : Public domain
  Programming Lang: Python
  Description : X-ray Reference Data

X-ray Reference Data in SQLite library, including a Python3
interface. The database contains data about the interactions
of X-rays with matter.

xraydb is needed as a build-dependency of xraylarch (ITP #949126)
xraydb will be maintained by the Debian PaN Maintainers
as part of the Debian Science Team.

Bug#1004957: RM: nodejs/experimental -- ROM; Preparing a transition for nodejs 14.19.0

[Jérémy Lal]

Package: ftp.debian.org
Severity: normal

Hi,

in experimental we have nodejs 16.13.2~dfsg-2, but it is blocked by icu 70.

The way forward (and also maybe a smoother transition) is to go with nodejs 
14.19.0.

However to prepare the transition i need to upload it to experimental.

Thank you for considering,

Jérémy

Bug#1003176: transition: perl 5.34

[Niko Tyni]

On Thu, Feb 03, 2022 at 09:49:28PM +0100, Sebastian Ramacher wrote:
> > On 2022-01-05 17:00:54 +, Niko Tyni wrote:
> > > we'd like a transition slot for Perl 5.34.
> ocaml is done, so please go ahead.

Thanks!

My last rebuilds found that graphviz has regressed and doesn't build
anymore (#1004956). Do we need to get that fixed first?

If not, I can hopefully upload 5.34 some time tomorrow (Saturday).
-- 
Niko

Bug#1004330: makes the package useless with PHP 8

[Francesco Potortì]

>I have a more or less working package of the most recent upstream
>release plus one or two patches at
>https://salsa.debian.org/abe/dokuwiki
>
>It runs in production on https://swissmk.ch/

I'd be happy to try it.  However after tweaking with the code I managed to have 
it almost working.  The only thing that I found not working  is generation and 
sending of email: the recipient is empty and the email bounces.  Snce this 
problem does not cause an error or warning for me to read in the logs, I have 
not found the culprit.

So I have enough incentives to try out a new version.  I am writing to you in 
private.

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#1004956: graphviz: FTBFS: These bindings need PHP7

[Niko Tyni]

Source: graphviz
Version: 2.42.2-5
Severity: serious
Tags: ftbfs sid bookworm
Control: block 1003176 with -1

This package fails to build from source on current sid, and apparently
testing as well.

Build logs can be found at

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/graphviz.html

Looking at the build history there, the PHP 8.1 transition seems to fit
the timeline.

Excerpt:

  gv_php.cpp:772:3: error: #error These bindings need PHP7 - to generate PHP5 
bindings use: SWIG < 4.0.0 and swig -php5
772 | # error These bindings need PHP7 - to generate PHP5 bindings use: 
SWIG < 4.0.0 and swig -php5
|   ^
  gv_php.cpp: In function 'int SWIG_ConvertPtr(zval*, void**, swig_type_info*, 
int)':
  gv_php.cpp:963:54: error: cannot convert 'zval*' {aka '_zval_struct*'} to 
'zend_object*' {aka '_zend_object*'} in argument passing
963 |   HashTable * ht = Z_OBJ_HT_P(z)->get_properties(z);
|  ^
|  |
|  zval* {aka 
_zval_struct*}
  gv_php.cpp: At global scope:
  gv_php.cpp:5405:2: error: 'ZEND_ARG_PASS_INFO' was not declared in this 
scope; did you mean 'ZEND_ARG_OBJ_INFO'?
 
-- 
Niko Tyni   nt...@debian.org

Bug#1004955: Wish: switch to new version of soundmodem

[Roland Schwarz]

Package: soundmodem
Version: 0.20-6

Please consider switching to my forked version of soundmodem available at:

https://gitlab.com/packetradio/soundmodem

I addressed the following issues:

* dependency on legacy gtk2, -> moved to gtk3
* missing systemd integration added
* improved 96 FSK mode

Best wishes, Roland

--
__
  _  _  | Roland Schwarz
 |_)(_  |
 | \__) | mailto:roland.schw...@blackspace.at
| http://www.blackspace.at


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004954: ITP:php-bacon-qr-code - QR Code generator

[Katharina Drexel]

Package: php-bacon-qr-code

* Package name: php-bacon-qr-code
  Upstream Author : Ben Scholzen 
* License : BSD-2-clause
  Description : QR Code generator
 BaconQrCode is a port of QR code portion of the ZXing library. It currently
 only features the encoder part, but could later receive the decoder part as
 well.

Regards
Katharina

Bug#1004953: emscripten: attempts internet communication during build

[Gianfranco Costamagna]

Source: emscripten
Version: 3.1.3~dfsg-2
Severity: serious

Hello, looks like a new test (test_sdl2_ttf) is trying to reach github during 
build

see 
https://launchpadlibrarian.net/583868498/buildlog_ubuntu-jammy-amd64.emscripten_3.1.3~dfsg-2ubuntu1_BUILDING.txt.gz



test_sdl2_mixer_wav (test_other.other) ... skipped 'requested to be skipped'
test_sdl2_linkable (test_other.other) ... skipped 'requested to be skipped'
test_sdl2_gfx_linkable (test_other.other) ... skipped 'requested to be skipped'
['--version'] 2.0.10
via emmake
ports:INFO: retrieving port: freetype from 
https://github.com/emscripten-ports/FreeType/archive/version_1.zip
['--cflags'] -s USE_SDL=2
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 169, in 
_new_conn
conn = connection.create_connection(
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 73, in 
create_connection
for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "/usr/lib/python3.10/socket.py", line 955, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 699, in 
urlopen
httplib_response = self._make_request(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 382, in 
_make_request
self._validate_conn(conn)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 1012, 
in _validate_conn
conn.connect()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 353, in 
connect
conn = self._new_conn()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 181, in 
_new_conn
raise NewConnectionError(
urllib3.exceptions.NewConnectionError: : Failed to establish a new connection: [Errno -2] Name or 
service not known

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 439, in send
resp = conn.urlopen(
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 755, in 
urlopen
retries = retries.increment(
  File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 574, in 
increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='github.com', port=443): 
Max retries exceeded with url: /emscripten-ports/FreeType/archive/version_1.zip 
(Caused by NewConnectionError(': Failed to establish a new connection: [Errno -2] Name or service 
not known'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/<>/emcc.py", line 3950, in 
sys.exit(main(sys.argv))
  File "/usr/lib/python3.10/contextlib.py", line 79, in inner
return func(*args, **kwds)
  File "/<>/emcc.py", line 3943, in main
ret = run(args)
  File "/<>/emcc.py", line 1145, in run
via emmake
linker_inputs = phase_compile_inputs(options, state, newargs, input_files)
  File "/usr/lib/python3.10/contextlib.py", line 79, in inner
return func(*args, **kwds)
  File "/<>/emcc.py", line 2672, in phase_compile_inputs
compile_source_file(i, input_file)
  File "/<>/emcc.py", line 2652, in compile_source_file
cmd = get_clang_command(input_file)
  File "/<>/emcc.py", line 2593, in get_clang_command
return get_compiler(src_file) + get_cflags(state.orig_args) + compile_args 
+ [src_file]
  File "/<>/emcc.py", line 898, in get_cflags
ports.add_cflags(cflags, settings)
  File "/<>/tools/ports/__init__.py", line 364, in add_cflags
port.get(Ports, settings, shared)
  File "/<>/tools/ports/freetype.py", line 19, in get
ports.fetch_project('freetype', 
'https://github.com/emscripten-ports/FreeType/archive/' + TAG + '.zip', 
'FreeType-' + TAG, sha512hash=HASH)
  File "/<>/tools/ports/__init__.py", line 258, in fetch_project
retrieve()
  File "/<>/tools/ports/__init__.py", line 213, in retrieve
response = requests.get(url)
  File "/usr/lib/python3/dist-packages/requests/api.py", line 76, in get
return request('get', url, params=params, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in send
r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='github.com', 
port=443): Max retries exceeded with url: