Bug#1025106: python-icecream: (autopkgtest) needs update for python3.11: ValueError: not enough values to unpack (expected 2, got 1)

[s3v]

Dear Maintainer,

After upload of executing/1.2.0 to unstable, your package builds
fine and all tests pass (both with python3.10 and python3.11).
I've checked in a sid (not bookworm) chroot environment.

Kind Regards

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

Bug#1026879: gnucash: Date format does not respect preferences

[Jeffrey Ratcliffe]

Package: gnucash
Version: 1:4.12-1+b1
Severity: normal
Tags: l10n

Dear Maintainer,

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

   * What led up to the situation?

Long time (> 10 years), daily user. Not had to change the preferences in years.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Started gscan2pdf as usual.

   * What was the outcome of this action?

Various settings not respected:
* the previous set of accounts was not automatically loaded
* the previous set of accounts was not available via "recent".
* having loaded the previous set of accounts, the default light/dark green
account theme was not used
* despite ISO date format being set in Edit/Preferences, the US format used.

   * What outcome did you expect instead?

Gnucash to load the previous set of account with the default light/dark green
account theme and ISO date format.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 gnucash depends on:
ii  gnucash-common 1:4.12-1
ii  guile-2.2  2.2.7+1-6+b1
ii  guile-3.0-libs 3.0.8-2
ii  libaqbanking44 6.5.3-1
ii  libboost-filesystem1.74.0  1.74.0-17+b2
ii  libboost-locale1.74.0  1.74.0-17+b2
ii  libboost-program-options1.74.0 1.74.0-17+b2
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu72]  1.74.0-17+b2
ii  libc6  2.36-6
ii  libcairo2  1.16.0-7
ii  libcrypt-ssleay-perl   0.73.06-2+b1
ii  libdate-manip-perl 6.90-1
ii  libdbi10.9.0-6
ii  libfinance-quote-perl  1.53-2
ii  libgcc-s1  12.2.0-10
ii  libgdk-pixbuf-2.0-02.42.10+dfsg-1
ii  libglib2.0-0   2.74.2-1
ii  libgtk-3-0 3.24.35-3
ii  libgwengui-gtk3-79 5.10.1-1
ii  libgwenhywfar795.10.1-1
ii  libhtml-tableextract-perl  2.15-2
ii  libhtml-tree-perl  5.07-3
ii  libicu72   72.1-3
ii  libofx71:0.10.9-1
ii  libpango-1.0-0 1.50.10+ds-1
ii  libpangocairo-1.0-01.50.10+ds-1
ii  libpython3.10  3.10.9-1
ii  libsecret-1-0  0.20.5-3
ii  libstdc++6 12.2.0-10
ii  libwebkit2gtk-4.0-37   2.38.2-1+b1
ii  libwww-perl6.67-1
ii  libxml22.9.14+dfsg-1.1+b2
ii  perl   5.36.0-6
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages gnucash recommends:
ii  gnucash-docs 4.12-1
ii  python3-gnucash  1:4.12-1+b1
ii  yelp 42.2-1

Versions of packages gnucash suggests:
pn  libdbd-mysql
pn  libdbd-pgsql
ii  libdbd-sqlite3  0.9.0-11

-- no debconf information

Bug#1026878: kwin_xkbcommon: XKB: inet:334:58: unrecognized keysym "XF86EmojiPicker"

[Helge Kreutzmann]

Package: kwin-x11
Version: 4:5.26.4-1
Severity: minor

During Plasma startup, I always get this message. If this is harmless,
please add a logcheck filter.


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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kwin-x11 depends on:
ii  kwin-common4:5.26.4-1
ii  libc6  2.36-6
ii  libepoxy0  1.5.10-1
ii  libgcc-s1  12.2.0-10
ii  libkdecorations2-5v5   4:5.26.4-1
ii  libkf5configcore5  5.101.0-1
ii  libkf5configgui5   5.101.0-1
ii  libkf5configwidgets5   5.101.0-1
ii  libkf5coreaddons5  5.101.0-1
ii  libkf5crash5   5.101.0-1
ii  libkf5globalaccel-bin  5.101.0-1
ii  libkf5globalaccel5 5.101.0-1
ii  libkf5i18n55.101.0-1
ii  libkf5notifications5   5.101.0-1
ii  libkf5plasma5  5.101.0-1
ii  libkf5service-bin  5.101.0-1
ii  libkf5service5 5.101.0-1
ii  libkf5windowsystem55.101.0-2
ii  libkwineffects14   4:5.26.4-1
ii  libkwinglutils14   4:5.26.4-1
ii  libqaccessibilityclient-qt5-0  0.4.1-1+b1
ii  libqt5core5a   5.15.6+dfsg-5
ii  libqt5dbus55.15.6+dfsg-5
ii  libqt5gui5 5.15.6+dfsg-5
ii  libqt5qml5 5.15.6+dfsg-2
ii  libqt5quick5   5.15.6+dfsg-2
ii  libqt5widgets5 5.15.6+dfsg-5
ii  libqt5x11extras5   5.15.6-2
ii  libstdc++6 12.2.0-10
ii  libx11-6   2:1.8.1-2
ii  libxcb-composite0  1.15-1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb-randr0  1.15-1
ii  libxcb-render0 1.15-1
ii  libxcb-shape0  1.15-1
ii  libxcb-xfixes0 1.15-1
ii  libxcb11.15-1
ii  libxi6 2:1.8-1+b1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

-- 
  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#1026858: Dependency on debconf dropped prematurely

[Gioele Barabucci]

Thanks Faidon for your analysis and Cyril for forwarding this bug report 
to me.


On Thu, 22 Dec 2022 23:06:05 +0100 Cyril Brulebois  wrote:

Faidon Liambotis  (2022-12-22):
> Going forward there are a few options:
>   * Revert the change and depend on debconf again. This is the safest
> option, as this has been the status quo since 2007.

That would look good to me.


As the original reporter of #1006492 and the author of the MR that 
removed that dependency, I agree [1] that, at the moment, the best 
course of action is to revert that change and re-instate cdebconf's 
dependency on debconf.


That removal was part of a bigger plan [2] whose execution got stuck [3] 
and will be resumed only post-freeze.


Regards,

[1] 
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/15#note_344632

[2] https://lists.debian.org/debian-boot/2022/08/msg00135.html
[3] https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/11

--
Gioele Barabucci

Bug#898706: gbp : debuild dpkg-buildpackage option support is buggy or not properly documented

[R, Kaushik]

Package: gbp
Version: 0.9.19
Severity: normal


The setting of Host  Architecture for package is buggy or not properly 
documented:

itworks only with -a (without a space), but not with -a 

(with a space) or --host-arch , which are accepted by

dpkg-buildpackage (and even documented as such). Either this

limitation should be removed or it should be properly documented

dh_gencontrol
make[1]: Leaving directory 
'/builds/oie-jupiter/product/interappcommunication/dds_packaging/rti-connext-dds/out-bullseye-i386/rti-connext-dds-6.1.0'
dh_md5sums
dh_builddeb
dpkg-deb: building package 'librticonnext-persistenceservice' in 
'../librticonnext-persistenceservice_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext' in 
'../librticonnext_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-routingservice' in 
'../librticonnext-routingservice_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-base' in 
'../librticonnext-base_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-monitoring' in 
'../librticonnext-monitoring_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-storageutils' in 
'../librticonnext-storageutils_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-recordingservicecore' in 
'../librticonnext-recordingservicecore_6.1.0-7_i386.deb'.
dpkg-genbuildinfo --build=binary
dpkg-genchanges --build=binary >../rti-connext-dds_6.1.0-7_i386.changes
dpkg-genchanges: info: binary-only upload (no source code included)
dpkg-source -i -I --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)
debuild: fatal error at line 1062:
can't open rti-connext-dds_6.1.0-7_amd64.changes for reading: No such file or 
directory
gbp:error: 'debuild -i -I -us -uc -b --host-arch i386' failed: it exited with 29

Same issue happens when using with git-buildpackage (gbp) only -ai386 works.

Bug#898706: gbp : debuild dpkg-buildpackage option support is buggy or not properly documented

[R, Kaushik]

Package: gbp
Version: 8.9.19
Severity: normal


The setting of Host  Architecture for package is buggy or not properly 
documented:

itworks only with -a (without a space), but not with -a 

(with a space) or --host-arch , which are accepted by

dpkg-buildpackage (and even documented as such). Either this

limitation should be removed or it should be properly documented

dh_gencontrol
make[1]: Leaving directory 
'/builds/oie-jupiter/product/interappcommunication/dds_packaging/rti-connext-dds/out-bullseye-i386/rti-connext-dds-6.1.0'
dh_md5sums
dh_builddeb
dpkg-deb: building package 'librticonnext-persistenceservice' in 
'../librticonnext-persistenceservice_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext' in 
'../librticonnext_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-routingservice' in 
'../librticonnext-routingservice_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-base' in 
'../librticonnext-base_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-monitoring' in 
'../librticonnext-monitoring_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-storageutils' in 
'../librticonnext-storageutils_6.1.0-7_i386.deb'.
dpkg-deb: building package 'librticonnext-recordingservicecore' in 
'../librticonnext-recordingservicecore_6.1.0-7_i386.deb'.
dpkg-genbuildinfo --build=binary
dpkg-genchanges --build=binary >../rti-connext-dds_6.1.0-7_i386.changes
dpkg-genchanges: info: binary-only upload (no source code included)
dpkg-source -i -I --after-build .
dpkg-buildpackage: info: binary-only upload (no source included)
debuild: fatal error at line 1062:
can't open rti-connext-dds_6.1.0-7_amd64.changes for reading: No such file or 
directory
gbp:error: 'debuild -i -I -us -uc -b --host-arch i386' failed: it exited with 29

Same issue happens when using with git-buildpackage (gbp) only -ai386 works.

Bug#1026877: opari2: please make the build reproducible

[Chris Lamb]

Source: opari2
Version: 2.0.7-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
opari2 could not be built reproducibly.

Patch attached that exports CFLAGS from dpkg-buildflags(1), ensuring
that -fdebug-prefix-map (and similar) to the underlying build system.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2022-12-23 05:22:27.671938667 +
--- b/debian/rules  2022-12-23 05:30:34.856752502 +
@@ -17,7 +17,7 @@
dh_autoreconf autoreconf -- -f -i . build-frontend
 
 override_dh_auto_configure:
-   ac_scorep_platform=linux dh_auto_configure -- --enable-shared
+   ac_scorep_platform=linux dh_auto_configure -- --enable-shared $(shell 
dpkg-buildflags --export=configure)
 
 override_dh_installdocs:
dh_installdocs

Bug#1026876: jamin: please make the build reproducible

[Chris Lamb]

Source: jamin
Version: 0.98.9~git20170111~199091~repack1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
jamin could not be built reproducibly.

Patch attached that exports CFLAGS from dpkg-buildflags(1), ensuring
that -fdebug-prefix-map (and similar) to the underlying build system.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2022-12-23 05:22:36.635962278 +
--- b/debian/rules  2022-12-23 05:28:12.940594471 +
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
 export CFLAGS += -fcommon -g
 
 %:

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

[Vagrant Cascadian]

On 2022-08-20, Vagrant Cascadian wrote:
> 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.

Pushed a fix for the pinebook-pro-rk3399 to the debian/sid branch by
pulling a patch from upstream:

  
https://salsa.debian.org/debian/u-boot/-/commit/2557bb1b4be611fb1d8f96d7de79914ca21fa2b6

This fix landed in upstream in 2023.01-rc4.


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

Still need to dig out the odroid-c2 and possibly troubleshoot if there
is something in the flashing process that has changed, or ... bisect
upstream git.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1026875: elan - update for rust-zip 0.6

[Peter Green]

Package: elan
Version: 1.4.2-2

We would like to update the zip crate to 0.6, I have uploaded the new version
to experimental to allow testing with it.

I bumped the dependency in elan and most of the code built fine, but there was
one chunk of code that failed.

let mtime = entry.last_modified().to_time().to_timespec();
let mtime = filetime::FileTime::from_unix_time(mtime.sec, 
mtime.nsec as u32);

zip 0.6 has moved from time 0.1 to time 0.3 and as a result of this the return
type of to_time() has changed from "Tm" to
"Result"

This raises a couple of issues, the first is that OffsetDateTime does not have a
to_timespec function, it does however have a unix_timestamp_nanos function which
can be used to achieve much the same goal.

The second though, is what to do about error handling. The old code in time 0.1
just blundered on if invalid values were supplied, but the new time 0.3 codepath
includes error checking. So that leaves the question of what to do if an error
happens during timestamp conversion, should some default value be used or
should the error be propagated to the caller.

My current patch takes the latter approach, passing the error up to the caller.

I have also raised this issue upstream at 
https://github.com/leanprover/elan/issues/85

At the present time, this bug report is filed for information, I still need
to check out the other reverse dependencies of rust-zip, and I would also like
feedback from upstream on this issue if possible.diff -Nru elan-1.4.2/debian/changelog elan-1.4.2/debian/changelog
--- elan-1.4.2/debian/changelog 2022-12-01 20:58:32.0 +
+++ elan-1.4.2/debian/changelog 2022-12-23 02:54:30.0 +
@@ -1,3 +1,10 @@
+elan (1.4.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update for rust-zip 0.6
+
+ -- Peter Michael Green   Fri, 23 Dec 2022 02:54:30 +
+
 elan (1.4.2-2) unstable; urgency=medium
 
   * Add lake symlink
diff -Nru elan-1.4.2/debian/control elan-1.4.2/debian/control
--- elan-1.4.2/debian/control   2022-12-01 20:52:28.0 +
+++ elan-1.4.2/debian/control   2022-12-23 02:10:54.0 +
@@ -24,7 +24,7 @@
  librust-toml-dev,
  librust-url-dev,
  librust-wait-timeout-dev,
- librust-zip-dev,
+ librust-zip-0.6-dev,
  librust-clap+atty-dev,
  librust-clap+strsim-dev,
  librust-clap+vec-map-dev,
@@ -41,7 +41,7 @@
  librust-openssl-probe-dev,
  librust-backtrace-sys-dev,
  librust-markdown-dev,
- librust-zip+time-dev,
+ librust-zip-0.6+time-dev,
  librust-zstd-dev,
  bash-completion
 Standards-Version: 4.6.1.0
diff -Nru elan-1.4.2/debian/patches/series elan-1.4.2/debian/patches/series
--- elan-1.4.2/debian/patches/series2022-12-01 20:52:28.0 +
+++ elan-1.4.2/debian/patches/series2022-12-23 02:13:45.0 +
@@ -1,2 +1,3 @@
 build.patch
 0002-dependencies.patch
+zip-0.6.patch
diff -Nru elan-1.4.2/debian/patches/zip-0.6.patch 
elan-1.4.2/debian/patches/zip-0.6.patch
--- elan-1.4.2/debian/patches/zip-0.6.patch 1970-01-01 00:00:00.0 
+
+++ elan-1.4.2/debian/patches/zip-0.6.patch 2022-12-23 02:54:30.0 
+
@@ -0,0 +1,87 @@
+Description: update for zip 0.6
+ Zip 0.6 moved from time 0.1 to time 0.3 which changes how timestamps are
+ handled.
+
+ The old implementation did not do any checking of validity during the
+ timestamp conversion process and just blundered on if an invalid timestamp
+ was supplied. The new implementation on the other hand can return an error.
+
+ This patch makes elan build with the new version of zip, currently it
+ handles the new error by passing it up to the caller.
+Author: Peter Michael Green 
+
+Index: elan-1.4.2/Cargo.toml
+===
+--- elan-1.4.2.orig/Cargo.toml
 elan-1.4.2/Cargo.toml
+@@ -47,7 +47,7 @@ time = "0.3.4"
+ toml = "0.5.8"
+ url = "2.2.0"
+ wait-timeout = "0.2.0"
+-zip = "0.5.9"
++zip = "0.6"
+ tar = ">=0.4.36"
+ flate2 = "1.0.14"
+ json = "0.12.4"
+Index: elan-1.4.2/src/elan-dist/Cargo.toml
+===
+--- elan-1.4.2.orig/src/elan-dist/Cargo.toml
 elan-1.4.2/src/elan-dist/Cargo.toml
+@@ -22,8 +22,9 @@ remove_dir_all = "0.7.0"
+ elan-utils = { path = "../elan-utils" }
+ error-chain = "0.12.4"
+ json = "0.12.4"
+-zip = "0.5.13"
++zip = "0.6"
+ filetime = "0.2.14"
++time = "0.3"
+ 
+ [target."cfg(not(windows))".dependencies]
+ libc = "0.2.88"
+Index: elan-1.4.2/src/elan-dist/src/component/package.rs
+===
+--- elan-1.4.2.orig/src/elan-dist/src/component/package.rs
 elan-1.4.2/src/elan-dist/src/component/package.rs
+@@ -122,8 +122,8 @@ impl<'a> ZipPackage<'a> {
+ }
+ }
+ } // make sure to close `dst` before setting mtime
+-let mtime = entry.last_modified().to_time().to_timespec();
+-let mtime = 

Bug#1026874: awscli installs a 5 million line manpage

[Noah Meyerhans]

Also it seems that generating this file triggers an OOM condition on
salsa. https://salsa.debian.org/noahm/awscli/-/jobs/3693800

Bug#1010120: found in stable

[Santiago Vila]

found 1010120 0.13.0-6
thanks

Bug#1026874: awscli installs a 5 million line manpage

[Noah Meyerhans]

Package: awscli
Version: 2.9.9-1
Severity: normal

Just making sure this is recorded:

The aws(1) man page installed by awscli 2.9.9-1 is not useful.  Ideally it
should be split up in to per service pages, e.g. aws-vpc(1), aws-ec2(2), etc.
for all services (some services already have their own pages, but most don't.)
But until then, it should be replaced by something more along the lines of the
`aws help` output.

$ ls -lh /usr/share/man/man1/aws.1.gz
-rw-r--r-- 1 root root 17M Dec 22 14:15 /usr/share/man/man1/aws.1.gz

doom:~$ time man aws 2> /dev/null | wc -l
5150024
man aws 2> /dev/null  134.93s user 17.01s system 191% cpu 1:19.53 total

Bug#1006179: [Pkg-clamav-devel] ClamAV 1.0.0 release candidate now available

[Andrew C Aitchison]

On Thu, 22 Dec 2022, Scott Kitterman wrote:


On Monday, December 12, 2022 10:45:57 PM EST Scott Kitterman wrote:

On Saturday, December 10, 2022 11:14:14 AM EST Sebastian Andrzej Siewior

wrote:

On 2022-12-07 12:51:30 [-0500], Scott Kitterman wrote:

OK.  I'm back to having some time for Debian again, so let me know how I
can help.


I pushed something to the experimental branch. It ain't much…
This updates the build dependencies and you still need download the
upstream .tar.gz yourself for 1.0.0. uscan is a bit of help. The split
script isn't working anymore.


Looks like it needs an some rewrite.  I guess we are in the land of CMake
now as the configure.ac files it expects to find don't exist now.


The llvm code is gone from the archive. This is the only good new. We
probably need to patch clamav to take the tfm library instead the one
they ship. The only change is probably that one you pointed out (with
the larger bit size).
I also found the 7z folder and I *think* that it can be
substituted by lzma-dev.
The result builds and the testsuite passes.
Besides we need to split out unrar.


Scott K


Sebastian


That doesn't sound too bad.  I'll see if I can find some time to work on the
split, but probably not until Wednesday or Friday.


I did, eventually, look at this some.  This is both easier and harder is some
ways.

First, the CMake build system supports not building libclamavunrar, so we
don't need to monkey with the build system to get clamav built with it
removed.  I think split script is a do-over.  Only the most trivial parts of
it are still useful.

My suggested path forward is to manually create a DFSG tarball (and clean up
the win32 bits we don't need) by removing the relevant directories:

libclamunrar
win32

Then, at least in theory we can build a DFSG free package by passing
ENABLE_UNRAR_DEFAULT=OFF in the configure parameters.

I think we should focus on getting clamav up to 1.0.0 before the freeze and
deal with the unrar bits later (should be easy enough to get a freeze
exception for if we need it).

If you think tha'ts reasonable, I'll manually make the tarball and update git
(including the pristine-tar branch so we can work with the same tarball)?


How will that affect the non-free unrar package that Ubuntu ships ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk

Bug#1006179: [Pkg-clamav-devel] ClamAV 1.0.0 release candidate now available

[Scott Kitterman]

On December 22, 2022 11:54:53 PM UTC, Andrew C Aitchison 
 wrote:
>On Thu, 22 Dec 2022, Scott Kitterman wrote:
>:

>> I think we should focus on getting clamav up to 1.0.0 before the freeze and
>> deal with the unrar bits later (should be easy enough to get a freeze
>> exception for if we need it).
>> 
>> If you think tha'ts reasonable, I'll manually make the tarball and update git
>> (including the pristine-tar branch so we can work with the same tarball)?
>
>How will that affect the non-free unrar package that Ubuntu ships ?

If you mean the libclamavunrar package, then Ubuntu will want to be careful 
about syncing clamav 1.0.0 before we've updated libclamavunrar in Debian.  If 
you mean the separate unrar package, it won't affect it.

Scott K

Bug#1026664: misspell-fixer: FTBFS: grep: work/R.txt: Permission denied

[Lajos Veres]

Hi,

Thanks for checking this.
I suspect this report is the same as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026771

Could you please help me how I can test these issues in the
infrastructure?

Thank you.

Best regards,
Lajos

On Tue, 20 Dec 2022, Lucas Nussbaum wrote:

> Source: misspell-fixer
> Version: 0.4-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221220 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 '/<>'
> > /bin/bash -c 'source test/tests.sh'
> > Git is not available so we do not test .gitignore related functionality.
> > testWhitelist
> > misspell-fixer: -W Save found misspelled file entries into  
> > .misspell-fixer.ignore instead of fixing them.
> > misspell-fixer: Target directories: work
> > misspell-fixer: Iteration 0: prefiltering.
> > misspell-fixer: Saving found misspells into .misspell-fixer.ignore.
> > misspell-fixer: Iteration 0: done.
> > /<>
> > misspell-fixer: -r Enable real run. Overwrite original files!
> > misspell-fixer: -n Disable backups.
> > misspell-fixer: Target directories: work
> > misspell-fixer: Iteration 0: prefiltering.
> > misspell-fixer: Skipping whitelisted entries based on 
> > .misspell-fixer.ignore.
> > misspell-fixer: Iteration 0: processing.
> > misspell-fixer: Iteration 0: done.
> > misspell-fixer: Iteration 1: prefiltering.
> > misspell-fixer: Skipping whitelisted entries based on 
> > .misspell-fixer.ignore.
> > misspell-fixer: Iteration 1: nothing to replace.
> > misspell-fixer: Iteration 1: done.
> > /<>
> > /<>
> > testWhitelistWithFileNameOverride
> > misspell-fixer: -W Save found misspelled file entries into  
> > .misspell-fixer.ignore instead of fixing them.
> > misspell-fixer: -w Use .misspell-fixer.ignore.override as white list file 
> > instead of  .misspell-fixer.ignore.
> > misspell-fixer: Target directories: work
> > misspell-fixer: Iteration 0: prefiltering.
> > misspell-fixer: Saving found misspells into .misspell-fixer.ignore.override.
> > misspell-fixer: Iteration 0: done.
> > /<>
> > misspell-fixer: -r Enable real run. Overwrite original files!
> > misspell-fixer: -n Disable backups.
> > misspell-fixer: -w Use .misspell-fixer.ignore.override as white list file 
> > instead of  .misspell-fixer.ignore.
> > misspell-fixer: Target directories: work
> > misspell-fixer: Iteration 0: prefiltering.
> > misspell-fixer: Skipping whitelisted entries based on 
> > .misspell-fixer.ignore.override.
> > misspell-fixer: Iteration 0: nothing to replace.
> > misspell-fixer: Iteration 0: done.
> > ASSERT:
> > /<>
> > diff -ruwb /tmp/misspell-fixer-test/1434479/expected/1.txt 
> > /tmp/misspell-fixer-test/1434479/work/1.txt
> > --- /tmp/misspell-fixer-test/1434479/expected/1.txt 2022-12-20 
> > 09:55:05.905961848 +
> > +++ /tmp/misspell-fixer-test/1434479/work/1.txt 2022-12-20 
> > 09:55:05.901961812 +
> > @@ -1,3 +1,3 @@
> > -successful
> > -successfully
> > -lower than
> > \ No newline at end of file
> > +succesful
> > +succesfully
> > +lower then
> > \ No newline at end of file
> > ASSERT:Expected output differs.
> > /<>
> > testWhitelistConflictWithRealRun
> > /<>
> > diff -ruwb /tmp/misspell-fixer-test/1434479/expected/1.txt 
> > /tmp/misspell-fixer-test/1434479/work/1.txt
> > --- /tmp/misspell-fixer-test/1434479/expected/1.txt 2022-12-20 
> > 09:55:05.905961848 +
> > +++ /tmp/misspell-fixer-test/1434479/work/1.txt 2022-12-20 
> > 09:55:05.901961812 +
> > @@ -1,3 +1,3 @@
> > -successful
> > -successfully
> > -lower than
> > \ No newline at end of file
> > +succesful
> > +succesfully
> > +lower then
> > \ No newline at end of file
> > ASSERT:Expected output differs.
> > testWhitelistConflictWithDoubleWhitelist
> > /<>
> > diff -ruwb /tmp/misspell-fixer-test/1434479/expected/1.txt 
> > /tmp/misspell-fixer-test/1434479/work/1.txt
> > --- /tmp/misspell-fixer-test/1434479/expected/1.txt 2022-12-20 
> > 09:55:05.905961848 +
> > +++ /tmp/misspell-fixer-test/1434479/work/1.txt 2022-12-20 
> > 09:55:05.901961812 +
> > @@ -1,3 +1,3 @@
> > -successful
> > -successfully
> > -lower than
> > \ No newline at end of file
> > +succesful
> > +succesfully
> > +lower then
> > \ No newline at end of file
> > ASSERT:Expected output differs.
> > misspell-fixer: -r Enable real run. Overwrite original files!
> > misspell-fixer: Target directories: .
> > misspell-fixer: We found both .github/.misspell-fixer.ignore and 
> > .misspell-fixer.ignore.  We can handle only one at the moment.
> > /<>
> > testShowDiff
> > /<>
> > diff -ruwb /tmp/misspell-fixer-test/1434479/expected/1.txt 
> > /tmp/misspell-fixer-test/1434479/work/1.txt
> > --- /tmp/misspell-fixer-test/1434479/expected/1.txt 2022-12-20 
> > 09:55:05.905961848 +
> > +++ /tmp/misspell-fixer-test/1434479/work/1.txt 2022-12-20 
> > 

Bug#1026771: misspell-fixer: flaky autopkgtest

[Lajos Veres]

Hi Paul,

Thank you.
How can I test my changes on the below infrastructure?
Does https://mentors.debian.net/ run those tests?
Or is this something different?

Thank you.

Best regards,
Lajos

On Tue, 20 Dec 2022, Paul Gevers wrote:

> Source: misspell-fixer
> Version: 0.4-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: flaky
>
> Dear maintainer(s),
>
> I looked at the results of the autopkgtest of your package. I noticed that it
> regularly fails on nearly all architectures.
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
>
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.
>
> Paul
>
> https://ci.debian.net/data/autopkgtest/testing/i386/m/misspell-fixer/29450943/log.gz
>
> diff -ruwb /tmp/misspell-fixer-test/1187/expected/1.txt
> /tmp/misspell-fixer-test/1187/work/1.txt
> --- /tmp/misspell-fixer-test/1187/expected/1.txt  2022-12-16
> 17:16:38.379207670 +
> +++ /tmp/misspell-fixer-test/1187/work/1.txt  2022-12-16 17:16:38.379207670
> +
> @@ -1,3 +1,3 @@
> -successful
> -successfully
> -lower than
> \ No newline at end of file
> +succesful
> +succesfully
> +lower then
> \ No newline at end of file
> ASSERT:Expected output differs.
>
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/misspell-fixer/29495252/log.gz
>
> grep: .misspell-fixer.1192.prepared.grep.patterns: No such file or directory
> ASSERT:
> /tmp/autopkgtest-lxc.m76gii84/downtmp/build.pyf/src
> --- test/expecteds/0.txt  2021-01-13 19:01:21.0 +
> +++ /tmp/misspell-fixer-test/1192/work/0.txt  2022-12-20 09:41:00.880559995
> +
> @@ -1,3 +1,3 @@
> -successful
> -successfully
> -lower than
> \ No newline at end of file
> +succesful
> +succesfully
> +lower then
> \ No newline at end of file
> ASSERT:Gitignore respected.
>
>
> https://ci.debian.net/data/autopkgtest/testing/armhf/m/misspell-fixer/29128270/log.gz
>
> https://ci.debian.net/data/autopkgtest/testing/ppc64el/m/misspell-fixer/29329154/log.gz
>
> https://ci.debian.net/data/autopkgtest/testing/s390x/m/misspell-fixer/28654360/log.gz
>

-- 
Lajos Veres
vla...@gmail.com
07927 460 778

Bug#1006179: [Pkg-clamav-devel] Bug#1006179: Bug#1006179: Bug#1006179: Bug#1006179: ClamAV 1.0.0 release candidate now available

[Scott Kitterman]

On Monday, December 12, 2022 10:45:57 PM EST Scott Kitterman wrote:
> On Saturday, December 10, 2022 11:14:14 AM EST Sebastian Andrzej Siewior
> 
> wrote:
> > On 2022-12-07 12:51:30 [-0500], Scott Kitterman wrote:
> > > OK.  I'm back to having some time for Debian again, so let me know how I
> > > can help.
> > 
> > I pushed something to the experimental branch. It ain't much…
> > This updates the build dependencies and you still need download the
> > upstream .tar.gz yourself for 1.0.0. uscan is a bit of help. The split
> > script isn't working anymore.
> 
> Looks like it needs an some rewrite.  I guess we are in the land of CMake
> now as the configure.ac files it expects to find don't exist now.
> 
> > The llvm code is gone from the archive. This is the only good new. We
> > probably need to patch clamav to take the tfm library instead the one
> > they ship. The only change is probably that one you pointed out (with
> > the larger bit size).
> > I also found the 7z folder and I *think* that it can be
> > substituted by lzma-dev.
> > The result builds and the testsuite passes.
> > Besides we need to split out unrar.
> > 
> > > Scott K
> > 
> > Sebastian
> 
> That doesn't sound too bad.  I'll see if I can find some time to work on the
> split, but probably not until Wednesday or Friday.

I did, eventually, look at this some.  This is both easier and harder is some 
ways.

First, the CMake build system supports not building libclamavunrar, so we 
don't need to monkey with the build system to get clamav built with it 
removed.  I think split script is a do-over.  Only the most trivial parts of 
it are still useful.

My suggested path forward is to manually create a DFSG tarball (and clean up 
the win32 bits we don't need) by removing the relevant directories:

libclamunrar
win32

Then, at least in theory we can build a DFSG free package by passing 
ENABLE_UNRAR_DEFAULT=OFF in the configure parameters.

I think we should focus on getting clamav up to 1.0.0 before the freeze and 
deal with the unrar bits later (should be easy enough to get a freeze 
exception for if we need it).

If you think tha'ts reasonable, I'll manually make the tarball and update git 
(including the pristine-tar branch so we can work with the same tarball)?

Scott K

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

Bug#1024795: python-llvmlite

[M. Zhou]

Sure, I think we can ship a snapshot version as long as it works
fine with llvm-14. Could you please verify the snapshot hash
again?

https://github.com/numba/llvmlite/commit/c65b3e662b7b08920172b710419d7a06b660be59

The commit seems missing. If it was close to the master branch,
I can directly pull the master branch and upload the corresponding
snapshot.

On Wed, 2022-12-21 at 20:05 -0800, Diane Trout wrote:
> Hi,
> 
> I was trying to update numba, and need the updated version of llvmlite
> built against llvm-14
> 
> The version that's currently in unstable is still built against llvml-
> 11
> 
> https://packages.debian.org/sid/python3-llvmlite
> 
> I've checked out out the llvmlite repository and rebuilt it locally
> using commit c65b3e662b7b08920172b710419d7a06b660be59 against llvm-14
> 
> and llvmlite's test cases pass. (And most of numba's passed too. And I
> think the remaining test failures aren't related to llvmlite)
> 
> Is there a chance we could get an updated version released soon?
> 
> Thanks
> Diane Trout

Bug#1011863: guix: FTBFS in bullseye because of expired certificates used in tests

[Santiago Vila]

reopen 1011863
found 1011863 1.2.0-4
fixed 1011863 1.3.0-5
retitle 1011863 guix: FTBFS in bullseye because of expired certificates used in 
tests
tags 1011863 + patch
thanks

Hello.

Reopening because packages in bullseye must build in bullseye.

I attach an upload proposal for bullseye, it's just a backport for the fix in 
1.3.0-5,
but beware because it's untested.

The procedure for uploads to stable is explained here:

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

Thanks.diff -Nru guix-1.2.0/debian/changelog guix-1.2.0/debian/changelog
--- guix-1.2.0/debian/changelog 2021-03-28 04:18:29.0 +0200
+++ guix-1.2.0/debian/changelog 2022-12-22 23:14:00.0 +0100
@@ -1,3 +1,10 @@
+guix (1.2.0-4+deb11u1) bullseye; urgency=medium
+
+  * debian/patches: Remove expiration dates on openpgp keys used in test
+suite. (Closes: #1011863).
+
+ -- Vagrant Cascadian   Thu, 22 Dec 2022 23:14:00 +0100
+
 guix (1.2.0-4) unstable; urgency=medium
 
   * debian/patches: Fix privilege escalation issue in
diff -Nru guix-1.2.0/debian/patches/series guix-1.2.0/debian/patches/series
--- guix-1.2.0/debian/patches/series2021-03-18 23:14:54.0 +0100
+++ guix-1.2.0/debian/patches/series2022-12-22 23:14:00.0 +0100
@@ -38,3 +38,4 @@
 0028-tests-lint.scm-Disable-several-lint-tests-that-fail-.patch
 0029-tests-swh.scm-Disable-tests-the-fail-with-guile-2.2.patch
 security/daemon-Prevent-privilege-escalation-with-keep-failed.patch
+tests-Ensure-test-OpenPGP-keys-never-expire.patch
diff -Nru 
guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch 
guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch
--- guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch 
1970-01-01 01:00:00.0 +0100
+++ guix-1.2.0/debian/patches/tests-Ensure-test-OpenPGP-keys-never-expire.patch 
2022-12-22 23:14:00.0 +0100
@@ -0,0 +1,55 @@
+From 3ae7632ca0a1edca9d8c3c766efb0dcc8aa5da37 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
+Date: Wed, 18 May 2022 23:20:21 +0200
+Subject: [PATCH] tests: Ensure test OpenPGP keys never expire.
+
+All these keys had expiration dates.  'tests/keys/ed25519.pub' expired
+on 2022-04-24.
+
+Fixes .
+
+* tests/keys/ed25519.pub, tests/keys/ed25519-2.pub,
+tests/keys/ed25519-3.pub: Remove expiration date.
+---
+ tests/keys/ed25519-2.pub | 11 +--
+ tests/keys/ed25519-3.pub | 10 +-
+ tests/keys/ed25519.pub   | 10 +-
+ 3 files changed, 15 insertions(+), 16 deletions(-)
+
+Adjusted to apply to older locations present in 1.3.0.
+
+--- a/tests/ed25519bis.key
 b/tests/ed25519bis.key
+@@ -1,10 +1,9 @@
+ -BEGIN PGP PUBLIC KEY BLOCK-
+ 
+ mDMEXtVsNhYJKwYBBAHaRw8BAQdAnLsYdh3BpeK1xDguJE80XW2/MSmqeeP6pbQw
+-8jAw0OG0IkNoYXJsaWUgR3VpeCA8Y2hhcmxpZUBleGFtcGxlLm9yZz6IlgQTFggA
+-PhYhBKBDaY1jer75FlruS4IkDtyrgNqDBQJe1Ww2AhsDBQkDwmcABQsJCAcCBhUK
+-CQgLAgQWAgMBAh4BAheAAAoJEIIkDtyrgNqDM6cA/idDdoxo9SU+witdTXt24APH
+-yRzHbX9Iyh4dZNIek9JwAP9E0BwSvDHB4LY9z4RWf2hJp3dm/yZ/jEpK+w4BGN4J
+-Ag==
+-=JIU0
++8jAw0OG0IkNoYXJsaWUgR3VpeCA8Y2hhcmxpZUBleGFtcGxlLm9yZz6IkAQTFggA
++OAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBKBDaY1jer75FlruS4IkDtyr
++gNqDBQJihWJtAAoJEIIkDtyrgNqDbs0BAPOaGSYf3pX3DReEe1zbxxVQrolX9/AZ
++VP0AOt0TAgkzAP0Sr7G1NuCtjWWGK1WmlyTFPhOWLhNriKgZFkBZrGypAw==
++=pdTB
+ -END PGP PUBLIC KEY BLOCK-
+--- a/tests/ed25519.key
 b/tests/ed25519.key
+@@ -2,9 +2,9 @@
+ 
+ mDMEXqNaoBYJKwYBBAHaRw8BAQdArviKtelb4g0I3zx9xyDS40Oz8i1/LRXqppG6
+ b23Hdim0KEVkIFR3by1GaWZ0eSA8bHVkbyt0ZXN0LWVjY0BjaGJvdWliLm9yZz6I
+-lgQTFggAPhYhBETTHiGvcTj5tjIoCncfScv6rgctBQJeo1qgAhsDBQkDwmcABQsJ
+-CAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHcfScv6rgctq4MA/1R9G0roEwrHwmTd
+-DHxt211eLqupwXE0Z7xY2FH6DHk9AP4owEefBU7jQprSAzBS+c6gdS3SCCKKqAh6
+-ToZ4LmbKAw==
+-=FXMK
++kAQTFggAOAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBETTHiGvcTj5tjIo
++CncfScv6rgctBQJihWH6AAoJEHcfScv6rgctfPMBAPv+yPmEgM+J6D1nZjXsO4zW
+++4e3y2Ez+QxgI2tn8Z2xAQDBUWyyu0X+8dguGmVlsaiQdkazaUSpexvIhh9zONYw
++Bg==
++=s4Vp
+ -END PGP PUBLIC KEY BLOCK-

Bug#1026871: opendht 2.3.1-1.1 NMU patch

[Petter Reinholdtsen]

[Alexandre Viau]
> Hey,
>
> This is maintained under collab-maint,
>
> Please update the git repo too and feel free to just add yourself to
> uploaders instead of doing an NMU :)

Very glad to hear this.  I have been told by Amin Bandali he has been
trying to reach you for months, and he would like to be a co-maintainer
of opendht.  I'll help him going forward.

I'll skip the 7 day delayed upload and let the next upload be an non-NMU
upload from Amid.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1026870:

[Palaiologos]

> If you're indeed testing this inside VirtualBox, do look whether there's an 
> update for that (too).

I am testing on bare metal.

> I also noticed several ACPI errors. I don't know if that's on the host or also
inside VirtualBox, but it may be worth looking into that. And also
comparing that with the 'old' kernel which did perform 'properly'.

The old kernel also logs these messages.

As for the 6.1.y series kernel, the installation fails on my machine:

<<<
sudo apt install linux-image-amd64=6.1~rc8-1~exp1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  linux-image-6.1.0-0-amd64
Suggested packages:
  linux-doc-6.1 debian-kernel-handbook
The following NEW packages will be installed:
  linux-image-6.1.0-0-amd64
The following packages will be upgraded:
  linux-image-amd64
1 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 71.9 MB of archives.
After this operation, 481 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.debian.org/debian experimental/main amd64
linux-image-6.1.0-0-amd64 amd64 6.1~rc8-1~exp1 [71.9 MB]
Get:2 http://deb.debian.org/debian experimental/main amd64
linux-image-amd64 amd64 6.1~rc8-1~exp1 [1,484 B]
Fetched 71.9 MB in 5s (14.4 MB/s)
Reading changelogs... Done
Selecting previously unselected package linux-image-6.1.0-0-amd64.
(Reading database ... 250232 files and directories currently installed.)
Preparing to unpack .../linux-image-6.1.0-0-amd64_6.1~rc8-1~exp1_amd64.deb ...
Unpacking linux-image-6.1.0-0-amd64 (6.1~rc8-1~exp1) ...
Preparing to unpack .../linux-image-amd64_6.1~rc8-1~exp1_amd64.deb ...
Unpacking linux-image-amd64 (6.1~rc8-1~exp1) over (6.0.12-1) ...
Setting up linux-image-6.1.0-0-amd64 (6.1~rc8-1~exp1) ...
I: /vmlinuz.old is now a symlink to boot/vmlinuz-6.0.0-6-amd64
I: /initrd.img.old is now a symlink to boot/initrd.img-6.0.0-6-amd64
I: /vmlinuz is now a symlink to boot/vmlinuz-6.1.0-0-amd64
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-0-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-0-amd64:ACPI
disabled in this kernel, not building module.
ACPI disabled in this kernel, not building module.
Sign command: /lib/modules/6.1.0-0-amd64/build/scripts/sign-file
Binary /lib/modules/6.1.0-0-amd64/build/scripts/sign-file not found,
modules won't be signed
ACPI disabled in this kernel, not building module.
Error! The /var/lib/dkms/acpi-call/1.2.2/6.1.0-0-amd64/x86_64/dkms.conf
for module acpi-call includes a BUILD_EXCLUSIVE directive which does
not match this kernel/arch/config.
This indicates that it should not be built.
Sign command: /lib/modules/6.1.0-0-amd64/build/scripts/sign-file
Binary /lib/modules/6.1.0-0-amd64/build/scripts/sign-file not found,
modules won't be signed
Error! Your kernel headers for kernel 6.1.0-0-amd64 cannot be found at
/lib/modules/6.1.0-0-amd64/build or /lib/modules/6.1.0-0-amd64/source.
Please install the linux-headers-6.1.0-0-amd64 package or use the
--kernelsourcedir option to tell DKMS where it's located.
Sign command: /lib/modules/6.1.0-0-amd64/build/scripts/sign-file
Binary /lib/modules/6.1.0-0-amd64/build/scripts/sign-file not found,
modules won't be signed
Error! Your kernel headers for kernel 6.1.0-0-amd64 cannot be found at
/lib/modules/6.1.0-0-amd64/build or /lib/modules/6.1.0-0-amd64/source.
Please install the linux-headers-6.1.0-0-amd64 package or use the
--kernelsourcedir option to tell DKMS where it's located.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: error processing package linux-image-6.1.0-0-amd64 (--configure):
 installed linux-image-6.1.0-0-amd64 package post-installation script
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.1.0-0-amd64 (=
6.1~rc8-1~exp1); however:
  Package linux-image-6.1.0-0-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-0-amd64
 linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
>>>

After manually installing the headers package, the installation
succeeded. I booted into the new kernel and its performance matches
the old working kernel (6.0.8), meaning that the regression seems to
have been fixed.

Yours, Kamila Szewczyk

Bug#828683: mc: please make the build reproducible

[Vagrant Cascadian]

On 2022-10-06, Vagrant Cascadian wrote:
> The attached alternate implements this for mc by touching the potential
> files before running configure with a consistent timestamp.
>
> According to my local tests, applying this patch should make mc build
> reproducibly once it lands in testing/bookworm! There are outstanding
> build path issues tested in unstable and experimental.
...
> From 4e69587954d29ec6bfc7d85b4b618724b16b840e Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian 
> Date: Thu, 6 Oct 2022 19:25:11 +
> Subject: [PATCH 5/5] debian/rules: Ensure consistent timestamp on manpages.
>
> The upstream build system uses the file modification time of the .in
> file for the manpage to embed into the generatated manpage, but if
> debian/patches modify the .in files, the timestamp is updated,
> resulting in builds performed in different months or years embedding a
> different date.
> ---
>  debian/rules | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/debian/rules b/debian/rules
> index c633a73..bf8eb5e 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -25,6 +25,8 @@ override_dh_autoreconf:
>  # AWK="awk" is inheritance of 4.7.* series, see http://bugs.debian.org/499723
>  # might be still necessary for extfs scripts
>  override_dh_auto_configure:
> + # Ensure reproducible timestamp on manpages
> + touch -d@$(SOURCE_DATE_EPOCH) doc/man/*.1.in doc/man/*/*.1.in
>   dh_auto_configure -- AWK="awk" X11_WWW="x-www-browser" \
>   --libexecdir='/usr/lib' \
>   --with-x \
> -- 
> 2.37.2

I Intend to NMU with this patch on the 29th (with a 10-day delay) unless
I hear otherwise.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1026870: linux-image-6.0.0-6-amd64 - significant performance degradation

[Diederik de Haas]

On Thursday, 22 December 2022 22:20:44 CET Kamila Szewczyk wrote:
> [  297.413358] vboxdrv: loading out-of-tree module taints kernel.

If you're indeed testing this inside VirtualBox, do look whether there's an
update for that (too).

> [ 3025.190695] ACPI Error: No handler for Region [ECSI] (6dd86190)
> [EmbeddedControl] (20220331/evregion-130) [ 3025.190747] ACPI Error: Region
> EmbeddedControl (ID=3) has no handler (20220331/exfldio-261) [ 3025.190781]
> ACPI Error: Aborting method \_SB.UBTC.ECRD due to previous error
> (AE_NOT_EXIST) (20220331/psparse-529) [ 3025.190830] ACPI Error: Aborting
> method \_SB.UBTC.NTFY due to previous error (AE_NOT_EXIST)

I also noticed several ACPI errors. I don't know if that's on the host or also
inside VirtualBox, but it may be worth looking into that.
And also comparing that with the 'old' kernel which did perform 'properly'.

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

Bug#1026873: FTBFS: crystal: tests use network

[Andrey Feofilaktov]

Package: crystal
Version: 1.6.0+dfsg-2

Package fails to build in an isolated environment (
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/crystal.html
)

One of the tests (
https://salsa.debian.org/deiv/crystal/-/blob/master/spec/std/socket/tcp_server_spec.cr#L89)
tries to establish a connection to a non-existent server which works
differently in isolation and locally.

-- 
Regards,
Andrey

Bug#1026858: Dependency on debconf dropped prematurely

[Cyril Brulebois]

Hi Faidon,

and many thanks for the detailed analysis.

Faidon Liambotis  (2022-12-22):
> Going forward there are a few options:
>   * Revert the change and depend on debconf again. This is the safest
> option, as this has been the status quo since 2007.

That would look good to me.

I'll admit outright that I didn't try and figure out the whole cdebconf
vs. debconf situation, what we would be trying to fix, and what the
benefits would be. But at least [1] reinforced my “should we be touching
that? right now??” gut feeling.

 1. https://lists.debian.org/debian-boot/2022/11/msg00044.html


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1026872: menu: READMEs mention /usr/share/menu/default, which doesn't exist, as documentation

[Bill Allombert]

On Thu, Dec 22, 2022 at 10:41:00PM +0100, наб wrote:
> Package: menu
> Version: 2.1.49
> Severity: normal
> 
> Dear Maintainer,
> 
> -- >8 --
> $ cat usr/share/menu/README
> ...
> The files should have the name of the package that's installing it,
> and may contain as many lines (menu entries) as is necessary.
> 
> For examples, please look in /usr/share/menu/default
> ...
> -- >8 --
> but
> -- >8 --
> $ find -name default
> -- >8 --
> so?
> 
> For reference, other documentation seems to indicate that /u/s/m/d

Dear нaб

/u/s/m/d was declared obsolete in 2.1.38, but due to recent developments,
I think I will need to revive it.

Thanks for using Debian menu,
Bill.

Bug#1026870: linux-image-6.0.0-6-amd64 - significant performance degradation

[Salvatore Bonaccorso]

Hi,

On Thu, Dec 22, 2022 at 10:20:44PM +0100, Kamila Szewczyk wrote:
> Package: src:linux
> Version: 6.0.12-1
> Severity: important
> X-Debbugs-Cc: kspalaiolo...@gmail.com
> 
> Dear Maintainer,
> 
> I have recently upgraded my Linux kernel to package version 6.0.12-1
> (6.0.0-6) from version 6.0.8 (6.0.0-4). Since then I am experiencing
> significant performance degradation. I have tried to observe the
> cause of it using the `perf' tool, however, I haven't had any luck
> with this so far, and the kernel has been logging the following
> messages throughout the procedure:
> 
> >>>
> Message from syslogd@laplace at Dec 22 21:51:20 ...
>  kernel:[ 5212.738589] Uhhuh. NMI received for unknown reason 2d on CPU 9.
> 
> Message from syslogd@laplace at Dec 22 21:51:20 ...
>  kernel:[ 5212.738607] Dazed and confused, but trying to continue
> 
> Message from syslogd@laplace at Dec 22 21:51:21 ...
>  kernel:[ 5214.422563] Uhhuh. NMI received for unknown reason 2d on CPU 7.
> 
> Message from syslogd@laplace at Dec 22 21:51:21 ...
>  kernel:[ 5214.422582] Dazed and confused, but trying to continue
> <<<
> 
> So far I have observed that returning to the previously installed
> kernel version solves most of my problems. I have also compared the
> execution times using `perf' on both of the kernels.
> 
> New kernel:
> <<<
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package asdfghjkl
> 
>  Performance counter stats for 'apt install asdfghjkl':
> 
>   2,409.28 msec task-clock   #0.999 CPUs 
> utilized
> 11  context-switches #4.566 /sec
>  4  cpu-migrations   #1.660 /sec
>  2,526  page-faults  #1.048 K/sec
>961,017,382  cycles   #0.399 GHz   
>(83.39%)
> 15,353,337  stalled-cycles-frontend  #1.60% frontend 
> cycles idle (83.40%)
>226,730,321  stalled-cycles-backend   #   23.59% backend 
> cycles idle  (83.40%)
>  2,018,766,682  instructions #2.10  insn per 
> cycle
>   #0.11  stalled cycles 
> per insn  (83.39%)
>383,290,701  branches #  159.089 M/sec 
>(83.35%)
>  1,819,464  branch-misses#0.47% of all 
> branches  (83.24%)
> 
>2.411797623 seconds time elapsed
> 
>2.349918000 seconds user
>0.062534000 seconds sys
> >>>
> 
> Old kernel:
> <<<
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package asdfghjkl
> 
>  Performance counter stats for 'apt install asdfghjkl':
> 
> 852.22 msec task-clock   #0.940 CPUs 
> utilized
>392  context-switches #  459.975 /sec
>  3  cpu-migrations   #3.520 /sec
>  2,548  page-faults  #2.990 K/sec
>  1,172,831,665  cycles   #1.376 GHz   
>(83.08%)
> 43,524,987  stalled-cycles-frontend  #3.71% frontend 
> cycles idle (83.76%)
>412,509,320  stalled-cycles-backend   #   35.17% backend 
> cycles idle  (82.83%)
>  2,060,235,707  instructions #1.76  insn per 
> cycle
>   #0.20  stalled cycles 
> per insn  (83.60%)
>396,100,764  branches #  464.786 M/sec 
>(83.18%)
>  1,892,879  branch-misses#0.48% of all 
> branches  (83.77%)
> 
>0.906939283 seconds time elapsed
> 
>0.795226000 seconds user
>0.059521000 seconds sys
> >>>
> 
> If there is any troubleshooting or important information
> I could provide, please let me know.
> 
> I have noticed that the clock speeds tend to be much lower
> on the new Linux kernel, however, I don't know the cause of it.
> All the system data (including e.g. CPU governor configuration)
> stays the same.

As we will soonish move to the 6.1.y series (which as LTS kernel
upstream is aimed to be the one we will use for bookworm), do you
observe the same regression when moving to the kernel available in
experimental? (Ideally test the just uploaded 6.1.1-1~exp1 once it is
built).

If it is still reproducible with latest kernel, would you be able to
bisect the changes between 6.0.8 and 6.0.12 to isolate the change
introducing the regression for you?

The following resource might be helpful for the later case:
https://wiki.debian.org/DebianKernel/GitBisect

Regards,
Salvatore

Bug#1026871: opendht 2.3.1-1.1 NMU patch

[Alexandre Viau]

Hey,

This is maintained under collab-maint,

Please update the git repo too and feel free to just add yourself to
uploaders instead of doing an NMU :)

Cheers,

--
Alexandre Viau
alexan...@alexandreviau.net

On Thu, 22 Dec 2022 at 16:39, Petter Reinholdtsen  wrote:
>
>
> Package: opendht
> Version: 2.3.1-1.1
> Severity: wishlist
>
> I have just uploaded a NMU for opendht to the 7 day delayed queue fixing
> a few long pending fixes sent to the salsa project.  This upload is part
> of an effort coordinated on #debian-voip to improve the jami package in
> Debian.
>
> This is the patch used.  It is also commited to the salsa project, which
> is under of the Debian team umbrella.
>
> diff --git a/debian/changelog b/debian/changelog
> index e8d06fe..4333e4b 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,23 @@
> +opendht (2.3.1-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload using salsa Debian team git repo.
> +
> +  [ Amin Bandali ]
> +  * d/watch: Tweak opts to use newly-suggested format in the current
> +uscan(1) manual for GitHub repositories, helping correctly detect
> +new releases again (partly fixes #1016489).
> +
> +  [ Federico Ceratto ]
> +  * Configure service sandbox (Closes: #1007163).
> +  * Bump up Standards-Version from 4.0.0 to 4.5.0.
> +  * Switch to debhelper-compat 12.
> +
> +  [ Petter Reinholdtsen ]
> +  * Switched build and binary dependency for libargon2-0-dev to libargon2-dev
> +(Closes: #1005699).
> +
> + -- Petter Reinholdtsen   Thu, 22 Dec 2022 22:33:19 +0100
> +
>  opendht (2.3.1-1) unstable; urgency=medium
>
>[ Amin Bandali ]
> diff --git a/debian/compat b/debian/compat
> deleted file mode 100644
> index f599e28..000
> --- a/debian/compat
> +++ /dev/null
> @@ -1 +0,0 @@
> -10
> diff --git a/debian/control b/debian/control
> index b9b532a..b511cb4 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -2,7 +2,7 @@ Source: opendht
>  Section: libs
>  Priority: optional
>  Maintainer: Alexandre Viau 
> -Build-Depends: debhelper (>= 9.20160709),
> +Build-Depends: debhelper-compat (= 12),
> cmake,
> dh-exec,
> pkg-config,
> @@ -10,7 +10,7 @@ Build-Depends: debhelper (>= 9.20160709),
> libmsgpack-dev (>= 1.2),
> libreadline6-dev,
> libncurses5-dev,
> -   libargon2-0-dev,
> +   libargon2-dev,
> librestinio-dev,
> libasio-dev,
> libjsoncpp-dev,
> @@ -18,7 +18,7 @@ Build-Depends: debhelper (>= 9.20160709),
> libssl-dev,
> libfmt-dev,
> nettle-dev
> -Standards-Version: 4.0.0
> +Standards-Version: 4.5.0
>  Homepage: https://github.com/savoirfairelinux/opendht
>  Vcs-Git: https://salsa.debian.org/debian/opendht.git
>  Vcs-Browser: https://salsa.debian.org/debian/opendht
> @@ -32,7 +32,7 @@ Depends: ${misc:Depends},
>   libmsgpack-dev (>= 1.2),
>   libreadline6-dev,
>   libncurses5-dev,
> - libargon2-0-dev,
> + libargon2-dev,
>   librestinio-dev,
>   libasio-dev,
>   libjsoncpp-dev,
> diff --git a/debian/dhtnode.service b/debian/dhtnode.service
> index a8e7644..90198f3 100644
> --- a/debian/dhtnode.service
> +++ b/debian/dhtnode.service
> @@ -1,14 +1,43 @@
>  [Unit]
>  Description=OpenDHT standalone node
> -After=network.target
>  Documentation=man:dhtnode(1)
> +After=network.target
> +ConditionPathExists=/etc/default/dhtnode
>
>  [Service]
> +Type=simple
>  User=opendht
>  Group=opendht
>  EnvironmentFile=/etc/default/dhtnode
>  ExecStart=/usr/bin/dhtnode -s $DHT_ARGS
>  Restart=on-failure
> +RestartSec=2s
> +LimitNOFILE=65536
> +WorkingDirectory=/tmp
> +
> +# Hardening
> +CapabilityBoundingSet=CAP_NET_BIND_SERVICE
> +LockPersonality=yes
> +NoNewPrivileges=yes
> +PrivateDevices=yes
> +PrivateTmp=yes
> +PrivateUsers=yes
> +ProtectClock=yes
> +ProtectControlGroups=yes
> +ProtectHome=yes
> +ProtectHostname=yes
> +ProtectKernelLogs=yes
> +ProtectKernelModules=yes
> +ProtectKernelTunables=yes
> +ProtectSystem=strict
> +ReadOnlyDirectories=/
> +ReadWriteDirectories=-/proc/self
> +ReadWriteDirectories=-/var/run
> +RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
> +RestrictNamespaces=yes
> +RestrictRealtime=yes
> +SystemCallArchitectures=native
> +SystemCallFilter=@system-service
>
>  [Install]
>  WantedBy=multi-user.target
> diff --git a/debian/watch b/debian/watch
> index b42aa67..31ca925 100644
> --- a/debian/watch
> +++ b/debian/watch
> @@ -1,4 +1,4 @@
>  version=4
> -opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
> +opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*@ARCHIVE_EXT@)%@PACKAGE@-$1%" \
>https://github.com/savoirfairelinux/opendht/tags \
> -  (?:.*?/)?@ANY_VERSION@@ARCHIVE_EXT@
> +  (?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@
>
> --
> Happy hacking
> Petter Reinholdtsen

Bug#1017039: more infos

[Thomas Lange]

I did some more tests.

modules.d/90overlayfs installs the script that mounts the overlay
using this line:

inst_hook mount 01 "$moddir/mount-overlayfs.sh"

But the mount hooks of dracut are not executed at all.
Here's the part of init.log:


/init@229(): getarg rd.break=mount -d rdbreak=mount
/lib/dracut-lib.sh@153(getarg): debug_off
/lib/dracut-lib.sh@23(debug_off): set +x
/lib/dracut-lib.sh@216(getarg): return 1
/init@232(): _i_mount=0
/init@233(): :
/init@234(): ismounted /sysroot
/lib/dracut-lib.sh@525(ismounted): findmnt /sysroot
/init@235(): usable_root /sysroot
/lib/dracut-lib.sh@736(usable_root): local _i
/lib/dracut-lib.sh@738(usable_root): '[' -d /sysroot ']'
/lib/dracut-lib.sh@740(usable_root): for _i in "$1"/usr/lib*/ld-*.so 
"$1"/lib*/ld-*.so
/lib/dracut-lib.sh@741(usable_root): '[' -e '/sysroot/usr/lib*/ld-*.so' ']'
/lib/dracut-lib.sh@740(usable_root): for _i in "$1"/usr/lib*/ld-*.so 
"$1"/lib*/ld-*.so
/lib/dracut-lib.sh@741(usable_root): '[' -e '/sysroot/lib*/ld-*.so' ']'
/lib/dracut-lib.sh@744(usable_root): for _i in proc sys dev
/lib/dracut-lib.sh@745(usable_root): '[' -e /sysroot/proc ']'
/lib/dracut-lib.sh@744(usable_root): for _i in proc sys dev
/lib/dracut-lib.sh@745(usable_root): '[' -e /sysroot/sys ']'
/lib/dracut-lib.sh@744(usable_root): for _i in proc sys dev
/lib/dracut-lib.sh@745(usable_root): '[' -e /sysroot/dev ']'
/lib/dracut-lib.sh@748(usable_root): return 0
/init@235(): break


Because of the break this line is not executed in init.sh and the
overlay mount script is not executed.

line 238 for f in "$hookdir"/mount/*.sh; do

-- 
regards Thomas

Bug#1026872: menu: READMEs mention /usr/share/menu/default, which doesn't exist, as documentation

[наб]

Package: menu
Version: 2.1.49
Severity: normal

Dear Maintainer,

-- >8 --
$ cat usr/share/menu/README
...
The files should have the name of the package that's installing it,
and may contain as many lines (menu entries) as is necessary.

For examples, please look in /usr/share/menu/default
...
-- >8 --
but
-- >8 --
$ find -name default
-- >8 --
so?

For reference, other documentation seems to indicate that /u/s/m/d
is where menu files go:
-- >8 --
$ find -type f -exec zgrep /usr/share/menu/default {} +
./usr/share/menu/README:For examples, please look in /usr/share/menu/default
./usr/share/man/man5/menufile.5.gz:.B /usr/share/menu/default/*
./usr/share/man/man5/menufile.5.gz:.I /usr/share/menu/default/*
./usr/share/man/man1/update-menus.1.gz:.I /usr/share/menu/default/*
./usr/share/man/fr/man5/menufile.5.gz:.B /usr/share/menu/default/*
./usr/share/man/fr/man5/menufile.5.gz:.I /usr/share/menu/default/*
./usr/share/man/fr/man1/update-menus.1.gz:.I /usr/share/menu/default/*
./usr/share/info/menu.info.gz:'/usr/lib/menu', '/usr/share/menu' and 
'/usr/share/menu/default', and
./usr/share/info/menu.info.gz:'/usr/lib/menu', '/usr/share/menu', 
'/usr/share/menu/default'.  (if a
./usr/share/doc/menu/menu.txt.gz: `/usr/lib/menu', `/usr/share/menu' and 
`/usr/share/menu/default', and
./usr/share/doc/menu/menu.txt.gz: `/usr/share/menu/default'.  (if a user 
runs `update-menus', it will
./usr/share/doc/menu/menu.sgml.gz:/usr/share/menu/default, and 
stores the menu entries of all
./usr/share/doc/menu/menu.sgml.gz:/usr/share/menu, 
/usr/share/menu/default.
./usr/share/doc/menu/html/ch7.html:/usr/share/menu, 
/usr/share/menu/default.  (if a user
./usr/share/doc/menu/html/ch2.html:/usr/share/menu/default, and 
stores the menu entries of all
./usr/share/doc/menu/changelog.gz:  * Move default entries to 
/usr/share/menu/default.
./usr/share/doc/menu/changelog.gz:  * Update documentation to reflect 
/usr/share/menu/default changes.
grep: ./usr/bin/update-menus: binary file matches
./etc/menu/README:and /usr/share/menu/default.
-- >8 --

However:
-- >8 --
$ zgrep usr/share/menu/default Contents-all.gz Contents-amd64.gz
-- >8 --
so?

idk

Best,
наб


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 menu depends on:
ii  libc6   2.36-6
ii  libgcc-s1   12.2.0-10
ii  libstdc++6  12.2.0-10

menu recommends no packages.

Versions of packages menu suggests:
pn  gksu | kde-cli-tools | ktsuss  
pn  menu-l10n  


signature.asc
Description: PGP signature

Bug#794398: clhep: please make the build reproducible

[Vagrant Cascadian]

Control: tags 794398 pending

On 2015-08-02, Reiner Herrmann wrote:
> While working on the "reproducible builds" effort [1], we have noticed
> that clhep could not be built reproducibly.
> A file list is sorted differently depending on the locale.
>
> The attached patch fixes this by sorting with LC_ALL set to C.

I have uploaded an NMU to DELAYED/10 fixing this sorting issue and
another reproducible builds issue with embedded build paths:

diff -Nru clhep-2.1.4.1+dfsg/debian/changelog 
clhep-2.1.4.1+dfsg/debian/changelog
--- clhep-2.1.4.1+dfsg/debian/changelog 2017-02-07 03:01:31.0 -0800
+++ clhep-2.1.4.1+dfsg/debian/changelog 2022-12-22 13:06:15.0 -0800
@@ -1,3 +1,16 @@
+clhep (2.1.4.1+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Reiner Herrmann ]
+  * getObjectList.in: Sort file list to get reproducible results
+(Closes: #794398)
+
+  [ Vagrant Cascadian ]
+  * debian/rules: Avoid embedding the build path in clhep-config.
+
+ -- Vagrant Cascadian   Thu, 22 Dec 2022 
13:06:15 -0800
+
 clhep (2.1.4.1+dfsg-1) unstable; urgency=medium
 
   [ Andreas Tille ]
diff -Nru 
clhep-2.1.4.1+dfsg/debian/patches/getobjectlist.in-sort-file-list-to-get-r.patch
 
clhep-2.1.4.1+dfsg/debian/patches/getobjectlist.in-sort-file-list-to-get-r.patch
--- 
clhep-2.1.4.1+dfsg/debian/patches/getobjectlist.in-sort-file-list-to-get-r.patch
1969-12-31 16:00:00.0 -0800
+++ 
clhep-2.1.4.1+dfsg/debian/patches/getobjectlist.in-sort-file-list-to-get-r.patch
2022-12-22 13:06:15.0 -0800
@@ -0,0 +1,19 @@
+From: Reiner Herrmann 
+Date: Sun, 2 Aug 2015 18:03:58 +0200
+X-Dgit-Generated: 2.1.4.1+dfsg-1.1 dacaf952527807a2f82c0884afa3fa3f10696298
+Subject: getObjectList.in: Sort file list to get reproducible results
+
+(Closes: #794398)
+
+---
+
+diff --git a/getObjectList.in b/getObjectList.in
+index 3f55df2..9ff040b 100755
+--- a/getObjectList.in
 b/getObjectList.in
+@@ -22,4 +22,4 @@ do
+fi
+ done
+ 
+-echo $filelist
++echo $filelist | tr ' ' '\n' | LC_ALL=C sort | tr '\n' ' '
diff -Nru clhep-2.1.4.1+dfsg/debian/patches/series 
clhep-2.1.4.1+dfsg/debian/patches/series
--- clhep-2.1.4.1+dfsg/debian/patches/series2017-02-07 02:54:11.0 
-0800
+++ clhep-2.1.4.1+dfsg/debian/patches/series2022-12-22 13:06:15.0 
-0800
@@ -4,3 +4,4 @@
 tests.patch
 fix-double-comparision-in-testBug58950.patch
 replace_psfig_by_graphicx.patch
+getobjectlist.in-sort-file-list-to-get-r.patch
diff -Nru clhep-2.1.4.1+dfsg/debian/rules clhep-2.1.4.1+dfsg/debian/rules
--- clhep-2.1.4.1+dfsg/debian/rules 2017-02-07 02:48:35.0 -0800
+++ clhep-2.1.4.1+dfsg/debian/rules 2022-12-22 13:06:15.0 -0800
@@ -34,5 +34,10 @@
dh_auto_build
doxygen doxygen.conf
 
+override_dh_install:
+   # Avoid embedding build path for reproducible builds
+   sed -i -e "s,$(CURDIR),BUILDDIR,g" debian/tmp/usr/bin/clhep-config
+   dh_install
+
 %:
dh $@ --with autoreconf $(dhopt)


signature.asc
Description: PGP signature

Bug#1026871: opendht 2.3.1-1.1 NMU patch

[Petter Reinholdtsen]

Package: opendht
Version: 2.3.1-1.1
Severity: wishlist

I have just uploaded a NMU for opendht to the 7 day delayed queue fixing
a few long pending fixes sent to the salsa project.  This upload is part
of an effort coordinated on #debian-voip to improve the jami package in
Debian.

This is the patch used.  It is also commited to the salsa project, which
is under of the Debian team umbrella.

diff --git a/debian/changelog b/debian/changelog
index e8d06fe..4333e4b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+opendht (2.3.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload using salsa Debian team git repo.
+
+  [ Amin Bandali ]
+  * d/watch: Tweak opts to use newly-suggested format in the current
+uscan(1) manual for GitHub repositories, helping correctly detect
+new releases again (partly fixes #1016489).
+
+  [ Federico Ceratto ]
+  * Configure service sandbox (Closes: #1007163).
+  * Bump up Standards-Version from 4.0.0 to 4.5.0.
+  * Switch to debhelper-compat 12.
+
+  [ Petter Reinholdtsen ]
+  * Switched build and binary dependency for libargon2-0-dev to libargon2-dev
+(Closes: #1005699).
+
+ -- Petter Reinholdtsen   Thu, 22 Dec 2022 22:33:19 +0100
+
 opendht (2.3.1-1) unstable; urgency=medium
 
   [ Amin Bandali ]
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index f599e28..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-10
diff --git a/debian/control b/debian/control
index b9b532a..b511cb4 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: opendht
 Section: libs
 Priority: optional
 Maintainer: Alexandre Viau 
-Build-Depends: debhelper (>= 9.20160709),
+Build-Depends: debhelper-compat (= 12),
cmake,
dh-exec,
pkg-config,
@@ -10,7 +10,7 @@ Build-Depends: debhelper (>= 9.20160709),
libmsgpack-dev (>= 1.2),
libreadline6-dev,
libncurses5-dev,
-   libargon2-0-dev,
+   libargon2-dev,
librestinio-dev,
libasio-dev,
libjsoncpp-dev,
@@ -18,7 +18,7 @@ Build-Depends: debhelper (>= 9.20160709),
libssl-dev,
libfmt-dev,
nettle-dev
-Standards-Version: 4.0.0
+Standards-Version: 4.5.0
 Homepage: https://github.com/savoirfairelinux/opendht
 Vcs-Git: https://salsa.debian.org/debian/opendht.git
 Vcs-Browser: https://salsa.debian.org/debian/opendht
@@ -32,7 +32,7 @@ Depends: ${misc:Depends},
  libmsgpack-dev (>= 1.2),
  libreadline6-dev,
  libncurses5-dev,
- libargon2-0-dev,
+ libargon2-dev,
  librestinio-dev,
  libasio-dev,
  libjsoncpp-dev,
diff --git a/debian/dhtnode.service b/debian/dhtnode.service
index a8e7644..90198f3 100644
--- a/debian/dhtnode.service
+++ b/debian/dhtnode.service
@@ -1,14 +1,43 @@
 [Unit]
 Description=OpenDHT standalone node
-After=network.target
 Documentation=man:dhtnode(1)
+After=network.target
+ConditionPathExists=/etc/default/dhtnode
 
 [Service]
+Type=simple
 User=opendht
 Group=opendht
 EnvironmentFile=/etc/default/dhtnode
 ExecStart=/usr/bin/dhtnode -s $DHT_ARGS
 Restart=on-failure
+RestartSec=2s
+LimitNOFILE=65536
+WorkingDirectory=/tmp
+
+# Hardening
+CapabilityBoundingSet=CAP_NET_BIND_SERVICE
+LockPersonality=yes
+NoNewPrivileges=yes
+PrivateDevices=yes
+PrivateTmp=yes
+PrivateUsers=yes
+ProtectClock=yes
+ProtectControlGroups=yes
+ProtectHome=yes
+ProtectHostname=yes
+ProtectKernelLogs=yes
+ProtectKernelModules=yes
+ProtectKernelTunables=yes
+ProtectSystem=strict
+ReadOnlyDirectories=/
+ReadWriteDirectories=-/proc/self
+ReadWriteDirectories=-/var/run
+RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
+RestrictNamespaces=yes
+RestrictRealtime=yes
+SystemCallArchitectures=native
+SystemCallFilter=@system-service
 
 [Install]
 WantedBy=multi-user.target
diff --git a/debian/watch b/debian/watch
index b42aa67..31ca925 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
 version=4
-opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%@PACKAGE@-$1.tar.gz%" \
+opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*@ARCHIVE_EXT@)%@PACKAGE@-$1%" \
   https://github.com/savoirfairelinux/opendht/tags \
-  (?:.*?/)?@ANY_VERSION@@ARCHIVE_EXT@
+  (?:.*?/)?v?@ANY_VERSION@@ARCHIVE_EXT@

-- 
Happy hacking
Petter Reinholdtsen

Bug#1026870: linux-image-6.0.0-6-amd64 - significant performance degradation

[Kamila Szewczyk]

Package: src:linux
Version: 6.0.12-1
Severity: important
X-Debbugs-Cc: kspalaiolo...@gmail.com

Dear Maintainer,

I have recently upgraded my Linux kernel to package version 6.0.12-1
(6.0.0-6) from version 6.0.8 (6.0.0-4). Since then I am experiencing
significant performance degradation. I have tried to observe the
cause of it using the `perf' tool, however, I haven't had any luck
with this so far, and the kernel has been logging the following
messages throughout the procedure:

>>>
Message from syslogd@laplace at Dec 22 21:51:20 ...
 kernel:[ 5212.738589] Uhhuh. NMI received for unknown reason 2d on CPU 9.

Message from syslogd@laplace at Dec 22 21:51:20 ...
 kernel:[ 5212.738607] Dazed and confused, but trying to continue

Message from syslogd@laplace at Dec 22 21:51:21 ...
 kernel:[ 5214.422563] Uhhuh. NMI received for unknown reason 2d on CPU 7.

Message from syslogd@laplace at Dec 22 21:51:21 ...
 kernel:[ 5214.422582] Dazed and confused, but trying to continue
<<<

So far I have observed that returning to the previously installed
kernel version solves most of my problems. I have also compared the
execution times using `perf' on both of the kernels.

New kernel:
<<<
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package asdfghjkl

 Performance counter stats for 'apt install asdfghjkl':

  2,409.28 msec task-clock   #0.999 CPUs 
utilized
11  context-switches #4.566 /sec
 4  cpu-migrations   #1.660 /sec
 2,526  page-faults  #1.048 K/sec
   961,017,382  cycles   #0.399 GHz 
 (83.39%)
15,353,337  stalled-cycles-frontend  #1.60% frontend 
cycles idle (83.40%)
   226,730,321  stalled-cycles-backend   #   23.59% backend 
cycles idle  (83.40%)
 2,018,766,682  instructions #2.10  insn per 
cycle
  #0.11  stalled cycles per 
insn  (83.39%)
   383,290,701  branches #  159.089 M/sec   
 (83.35%)
 1,819,464  branch-misses#0.47% of all 
branches  (83.24%)

   2.411797623 seconds time elapsed

   2.349918000 seconds user
   0.062534000 seconds sys
>>>

Old kernel:
<<<
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package asdfghjkl

 Performance counter stats for 'apt install asdfghjkl':

852.22 msec task-clock   #0.940 CPUs 
utilized
   392  context-switches #  459.975 /sec
 3  cpu-migrations   #3.520 /sec
 2,548  page-faults  #2.990 K/sec
 1,172,831,665  cycles   #1.376 GHz 
 (83.08%)
43,524,987  stalled-cycles-frontend  #3.71% frontend 
cycles idle (83.76%)
   412,509,320  stalled-cycles-backend   #   35.17% backend 
cycles idle  (82.83%)
 2,060,235,707  instructions #1.76  insn per 
cycle
  #0.20  stalled cycles per 
insn  (83.60%)
   396,100,764  branches #  464.786 M/sec   
 (83.18%)
 1,892,879  branch-misses#0.48% of all 
branches  (83.77%)

   0.906939283 seconds time elapsed

   0.795226000 seconds user
   0.059521000 seconds sys
>>>

If there is any troubleshooting or important information
I could provide, please let me know.

I have noticed that the clock speeds tend to be much lower
on the new Linux kernel, however, I don't know the cause of it.
All the system data (including e.g. CPU governor configuration)
stays the same.

Yours, Kamila Szewczyk.

-- Package-specific info:
** Version:
Linux version 6.0.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9.1) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP 
PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09)

** Command line:
BOOT_IMAGE=/vmlinuz-6.0.0-6-amd64 root=/dev/mapper/laplace--vg-root ro quiet

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[  290.013257] snd_hda_intel :04:00.1: Handle vga_switcheroo audio client
[  290.013307] snd_hda_intel :04:00.6: enabling device ( -> 0002)
[  290.047532] snd_hda_intel :04:00.1: bound :04:00.0 (ops 
amdgpu_dm_audio_component_bind_ops [amdgpu])
[  290.065328] input: HD-Audio Generic HDMI/DP,pcm=3 as 
/devices/pci:00/:00:08.1/:04:00.1/sound/card0/input12
[  290.065411] input: HD-Audio 

Bug#1026735: clusterssh: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255

[tony mancill]

Hi Gregor,

On Tue, Dec 20, 2022 at 07:31:55PM +0100, gregor herrmann wrote:
> Control: tag -1 + confirmed upstream
> 
> On Tue, 20 Dec 2022 18:28:10 +0100, Lucas Nussbaum wrote:
> 
> > Source: clusterssh
> > Version: 4.16-3
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20221220 ftbfs-bookworm
> 
> > > #   Failed test 'returned ok'
> > > #   at t/15config.t line 546.
> > > #  got: 'die'
> > > # expected: 'return'
> > > 
> > > #   Failed test 'Expecting no STDERR'
> > > #   at t/15config.t line 550.
> > > #  got: ''
> > > # expected: 'Unable to write default $HOME/.clusterssh/config: Is a 
> > > directory
> > > # 
> > > # '
> > > # Looks like you failed 2 tests of 155.
> > > t/15config.t .. 
> 
> > > # check failure to write default config is caught
> > > not ok 147 - returned ok
> > > ok 148 - An object of class 'App::ClusterSSH::Config' isa 
> > > 'App::ClusterSSH::Config'
> > > ok 149 - An object of class 'App::ClusterSSH::Config' isa 
> > > 'App::ClusterSSH::Config'
> > > ok 150 - Expecting no STDOUT
> > > not ok 151 - Expecting no STDERR
> 
> > > Test Summary Report
> > > ---
> 
> > > t/15config.t(Wstat: 512 (exited 2) Tests: 155 Failed: 2)
> > >   Failed tests:  147, 151
> > >   Non-zero exit status: 2
> 
> This reminds me of #1025722 in duck and is probably also caused by
> this change in perl:
> 
> perl (5.36.0-5) unstable; urgency=medium
> 
>   * Backported upstream changes:
> + only clear the stream error state in readline() for glob()
>   (Closes: #1016369)
> 
> The problem seems to be in lines 384 ff in write_user_config_file()
> in lib/App/ClusterSSH/Config.pm:
> 
>341  sub write_user_config_file {
> 
>384  # Debian #673507 - migrate clusters prior to writing 
> ~/.clusterssh/config
>385  # in order to update the extra_cluster_file property
>386  if (%old_clusters) {
>387  if ( open( my $fh, ">", "$ENV{HOME}/.clusterssh/clusters" ) ) 
> {
>388  print $fh '# '
>389  . $self->loc('Tag definitions moved from old .csshrc 
> file'),
>390  $/;
>391  foreach ( sort( keys(%old_clusters) ) ) {
>392  print $fh $_, ' ', join( ' ', $old_clusters{$_} ), $/;
>393  }
>394  close($fh);
>395  }
>396  else {
>397  croak(
>398  App::ClusterSSH::Exception::Config->throw(
>399  error => $self->loc(
>400  'Unable to write [_1]: [_2]' . $/,
>401  '$HOME/.clusterssh/clusters',
>402  $!
>403  ),
>404  ),
>405  );
>406  }
>407  }
> 
> 
> As #673507 is from 2012, I guess this code (and the tests) can be
> removed?

I think reference to #673507 is merely for context and that the behavior
implemented (with respect to the configuration file location and logic)
is the desired behavior.

Thank you for the pointer to the bug in duck [1].  I'll work on a patch.

Cheers,
tony

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


signature.asc
Description: PGP signature

Bug#1026839: systemd: kills --user services after logging out

[Michael Biebl]

Hi

Am 22.12.22 um 18:48 schrieb Philippe Cerfon:

Hey Michael.

So that means KillUserProcesses= affects only non-service user processes?

It's a little bit hard to read that out of it's description in
logind.conf(5). Would it help it that simply says something that this
option doesn't affect --user services?



If you think that the man pages need further clarification, please file
an issue upstream at http://github.com/systemd/systemd/issues (ideally 
with an associated PR).



Michael




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005413: NMU fixing FTBFS and reproducible builds issues

[Vagrant Cascadian]

Control: tags 787996 pending
Control: tags 1005413 pending
Control: tags 1005414 pending

I have uploaded an NMU fixing FTBFS and reproducible builds issues:

diff -Nru cloop-3.14.1.3/advancecomp-1.15/file.cc 
cloop-3.14.1.3+nmu1/advancecomp-1.15/file.cc
--- cloop-3.14.1.3/advancecomp-1.15/file.cc 2020-04-19 01:18:13.0 
-0700
+++ cloop-3.14.1.3+nmu1/advancecomp-1.15/file.cc2022-12-22 
12:41:49.0 -0800
@@ -98,7 +98,7 @@
 /**
  * Check if a file exists.
  */
-bool file_exists(const string& path) throw (error)
+bool file_exists(const string& path)
 {
struct stat s;
if (stat(path.c_str(), ) != 0) {
@@ -114,7 +114,7 @@
 /**
  * Write a whole file.
  */
-void file_write(const string& path, const char* data, unsigned size) throw 
(error)
+void file_write(const string& path, const char* data, unsigned size)
 {
FILE* f = fopen(path.c_str(), "wb");
if (!f)
@@ -134,7 +134,7 @@
 /**
  * Read a whole file.
  */
-void file_read(const string& path, char* data, unsigned size) throw (error)
+void file_read(const string& path, char* data, unsigned size)
 {
file_read(path, data, 0, size);
 }
@@ -142,7 +142,7 @@
 /**
  * Read a whole file.
  */
-void file_read(const string& path, char* data, unsigned offset, unsigned size) 
throw (error)
+void file_read(const string& path, char* data, unsigned offset, unsigned size)
 {
FILE* f = fopen(path.c_str(), "rb");
if (!f)
@@ -166,7 +166,7 @@
 /**
  * Get the time of a file.
  */
-time_t file_time(const string& path) throw (error)
+time_t file_time(const string& path)
 {
struct stat s;
if (stat(path.c_str(), )!=0)
@@ -178,7 +178,7 @@
 /**
  * Set the time of a file.
  */
-void file_utime(const string& path, time_t tod) throw (error)
+void file_utime(const string& path, time_t tod)
 {
struct utimbuf u;
 
@@ -192,7 +192,7 @@
 /**
  * Get the size of a file.
  */
-unsigned file_size(const string& path) throw (error)
+unsigned file_size(const string& path)
 {
struct stat s;
if (stat(path.c_str(), )!=0)
@@ -204,7 +204,7 @@
 /**
  * Get the crc of a file.
  */
-crc_t file_crc(const string& path) throw (error)
+crc_t file_crc(const string& path)
 {
unsigned size = file_size(path);
 
@@ -227,7 +227,7 @@
 /**
  * Copy a file.
  */
-void file_copy(const string& path1, const string& path2) throw (error)
+void file_copy(const string& path1, const string& path2)
 {
unsigned size;
 
@@ -249,7 +249,7 @@
 /**
  * Move a file.
  */
-void file_move(const string& path1, const string& path2) throw (error)
+void file_move(const string& path1, const string& path2)
 {
if (rename(path1.c_str(), path2.c_str())!=0
&& errno==EXDEV) {
@@ -271,7 +271,7 @@
 /**
  * Remove a file.
  */
-void file_remove(const string& path1) throw (error)
+void file_remove(const string& path1)
 {
if (remove(path1.c_str())!=0) {
throw error() << "Failed remove of " << path1;
@@ -281,7 +281,7 @@
 /**
  * Rename a file.
  */
-void file_rename(const string& path1, const string& path2) throw (error)
+void file_rename(const string& path1, const string& path2)
 {
if (rename(path1.c_str(), path2.c_str())!=0) {
throw error() << "Failed rename of " << path1 << " to " << 
path2;
@@ -400,7 +400,7 @@
 /**
  * Make a drectory tree.
  */
-void file_mktree(const std::string& path) throw (error)
+void file_mktree(const std::string& path)
 {
string dir = file_dir(path);
string name = file_name(path);
diff -Nru cloop-3.14.1.3/advancecomp-1.15/file.h 
cloop-3.14.1.3+nmu1/advancecomp-1.15/file.h
--- cloop-3.14.1.3/advancecomp-1.15/file.h  2020-04-19 01:18:13.0 
-0700
+++ cloop-3.14.1.3+nmu1/advancecomp-1.15/file.h 2022-12-22 12:41:49.0 
-0800
@@ -67,18 +67,18 @@
 crc_t crc_compute(const char* data, unsigned len);
 crc_t crc_compute(crc_t pred, const char* data, unsigned len);
 
-bool file_exists(const std::string& file) throw (error);
-void file_write(const std::string& path, const char* data, unsigned size) 
throw (error);
-void file_read(const std::string& path, char* data, unsigned size) throw 
(error);
-void file_read(const std::string& path, char* data, unsigned offset, unsigned 
size) throw (error);
-time_t file_time(const std::string& path) throw (error);
-void file_utime(const std::string& path, time_t tod) throw (error);
-unsigned file_size(const std::string& path) throw (error);
-crc_t file_crc(const std::string& path) throw (error);
-void file_copy(const std::string& path1, const std::string& path2) throw 
(error);
-void file_move(const std::string& path1, const std::string& path2) throw 
(error);
-void file_remove(const std::string& path1) throw (error);
-void file_mktree(const std::string& path1) throw (error);
+bool file_exists(const std::string& file);
+void file_write(const std::string& path, const char* data, unsigned size);
+void file_read(const std::string& path, char* data, unsigned size);

Bug#1026869: lua-nvim: flaky autopkgtest: times out on ppc64el and s390x

[Paul Gevers]

Source: lua-nvim
Version: 0.2.2-1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky timeout
Control: found -1 0.2.3-1-1

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails on s390x and ppc64el due to an autopkgtest 
timeout after 2 hours and 47 minutes, while a successful run only takes 
about a minute.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/packages/l/lua-nvim/testing/ppc64el/
https://ci.debian.net/packages/l/lua-nvim/testing/s390x/
https://ci.debian.net/packages/l/lua-nvim/stable/ppc64el/
https://ci.debian.net/packages/l/lua-nvim/stable/s390x/

https://ci.debian.net/data/autopkgtest/testing/ppc64el/l/lua-nvim/26699552/log.gz
* lua dynamic custom (5.1, autopkgtest) **
[==] Running tests from scanned files.
[--] Global test environment setup.
[--] Running tests from test/session_spec.lua
[ RUN  ] test/session_spec.lua @ 38: Session using ChidProcessStream 
can make requests to nvim
[   OK ] test/session_spec.lua @ 38: Session using ChidProcessStream 
can make requests to nvim (7.88 ms)
[ RUN  ] test/session_spec.lua @ 43: Session using ChidProcessStream 
can get api metadata
autopkgtest [13:07:01]: ERROR: timed out on command "su -s /bin/bash 
debci [...]


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024811: Re: Bug#1024811: linux: /proc/[pid]/stat unparsable

[Thorsten Glaser]

Donald Buczek dixit:

>No, Escaping would break existing programs which parse the line by
>searching for the ')' from the right.

Huh? No!

The format is "(" + string + ") " after all, and only the string
part would get escaped.

The only visible change would be that programs containing a
whitespace character (and, ideally, a ‘(’) in their name would
be escaped, which are these that are currently broken anyway.
And perhaps backslashes, if you decide to encode unambiguous,
but given the field length limit, I don’t think that was ever
a goal (both because I suspect this file was intended to be
used to get a quick overview and therefore deliberately shortens
and because the full info is available elsewhere), so no need to
encode unambiguously.

>If some documentation suggests, that you can just parse it with scanf,
>the documentation should be corrected/improved instead.

No. Someone recently did a survey, and most code in existence splits
by whitespace. Fix the kernel bug instead.

>Are you referring to proc(5) "The fields, in order, with their proper
>scanf(3) format specifiers, are listed below" [1] or something else?

Yes.

>The referenced manual page is wrong in regard to the length, too. There
>is no 16 character limit to the field, because it can contain a
>workqueue task name, too:

Probably used to be cut off after 16. Go fix that in the manpage
then. But do fix the encoding kernel-side.

>In fact, if you start escaping now you might also break programs which
>rely on the current 64 character limit.

Just cut off at the end then, like I suspect was done at 16 bytes
initially.

Or strip whitespace and closing parenthesis if present instead
of encoding them, or replace them with a question mark.

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#1026868: node-puppeteer: autopkgtest regression: 13 failing

[Paul Gevers]

Source: node-puppeteer
Version: 13.4.1+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it recently (around 
august 2022) started to fail consistently in testing.


Paul

https://ci.debian.net/packages/n/node-puppeteer/

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-puppeteer/29397412/log.gz

  887 passing (3m)
  11 pending
  13 failing

  1) Accessibility
   filtering children of leaf nodes
 rich text editable fields should have children:
 Error: expect(received).toEqual(expected) // deep equality

- Expected  - 1
+ Received  + 1

  Object {
"children": Array [
  Object {
-   "name": "Edit this image:",
+   "name": "Edit this image: ",
"role": "StaticText",
  },
  Object {
"name": "my fake image",
"role": "img",
  },
],
"name": "",
"role": "generic",
"value": "Edit this image: ",
  }
  at Context. (test/accessibility.spec.ts:289:36)
  at processTicksAndRejections (node:internal/process/task_queues:95:5)

  2) Accessibility
   filtering children of leaf nodes
 rich text editable fields with role should have children:
 Error: expect(received).toEqual(expected) // deep equality

- Expected  - 5
+ Received  + 1

  Object {
"children": Array [
  Object {
-   "name": "Edit this image:",
+   "name": "Edit this image: ",
"role": "StaticText",
- },
- Object {
-   "name": "my fake image",
-   "role": "img",
  },
],
"multiline": true,
"name": "",
"role": "textbox",
"value": "Edit this image: ",
  }
  at Context. (test/accessibility.spec.ts:327:36)
  at processTicksAndRejections (node:internal/process/task_queues:95:5)

  3) AriaQueryHandler
   queryOne (Chromium web test)
 should find both ignored and unignored:
 Error: expect(received).toEqual(expected) // deep equality

- Expected  - 1
+ Received  + 0

  Array [
"shown",
-   "hidden",
  ]
  at Context. (test/ariaqueryhandler.spec.ts:616:19)
  at processTicksAndRejections (node:internal/process/task_queues:95:5)

  4) Browser specs
   Browser.target
 should return browser target:
 Error: Browser target is not found
  at Browser.target (src/common/Browser.ts:522:13)
  at Context. (test/browser.spec.ts:48:30)
  at callFn (/usr/share/nodejs/mocha/lib/runnable.js:366:21)
  at Test.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:354:5)
  at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:666:10)
  at /usr/share/nodejs/mocha/lib/runner.js:789:12
  at next (/usr/share/nodejs/mocha/lib/runner.js:581:14)
  at /usr/share/nodejs/mocha/lib/runner.js:591:7
  at next (/usr/share/nodejs/mocha/lib/runner.js:474:14)
  at Immediate. 
(/usr/share/nodejs/mocha/lib/runner.js:559:5)

  at processImmediate (node:internal/timers:471:21)

  5) Emulation
   Page.emulateVisionDeficiency
 should work:
 Error: screenshot-sanity.png mismatch! Sizes differ: expected 
image 500px X 500px, but got 500px X 1000px.  Output is saved in 
"output-chromium" directory

  at Context. (test/emulation.spec.ts:338:28)
  at processTicksAndRejections (node:internal/process/task_queues:95:5)

  6) Launcher specs
   Puppeteer
 Puppeteer.executablePath
   when PUPPETEER_EXECUTABLE_PATH is set
 "before each" hook for "its value is returned":
 TypeError: 'process.env' only accepts a configurable, writable, 
and enumerable data descriptor

  at Function.defineProperty ()
  at Object.value 
(node_modules/sinon/lib/sinon/default-behaviors.js:269:16)
  at Object.proto. [as value] 
(node_modules/sinon/lib/sinon/behavior.js:260:12)
  at Function. 
(node_modules/sinon/lib/sinon/behavior.js:250:46)

  at Context. (test/launcher.spec.ts:770:14)
  at callFn (/usr/share/nodejs/mocha/lib/runnable.js:366:21)
  at Hook.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:354:5)
  at next (/usr/share/nodejs/mocha/lib/runner.js:498:10)
  at Immediate._onImmediate 
(/usr/share/nodejs/mocha/lib/runner.js:559:5)

  at processImmediate (node:internal/timers:471:21)

  7) Launcher specs
   Puppeteer
 Puppeteer.executablePath
   when the product is chrome, platform is not darwin, and arch 
is arm64

 and the executable exists
   and PUPPETEER_EXECUTABLE_PATH is set
 "before each" hook for "its value is returned":
 TypeError: 'process.env' only accepts a configurable, writable, 
and enumerable data descriptor

  at Function.defineProperty ()
  at Object.value 
(node_modules/sinon/lib/sinon/default-behaviors.js:269:16)
  at Object.proto. [as value] 
(node_modules/sinon/lib/sinon/behavior.js:260:12)
  at Function. 
(node_modules/sinon/lib/sinon/behavior.js:250:46)

  

Bug#1026867: transition: youtube-dl

[Andres Salomon]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: 994...@bugs.debian.org, debian-de...@lists.debian.org

Hi,

Youtube-dl has mostly stopped development other than basic maintenance, and
development has resumed with the yt-dlp project (which is already in debian)
as documented in .

For the bookworm release, we intend to drop the youtube-dl upstream code 
from
the archive, with an empty transition package that will simply depend on 
yt-dlp

and a NEWS entry informing users of the change. We considered attempting a
seamless transition that provided a wrapper python module for the youtube_dl
library and the /usr/bin/youtube-dl executable, but there are complications
(such slightly different behavior between the two programs even when using
yt-dlp's provided '--compat-options youtube-dl' argument, and programs 
that are
aware of both yt-dlp and youtube-dl that will get confused if we pretend 
that
youtube-dl is yt-dlp). Rather than risk the potential to introduce 
silent bugs

into user setups, we prefer to simply inform users of the change and require
them to manually verify their setups with yt-dlp.

I filed 13 bugs with packages that have reverse dependencies on youtube-dl
(ignoring those packages that depend on yt-dlp|youtube-dl); half have 
already
been fixed. I plan to bump the severity on remaining bugs once the 
youtube-dl
transition package is uploaded to sid (for those packages that actually 
break

without a youtube-dl script/library).

Depends on youtube-dl:
ytcc: #1024212
youtubedl-gui: #1024214 (done)
mkchromecast: #1024216

Recommends youtube-dl:
lollypop: #1024217 (done)
celluloid: #1024222
lives: #1024229
libmpv1: #1026866

Suggests youtube-dl:
git-annex: #1024226 (done)
gpodder: #1024227 (done)
liquidsoap: #1024228 (done)
ytfzf: #1024230 (done)
acetoneiso: #1024231
python3-moviepy: #1024232

There are no library or ABI concerns with this transition, this is mostly
to get a transition slot and to track the transition.

Ben file:

title = "youtube-dl";
is_affected = .build-depends ~ /youtube-dl/ | .depends ~ /youtube-dl/;
is_good = .build-depends ~ /yt-dlp/ | .depends ~ /yt-dlp/;
is_bad = .build-depends ~ /youtube-dl/ | .depends ~ /youtube-dl/;

I can NMU where necessary for the remaining bugs, once the transition is
underway.

Thanks,
Andres

Bug#1023262: any2fasta_0.4.2-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,

Am Thu, Dec 22, 2022 at 07:00:10PM + schrieb Thorsten Alteholz:
> in this package even the README says that the license is GPL-3-only ...

Thanks for checking in usually busy days
Andreas. 

-- 
http://fam-tille.de

Bug#1026866: libmpv1: please drop youtube-dl versioned recommends

[Andres Salomon]

Package: libmpv1
Version: 0.34.1-1+b5
Severity: minor

We are planning to drop youtube-dl from the archive, as it has been 
replaced by yt-dlp (see  for more 
details). The mpv package already recommends yt-dlp, but the libmpv1 
package has an old versioned recommends for youtube-dl (>= 2014.11.26). 
This is likely a legacy thing, but that recommends should either be 
completely dropped (if the need for it was only due to a bug or 
incompatibility related to an ancient version of youtube-dl), or 
replaced with a recommends on yt-dlp.


I don't anticipate the youtube-dl -> yt-dlp transition breaking libmpv1 
either way, which is why this is filed as minor; but it would be good 
to clean up these references to youtube-dl before the bookworm+1 
release.

Bug#1026666: Please make liblog4j2-java depend on junit5

[Pierre Gruet]

Hi again tony,

Le 22/12/2022 à 16:16, tony mancill a écrit :

Hi Pierre,

On Thu, Dec 22, 2022 at 07:31:30AM +0100, Pierre Gruet wrote:

Hi tony,

Le 21/12/2022 à 22:58, tony mancill a écrit :

On Tue, Dec 20, 2022 at 11:45:54PM +0100, Pierre Gruet wrote:

Control: retitle -1 Please make liblog4j2-java depend on junit5

Hello,

In version 2.19.0-1 of liblog4j2-java, the file

/usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom
declares the junit-bom artifact as a dependency. It is shipped in junit5.

If this dependency is not added, reverse dependencies of liglog4j2-java fail
to build (see logs above) as the junit-bom artifact is not found.


Hi Pierre,

I'm wondering if it wouldn't better to remove junit-bom from log4j pom.
I don't believe we actually need junit5 at runtime for log4j2, so
packages depending on liblog4j2-java should not have to install junit5.

Any concerns with taking that approach and addressing the bug by
adjusting the pom shipped with liblog4j2-java?


Thanks for having a look; I haven't looked further but I also fail to
imagine why junit5 would be needed, so I agree with the proposed fix!


I am spot-checking a few of the reverse dependencies now and will upload
today.  Thank you for identifying the root cause for this set of build
failures.



Glad I could help! THanks for taking care of the fix.
If I may help in any way, please tell me :)


Cheers,
tony


Best,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#997715: libapache-poi-java: FTBFS in bullseye: tests failed

[Santiago Vila]

Dear maintainers:

This package FTBFS for me on bullseye, tried several times on different 
machines.
(I'm attaching a build log)

I think it is the same bug reported by Lucas back in October 2021 (i.e. this 
one),
which was fixed only in bookworm.

Unfortunately, I'm not 100% sure, because I tried applying 
ignore-test-errors.patch
to the bullseye version and the FTBFS did not go away.

Please tell me if you think it's the same bug, or I have to open a new one.
(Packages in bullseye must build in bullseye).

Thanks.

libapache-poi-java_4.0.1-1_amd64-20221130T15.178Z.gz
Description: application/gzip

Bug#1026865: libthrust: flaky autopkgtest (host dependent)

[Paul Gevers]

Source: libthrust
Version: 1.16.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails on amd64. The failures seem related on the host 
that runs the test. The tests seem to pass on ci-worker13 (our beefy 
host [1], but fail and timeout (after 12 hours) on our other hosts [2].


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

[1] https://metal.equinix.com/product/servers/m3-large/
[2] https://aws.amazon.com/ec2/instance-types/m5/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026864: dmrgpp: flaky autopkgtest on amd64: times out

[Paul Gevers]

Source: dmrgpp
Version: 6.02-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky timeout

Dear maintainer(s),

I looked at the results of the autopkgtest of your package. I noticed 
that it regularly fails on amd64 because it times out after 2 hours and 
47 minutes. Apparently this only happens on our most powerful worker: 
ci-worker13, but not all runs there time out. I'm wondering if this 
might be a race condition that the test only experiences with lots of 
CPUs (64) or lots of memory (256GB) (and depends on the load of the system).


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026863: libvirtd segfaults on virsh define given typo

[Gedalya]

Package: libvirt-daemon
Version: 8.10.0-2


Hello,

Given the following stanza in a domain XML,

    
  
  
    

with bridge='eno1' instead of dev='eno1', libvirtd segfaults.

See attached backtrace, libvirtd invoked with -v for extra noise

Thanks,

Gedalya

2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleDispatch:115 : 
EVENT_GLIB_DISPATCH_HANDLE: watch=2 events=1 cb=0x7f247e1d3150 
opaque=0x55ad955240f0
2022-12-22 19:29:00.366+: 17555: info : virObjectNew:256 : OBJECT_NEW: 
obj=0x55ad955246f0 classname=virNetSocket
2022-12-22 19:29:00.366+: 17555: info : virNetSocketNew:294 : 
RPC_SOCKET_NEW: sock=0x55ad955246f0 fd=16 errfd=-1 pid=0 localAddr=127.0.0.1;0, 
remoteAddr=127.0.0.1;0
2022-12-22 19:29:00.366+: 17555: info : virObjectNew:256 : OBJECT_NEW: 
obj=0x55ad9552e640 classname=virNetServerClient
2022-12-22 19:29:00.366+: 17555: info : virObjectRef:400 : OBJECT_REF: 
obj=0x55ad955246f0
2022-12-22 19:29:00.366+: 17555: info : virEventGLibTimeoutAdd:358 : 
EVENT_GLIB_ADD_TIMEOUT: timer=16 interval=-1 cb=0x7f247e1e7b90 
opaque=0x55ad9552e640 ff=(nil)
2022-12-22 19:29:00.366+: 17555: info : virNetServerClientNewInternal:409 : 
RPC_SERVER_CLIENT_NEW: client=0x55ad9552e640 sock=0x55ad955246f0
2022-12-22 19:29:00.366+: 17555: info : virObjectRef:400 : OBJECT_REF: 
obj=0x55ad9552e640
2022-12-22 19:29:00.366+: 17555: info : virObjectRef:400 : OBJECT_REF: 
obj=0x55ad955246f0
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleAdd:159 : 
EVENT_GLIB_ADD_HANDLE: watch=14 fd=16 events=1 cb=0x7f247e1d3150 
opaque=0x55ad955246f0 ff=0x7f247e1d30f0
2022-12-22 19:29:00.366+: 17555: info : virObjectRef:400 : OBJECT_REF: 
obj=0x55ad9552e640
2022-12-22 19:29:00.366+: 17555: info : virNetServerCheckLimits:292 : 
Re-enabling services
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleUpdate:194 : 
EVENT_GLIB_UPDATE_HANDLE: watch=2 events=1
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleUpdate:194 : 
EVENT_GLIB_UPDATE_HANDLE: watch=3 events=1
2022-12-22 19:29:00.366+: 17555: info : virObjectNew:256 : OBJECT_NEW: 
obj=0x7f242c0165d0 classname=virKeepAlive
2022-12-22 19:29:00.366+: 17555: info : virKeepAliveNew:205 : 
RPC_KEEPALIVE_NEW: ka=0x7f242c0165d0 client=0x55ad9552e640
2022-12-22 19:29:00.366+: 17555: info : virObjectRef:400 : OBJECT_REF: 
obj=0x55ad9552e640
2022-12-22 19:29:00.366+: 17555: info : virObjectUnref:378 : OBJECT_UNREF: 
obj=0x55ad9552e640
2022-12-22 19:29:00.366+: 17555: info : virObjectUnref:378 : OBJECT_UNREF: 
obj=0x55ad955246f0
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleDispatch:115 : 
EVENT_GLIB_DISPATCH_HANDLE: watch=14 events=1 cb=0x7f247e1d3150 
opaque=0x55ad955246f0
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleUpdate:194 : 
EVENT_GLIB_UPDATE_HANDLE: watch=14 events=1
2022-12-22 19:29:00.366+: 17555: info : virNetServerClientDispatchRead:1224 
: RPC_SERVER_CLIENT_MSG_RX: client=0x55ad9552e640 len=28 prog=536903814 vers=1 
proc=66 type=0 status=0 serial=0
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleUpdate:194 : 
EVENT_GLIB_UPDATE_HANDLE: watch=14 events=1
2022-12-22 19:29:00.366+: 17555: info : virObjectRef:400 : OBJECT_REF: 
obj=0x55ad9550b080
2022-12-22 19:29:00.366+: 17555: info : virObjectRef:400 : OBJECT_REF: 
obj=0x55ad9552e640
2022-12-22 19:29:00.366+: 17555: info : virObjectRef:400 : OBJECT_REF: 
obj=0x55ad9551f810
2022-12-22 19:29:00.366+: 17555: info : virObjectUnref:378 : OBJECT_UNREF: 
obj=0x55ad9550b080
2022-12-22 19:29:00.366+: 17563: info : remoteDispatchAuthList:3601 : 
Bypass polkit auth for privileged client pid:17652,uid:0
2022-12-22 19:29:00.366+: 17563: info : virNetServerCheckLimits:292 : 
Re-enabling services
2022-12-22 19:29:00.366+: 17563: info : virEventGLibHandleUpdate:194 : 
EVENT_GLIB_UPDATE_HANDLE: watch=2 events=1
2022-12-22 19:29:00.366+: 17563: info : virEventGLibHandleUpdate:194 : 
EVENT_GLIB_UPDATE_HANDLE: watch=3 events=1
2022-12-22 19:29:00.366+: 17563: info : 
virNetServerClientSendMessageLocked:1460 : RPC_SERVER_CLIENT_MSG_TX_QUEUE: 
client=0x55ad9552e640 len=36 prog=536903814 vers=1 proc=66 type=1 status=0 
serial=0
2022-12-22 19:29:00.366+: 17563: info : virEventGLibHandleUpdate:194 : 
EVENT_GLIB_UPDATE_HANDLE: watch=14 events=3
2022-12-22 19:29:00.366+: 17563: info : virObjectUnref:378 : OBJECT_UNREF: 
obj=0x55ad9551f810
2022-12-22 19:29:00.366+: 17563: info : virObjectUnref:378 : OBJECT_UNREF: 
obj=0x55ad9552e640
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleDispatch:115 : 
EVENT_GLIB_DISPATCH_HANDLE: watch=14 events=2 cb=0x7f247e1d3150 
opaque=0x55ad955246f0
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleUpdate:194 : 
EVENT_GLIB_UPDATE_HANDLE: watch=14 events=1
2022-12-22 19:29:00.366+: 17555: info : virEventGLibHandleDispatch:115 : 
EVENT_GLIB_DISPATCH_HANDLE: watch=14 events=1 cb=0x7f247e1d3150 

Bug#1025386: firejail: cannot use gdb with --allow-debuggers --profile=firefox

[Reiner Herrmann]

On Thu, Dec 22, 2022 at 08:41:26PM +0100, Vincent Lefevre wrote:
> On 2022-12-22 19:27:37 +0100, Reiner Herrmann wrote:
> > You can install gdb-minimal. It does not have Python-support and works
> > with your original "firejail --allow-debuggers --profile=firefox gdb"
> > command line.
> 
> But it is not co-installable with gdb. This is silly!
> 
> gdb-minimal apparently doesn't have source highlighting,
> so I would need both. Or there should be a 3rd package
> gdb-nopython.

Please consider opening a bug against the gdb package then.
I think there is nothing I could change in firejail.

Regards,
  Reiner

Bug#1025386: firejail: cannot use gdb with --allow-debuggers --profile=firefox

[Vincent Lefevre]

On 2022-12-22 19:27:37 +0100, Reiner Herrmann wrote:
> You can install gdb-minimal. It does not have Python-support and works
> with your original "firejail --allow-debuggers --profile=firefox gdb"
> command line.

But it is not co-installable with gdb. This is silly!

gdb-minimal apparently doesn't have source highlighting,
so I would need both. Or there should be a 3rd package
gdb-nopython.

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

Bug#1024322: transition: dpdk

[Sebastian Ramacher]

On 2022-12-22 20:16:36 +0100, Luca Boccassi wrote:
> On Sat, 17 Dec 2022 14:52:30 +0100 Sebastian Ramacher
>  wrote:
> > Control: tags -1 confirmed
> > 
> > Hi Luca
> > 
> > On 2022-12-17 02:12:56 +, Luca Boccassi wrote:
> > > Control: tags -1 -moreinfo
> > > 
> > > On Wed, 23 Nov 2022 at 19:49, Sebastian Ramacher
>  wrote:
> > > >
> > > > Control: tags -1 moreinfo
> > > >
> > > > On 2022-11-17 14:27:25 +, Luca Boccassi wrote:
> > > > > Package: release.debian.org
> > > > > Severity: normal
> > > > > User: release.debian@packages.debian.org
> > > > > Usertags: transition
> > > > > X-Debbugs-CC:
> pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org
> > > > >
> > > > > Hello Thomas and Release Team,
> > > > >
> > > > > As we did for Bullseye, we are proposing the following plan to
> allow
> > > > > Bookworm to ship with the latest LTS versions of DPDK and OVS.
> This
> > > > > will let us make use of the full LTS support windows for both
> projects,
> > > > > as we have done for the past few releases.
> > > > >
> > > > > Upload OVS built from git (with new sonames/package renames if
> > > > > necessary), new OVN, DPDK 22.11 in early-to-mid December to
> unstable,
> > > > > ideally before the 16th as we go on vacation after that, to
> finish the
> > > > > transition.
> > > > >
> > > > > Then, after OVS 3.1 releases in February, upload it unstable
> (no
> > > > > soname/transition required, as only bug fixes will go in at
> that
> > > > > point). The upstream release might happen before or after the
> > > > > 2023/02/12 soft freeze, and if it is after we will ask for an
> > > > > exception.
> > > > >
> > > > > Would this plan work for everyone?
> > > >
> > > > Sounds like that should work like last time. Please remove the
> moreinfo
> > > > tag once dpdk is ready for the upload to unstable.
> > > 
> > > Hi,
> > > 
> > > We are now ready. dpdk, openvswitch and ovn are ready in
> experimental.
> > > uhd and collectd in unstable will need a simple binary rebuild and
> are
> > > already compatible.
> > 
> > Please go ahead
> 
> Only src:uhd has been rebuilt, please rebuild src:collectd too (it only
> has Recommends instead of Depends as it's a plugin-based software, so
> it won't show in apt rdepends et al).

I'll schedule those builds once dpkd migrated. Otherwise the rebuilds
migrate before the recommends can be satisfied in testing.

Cheers
-- 
Sebastian Ramacher

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

[Timo Aaltonen]

Vincent Lefevre kirjoitti 21.12.2022 klo 15.01:

Package: libx11-6
Version: 2:1.8.3-2
Severity: grave
Justification: renders package unusable

or possible data loss?

After the upgrade to libx11-6 2:1.8.3-2, I get the following errors
when running emacs:

e.g.

Xlib: sequence lost (0x1 > 0x473) in reply type 0x21!
Xlib: sequence lost (0x1 > 0x58e) in reply type 0xf!
Xlib: sequence lost (0x1 > 0x9bb) in reply type 0xf!
Xlib: sequence lost (0x1 > 0xfb4) in reply type 0xc!
Xlib: sequence lost (0x1 > 0xfbe) in reply type 0xf!

or

Xlib: sequence lost (0x1 > 0x450) in reply type 0x1c!
Xlib: sequence lost (0x1 > 0x45b) in reply type 0x13!
Xlib: sequence lost (0x1 > 0x473) in reply type 0x21!
Xlib: sequence lost (0x1 > 0x567) in reply type 0xf!
Xlib: sequence lost (0x1 > 0xa0d) in reply type 0xf!
Xlib: sequence lost (0x1 > 0xfb7) in reply type 0xc!
Xlib: sequence lost (0x1 > 0xfc1) in reply type 0xf!

etc.

This changes each time.

Not sure about the bug severity, but if such errors are output,
this means that they are really serious. Otherwise, the end user
shouldn't be bothered. In any case, this must be fixed before
the next Debian release.



meh, well the offending commit is found so I'll revert that as well 
unless a fix is made upstream soon, and that's unlikely due to holidays



--
t

Bug#828876: ario: please make the build reproducible

[Vagrant Cascadian]

Control: tags 828876 pending

On 2022-10-06, Vagrant Cascadian wrote:
> On 2016-06-28, Reiner Herrmann wrote:
>> While working on the "reproducible builds" effort [1], we have noticed
>> that ario could not be built reproducibly.
>> It embeds the current year into the binary.
>>
>> The attached patch replaces it with a static value.
>
> I can confirm this patch is still needed, but when I tried applying this
> patch, it fails to build asking for automake-1.15 (which is no longer in
> debian, but automake-1.16 is):
>
>   Making all in src
>   make[3]: Entering directory '/<>/src'
>   cd .. && /bin/bash /<>/missing automake-1.15 --foreign 
> src/Makefile
>   /<>/missing: line 81: automake-1.15: command not found
>   WARNING: 'automake-1.15' is missing on your system.
>   You should only need it if you modified 'Makefile.am' or
>   'configure.ac' or m4 files included by 'configure.ac'.
>
> Struggling to figure out how to get cdbs to actually regenerate the
> files with a newer automake...

Fixed this by adding support for dh-autoreconf.

Uploaded an NMU fixing this to DELAYED/10:

diff -Nru ario-1.6/debian/changelog ario-1.6/debian/changelog
--- ario-1.6/debian/changelog   2021-01-02 09:54:20.0 -0800
+++ ario-1.6/debian/changelog   2022-12-22 10:45:30.0 -0800
@@ -1,3 +1,16 @@
+ario (1.6-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Reiner Herrmann ]
+  * Replace current year with static value to get reproducible build
+(Closes: #828876)
+
+  [ Vagrant Cascadian ]
+  * Use dh-autoreconf.
+
+ -- Vagrant Cascadian   Thu, 22 Dec 2022 10:45:30 -0800
+
 ario (1.6-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru ario-1.6/debian/control ario-1.6/debian/control
--- ario-1.6/debian/control 2018-01-14 14:06:03.0 -0800
+++ ario-1.6/debian/control 2022-12-22 10:45:30.0 -0800
@@ -2,7 +2,7 @@
 Section: sound
 Priority: optional
 Maintainer: Marc Pavot 
-Build-Depends: debhelper (>=9), cdbs, autotools-dev, libgtk-3-dev, 
libglib2.0-dev, libxml2-dev, libcurl4-gnutls-dev, intltool, 
libavahi-client-dev, libavahi-glib-dev, libdbus-glib-1-dev, libtagc0-dev, 
libmpdclient-dev, 
+Build-Depends: debhelper (>=9), dh-autoreconf, cdbs, autotools-dev, 
libgtk-3-dev, libglib2.0-dev, libxml2-dev, libcurl4-gnutls-dev, intltool, 
libavahi-client-dev, libavahi-glib-dev, libdbus-glib-1-dev, libtagc0-dev, 
libmpdclient-dev, 
 Standards-Version: 4.1.3
 Homepage: http://ario-player.sourceforge.net/
 
diff -Nru 
ario-1.6/debian/patches/replace-current-year-with-static-value-t.patch 
ario-1.6/debian/patches/replace-current-year-with-static-value-t.patch
--- ario-1.6/debian/patches/replace-current-year-with-static-value-t.patch  
1969-12-31 16:00:00.0 -0800
+++ ario-1.6/debian/patches/replace-current-year-with-static-value-t.patch  
2022-12-22 10:45:30.0 -0800
@@ -0,0 +1,36 @@
+From: Reiner Herrmann 
+Date: Tue, 28 Jun 2016 20:57:58 +0200
+X-Dgit-Generated: 1.6-1.2 ee49d4c2ad945b1ccb14656dba223bd01cc15557
+Subject: Replace current year with static value to get reproducible build
+
+(Closes: #828876)
+
+---
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 64f2fef..c6a855e 100644
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -206,8 +206,7 @@ AM_CPPFLAGS = \
+ -DDATA_PATH=\""$(pkgdatadir)/data/"\"\
+ -DUI_PATH=\""$(pkgdatadir)/ui/"\"\
+   -DARIO_PLUGIN_DIR=\"$(PLUGINDIR)\"\
+-  -DARIO_PLUGIN_DATA_DIR=\"$(PLUGIN_DATA_DIR)\"\
+-  -DCURRENT_DATE="\"`date +%G`\""
++  -DARIO_PLUGIN_DATA_DIR=\"$(PLUGIN_DATA_DIR)\"
+ 
+ if MPD_GLIB
+ AM_CPPFLAGS += -DMPD_GLIB
+diff --git a/src/shell/ario-shell.c b/src/shell/ario-shell.c
+index a9cb4fa..b6422e7 100644
+--- a/src/shell/ario-shell.c
 b/src/shell/ario-shell.c
+@@ -665,7 +665,7 @@ ario_shell_cmd_about (GSimpleAction *action,
+"name", "Ario",
+"program-name", "Ario",
+"version", PACKAGE_VERSION,
+-   "copyright", "Copyright \xc2\xa9 2005-" 
CURRENT_DATE " Marc Pavot",
++   "copyright", "Copyright \xc2\xa9 2005-2011 
Marc Pavot",
+"comments", _("GTK client for MPD"),
+"translator-credits", _("translator-credits"),
+"authors", (const char **) authors,
diff -Nru ario-1.6/debian/patches/series ario-1.6/debian/patches/series
--- ario-1.6/debian/patches/series  2018-01-14 14:06:03.0 -0800
+++ ario-1.6/debian/patches/series  2022-12-22 10:45:30.0 -0800
@@ -0,0 +1 @@
+replace-current-year-with-static-value-t.patch
diff -Nru ario-1.6/debian/rules ario-1.6/debian/rules
--- ario-1.6/debian/rules   2013-05-18 10:26:19.0 -0700
+++ ario-1.6/debian/rules   2022-12-22 10:45:30.0 -0800
@@ -2,6 +2,7 @@
   

Bug#1026021: pytest-forked: FTBFS with pytest 7.2

[Timo Röhling]

* Scott Talbert  [2022-12-22 12:29]:


Thanks, I did notice this but I was planning to wait on a new upstream 
release which should fix this (hopefully coming soon).



No problem. I found your PR in the mean time (better than my hotfix
btw), and pytest still has a few other regressions anyway, so I'm
fine waiting for upstream to have a proper release soon(ish).


Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1024322: transition: dpdk

[Luca Boccassi]

On Sat, 17 Dec 2022 14:52:30 +0100 Sebastian Ramacher
 wrote:
> Control: tags -1 confirmed
> 
> Hi Luca
> 
> On 2022-12-17 02:12:56 +, Luca Boccassi wrote:
> > Control: tags -1 -moreinfo
> > 
> > On Wed, 23 Nov 2022 at 19:49, Sebastian Ramacher
 wrote:
> > >
> > > Control: tags -1 moreinfo
> > >
> > > On 2022-11-17 14:27:25 +, Luca Boccassi wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > > X-Debbugs-CC:
pkg-dpdk-de...@lists.alioth.debian.org z...@debian.org
> > > >
> > > > Hello Thomas and Release Team,
> > > >
> > > > As we did for Bullseye, we are proposing the following plan to
allow
> > > > Bookworm to ship with the latest LTS versions of DPDK and OVS.
This
> > > > will let us make use of the full LTS support windows for both
projects,
> > > > as we have done for the past few releases.
> > > >
> > > > Upload OVS built from git (with new sonames/package renames if
> > > > necessary), new OVN, DPDK 22.11 in early-to-mid December to
unstable,
> > > > ideally before the 16th as we go on vacation after that, to
finish the
> > > > transition.
> > > >
> > > > Then, after OVS 3.1 releases in February, upload it unstable
(no
> > > > soname/transition required, as only bug fixes will go in at
that
> > > > point). The upstream release might happen before or after the
> > > > 2023/02/12 soft freeze, and if it is after we will ask for an
> > > > exception.
> > > >
> > > > Would this plan work for everyone?
> > >
> > > Sounds like that should work like last time. Please remove the
moreinfo
> > > tag once dpdk is ready for the upload to unstable.
> > 
> > Hi,
> > 
> > We are now ready. dpdk, openvswitch and ovn are ready in
experimental.
> > uhd and collectd in unstable will need a simple binary rebuild and
are
> > already compatible.
> 
> Please go ahead

Only src:uhd has been rebuilt, please rebuild src:collectd too (it only
has Recommends instead of Depends as it's a plugin-based software, so
it won't show in apt rdepends et al).

-- 
Kind regards,
Luca Boccassi


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

Bug#1026862: Wrong installation path for tmpfiles.d/tpm2-tss-fapi.conf

[Christoph Biedl]

Package: libtss2-fapi1
Version: 3.2.1-1
Severity: normal

(...)
Setting up libtss2-fapi1:amd64 (3.2.1-1) ...
Failed to read '/usr/lib/tmpfiles.d/tpm2-tss-fapi.conf': Is a directory
(...)

Cause is an old trap, debian/*.install wants a directory only in the
second column. Happens all the time to me as well :)

And therefore, package content:

-rw-r--r-- root/root   432 2022-12-19 07:42 
./usr/lib/tmpfiles.d/tpm2-tss-fapi.conf/tpm2-tss-fapi.conf

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#986458: python-pangolearn_2022-02-02+dfsg-1_amd64.changes REJECTED

[Thorsten Alteholz]

Hi Andreas,

On 21.12.22 20:25, Andreas Tille wrote:

Am Wed, Dec 21, 2022 at 07:00:10PM + schrieb Thorsten Alteholz:

shouldn't be that license better GPL-3.0 only?

I admit I have no idea what in

 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 (at your option) any later version.

makes you believe that this should be better GPL-3.0


I did a grep for "either version 3" over all files and just found this 
term in the standard example of how to apply the GPL to some software. A 
few lines above it clearly says "END OF TERMS AND CONDITIONS".


So I have to an answer with a question: What makes you believe that this 
term is part of the license of this software?


   Thorsten

Bug#1026856: [3dprinter-general] Bug#1026856: cura-engine: FTBFS: 14 tests segfault

[Gregor Riepl]

cura-engine/experimental recently started to FTBFS:

46% tests passed, 14 tests failed out of 26


This is caused by the recent protobuf transition, see gdb log below.

It will be fixed in libarcus 5.0.0-2, which is waiting for release:
https://salsa.debian.org/3dprinting-team/libarcus/-/commit/c2dfe6eacb2213195619b50f1d1efc7cd519c8f8

@myon: Can you take care of pushing this version, please?

Thank you!



(gdb) run
Starting program: 
/home/onitake/Code/cura/CuraEngine/obj-x86_64-linux-gnu/ArcusCommunicationPrivateTest 


[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x773b8c90 in 
google::protobuf::internal::AddDescriptors(google::protobuf::internal::DescriptorTable 
const*) () from /lib/x86_64-linux-gnu/libprotobuf.so.23

(gdb) bt
#0  0x773b8c90 in 
google::protobuf::internal::AddDescriptors(google::protobuf::internal::DescriptorTable 
const*) () from /lib/x86_64-linux-gnu/libprotobuf.so.23
#1  0x773b8cf2 in 
google::protobuf::internal::AddDescriptors(google::protobuf::internal::DescriptorTable 
const*) () from /lib/x86_64-linux-gnu/libprotobuf.so.23
#2  0x77fcfabe in call_init (env=0x7fffdc88, 
argv=0x7fffdc78, argc=1, l=) at ./elf/dl-init.c:70
#3  call_init (l=, argc=1, argv=0x7fffdc78, 
env=0x7fffdc88) at ./elf/dl-init.c:26
#4  0x77fcfba4 in _dl_init (main_map=0x77ffe2e0, argc=1, 
argv=0x7fffdc78, env=0x7fffdc88) at ./elf/dl-init.c:117

#5  0x77fe59f0 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6  0x0001 in ?? ()
#7  0x7fffe032 in ?? ()
#8  0x in ?? ()

Bug#1026861: Broken Official Archives (including global mirrors)

[dubba]

Package: project
Version: 3.1r8

The .jigdo and .template files for DVD ISOs of Debian GNU/Linux 3.1r8 
(Sarge, final version) no longer function to generate the following 
ISOs:

- DVD ISO 1 for i386 arch;
- DVD ISO 1 for IA64 arch;
- DVD ISO 1 for PowerPC arch;
- DVD ISO 2 for PowerPC arch;

As both the official BitTorrent files for these (.torrent), as well as 
direct .ISO links, are no longer provided for older versions, the only 
method officially available to obtain this OS is via the Jigsaw Download 
(jigdo) tool called jigdo-lite, according to Debian GNU/Linux official 
guides.


The "good news" is that it seems to be only between 1 or 2 files that 
are missing for each of those images to be completed, suggesting the 
error was likely accidental, and a fix is hopefully doable. Below is the 
output I get for the aforementioned DVD ISO 2 for PowerPC arch, as an 
example:



Found 0 of the 2 files required by the template
Copied input files to temporary file 
`debian-31r8-powerpc-binary-2.iso.tmp' - repeat command and supply more 
files to continue


-
Aaargh - 2 files could not be downloaded. This should not
happen! Depending on the problem, it may help to retry downloading
the missing files.
Also, you could try changing to another Debian or Non-US server,
in case the one you used is out of sync.

However, if all the files downloaded without errors and you
still get this message, it means that the files changed on the
server, so the image cannot be generated.
As a last resort, you could try to complete the CD image download
by fetching the remaining data with rsync.


Switching to use different servers from US, Japan and beyond yielded the 
same results, even when deleting the partial download data and 
restarting the download process.


I suspect further Jigdo downloads might be broken beyond those I 
highlight in this e-mail, in particular those for exotic architectures 
(m68k etc.) and those of even older Debian GNU/Linux versions, however 
that much has yet to be confirmed.


I installed jigdo-lite via the package manager "Fink" under macOS 
10.14.6 Mojave on an AMD64 (x86_64) machine, through which I 
successfully downloaded and assembled multiple Debian GNU/Linux ISO 
images, the sole exceptions being the ones mentioned above.


Although it would not fix the bug per se, jigdo-lite also suggests to 
use "rsync" as a "last resort", however I have no idea how rsync could 
assist with this, nor how it could be used to solve this problem, if at 
all.


Any support, feedback and/or bugfix to solve this problem would be 
greatly appreciated.


Sincerely,

Dubba

Bug#1026860: libarcus: Lintian error custom-library-search-path due to rpath usage

[Gregor Riepl]

Source: libarcus
Version: 5.0.0-1
Severity: normal
X-Debbugs-Cc: onit...@gmail.com

This seems to a new occurrence, reported since the build was switched to DH13.

E: python3-arcus: custom-library-search-path RUNPATH
/usr/lib/python3.10/config-3.10-x86_64-linux-gnu [usr/lib/python3/dist-
packages/pyArcus.cpython-310-x86_64-linux-gnu.so]

Caused by (search for -rpath):

[100%] Linking CXX shared library pyArcus.so
/usr/bin/cmake -E cmake_link_script CMakeFiles/sip_pyArcus.dir/link.txt
--verbose=1
/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=<>/libArcus=. -fstack-
protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -flto=auto -fno-fat-lto-objects -Wl,-z,relro -Wl,-z,now
-shared -Wl,-soname,pyArcus.so -o pyArcus.so
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_array.c.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_core.c.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_descriptors.c.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_enum.c.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_int_convertors.c.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_object_map.c.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_threads.c.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_voidptr.c.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sip_bool.cpp.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart0.cpp.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart1.cpp.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart2.cpp.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart3.cpp.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart4.cpp.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart5.cpp.o
CMakeFiles/sip_pyArcus.dir/pyArcus/pyArcus/sippyArcuspart6.cpp.o
CMakeFiles/sip_pyArcus.dir/python/PythonMessage.cpp.o
-Wl,-rpath,<>/libArcus/.pybuild/cpython3_3.10/build:/usr/lib/python3.10/config-3.10-x86_64-linux-
gnu: libArcus.so.5.0.0 /usr/lib/x86_64-linux-gnu/libprotobuf.so
/usr/lib/python3.10/config-3.10-x86_64-linux-gnu/libpython3.10.so

It seems that the rpath option is generated by pybuild, but I'm not 100% sure.
If this is the case, I think this issue should be reported against pybuild.


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

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

Bug#1025386: firejail: cannot use gdb with --allow-debuggers --profile=firefox

[Reiner Herrmann]

On Thu, Dec 22, 2022 at 07:20:07PM +0100, Vincent Lefevre wrote:
> Hi Reiner,
> 
> On 2022-12-10 18:48:39 +0100, Reiner Herrmann wrote:
> > Debugging tools that have dependencies (like in your example gdb -> python3)
> > need to be handled additionally (either by asking gdb to not use the
> > python3 extensions, or by adding parameters that whitelist it).
> > 
> > With the following command line I was able to get a gdb shell:
> > > $ firejail --allow-debuggers --include=/etc/firejail/allow-python3.inc 
> > > --profile=firefox gdb
> > > [...]
> > > (gdb)
> 
> However, this is not a good solution from a security point of view.
> There's a difference between allowing Python completely and just
> embedding in some given application.

This was just a suggestion to show that it is possible to run gdb.
If the permissions are too broad for you, you can create your own include
that is more narrow and only allows what is needed by gdb.

> This could also be an issue in gdb. There should be a way to disable
> Python, or have Python automatically disabled when not available.

You can install gdb-minimal. It does not have Python-support and works
with your original "firejail --allow-debuggers --profile=firefox gdb"
command line.

Kind regards,
  Reiner

Bug#1025386: firejail: cannot use gdb with --allow-debuggers --profile=firefox

[Vincent Lefevre]

Hi Reiner,

On 2022-12-10 18:48:39 +0100, Reiner Herrmann wrote:
> Debugging tools that have dependencies (like in your example gdb -> python3)
> need to be handled additionally (either by asking gdb to not use the
> python3 extensions, or by adding parameters that whitelist it).
> 
> With the following command line I was able to get a gdb shell:
> > $ firejail --allow-debuggers --include=/etc/firejail/allow-python3.inc 
> > --profile=firefox gdb
> > [...]
> > (gdb)

However, this is not a good solution from a security point of view.
There's a difference between allowing Python completely and just
embedding in some given application.

This could also be an issue in gdb. There should be a way to disable
Python, or have Python automatically disabled when not available.

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

Bug#1022578: fail2ban: Exim beeing attacked, but fail2ban refuses to block because "Too many errors"...

[Arjan Veenstra]

I'm seeing the same issue, and on my system it consistently coincides with the 
Exim log file being rotated. This means that fail2ban will work until the end 
of the day and then needs to be restarted.

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

[Vincent Lefevre]

Control: affects -1 emacs-gtk mlterm

This also affects mlterm, when I resize the terminal.

In the upstream bug, someone says that it also affects xterm,
but I cannot reproduce the issue with xterm.

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

Bug#982815: How to deal with solved bug #982815?

[Akbarkhon Variskhanov]

On Thu, Dec 22, 2022 at 9:21 PM Roland Sommer  wrote:
>
> Dear maintainer,
>
> You've marked this bug as fixed and I don't understand how to get the
> fixed package.
>
> It's not available via stable, updates and backports repositories:
>
> root@pc14:~# apt-cache policy xfce4-taskmanager
> xfce4-taskmanager:
>   Installed: 1.4.0-1
>   Candidate: 1.4.0-1
>   Version table:
>  *** 1.4.0-1 500
> 500 http://ftp.uni-stuttgart.de/debian bullseye/main amd64
> Packages 100 /var/lib/dpkg/status
>
> Installing from testing is not an option since dependencies are not
> met:
>
> root@pc14:~# dpkg -i xfce4-taskmanager_1.5.5-1_amd64.deb
> (Reading database ... 229649 files and directories currently installed.)
> Preparing to unpack xfce4-taskmanager_1.5.5-1_amd64.deb ...
> Unpacking xfce4-taskmanager (1.5.5-1) over (1.4.0-1) ...
> dpkg: dependency problems prevent configuration of xfce4-taskmanager:
>  xfce4-taskmanager depends on libc6 (>= 2.34); however:
>   Version of libc6:amd64 on system is 2.31-13+deb11u5.
>  xfce4-taskmanager depends on libxmu6 (>= 2:1.1.3); however:
>   Version of libxmu6:amd64 on system is 2:1.1.2-2+b3.
>
> Where can I get 1.5.2-1 (or any suitable version)?
>
> TIA,
> Roland
>

Hi, Roland.

Please keep the bug number in the address list.

1.5.2-1 and later versions are available in unstable, as shown on the
version graph above.

If you don't want to install packages from unstable on your production
system, you're gonna have to wait until they migrate from unstable to
testing and then eventually to stable.

HTH,
Akbar.

Bug#1026859: mirror submission for mirror.rustytel.net

[Rusty Dekema]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.rustytel.net
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Rusty Dekema 
Country: US United States
Location: Detroit, MI, USA




Trace Url: http://mirror.rustytel.net/debian/project/trace/
Trace Url: http://mirror.rustytel.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.rustytel.net/debian/project/trace/mirror.rustytel.net

Bug#1026839: systemd: kills --user services after logging out

[Philippe Cerfon]

Hey Michael.

So that means KillUserProcesses= affects only non-service user processes?

It's a little bit hard to read that out of it's description in
logind.conf(5). Would it help it that simply says something that this
option doesn't affect --user services?

Thanks,
Philippe

Bug#1026021: pytest-forked: FTBFS with pytest 7.2

[Scott Talbert]

On Tue, 13 Dec 2022, Timo Röhling wrote:


Source: pytest-forked
Version: 1.4.0-1
Severity: serious
Tags: ftbfs patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

your package FTBFS with pytest 7.2; the test summary has been augmented
with a reason, which is not captured by test_xfail_behavior.py:


Thanks, I did notice this but I was planning to wait on a new upstream 
release which should fix this (hopefully coming soon).


Regards,
Scott

Bug#1026858: Dependency on debconf dropped prematurely

[Faidon Liambotis]

Source: cdebconf
Version: 0.265
Severity: critical

cdebconf 0.265 dropped the "debconf" dependency, that Joey Hess
"temporarily" added in 2007 with cdebconf 0.123[1]. This was added to
"avoid anyone breaking their systems by removing debconf, which
dependencies now allow".

Unfortunately, that removal was premature, and indeed, it is now
possible for someone to install cdebconf 0.265, remove debconf from
their system (which apt will happily do), and for hundreds of unrelated
random packages to break, in the same way that was reported back then
with #443627.

Example steps to reproduce:
  # on a clean chroot or container, e.g. podman run -it --rm debian:sid
  apt install -y cdebconf
  apt purge -y debconf# this was not previously possible, but now is
  # pick a random package that uses debconf, in this case tzdata
  apt purge -y tzdata # in case this was already installed
  apt install tzdata  # kaboom

I believe the reporter of #1006492 misunderstood the original change and
therefore that bug is invalid. Additionally, I believe the resolution of
#328498 to be premature, given that cdebconf is clearly not the default :)

The underlying cause is that cdebconf Provides: debconf-2.0, to indicate
that it provides the debconf 2.0 protocol, because that was its original
intention. However, it does not do so; it only did transitively, because
of the debconf dependency. Packages in the archive depend on some
variation of "debconf | debconf-2.0" expecting certain facilities
(binaries, shell libraries, etc.). However, cdebconf does NOT currently
provide any of these.

At least these differences exist:
  * cdebconf provides its binaries under /usr/lib/cdebconf, not /usr/bin
(presumably to avoid a Conflict with debconf), and thus standard
binaries that maintainer scripts (and administrators) expect, cannot
be found.
 
For example, /usr/bin/debconf-set-selections,
/usr/sbin/dpkg-preconfigure or /usr/sbin/dpkg-reconfigure.
 
  * cdebconf does not ship /usr/share/debconf/confmodule. Many
maintainer scripts expect this. tzdata, mentioned above, is one of
them.
 
  * cdebconf does not ship the Perl implementation of
Debconf::Client::ConfModule, but the debconf package does. There are
packages that expect that a "debconf-2.0" dependency will make this
available to them. For example /usr/sbin/pam-auth-update from the
libpam-runtime package uses it, but the package depends "just" on
"debconf (>= 0.5) | debconf-2.0, debconf (>= 1.5.19) | cdebconf".
 
  * Finally, cdebconf does not include a debconf-apt-progress
implementation. See #537523 for an old bug describing this, as well
as a request for the passthrough frontend.

Going forward there are a few options:
  * Revert the change and depend on debconf again. This is the safest
option, as this has been the status quo since 2007.
  
  * Remove the debconf-2.0 Provides from cdebconf. This is, arguably,
the option that would maximize correctness, given cdebconf is not
really providing the facilities expected by debconf-2.0. It's
unclear to me what this could break, though.
  
  * Longer-term... actually create feature parity between cdebconf and
debconf, potentially even switching to cdebconf by default, as Joey
originally intended. This will likely include _at least_ the
following:
- Resolving the items in #537523 (debconf-apt-progress).
- Splitting Debconf::Client::ConfModule from debconf to a
  libdebconf-client-confmodule-perl package, and either have
  cdebconf depend on it, or perform an MBF to ask downstream users
  to add this dependency explicitly. (Which of the two depends on
  whether one considers this Perl API part of the "debconf-2.0"
  protocol or not.)
- Shipping /usr/share/debconf/confmodule by cdebconf, moving
  cdebconf's binaries to /usr/bin and /usr/sbin, adding a Conflict
  again, and deprecating DEBCONF_USE_CDEBCONF.

Regards,
Faidon

1: 
https://salsa.debian.org/installer-team/cdebconf/-/commit/b4dfa070d676917f12f58cc52fe46fe2f4094fc3

Bug#1026857: Installation media not bootable for architecture ppc64el on Tyan TN71-BP012

[oliviosu_ppc64el]

Package: installation-reports

Boot method: USB
Image version: 
https://get.debian.org/images/release/current/ppc64el/iso-dvd/debian-11.6.0-ppc64el-DVD-1.iso
Date: 19 dec 2022

Machine: Tyan TN71-BP012
Processor: ppc64el (POWER8)
Memory: (irrelevant)
Partitions: (could not create)

Output of lspci -knn (or lspci -nn): (could not run)

Base System Installation Checklist:

Initial boot:   [E]
Detect network card:    [ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:    [ ]
Clock/timezone setup:   [ ]
User/password setup:    [ ]
Install tasks:  [ ]
Install boot loader:    [ ]
Overall install:    [ ]

Comments/Problems:
Installer fail to start, kernel crash.
Test on Tyan TN71-BP012 (IBM POWER8), the iso was wrote with dd to USB.
(Petitboot (dev.20150810) TN71-BP012 TCGQV04D0011)

The same kernel work on this computer via upgraded (on SSD) Debian 10 to 11.6 
(Debian 10 insallation working fine)
boot entry:
Debian GNU/Linux, with Linux 5.10.0-20-powerpc64le
working fine.

The computer have screen and keyboard.
Boot was done creating entry in petitboot with:
selecting sdb (usb device)
Kernel: /install/vmlinux
Initrd: /install/initrd.gz

Then booting it.
Ipimitool was used to record the output:


The system is going down NOW!t
Sent SIGTERM to all processes
Sent SIGKILL to all processes
[93018543727,3] OPAL: Trying a CPU re-init with flags: 0x2
[[    0.00] hash-mmu: base_shift=12: shift=12, sllp=0x, 
avpnm=0x, tlbiel=1, penc=0
[    0.00] hash-mmu: base_shift=12: shift=16, sllp=0x, 
avpnm=0x, tlbiel=1, penc=7
[    0.00] hash-mmu: base_shift=12: shift=24, sllp=0x, 
avpnm=0x, tlbiel=1, penc=56
[    0.00] hash-mmu: base_shift=16: shift=16, sllp=0x0110, 
avpnm=0x, tlbiel=1, penc=1
[    0.00] hash-mmu: base_shift=16: shift=24, sllp=0x0110, 
avpnm=0x, tlbiel=1, penc=8
[    0.00] hash-mmu: base_shift=20: shift=20, sllp=0x0130, 
avpnm=0x, tlbiel=0, penc=2
[    0.00] hash-mmu: base_shift=24: shift=24, sllp=0x0100, 
avpnm=0x0001, tlbiel=0, penc=0
[    0.00] hash-mmu: base_shift=34: shift=34, sllp=0x0120, 
avpnm=0x07ff, tlbiel=0, penc=3
[    0.00] Enabling pkeys with max key count 32
[    0.00] Page orders: linear mapping = 24, virtual = 16, io = 12, vmemmap 
= 24
[    0.00] Using 1TB segments
[    0.00] hash-mmu: Initializing hash mmu with SLB
[    0.00] Linux version 5.10.0-20-powerpc64le 
(debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU 
ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.158-2 (2022-12-13)
[    0.00] Found initrd at 0xc33b:0xc42c1452
[    0.00] OPAL: Found non-mapped LPC bus on chip 0
[    0.00] Using PowerNV machine description
[    0.00] [ cut here ]
[    0.00] opal: OPAL_CONSOLE_FLUSH missing.
[    0.00] WARNING: CPU: 56 PID: 0 at 
arch/powerpc/platforms/powernv/opal.c:528 __opal_flush_console+0x10c/0x120
[    0.00] Modules linked in:
[    0.00] CPU: 56 PID: 0 Comm: swapper Not tainted 5.10.0-20-powerpc64le 
#1 Debian 5.10.158-2
[    0.00] NIP:  c00bae9c LR: c00bae98 CTR: c01c9900
[    0.00] REGS: c15ab7f0 TRAP: 0700   Not tainted  
(5.10.0-20-powerpc64le Debian 5.10.158-2)
[    0.00] MSR:  90021033   CR: 28024442  
XER: 2000
[    0.00] CFAR: c0132540 IRQMASK: 1
[    0.00] GPR00: c00bae98 c15aba80 c15af900 
0022
[    0.00] GPR04: c0dbc002 0002 4f534e4f435f4c41 
4853554c465f454c
[    0.00] GPR08: 676e697373696d20 c15df900 0027 
90001033
[    0.00] GPR12: c01c9900 c178 c1692530 
c168ff28
[    0.00] GPR16: c1402f10   
c1537500
[    0.00] GPR20: c1692518 c16900e8 c1690518 

[    0.00] GPR24: 0001 c16900d8 c15e1fe0 

[    0.00] GPR28: 0001 c175b908  

[    0.00] NIP [c00bae9c] __opal_flush_console+0x10c/0x120
[    0.00] LR [c00bae98] __opal_flush_console+0x108/0x120
[    0.00] Call Trace:
[    0.00] [c15aba80] [c00bae98] 
__opal_flush_console+0x108/0x120 (unreliable)
[    0.00] [c15abb00] [c00bbcec] 
opal_flush_console+0x2c/0x1f0
[    0.00] [c15abb70] [c0857e20] udbg_opal_putc+0xe0/0x140
[    0.00] [c15abbc0] [c0028a88] udbg_write+0x88/0x150
[    0.00] [c15abc00] [c01c77c4] console_unlock+0x584/0x840
[    0.00] [c15abd80] [c01c7e00] 
register_console+0x200/0x3c0
[    0.00] [c15abe10] 

Bug#1020834: amgcl: FTBFS on 32-bit platforms

[Andreas Beckmann]

Followup-For: Bug #1020834
Control: retitle -1 amgcl: FTBFS on 32-bit platforms
Control: found -1 1.4.3-4

Hi,

compilation does now succeed, but thereafter it fails with a linker error:

[ 70%] Linking CXX executable mpi_complex
cd /build/amgcl-1.4.3/obj-i686-linux-gnu/examples/mpi && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/mpi_complex.dir/link.txt --verbose=1
/usr/bin/c++ -g -O2 -ffile-prefix-map=/build/amgcl-1.4.3=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -rdynamic 
CMakeFiles/mpi_complex.dir/mpi_complex.cpp.o -o mpi_complex  
-Wl,-rpath,/usr/lib/i386-l
inux-gnu/openmpi/lib -fopenmp /usr/lib/i386-linux-gnu/openmpi/lib/libmpi_cxx.so 
/usr/lib/i386-linux-gnu/openmpi/lib/libmpi.so 
/usr/lib/i386-linux-gnu/libboost_program_options.so.1.74.0 -lparmetis -lmetis 
/usr/bin/ld: CMakeFiles/mpi_complex.dir/mpi_complex.cpp.o: in function 
`amgcl::mpi::coarsening::pmis, 
int, int> 
>::aggregates(amgcl::mpi::distributed_matrix > const&, std::ve
ctor >&, std::vector >&)':
./obj-i686-linux-gnu/examples/mpi/./amgcl/mpi/coarsening/pmis.hpp:444: 
undefined reference to 
`amgcl::mpi::coarsening::pmis, 
int, int> >::undone'
collect2: error: ld returned 1 exit status

That symbol is missing for different types T in other executables, too:

amgcl::mpi::coarsening::pmis >::undone


Andreas

Bug#1026856: cura-engine: FTBFS: 14 tests segfault

[Andreas Beckmann]

Source: cura-engine
Version: 1:5.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

cura-engine/experimental recently started to FTBFS:

46% tests passed, 14 tests failed out of 26

Total Test time (real) =   2.57 sec

The following tests FAILED:
  3 - ExtruderPlanTest (SEGFAULT)
  4 - GCodeExportTest (SEGFAULT)
  5 - InfillTest (SEGFAULT)
  6 - LayerPlanTest (SEGFAULT)
  7 - PathOrderOptimizerTest (SEGFAULT)
  8 - PathOrderMonotonicTest (SEGFAULT)
  9 - TimeEstimateCalculatorTest (SEGFAULT)
 10 - WallsComputationTest (SEGFAULT)
 11 - ArcusCommunicationTest (SEGFAULT)
 12 - ArcusCommunicationPrivateTest (SEGFAULT)
 13 - SlicePhaseTest (SEGFAULT)
 14 - SettingsTest (SEGFAULT)
 22 - PolygonTest (SEGFAULT)
 23 - PolygonUtilsTest (SEGFAULT)
Errors while running CTest

A previous amd64 rebuild on Oct 17 was still successful.


Andreas


cura-engine_1:5.0.0-1.log.gz
Description: application/gzip

Bug#1022573: transition: procps

[陳昌倬]

On Wed, Dec 21, 2022 at 07:54:17PM +0100, Paul Gevers wrote:
> ChangZhuo, src:lxqt-session is in the same boat, but already changed it's
> Build-Dependency in experimental. An upload to unstable would be
> appreciated.

Uploaded to unstable


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#1026855: libgoogle-auto-service-java: ships /usr/share/maven-repo/build-only/build-only/NO_VERSION/build-only-NO_VERSION.pom

[Andreas Beckmann]

Package: libgoogle-auto-service-java
Version: 1.0~rc7-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

libgoogle-auto-service-java ships two dubious files that should probably
not be in the package at all:

  
/usr/share/maven-repo/build-only/build-only/NO_VERSION/build-only-NO_VERSION.pom
  /usr/share/maven-repo/build-only/build-only/debian/build-only-debian.pom

This now started to cause a file conflict with another package doing
the same mistake.

No other package in the archive ships anything "useful" in
/usr/share/maven-repo/build-only/


cheers,

Andreas

Bug#1026854: libgoogle-auto-common-java: ships /usr/share/maven-repo/build-only/build-only/NO_VERSION/build-only-NO_VERSION.pom

[Andreas Beckmann]

Package: libgoogle-auto-common-java
Version: 1.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

libgoogle-auto-common-java ships two dubious files that should probably
not be in the package at all:

  
/usr/share/maven-repo/build-only/build-only/NO_VERSION/build-only-NO_VERSION.pom
  /usr/share/maven-repo/build-only/build-only/debian/build-only-debian.pom

This now started to cause a file conflict with another package doing
the same mistake.

No other package in the archive ships anything "useful" in
/usr/share/maven-repo/build-only/


cheers,

Andreas

Bug#1026853: rust-svgdom: (build-)depends on old version of rust-roxmltree

[Peter Green]

Package: rust-svgdom
Version: 0.18.0-2
Severity: serious

svgdom depends on version 0.7 of the roxmltree crate. Debian sid now has version
0.16.

I tried bumping the dependency but it fails to build with the following errors.



error[E0599]: no method named `write_buf` found for struct `Document` in the current scope   
  --> benches/parser.rs:45:21
   |
45 | doc.write_buf( ouput_data); 
   | ^ method not found in `Document`
...

52 | do_write!(write_small, "benches/small.svg");
   | --- in this macro invocation
   |
   = note: this error originates in the macro `do_write` (in Nightly builds, 
run with -Z macro-backtrace for more info)

error[E0599]: no method named `write_buf` found for struct `Document` in the 
current scope
  --> benches/parser.rs:45:21
   |
45 | doc.write_buf( ouput_data);
   | ^ method not found in `Document`
...
53 | do_write!(write_medium, "benches/medium.svg");
   | - in this macro invocation
   |
   = note: this error originates in the macro `do_write` (in Nightly builds, 
run with -Z macro-backtrace for more info)

error[E0599]: no method named `write_buf` found for struct `Document` in the 
current scope
  --> benches/parser.rs:45:21
   |
45 | doc.write_buf( ouput_data);
   | ^ method not found in `Document`
...
54 | do_write!(write_large, "benches/large.svg");
   | --- in this macro invocation
   |
   = note: this error originates in the macro `do_write` (in Nightly builds, 
run with -Z macro-backtrace for more info)

Bug#923023: original-awk FTCBFS: builds for the wrong architecture

[Santiago Vila]

El 22/12/22 a las 9:20, Helmut Grohne escribió:

I don't think having me test your branches is an efficient process. Can
I propose the following alternatives?

  * If you are using sbuild, add --host=somearch.
  * If you are using pbuilder, add --host-arch somearch.
  * If you are using salsa, enable salsa-ci and check the cross build.
  * If you use none of the above, upload and check
https://crossqa.debian.net/src/original-awk.
  * If you feel that all of this is too much work, close my FTCBFS bug
with a note "upstream build system significantly changed, patch no
longer applicable". I'll send a new patch eventually.


Ok, seems fair to me.

I tried sbuild --host=i386 and sbuild took care of everything, and
this time lintian did not complain about weird ELF binary.

I did not really know it was so easy to check. Now I do :-)

Thanks a lot.

Bug#1026823: RFS: zvbi/0.2.39-1 -- Vertical Blanking Interval (VBI) utilities

[Adam Borowski]

On Wed, Dec 21, 2022 at 07:04:11PM +0200, Ileana Dumitrescu wrote:
>  zvbi (0.2.39-1) unstable; urgency=medium
>  .
>* New upstream release.
>* debian/rules: Remove NOCONFIGURE=1.

✓

> I am also hoping to work with a mentors team member to help secure a key
> endorsement for my DM application. Please let me know what I can do!

The old way involves meeting in person, briefly waving a government-looking
id in the face of someone who has no ability to verify the id's authenticity
in any way -- and, as we joke, an id is valid if the photo doesn't look like
you as that's how real ids look (only a forger would be a try-hard enough to
get a photo that actually resembles you!).  And it's trivial to get fakes
that are good enough to fool professionals anyway.

The new way is to have a quick video chat (in order to ascertain you didn't
hire a random drunkie), and wave aforemented government-looking id.

In either case, you can use any DD, me included.
 * for a physical meeting, you're probably far from Gdańsk, Poland
 * but you likely have a camera-equipped device

Thus: if you're not afraid of the trauma of seeing my face, I'm a valid
endorser.  Or you can ask anyone else...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1026358: RFS: streamlink/5.1.2-1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Hi,

On 22/12/2022 16:30, Adam Borowski wrote:

On Mon, Dec 19, 2022 at 01:19:03AM +0100, Alexis Murzeau wrote:

streamlink (5.1.2-1) unstable; urgency=medium

* New upstream version 5.1.2
* d/README.source: update instructions
* d/streamlink.{install,manpages}: update completion scripts location

   -- Alexis Murzeau   Mon, 19 Dec 2022 00:25:14 +0100


Hi,
this upload uses an old version of debian/changelog for 5.1.1-1:

  streamlink (5.1.1-1) unstable; urgency=medium
  
* New upstream version 5.1.1

-  * Control: add build-dep on python3-certifi.
  
- -- Alexis Murzeau   Tue, 29 Nov 2022 08:51:03 +

+ -- Alexis Murzeau   Mon, 28 Nov 2022 21:49:55 +0100

Please update that to be same as in the archive.


Meow!


Thanks, I forgot to do that.

I've updated it, and also made additional small changes to the changelog
to close a bug that is fixed with this version and a
standards-version update.

I've uploaded the update to mentors, here is the new changelog:

https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_5.1.2-1.dsc

streamlink (5.1.2-1) unstable; urgency=medium

  * New upstream version 5.1.2
  * d/README.source: update packaging instructions
  * d/streamlink.{install,manpages}: update completion scripts location
(Closes: #1026714)
  * Bump Standards-Version to 4.6.2 (no changes)

 -- Alexis Murzeau   Thu, 22 Dec 2022 15:35:53 +0100

streamlink (5.1.1-1) unstable; urgency=medium

  * New upstream version 5.1.1
  * Control: add build-dep on python3-certifi.

 -- Alexis Murzeau   Tue, 29 Nov 2022 08:51:03 +


--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026852: ITP: rust-cargo-debstatus -- cargo-tree for debian packaging

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-rust-maintain...@alioth-lists.debian.net, matthias.geiger1...@tutanota.de

* Package name: rust-cargo-debstatus
  Version : 0.4.0
  Upstream Contact: kpcyrd 
* URL : https://github.com/kpcyrd/cargo-debstatus
* License : GPL-3
  Programming Lang: Rust
  Description : cargo-tree for debian packaging

This program shows the colored output of missing crates in a tree for a rust 
program if invoked.
As of now one crate is still missing for it. It's only missing dependency is in 
NEW. Blair Noctis and myself are working on it.
It is especially useful to get an overview for reverse dependencies in bigger 
rust projects. It will be maintained with the debian-rust team.

Thanks,

Matthias Geiger  

Bug#1026846: login: PATH set to ENV_SUPATH when logging in as a regular user

[Andrea Pappacoda]

Package: login
Version: 1:4.13+dfsg1-1
Followup-For: Bug #1026846

It seems that being part of the `sudo` group isn't causing the issue. I've
created a temporary user, logged into my DE with it and observed that PATH was
set to the expected value.

One interesting thing I've noticed is that if I log into my computer with a
text-only session (on e.g. tty3), PATH is set to the correct value.

As this seems now relevant, I'm running the latest version of GNOME available
in Testing; it's a fairly minimal install. gnome-core is not installed, but
I've manually installed pretty much everything apart from the software store
and a couple of things I do not need; here's what's not present:

$ apt depends gnome-core | grep Depends | tr ' ' '\n' | grep '[[:alpha:]]'
| grep -vE '\)|:' | tr ',' ' ' | xargs apt -qq list | grep -v installed | cut
-d / -f 1 | tr '\n' ' '
at-spi2-core baobab evolution-data-server gnome-bluetooth-sendto gnome-
console gnome-contacts gnome-font-viewer gnome-logs gnome-shell-extensions
gnome-software gnome-sushi gnome-system-monitor gnome-terminal gnome-themes-
extra gnome-user-docs gnome-user-share gstreamer1.0-packagekit libatk-adaptor
nautilus totem tracker yelp


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 login depends on:
ii  libaudit1   1:3.0.7-1.1+b2
ii  libc6   2.36-6
ii  libcrypt1   1:4.4.33-1
ii  libpam-modules  1.5.2-5
ii  libpam-runtime  1.5.2-5
ii  libpam0g1.5.2-5

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1026851: /usr/libexec/bluetooth/bluetoothd: a2dp-sink profile connect failed for 50:19:A2:13:02:AD: Protocol not available

[Tobias Koeck]

Package: bluez
Version: 5.55-3.1
Severity: normal
File: /usr/libexec/bluetooth/bluetoothd

Dear Maintainer,

I wanted to connect the MPow Flame and in the /var/log/syslog the
following messages is available.

bluetoothd[836]: src/service.c:btd_service_connect() a2dp-sink profile connect 
failed for 50:19:A2:13:02:AD: Protocol not available

It doesn't connect.

Greetings
Tobias

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

Kernel: Linux 6.1.0-0-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bluez depends on:
ii  dbus 1.12.24-0+deb11u1
ii  init-system-helpers  1.64~bpo11+1
ii  kmod 28-1
ii  libasound2   1.2.4-1.1
ii  libc62.34-4
ii  libdbus-1-3  1.12.24-0+deb11u1
ii  libdw1   0.187-1~bpo11+1
ii  libglib2.0-0 2.72.3-1+b1
ii  libreadline8 8.1-1
ii  libudev1 251.3-1~bpo11+1
ii  lsb-base 11.1.0
ii  udev 251.3-1~bpo11+1

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  14.2-2

-- no debconf information

Bug#1026358: RFS: streamlink/5.1.2-1 -- CLI for extracting video streams from various websites to a video player

[Adam Borowski]

On Mon, Dec 19, 2022 at 01:19:03AM +0100, Alexis Murzeau wrote:
> streamlink (5.1.2-1) unstable; urgency=medium
> 
>* New upstream version 5.1.2
>* d/README.source: update instructions
>* d/streamlink.{install,manpages}: update completion scripts location
> 
>   -- Alexis Murzeau   Mon, 19 Dec 2022 00:25:14 +0100

Hi,
this upload uses an old version of debian/changelog for 5.1.1-1:

 streamlink (5.1.1-1) unstable; urgency=medium
 
   * New upstream version 5.1.1
-  * Control: add build-dep on python3-certifi.
 
- -- Alexis Murzeau   Tue, 29 Nov 2022 08:51:03 +
+ -- Alexis Murzeau   Mon, 28 Nov 2022 21:49:55 +0100

Please update that to be same as in the archive.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢠⠒⠀⣿⡁ productivity.  You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so.  I recommend Skepticism
⠈⠳⣄ (funeral doom metal).

Bug#1026666: Please make liblog4j2-java depend on junit5

[tony mancill]

Hi Pierre,

On Thu, Dec 22, 2022 at 07:31:30AM +0100, Pierre Gruet wrote:
> Hi tony,
> 
> Le 21/12/2022 à 22:58, tony mancill a écrit :
> > On Tue, Dec 20, 2022 at 11:45:54PM +0100, Pierre Gruet wrote:
> > > Control: retitle -1 Please make liblog4j2-java depend on junit5
> > > 
> > > Hello,
> > > 
> > > In version 2.19.0-1 of liblog4j2-java, the file
> > >   
> > > /usr/share/maven-repo/org/apache/logging/log4j/log4j/debian/log4j-debian.pom
> > > declares the junit-bom artifact as a dependency. It is shipped in junit5.
> > > 
> > > If this dependency is not added, reverse dependencies of liglog4j2-java 
> > > fail
> > > to build (see logs above) as the junit-bom artifact is not found.
> > 
> > Hi Pierre,
> > 
> > I'm wondering if it wouldn't better to remove junit-bom from log4j pom.
> > I don't believe we actually need junit5 at runtime for log4j2, so
> > packages depending on liblog4j2-java should not have to install junit5.
> > 
> > Any concerns with taking that approach and addressing the bug by
> > adjusting the pom shipped with liblog4j2-java?
> 
> Thanks for having a look; I haven't looked further but I also fail to
> imagine why junit5 would be needed, so I agree with the proposed fix!

I am spot-checking a few of the reverse dependencies now and will upload
today.  Thank you for identifying the root cause for this set of build
failures.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1019380: UDD: import ports.d.o data to ports tables instead of derivatives tables

[Lucas Nussbaum]

On 08/09/22 at 16:23 +0800, Paul Wise wrote:
> Package: qa.debian.org
> Severity: wishlist
> User: qa.debian@packages.debian.org
> Usertags: udd
> X-Debbugs-CC: John Paul Adrian Glaubitz , Aurelien Jarno 
> 
> 
> Currently the unofficial Debian ports archive is imported in UDD tables
> named 'derivatives', but these days it is more of a Debian subproject.
> 
> The 'derivatives' table also receives (or did in the past) data from
> aptosid and skolelinux, which are/were both derivatives of Debian.
> 
> Therefore, I would like ports data to be imported into 'ports' tables
> instead and make the new ports table available to the UDD madison cgi
> and then add the ports UDD madison cgi to the default rmadison URL map.
> 
> https://qa.debian.org/cgi-bin/madison.cgi?table=derivatives

Hi,

That sounds OK in principle. However,

1/ looking into it, I noticed that the source for packages in unreleased
is not shipped. Is that expected?

2/ Would you be OK with a set of tables named unofficial_sources,
unofficial_packages, etc? Then I would re-use the same set of tables to
import janitor's fresh-releases and fresh-snapshots suite.

Lucas

Bug#1026849: ax25-apps: ax25mond(8) manual page contains wrong name

[Nate Bargmann]

Package: ax25-apps
Version: 0.0.8-rc5+git20190411+0ff1383-4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

In reading up on the various capabilities of the AX.25 stack, I read the
manual page for ax25mond(8) and saw that in the NAME and SYNOPSIS
sections the name 'axcall' appears instead of the expected 'ax25mond'.

Through the https://manpages.debian.org/ Web interface I have confirmed
this bug exists in both Testing and Unstable as well as Stable which is
where I first noticed it.

I compiled the upstream Git repository checkout and the resulting name
is correct as built by upstream.

I checked the other manual pages of the ax25-apps package and those
names appear to be correct.

- - Nate


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

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

Versions of packages ax25-apps depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libax250.0.12-rc5+git20190411+b17ff36-3
ii  libc6  2.31-13+deb11u5
ii  libncursesw6   6.2+20201114-2
ii  libtinfo6  6.2+20201114-2

ax25-apps recommends no packages.

Versions of packages ax25-apps suggests:
ii  ax25-tools  0.0.10-rc5+git20190411+3595f87-5

- -- debconf information:
  ax25-apps/suid_listen: false

-BEGIN PGP SIGNATURE-

iGsEARECACsWIQSC1k9rDmfNQfaJu6b7LFEw1VqIGQUCY6Rklg0cbjBuYkBuMG5i
LnVzAAoJEPssUTDVWogZrkQAniLyOKwf+Lis4CJmu7KFRPzbKbO+AJ9DtvVnQif8
2e+clyngnZK0Yw0sLQ==
=g5CP
-END PGP SIGNATURE-

Bug#1026848: apt-cacher-ng: Two fixes for erroneous tagging

[Antonio Russo]

Package: apt-cacher-ng
X-Debbugs-Cc: aeru...@aerusso.net
Severity: important
Tags: patch upstream

Dear maintainer,

In bug 1026395, I identified behavior where apt-cacher-ng was tagging many
valid, referenced files for deletion.  One cause is mentioned there.  However,
I failed to notice another source of erroneous tagging: SHA256 sums in
the Packages/Sources/etc. files are not being detected.

For examples, debrep/dists/bullseye-backports/main/binary-amd64/Packages, 
contains "^SHA256: " lines that are not being used.

The first of the two patches fixes that behavior for Packages.

During this process, a third source showed up: the lists of files in Sources
was getting clobbered because of the behavior of 
cacheman.cc:ParseGenericRfc822File
("we don't merge").

The second patch implements streaming handling of Sources a la Packages.  That
patch parses possibly untrusted data, so please give it a close read (also I
haven't done a lot of C++ coding recently, so I apologize in advance).

I'm tagging this important because most files for bookworm (and later) will
be automatically purged after a few days, since they are found to never be
referenced.  This has significant impact on many use cases for this package.

Best,
Antonio Russodiff --git a/src/cacheman.cc b/src/cacheman.cc
index 43d8f12..940be40 100644
--- a/src/cacheman.cc
+++ b/src/cacheman.cc
@@ -1700,7 +1700,7 @@ bool cacheman::ParseAndProcessMetaFile(std::functioncommit 5d03dc3da84531a3902536b2e9fed01d5eb54e23
Author: Antonio Russo 
Date:   Thu Dec 22 04:41:14 2022 -0700

Streaming support for Sources

Signed-off-by: Antonio Russo 

diff --git a/src/cacheman.cc b/src/cacheman.cc
index 940be40..52f3a38 100644
--- a/src/cacheman.cc
+++ b/src/cacheman.cc
@@ -1695,6 +1695,7 @@ bool cacheman::ParseAndProcessMetaFile(std::function=STEP) SendChunk("\n");});
+	CSTYPES current_cstype = CSTYPES::CSTYPE_INVALID;
 
 	switch(idxType)
 	{
@@ -1911,8 +1912,55 @@ bool cacheman::ParseAndProcessMetaFile(std::function.");
+
+			if (sLine.empty())
+			{
+current_cstype = CSTYPES::CSTYPE_INVALID;
+continue;
+			}
+
+			if (isspace((unsigned) (sLine[0])))
+			{
+if(current_cstype == CSTYPES::CSTYPE_INVALID)
+	continue;
+
+trimBoth(sLine);
+info.fpr.csType = current_cstype;
+if(ParseDebianIndexLine(info, sLine)) {
+	info.sDirectory=sPkgBaseDir;
+	ret(info);
+}
+info.SetInvalid();
+continue;
+			}
+
+			current_cstype = CSTYPES::CSTYPE_INVALID;
+
+			if (ParseKeyValLine(sLine, key, val))
+			{
+if(key==sSrcMD5)
+	current_cstype = CSTYPE_MD5;
+else if(key==sSrcSHA256)
+	current_cstype = CSTYPE_SHA256;
+else
+	continue;
+			}
+		}
+		break;
 	case EIDX_TRANSIDX:
 		return ParseDebianRfc822Index(reader, ret, sBaseDir, sPkgBaseDir,
 EIDX_TRANSIDX, CSTYPES::CSTYPE_SHA1, "SHA1", byHashMode);

Bug#1024811: Re: Bug#1024811: linux: /proc/[pid]/stat unparsable

[Donald Buczek]

On 12/22/22 1:53 AM, Thorsten Glaser wrote:
> On Sat, 26 Nov 2022, Alexey Dobriyan wrote:
> 
>> /proc never escaped "comm" field of /proc/*/stat.
> 
> Yes, that’s precisely the bug.
> 
>> To parse /proc/*/stat reliably, search for '(' from the beginning, then
>> for ')' backwards. Everything in between parenthesis is "comm".
> 
> That’s not guaranteed to stay reliable: fields can be, and have
> been in the past, added, and new %s fields will break this. Do
> not rely on it either.
> 
>> Everything else are numbers separated by spaces.
> 
> Currently, yes.
> 
> But the field is *clearly* documented as intended to be
> parsable by scanf(3), which splits on white space. So the
> Linux kernel MUST encode embedded whitespace so the
> documented(!) access method works.

No, Escaping would break existing programs which parse the line by searching 
for the ')' from the right. The format, surly, is ugly, but that is how it is.

If some documentation suggests, that you can just parse it with scanf, the 
documentation should be corrected/improved instead.

Are you referring to proc(5) "The fields, in order, with their proper scanf(3) 
format specifiers, are listed below" [1] or something else?

The referenced manual page is wrong in regard to the length, too. There is no 
16 character limit to the field, because it can contain a workqueue task name, 
too:

buczek@theinternet:/tmp$ cat /proc/27190/stat
27190 (kworker/11:2-mm_percpu_wq) I 2 0 0 0 -1 69238880 0 0 0 0 0 170 0 0 
20 0 1 0 109348986 0 0 18446744073709551615 0 0 0 0 0 0 0 2147483647 0 0 0 0 17 
11 0 0 0 0 0 0 0 0 0 0 0 0 0

The current limit seems to be 64 characters [2] when escaping is off, as it is 
the case with /proc/pid/stat. But generally the length of the field and thereby 
of the whole line seems to be rather undefined. So to parse that, you either 
either need to do some try-and-restart-with-a-bigger-buffer dance or use a 
buffer size of which you just hope that it will be big enough for the forseable 
time. 

In fact, if you start escaping now you might also break programs which rely on 
the current 64 character limit.

Best

  Donald

[1]: https://man7.org/linux/man-pages/man5/proc.5.html
[2]: https://elixir.bootlin.com/linux/latest/source/fs/proc/array.c#L99

> 
> bye,
> //mirabilos
> 


-- 
Donald Buczek
buc...@molgen.mpg.de
Tel: +49 30 8413 1433

Bug#1026847: zabbix: CVE-2022-46768 CVE-2022-43515

[Moritz Mühlenhoff]

Source: zabbix
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerabilities were published for zabbix.

CVE-2022-46768[0]:
| Arbitrary file read vulnerability exists in Zabbix Web Service Report
| Generation, which listens on the port 10053. The service does not have
| proper validation for URL parameters before reading the files.

https://support.zabbix.com/browse/ZBX-22087

CVE-2022-43515[1]:
| Zabbix Frontend provides a feature that allows admins to maintain the
| installation and ensure that only certain IP addresses can access it.
| In this way, any user will not be able to access the Zabbix Frontend
| while it is being maintained and possible sensitive data will be
| prevented from being disclosed. An attacker can bypass this protection
| and access the instance using IP address not listed in the defined
| range.

https://support.zabbix.com/browse/ZBX-22050

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-46768
https://www.cve.org/CVERecord?id=CVE-2022-46768
[1] https://security-tracker.debian.org/tracker/CVE-2022-43515
https://www.cve.org/CVERecord?id=CVE-2022-43515

Please adjust the affected versions in the BTS as needed.

Bug#1026846: login: PATH set to ENV_SUPATH when logging in as a regular user

[Andrea Pappacoda]

Package: login
Version: 1:4.13+dfsg1-1
Severity: normal

Hi, after noticing that /usr/bin/games was not in my PATH, I tried to figure
out why. My PATH is currently set to
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, which is the same
exact value found in /etc/login.defs under the variable ENV_SUPATH, which
should be the default PATH for superusers.

This issue isn't present when logging in as a different user which isn't part
of the sudo group.

List of my groups:

tachi : tachi cdrom floppy sudo audio dip video plugdev users kvm netdev
bluetooth sbuild scanner lpadmin

List of the other user's groups:

lorenzo : lorenzo lp cdrom audio video plugdev users netdev scanner

What could be the cause of this issue?

Thanks!


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 login depends on:
ii  libaudit1   1:3.0.7-1.1+b2
ii  libc6   2.36-6
ii  libcrypt1   1:4.4.33-1
ii  libpam-modules  1.5.2-5
ii  libpam-runtime  1.5.2-5
ii  libpam0g1.5.2-5

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1017518: new upstream (8.3)

[Marco d'Itri]

On Dec 13, David Lamparter  wrote:

> In a way, yes;  we had made an agreement with Ondřej Surý but that seems
> to have broken down.  I'm happy to work on Debian packaging for FRR, but
> I can't upload myself due to not being a DM/DD, and the brain cost of
> socially interacting with someone else to pipe things through is too
> high for me to take.  (Sadly due to my personality traits, even just
> handling mails is immensely expensive for me...)
> 
> Do you have any suggestions on a way forward?
Let's try this way: push your best attempt at a new package to your 
repository and I will review it and try to upload it.
I will avoid further communications unless strictly needed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#923023: original-awk FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Hi Santiago,

On Thu, Dec 22, 2022 at 12:10:57AM +0100, Santiago Vila wrote:
> The upstream makefile now has a CC and a HOSTCC for cross-builds.
> So I guess now we just need to pass CC as CC and CC_FOR_BUILD as HOSTCC.

Thank you for caring about cross builds.

> Can you try this and tell me if it works?
> 
> git clone g...@salsa.debian.org:sanvila/original-awk.git

I don't think having me test your branches is an efficient process. Can
I propose the following alternatives?

 * If you are using sbuild, add --host=somearch.
 * If you are using pbuilder, add --host-arch somearch.
 * If you are using salsa, enable salsa-ci and check the cross build.
 * If you use none of the above, upload and check
   https://crossqa.debian.net/src/original-awk.
 * If you feel that all of this is too much work, close my FTCBFS bug
   with a note "upstream build system significantly changed, patch no
   longer applicable". I'll send a new patch eventually.

This applies to all kinds of FTCBFS bugs filed by me.

Helmut

Bug#1000615: fsverity-utils FTCBFS: rebuilds with the build architecture compiler during make install

[Luca Boccassi]

On Thu, 25 Nov 2021 22:31:41 +0100 Helmut Grohne 
wrote:
> Source: fsverity-utils
> Version: 1.4-1~exp1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> fsverity-utils fails to cross build from source, because make install
> detects a changed compiler and proceeds to rebuild it using the build
> architecture compiler. Exporting the host architecture CC for all
> targets fixes this. Please consider applying the attached patch.
> 
> Helmut

Romain,

I'll NMU a fix for this and the new upstream version in the next week
or so, unless you have time to do it beforehand.

-- 
Kind regards,
Luca Boccassi


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

Bug#1026845: bullseye-pu: package systemd/247.3-7+deb11u2

[Luca Boccassi]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org

Dear release team,

We'd like to upload several bug fixes, including security fixes, for
systemd to bullseye.
The fixes come from the upstream stable branches which are covered by
CI and confirmed by reporters.

Please find the debdiff attached.

Kind regards,
Luca Boccassi


pu.debdiff
Description: Binary data

Bug#1026095: ITP: ruby-mdl -- A gem that offers a syntax check for markdown files

[Jakub Wilk]

* Norwid Behrnd , 2022-12-22 11:58:
You are right that there should be only one ticket, and that the one 
filed later (1026114) is the one to retain.  Thus, my upload by 
yesterday refers to ticket 1026144 only.


Because I started this ticket no longer valid, of course I equally 
should close it


Beware that #1026095 and #1026114 and  are currently merged, so if you 
close one, the other one will be closed too. If you want to close 
#1026095 only, you need to unmerge them first.


But it's less work to keep the bugs merged and not close anything for 
now. :)



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


I'd recommend merging #989710, instead of closing it, too. That way the 
submitter, and perhaps other people who subscribed to the old bug, will 
be notified only when the package reaches Debian.


--
Jakub Wilk

Bug#1026231: debian-policy: document droppage of support for legacy locales

[Simon McVittie]

On Wed, 21 Dec 2022 at 18:15:11 +0100, Adam Borowski wrote:
> On Mon, Dec 19, 2022 at 07:08:09PM +, Simon McVittie wrote:
> > On Fri, 16 Dec 2022 at 19:21:37 +0100, Adam Borowski wrote:
> > > * The execution environment (usually init system or a container) must
> > >   default to UTF-8 encoding unless explicitly configured otherwise.
> > 
> > Is this already true? This seems like the sort of thing which should be
> > fixed in at least the major init systems and container managers before it
> > goes into Policy, in the interests of not making those init systems and
> > container managers retroactively buggy.
> 
> I'm less knowledgeable about containers, but they appear to work.  It might
> be due to copying variables from the host or having template defaults...

There are three major categories of container that I'm aware of:

1. Full-system containers like lxc/lxd run a complete init system like
   systemd or sysv-rc for the container (they aim to behave like a
   lighter-weight alternative to VMs), so their init system would be
   responsible for making this work. This seems non-problematic for your
   proposed requirement: if an init system does the right thing on bare
   metal or in a VM, it will also do the right thing in lxc containers.

2. Per-service containers like the upstream-recommended use of Docker either
   have no init system at all, or a minimal reaper process like tini
   (they aim to behave like a heavier-weight alternative to chroots).
   chroot managers that have subsequently gained namespace functionality,
   like some uses of pbuilder and schroot, also work like this.
   I think these are the category that is most likely to have trouble
   complying with the requirement you propose, because the container manager
   is intentionally "hands-off" (mechanism more than policy), while the
   processes run inside the container are not under Debian's control (they
   are chosen by whoever wrote the Dockerfile or equivalent, and might come
   from either Debian or another distribution).

3. Per-app containers like Flatpak and Snap are not intended to emulate a
   whole system, so they are expected to inherit locale settings from the
   host system like a non-sandboxed app would. They shouldn't be a problem
   here, as long as your proposed requirement is worded in such a way that
   it is valid for these container managers to rely on the host system
   locale being correct (in other words, if someone using the legacy en_GB
   locale reports a bug "flatpak: does not set a UTF-8 locale", I should be
   able to close it with "This is not flatpak's job, set your host system
   locale to en_GB.UTF-8 instead").

podman and systemd-nspawn can be used as either the first category
(like lxc) or the second (like Docker), depending how they were invoked.

> Anyway, my aim is more to tell packages that they are allowed to misbehave
> when the settings are missing than to hunt misuse scenarios.  But, if such
> a scenario is found, with the current Policy there is no recourse, while
> if this rule is added it would be a bug.

Not every bug necessarily needs to be a Policy violation.

> I just tested Windows 11 notepad.exe: it defaults to UTF-8, and when
> saving it allows "ANSI" "UTF-16 LE" "UTF-16 BE" "UTF-8" (default) and
> "UTF-8 with BOM".

Yes, that's the sort of UX that I think needs to be allowed. I would
personally not expose that choice in the UI of an intentionally simple
text editor like Notepad or gnome-text-editor, but I would expect similar
behaviour in an editor with more elaborate programmer-oriented features,
like vim, emacs, gnome-builder or kate.

If iconv(1) or a similar program has an option for "UTF-8 with BOM" then
that also needs to not be accidentally declared to be a Policy violation.

smcv

Bug#989710: RFP: markdownlint -- A tool to check markdown files and flag style issues.

[Norwid Behrnd]

@Jerome Charaoui I would like to let you know about ticket 1026114 with an ITP.
Based on the current version 0.12.0 of markdownlint, the work advanced to the
stage requesting a sponsorship.

Regards,
-- 
  Norwid Behrnd

Bug#1026844: scm: fix ftbfs on riscv64, mips64el, s390x

[Bo YU]

Source: scm
Version: 5f3-2
Severity: important
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,


The package has ftbfs issue on mips64el, s390x and riscv64 due to:
```
#define SHORT_INT
in scmfig.h and recompile scm
make[3]: *** [Makefile:553: checklit] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:354: scmlit] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:32: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:19: binary-arch] Error 2
```

The full build log is here:
https://buildd.debian.org/status/fetch.php?pkg=scm=mips64el=5f3-2=1671594837=0

https://buildd.debian.org/status/fetch.php?pkg=scm=s390x=5f3-2=1671590229=0

https://buildd.debian.org/status/fetch.php?pkg=scm=riscv64=5f3-2=1671546696=0

The pacth is trying to fix these issues and I have tested it. Please let
me know if there is any issue. Thanks.

BR,
Bo


-- 
Regards,
--
  Bo YU

diff -Nru scm-5f3/debian/changelog scm-5f3/debian/changelog
--- scm-5f3/debian/changelog2021-12-03 00:31:25.0 +0800
+++ scm-5f3/debian/changelog2022-12-22 18:37:03.0 +0800
@@ -1,3 +1,10 @@
+scm (5f3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add supoort for riscv64, mips64el, s390x. (Closes: #-1, #387087)
+
+ -- Bo YU   Thu, 22 Dec 2022 18:37:03 +0800
+
 scm (5f3-1) unstable; urgency=medium
 
   * Update debian/watch uscan support file
diff -Nru scm-5f3/debian/patches/series scm-5f3/debian/patches/series
--- scm-5f3/debian/patches/series   2021-12-02 05:23:26.0 +0800
+++ scm-5f3/debian/patches/series   2022-12-22 18:07:35.0 +0800
@@ -5,3 +5,4 @@
 add-missing-edit-line-feature.patch
 fix-argument-imm-being-ignored-in-m_letstar1.patch
 fix-readline-related-bug.patch
+support-rv64-mips64el-s390x.patch
diff -Nru scm-5f3/debian/patches/support-rv64-mips64el-s390x.patch 
scm-5f3/debian/patches/support-rv64-mips64el-s390x.patch
--- scm-5f3/debian/patches/support-rv64-mips64el-s390x.patch1970-01-01 
07:30:00.0 +0730
+++ scm-5f3/debian/patches/support-rv64-mips64el-s390x.patch2022-12-22 
18:11:36.0 +0800
@@ -0,0 +1,21 @@
+--- a/scmfig.h
 b/scmfig.h
+@@ -272,6 +272,18 @@
+ # define SHORT_INT
+ # define CDR_DOUBLES
+ #endif
++#ifdef __mips__ && _MIPSEL && _MIPS_SIM==_ABI64
++# define SHORT_INT
++# define CDR_DOUBLES
++#endif
++#ifdef __riscv && __riscv_xlen==64
++# define SHORT_INT
++# define CDR_DOUBLES
++#endif
++#ifdef __s390x__
++# define SHORT_INT
++# define CDR_DOUBLES
++#endif
+ #ifdef MSDOS  /* Microsoft C 5.10 and 6.00A */
+ # ifndef GO32
+ #  define SHORT_INT


signature.asc
Description: PGP signature

Bug#1012844: fixed in wpa 2:2.10-10

[Vincent Lefevre]

On 2022-12-21 09:24:08 +, Debian Bug Tracking System wrote:
> Changes:
>  wpa (2:2.10-10) unstable; urgency=medium
>  .
>* Configure wpa_supplicant.service to create control sockets owned by 
> group netdev
>  (Closes: #1012844)

Thanks. I confirm that this fixes the problem (I've tested both
wpa_cli and wpa_gui).

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

Bug#1026839: systemd: kills --user services after logging out

[Michael Biebl]

Am 22.12.22 um 03:17 schrieb Philippe Cerfon:


Any idea why this doesn't work as expected (by me)?


If you want your user services to persist after logging out, you need to 
enable lingering.


Michael


OpenPGP_signature
Description: OpenPGP digital signature