Bug#1012245: nvidia-graphics-drivers-tesla-470: fails on ppc64el due to transitive GPL symbol usage

[Paul Gevers]

Hi Andreas,

On 21-08-2022 01:44, Andreas Beckmann wrote:

On Mon, 8 Aug 2022 16:27:30 +0200 Andreas Beckmann  wrote:
On Sun, 26 Jun 2022 15:26:07 +0200 Andreas Beckmann  
wrote:

> I've temporarily disabled the autopkgtest on ppc64el.

That seems to be a kernel specific issue and appears to be fixed with 
Linux 5.19 in experimental (but is still reproducible in Linux 5.18).

Re-enabling the autopkgtests on ppc64el.


Can you ignore the autopkgtest "regression" on ppc64el and let the CVE 
fixes into testing?


Yes, but please disable the test again or detect the kernel version and 
skip the test (exit 77 with the skippable restriction) if it's too low 
and you're on ppc64el because...


Linux 5.19 seems to take longer getting into sid 


our hosts are running stable and we're using the lxc backend of 
autopkgtest. So you'll need to wait until a fixed kernel landed in 
stable(-security|-proposed-updates|).



than I expected ...

src:nvidia-graphics-drivers-tesla-470
src:nvidia-graphics-drivers-tesla-510
src:nvidia-graphics-drivers-tesla


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017817: emacs: new release seems to have funny ideas about byte-compiling process

[Liam Stitt]

Package: emacs
Version: 1:28.1+1-2
Severity: important
X-Debbugs-Cc: sti...@cuug.ab.ca

I haven't dug into the guts of the installation process to try and
identify what's happening as yet so this is an inference, but it seems
like the byte-compilation phase is tossing off (or equivalent to) a
"make -j" without any sort of awareness of the number of processors in a
system. I am observing hundreds of attempts to batch-compile in
parallel, and naturally my system starts thrashing badly and killing
processes. I imagine this should eventually finish, but I wouldn't
presume to guess how long it would take!

(Also a bit surprised this hasn't already been reported, and thus afraid
it's some quirk of my installation, but if not it's *got* to be biting
some other folks as least as badly.)


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

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

Versions of packages emacs depends on:
ih  emacs-gtk  1:28.1+1-2

emacs recommends no packages.

emacs suggests no packages.

-- no debconf information

Bug#1017816: golang-github-bsm-pool: Flaky test on i386, blocking other packages migration

[Shengjing Zhu]

Source: golang-github-bsm-pool
Version: 0.8.0-6
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: z...@debian.org

https://ci.debian.net/user/britney/jobs?package=golang-github-bsm-pool[]=testing[]=i386
https://ci.debian.net/packages/g/golang-github-bsm-pool/testing/i386/

The test is flaky on i386, and it blocks other packages migration to testing.

Bug#1005449: awl: FTBFS: TypeError: implode(): Argument #2 ($array) must be of type ?array, string given - in tests/myCalendarTest.php:61

[Logan Rosen]

Control: tags -1 patch

Hi,

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

  * d/p/fix-mycalendar-test.patch: Cherrypick upstream fix for failing
myCalendar test, fixing FTBFS on rebuild.

Thanks for considering the patch.

Logan
diff -Nru awl-0.62/debian/patches/fix-mycalendar-test.patch 
awl-0.62/debian/patches/fix-mycalendar-test.patch
--- awl-0.62/debian/patches/fix-mycalendar-test.patch   1969-12-31 
19:00:00.0 -0500
+++ awl-0.62/debian/patches/fix-mycalendar-test.patch   2022-08-20 
23:35:14.0 -0400
@@ -0,0 +1,13 @@
+diff --git a/tests/myCalendarTest.php b/tests/myCalendarTest.php
+index 
aa1795a027a57c36add737fa1474cb99658d0c9c..3d795147f234e298498e7444e54c386fb9df5ab3
 100644
+--- a/tests/myCalendarTest.php
 b/tests/myCalendarTest.php
+@@ -58,7 +58,7 @@ class myCalendarTest extends PHPUnit_Framework_TestCase {
+ 
+ $data = 
explode("\n",$this->getData('tests/data/0244-MOZ-POST-FB.test'));
+ 
+-$data = implode($data, "\r\n");
++$data = implode("\r\n", $data);
+ 
+ $mycalendar = new vCalendar($data);
+ //foreach($mycalendar->GetComponents() as $comp){
diff -Nru awl-0.62/debian/patches/series awl-0.62/debian/patches/series
--- awl-0.62/debian/patches/series  1969-12-31 19:00:00.0 -0500
+++ awl-0.62/debian/patches/series  2022-08-20 23:35:37.0 -0400
@@ -0,0 +1 @@
+fix-mycalendar-test.patch

Bug#1017804: status update

[Antoine Beaupré]

On 2022-08-20 16:52:15, Antoine Beaupré wrote:
> I have made some progress on the package and pushed what i have on
> salsa:
>
> https://salsa.debian.org/debian/pw
>
> upstream's makefile is a little... odd. the manpages are executable and
> it doesn't seem like we have a working PREFIX (manpages are in
> /share). but all stuff that's kind of easy to fix.

That has mostly been fixed. Next up is to do a cursory look at the
source code to ensure it's not just a total backdoor. Then up to
experimental, if I actually like what the thing does... I still have to
run this in prod! ;)

The base commit to audit is on salsa, it's:

commit 750414a11255d23771f833d12b487d753fcdd346 (origin/master, origin/HEAD, 
master)
Author: Kaz Kylheku 
Date:   Mon Jul 4 08:32:10 2022 -0700

Add LICENSE file.

a.

-- 
Conformity-the natural instinct to passively yield to that vague something
recognized as authority.
- Mark Twain


signature.asc
Description: PGP signature

Bug#1017684: tiledb-r: ftbfs on riscv64("undefined symbol: __atomic_compare_exchange_1")

[Bo YU]

Hi,
On Sat, Aug 20, 2022 at 06:22:17PM -0500, Dirk Eddelbuettel wrote:


On 19 August 2022 at 07:21, Bo YU wrote:
| Source: tiledb-r
| Version: 0.15.0-1
| Severity: normal
| Tags: ftbfs, patch
| User: debian-ri...@lists.debian.org
| Usertags: riscv64
| X-Debbugs-Cc: debian-ri...@lists.debian.org
|
| Dear Maintainer,
|
| The tiledb-r has a ftbfs on riscv64 due to missing -latomic explicitly
| after 0.13.0-1:
|
| https://buildd.debian.org/status/logs.php?pkg=tiledb-r=riscv64
|
| The full buildd log failed is here:
| 
https://buildd.debian.org/status/fetch.php?pkg=tiledb-r=riscv64=0.15.0-1=1660431861=0
|
| The patch attached is trying to fix issue as you suggested.
| And I'll check if there are other r-cran-* packages with similar problems 
also.

Ok I'll deal with it (and I am actually upstream for it so I can do it in a
local debian/patches file or upstream) -- the proper way is in configure.ac
conditional on the architecture.

So what is the proper architecture name for riscv64, and please remind me
what the best way to determine it is (uname -m ? Or uname -p ?  Or uname -i ?)


There is only usefully for $(uname -m) for riscv64 hadreware now.

vimer@unmatched:~/build/08/33_gridengine$ uname -m
riscv64
vimer@unmatched:~/build/08/33_gridengine$ uname -p
unknown
vimer@unmatched:~/build/08/33_gridengine$ uname -i
unknown

BTW, I saw the solution is ok also.

ifeq ($(DEB_HOST_ARCH),riscv64)
# do something
endif

Is it ok for our case?


Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org


--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1017815: RFS: rumur/2022.08.20-1 [RC] -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

* Package name : rumur
Version : 2022.08.20-1
Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
Section : devel

The source builds the following binary packages:

rumur - model checker for the Murphi language

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2022.08.20-1.dsc


Changes since the last upload:

rumur (2022.08.20-1) unstable; urgency=medium
.
* New upstream release.
.
* Fix sandbox failures due to getrandom. Closes: #1017199.

Regards,
Matt

Bug#785356: Interne Partnerschaft

[Dave E. Ramsden]

Ich habe einen Geschäftsvorschlag für Sie, der einen beträchtlichen Betrag wert 
ist (GBP 13,5 Mio.). Bei Interesse antworten Sie für weitere Details.
 
Geben Sie, wenn möglich, Ihr Interesse an Englisch an, um besser kommunizieren 
zu können.
 
Mit freundlichen Grüßen,
David Ramsden

Sekretärin: Chantal Salvi

Bug#1016963: u-boot: delay migration to testing to test more platforms

[Vagrant Cascadian]

On 2022-08-10, Vagrant Cascadian wrote:
> This bug is just to delay migration to testing while more platforms get
> tested. If you have a relevent board, please consider testing and
> reporting the status:
>
>   https://wiki.debian.org/U-boot/Status

Well, this turned out to be pretty troublesome. The pinebook-pro-rk3399
u-boot boots, but causes issues loading the rootfs from nvme or microsd.

the odroid-c2 crashes as soon as it tries to switch to the kernel.

So, problems on two out of four platforms that I've tried so far.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1012245: nvidia-graphics-drivers-tesla-470: fails on ppc64el due to transitive GPL symbol usage

[Andreas Beckmann]

Hi Paul,

On Mon, 8 Aug 2022 16:27:30 +0200 Andreas Beckmann  wrote:

On Sun, 26 Jun 2022 15:26:07 +0200 Andreas Beckmann  wrote:
> I've temporarily disabled the autopkgtest on ppc64el.

That seems to be a kernel specific issue and appears to be fixed with 
Linux 5.19 in experimental (but is still reproducible in Linux 5.18).

Re-enabling the autopkgtests on ppc64el.


Can you ignore the autopkgtest "regression" on ppc64el and let the CVE 
fixes into testing? Linux 5.19 seems to take longer getting into sid 
than I expected ...


src:nvidia-graphics-drivers-tesla-470
src:nvidia-graphics-drivers-tesla-510
src:nvidia-graphics-drivers-tesla

Thanks

Andreas

Bug#994712: isa-support: Please add arm6 for armel

[Jérémy Lal]

Source: isa-support
Version: 9
Followup-For: Bug #994712

Hi,

for FTP master eyes, yes nodejs is waiting that feature
and will bootstrap an armel upload as soon as made possible
by the new version of isa-support.

Thanks !


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

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

Bug#1017769: man-db: Uses setpriv which seems to be Linux-only

[Guillem Jover]

On Sat, 2022-08-20 at 00:44:17 +0100, Colin Watson wrote:
> On Sat, Aug 20, 2022 at 01:35:54AM +0200, Guillem Jover wrote:
> > The man-db package seems to have switched from start-stop-daemon to
> > setpriv, but the latter seems to be Linux-only. On a hurd-i386 box I
> > see the following now:
> > 
> >   Processing triggers for man-db (2.10.2-2) ...
> >   /var/lib/dpkg/info/man-db.postinst: 22: setpriv: not found
> 
> Bother.  Do you know of a portable replacement, or do I have to add a
> fallback to perl?  I was hoping to avoid the latter, especially since
> setpriv is clearly simpler.

I was checking man-db packaging history and it was not clear to me why
start-stop-daemon was switched to the perl code. I don't understand
why s-s-d would not be available during debootstrap (didn't fine a
commit with the change, as it seemed to be included as part of a merge
commit, and just the changelog entry)?

Thanks,
Guillem

Bug#1017684: tiledb-r: ftbfs on riscv64("undefined symbol: __atomic_compare_exchange_1")

[Dirk Eddelbuettel]

On 19 August 2022 at 07:21, Bo YU wrote:
| Source: tiledb-r
| Version: 0.15.0-1
| Severity: normal
| Tags: ftbfs, patch
| User: debian-ri...@lists.debian.org
| Usertags: riscv64
| X-Debbugs-Cc: debian-ri...@lists.debian.org
| 
| Dear Maintainer,
| 
| The tiledb-r has a ftbfs on riscv64 due to missing -latomic explicitly
| after 0.13.0-1:
| 
| https://buildd.debian.org/status/logs.php?pkg=tiledb-r=riscv64
| 
| The full buildd log failed is here:
| 
https://buildd.debian.org/status/fetch.php?pkg=tiledb-r=riscv64=0.15.0-1=1660431861=0
| 
| The patch attached is trying to fix issue as you suggested. 
| And I'll check if there are other r-cran-* packages with similar problems 
also.

Ok I'll deal with it (and I am actually upstream for it so I can do it in a
local debian/patches file or upstream) -- the proper way is in configure.ac
conditional on the architecture.

So what is the proper architecture name for riscv64, and please remind me
what the best way to determine it is (uname -m ? Or uname -p ?  Or uname -i ?)

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1017814: rtv: upgrade to tuir

[michel]

Package: rtv
Version: 1.27.0+dfsg-2
Severity: important
Tags: upstream
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,



rtv is abandoned and it has already an anoying small bug with loading links (it 
almost always needs a second try).

But, there's a fork, tuir https://gitlab.com/ajak/tuir
It's basically rtv with bug fixes. It works fine, the bug from above is gone.

Bug#939904: Temporary network disruption during upgrade

[Raphaël Halimi]

Le 21/08/2022 à 00:41, Luca Boccassi a écrit :

Yes I noticed the same thing when building images, this cross-device
check is a true annoyance and can't seem to find a workaround :-/


I can't find a solution, so unfortunately it looks like we have to
resort to maintainer scripts, which is awful but I can't think of
anything else:

https://salsa.debian.org/systemd-team/systemd/-/merge_requests/164


Sorry to annoy you again, but... Why not just leave /etc/resolv.conf 
alone ? After all, shouldn't it be the user's choice to link it against 
/run/systemd/resolve/stub-resolv.conf, /run/systemd/resolve/resolv.conf, 
or just manage it manually ?


Plus, it would solve both problems I mentioned before.

Regards,

--
Raphaël Halimi

Bug#1017784: reverse dependencies

[Luca Boccassi]

Control: tags -1 -moreinfo

On Sat, 20 Aug 2022 17:46:33 + (UTC) Thorsten Alteholz
 wrote:
> Control: tags -1 + moreinfo
> 
> Hi Adrian,
> 
> there are reverse dependencies that needs to be taken care of:
> 
> 
> Checking reverse dependencies...
> # Broken Build-Depends:
> collectd: libdpdk-dev
> openvswitch: libdpdk-dev (>= 21.11)
> uhd: libdpdk-dev (>= 20)
> 
> 
> This needs to be addressed first. Please remove the moreinfo tag once
that 
> is done.
> 
>    Thorsten

Hi,

There are no reverse dependencies using the armhf builds.

https://packages.debian.org/bookworm/libuhd4.2.0-dpdk
https://packages.debian.org/bookworm/openvswitch-switch-dpdk

-- 
Kind regards,
Luca Boccassi


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

Bug#1017646: scowl: Ship qtwebengine-dictionary binaries

[Don Armstrong]

On Thu, 18 Aug 2022, Soren Stoutner wrote:
> I thought about creating a separate source package for this, but it
> seems to make more sense to me to include this as separate binaries in
> the current scowl package. I am willing to submit a patch and assist
> with maintining it over time if you would like.

Yeah, this should definitely be a patch to produce the additional binary
packages [or potentially, the existing binary packages can produce the
combined dictionary files, depending on the relative sizes.]

Is there a naming convention for these packages already?

Thanks!
-- 
Don Armstrong  https://www.donarmstrong.com

Live and learn
or die and teach by example
 -- a softer world #625
http://www.asofterworld.com/index.php?id=625

Bug#939904: Temporary network disruption during upgrade

[Luca Boccassi]

On Sat, 20 Aug 2022 20:30:43 +0100 Luca Boccassi 
wrote:
> On Fri, 19 Aug 2022 08:58:03 +0200 Michael Prokop 
> wrote:
> > Hi,
> > 
> > * Luca Boccassi [Thu Aug 18, 2022 at 03:20:22PM +0100]:
> > > On Thu, 2022-08-18 at 16:07 +0200, Raphaël Halimi wrote:
> > 
> > > > And, last but not the least, I see that /etc/resolv.conf is now
> part of 
> > > > systemd-resolved files, which means that it would be deleted
when
> the 
> > > > systemd-resolved package is removed from the system. I think it
> would 
> > > > also deserve its own bug with some high priority
> > > 
> > > No, that's working as intended - you remove one resolver, you
need
> to
> > > install another one that provides it.
> > 
> > I just tested a few things, JFYI:
> > 
> > * When systemd-resolved is installed and gets removed, the
> >   file/symlink /etc/resolv.conf gets removed as well. Is that
really
> >   expected? (This is something e.g. the resolvconf doesn't do, you
> >   still end up with a /etc/resolv.conf being in-place then)
> > 
> > * Installation of the systemd-resolved package inside docker/podman
> >   fails hard for me (running on a Debian/bullseye host):
> > 
> > | Unpacking systemd-resolved (251.4-1) ...
> > | dpkg: error processing archive /var/cache/apt/archives/systemd-
> resolved_251.4-1_amd64.deb (--unpack):
> > |  unable to make backup link of './etc/resolv.conf' before
> installing new version: Invalid cross-device link
> > | Selecting previously unselected package libnss-resolve:amd64.
> > | Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ...
> > | Unpacking libnss-resolve:amd64 (251.4-1) ...
> > | Errors were encountered while processing:
> > |  /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb
> > | E: Sub-process /usr/bin/dpkg returned an error code (1)
> > 
> > (Didn't investigate further on this yet, seems to be related to the
> > way dpkg handles symlinks (as set up by dh_link in the systemd
> > packaging) and containers with overlay doesn't like that, though
> > installing systemd inside docker/podman containers used to work
fine
> > so far for me)
> > 
> > HTH && regards
> > -mika-
> 
> Yes I noticed the same thing when building images, this cross-device
> check is a true annoyance and can't seem to find a workaround :-/

I can't find a solution, so unfortunately it looks like we have to
resort to maintainer scripts, which is awful but I can't think of
anything else:

https://salsa.debian.org/systemd-team/systemd/-/merge_requests/164

-- 
Kind regards,
Luca Boccassi


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

Bug#1017578: gtk+3.0: build test failures with glib 2.73

[Simon McVittie]

Version: 3.24.34-2

On Wed, 17 Aug 2022 at 18:48:30 -0400, Jeremy Bicha wrote:
> As detected by autopkgtests, gtk+3.0 will fail its build tests with
> glib 2.73 (currently in experimental).

I'd forgotten that this had a bug number, but it should be fixed in today's
upload to unstable. Upstream:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4968

smcv

Bug#1017813: RM: opencolorio [all] -- NBS; sole binary-all package was dropped

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

opencolorio (2.1.2+dfsg1-1) experimental; urgency=medium
...
  * debian/:
- drop documentation binary package
...
 -- Matteo F. Vescovi   Thu, 11 Aug 2022 23:46:16 +0200

Bug#1017812: golang-github-sylabs-sif: autopkgtest regressions

[Steve Langasek]

Source: golang-github-sylabs-sif
Version: 2.3.1-3
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Dmitry,

golang-github-sylabs-sif 2.3.1-3 has been stuck in unstable for 129 days
because the autopkgtests fail in the new version of the package.  This is a
regression that makes the package unreleasable.

[...]
dh_auto_test --builddirectory=_build --buildsystem=golang
cd _build && go test -vet=off -v -p 64
package .: no Go files in 
/tmp/autopkgtest-lxc.5tl7_sga/downtmp/autopkgtest_tmp/_build
dh_auto_test: error: cd _build && go test -vet=off -v -p 64 returned exit code 1
[...]

(https://ci.debian.net/data/autopkgtest/unstable/amd64/g/golang-github-sylabs-sif/24947614/log.gz)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1017811: node-wikibase-cli: FTBFS without Internet access

[Steve Langasek]

Package: node-wikibase-cli
Version: 15.15.4-3
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Andrius,

In Ubuntu, node-wikibase-cli fails to build from source because dh_auto_test
runs a test suite at build time which requires Internet access, and the
Ubuntu build environment does not allow access to the Internet.

Debian packages should not fail to build when they are built offline.

The attached patch fixes the package to run the testsuite but ignore any
failures.  I've uploaded this patch to Ubuntu to fix the failure there.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru node-wikibase-cli-15.15.4/debian/rules 
node-wikibase-cli-15.15.4/debian/rules
--- node-wikibase-cli-15.15.4/debian/rules  2022-03-18 07:03:58.0 
-0700
+++ node-wikibase-cli-15.15.4/debian/rules  2022-08-20 15:01:12.0 
-0700
@@ -10,3 +10,7 @@
help2man wb --name 'command-line interface to Wikibase' --no-info > 
debian/wb.1
help2man wd --name 'command-line interface to Wikidata' --no-info > 
debian/wd.1
dh_installman
+
+override_dh_auto_test:
+   # ignore failures from testsuite which requires Internet access
+   dh_auto_test || true

Bug#1017766: podman: Failed to activate DNS. Missing dependency on golang-github-containernetworking-plugin-dnsname

[Michael Musenbrock]

On 20.08.22 22:11, Michael Musenbrock wrote:

On 20.08.22 20:01, Reinhard Tartler wrote:

 From the list of packages in your big report i see that the packages netavark 
and
aardvark-dns are absent. Does installing them work for your without
the golang-github-containernetworking-plugin-dnsname package?


netavarak was already installed, but aardvark-dns not. I uninstalled the
golang-github-containernetworking-plugin-dnsname and installed aardvark-dns.


I retried and checked 'podman info --format {{.Host.NetworkBackend}}', which 
still
reported 'cni'.

So I changed the containers.conf and specified netavark as network_backend in 
the
Network-section.

Afterwards 'podman info --format {{.Host.NetworkBackend}}' reported 'netavark'.

Now a dns-server is active in the network, but the other pods attached to the 
network
still can't be resolved. But this may be just some config issue. I will check.





# dpkg -l | grep -e aardvark-dns -e netavark -e
golang-github-containernetworking-plugin-dnsname
ii  aardvark-dns 1.0.3-1+b1
ii  netavark 1.0.3-3

Afterwards I got the DNS issue again.

The reason why I tried the golang package in the first place, was that I saw 
the following
message in a 'podman network ls'
 > WARN[] Error validating CNI config file
/home/michael/.config/cni/net.d/caba086a-7c97-46ba-87c2-f3cec00c71c2.conflist: 
[failed to
find plugin "dnsname" in path [/usr/local/libexec/cni /usr/libexec/cni 
/usr/local/lib/cni
/usr/lib/cni /opt/cni/bin]]

 >
 > One of the main major changes in podman 4 is the rust based networking 
stack. It should be
 > installed by default for new installations. Did this not happen or is this 
an upgrade
 > situation?

 From the installation history: I installed 4.1.1+ds1-2 first on this machine, 
and then did
the upgrade to 4.2.

Bug#1017810: linux-perf-5.10: perf report blocks ^Z

[наб]

Package: linux-perf-5.10
Version: 5.10.127-2
Severity: normal

Dear Maintainer,

perf report, when in the curses^WS-Lang(?!) UI, when pressing ^Z,
has the audacity to write
  > Press '?' for help on key bindings
in the status line.

Just how are you supposed to use this,
especially considering that it takes a good second to start up?

Best,
наб

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

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

Versions of packages linux-perf-5.10 depends on:
ii  libbabeltrace1  1.5.8-1+b3
ii  libc6   2.31-13+deb11u3
ii  libcap2 1:2.44-1
ii  libdw1  0.183-1
ii  libelf1 0.183-1
ii  liblzma55.2.5-2.1~deb11u1
ii  libnuma12.0.12-1+b1
ii  libopencsd0 0.14.4-1
ii  libperl5.32 5.32.1-4+deb11u2
ii  libpython3.93.9.2-1
ii  libslang2   2.3.2-5
ii  libunwind8  1.3.2-2
ii  perl5.32.1-4+deb11u2
ii  python3 3.9.2-3
ii  zlib1g  1:1.2.11.dfsg-2+deb11u1

Versions of packages linux-perf-5.10 recommends:
ii  linux-base  4.6

Versions of packages linux-perf-5.10 suggests:
ii  linux-doc-5.10  5.10.127-2

-- no debconf information


signature.asc
Description: PGP signature

Bug#983146: 983146 RFS: bung/3.2.6-3 [ITP] -- backup next generation

[Bastian Germann]

Am 20.08.22 um 04:39 schrieb Charles:
Regards "You should then export and install the .htm as documentation automatically", when and where do you want that 
automation to happen?


During the package build with libreoffice-common as Build-Dependency.

Bug#1006818: eye: (autopkgtest) failure on non-amd64

[Adrian Bunk]

Control: reassign -1 eye 19.0221.2026~ds-1
Control: retitle -1 eye fails to work on !amd64

On Sat, Mar 05, 2022 at 08:41:47PM +0100, Paul Gevers wrote:
> Source: eye
> Version: 19.0221.2026~ds-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fails-always
> 
> Dear maintainer(s),
> 
> You package has an autopkgtest, great. However, it fails on all
> architectures but amd64. Can you please investigate the situation and fix
> it?
>...
> #   Failed test 'bare command, stderr'
> #   at debian/tests/eye.pvm.t line 11.
> #   '/usr/bin/eye.pvm: 3: exec:
> /usr/lib/swi-prolog/bin/x86_64-linux/swipl: not found
>...

The autopkgtest caught that the package is not functional on !amd64:

(buster_arm64-dchroot)bunk@amdahl:/tmp$ eye.pvm 
/usr/bin/eye.pvm: 3: exec: /usr/lib/swi-prolog/bin/x86_64-linux/swipl: not found
(buster_arm64-dchroot)bunk@amdahl:/tmp$ 

Changing Architecture: from "all" to "any" might be a reasonable option.

cu
Adrian

Bug#1017796: magit-forge-el: FTBFS if apt does not have deb-src lines configured

[Matteo F. Vescovi]

Hi Steve!

On 2022-08-20 at 09:56 (-07), Steve Langasek wrote:
> Hi Matteo,

[...]

> This approach is also buggy, because it looks for the most recent
> version of the source package in the cache, when what you ACTUALLY
> want to know is the version of the binary package that has been
> installed as a build-dependency.

Good catch! Thanks a lot.
Mine was a simple hack to build the package but never meant to be the
final solution.

> The attached patch uses dpkg -l instead of apt-cache to query the
> installed system. I have uploaded this change to Ubuntu, where it has
> built successfully.

I've applied your patch to m-f-el package [1] but latest upload of Emacs
28 is in trouble these days and the build is failing at the moment.
Gonna test it again asap.

Cheers.


[1] 
https://salsa.debian.org/emacsen-team/magit-forge-el/-/commit/8bbc3326785d2759b347fda3fb8f561892871f16

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#1017808: ITP: zfp -- Fixed-Rate Compressed Floating-Point Arrays

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: zfp
  Version : 1.0.0
  Upstream Authors: Peter Lindstrom
  URL : https://github.com/LLNL/zfp
* License : BSD-3-clause
  Description : Fixed-Rate Compressed Floating-Point Arrays
 This is a compressed format for representing multidimensional 
floating-point
 and integer arrays.  zfp provides compressed-array classes that support 
high
 throughput read and write random access to individual array elements. 
zfp
 also supports serial and parallel (OpenMP and CUDA) compression of 
whole
 arrays, e.g., for applications that read and write large data sets to 
and

 from disk.

It has bindings for C, C++, Fortran, and Python, as well as a cli tool

Bug#853915:

[Gina]

Help bugs

g

Bug#1016187: collectd: diff for NMU version 5.12.0-9.1

[Bernd Zeimetz]

Hi,

thanks for your work, but I don't think that disabling -Werror is an
appropriate fix, especially as the issues are rather easy to fix.

I've uploaded -10 a few seconds ago.


Bernd

On Sat, 2022-08-20 at 22:22 +0300, Adrian Bunk wrote:
> Control: tags 1016187 + patch
> 
> Dear maintainer,
> 
> I've prepared an NMU for collectd (versioned as 5.12.0-9.1) and uploaded 
> it to DELAYED/2. Please feel free to tell me if I should cancel it.
> 
> cu
> Adrian

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#1017804: Acknowledgement (ITP: pw -- interactively filtered pipe watcher)

[Antoine Beaupré]

I have made some progress on the package and pushed what i have on
salsa:

https://salsa.debian.org/debian/pw

upstream's makefile is a little... odd. the manpages are executable and
it doesn't seem like we have a working PREFIX (manpages are in
/share). but all stuff that's kind of easy to fix.

a.
-- 
Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est
pas réfutable relève de la magie ou de la mystique.
- Karl Popper

Bug#1017804: Processed: ITP: pw -- interactively filtered pipe watcher

[Antoine Beaupré]

Control: reopen -1

Hmm... isn't it a little rude to close a bug report without notifying
the owner/author of why you did so?

Furthermore, I looked at #903814 the ITP which you claim to be the same
as this one, and it's not the same program. This is "pipewatch" and
#903814 is "password manager".

Obviously, maybe there's a namespace clash here, but is that supposed to
be resolved in the WNPP / BTS, even before any one of those packages is
packaged at all?

Furthermore, it looks like the password manager project is abandoned
now:

https://github.com/dashohoxha/pw

.. so I doubt we want that in the archive anyways.

On 2022-08-20 19:57:03, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> close 1017804
> Bug #1017804 [wnpp] ITP: pw -- interactively filtered pipe watcher
> Marked Bug as done
>> stop
> Stopping processing here.
>
> Please contact me if you need assistance.
> -- 
> 1017804: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017804
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#1017766: podman: Failed to activate DNS. Missing dependency on golang-github-containernetworking-plugin-dnsname

[Michael Musenbrock]

On 20.08.22 20:01, Reinhard Tartler wrote:

 From the list of packages in your big report i see that the packages netavark 
and
aardvark-dns are absent. Does installing them work for your without
the golang-github-containernetworking-plugin-dnsname package?


netavarak was already installed, but aardvark-dns not. I uninstalled the
golang-github-containernetworking-plugin-dnsname and installed aardvark-dns.


# dpkg -l | grep -e aardvark-dns -e netavark -e
golang-github-containernetworking-plugin-dnsname
ii  aardvark-dns 1.0.3-1+b1
ii  netavark 1.0.3-3

Afterwards I got the DNS issue again.

The reason why I tried the golang package in the first place, was that I saw 
the following
message in a 'podman network ls'
> WARN[] Error validating CNI config file
/home/michael/.config/cni/net.d/caba086a-7c97-46ba-87c2-f3cec00c71c2.conflist: 
[failed to
find plugin "dnsname" in path [/usr/local/libexec/cni /usr/libexec/cni 
/usr/local/lib/cni
/usr/lib/cni /opt/cni/bin]]

>
> One of the main major changes in podman 4 is the rust based networking stack. 
It should be
> installed by default for new installations. Did this not happen or is this an 
upgrade
> situation?

From the installation history: I installed 4.1.1+ds1-2 first on this machine, 
and then did
the upgrade to 4.2.

br m



-rt

On Fri, Aug 19, 2022, 23:39 Michael Musenbrock mailto:michael.musenbr...@gmx.at>> wrote:

Package: podman
Version: 4.2.0+ds1-3
Severity: important

Hi,

thanks for bringing up-to-date podman packages to Debian. This is really 
nice to have
those current version available.

With the latest version of the podman packages (4.2.0+ds1-3) dns resolution 
fails for
podman networks.

This could simply be resolved by installing
'golang-github-containernetworking-plugin-dnsname'. I think this should be 
installed
automatically via dependencies.

hth, keep up the nice work
regards Michael


-- System Information:
Debian Release: bookworm/sid
   APT prefers unstable
   APT policy: (504, 'unstable'), (503, 'testing'), (502, 'experimental'), 
(1,
'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages podman depends on:
ii  conmon                           2.1.3+ds1-1
ii  crun                             1.5+dfsg-1+b1
ii  golang-github-containers-common  0.49.1+ds1-1
ii  libc6                            2.34-4
ii  libdevmapper1.02.1               2:1.02.185-1
ii  libgpgme11                       1.17.1-4
ii  libseccomp2                      2.5.4-1+b1
ii  runc                             1.1.3+ds1-7
ii  systemd [systemd-tmpfiles]       251.4-1

Versions of packages podman recommends:
ii  buildah            1.27.0+ds1-5
ii  catatonit          0.1.7-1
ii  dbus-user-session  1.14.0-2
ii  fuse-overlayfs     1.9-1
ii  slirp4netns        1.2.0-1
ii  tini               0.19.0-1
ii  uidmap             1:4.11.1+dfsg1-2

Versions of packages podman suggests:
ii  containers-storage  1.42.0+ds1-1
ii  docker-compose      1.29.2-1
ii  iptables            1.8.8-1

-- no debconf information

Bug#1017807: python-amply: broken link to homepage in debian/control

[Daniele Forsi]

Source: python-amply
Version: 0.1.4-2
Severity: minor
X-Debbugs-Cc: dfo...@gmail.com

Dear maintainer,

the address https://github.com/willu47/python-amply set in debian/control 
returns error 404

it seems that the working address is without the word "python": 
https://github.com/willu47/amply

thanks,
Daniele

Bug#1001661: notcurses: flaky autopkgtests on armhf

[Adrian Bunk]

On Wed, Mar 16, 2022 at 10:48:23PM +0100, Paul Gevers wrote:
>...
> All timeout after 2:47 hours.

There are no reports of runtime issues.

There do not seem to be any FTBFS issues due to it:
https://tests.reproducible-builds.org/debian/history/notcurses.html

A package with a flaky autopkgtest is worse than
a package without an autopkgtest.

Not having working and used software in the next stable is also worse 
than disabling the autopkgtest.

One possible mitigation would be to disable the autopkgtest until the 
issue has been fixed.

> Paul

cu
Adrian

Bug#1013540: sklearn-pandas: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.10" returned exit code 13

[Steve Langasek]

Package: sklearn-pandas
Followup-For: Bug #1013540
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Hi Federico,

Please find attached a patch that fixes this build failure, which is just a
minor matter of a class name having changed.

I have uploaded this change to Ubuntu to fix the build failure there.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru sklearn-pandas-2.2.0/debian/patches/scipy-test.patch 
sklearn-pandas-2.2.0/debian/patches/scipy-test.patch
--- sklearn-pandas-2.2.0/debian/patches/scipy-test.patch1969-12-31 
16:00:00.0 -0800
+++ sklearn-pandas-2.2.0/debian/patches/scipy-test.patch2022-08-20 
12:29:25.0 -0700
@@ -0,0 +1,20 @@
+Description: fix tests for current scipy
+ scipy has made changes to its class hierarchy, update the tests to match
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/1013540
+Last-Update: 2022-08-20
+Forwarded: no
+
+Index: sklearn-pandas-2.2.0/README.rst
+===
+--- sklearn-pandas-2.2.0.orig/README.rst
 sklearn-pandas-2.2.0/README.rst
+@@ -473,7 +473,7 @@
+ ... ('pet', CountVectorizer()),
+ ... ], sparse=True)
+ >>> type(mapper5.fit_transform(data))
+-
++
+ 
+ The stacking of the sparse features is done without ever densifying them.
+ 
diff -Nru sklearn-pandas-2.2.0/debian/patches/series 
sklearn-pandas-2.2.0/debian/patches/series
--- sklearn-pandas-2.2.0/debian/patches/series  1969-12-31 16:00:00.0 
-0800
+++ sklearn-pandas-2.2.0/debian/patches/series  2022-08-20 12:27:22.0 
-0700
@@ -0,0 +1 @@
+scipy-test.patch

Bug#939904: Temporary network disruption during upgrade

[Luca Boccassi]

On Fri, 19 Aug 2022 08:58:03 +0200 Michael Prokop 
wrote:
> Hi,
> 
> * Luca Boccassi [Thu Aug 18, 2022 at 03:20:22PM +0100]:
> > On Thu, 2022-08-18 at 16:07 +0200, Raphaël Halimi wrote:
> 
> > > And, last but not the least, I see that /etc/resolv.conf is now
part of 
> > > systemd-resolved files, which means that it would be deleted when
the 
> > > systemd-resolved package is removed from the system. I think it
would 
> > > also deserve its own bug with some high priority
> > 
> > No, that's working as intended - you remove one resolver, you need
to
> > install another one that provides it.
> 
> I just tested a few things, JFYI:
> 
> * When systemd-resolved is installed and gets removed, the
>   file/symlink /etc/resolv.conf gets removed as well. Is that really
>   expected? (This is something e.g. the resolvconf doesn't do, you
>   still end up with a /etc/resolv.conf being in-place then)
> 
> * Installation of the systemd-resolved package inside docker/podman
>   fails hard for me (running on a Debian/bullseye host):
> 
> | Unpacking systemd-resolved (251.4-1) ...
> | dpkg: error processing archive /var/cache/apt/archives/systemd-
resolved_251.4-1_amd64.deb (--unpack):
> |  unable to make backup link of './etc/resolv.conf' before
installing new version: Invalid cross-device link
> | Selecting previously unselected package libnss-resolve:amd64.
> | Preparing to unpack .../libnss-resolve_251.4-1_amd64.deb ...
> | Unpacking libnss-resolve:amd64 (251.4-1) ...
> | Errors were encountered while processing:
> |  /var/cache/apt/archives/systemd-resolved_251.4-1_amd64.deb
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> (Didn't investigate further on this yet, seems to be related to the
> way dpkg handles symlinks (as set up by dh_link in the systemd
> packaging) and containers with overlay doesn't like that, though
> installing systemd inside docker/podman containers used to work fine
> so far for me)
> 
> HTH && regards
> -mika-

Yes I noticed the same thing when building images, this cross-device
check is a true annoyance and can't seem to find a workaround :-/

-- 
Kind regards,
Luca Boccassi


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

Bug#1017805: RFP: viddy -- modern watch command. Time machine and pager

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org

* Package name: viddy
  Version : 0.3.6
  Upstream Author : https://github.com/sachaos
* URL : https://github.com/sachaos/viddy
* License : MIT
  Programming Lang: Golang
  Description : modern watch command. Time machine and pager

 * Basic features of original watch command.
 * Execute command periodically, and display the result.
 * color output.
 * diff highlight.
 * Time machine mode. sunglasses
   * Rewind like video.
   * Go to the past, and back to the future.
 * See output in pager.
 * Vim like keymaps.
 * Search text.
 * Suspend and restart execution.
 * Run command in precise intervals forcibly.
 * Support shell alias
 * Customize keymappings.
 * Customize color.



I just filed a request about pw mentioning this package, so I might as
well document it here. I understand we don't want to package the
entire universe just because it exists, but I've had a few colleagues
just "uh" and "ah" seeing this one, so I am betting someone
will be interested enough in this package to want it in Debian.

Obviously, a similar package to this is the watch command... I also
just filed an ITP for pw ("pipe watcher", #1017804) that is somewhat
similar, but IMHO more powerful.

Bug#1016187: collectd: diff for NMU version 5.12.0-9.1

[Adrian Bunk]

Control: tags 1016187 + patch

Dear maintainer,

I've prepared an NMU for collectd (versioned as 5.12.0-9.1) and uploaded 
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru collectd-5.12.0/debian/changelog collectd-5.12.0/debian/changelog
--- collectd-5.12.0/debian/changelog	2022-02-22 02:17:43.0 +0200
+++ collectd-5.12.0/debian/changelog	2022-08-20 22:15:33.0 +0300
@@ -1,3 +1,10 @@
+collectd (5.12.0-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't build with -Werror. (Closes: #1016187)
+
+ -- Adrian Bunk   Sat, 20 Aug 2022 22:15:33 +0300
+
 collectd (5.12.0-9) unstable; urgency=medium
 
   * [577cd1f] Don't build mysql plugin on kfreebsd*
diff -Nru collectd-5.12.0/debian/rules collectd-5.12.0/debian/rules
--- collectd-5.12.0/debian/rules	2022-02-22 02:17:43.0 +0200
+++ collectd-5.12.0/debian/rules	2022-08-20 22:15:29.0 +0300
@@ -63,6 +63,7 @@
 			--without-libstatgrab \
 			--disable-static \
 			--disable-silent-rules \
+			--disable-werror \
 			--enable-all-plugins
 
 # disable tokyotyrant (#980331)

Bug#1017804: ITP: pw -- interactively filtered pipe watcher

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pw
  Version : 2
  Upstream Author : Kaz Kylheku
* URL : https://www.kylheku.com/cgit/pw/
* License : BSD-2
  Programming Lang: C
  Description : interactively filtered pipe watcher

pw can monitor anything that produces textual output. tail -f
/var/logfile, tcpdump, strace, ...

pw does not show you everything. Of course, it reads all the data, but
it does that in the background. It continuously pumps lines of input
through a small FIFO buffer. This buffer is sampled, and the sample is
displayed. When that sampling occurs is controlled in various
interactive ways. What goes into the FIFO can be filtered and the
filters can be edited interactively.

With pw you can:

 * Interactively apply and remove filters on-the-fly, without
   interrupting the source.

 * Make recurring patterns in the stream appear to "freeze" on the
   screen, using triggers.

 * Prevent the overwhelming amount of output from a program from
   flooding the terminal, while consuming all of that output so that
   the program isn't blocked. pw can pause its display updates
   entirely.

 * Juggle multiple shell background jobs that produce output, yet
   execute indefinitely without blocking. When pw runs as part of a
   shell background job, it continues to consume input, process
   filters and take snapshots, without displaying anything. When put
   into the foreground again, display resumes.

For instance the command "tcpdump -i  -l | pw" turns
tcpdump into an interactive network monitoring tool in which you can
use the dynamic filtering in pw to select different kinds of packets,
and use the trigger feature to capture certain patterns of
interaction.

pw is like an oscilloscope for text streams. Digital oscilloscopes
sample the signal and pass it through a fifo, which is sampled to the
oscilloscope screen, and can trigger the sampling on certain
conditions in the signal to make waveforms appear to stand still. pw
does something like that for text streams.



I am rather intrigued by this program. It's the sort of "swiss army
knife" kind of tool that kind of makes no sense until you find a
purpose for it. I've been trying to figure out where this tool fits in
my toolbox and, just today, I was trying to find out what this silly
Purism Librem firmware upgrade tool was doing in the background, with
`ps axfu`. But I was having all this garbage out there, and it was
hard to filter things out properly. I might have been able to pull
something out with `watch`, but I think pw might have been better for
this particular case. I'm also quite interested in using it to analyse
logs or packet dumps during attacks or outages.

Another similarly named package, already in Debian (and maintained by
yours truly) is `pv`, the "pipe viewer". But it has a completely
different function; whereas pw shows you the content of the pipe in a
specific way, pv just counts lines or bytes going through it,
specifically without showing you its content.

There is another tool similar to "watch" that overlaps with this a
little bit:

https://github.com/sachaos/viddy

... it's basically the "watch" command with history. It supports
searching (which pw does, and probably better) and going back in
history (which pw does not). I had a hard time finding that package
name again, for what that's worth...

I suspect I could also forget the name `pw` quite quickly, but by
packaging it, I guess I'm more confident I will forget it less. :p
Probably the worst reason to package something ever, but there you go,
that's how I ended up maintaining pv in the first place, so probably
that means.. uh... something good something.

Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO

[Leandro Cunha]

Hi.

Had the same problem with me and I don't see a good idea to send
release candidate versions to sid/testing but to experimental. There
are a lot of people who use sid/testing on a daily basis.
With the graphics card NVidia GT310 using the Nouveau.
But it was good to catch the problem before launch.

-- 
Cheers,
Leandro Cunha

Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11

[Paul Gevers]

Hi,

On 20-08-2022 13:44, Guillem Jover wrote:

The liburing test suite works on the buildds, I just uploaded a new
release and it built fine locally with Linux 5.19.0-trunk-amd64, and
on the buildds. I think this needs to be reassigned, I'd assume to the
kernel (but I'm not entirely sure).


I'd say, go ahead.


Also could a newer kernel be tried on the infra?


If it's in a reasonable archive and the version sorting is such that 
it's below the next stable or security update version, yes. But I don't 
want to deviate from the stable (security) archive longer than needed.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017784: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Adrian,

there are reverse dependencies that needs to be taken care of:


Checking reverse dependencies...
# Broken Build-Depends:
collectd: libdpdk-dev
openvswitch: libdpdk-dev (>= 21.11)
uhd: libdpdk-dev (>= 20)


This needs to be addressed first. Please remove the moreinfo tag once that 
is done.


  Thorsten

Bug#1004511: vcmi

[Thorsten Alteholz]

Hi Paul,

as far as I see only vcmi still has a dependency on libluajit-5.1-dev on 
ppc64el. Do you agree?


  Thorsten

Bug#1017803: adwaita-qt: FTBFS when built with -O3 (symbols mismatches)

[Steve Langasek]

Package: adwaita-qt
Version: 1.4.1-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Dmitry,

In Ubuntu, adwaita-qt has been failing to build from source on ppc64el
because the Ubuntu ppc64el port builds with -O3 by default, which results in
some rearrangement of optional symbols that are not part of the library ABI.

The attached patch lets the package build on all architectures.

Please consider including in Debian.
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru adwaita-qt-1.4.1/debian/libadwaitaqt1.symbols 
adwaita-qt-1.4.1/debian/libadwaitaqt1.symbols
--- adwaita-qt-1.4.1/debian/libadwaitaqt1.symbols   2022-04-21 
03:46:00.0 -0700
+++ adwaita-qt-1.4.1/debian/libadwaitaqt1.symbols   2022-08-20 
10:28:06.0 -0700
@@ -4,6 +4,8 @@
  _Z25qInitResources_stylesheetv@Base 1.4.0
  _Z28qCleanupResources_stylesheetv@Base 1.4.0
  _Z7ADWAITAv@Base 1.4.0
+ (optional=inline)_ZN10QByteArrayD1Ev@Base 1.4.1
+ (optional=inline)_ZN10QByteArrayD2Ev@Base 1.4.1
  _ZN11QStringListD1Ev@Base 1.1.90
  _ZN11QStringListD2Ev@Base 1.1.90
  
(optional=templinst)_ZN4QMapIN7Adwaita12ColorVariantE6QColorE6insertERKS1_RKS2_@Base
 1.4.0
@@ -12,12 +14,18 @@
  
(optional=templinst)_ZN5QHashI7QString4QMapIN7Adwaita12ColorVariantE6QColorEE11deleteNode2EPN9QHashData4NodeE@Base
 1.4.0
  
(optional=templinst)_ZN5QHashI7QString4QMapIN7Adwaita12ColorVariantE6QColorEE13duplicateNodeEPN9QHashData4NodeEPv@Base
 1.4.0
  
(optional=templinst)_ZN5QHashI7QString4QMapIN7Adwaita12ColorVariantE6QColorEE6insertERKS0_RKS5_@Base
 1.4.0
+ 
(optional=inline)_ZN5QHashI7QString4QMapIN7Adwaita12ColorVariantE6QColorEED1Ev@Base
 1.4.1
+ 
(optional=inline)_ZN5QHashI7QString4QMapIN7Adwaita12ColorVariantE6QColorEED2Ev@Base
 1.4.1
  
(optional=templinst)_ZN5QHashIN7Adwaita12ColorVariantE6QColorE11deleteNode2EPN9QHashData4NodeE@Base
 1.4.0
  
(optional=templinst)_ZN5QHashIN7Adwaita12ColorVariantE6QColorE13detach_helperEv@Base
 1.4.0
  
(optional=templinst)_ZN5QHashIN7Adwaita12ColorVariantE6QColorE13duplicateNodeEPN9QHashData4NodeEPv@Base
 1.4.0
+ (optional=inline)_ZN5QHashIN7Adwaita12ColorVariantE6QColorED1Ev@Base 1.4.1
+ (optional=inline)_ZN5QHashIN7Adwaita12ColorVariantE6QColorED2Ev@Base 1.4.1
  
(optional=templinst)_ZN5QHashIN7Adwaita13ColorsPrivate12AdwaitaColorES_INS0_12ColorVariantE6QColorEE11deleteNode2EPN9QHashData4NodeE@Base
 1.4.0
  
(optional=templinst)_ZN5QHashIN7Adwaita13ColorsPrivate12AdwaitaColorES_INS0_12ColorVariantE6QColorEE13duplicateNodeEPN9QHashData4NodeEPv@Base
 1.4.0
  
(optional=templinst)_ZN5QHashIN7Adwaita13ColorsPrivate12AdwaitaColorES_INS0_12ColorVariantE6QColorEE6insertERKS2_RKS5_@Base
 1.4.0
+ 
(optional=inline)_ZN5QHashIN7Adwaita13ColorsPrivate12AdwaitaColorES_INS0_12ColorVariantE6QColorEED1Ev@Base
 1.4.1
+ 
(optional=inline)_ZN5QHashIN7Adwaita13ColorsPrivate12AdwaitaColorES_INS0_12ColorVariantE6QColorEED2Ev@Base
 1.4.1
  (optional=templinst)_ZN5QListI7QStringE18detach_helper_growEii@Base 1.4.0
  (optional=templinst)_ZN5QListI7QStringE6appendERKS0_@Base 1.4.0
  (optional=templinst)_ZN5QListI7QStringEC1IPKS0_Lb1EEET_S5_@Base 1.4.0
@@ -149,6 +157,8 @@
  (optional=templinst)_ZN7QVectorI7QPointFED1Ev@Base 1.3.0
  (optional=templinst)_ZN7QVectorI7QPointFED2Ev@Base 1.3.0
  
(optional=templinst)_ZNK5QHashI7QString4QMapIN7Adwaita12ColorVariantE6QColorEE8findNodeERKS0_j@Base
 1.4.0
+ (optional=inline)_ZN8QMapDataIN7Adwaita12ColorVariantE6QColorE7destroyEv@Base 
1.4.1
+ (optional=inline)_ZN9QtPrivate8RefCount5derefEv@Base 1.4.1
  _ZNK7Adwaita12StyleOptions10colorGroupEv@Base 1.1.90
  _ZNK7Adwaita12StyleOptions12colorVariantEv@Base 1.1.90
  _ZNK7Adwaita12StyleOptions12outlineColorEv@Base 1.3.0
diff -Nru adwaita-qt-1.4.1/debian/libadwaitaqt6-1.symbols 
adwaita-qt-1.4.1/debian/libadwaitaqt6-1.symbols
--- adwaita-qt-1.4.1/debian/libadwaitaqt6-1.symbols 2022-04-21 
03:46:00.0 -0700
+++ adwaita-qt-1.4.1/debian/libadwaitaqt6-1.symbols 2022-08-20 
10:28:06.0 -0700
@@ -17,6 +17,8 @@
  
(optional=templinst|subst)_ZN12QHashPrivate4DataINS_4NodeIN7Adwaita13ColorsPrivate12AdwaitaColorE5QHashINS2_12ColorVariantE6QColorC2ERKSA_{size_t}@Base
 1.4.1
  
(optional=templinst)_ZN12QHashPrivate4DataINS_4NodeIN7Adwaita13ColorsPrivate12AdwaitaColorE5QHashINS2_12ColorVariantE6QColorD1Ev@Base
 1.4.1
  
(optional=templinst)_ZN12QHashPrivate4DataINS_4NodeIN7Adwaita13ColorsPrivate12AdwaitaColorE5QHashINS2_12ColorVariantE6QColorD2Ev@Base
 1.4.1
+ 
(optional=inline)_ZN12QHashPrivate4DataINS_4NodeIN7Adwaita12ColorVariantE6QColorEEE12findOrInsertERKS3_@Base
 1.4.1
+ 

Bug#1017766: podman: Failed to activate DNS. Missing dependency on golang-github-containernetworking-plugin-dnsname

[Reinhard Tartler]

>From the list of packages in your big report i see that the packages
netavark and aardvark-dns are absent. Does installing them work for your
without the golang-github-containernetworking-plugin-dnsname package?


One of the main major changes in podman 4 is the rust based networking
stack. It should be installed by default for new installations. Did this
not happen or is this an upgrade situation?

-rt

On Fri, Aug 19, 2022, 23:39 Michael Musenbrock 
wrote:

> Package: podman
> Version: 4.2.0+ds1-3
> Severity: important
>
> Hi,
>
> thanks for bringing up-to-date podman packages to Debian. This is really
> nice to have those current version available.
>
> With the latest version of the podman packages (4.2.0+ds1-3) dns
> resolution fails for podman networks.
>
> This could simply be resolved by installing
> 'golang-github-containernetworking-plugin-dnsname'. I think this should be
> installed automatically via dependencies.
>
> hth, keep up the nice work
> regards Michael
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (504, 'unstable'), (503, 'testing'), (502, 'experimental'),
> (1, 'experimental-debug')
> merged-usr: no
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.18.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.1.3+ds1-1
> ii  crun 1.5+dfsg-1+b1
> ii  golang-github-containers-common  0.49.1+ds1-1
> ii  libc62.34-4
> ii  libdevmapper1.02.1   2:1.02.185-1
> ii  libgpgme11   1.17.1-4
> ii  libseccomp2  2.5.4-1+b1
> ii  runc 1.1.3+ds1-7
> ii  systemd [systemd-tmpfiles]   251.4-1
>
> Versions of packages podman recommends:
> ii  buildah1.27.0+ds1-5
> ii  catatonit  0.1.7-1
> ii  dbus-user-session  1.14.0-2
> ii  fuse-overlayfs 1.9-1
> ii  slirp4netns1.2.0-1
> ii  tini   0.19.0-1
> ii  uidmap 1:4.11.1+dfsg1-2
>
> Versions of packages podman suggests:
> ii  containers-storage  1.42.0+ds1-1
> ii  docker-compose  1.29.2-1
> ii  iptables1.8.8-1
>
> -- no debconf information
>
>

Bug#1017802: gr-funcube FTBFS witn fmtlib 9.0.0 (?)

[Adrian Bunk]

Source: gr-funcube
Version: 3.10.0~rc2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=gr-funcube=3.10.0~rc2-1%2Bb1

...
In file included from /usr/include/spdlog/fmt/fmt.h:27,
 from /usr/include/spdlog/common.h:45,
 from /usr/include/gnuradio/logger.h:36,
 from /usr/include/gnuradio/custom_lock.h:15,
 from /usr/include/gnuradio/buffer.h:15,
 from /usr/include/gnuradio/buffer_double_mapped.h:15,
 from /usr/include/gnuradio/io_signature.h:17,
 from /usr/include/gnuradio/basic_block.h:15,
 from /usr/include/gnuradio/block.h:17,
 from /<>/lib/../include/funcube/fcd_control.h:11,
 from /<>/lib/fcd_control_impl.h:11,
 from /<>/lib/fcd_control_impl.cc:12:
/usr/include/fmt/core.h: In instantiation of ‘constexpr 
fmt::v9::detail::value fmt::v9::detail::make_value(T&&) [with Context 
= fmt::v9::basic_format_context; T = unsigned char* 
const&]’:
/usr/include/fmt/core.h:1753:29:   required from ‘constexpr 
fmt::v9::detail::value fmt::v9::detail::make_arg(T&&) [with bool 
IS_PACKED = true; Context = fmt::v9::basic_format_context; type  = fmt::v9::detail::type::custom_type; T = unsigned 
char* const&; typename std::enable_if::type  = 0]’
/usr/include/fmt/core.h:1877:77:   required from ‘constexpr 
fmt::v9::format_arg_store::format_arg_store(T&& ...) [with T = 
{unsigned char* const&}; Context = 
fmt::v9::basic_format_context; Args = {unsigned 
char*}]’
/usr/include/fmt/core.h:1894:38:   required from ‘constexpr 
fmt::v9::format_arg_store::type>::type ...> fmt::v9::make_format_args(Args&& 
...) [with Context = basic_format_context; Args = {unsigned 
char* const&}]’
/usr/include/spdlog/logger.h:370:68:   required from ‘void 
spdlog::logger::log_(spdlog::source_loc, spdlog::level::level_enum, 
spdlog::string_view_t, Args&& ...) [with Args = {unsigned char* const&}; 
spdlog::string_view_t = fmt::v9::basic_string_view]’
/usr/include/spdlog/logger.h:90:13:   required from ‘void 
spdlog::logger::log(spdlog::source_loc, spdlog::level::level_enum, 
fmt::v9::format_string, Args&& ...) [with Args = {unsigned char* 
const&}; fmt::v9::format_string = fmt::v9::basic_format_string]’
/usr/include/spdlog/logger.h:96:12:   required from ‘void 
spdlog::logger::log(spdlog::level::level_enum, fmt::v9::format_string, 
Args&& ...) [with Args = {unsigned char* const&}; fmt::v9::format_string 
= fmt::v9::basic_format_string]’
/usr/include/spdlog/logger.h:158:12:   required from ‘void 
spdlog::logger::info(fmt::v9::format_string, Args&& ...) [with Args = 
{unsigned char* const&}; fmt::v9::format_string = 
fmt::v9::basic_format_string]’
/usr/include/gnuradio/logger.h:156:23:   required from ‘void 
gr::logger::info(const spdlog::string_view_t&, const Args& ...) [with Args = 
{unsigned char*}; spdlog::string_view_t = fmt::v9::basic_string_view]’
/<>/lib/fcd_control_impl.cc:61:19:   required from here
/usr/include/fmt/core.h:1727:17: error: static assertion failed: Formatting of 
non-void pointers is disallowed.
 1727 |   static_assert(formattable_pointer,
  | ^~~
/usr/include/fmt/core.h:1727:17: note: ‘formattable_pointer’ evaluates to false
In file included from /usr/include/spdlog/fmt/fmt.h:27,
 from /usr/include/spdlog/common.h:45,
 from /usr/include/gnuradio/logger.h:36,
 from /usr/include/gnuradio/custom_lock.h:15,
 from /usr/include/gnuradio/buffer.h:15,
 from /usr/include/gnuradio/buffer_double_mapped.h:15,
 from /usr/include/gnuradio/io_signature.h:17,
 from /usr/include/gnuradio/basic_block.h:15,
 from /usr/include/gnuradio/block.h:17,
 from 
/<>/lib/../include/funcube/fcdpp_control.h:11,
 from /<>/lib/fcdpp_control_impl.h:12,
 from /<>/lib/fcdpp_control_impl.cc:13:
/usr/include/fmt/core.h: In instantiation of ‘constexpr 
fmt::v9::detail::value fmt::v9::detail::make_value(T&&) [with Context 
= fmt::v9::basic_format_context; T = unsigned char* 
const&]’:
/usr/include/fmt/core.h:1753:29:   required from ‘constexpr 
fmt::v9::detail::value fmt::v9::detail::make_arg(T&&) [with bool 
IS_PACKED = true; Context = fmt::v9::basic_format_context; type  = fmt::v9::detail::type::custom_type; T = unsigned 
char* const&; typename std::enable_if::type  = 0]’
/usr/include/fmt/core.h:1877:77:   required from ‘constexpr 
fmt::v9::format_arg_store::format_arg_store(T&& ...) [with T = 
{unsigned char* const&}; Context = 
fmt::v9::basic_format_context; Args = {unsigned 
char*}]’
/usr/include/fmt/core.h:1894:38:   required from ‘constexpr 
fmt::v9::format_arg_store::type>::type ...> fmt::v9::make_format_args(Args&& 
...) [with Context = basic_format_context; Args = {unsigned 
char* const&}]’
/usr/include/spdlog/logger.h:370:68:   required from 

Bug#898972: Are you still packaging this?

[Ben Westover]

Hello,

Are you still planning on packaging this? Your package was removed from
Mentors years ago. If you don't want to do it anymore, I can take over.

One thing to note is upstream's policy on others compiling their source
code and trying to use the MultiMC name:

> We keep Launcher open source because we think it's important to be
> able to see the source code for a project like this, and we do so
> using the Apache license.
>
> The license gives you access to the source MultiMC is built from, but:
>  * Not the name, logo and other branding.
>  * Not the API tokens required to talk to services the launcher
>depends on.
>
> You must provide your own branding if you want to distribute your own
> builds.
>
> You will also have to register your own app on Azure to be able to
> handle Microsoft account logins.
>
> If you decide to fork the project, a mention of its origins in the
> About dialog and the license is acceptable. However, it should be
> abundantly clear that the project is a fork *without* implying that
> you have our blessing.

Not only will we need to make our own branding for a Debian MultiMC
package (like iceweasel), but we will also need to create an Azure
application if we want to allow players to log in using their Microsoft
account (the majority of current Minecraft players who have migrated).

I have attached a logo I created for fun, but we will need to figure out
this Azure issue.

Regards
--
Ben Westover

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012530: 4ti2: package header files

[Jerome BENOIT]

Hi Doug, you are correct, 4ti2 is indeed a library.
I am considering to add lib4ti2-dev package.
Thanks,
Jerome
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1017801: openmw: hangs at start (ffmpeg-5 related)

[IOhannes m zmoelnig]

Package: openmw
Version: 0.47.0-1
Severity: important
Tags: upstream patch

Dear Maintainer,

When launching Morrowind with openmw, the game starts and you eventually come to
the initial game menu.
Clicking any item in the menu will freeze the game window.
The music keeps playing and the system stays otherwise reactive.

This is a known problem due to a bug in openmw that is triggered by ffmpeg-5.
The upstream bug-report can be found here:
  https://gitlab.com/OpenMW/openmw/-/issues/6631

Upstream also has a fix, which I attach.

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

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages openmw depends on:
ii  libavcodec597:5.1-2+b1
ii  libavformat59   7:5.1-2+b1
ii  libavutil57 7:5.1-2+b1
ii  libboost-filesystem1.74.0   1.74.0-16.1+b1
ii  libboost-iostreams1.74.01.74.0-16.1+b1
ii  libboost-program-options1.74.0  1.74.0-16.1+b1
ii  libbullet3.06   3.06+dfsg-4+b1
ii  libc6   2.34-4
ii  libgcc-s1   12.1.0-8
ii  libgl1  1.4.0-1
ii  liblz4-11.9.3-2
ii  libmyguiengine3debian1v53.4.1+dfsg-1
ii  libopenal1  1:1.19.1-2
ii  libopenscenegraph1613.6.5+dfsg1-7+b5
ii  libopenthreads213.6.5+dfsg1-7+b5
ii  librecast1  1.5.1+git20210215.e75adf8-1+b1
ii  libsdl2-2.0-0   2.0.22+dfsg-6
ii  libstdc++6  12.1.0-8
ii  libswresample4  7:5.1-2+b1
ii  libswscale6 7:5.1-2+b1
ii  libtinyxml2.6.2v5   2.6.2-6
ii  openmw-data 0.47.0-1

Versions of packages openmw recommends:
ii  openmw-launcher  0.47.0-1

openmw suggests no packages.

-- no debconf information
Description: Fix video hang with ffmpeg-5
Author: Dominique Martinet 
Origin: upstream
Applied-Upstream: 
https://gitlab.com/OpenMW/openmw/-/commit/436db8c0e55b0d5be43df982d15025ed0fc76c40
Last-Update: 2022-08-20
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- openmw.orig/apps/openmw/mwsound/ffmpeg_decoder.cpp
+++ openmw/apps/openmw/mwsound/ffmpeg_decoder.cpp
@@ -18,11 +18,15 @@
 std::istream& stream = 
*static_cast(user_data)->mDataStream;
 stream.clear();
 stream.read((char*)buf, buf_size);
-return stream.gcount();
+std::streamsize count = stream.gcount();
+if (count == 0)
+return AVERROR_EOF;
+return count;
+
 }
 catch (std::exception& )
 {
-return 0;
+return AVERROR_UNKNOWN;
 }
 }
 

Bug#1009684: openmw: FTBFS with glibc 2.34

[IOhannes m zmoelnig]

Source: openmw
Version: 0.47.0-1
Followup-For: Bug #1009684
Control: tags -1 patch

Ubuntu appears to have patched openmw to fix this issue.
Please find the patch attached.
Description: Assume SIGSTKSZ is not a constant
Origin: upstream, 
https://gitlab.com/OpenMW/openmw/-/commit/98a7d90ee258ceef9c70b0b2955d0458ec46f048
Author: elsid 
Last-Update: 2021-09-24

--- a/components/crashcatcher/crashcatcher.cpp
+++ b/components/crashcatcher/crashcatcher.cpp
@@ -56,8 +56,6 @@
 
 static char argv0[PATH_MAX];
 
-static char altstack[SIGSTKSZ];
-
 
 static struct {
 int signum;
@@ -475,9 +473,10 @@
 
 /* Set an alternate signal stack so SIGSEGVs caused by stack overflows
  * still run */
+static char* altstack = new char [SIGSTKSZ];
 altss.ss_sp = altstack;
 altss.ss_flags = 0;
-altss.ss_size = sizeof(altstack);
+altss.ss_size = SIGSTKSZ;
 sigaltstack(, nullptr);
 
 memset(, 0, sizeof(sa));

Bug#1016765: webkit2gtk: Please enable gtk4 build

[Jeremy Bicha]

On Tue, Aug 16, 2022 at 9:30 AM Jeremy Bicha  wrote:
>
> On Tue, Aug 16, 2022 at 9:27 AM Alberto Garcia  wrote:
> > On Tue, Aug 16, 2022 at 09:13:57AM -0400, Jeremy Bicha wrote:
> >
> > > > Thanks! I'll push the changes to salsa and probably wait for the
> > > > new development release of webkit.
> > > Could you upload now?
> >
> > I just checked with upstream and there'll be a new release this week,
> > are you ok with waiting?
>
> Yes, this week should be good enough. Thanks!
>
> Jeremy Bicha

Could you push your work to Salsa? I intend to upload directly to
Ubuntu 22.10 without waiting for Debian NEW acceptance.

Jeremy

Bug#1017800: pulseaudio: Reflect Debian default of 'autospawn = no' in commented client.conf

[Pat Coulthard]

Package: pulseaudio
Version: 14.2-2
Severity: minor
X-Debbugs-Cc: pmcoulth...@gmail.com

Debian patches the defualt behavior of the PulseAudio client to disable
autospawning the PulseAudio daemon. However the commented line in
/etc/pulseaudio/client.conf does not reflect this Debian deviation from
the upstream default:

; autospawn = yes


Similarly, README.Debian could use some attention:
 - It references setting 'autospawn = no', despite it now being the default.
 - It references a now non-existant /etc/default/pulseaudio


Thanks!


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libasound2   1.2.4-1.1
ii  libasound2-plugins   1.2.2-2
ii  libc62.31-13+deb11u3
ii  libcap2  1:2.44-1
ii  libdbus-1-3  1.12.20-2
ii  libgcc-s110.2.1-6
ii  libice6  2:1.0.10-1
ii  libltdl7 2.4.6-15
ii  liborc-0.4-0 1:0.4.32-1
ii  libpulse014.2-2
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.31-2
ii  libsoxr0 0.1.3-4
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-7
ii  libtdb1  1.4.3-1+b1
ii  libudev1 247.3-7
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb1  1.14-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 14.2-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.12.20-2
ii  libpam-systemd [logind]  247.3-7
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  4.0-2
pn  pavumeter
ii  udev 247.3-7

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = 

Bug#1017799: traceroute does not default to ipv6 when destination has a AAAA record

[Gabriel Filion]

Package: traceroute
Version: 1:2.1.0-3
Severity: wishlist
Tags: upstream ipv6

Hi,

The traceroute binary can currently be used with both address families, IPv4
and IPv6, which is great!

However, contrary to how i.e ping behaves traceroute does not chose to use ipv6
when a  dns record exists for the destination of the trace and one needs to
explicitely specify -6 to get a trace over ipv6.

In the grand mission of pushing internet users more and more towards IPv6, it
would make more sense to default to ipv6 whenever it's possible and fallback to
IPv4 otherwise.

Note: I've only tested the above-mentioned behavior on debian bullseye (so with
libc6 2.31) since I don't currently have a debian sid system that's connected
to IPv6.


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_CA.utf8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages traceroute depends on:
ii  libc6  2.34-4

traceroute recommends no packages.

traceroute suggests no packages.

-- no debconf information

Bug#1017798: emacs-common can't be installed: segfault in postinst

[Akkana Peck]

Package: emacs-common
Version: 1:28.1+1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: d...@shallowsky.com

Dear Maintainer,

Emacs can't be updated as of the current sid version, because of a
segfault during postinst:

Preparing to unpack .../emacs-gtk_1%3a28.1+1-1_amd64.deb ...
Unpacking emacs-gtk (1:28.1+1-1) ...
Setting up emacs-gtk (1:28.1+1-1) ...
update-alternatives: using /usr/bin/emacs-gtk to provide /usr/bin/emacs (emacs) 
in auto mode
tsort: -: input contains a loop:
tsort: elpa-org
tsort: emacsen-common
tsort: -: input contains a loop:
tsort: elpa-htmlize
tsort: elpa-org
tsort: emacsen-common
Install elpa-htmlize for emacs
install/htmlize-1.56: Handling install of emacsen flavor emacs
install/htmlize-1.56: byte-compiling for emacs
Fatal error 11: Segmentation fault
Backtrace:
emacs(+0x153d71)[0x560ec9351d71]
emacs(+0x48902)[0x560ec9246902]
emacs(+0x48dcf)[0x560ec9246dcf]
emacs(+0x15209d)[0x560ec935009d]
emacs(+0x152119)[0x560ec9350119]
/lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7f4d7663daf0]
emacs(+0x194c30)[0x560ec9392c30]
emacs(+0x19a1ca)[0x560ec93981ca]
emacs(+0x1b87b5)[0x560ec93b67b5]
emacs(+0x1b88df)[0x560ec93b68df]
emacs(+0x1deff5)[0x560ec93dcff5]
emacs(+0x1df9d3)[0x560ec93dd9d3]
emacs(+0x1e3278)[0x560ec93e1278]
emacs(+0x1e3f3a)[0x560ec93e1f3a]
emacs(+0x1b8442)[0x560ec93b6442]
emacs(+0x1b8710)[0x560ec93b6710]
emacs(+0x1b88df)[0x560ec93b68df]
emacs(+0x1deff5)[0x560ec93dcff5]
emacs(+0x1df9d3)[0x560ec93dd9d3]
emacs(+0x1e3278)[0x560ec93e1278]
emacs(+0x1e3f3a)[0x560ec93e1f3a]
emacs(+0x1b8442)[0x560ec93b6442]
emacs(+0x1b8710)[0x560ec93b6710]
emacs(+0x1b88df)[0x560ec93b68df]
emacs(+0x1deff5)[0x560ec93dcff5]
emacs(+0x1df9d3)[0x560ec93dd9d3]
emacs(+0x1e3278)[0x560ec93e1278]
emacs(+0x1e3f3a)[0x560ec93e1f3a]
emacs(+0x1b8442)[0x560ec93b6442]
emacs(+0x1b8710)[0x560ec93b6710]
emacs(+0x1b88df)[0x560ec93b68df]
emacs(+0x1deff5)[0x560ec93dcff5]
emacs(+0x1df9d3)[0x560ec93dd9d3]
emacs(+0x1e3278)[0x560ec93e1278]
emacs(+0x1e3f3a)[0x560ec93e1f3a]
emacs(+0x1b8442)[0x560ec93b6442]
emacs(+0x1b8710)[0x560ec93b6710]
emacs(+0x1b88df)[0x560ec93b68df]
emacs(+0x1deff5)[0x560ec93dcff5]
emacs(+0x1df9d3)[0x560ec93dd9d3]
emacs(+0x1e3278)[0x560ec93e1278]
...
Segmentation fault
ERROR: install script from elpa-htmlize package failed
dpkg: error processing package emacs-gtk (--configure):
 installed emacs-gtk package post-installation script subprocess returned error 
exit status 1
dpkg: dependency problems prevent configuration of emacs:
 emacs depends on emacs-gtk (>= 1:27.1) | emacs-lucid (>= 1:27.1) | emacs-nox 
(>= 1:27.1); however:
  Package emacs-gtk is not configured yet.
  Package emacs-lucid is not installed.
  Package emacs-nox is not installed.

dpkg: error processing package emacs (--configure):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.10.2-2) ...
Processing triggers for mailcap (3.70+nmu1) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Errors were encountered while processing:
 emacs-gtk
 emacs
E: Sub-process /usr/bin/dpkg returned an error code (1)

This happens regardless of whether emacs-gtk, emacs-lucid or
emacs-nox is used.

This might be the same segfault as bug #1017779, but that bug has
severity normal, while this causes all emacs packages to be unusable
so it should be grave according to the definitions reportbug shows
me, and a new bug is the only way I know to do that.

I tried to downgrade to emacs-common=1:27.1+1-3.1 by pointing to
https://snapshot.debian.org/archive/debian/20210328T030002Z/
but it looks like that sort of downgrade requires manually chasing
all the dependencies' versions and dates and then finding a snapshot
that has all of them, and I gave up after a few tries.

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
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/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs-common depends on:
ii  emacsen-common   3.0.4
ii  init-system-helpers  1.64
ii  install-info 6.8-6

Versions of packages emacs-common recommends:
pn  emacs-el  

Versions of packages emacs-common suggests:
ii  emacs-common-non-dfsg  1:27.1+1-2
ii  ncurses-term   6.3+20220423-2

-- no debconf information

Bug#1017797: libigloo: FTBFS on s390x: not big-endian safe?

[Steve Langasek]

Source: libigloo
Version: 0.9.1-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Unit 193,

libigloo 0.9.1 has been stuck in unstable for 170 days because it fails to
build from source on s390x with a large number of test failures:

  [...]
  # Expected: 0 (NONE: No error)
  # Got:  -1 (GENERIC: Generic error)
  not ok 6 digest by vectors/digest match
  FAIL: tests/digest 6 digest by vectors/digest match
  [...]

  
(https://buildd.debian.org/status/fetch.php?pkg=libigloo=s390x=0.9.1-1=1646188967=0)

Some preliminary investigation suggests to me this is not a bug in the test
suite, but is instead an endianness problem with the implementation itself
(the hash output does not differ in byte order, but is instead completely
different).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages

[Thorsten Glaser]

Markus Koschany dixit:

>The --add-opens error message was misleading and it turned out the underlying
>root cause for the FTBFS was a different one. Gradle currently fails to build
>because of a different jansi bug.

OK, so keep that one open and close this one?

>There is still some work to do with Gradle 6.x and progress is slow but
>I still think we should focus on that instead of trying to ship Gradle
>4 again.

Ideally fix the RC bugs first though so not only is there a Plan B but also
will the affected r-deps not be autoremoved from testing due to these issues.

bye,
//mirabilos
-- 
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing

Bug#1012214: gradle: FTBFS with jansi 2

[Markus Koschany]

Control: retitle -1 gradle: FTBFS with jansi 2

Let me try to fix this 



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

Bug#1017796: magit-forge-el: FTBFS if apt does not have deb-src lines configured

[Steve Langasek]

Package: magit-forge-el
Version: 0.3.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Matteo,

The magit-forge-el package was failing to build in Ubuntu, because
debian/rules relies on apt-cache showsrc to figure out the paths for magit
and closql on the installed system, but the Ubuntu build environment doesn't
have deb-src entries configured (nor should it need to).

This approach is also buggy, because it looks for the most recent version of
the source package in the cache, when what you ACTUALLY want to know is the
version of the binary package that has been installed as a build-dependency.

The attached patch uses dpkg -l instead of apt-cache to query the installed
system.  I have uploaded this change to Ubuntu, where it has built
successfully.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru magit-forge-el-0.3.1/debian/rules magit-forge-el-0.3.1/debian/rules
--- magit-forge-el-0.3.1/debian/rules   2022-02-25 15:00:33.0 -0800
+++ magit-forge-el-0.3.1/debian/rules   2022-08-20 09:51:08.0 -0700
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
-CLOSQL_VER = $(shell apt-cache showsrc closql-el | grep "Version:" | sort -r | 
head -n1 | cut -f2 -d ' ' | cut -f1 -d '-')
-MAGIT_VER = $(shell apt-cache showsrc magit | grep "Version:" | sort -r | head 
-n1 | cut -f2 -d ' ' | cut -f1 -d '-')
+CLOSQL_VER = $(shell dpkg -l elpa-closql | awk '/^ii/ { print $$3 }' | cut -f1 
-d '-')
+MAGIT_VER = $(shell dpkg -l elpa-magit | awk '/^ii/ { print $$3 }' | cut -f1 
-d '-')
 
 LPATH =  -L /usr/share/emacs/site-lisp/elpa-src/closql-$(CLOSQL_VER)
 LPATH += -L /usr/share/emacs/site-lisp/elpa-src/magit-$(MAGIT_VER)

Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages

[Markus Koschany]

Am Samstag, dem 20.08.2022 um 16:35 + schrieb Thorsten Glaser:
> Markus Koschany dixit:
> 
> > The newly added --add-opens option is only valid for OpenJDK 17. I
> > understand that we switch to it for Debian 12 but it currently breaks
> > all packages that are built with OpenJDK 11. I am currently in the
> 
> Is this true? AFAIK --add-opens is for 11+ (probably even 9+). It
> certainly seems to work on buster for me.


The --add-opens error message was misleading and it turned out the underlying
root cause for the FTBFS was a different one. Gradle currently fails to build
because of a different jansi bug. There is still some work to do with Gradle
6.x and progress is slow but I still think we should focus on that instead of
trying to ship Gradle 4 again.




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

Bug#1017792: gnome-tweaks: Does not launch: unknown setting: font-hinting

[Jeremy Bicha]

On Sat, Aug 20, 2022 at 12:03 PM Mikolaj Kuranowski
 wrote:
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Versions of packages gnome-tweaks depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
> ii  gir1.2-glib-2.0  1.72.0-1+b1
> ii  gir1.2-gnomedesktop-3.0  42.3-1
> ii  gir1.2-gtk-3.0   3.24.34-1
> ii  gir1.2-handy-1   1.7.90-1
> ii  gir1.2-notify-0.70.8.1-1
> ii  gir1.2-pango-1.0 1.50.9+ds-1
> ii  gir1.2-soup-2.4  2.74.2-3
> ii  gnome-settings-daemon3.38.2-1
> ii  gnome-shell-common   3.38.6-1~deb11u1
> ii  gnome-shell-extension-prefs  3.38.6-1~deb11u1
> ii  gsettings-desktop-schemas3.38.0-2

Please update your gsettings-desktop-schemas to 42.0-1 (or higher).

You're likely to hit more of these kinds of bugs if you don't
regularly install all available updates. It is a valid bug but most
people won't see it and it's impossible for developers to test every
arbitrary combination of package versions.

It looks like you still have a lot of Debian 11 packages installed
(gnome-shell, gnome-settings-daemon ,etc.) instead of the current
Testing versions.

Thank you,
Jeremy Bicha

Bug#1017795: mmdebstrap hangs when apt cannot resolve dependencies

[Gioele Barabucci]

Package: mmdebstrap
Version: 1.1.0

When apt fails to resolve dependencies, the mmdebstrap process does not 
exit, it just hangs waiting for something.


These are the last lines produced by mmdebstrap before getting stuck:

```
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
[...]
E: Unable to correct problems, you have held broken packages.
E: apt-get --yes -oDebug::pkgDpkgPm=1 -oDir::Log=/dev/null 
-oAPT::Keep-Fds::=7 -oDPkg::Tools::options::'cat >&7'::InfoFD=7 
-oDpkg::Pre-Install-Pkgs::=cat >&7 -oDebug::NoLocking=1 
-oDpkg::Use-Pty=0 install mypackage -oAPT::Status-Fd=<$fd> 
-oDpkg::Use-Pty=false failed at ./mmdebstrap line 184.
main::error("apt-get --yes -oDebug::pkgDpkgPm=1 
-oDir::Log=/dev/null -oAPT"...) called at ./mmdebstrap line 861
main::run_progress(CODE(0x561c4e5e80b0), CODE(0x561c4e1abb10), 
CODE(0x561c4e195af0), undef) called at ./mmdebstrap line 953
main::run_apt_progress(HASH(0x561c4e58dca8)) called at 
./mmdebstrap line 1022
main::run_apt_download_progress(HASH(0x561c4e5800c0)) called at 
./mmdebstrap line 2187
main::run_download(HASH(0x561c4e5fb2d8)) called at ./mmdebstrap 
line 1650

main::setup(HASH(0x561c4e5fb2d8)) called at ./mmdebstrap line 5508
main::__ANON__() called at ./mmdebstrap line 653
main::get_unshare_cmd(CODE(0x561c4e5e7f18), 
ARRAY(0x561c4e3fa270)) called at ./mmdebstrap line 

main::main() called at ./mmdebstrap line 5903
```

Interrupting the process with CTRL-C makes mmdebstrap generate this 
additional output:


```
^CI: 3434314 5672 main() received signal INT: waiting for setup...
W: listening on child socket failed:
D: 3434314 5712 finish to listen for hooks
I: 3434314 5836 removing tempdir /tmp/mmdebstrap.BWrei226yQ...
E: mmdebstrap failed to run at ./mmdebstrap line 184.
main::error("mmdebstrap failed to run") called at ./mmdebstrap 
line 5899

main::main() called at ./mmdebstrap line 5903
```

--
Gioele Barabucci

Bug#1017794: glib2.0: Upload 2.73 to Unstable

[Jeremy Bicha]

Source: glib2.0
Version: 2.72.3-1
Severity: wishlist
Control: block -1 by 1017578

We have one blocker bug to fix before we can upload glib 2.73 to Unstable.

There is also https://bugs.debian.org/1017793 but it's not a blocker
bug for Debian.

Thank you,
Jeremy Bicha

Bug#1017793: gvfs: autopkgtest failure with glib 2.73

[Jeremy Bicha]

Source: gvfs
Version: 1.50.2-1
Forwarded: https://gitlab.gnome.org/GNOME/gvfs/-/issues/641
Tags: upstream sid bookworm

The gvfs autokpgtests are failing with glib 2.73.3-1 (currently in
Debian experimental).

This doesn't show up at
https://ci.debian.net/packages/g/gvfs/unstable/amd64/ because the
autopkgtests require machine-level isolation and ci.debian.net doesn't
support that yet. It does show up on Ubuntu's autopkgtest
infrastructure.

The tests don't fail at build time.

Thank you,
Jeremy Bicha

Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages

[Thorsten Glaser]

Markus Koschany dixit:

>The newly added --add-opens option is only valid for OpenJDK 17. I
>understand that we switch to it for Debian 12 but it currently breaks
>all packages that are built with OpenJDK 11. I am currently in the

Is this true? AFAIK --add-opens is for 11+ (probably even 9+). It
certainly seems to work on buster for me.

bye,
//mirabilos
-- 
 Beware of ritual lest you forget the meaning behind it.
 yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.

Bug#996415: mark libnghttp2-dev Multi-Arch: same

[Bastien Roucariès]

control: severity -1 important

Hi Tomasz,

Could you made a release of libnghttp2-dev by applying this patch ?

We plan to boostrap nodejs on a new architecture and it will help us a lot.

Thanks

Bastien

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

Bug#926714: Gradle packaging status update

[Phil Morrell]

Hi all, documenting my observations as of today because it's not looking
promising for bookworm.

* kotlin FTBFS because of changes to support openjdk 17 #1012214
* gradle FTBFS since an upload of libjansi-java 2.4.0 #1013545
* gradle v6 has been (loosely) imported to the java-team repo
  https://salsa.debian.org/freexian-team/project-funding/-/issues/19#note_314274
* I have not yet successfully built gradle v6 from gradle v6

The gradle-6.4.1-initial branch has a mix of patches, the series being I
think just a dump from the GSoC repo, which itself I think didn't
migrate the existing gradle v4 debianisation patches. To build at all,
an additional change to remove-enterprise-plugin.patch is needed to drop
build.gradle.kts#L36. See https://www.emorrp1.name/gradle/ for output.

Rebuilding fails to find ant-1.10.7.jar, since it is in +bootstrap but
is 1.10.12 in debian. Oddly, this is still true after editing all
references to the hardcoded version, trying to fudge with maven.rules
and seems to be because of something gradle does to handle its own
dependency resolution as hinted at by:

https://salsa.debian.org/java-team/gradle/-/commit/f16a4214840f46d44032840cfb52f52c145a662d#fc53ddfd6619eeea25e146e23133a9367c26a52b

I think the next thing I'll look into is improving the +bootstrap, which
I think was just a dump of all the recursive jars it might possibly
need. There's a bootstrap script in the source to update, and I liked
the kotlin one, so will probable just import that. It'd be helpful if
the artifacts were split into two, those that are output to the build
and those that are just the frozen build-deps.

Feel free to chat with me in #debian-java on irc/matrix and if anyone
has permissions to the Salsa java-team, please could you add me there.


signature.asc
Description: PGP signature

Bug#1017792: gnome-tweaks: Does not launch: unknown setting: font-hinting

[Mikolaj Kuranowski]

Package: gnome-tweaks
Version: 42~beta-1
Severity: important
X-Debbugs-Cc: mkuranowski+debianb...@gmail.com

It is not possible to launch the tool - it immediately crashes with the
following traceback:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gtweak/app.py", line 50, in do_activate
self.win = Window(self, model)
  File "/usr/lib/python3/dist-packages/gtweak/tweakview.py", line 58, in
__init__
self._model.load_tweaks(self)
  File "/usr/lib/python3/dist-packages/gtweak/tweakmodel.py", line 107, in
load_tweaks
mods = __import__("gtweak.tweaks", globals(), locals(), tweak_files, 0)
  File "/usr/lib/python3/dist-packages/gtweak/tweaks/tweak_group_font.py", line
113, in 
FontXSettingsTweak(),
  File "/usr/lib/python3/dist-packages/gtweak/tweaks/tweak_group_font.py", line
41, in __init__
self.btn_full.set_active(self.settings["font-hinting"] == "full")
  File "/usr/lib/python3/dist-packages/gi/overrides/Gio.py", line 259, in
__getitem__
raise KeyError('unknown key: %r' % (key,))
KeyError: "unknown key: 'font-hinting'"


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 gnome-tweaks depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gnomedesktop-3.0  42.3-1
ii  gir1.2-gtk-3.0   3.24.34-1
ii  gir1.2-handy-1   1.7.90-1
ii  gir1.2-notify-0.70.8.1-1
ii  gir1.2-pango-1.0 1.50.9+ds-1
ii  gir1.2-soup-2.4  2.74.2-3
ii  gnome-settings-daemon3.38.2-1
ii  gnome-shell-common   3.38.6-1~deb11u1
ii  gnome-shell-extension-prefs  3.38.6-1~deb11u1
ii  gsettings-desktop-schemas3.38.0-2
ii  mutter-common42.3-2
ii  python3  3.10.5-3
ii  python3-gi   3.42.2-1

gnome-tweaks recommends no packages.

gnome-tweaks suggests no packages.

-- no debconf information

Bug#1017791: valgrind: does not support rseq syscall

[Aurelien Jarno]

Package: valgrind
Version: 1:3.18.1-1.1
Severity: important
Tags: patch upstream
User: debian-gl...@lists.debian.org
Usertags: glibc2.35
Forwarded: 
https://sourceware.org/git/?p=valgrind.git;a=commit;h=1024237358f01009fe233cb1294f3b8211304eaa

Dear maintainer(s),

valgrind does not implement the new rseq syscall, which is getting used
by default starting with glibc 2.35. This causes it to display the
following message, which in turns breaks some autopkgtest [1]:

| WARNING: unhandled amd64-linux syscall: 334
| You may be able to write your own handler.
| Read the file README_MISSING_SYSCALL_OR_IOCTL.
| Nevertheless we consider this a bug.  Please report
| it at http://valgrind.org/support/bug_reports.html.

There is already an upstream fix available [2], would it be possible to
get it included in the next upload?

Thanks,
Aurelien

[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/c/critnib/24898218/log.gz
[2] 
https://sourceware.org/git/?p=valgrind.git;a=commit;h=1024237358f01009fe233cb1294f3b8211304eaa

Bug#1017790: chrony needs a seccomp filter update for glibc 2.35

[Aurelien Jarno]

Source: chrony
Version: 4.2-2
Severity: important
Tags: patch upstream
User: debian-gl...@lists.debian.org
Usertags: glibc2.35
Forwarded: 
https://git.tuxfamily.org/chrony/chrony.git/commit/?id=8bb8f15a7d049ed26c69d95087065b381f76ec4d
 

Dear maintainer(s),

chrony uses a seccomp filter, and glibc 2.35 uses the new rseq syscall
by default, causing chrony to fail to work [1].

There is already an upstream fix available [2], would it be possible to
get it in the next upload?

Thanks,
Aurelien


[1] 
https://ci.debian.net/data/autopkgtest/unstable/amd64/c/chrony/25005126/log.gz
[2] 
https://git.tuxfamily.org/chrony/chrony.git/commit/?id=8bb8f15a7d049ed26c69d95087065b381f76ec4d

Bug#1017742: po4a: Please provide marker for double strings during po4a-gettextize

[Helge Kreutzmann]

Hello Martin,
On Sat, Aug 20, 2022 at 10:43:23AM +0200, Martin Quinson wrote:
> - Le 19 Aoû 22, à 21:13, Helge Kreutzmann deb...@helgefjell.de a écrit :
> 
> > Package: po4a
> > Version: 0.67-2
> > Severity: wishlist
> > 
> > Since recently po4a-gettextize adds spaces at the end of strings
> > during gettextisation, if strings occure multiple times in the master
> > file (or translation).
> > 
> > In production, multiple indentical strings in the original file are
> > only stored once in the po file (as they are translated the same).
> > 
> > Therefore, translators need to review those strings carefully and
> > remove those entries from the po file, which have this final space
> > added. In this process they need to choose the most appropriate
> > translation to keep.
> > 
> > Currently, this can be quite difficult, as the string can occur
> > multiple times and the trailing space(s) are difficult to spot in
> > large files. Also these trailing spaces are hard to get a good regular
> > expression for searching.
> > 
> > Therefor I kindly ask you if you could mark those strings in addition
> > (!) with a suitable translator comment (e.g. "Potential duplicate
> > string, review and consolidate"). This would users allow to use msggrep(1)
> > with the option -C to filter them out for review.
> > 
> > Thanks for considering.
> 
> Your bug report makes me realize that the current behavior is perfectly 
> broken. I was hopping for the next msgmerge to merge the alternative 
> translations of the same msgid, but I realize that they will most probably be 
> dropped in the process. 

Yes, that is what I noticed as well. (We just went through it at
manpages-l10n).

> Mmm. Let me think about it, I'll try to reimplement this thing so that the 
> carful review that you describe becomes automatically done during the 
> gettexization.

Thanks!

Greetings

Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1017441: Please assert severity of bug#1017441 (debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles)

[Niels Thykier]

Hi Release team,

Bug #1017441 was filed against debhelper in related to a change to 
dh_installtmpfiles that made it apply an unconditional dependency on

"systemd | systemd-tmpfiles".

My concern is not the dependency itself (as I understand it, the systemd 
GR ratifies that).  What might be concerning is that the dependency 
appears in lower levels of the build stack causing additional package to 
appear in our chroot according to Santiago Vila (quoted below in full).


The bug was originally filed as RC but has now been degraded to 
wishlist. Admittedly, it is not clear to me the downgrade was done with 
the knowledge that the bug affected our chroots.


The question is whether you feel this is an RC bug and would like me to 
revert the change immediately / before the transition freeze?
  The alternative is you do not feel this bug is concerning/RC in which 
case I will keep the current version until people have come to a 
conclusion on the bug.


What is your view on the above question?

Thanks,
~Niels

PS: Please include the bug in CC with your (formal) answer to that question.

Santiago Vila:

Hello.

As of today, upgrading a sid chroot containing debhelper to the sid of 
today, systemd, mount, and several other packages are installed into the 
chroot. This is usually undesired because we want build chroots to be as 
minimal as possible.


Users of debootstrap can certainly use --include and --exclude to 
fine-tune the contents of the chroot, but as a user of debootstrap, I 
would expect it to do the right thing (minimal chroot) by default and 
without having to fine-tune it.


On amd64, I've checked that installing systemd-standalone-tmpfiles 
allows systemd and all the extra packages to be removed again.


So I wonder if reversing the dependency created by debhelper:

systemd | systemd-tmpfiles

would improve this state of things.

(Trimming Cc list a little bit, I don't want to spam everybody)

Thanks.

Bug#1017789: fcitx5-chinese-addons: Missing optional build-dependency fcitx5-lua

[Boyuan Yang]

Source: fcitx5-chinese-addons
Version: 5.0.4-1
Severity: normal

Currently fcitx5-chinese-addons has an optional build-dependency on fcitx5-
lua, which is not included in Debian's packaging. This will make lua-related
features unavailable in fcitx5's Chinese input methods.

Thanks,
Boyuan Yang


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

Bug#1017788: fcitx5-module-lua: Missing lua library depednency (liblua5.3-0)

[Boyuan Yang]

Package: fcitx5-module-lua
Severity: important
Version: 5.0.3-1

Package fcitx5-module-lua uses dlopen() on liblua5.3, not dynamic linking. As
a result, its library dependency was not handled correctly by dh_shlibdeps. We
should add a manual library dependency.

Thanks,
Boyuan Yang


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

Bug#1017292: r-cran-av: FTBFS: Error: package or namespace load failed for ‘av’ in dyn.load(file, DLLpath = DLLpath, ...):

[Nilesh Patra]

Control: fixed -1 0.8.0+dfsg-1
Control: close -1


This seems to build ok now


https://buildd.debian.org/status/fetch.php?pkg=r-cran-av=amd64=0.8.0%2Bdfsg-1=1660914888=0

closing.

On Sun, 14 Aug 2022 09:50:58 +0200 Lucas Nussbaum  wrote:
> Source: r-cran-av
> Version: 0.7.0+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220813 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>/src'
> > make[1]: Leaving directory '/<>/src'
> > installing to 
> > /<>/debian/r-cran-av/usr/lib/R/site-library/00LOCK-r-cran-av-0.7.0+dfsg/00new/av/libs
> > ** R
> > ** inst
> > ** byte-compile and prepare package for lazy loading
> > ** help
> > *** installing help indices
> > ** building package indices
> > ** testing if installed package can be loaded from temporary location
> > Error: package or namespace load failed for ‘av’ in dyn.load(file, DLLpath 
> > = DLLpath, ...):
> >  unable to load shared object 
> > '/<>/debian/r-cran-av/usr/lib/R/site-library/00LOCK-r-cran-av-0.7.0+dfsg/00new/av/libs/av.so':
> >   
> > /<>/debian/r-cran-av/usr/lib/R/site-library/00LOCK-r-cran-av-0.7.0+dfsg/00new/av/libs/av.so:
> >  undefined symbol: FFABS
> > Error: loading failed
> > Execution halted
> > ERROR: loading failed
> > * removing ‘/<>/debian/r-cran-av/usr/lib/R/site-library/av’
> > dh_auto_install: error: R CMD INSTALL -l 
> > /<>/r-cran-av-0.7.0\+dfsg/debian/r-cran-av/usr/lib/R/site-library 
> > --clean . "--built-timestamp='Wed, 09 Feb 2022 15:30:48 +0100'" returned 
> > exit code 1
> > make: *** [debian/rules:6: binary] Error 25
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2022/08/13/r-cran-av_0.7.0+dfsg-1_unstable.log
> 
> All bugs filed during this archive rebuild are listed at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220813;users=lu...@debian.org
> or:
> https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220813=lu...@debian.org=1=1=1=1#results
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> If you reassign this bug to another package, please marking it as 
> 'affects'-ing
> this package. See https://www.debian.org/Bugs/server-control#affects
> 
> If you fail to reproduce this, please provide a build log and diff it with 
> mine
> so that we can identify if something relevant changed in the meantime.
> 
> 

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1017787: ikhal crashes regularly when creating events

[VA]

Package: khal
Version: 1:0.10.4~ds-3

ikhal crashes regularly when creating events, with this backtrace:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/khal/ui/__init__.py", line 1358, 
in start_pane

loop.run()
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 287, 
in run

self._run()
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 385, 
in _run

self.event_loop.run()
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 790, 
in run

self._loop()
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 827, 
in _loop

self._watch_files[fd]()
  File "/usr/lib/python3/dist-packages/urwid/raw_display.py", line 416, 
in 

wrapper = lambda: self.parse_input(
  File "/usr/lib/python3/dist-packages/urwid/raw_display.py", line 515, 
in parse_input

callback(processed, processed_codes)
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 412, 
in _update

self.process_input(keys)
  File "/usr/lib/python3/dist-packages/urwid/main_loop.py", line 513, 
in process_input

k = self._topmost_widget.keypress(self.screen_size, k)
  File "/usr/lib/python3/dist-packages/urwid/wimp.py", line 651, in 
keypress

return self._current_widget.keypress(size, key)
  File "/usr/lib/python3/dist-packages/urwid/container.py", line 1135, 
in keypress

return self.body.keypress( (maxcol, remaining), key )
  File "/usr/lib/python3/dist-packages/urwid/container.py", line 2316, 
in keypress

key = w.keypress((mc,) + size[1:], key)
  File "/usr/lib/python3/dist-packages/urwid/container.py", line 1626, 
in keypress

key = self.focus.keypress(tsize, key)
  File "/usr/lib/python3/dist-packages/urwid/container.py", line 2316, 
in keypress

key = w.keypress((mc,) + size[1:], key)
  File "/usr/lib/python3/dist-packages/khal/ui/editor.py", line 530, in 
keypress

return super().keypress(size, key)
  File "/usr/lib/python3/dist-packages/khal/ui/widgets.py", line 376, 
in keypress

key = super().keypress(size, key)
  File "/usr/lib/python3/dist-packages/urwid/listbox.py", line 968, in 
keypress

key = focus_widget.keypress((maxcol,),key)
  File "/usr/lib/python3/dist-packages/urwid/container.py", line 2316, 
in keypress

key = w.keypress((mc,) + size[1:], key)
  File "/usr/lib/python3/dist-packages/urwid/wimp.py", line 543, in 
keypress

self._emit('click')
  File "/usr/lib/python3/dist-packages/urwid/widget.py", line 461, in _emit
signals.emit_signal(self, name, self, *args)
  File "/usr/lib/python3/dist-packages/urwid/signals.py", line 265, in emit
result |= self._call_callback(callback, user_arg, user_args, args)
  File "/usr/lib/python3/dist-packages/urwid/signals.py", line 295, in 
_call_callback

return bool(callback(*args_to_pass))
  File "/usr/lib/python3/dist-packages/khal/ui/editor.py", line 503, in 
save

self.collection.new(self.event)
  File "/usr/lib/python3/dist-packages/khal/khalendar/khalendar.py", 
line 208, in new

event.href, event.etag = self._storages[calendar].upload(event)
  File "/usr/lib/python3/dist-packages/khal/khalendar/vdir.py", line 
212, in upload

if not isinstance(item.raw, str):
  File "/usr/lib/python3/dist-packages/khal/khalendar/event.py", line 
382, in raw

timezone = create_timezone(tzinfo, self.start)
  File "/usr/lib/python3/dist-packages/khal/khalendar/event.py", line 
858, in create_timezone

for one, two in iter(tz._tzinfos.items())
AttributeError: '_PytzShimTimezone' object has no attribute '_tzinfos'


---

Also, there are a lot of warnings (not crashes though) when doing almost 
anything in ikhal or simply running khal list, like this:


/usr/lib/python3/dist-packages/khal/khalendar/event.py:543: 
PytzUsageWarning: The localize method is no longer necessary, as this 
time zone supports the fold attribute (PEP 495). For more details on 
migrating to a PEP 495-compliant implementation, see 
https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html

  end_local_datetime = self._locale['local_timezone'].localize(
/usr/lib/python3/dist-packages/khal/khalendar/event.py:546: 
PytzUsageWarning: The localize method is no longer necessary, as this 
time zone supports the fold attribute (PEP 495). For more details on 
migrating to a PEP 495-compliant implementation, see 
https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html

  day_start = self._locale['local_timezone'].localize(
/usr/lib/python3/dist-packages/khal/khalendar/event.py:549: 
PytzUsageWarning: The localize method is no longer necessary, as this 
time zone supports the fold attribute (PEP 495). For more details on 
migrating to a PEP 495-compliant implementation, see 
https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html

Bug#1017784: RM: dpdk [armhf] -- NBS; package no longer built on armhf

[Luca Boccassi]

On Sat, 20 Aug 2022 14:10:35 +0300 Adrian Bunk  wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> dpdk (21.11-1) experimental; urgency=medium
> 
>   [ Christian Ehrhardt ]
> ...
>   * d/control: drop armhf builds
> ...
>  -- Luca Boccassi   Mon, 29 Nov 2021 12:47:03 +

Thanks Adrian, I was about to file this myself, as I had forgotten
yesterday evening.

For reference, while armhf builds are somewhat supported, upstream
really focuses on arm64 and we are not aware of any usage of armhf.
None of the reverse dependencies in Debian and Ubuntu build against
libdpdk-dev armhf, they all skip it.

-- 
Kind regards,
Luca Boccassi


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

Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles

[Luca Boccassi]

On Sat, 20 Aug 2022 at 13:51, Santiago Vila  wrote:
>
> El 20/8/22 a las 14:40, Santiago Vila escribió:
> > So I wonder if reversing the dependency created by debhelper:
> >
> > systemd | systemd-tmpfiles
> >
> > would improve this state of things.
>
> Sorry, the above is confusing. I mean reversing the *order*, so that it
> becomes this:
>
> systemd-tmpfiles | systemd
>
> The issue here is that those who don't have systemd already installed
> (either chroots, non-Linux architectures, or containers) will probably
> consider undesirable that systemd is now installed on upgrades.
>
> Thanks.

I think we do want the default implementation to be pulled in by
default, this has already been discussed last time. The standalone
packages are not the default, are way less tested, and are simply
provided for compatibility for !systemd installations, which again are
not the default.

There's nothing wrong with having the binary systemd package installed
in a chroot - if one doesn't want it, they just have to specify they
want the -standalone variant and things will work out just fine. This
is not really any different than any other defaults, e.g. if you want
dbus-broker instead of dbus-daemon you'll have to manually specify it,
as the default is dbus-daemon and that's what gets pulled in if
there's no other hint.

Kind regards,
Luca Boccassi

Bug#1017786: ITP: kokkos -- C++ Performance Portability Programming

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: kokkos
  Version : 3.6.01
  Upstream Authors: Christian R. Trott 
  URL : https://github.com/kokkos/kokkos
* License : BSD-3-clause
  Description : C++ Performance Portability Programming
 This implements a programming model in C++ for writing performance
 portable applications targeting all major HPC platforms. For that 
purpose it
 provides abstractions for both parallel execution of code and data 
management.
 Kokkos is designed to target complex node architectures with N-level 
memory
 hierarchies and multiple types of execution resources. It currently can 
use
 CUDA, HPX, OpenMP and Pthreads as backend programming models with 
several other

 backends in development.

Bug#1017727: autoconf-archive: ax_cc_maxopt.m4 change breaks code due to syntax error

[Jerome BENOIT]

Hello,

the issue was fixed  in the upstream version, serial 23 :

https://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_cc_maxopt.m4

hth,
Jerome
--
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1015126: cool-retro-term: FTBFS: make[2]: *** No rule to make target 'qml/fonts/1971-ibm-3278/3270-Regular.ttf', needed by 'qrc_resources.cpp'. Stop.

[Gürkan Myczko]

Hi Reiner,

> On 20 Aug 2022, at 14:33, Reiner Herrmann  wrote:
> 
> Control: tags -1 + patch
> 
> Hi,
> 
>> make[2]: *** No rule to make target 
>> 'qml/fonts/1971-ibm-3278/3270-Regular.ttf', needed by 'qrc_resources.cpp'.  
>> Stop.
> 
> this is broken since src:3270font 3.0.0-2:
> 
>>   * Install TTF not OTF, the latter produces uneven glyphs somehow.
> 
> app/qml/fonts/1971-ibm-3278/3270-Regular.ttf was a symlink to the otf
> file (/usr/share/fonts/opentype/3270/3270-Regular.otf), which is no
> longer available.
> 
> The attached patch fixes the FTBFS by replacing the symlink with a link
> to the ttf file.

> Kind regards,
>  Reiner
> 

Thank you so much, will apply ASAP!

Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles

[Santiago Vila]

El 20/8/22 a las 14:40, Santiago Vila escribió:

So I wonder if reversing the dependency created by debhelper:

systemd | systemd-tmpfiles

would improve this state of things.


Sorry, the above is confusing. I mean reversing the *order*, so that it 
becomes this:


systemd-tmpfiles | systemd

The issue here is that those who don't have systemd already installed 
(either chroots, non-Linux architectures, or containers) will probably 
consider undesirable that systemd is now installed on upgrades.


Thanks.

Bug#1016423: Fix applied upstream

[Jeremy Stanley]

This is now addressed upstream in the following commit, so you
should be able to drop the patch when packaging the next release
(whenever that happens):

https://gitlab.xiph.org/xiph/ezstream/-/commit/c9426f2

Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles

[Santiago Vila]

Hello.

As of today, upgrading a sid chroot containing debhelper to the sid of 
today, systemd, mount, and several other packages are installed into the 
chroot. This is usually undesired because we want build chroots to be as 
minimal as possible.


Users of debootstrap can certainly use --include and --exclude to 
fine-tune the contents of the chroot, but as a user of debootstrap, I 
would expect it to do the right thing (minimal chroot) by default and 
without having to fine-tune it.


On amd64, I've checked that installing systemd-standalone-tmpfiles 
allows systemd and all the extra packages to be removed again.


So I wonder if reversing the dependency created by debhelper:

systemd | systemd-tmpfiles

would improve this state of things.

(Trimming Cc list a little bit, I don't want to spam everybody)

Thanks.

Bug#1017785: golang-github-templexxx-cpu FTBFS on riscv64

[Adrian Bunk]

Source: golang-github-templexxx-cpu
Version: 0.0.9-2
Severity: important
Tags: ftbfs patch fixed-upstream
Forwarded: https://github.com/templexxx/cpu/pull/8
Control: affects -1 src:snowflake src:kcptun

https://buildd.debian.org/status/fetch.php?pkg=kcptun=riscv64=20210922%2Bds-1%2Bb2=1660738510=0
https://buildd.debian.org/status/fetch.php?pkg=snowflake=riscv64=2.2.0-4%2Bb1=1660744194=0

...
# github.com/templexxx/cpu
src/github.com/templexxx/cpu/cpu_riscv64.go:9:6: doinit redeclared in this block
src/github.com/templexxx/cpu/cpu_no_init.go:15:6: other declaration of 
doinit
...

Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)

[Tobias Frost]

On Sun, Aug 07, 2022 at 02:44:05PM +0200, Michael Biebl wrote:
> On Sun, 2 Jan 2022 16:12:16 +0100 Tobias Frost  wrote:
> > On Sun, Jan 02, 2022 at 03:24:57PM +0100, Michael Biebl wrote:
> > > > Control: tags -1 + moreinfo unreproducible
> > > > On 02.01.22 14:52, Tobias Frost wrote:
> > > > > Please let me know if there are additional details I could supply.
> > > > > > > Can you provide steps how to reproduce the issue?
> > 
> > > More details how the container is constructed, which fs is used etc. might
> > > help as well.
> > 
> > When I find a way to reproduce, I'll let you know.
> > 
> 
> 
> Any news here?

Sorry, no news. Probably best is to close that bug, (ENOTIME from my side to 
investigate further)

-- 
tobi

Bug#1015272: liburing autopkgtest started to hang containers in Debian and Ubuntu since ~2022-07-11

[Guillem Jover]

Hi!


On Tue, 2022-07-19 at 08:28:09 +0200, Paul Gevers wrote:
> On 18-07-2022 23:44, Guillem Jover wrote:
> > While only having skimmed over the logs, the first suspect for me would
> > be the Linux kernel, where liburing might be triggering some kernel bug.
> > Were the systems upgraded around that time with a newer kernel version
> > (is that a 5.18.x from bpo)?
> 
> In Debian we did have a point release on 2022-07-09, I upgraded that evening
> (UTC).

So this seems to confirm that the problem lays elsewhere. :)

> > The only other options if that would not
> > have been the case that seem plausible would be glibc (which was uploaded
> > on the 10th, and could be a suspect), or lxc itself or similar, but that
> > has not been uploaded for a while in sid.
> 
> lxc comes from stable. Everything in it is either unstable or testing.
> 
> I'm not totally sure about the Ubuntu setup. Maybe Brian can comment on
> that.

The liburing test suite works on the buildds, I just uploaded a new
release and it built fine locally with Linux 5.19.0-trunk-amd64, and
on the buildds. I think this needs to be reassigned, I'd assume to the
kernel (but I'm not entirely sure).

Also could a newer kernel be tried on the infra?

Thanks,
Guillem

Bug#1017053: closed by Drew Parsons (reply to dpars...@debian.org) (Re: Bug#1017053 fenics-dolfinx: FTBFS on mips64el)

[Graham Inggs]

Hi Drew

> This is pmix bug#1017356, hopefully fixed in pmix 4.2.0~rc2-1 (not clear
> why the pmix upload did not close the bug).

I don't believe it is.  The FTBFS on mips64el [1] started before the
pmix upload.

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=fenics-dolfinx=mips64el

Bug#1017784: RM: dpdk [armhf] -- NBS; package no longer built on armhf

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

dpdk (21.11-1) experimental; urgency=medium

  [ Christian Ehrhardt ]
...
  * d/control: drop armhf builds
...
 -- Luca Boccassi   Mon, 29 Nov 2021 12:47:03 +

Bug#960640: bash-completion: dh_bash-completion needs to record installed files for dh_missing

[David Prévot]

Hi,

Le Sun, Aug 30, 2020 at 09:24:14AM -0700, Nicholas Breen a écrit :

> As an example package demonstrating this bug […]

Latest composer (2.4.0-1) also triggered it. I worked around the issue
by declaring the file in debian/not-installed. Without it, an explicit
error message suggested to…


  reference the
  "Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)

Regards

David


signature.asc
Description: PGP signature

Bug#672699: ITP: spectrum2 -- XMPP transport/gateway

[Tobias Frost]

Hi Thorsten,

I've just found out about this bug. My plan is also to package
spectrum2; for that I've already packaged libcommuni and also
working on swift-im (in a state that it compiles now, but still needs
significant polishing)

Should we team up?

-- 
tobi

Bug#672699: ITP: spectrum2 -- XMPP transport/gateway

[Tobias Frost]

Hi Thorsten,

I've just found out about this bug. My plan is also to package
spectrum2; for that I've already packaged libcommuni and also
working on swift-im (in a state that it compiles now, but still needs
significant polishing)

Should we team up?

-- 
tobi

Bug#1017783: RFS: tablix2/0.3.5-4 [QA] -- Kernel for solving general timetabling problems

[Hugh McMaster]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tablix2
   Version : 0.3.5-4
   Upstream Author : Tomaž Šolc 
 * URL : https://www.tablix.org
 * License : LGPL-2+, LGPL-2.1+, TinyScheme-BSD-3-Clause,
GPL-2+, public-domain, HPND-sell-variant
 * Vcs : [fill in URL of packaging vcs]
   Section : misc

The source builds the following binary packages:

  tablix2 - Kernel for solving general timetabling problems
  tablix2-doc - Kernel for solving general timetabling problems (documentation)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tablix2/tablix2_0.3.5-4.dsc

Changes since the last upload:

 tablix2 (0.3.5-4) unstable; urgency=medium
 .
   * QA upload.
   * Set Maintainer to Debian QA Group (see #994647).
   * Convert package to '3.0 (quilt)' format (Closes: #1007512).
   * debian/control:
 + Priority: extra -> optional.
 + Switch to debhelper-compat v13 and drop debian/compat file.
 + Build-Depends: add pkg-config; remove dh-autoreconf.
 + Raise Standards-Version to 4.6.1 from 3.9.8 (no changes needed).
 + Update package description.
 + Use HTTPS protocol.
 + Add documentation and examples package (tablix2-doc).
 + Declare Rules-Requires-Root: no.
 + Trim trailing whitespace.
 + Suggest gnuplot instead of Recommending it.
   * debian/copyright: Convert to DEP-5 format and update.
   * debian/patches:
 + Remove references to 'debian' from upstream build files.
 + Remove hard-coded 'localedir' override from configure.in.
 + Use pkg-config to find libxml2 (Closes: #949502).
 + Fix spelling and syntax errors in the man pages.
   * debian/rules:
 + Use the 'dh' build system (Closes: #949600).
 + Add hardening flags to DEB_BUILD_MAINT_OPTIONS.
   * debian/upstream: Add metadata file.
   * debian/watch: Update version, repository URL and archive regex.
   * tablix2: Don't install the *.la files (Closes: #810271).
   * tablix2.docs: Add doc-base file.
   * Override some Lintian warnings.

Regards,
-- 
  Hugh McMaster

Bug#1017765: (no subject)

[Jochen Sprickerhof]

Hi Sylvestre,,

* Sylvestre Ledru  [2022-08-19 23:46]:

Could you please provide a reduce test case?


Sure, this produces the same error with clang++-14 on armel but works with
clang++-13 and gcc:

template  void psincos_float(Packet &_x) {
  __asm__("" : "+g,w"(_x));
}
int main() {}

Some context to the function is here:

https://gitlab.com/libeigen/eigen/-/commit/82d61af3a490154ad1c0ae2fe00c561095854897#859198abc81bc7db86d6add0a16b27c957a7358b_1066_1070

Cheers Jochen

* Sylvestre Ledru  [2022-08-19 23:46]:

Hello

Could you please provide a reduce test case?

Thanks
Sylvestre
On 2022-08-19 23:34, Jochen Sprickerhof wrote:

Package: clang-14
Version: 1:14.0.6-2
Severity: normal
X-Debbugs-Cc: jspri...@debian.org
Control: affects -1 libeigen3-dev src:pcl

Hi,

on an up to date armel:

jspricke@harris:~$ dd-schroot-cmd -c $sessionid apt-get install
clang-13 clang-14 libeigen3-dev
(sid_armel-dchroot)jspricke@harris:~$ echo -e "#include
\nint main() {}" > eigen.cpp
(sid_armel-dchroot)jspricke@harris:~$ clang++-14 -I
/usr/include/eigen3 eigen.cpp
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:641:3:
error: invalid output constraint '+g,w' in asm
 EIGEN_OPTIMIZATION_BARRIER(y_round)
 ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note:
expanded from macro 'EIGEN_OPTIMIZATION_BARRIER'
 #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" 
(X));

   ^
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:663:3:
error: invalid output constraint '+g,w' in asm
 EIGEN_OPTIMIZATION_BARRIER(x)
 ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note:
expanded from macro 'EIGEN_OPTIMIZATION_BARRIER'
 #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" 
(X));

   ^
In file included from eigen.cpp:1:
In file included from /usr/include/eigen3/Eigen/Core:250:
/usr/include/eigen3/Eigen/src/Core/arch/Default/GenericPacketMathFunctions.h:665:3:
error: invalid output constraint '+g,w' in asm
 EIGEN_OPTIMIZATION_BARRIER(x)
 ^
/usr/include/eigen3/Eigen/src/Core/util/Macros.h:1134:61: note:
expanded from macro 'EIGEN_OPTIMIZATION_BARRIER'
 #define EIGEN_OPTIMIZATION_BARRIER(X)  __asm__  ("" : "+g,w" 
(X));

   ^
3 errors generated.

(sid_armel-dchroot)jspricke@harris:~$ clang++-13 -I
/usr/include/eigen3 eigen.cpp
(sid_armel-dchroot)jspricke@harris:~$ g++ -I /usr/include/eigen3 
eigen.cpp


This currently breaks src:pcl, can you have a look?

Cheers Jochen


-- System Information:
Debian Release: bookworm/sid
 APT prefers unstable-debug
 APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: armel (armv7l)

Kernel: Linux 4.19.0-21-armmp (SMP w/1 CPU thread)
Kernel taint flags: TAINT_DIE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages clang-14 depends on:
ii  binutils2.38.90.20220713-2
ii  libatomic1  12.1.0-8
ii  libc6   2.34-4
ii  libc6-dev   2.34-4
ii  libclang-common-14-dev  1:14.0.6-2
ii  libclang-cpp14  1:14.0.6-2
ii  libclang1-141:14.0.6-2
ii  libgcc-12-dev   12.1.0-8
ii  libgcc-s1   12.1.0-8
ii  libllvm14   1:14.0.6-2
ii  libobjc-12-dev  12.1.0-8
ii  libstdc++-12-dev12.1.0-8
ii  libstdc++6  12.1.0-8
ii  llvm-14-linker-tools1:14.0.6-2

Versions of packages clang-14 recommends:
pn  llvm-14-dev  
ii  python3  3.10.6-1

Versions of packages clang-14 suggests:
pn  clang-14-doc  

-- no debconf information




signature.asc
Description: PGP signature

Bug#1017781: ghc: fails to install

[Holger Levsen]

Package: ghc
Version: 9.0.2-3
Severity: serious

Dear Maintainer,

Setting up ghc (9.0.2-3) ...
/usr/lib/ghc/bin/ghc: error while loading shared libraries: 
libHShaskeline-0.8.2-ghc9.0.2.so: cannot open shared object file: No such file 
or directory
/usr/lib/ghc/bin/ghc-pkg: error while loading shared libraries: 
libHSterminfo-0.4.1.5-ghc9.0.2.so: cannot open shared object file: No such file 
or directory
dpkg: error processing package ghc (--configure):
 installed ghc package post-installation script subprocess returned error exit 
status 127
[...]
Errors were encountered while processing:
 ghc
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- 
cheers,
Holger

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

The mark of a civilized man is the ability to look at a column of numbers and
weep. (Bertrand Russell)


signature.asc
Description: PGP signature

Bug#1017779: emacs-common dies in postinst with "corrupted double-linked list"

[Harald Dunkel]

Package: emacs-common
Version: 1:28.1+1-1

emacs-common can't be upgraded:

# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  libgccjit0
The following packages will be upgraded:
  emacs-bin-common emacs-common emacs-lucid
3 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/28.9 MB of archives.
After this operation, 51.6 MB of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 239890 files and directories currently installed.)
Preparing to unpack .../emacs-lucid_1%3a28.1+1-1_amd64.deb ...
Remove dictionaries-common for emacs
remove/dictionaries-common: Purging byte-compiled files for flavour emacs
Remove emacsen-common for emacs
emacsen-common: Handling removal of emacsen flavor emacs
Unpacking emacs-lucid (1:28.1+1-1) over (1:27.1+1-3.1+b1) ...
Preparing to unpack .../emacs-bin-common_1%3a28.1+1-1_amd64.deb ...
Unpacking emacs-bin-common (1:28.1+1-1) over (1:27.1+1-3.1+b1) ...
Preparing to unpack .../emacs-common_1%3a28.1+1-1_all.deb ...
Unpacking emacs-common (1:28.1+1-1) over (1:27.1+1-3.1) ...
Selecting previously unselected package libgccjit0:amd64.
Preparing to unpack .../libgccjit0_12.1.0-8_amd64.deb ...
Unpacking libgccjit0:amd64 (12.1.0-8) ...
Setting up emacs-common (1:28.1+1-1) ...
Setting up libgccjit0:amd64 (12.1.0-8) ...
Setting up emacs-bin-common (1:28.1+1-1) ...
Setting up emacs-lucid (1:28.1+1-1) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
corrupted double-linked list
Fatal error 6: Aborted
Backtrace:
emacs(+0x14c5a1)[0x556443a185a1]
emacs(+0x45c8d)[0x556443911c8d]
emacs(+0x4615a)[0x55644391215a]
emacs(+0x14a8cd)[0x556443a168cd]
emacs(+0x14a9b9)[0x556443a169b9]
/lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7f41a6c3daf0]
/lib/x86_64-linux-gnu/libc.so.6(+0x8983c)[0x7f41a6c8983c]
/lib/x86_64-linux-gnu/libc.so.6(raise+0x12)[0x7f41a6c3da52]
/lib/x86_64-linux-gnu/libc.so.6(abort+0xcf)[0x7f41a6c28469]
/lib/x86_64-linux-gnu/libc.so.6(+0x7dc18)[0x7f41a6c7dc18]
/lib/x86_64-linux-gnu/libc.so.6(+0x9355a)[0x7f41a6c9355a]
/lib/x86_64-linux-gnu/libc.so.6(+0x93e9c)[0x7f41a6c93e9c]
/lib/x86_64-linux-gnu/libc.so.6(+0x967a1)[0x7f41a6c967a1]
/lib/x86_64-linux-gnu/libc.so.6(malloc+0x95)[0x7f41a6c97275]
emacs(+0x18e3e5)[0x556443a5a3e5]
emacs(+0x18e576)[0x556443a5a576]
emacs(+0x18e7b2)[0x556443a5a7b2]
emacs(+0x18e980)[0x556443a5a980]
emacs(+0x1a64ac)[0x556443a724ac]
emacs(+0x1d7771)[0x556443aa3771]
emacs(+0x1d8173)[0x556443aa4173]
emacs(+0x1dba18)[0x556443aa7a18]
emacs(+0x1dc6da)[0x556443aa86da]
emacs(+0x1b0be2)[0x556443a7cbe2]
emacs(+0x1b0eb0)[0x556443a7ceb0]
emacs(+0x1b107f)[0x556443a7d07f]
emacs(+0x1d7795)[0x556443aa3795]
emacs(+0x1d8173)[0x556443aa4173]
emacs(+0x1dba18)[0x556443aa7a18]
emacs(+0x1dc6da)[0x556443aa86da]
emacs(+0x1b0be2)[0x556443a7cbe2]
emacs(+0x1b0eb0)[0x556443a7ceb0]
emacs(+0x1b107f)[0x556443a7d07f]
emacs(+0x1d7795)[0x556443aa3795]
emacs(+0x1d8173)[0x556443aa4173]
emacs(+0x1dba18)[0x556443aa7a18]
emacs(+0x1dc6da)[0x556443aa86da]
emacs(+0x1b0be2)[0x556443a7cbe2]
emacs(+0x1b0eb0)[0x556443a7ceb0]
emacs(+0x1b107f)[0x556443a7d07f]
emacs(+0x1d7795)[0x556443aa3795]
...
Aborted
ERROR: install script from emacsen-common package failed
dpkg: error processing package emacs-lucid (--configure):
 installed emacs-lucid package post-installation script subprocess returned 
error exit status 1
Processing triggers for mailcap (3.70+nmu1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for libc-bin (2.34-4) ...
Processing triggers for man-db (2.10.2-2) ...
Processing triggers for install-info (6.8-6) ...
Errors were encountered while processing:
 emacs-lucid
[master 8d1ca7c9] committing changes in /etc made by "apt upgrade"
 1 file changed, 17 insertions(+)
E: Sub-process /usr/bin/dpkg returned an error code (1)


Regads
Harri

Bug#1017778: vcfanno: Please replace golang-toml-dev with golang-github-burntsushi-toml-dev

[Shengjing Zhu]

Source: vcfanno
Version: 0.3.3+ds-1
Severity: normal
X-Debbugs-Cc: z...@debian.org

golang-toml-dev is removed 1 year ago, but your package still build-depends on 
it.

Bug#1016754: po4a: Incorrect bold handling for manpages bug 2

[Martin Quinson]

- Le 20 Aoû 22, à 5:24, Helge Kreutzmann deb...@helgefjell.de a écrit :

> Hello Martin,
> On Sat, Aug 20, 2022 at 02:25:36AM +0200, Martin Quinson wrote:
>> thanks for the additional info.
>> 
>> Could you please try to reduce the files to simplify my debugging effort? 
>> It'd
>> be great if you could come up with a file as simple as possible, ie, one 
>> short
>> paragraph only if possible, and using UPPERCASE as a translation instead of
>> german. We have a lot of such files in our test suite. Search for example for
>> .man, .pot, .po and .trans files eg in t/fmt/man. (.norm is the normalized
>> file, ie the file after po4a parsing but with no translation while .trans is
>> the translated file, using the po file).
>> 
>> That would be really precious to me.
> 
> I'll try, however, it might take some time.

If it takes too long, then don't convert from German to upperside fake locale. 
Reducing the example is the most important.

Thanks, 
Mt

Bug#1017742: po4a: Please provide marker for double strings during po4a-gettextize

[Martin Quinson]

- Le 19 Aoû 22, à 21:13, Helge Kreutzmann deb...@helgefjell.de a écrit :

> Package: po4a
> Version: 0.67-2
> Severity: wishlist
> 
> Since recently po4a-gettextize adds spaces at the end of strings
> during gettextisation, if strings occure multiple times in the master
> file (or translation).
> 
> In production, multiple indentical strings in the original file are
> only stored once in the po file (as they are translated the same).
> 
> Therefore, translators need to review those strings carefully and
> remove those entries from the po file, which have this final space
> added. In this process they need to choose the most appropriate
> translation to keep.
> 
> Currently, this can be quite difficult, as the string can occur
> multiple times and the trailing space(s) are difficult to spot in
> large files. Also these trailing spaces are hard to get a good regular
> expression for searching.
> 
> Therefor I kindly ask you if you could mark those strings in addition
> (!) with a suitable translator comment (e.g. "Potential duplicate
> string, review and consolidate"). This would users allow to use msggrep(1)
> with the option -C to filter them out for review.
> 
> Thanks for considering.

Your bug report makes me realize that the current behavior is perfectly broken. 
I was hopping for the next msgmerge to merge the alternative translations of 
the same msgid, but I realize that they will most probably be dropped in the 
process. 

Mmm. Let me think about it, I'll try to reimplement this thing so that the 
carful review that you describe becomes automatically done during the 
gettexization.

Many thanks for reporting,
Mt

Bug#1017776: elpa-ledger: Breaks upgrade to Emacs 28.1

[intrigeri]

Package: elpa-ledger
Version: 3.1.2~pre3+g5067e408-2
Severity: serious

Hi,

When upgrading my sid system today, which included the upgrade to
Emacs 28.1, byte-compilation of the ledger .el files failed,
which broke the upgrade. See log below.

I understand that's because define-obsolete-function-alias now needs
3 arguments. Indeed, applying this fix from upstream Git fixed the problem for
me:

https://github.com/ledger/ledger-mode/commit/bcd8cefb720702db88986a52bb66e08e2e451c05

Thanks for maintaining ledger-mode in Debian! :)

Failure log:

  Install elpa-ledger for emacs
  install/ledger-3.1.2: Handling install of emacsen flavor emacs
  install/ledger-3.1.2: byte-compiling for emacs
  Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
  Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
  Error loading autoloads: (wrong-number-of-arguments (3 . 4) 2)
  Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
  Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

  In toplevel form:
  ledger-check.el:31:1: Error: Wrong number of arguments: (3 . 4), 2

  In ledger-string-to-number:
  ledger-commodities.el:112:8: Warning: docstring wider than 80 characters

  In ledger-accounts-list-in-buffer:
  ledger-complete.el:93:8: Warning: docstring wider than 80 characters

  In ledger-single-line-config:
  ledger-context.el:55:11: Warning: docstring wider than 80 characters

  In toplevel form:
  ledger-exec.el:33:1: Warning: defvar `ledger-works' docstring wider than 80
  characters

  In ledger-exec-success-p:
  ledger-exec.el:61:8: Warning: docstring wider than 80 characters

  In ledger-version-greater-p:
  ledger-exec.el:96:8: Warning: docstring wider than 80 characters
  ../../elpa-src/ledger-3.1.2/ledger-occur.el: Warning: Use keywords rather 
than deprecated positional arguments to `define-minor-mode'
  Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
  Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

  In toplevel form:
  ledger-mode.el:48:1: Error: Wrong number of arguments: (3 . 4), 2

  In ledger-navigate-skip-lines-backwards:
  ledger-navigate.el:100:8: Warning: docstring wider than 80 characters

  In toplevel form:
  ledger-occur.el:37:1: Warning: custom-declare-variable
  `ledger-occur-use-face-shown' docstring wider than 80 characters
  ledger-occur.el:58:39: Warning: Use keywords rather than deprecated positional
  arguments to `define-minor-mode'

  In ledger-occur-mode:
  ledger-occur.el:58:39: Warning: docstring wider than 80 characters

  In ledger-occur-find-matches:
  ledger-occur.el:137:8: Warning: docstring wider than 80 characters

  In ledger-post-align-postings:
  ledger-post.el:96:8: Warning: docstring wider than 80 characters

  In toplevel form:
  ledger-reconcile.el:56:1: Warning: custom-declare-variable
  `ledger-narrow-on-reconcile' docstring wider than 80 characters
  ledger-reconcile.el:61:1: Warning: custom-declare-variable
  `ledger-buffer-tracks-reconcile-buffer' docstring wider than 80 characters
  ledger-reconcile.el:67:1: Warning: custom-declare-variable
  `ledger-reconcile-force-window-bottom' docstring wider than 80 characters
  ledger-reconcile.el:119:1: Warning: custom-declare-variable
  `ledger-reconcile-sort-key' docstring wider than 80 characters
  ledger-reconcile.el:126:1: Warning: custom-declare-variable
  `ledger-reconcile-insert-effective-date' docstring wider than 80
  characters

  In ledger-do-reconcile:
  ledger-reconcile.el:445:8: Warning: docstring wider than 80 characters

  In ledger-reconcile-ensure-xacts-visible:
  ledger-reconcile.el:477:8: Warning: docstring wider than 80 characters

  In ledger-reconcile-track-xact:
  ledger-reconcile.el:494:8: Warning: docstring wider than 80 characters

  In toplevel form:
  ledger-report.el:88:1: Warning: custom-declare-variable
  `ledger-report-auto-refresh-sticky-cursor' docstring wider than 80
  characters
  ledger-report.el:592:1: Error: Wrong number of arguments: (3 . 4), 2

  In ledger-schedule-constrain-every-count-day:
  ledger-schedule.el:128:8: Warning: docstring wider than 80 characters

  In ledger-schedule-constrain-date-range:
  ledger-schedule.el:136:8: Warning: docstring wider than 80 characters

  In ledger-schedule-list-upcoming-xacts:
  ledger-schedule.el:277:8: Warning: docstring wider than 80 characters

  In ledger-sort-startkey:
  ledger-sort.el:61:8: Warning: docstring wider than 80 characters

  In toplevel form:
  ledger-texi.el:128:1: Warning: Variable ‘output’ left uninitialized
  ledger-texi.el:128:1: Warning: Variable ‘input’ left uninitialized

  In toplevel form:
  ledger-xact.el:138:1: Warning: defvar
  `ledger-copy-transaction-insert-blank-line-after' docstring wider than 80
  characters

  In ledger-copy-transaction-at-point:
  ledger-xact.el:141:8: Warning: docstring wider than 80 characters
  ERROR: install script from