date:20231120

On 2023-11-20 22:53:06 +0100, Preuße, Hilmar wrote:
> Currently I'm now able to reproduce the issue, I guess b/c we're in winter
> time. I guess I have to break the time on my test box...

No need to break the time. Try with "TZ=Australia/Canberra", which
currently has summer time.

zira:~> export TZ=Australia/Canberra
zira:~> date && xelatex test.tex && pdfinfo test.pdf | grep Date:
Tue Nov 21 11:10:08 AEDT 2023
[...]
CreationDate:Tue Nov 21 10:10:08 2023 AEDT

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

Bug#1056321: elogind conflicts with same version libelogind0

2023-11-20 Thread Thorsten Glaser

On Mon, 20 Nov 2023, Mark Hindley wrote:

>Neither, it reflects that fact that elogind in Debian is now patched to use
>libsystemd0 compatible cgroups. libelogind0 is no longer used and will be
>removed by apt, libsystemd0 will be installed instead.

>HTH. Closing.

Did you forget to not build the libelogind0 binary package any more
then?

bye,
//mirabilos
-- 
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

Bug#1056329: Cannot create simple TCPMUXPLUS service - produces seg fault

2023-11-20 Thread Brian Blood

Disregard,

I did not see in the xinetd.conf manpage that you have to also add the base 
tcpmux service file.

Bug#1043419: raising missing trigger interest to serious

2023-11-20 Thread Lorenzo

Hi Helmut,

On Sat, 18 Nov 2023 17:40:23 +0100 Helmut Grohne 
wrote:

First the actionable part:

> Is there actually any issue with promoting the change from
> experimental to unstable?
Yes: the version in experimental is definitely RC buggy, for reasons
unrelated to usrmerge

> If you lack a sponsor, I am willing to help
> out once to get this fixed.
Thanks, really appreciated:
I prepared a runit_2.1.2-54+usrmerge runit upload targeted at unstable
with two commits backported, you can find it on mentors

https://mentors.debian.net/package/runit/
dget -x
https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-54+usrmerge.dsc

and on salsa (usrmerge branch)
https://salsa.debian.org/debian/runit/-/tree/usrmerge?ref_type=heads

let me know if something else is needed for this upload.

Now the annoying part:

> it still affects
> trixie and sid, so by raising it to serious, we get rid of the bug in
> trixie before too long (either via upload or autoremove).

> [...] However, runit's triggers do
> not work anymore. That's a serious bug and we're tracking it like
> that.

I disagree about the severity (it should be assessed by looking at
the broken feature that is provided by the trigger) and especially I
disagree that the malfunction of this specific feature should cause the
removal of runit from testing (and the same goes for any other
alternative init system).
I'm stopping here as I think you don't want to spend further time on
this bug since it can be fixed with an upload, but I can elaborate if
you want me to.

Best Regards,
Lorenzo

> 
> Helmut
> 
> 
>

Bug#1056330: bookworm-pu: package toil/5.9.2-2+deb12u1

2023-11-20 Thread Santiago Vila


Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@packages.debian.org, sanv...@debian.org
Control: affects -1 + src:toil

[ Reason ]
This upload fixes Bug#1031192. FTBFS on single-cpu systems.

[ Impact ]
Anybody trying to build the package from source in stable on a single-cpu
system will see that the package unexpectedly FTBFS.

[ Tests ]
I've tested that the updated package builds ok in all systems.

[ Risks ]
There are no actual code changes in the program, only in the
way the tests are executed.

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

[ Changes ]
Backport patch from unstable to run the tests using
a single CPU.

[ Other info ]
The package is already uploaded.diff -Nru toil-5.9.2/debian/changelog toil-5.9.2/debian/changelog
--- toil-5.9.2/debian/changelog 2023-02-06 19:04:14.0 +0100
+++ toil-5.9.2/debian/changelog 2023-11-21 00:35:00.0 +0100
@@ -1,3 +1,11 @@
+toil (5.9.2-2+deb12u1) bookworm; urgency=medium
+
+  * Team upload.
+  * Apply patch by Michael R. Crusoe to request a single core
+in the tests. Closes: #1031192.
+
+ -- Santiago Vila   Tue, 21 Nov 2023 00:35:00 +0100
+
 toil (5.9.2-2) unstable; urgency=medium
 
   * Add patch to handle errors when testing on ec2.
diff -Nru toil-5.9.2/debian/patches/fewer_cores 
toil-5.9.2/debian/patches/fewer_cores
--- toil-5.9.2/debian/patches/fewer_cores   1970-01-01 01:00:00.0 
+0100
+++ toil-5.9.2/debian/patches/fewer_cores   2023-11-21 00:34:08.0 
+0100
@@ -0,0 +1,37 @@
+From: Michael R. Crusoe 
+Subject: Tests: only request a single core
+Bugs: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031192
+
+--- a/src/toil/test/src/helloWorldTest.py
 b/src/toil/test/src/helloWorldTest.py
+@@ -24,7 +24,7 @@
+ 
+ class HelloWorld(Job):
+ def __init__(self):
+-Job.__init__(self,  memory=10, cores=2, disk="3G")
++Job.__init__(self,  memory=10, cores=1, disk="3G")
+ 
+ def run(self, fileStore):
+ fileID = self.addChildJobFn(childFn, cores=1, memory="1M", 
disk="3G").rv()
+--- a/src/toil/test/src/realtimeLoggerTest.py
 b/src/toil/test/src/realtimeLoggerTest.py
+@@ -57,7 +57,7 @@
+ 
+ class LogTest(Job):
+ def __init__(self):
+-Job.__init__(self, memory=10, cores=2, disk='3G')
++Job.__init__(self, memory=10, cores=1, disk='3G')
+ 
+ def run(self, fileStore):
+ RealtimeLogger.info('This should be logged at info level')
+--- a/src/toil/test/src/userDefinedJobArgTypeTest.py
 b/src/toil/test/src/userDefinedJobArgTypeTest.py
+@@ -59,7 +59,7 @@
+ 
+ class JobClass(Job):
+ def __init__(self, level, foo):
+-Job.__init__(self, memory=10, cores=2, disk="300M")
++Job.__init__(self, memory=10, cores=1, disk="300M")
+ self.level = level
+ self.foo = foo
+ 
diff -Nru toil-5.9.2/debian/patches/series toil-5.9.2/debian/patches/series
--- toil-5.9.2/debian/patches/series2023-02-06 19:01:55.0 +0100
+++ toil-5.9.2/debian/patches/series2023-11-21 00:34:08.0 +0100
@@ -10,3 +10,4 @@
 atomic_copy_as_alternative.patch
 python3_in_doc.patch
 avoid_boto
+fewer_cores

Bug#967267: basilisk2: depends on deprecated GTK 2

2023-11-20 Thread Bastian Germann


The package builds without GTK 2, which will disable the GUI preferences editor.
I think it should still be fine to use.

Bug#1056329: xinetd: Cannot create simple TCPMUXPLUS service - produces seg fault

2023-11-20 Thread Brian Blood

Package: xinetd
Version: 1:2.3.15.3-1+b1
Severity: important

Dear Maintainer,

I'm trying to create a simple TCPMUXPLUS service that takes a TCP connection 
and returns a predetermined amount a entropy.

Here is my xinet.d conf file:

# default: off
# description: An xinetd service which provides entropy.
# the shell script called will return 128 bytes of entropy to the caller.
service entropy
{
id  = entropy
type= TCPMUXPLUS UNLISTED
socket_type = stream
protocol= tcp
disable = no
#flags   = KEEPALIVE IPv4
instances   = 40
server  = /srv/xinetd-entropy.sh
log_type= FILE /var/log/entropy-xinetd.log
log_on_success  = PID HOST USERID EXIT DURATION
log_on_failure  = HOST USERID ATTEMPT
user= nobody
wait= no
}

In this form, restarting xinetd produces this syslog output:

systemd[1]: Started xinetd.service - LSB: Starts or stops the xinetd daemon..
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/chargen 
[file=/etc/xinetd.conf] [line=14]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/chargen-udp 
[file=/etc/xinetd.d/chargen-udp] [line=28]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/daytime 
[file=/etc/xinetd.d/daytime] [line=14]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/daytime-udp 
[file=/etc/xinetd.d/daytime-udp] [line=26]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/discard 
[file=/etc/xinetd.d/discard] [line=14]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/discard-udp 
[file=/etc/xinetd.d/discard-udp] [line=25]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/echo 
[file=/etc/xinetd.d/echo] [line=14]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/echo-udp 
[file=/etc/xinetd.d/echo-udp] [line=26]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/egd-py 
[file=/etc/xinetd.d/egd-py] [line=14]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/entropy 
[file=/etc/xinetd.d/entropy] [line=21]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/servers 
[file=/etc/xinetd.d/servers] [line=21]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/services 
[file=/etc/xinetd.d/services] [line=13]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/time 
[file=/etc/xinetd.d/time] [line=13]
xinetd[9295]: Reading included configuration file: /etc/xinetd.d/time-udp 
[file=/etc/xinetd.d/time-udp] [line=28]
xinetd[9295]: 2.3.15.3 started with libwrap loadavg labeled-networking options 
compiled in.
xinetd[9295]: Started working: 0 available services





When I comment out the socket_type and protocol lines in the conf (since they 
are redundant to type being TCPMUXPLUS), restarting xinetd segfaults:


systemd[1]: Started xinetd.service - LSB: Starts or stops the xinetd daemon..
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/chargen 
[file=/etc/xinetd.conf] [line=14]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/chargen-udp 
[file=/etc/xinetd.d/chargen-udp] [line=28]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/daytime 
[file=/etc/xinetd.d/daytime] [line=14]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/daytime-udp 
[file=/etc/xinetd.d/daytime-udp] [line=26]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/discard 
[file=/etc/xinetd.d/discard] [line=14]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/discard-udp 
[file=/etc/xinetd.d/discard-udp] [line=25]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/echo 
[file=/etc/xinetd.d/echo] [line=14]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/echo-udp 
[file=/etc/xinetd.d/echo-udp] [line=26]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/egd-py 
[file=/etc/xinetd.d/egd-py] [line=14]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/entropy 
[file=/etc/xinetd.d/entropy] [line=21]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/servers 
[file=/etc/xinetd.d/servers] [line=21]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/services 
[file=/etc/xinetd.d/services] [line=13]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/time 
[file=/etc/xinetd.d/time] [line=13]
xinetd[9364]: Reading included configuration file: /etc/xinetd.d/time-udp 
[file=/etc/xinetd.d/time-udp] [line=28]
xinetd[9364]: 9364 {general_handler} (9364) Unexpected signal: 11 (Segmentation 
fault)
xinetd[9364]: 9364 {general_handler} (9364) Unexpected signal: 11 (Segmentation 
fault)
xinetd[9364]: 9364 {general_handler} (9364) Unexpected signal: 11 (Segmentation 
fault)
xinetd[9364]: 9364 {general_handler} (9364) Unexpected signal: 11 (Segmentation 
fault)
xinetd[9364]: 9364

Bug#1051243: texlive-binaries -8 version fixed the problem

2023-11-20 Thread Friedrich Beckmann

The problem is gone with the -8 release of texlive-binaries.

Thanks!!!

Bug#1056328: Fwd: Improving Compiz Default Settings

2023-11-20 Thread Samuel Thibault

Control: severity -1 wishlist
Control: tags -1 + upstream

Hello,

rhy o'drinnan, le lun. 20 nov. 2023 12:38:21 -1000, a ecrit:
> The defaults in Compiz are not terrible, but they could definitely be better. 
> This effects all distros downstream, and I've tried unsuccessfully to fix it
> and make changes in both Mint and Devuan, but it seems we need to upgrade the
> defaults in Debian and then they will just propagate down from there.

Well, even better submit fixes to upstream compiz
https://gitlab.com/compiz/compiz-core
so it propagates to all distributions, not only the Debian-based ones.

> Let me know if I can give examples or submit patches to relevant packages and
> what that would entail.

Yes, patches would be very welcome, as I don't think I can find time on
working them out myself.

Samuel

Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7


On 20.11.2023 11:34, Adrian Bunk wrote:

Hi all,


Right now the autopkgtests block zlib migration to testing since they
test zlib/unstable with texlive-binaries/testing - this is permitted
by the dependencies.

And this is not just a test issue:

Anybody has opened #1056312, I add my statement how to address this 
issue. So, I guess time to close this bug here.


Thanks to all, who contributed!

Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056328: Fwd: Improving Compiz Default Settings

2023-11-20 Thread rhy o'drinnan

Package: Compiz

The defaults in Compiz are not terrible, but they could definitely be
better. This effects all distros downstream, and I've tried unsuccessfully
to fix it and make changes in both Mint and Devuan, but it seems we need to
upgrade the defaults in Debian and then they will just propagate down from
there.

Basically, the important changes are minor, but make a very big usability
difference.

For one, in some downstream distros shortcuts are broken by compiz somehow,
for example alt+ctl T won't open a terminal any more.

The desktop cube settings are pretty ugly by default. It doesn't take much
to make them a lot better.

A) There should be some zoom out when desktop cube is enabled.
B) The cube looks a lot cleaner with transparent top and bottom caps.
C) Having a bit of opacity by default in mouse driven rotate cube is
another default that would be easy to implement and make quite a usability
improvement.
D) Enabling 3d windows by default makes desktop cube rotate a lot more
engagin.
E) The default skybox is pretty ugly. Another easy fix.
F) The speed of cube rotate, (as well as the minimize/maximize animations)
could definitely be bumped up. By default they are a bit slow.

Also, a lot of the shortcuts seem to be changed across distros, and there
used to be a very clear standard. For example SHFT+SUPER + Scroll for
enhanced zoom is broken in some downstream distros, and I've seen several
varying compete default controls that don't match what has been the
convention for more than decades.

Some of the MATE integration is a little off as well, but that might be a
MATE issue.

Let me know if I can give examples or submit patches to relevant packages
and what that would entail.

Here's a video of a better default Compiz configuration than what exists
out of the box at this moment.

https://rumble.com/v3wxjc1-compiz-default-settings-suggestions-for-debian-mint-devuan.html

All feedback welcome and thank you for creating my favorite operating
system ever before systemd.

rhY

--
- Cowboy Crooner, Violinist, Composer, Linux Guy, World's Best Dad, AirShip
Designer

rhymusic.com

OpenAirShips.com

thorntontechs.com

khanz.co

--
- Cowboy Crooner, Violinist, Composer, Linux Guy, World's Best Dad, AirShip
Designer

rhymusic.com

OpenAirShips.com

thorntontechs.com

khanz.co

Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory


Control: tags -1 - wontfix
Control: tags -1 + pending

On 20.11.2023 16:46, Pavel Sanda wrote:

Hello Pavel,


You can try proposed fix on your current setup.
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg220760.html

I plan to push it into CTAN, so it will hopefully get fixed in trixie
(or bookworm if some cares to backport the fix).

Thanks for the patch! I did not test it, but I've seen you did. I pushed 
it to our repo so it will be in next upload. Good luck with pushing the 
patch to CTAN.


Hilmar
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1010048: fs-uae-launcher: GUI is corrupted.

2023-11-20 Thread John Paul Adrian Glaubitz

On Mon, 2023-11-20 at 22:13 +0100, Miguel A. Vallejo wrote:
> I revisited https://github.com/FrodeSolheim/fs-uae-launcher/issues/143
> and I noticed user glaubitz is open to make the changes needed to have
> this package back in Debian.
> 
> Dear maintainer, please explain to GitHub / glaubitz what is needed to
> have fs-uae-launcher back in Debian.

That user "glaubitz" is me ;-).

Someone actually sent me a mail in private and offered to help sorting
out with the packaging issues but I haven't heard back from him.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1056327: Acknowledgement (Nautilus integration: Nextcloud shares shown twice)


Control: tags -1 + patch

Attached is a (build)tested patch, fixing the issue

Michael
diff -Nru nextcloud-desktop-3.10.0/debian/changelog 
nextcloud-desktop-3.10.0/debian/changelog
--- nextcloud-desktop-3.10.0/debian/changelog   2023-10-08 00:39:51.0 
+0200
+++ nextcloud-desktop-3.10.0/debian/changelog   2023-11-20 21:40:14.0 
+0100
@@ -1,3 +1,13 @@
+nextcloud-desktop (3.10.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not install legacy /usr/share/cloud-provider directory.
+Since libcloudproviders 0.3.3+ the integration points are now directly
+specificied in the .desktop file. This avoids that Nautilus shows
+Nextcloud shares twice. (Closes: #1056327)
+
+ -- Michael Biebl   Mon, 20 Nov 2023 21:40:14 +0100
+
 nextcloud-desktop (3.10.0-1) unstable; urgency=medium
 
   * New upstream release (3.10.0).
diff -Nru nextcloud-desktop-3.10.0/debian/control 
nextcloud-desktop-3.10.0/debian/control
--- nextcloud-desktop-3.10.0/debian/control 2023-10-08 00:39:51.0 
+0200
+++ nextcloud-desktop-3.10.0/debian/control 2023-11-20 21:40:14.0 
+0100
@@ -8,7 +8,7 @@
debhelper-compat (= 13),
doxygen,
extra-cmake-modules (>= 5.16.0~),
-   libcloudproviders-dev,
+   libcloudproviders-dev (>= 0.3.3),
libcmocka-dev,
libdbus-1-dev,
libinotify-dev [kfreebsd-any],
diff -Nru nextcloud-desktop-3.10.0/debian/nextcloud-desktop.install 
nextcloud-desktop-3.10.0/debian/nextcloud-desktop.install
--- nextcloud-desktop-3.10.0/debian/nextcloud-desktop.install   2023-10-08 
00:39:51.0 +0200
+++ nextcloud-desktop-3.10.0/debian/nextcloud-desktop.install   2023-11-20 
21:39:59.0 +0100
@@ -2,5 +2,4 @@
 usr/lib/*/qt5/plugins/nextcloudsync_vfs_*.so
 usr/share/applications/com.nextcloud.desktopclient.nextcloud.desktop
 usr/share/dbus-1/services/com.nextcloudgmbh.Nextcloud.service
-usr/share/cloud-providers/com.nextcloudgmbh.Nextcloud.ini
 usr/share/mime/packages/nextcloud.xml
diff -Nru nextcloud-desktop-3.10.0/debian/not-installed 
nextcloud-desktop-3.10.0/debian/not-installed
--- nextcloud-desktop-3.10.0/debian/not-installed   2023-10-08 
00:39:51.0 +0200
+++ nextcloud-desktop-3.10.0/debian/not-installed   2023-11-20 
21:40:14.0 +0100
@@ -1 +1,2 @@
 usr/share/man/man1/nextcloud.1
+usr/share/cloud-providers/


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041631: texlive-xetex: CreationDate in the generated PDF file is incorrect by 1 hour in some timezones


On 21.07.2023 16:46, Vincent Lefevre wrote:

On 2023-07-21 16:36:21 +0200, Preuße, Hilmar wrote:

On 21.07.2023 16:28, Vincent Lefevre wrote:


Hi,


The "CreationDate:" field in the generated PDF file is incorrect by
1 hour in the Europe/Paris CEST timezone (= UTC + 2).


I've uploaded TL2023 to experimental. Are you willing to test if the issue
is solved there?

Beware: the package is not complete yet, there is not context package being
compatible to texlive-binaries.


Sorry, I've just noticed that I forgot to include the test.tex file.
Here is it (this is the simplest one as possible):

\documentclass{article}
\begin{document}
.
\end{document}

If you installed TL2023 on one of your machines, could you try to
reproduce the bug after "export TZ=Europe/Paris", for instance?

Otherwise, I can try (but it will be a bit complex to upgrade the
packages to experimental and downgrade again after the test).



Currently I'm now able to reproduce the issue, I guess b/c we're in 
winter time. I guess I have to break the time on my test box...


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050417: lightdm-guest-session support (via Arctica Greeter) takes a long time to startup X11 guest sessions

2023-11-20 Thread Mike Gabriel


HI Yves-Alexis,

On  Mo 20 Nov 2023 21:39:54 CET, Yves-Alexis Perez wrote:


On Sun, 2023-11-19 at 10:07 +, Mike Gabriel wrote:

I just tested this once more: It needs to be

/run/user/*/ICEauthority-l l,

Without that line, guest login to a MATE desktop is slloo 
(with error dialog about /run/user/*/ICEauthority, without "-l").

With that line, login is smooth, no error dialog anymore.


Ok, that's confusing (unless there's a specific syntax weirdness?). I assume
you tested with:

/run/user/*/ICEauthority l,

and it didn't work?


Correct. To be fully sure, I tested again (Debian 12):

/run/user/*/ICEauthority l, -> long delay when logging into MATE (+  
dialog error)

/run/user/*/ICEauthority-l l, -> smoothly logging into MATE
no such line -> -> long delay when logging into MATE (+ dialog error)

Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgp77AHFkGQgA.pgp
Description: Digitale PGP-Signatur

Bug#1056157: libfalcosecurity0-dev: libsinsp.pc lists wrong libs: -lgRPC::grpc++ -lgRPC::grpc -lgRPC::gpr

2023-11-20 Thread Dima Kogan

Hello. Thanks for the report. I fixed the original issue you reported in
git, but haven't tested it yet, or released the fixed packages.

I'll look at this in a bit.

This package has bigger problems, unfortunately. Let me know if you
want to help fix them.

Bug#1056157: libfalcosecurity0-dev: libsinsp.pc lists wrong libs: -lgRPC::grpc++ -lgRPC::grpc -lgRPC::gpr

2023-11-20 Thread Bálint Réczey

Hi,

On Fri, 17 Nov 2023 23:44:23 +0100 =?UTF-8?B?QsOhbGludCBSw6ljemV5?=
 wrote:
> Source: falcosecurity-libs
> Version: 0.11.3+repack-6
> Severity: wishlist
> Affects: wireshark
>
> Dear Maintainer,
>
> libsinsp.pc should list the grpc libs without the gRPC:: prefix. That
> prevents configuring wireshark to build Logray.

-lluajit-5 also seems wrong, it should probably be -lluajit-5.1 or it
could just be omitted.

Would not just -lsinsp be enough BTW? If not, please make
libfalcosecurity0-dev depend on the development packages shipping the
libraries needed for linking.

Cheers,
Balint

> Cheers,
> Balint
>
>

Bug#1055567: Error: gscan2pdf fails to compile

2023-11-20 Thread Jeff


On 20/11/2023 17:51, Soumyanath Chatterjee wrote:
soumyanath@ganak-desktop:~$ LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ 
gscan2pdf


This one works.

Please suggest what changes I need to make to run it normally


For me, this isn't a problem with gscan2pdf, but with the way that 
libsane was compiled (or better, linked) against libusb.


i.e. the problem can only be fixed by a new version of libsane.

As you are using Ubuntu, I suggest you raise a bug against the libsane 
package:


https://packages.ubuntu.com/search?keywords=libsane


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1010048: fs-uae-launcher: GUI is corrupted.

2023-11-20 Thread Miguel A. Vallejo

Hello

I revisited https://github.com/FrodeSolheim/fs-uae-launcher/issues/143
and I noticed user glaubitz is open to make the changes needed to have
this package back in Debian.

Dear maintainer, please explain to GitHub / glaubitz what is needed to
have fs-uae-launcher back in Debian.

Thank you

Bug#1053023: Additional information

2023-11-20 Thread Vladimir Petko

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this
issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/gnome-split/-/merge_requests/1

Bug#1056327: Nautilus integration: Nextcloud shares shown twice

Package: nextcloud-desktop
Version: 3.10.0-1
Severity: normal

Since the upgrade to 3.10.0-1, any Nextcloud shares are shown twice in
Nautilus.
This has been raised upstream https://github.com/nextcloud/desktop/issues/6218

The recommendation is, that with libcloudproviders 0.3.3+, the directory
/usr/share/cloud-providers is considered legacy and should not be
shipped anymore
https://github.com/nextcloud/desktop/issues/6218#issuecomment-1819479543


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

Kernel: Linux 6.5.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 nextcloud-desktop depends on:
ii  libc6  2.37-12
ii  libcloudproviders0 0.3.4-1
ii  libgcc-s1  13.2.0-6
ii  libglib2.0-0   2.78.1-4
ii  libkf5archive5 5.107.0-1
ii  libnextcloudsync0  3.10.0-1
ii  libqt5core5a   5.15.10+dfsg-5
ii  libqt5dbus55.15.10+dfsg-5
ii  libqt5gui5 5.15.10+dfsg-5
ii  libqt5keychain10.14.1-1
ii  libqt5network5 5.15.10+dfsg-5
ii  libqt5qml5 5.15.10+dfsg-2
ii  libqt5quick5   5.15.10+dfsg-2
ii  libqt5quickcontrols2-5 5.15.10+dfsg-2
ii  libqt5sql5-sqlite  5.15.10+dfsg-5
ii  libqt5svg5 5.15.10-2
ii  libqt5webenginecore5   5.15.15+dfsg-2+b1
ii  libqt5webenginewidgets55.15.15+dfsg-2+b1
ii  libqt5widgets5 5.15.10+dfsg-5
ii  libssl33.0.12-2
ii  libstdc++6 13.2.0-6
ii  nextcloud-desktop-common   3.10.0-1
ii  nextcloud-desktop-l10n 3.10.0-1
ii  qml-module-qt-labs-platform5.15.10+dfsg-2
ii  qml-module-qtgraphicaleffects  5.15.10-2
ii  qml-module-qtqml   5.15.10+dfsg-2
ii  qml-module-qtqml-models2   5.15.10+dfsg-2
ii  qml-module-qtquick-controls2   5.15.10+dfsg-2
ii  qml-module-qtquick-dialogs 5.15.10-2
ii  qml-module-qtquick-layouts 5.15.10+dfsg-2
ii  qml-module-qtquick-window2 5.15.10+dfsg-2
ii  qml-module-qtquick25.15.10+dfsg-2

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.10.0-1

nextcloud-desktop suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: missing file 
/usr/share/cloud-providers/com.nextcloudgmbh.Nextcloud.ini (from 
nextcloud-desktop package)

Bug#1056326: ITP: python-crispy-bootstrap3 -- Bootstrap3 template pack for django-crispy-forms

2023-11-20 Thread Michael Fladischer

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-crispy-bootstrap3
  Version : 2022.1
  Upstream Contact: David Smith
* URL : https://github.com/django-crispy-forms/crispy-bootstrap3
* License : Expat
  Programming Lang: Python
  Description : Bootstrap3 template pack for django-crispy-forms

 Bootstrap3 template pack for django-crispy-forms. This template pack was
 included with the core django-crispy-forms package until version 2.0.

It is a dependency to run the tests in django-crispy-forms >2 and I intend to
maintain it as part of the DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmVbxVYbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqOtIH/0z/UfmggnZh4qn0VWAl
eIkgVUMbcq9rHbSSf4lKSZwdKGRgKSp8EWKEOucgMELr9RljGt/6IVUFOp45r5jJ
rNsqBVvR+atGoElkqtFg7MM6apHHjAd3gDV6vndE4YDTlEhFaQ1L6yQ1RZr+Pmbs
IEb0oerE6yz0tWbtaGfMnH03Sv0j0LodZ73lCAIXW+pZ6y6eFCwQSFO07wf0Geom
PhChc8QlF1/A6nsI3T6l+OZ266wQlb4Iytf0/KPiNO/mgUSh+b40+IEj2GXoD4M1
H2rRlqOrc1bCH+rIShE3+mUKZsYPi8dSclADveTCUdA8tKZVyEFPNva1vo9ztWrt
4Jk=
=Kzic
-END PGP SIGNATURE-

Bug#1050417: lightdm-guest-session support (via Arctica Greeter) takes a long time to startup X11 guest sessions

2023-11-20 Thread Yves-Alexis Perez

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2023-11-19 at 10:07 +, Mike Gabriel wrote:
> I just tested this once more: It needs to be
> 
> /run/user/*/ICEauthority-l l,
> 
> Without that line, guest login to a MATE desktop is slloo  
> (with error dialog about /run/user/*/ICEauthority, without "-l").
> 
> With that line, login is smooth, no error dialog anymore.

Ok, that's confusing (unless there's a specific syntax weirdness?). I assume
you tested with:

/run/user/*/ICEauthority l,

and it didn't work?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmVbxBsACgkQ3rYcyPpX
RFtyIQgA235A9IBEsi1H1NRl9VROuJSPFM8k4KTXrkbNMQ28pz+e24tnnfnbFXRa
55WnPtSzP96+420dKiUuYQgoL+BmZf4zQXT9o2YQDzdXVbFhtDpy+NW8B4rOQk0j
EuaSwNcAXrE/QJsGMt0JfX9vIm+X8cHorYupHEy61kIAyzpRgU5K8fAUclV6vs2L
RHbxja0HAXHCsoURKbVkEPJWo6LGX+fB7N1uJSGhFNfKJcYx1CDPJGgsGnuge7MV
JrjyFFrCeHyCK/zqxQZUvBKH5roI+EEoo+eHuADhCJAwqc4L/+aHa90e+on1Z8il
QEajGSWgyo3HGrymx2hCEHRVxolD9w==
=omCC
-END PGP SIGNATURE-

Bug#1054308: Please install helper binaries into /usr/libexec


Hi

On Sat, 21 Oct 2023 13:41:38 +0200 Michael Biebl  wrote:

Source: network-manager-ssh
Version: 1.2.11-1
Severity: wishlist
Tags: patch
User: bi...@debian.org
Usertags: nm-libexec

Hi,

your package installs helper binaries that are currently located in
/usr/lib/NetworkManager.
Now that Debian policy allows to install such binaries into
/usr/libexec, it was requested in [1] that the network-manager package
is updated to use this location to align with other distros and avoid
unnecessary friction.

The network-manager package and the vpn packages maintained by the
pkg-utopia team have been updated accordingly.

For consistencies sake, please consider applying the attached patch,
which moves the helper binaries to /usr/libexec.

Thanks,
Michael


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



I've done an NMU to Delayed/14 including this change.

Please holler, if you want me to cancel the NMU.

Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055067: isc-dhcp-client: network-manager 1.44.2-3 changed path to nm-dhcp-helper, apparmor need update

I will add a versioned Breaks isc-dhcp-client (<< 4.4.3-P1-5) to 
network-manager, assuming the next version fixing this issue will be 
4.4.3-P1-5.


Btw, the AppArmor policy also references
/usr/lib/NetworkManager/nm-dhcp-client.action

This binary is long gone. You can just remove any traces of it.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056073: audacious: No media buttons in QT mode

2023-11-20 Thread Amy Kos


Control: block -1 by 1055311


Hi,

please install libqt6svg6

Cheers.
Amy

Bug#1056325: AppArmor policy references outdated NetworkManager binaries

Package: dhcpcanon
Version: 0.8.5-2
Severity: important

The AppArmor policy shipped by dhcpcanon references the following
outdated NetworkManager resources:

a/ The binary /usr/lib/NetworkManager/nm-dhcp-helper has been moved to
/usr/libexec/nm-dhcp-helper in network-manager_1.44.2-3

b/ The binary /usr/lib/NetworkManager/nm-dhcp-client.action is long
gone.

Bug#1056047: python-skbio ftbfs with Python 3.12 (and cython 3.0.5)

With cython 0.29, there are test failures, as can be seen in the
upstream bug report:

https://github.com/scikit-bio/scikit-bio/issues/1897

Bug#1056323: python-biom-format: FTBFS with Python 3.12 (test failures)

Control: tags -1 + patch

The attached patch, cherry-picked from upstream, works for me.
Description: locale.format --> locale.format_string
 locale.format was deprecated in Python 3.7, see
 https://docs.python.org/3/library/locale.html#locale.format
Origin: upstream, https://github.com/biocore/biom-format/commit/de8886a77940b7fd627498990888509c464702fd
Author: Peter Cock 
Last-Update: 2023-03-13

--- a/biom/cli/table_summarizer.py
+++ b/biom/cli/table_summarizer.py
@@ -80,20 +80,20 @@
 
 if observations:
 # as this is a transpose of the original table...
-lines.append('Num samples: ' + locale.format('%d', num_observations,
- grouping=True))
-lines.append('Num observations: ' + locale.format('%d', num_samples,
-  grouping=True))
+lines.append('Num samples: ' + locale.format_string('%d',
+ num_observations, grouping=True))
+lines.append('Num observations: ' + locale.format_string('%d',
+ num_samples, grouping=True))
 else:
-lines.append('Num samples: ' + locale.format('%d', num_samples,
- grouping=True))
-lines.append('Num observations: ' + locale.format('%d',
+lines.append('Num samples: ' + locale.format_string('%d',
+ num_samples, grouping=True))
+lines.append('Num observations: ' + locale.format_string('%d',
  num_observations, grouping=True))
 
 if not qualitative:
 total_count = sum(counts_per_sample_values)
-lines.append('Total count: ' + locale.format('%d', total_count,
- grouping=True))
+lines.append('Total count: ' + locale.format_string('%d',
+ total_count, grouping=True))
 lines.append('Table density (fraction of non-zero values): %1.3f' %
  table.get_table_density())
 
@@ -107,13 +107,15 @@
 else:
 lines.append('Counts/sample summary:')
 
-lines.append(' Min: ' + locale.format('%1.3f', min_counts, grouping=True))
-lines.append(' Max: ' + locale.format('%1.3f', max_counts, grouping=True))
-lines.append(' Median: ' + locale.format('%1.3f', median_counts,
- grouping=True))
-lines.append(' Mean: ' + locale.format('%1.3f', mean_counts,
-   grouping=True))
-lines.append(' Std. dev.: ' + locale.format('%1.3f',
+lines.append(' Min: ' + locale.format_string('%1.3f',
+ min_counts, grouping=True))
+lines.append(' Max: ' + locale.format_string('%1.3f',
+ max_counts, grouping=True))
+lines.append(' Median: ' + locale.format_string('%1.3f',
+ median_counts, grouping=True))
+lines.append(' Mean: ' + locale.format_string('%1.3f',
+ mean_counts, grouping=True))
+lines.append(' Std. dev.: ' + locale.format_string('%1.3f',
  std(counts_per_sample_values), grouping=True))
 
 if observations:
@@ -140,6 +142,7 @@
 lines.append('Counts/sample detail:')
 
 for k, v in sorted(counts_per_samp.items(), key=itemgetter(1)):
-lines.append('%s: ' % k + locale.format('%1.3f', v, grouping=True))
+lines.append('%s: ' % k + locale.format_string('%1.3f',
+ v, grouping=True))
 
 return "\n".join(lines)

Bug#1056324: RFS: libonig/6.9.9-1 -- regular expressions library

2023-11-20 Thread Jörg Frings-Fürst

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name : libonig
   Version  : 6.9.9-1
   Upstream contact : [fill in name and email of upstream]
   URL  : https://github.com/kkos/oniguruma
   License  : BSD-2-clause
   Vcs  : https://git.jff.email/cgit/libonig.git
   Section  : libs

The source builds the following binary packages:

  libonig5 - regular expressions library
  libonig-dev - regular expressions library — development files

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

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

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

 dget -x  
https://mentors.debian.net/debian/pool/main/libo/libonig/libonig_6.9.9-1.dsc

or from

 git https://git.jff.email/cgit/libonig.git/?h=release%2Fdebian%2F6.9.9-1

or

 git (old) https://jff.email/cgit/libonig.git/?h=release%2Fdebian%2F6.9.9-1


Changes since the last upload:

 libonig (6.9.9-1) unstable; urgency=medium
 .
   * New upstream release.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list: 
 - Please send me a picture from the nature at your home.






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

Bug#1036525: network-manager-applet: Add support for WPA3 Enterprise networks


Hi Robert

On Mon, 22 May 2023 00:59:37 +0200 Robert Senger 
 wrote:

Source: network-manager-applet
Version: 1.30.0-2
Severity: wishlist
Tags: patch upstream

Dear Maintainer,

please add support for WPA3 Enterprise networks. NetworkManager does support
these networks, only network-manager-applet and libnma packages do not. I've
patched both packages and successfully added full support for WPA3 Enterprise.
I am not a professional developer, and I do not have a build environment, so I
had to patch the deb-src packages. Because of that, I have not included these
patches as they may be of doubtfull quality, but if anyone is interested in
those patches, just contact me.



Patches like this should really be added upstream and properly reviewed 
there. It's not suitable as a downstream modification.


Please submit a MR at
https://gitlab.gnome.org/GNOME/network-manager-applet/-/merge_requests

Thanks for your contribution!

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056323: python-biom-format: FTBFS with Python 3.12 (test failures)

Source: python-biom-format
Version: 2.1.12-3
Severity: important
Tags: ftbfs sid trixie
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Hi Maintainer

python-biom-format FTBFS with Python 3.12 as a supported version.
I've copied below what I hope is the relevant part of the log.

Regards
Graham


=== FAILURES ===
___ TestSummarizeTable.test_default 

self = 

def test_default(self):
""" TableSummarizer functions as expected

"""
>   result = _summarize_table(self.biom1)

/<>/.pybuild/cpython3_3.12_biom-format/build/biom/tests/test_cli/test_summarize_table.py:30:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

table = 14 x 9  with 30 nonzero entries (23% dense)
qualitative = False, observations = False

def _summarize_table(table, qualitative=False, observations=False):
lines = []
locale.setlocale(locale.LC_ALL, '')

if observations:
table = table.transpose()

min_counts, max_counts, median_counts, mean_counts, counts_per_samp =\
compute_counts_per_sample_stats(table, qualitative)
num_observations = len(table.ids(axis='observation'))

counts_per_sample_values = list(counts_per_samp.values())

if table.metadata() is None:
sample_md_keys = ["None provided"]
else:
sample_md_keys = table.metadata()[0].keys()

if table.metadata(axis='observation') is None:
observation_md_keys = ["None provided"]
else:
observation_md_keys = table.metadata(axis='observation')[0].keys()

num_samples = len(table.ids())

if observations:
# as this is a transpose of the original table...
lines.append('Num samples: ' + locale.format('%d', num_observations,
 grouping=True))
lines.append('Num observations: ' + locale.format('%d', num_samples,
  grouping=True))
else:
>   lines.append('Num samples: ' + locale.format('%d', num_samples,
 grouping=True))
E   AttributeError: module 'locale' has no attribute 'format'.
Did you mean: '_format'?

/<>/.pybuild/cpython3_3.12_biom-format/build/biom/cli/table_summarizer.py:88:
AttributeError

Bug#1056322: FTBFS: python-oslo.concurrency: requires root rights

2023-11-20 Thread Andrey Feofilaktov

Package: python-oslo.concurrency
Version: 5.2.0-2

Package tries to set core rlimit in one of its tests:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-oslo.concurrency.html

There has already been a skip for test_setrlimit_error of the same test
suite:
https://salsa.debian.org/openstack-team/oslo/python-oslo.concurrency/-/commit/66c7efb2b51570e0aa88d3100dcef378dae9aa13

I did not find the issue in the upstream:
https://bugs.launchpad.net/oslo.concurrency, and the tests are unchanged
there, so I assume the preferred approach for Debian packaging is skipping
that test.

Here's a patch that worked for me:

Description: Skip test_core_size of the prlimit suite
Author: Andrey Feofilaktov 
Last-Update: 2023-11-20
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: python-oslo.concurrency-5.2.0/debian/rules
===
--- python-oslo.concurrency-5.2.0.orig/debian/rules
+++ python-oslo.concurrency-5.2.0/debian/rules
@@ -20,7 +20,7 @@ ifeq (,$(findstring nocheck, $(DEB_BUILD
set -e ; set -x ; for i in $(PYTHON3S) ; do \
rm -rf .stestr ;\
PATH=$$PATH:$(CURDIR)/debian/exe-test
PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages
PYTHON=python$$i TEST_EVENTLET=0 lockutils-wrapper stestr run --parallel
--subunit
'oslo_concurrency\.tests\.unit\.(?!test_processutils\.PrlimitTestCase\.test_setrlimit_error)'
| subunit2pyunit ; \
-   PATH=$$PATH:$(CURDIR)/debian/exe-test
PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages
PYTHON=python$$i TEST_EVENTLET=1 lockutils-wrapper stestr run --parallel
--subunit
'oslo_concurrency\.tests\.unit\.(?!test_processutils\.PrlimitTestCase\.test_setrlimit_error)'
| subunit2pyunit ; \
+   PATH=$$PATH:$(CURDIR)/debian/exe-test
PYTHONPATH=$(CURDIR)/debian/tmp/usr/lib/python3/dist-packages
PYTHON=python$$i TEST_EVENTLET=1 lockutils-wrapper stestr run --parallel
--subunit
'oslo_concurrency\.tests\.unit\.(?!test_processutils\.PrlimitTestCase\.(test_setrlimit_error\|test_core_size))'
| subunit2pyunit ; \
done
 endif

-- 
Regards,
Andrey

Bug#1003860: Will makemkv eventually make its' way to debian/non-free?

2023-11-20 Thread Samuli Suonpää

Any plans regarding this ITP? Are you planning to upload the package to 
debian/non-free at some point?

I see you are providing packages on you own apt tree. The packages there are 
currently uninstallable in bookworm and seem to be blocking upgrades of 
libavcodec59 and libavutils57.

Dependency issue seems to be with libmakemkv1:

Depends: libavcodec59 (= 7:5.1.3-1), libavutil57 (>= 7:5.1)


-- 
Samuli Suonpää, toimittaja

Bug#1055864: marked as pending in dh-make

2023-11-20 Thread Baptiste Beauplat

Hi Faidon,

On Mon, 2023-11-20 at 18:55 +, Baptiste Beauplat wrote:
> https://salsa.debian.org/debian/dh-make/-/commit/0ff6224dfea6c4c1502bf62b2bf57702de77d7e7

I've made a mention of lowdown in the manpage example.

Since it has very low adoption right now, I'll leave the reference to
pandoc as well.

I'll do a release of dh-make next week, including this modification.

Thanks!

-- 
Baptiste Beauplat



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

Bug#1056176: insserv: please support DPKG_ROOT

2023-11-20 Thread Mark Hindley

Control: tags -1 pending

Thanks.

Queued for the next upload.

Mark

Bug#1004472: groupmem: make authentification clear and check interaction with PAM

2023-11-20 Thread Miha Purg

Package: passwd
Version: 1:4.13+dfsg1-3
Followup-For: Bug #1004472
X-Debbugs-Cc: miha.p...@canonical.com

Confirming that the issue still exists in unstable.

When trying to use the command as root, the user is prompted for root's 
password,
which doesn't seem to be the correct behavior.

The reason seems to be a missing PAM file for groupmems:
https://github.com/shadow-maint/shadow/blob/master/etc/pam.d/groupmems

See also https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2039541

Best regards,
Miha



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

Kernel: Linux 6.1.0-13-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
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 passwd depends on:
ii  libaudit1   1:3.0.9-1
ii  libc6   2.36-9+deb12u3
ii  libcrypt1   1:4.4.33-2
ii  libpam-modules  1.5.2-6+deb12u1
ii  libpam0g1.5.2-6+deb12u1
ii  libselinux1 3.4-1+b6
ii  libsemanage23.4-1+b5

Versions of packages passwd recommends:
ii  sensible-utils  0.0.17+nmu1

passwd suggests no packages.

-- debconf information excluded

Bug#1006263: ifupdown: outdated DHCP client support

2023-11-20 Thread Martin-Éric Racine

Package: ifupdown
Version: 0.8.41
Followup-For: Bug #1006263

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As discussed in bug #1038882, ifupdown needs to change its precedence order for 
DHCP clients. The new order of precedence should be: dhcpcd, dhclient, others 
(see above). This is necessary to ensure that dhcpcd-base will become the new 
default DHCP client after upgrades.

Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmVbnr4ACgkQrh+Cd8S0
17YtvxAAtY6xRzY+T628fW9mtCR3jcC01aPNhSJNNUDzwGyGvh6CWha3Tp4HJfPF
AQh/Hdc+4j+HPo+EKOvO5zm58DHsGTKSFrm72QTwLJmhmXHig1ZNjDcSY+TUno3Y
mPoEhWKDkPxqeO8tDOCV2m9ydRk9AEYNO2TgoGarIj+EeIOzKzNdWZCPDnb+HC4U
7MJJjjtAyBbt1OFFX1QhMcSJAiJU8uIEQyjhrztvAYHLnxMV/hov92sf82RsXR2G
QTjf0rNSdOtcYnyJW612HzDsWuHAIRbp9qBpSn6cwLvz1OP+ZwRVWKk7xcuN0xj2
/t5Gw2IOX6KZ4KFB1jPTjYItb4XBmtu4jV9/IBUCLMImFLN1lYShUZ1z5EJ6mWY/
eEn5mWqiibF2ttW6VbMoTCFTLew2ETY6RDTcKFvK7PbDmruUhU54h50Egpeo46yA
eQuVbH+Rvz29su8+NtXH2KzLnKcS+sAXSNYw+KkiHg+HfkebA7sLvNbnQIy18Mej
CnnEAV5JsU63EXbELAMDYtOuE1RDTdFvRBftJXjAWJPw3yOl1k9T2kSju0yBLuFd
bxxlciIlSM0Xx4WVFiA62hAuU4rukPp+f4nqQXfE+kPeMEfX0ma2wGAof36kjgLP
IXKkIRlj+386j02SXxrv5iojobm04Gj7UIokEsCEMQZMSb7fAhU=
=/jHu
-END PGP SIGNATURE-

Bug#1056321: elogind conflicts with same version libelogind0

2023-11-20 Thread Slim Joe

Package: elogind
Version: 246.10-1debian1
Severity: normal

Dear Maintainer,

The systemd alternative, elogind, appears to conflict with its apparent support 
library (libelogind0). Is this a packaging oversight? Or this part of a plan to 
eventually deprecate elogind as an install option?

Below is a prettifed shell output showing the conflict between the version of 
elogind vs. libelogind in Testing (also Unstable).

$ apt show elogind/testing libelogind0/testing | grep -E 
'^(Package|Version|Depend|Conflicts)' 

Package: elogind
Version: 252.9-1debian2
Depends: libacl1 (>= 2.2.23), libc6 (>= 2.34), libcap2 (>= 1:2.10), libmount1 
(>= 2.19.1), libpam0g (>= 0.99.7.1), libselinux1 (>= 3.1~), libudev1, 
libsystemd0, dbus (>= 1.9.14)
Conflicts: libelogind0, systemd

Package: libelogind0
Version: 252.9-1debian2
Depends: libc6 (>= 2.34), libcap2 (>= 1:2.10)
Conflicts: libsystemd0, systemd

A casual look at the Conflicts field for "elogind" suggests
a possible fix. Maybe you could add a "versioned" conflict
for libelogind, something like: libelogind (>= xxx.xx)?

If elogind is to be phased out, maybe an appropriate notice
should be posted and perhaps a transitional dummy package
should be made?

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (90, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages elogind depends on:
ii  dbus   1.14.10-3
ii  debconf1.5.82
ii  init-system-helpers1.65.2
ii  libacl12.3.1-3
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libelogind0246.10-1debian1
ii  libpam0g   1.5.2-9.1
ii  libselinux13.5-1
ii  libudev1   254.5-1
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.08-3

Versions of packages elogind recommends:
ii  libpam-elogind  246.10-1debian1
pn  polkitd 

elogind suggests no packages.

-- no debconf information

Bug#1038882: proposal: dhcpcd-base as standard DHCP client starting with Trixie

2023-11-20 Thread Martin-Éric Racine

(non-subscriber - please keep me in CC)
On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine
 wrote:
>
> On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine
>  wrote:
> >
> > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón
> > >  wrote:
> > > >
> > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > > > > >  wrote:
> > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > > > > > Greetings,
> > > > > > > >
> > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now 
> > > > > > > > might be a
> > > > > > > > good time to re-visit Debian's choice of standard DHCP client 
> > > > > > > > shipping
> > > > > > > > with priority:important.
> > > > > > > >
> > > > > > > > I hereby propose bin:dhcpcd-base:
> > > > > > > >
> > > > > > > > 1) already supported by ifupdown.
> > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with 
> > > > > > > > privilege separation.
> > > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > > > > > > > configure both stacks.
> > > > > > > ...
> > > > > > >
> > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client 
> > > > > > > for
> > > > > > > the moment, and I'll make the relevant changes in ifupdown as 
> > > > > > > soon as I
> > > > > > > can. Josué, any thoughts?
> > > > > >
> > > > > > 1) As someone pointed out in the thread, the reason why
> > > > > > isc-dhcp-client had priority:important probably was to ensure that
> > > > > > debootstrap would pull it, since debootstrap ignores Recommends and
> > > > > > packages with a priority lower than standard.
> > > > > >
> > > > > > 2) However, as long as ifupdown explictly depends on a package, it 
> > > > > > can
> > > > > > also pull dependencies with a lower priority. Right now ifupdown
> > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would
> > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" 
> > > > > > instead.
> > > > > >
> > > > > > 3) At that point, swapping the priority of isc-dhcp-client and
> > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of 
> > > > > > both
> > > > > > could, in principle, be optional, just as long as ifupdown 
> > > > > > explicitly
> > > > > > Depends on a DHCP client, and the first alternative is a real 
> > > > > > package.
> > > > >
> > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if
> > > > > isc-client-dhcp is a Recommends, is because not all users want a dhcp
> > > > > client installed, where all the ipv4 is handled statically, and ipv6 
> > > > > is
> > > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base 
> > > > > the
> > > > > next upgrade.
> > > > >
> > > > > So I'd prefer to go forward with the steps proposed by Simon, and
> > > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends:
> > > > > Unless there is a strong objection, I'll file the override bug report.
> > > >
> > > > (sorry for taking so long to come back to this)
> > > >
> > > > For the moment, ifupdown is still installed by the debian-installer as
> > > > default network interfaces manager. And after sleeping over it, and
> > > > discussing with debian fellows, I would like to call for consensus to
> > > > rise Priority: Important to dhcpcd-base (as initially requested in
> > > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client.
> > > >
> > > > This addresses two scenarios: keep some systems as small as possible
> > > > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp
> > > > client available after installing/bootstrapping.
> > > >
> > > > So I would like to retitle #1038882 back as originally reported. (Sorry
> > > > for going back and forth) Objections?
> > > >
> > > > The situation regarding the default network interfaces manager could
> > > > change, even in the short term. But that could be discussed in another
> > > > thread.
> > >
> > > No objection. Raising the priority of dhcpcd-base to important works for 
> > > me.
> >
> > Have we reached a conclusion? Are we moving ahead with this or not?
>
> What is the current situation?

Michael replied that an upgrade would result in both remaining
installed. That is precisely the situation that I previously tried to
avoid by having a Conflicts against other dhcp-clients. I've been told
that this was the incorrect approach, so I removed the Conflicts.

Rhys asked what happens if both are installed. As per interfaces(5):
dhclient, udhcpc, dhcpcd - in order of precedence. Basically, ensuring
that dhcpcd gets used would require a change to ifupdown's search

Bug#1056313: [Pkg-utopia-maintainers] Bug#1056313: network-manager: breaks networking


Control: severity -1 normal
Control: block -1 1055067


Am 20.11.23 um 13:25 schrieb Vincent Lefevre:

On 2023-11-20 12:42:14 +0100, Vincent Lefevre wrote:

I suspect that nm-dhcp-helper has been added because it is now needed.
But it doesn't work due to the "Permission denied".


If I understand correctly, /usr/lib/NetworkManager/nm-dhcp-helper moved
to /usr/libexec/nm-dhcp-helper, but /etc/apparmor.d/sbin.dhclient from
isc-dhcp-client was not updated.

/etc/apparmor.d/sbin.dhclient still contains the old paths.


Please work together with the isc-dhcp-client maintainers to get this 
AppArmor config updated.

There is nothing that can be done in the network-manager package about this.



Shouldn't there be a "Breaks:" on isc-dhcp-client (<< 4.4.3-P1-4) in
order to ensure that the user also upgrades isc-dhcp-client or block
the upgrade until isc-dhcp-clients gets modified?


We could consider adding such a versioned Breaks, once a fixed version 
of isc-dhcp-client exists.


Given that network-manager by default no longer uses dhclient, and 
unversioned Breaks is not warranted.





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056320: RFS: mp3guessenc/0.27.6~beta+dfsg-1 -- Utility for analysis of audio mpeg files

2023-11-20 Thread Peter B


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : mp3guessenc
   Version  : 0.27.6~beta+dfsg-1
   Upstream contact : eblanc...@users.sourceforge.net
 * URL  : https://mp3guessenc.sourceforge.io/
 * License  : LGPL-2.1+, CC0-1.0
 * Vcs  : https://salsa.debian.org/debian/mp3guessenc
   Section  : sound

The source builds the following binary packages:

  mp3guessenc - Utility for analysis of audio mpeg files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/m/mp3guessenc/mp3guessenc_0.27.6~beta+dfsg-1.dsc

Changes since the last upload:

 mp3guessenc (0.27.6~beta+dfsg-1) unstable; urgency=medium
 .
   * New upstream version
  (updated ID3v1 detection routine)
   * Standards now 4.6.2

Regards,
--
  Peter Blackman

Bug#1055567: Error: gscan2pdf fails to compile

2023-11-20 Thread Soumyanath Chatterjee


On 20/11/23 17:03, Jeff wrote:

What about:

sudo ldconfig

cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf

If you start gscan2pdf as follows:

LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ gscan2pdf

?

Can you start xsane, simple-scan or scanimage ?



soumyanath@ganak-desktop:~$ sudo ldconfig
[sudo] password for soumyanath:
soumyanath@ganak-desktop:~$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
soumyanath@ganak-desktop:~$ LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ 
gscan2pdf


This one works.

Please suggest what changes I need to make to run it normally

Bug#1056315: texlive-latex-base: lualatex - zlib library version does not match


Control: reassign -1 texlive-binaries
Control: block -1 by 1056204
Control: severity -1 grave
Control: forcemerge -1 1056183

On 20.11.2023 14:18, Grégory Mounié wrote:

Hi,


When trying to compile a Latex file with lualatex, lualatex fails immediately
with the following messages:


Just bug handling. Bug is known and addressed already in latest upload.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056151: fai-client: Diversion makes /usr/sbin/init vanish in /usr-move conditions

2023-11-20 Thread Chris Hofstaedtler

Control: found -1 fai-client/6.0.5

* Thomas Lange  [231117 23:50]:
> > On Fri, 17 Nov 2023 20:54:29 +0100, Chris Hofstaedtler 
> >  said:
> 
> > Now a problem arises, when:
> > - I use a basefile tar.gz, made with an old systemd (say, it uses
> >   testing as of today)
> > - During baseupdate, systemd gets updated and moves its file (say, I'm
> >   actually installing unstable)
> Mmm, I do not know if it's possible to catch this.
> Using an old system which is then updated may always cause strange
> problems.

I came at it from another PoV: is this still needed? 

> Does this problem also arises when you use a basefile from unstable?
> This is the main question I have.

No, because then there is no systemd-sysv upgrade happening as part
of updatebase. But then updatebase is kinda supposed to handle
exactly such things, no?

> fai-client 5.11? I do not know this version. I guess it's some
> other version.

I can't say what the version we saw this originally really is, but
it reproduces on 6.0.5.  

Best,
Chris

Bug#1056319: RFP: avis-imgv -- Fast and Configurable Rust Image Viewer

2023-11-20 Thread Antoine Beaupre

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

* Package name: avis-imgv
  Version : No releases published
  Upstream Contact: https://github.com/hats-np
* URL : https://github.com/hats-np/avis-imgv
* License : GPL-3
  Programming Lang: Rust
  Description : Fast and Configurable Rust Image Viewer

avis-imgv is a fast, configurable and color managed image viewer built
with Rust and egui. My goal was for it to be fast and to be able to
adapt to any kind of hardware power through user configuration.

As of now it's only been tested in Linux, but I don't see why it
wouldn't work in Windows/macOS. Configuration and cache directories
are obtained through the directories crate which is platform-agnostic.



"I" in the above is not me, but the upstream author.

I'm always on the hunt for a good image viewer. I am particularly
interested in software that has the capability of showing multiple
images at once, and recursing into subdirectories.

This one is also one of the (currently) rare image viewers written in
a safe language (Rust), which I find particularly relevant given the
attack surface of image rendering in general.

Bug#1056318: bookworm-pu: package dhcpcd5/9.4.1-24~deb12u3

2023-11-20 Thread Martin-Éric Racine

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: dhcp...@packages.debian.org
Control: affects -1 + src:dhcpcd5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ Reason ]
As per bug #1053657, files moved between binary targets and between /lib and 
/usr/lib may cause problems when upgrading from Bullseye due to the 
introduction of usrmerge.

[ Impact ]
As per bug report, the issue is not trivially reproducible and probably does 
not affect the majority of users. However, given how moving files between /lib 
and /usr/lib was considered an RC issue during the transition to usrmerge, 
mitigation is desirable just to be safe.

[ Tests ]
Manual upgrade tested in chroot and confirmed to work as expected.

[ Risks ]
None.

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

[ Changes ]
1) Migrate Breaks/Replaces dhcpcd5 (<< 9.4.1-2) to Conflicts (Closes: #1053657).
2) Update dhcpcd.preinst version check for previous bookworm-pu fix.

[ Other info ]

diff -Nru dhcpcd5-9.4.1/debian/changelog dhcpcd5-9.4.1/debian/changelog
- --- dhcpcd5-9.4.1/debian/changelog2023-07-22 17:56:49.0 +0300
+++ dhcpcd5-9.4.1/debian/changelog  2023-10-20 11:12:13.0 +0300
@@ -1,3 +1,10 @@
+dhcpcd5 (9.4.1-24~deb12u3) bookworm; urgency=medium
+
+  * Move Breaks/Replaces dhcpcd5 (<< 9.4.1-2) to Conflicts (Closes: #1053657).
+  * Update dhcpcd.preinst version check.
+
+ -- Martin-Éric Racine   Fri, 20 Oct 2023 11:12:13 
+0300
+
 dhcpcd5 (9.4.1-24~deb12u2) bookworm; urgency=medium
 
   * Fixed dhcpcd.preinst with the tilde version.
diff -Nru dhcpcd5-9.4.1/debian/control dhcpcd5-9.4.1/debian/control
- --- dhcpcd5-9.4.1/debian/control  2023-05-28 05:57:38.0 +0300
+++ dhcpcd5-9.4.1/debian/control2023-10-20 11:11:34.0 +0300
@@ -14,8 +14,7 @@
 Package: dhcpcd-base
 Architecture: any
 Provides: dhcp-client
- -Replaces: dhcpcd5 (<< 9.4.1-2)
- -Breaks: dhcpcd5 (<< 9.4.1-2)
+Conflicts: dhcpcd5 (<< 9.4.1-2)
 Depends: adduser,
  ${misc:Depends},
  ${shlibs:Depends}
diff -Nru dhcpcd5-9.4.1/debian/dhcpcd.preinst 
dhcpcd5-9.4.1/debian/dhcpcd.preinst
- --- dhcpcd5-9.4.1/debian/dhcpcd.preinst   2023-07-22 17:56:40.0 
+0300
+++ dhcpcd5-9.4.1/debian/dhcpcd.preinst 2023-10-20 11:12:08.0 +0300
@@ -2,7 +2,7 @@
 # As per Debian bug #1037190.
 # Copyright 2023 Andreas Beckmann 
 set -e
- -if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24~deb12u2~" ; then
+if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24~deb12u3~" ; then
   # Cleanup leftovers from dhcpcd 1:3.* in Wheezy.
   # Can be removed after Trixie is released.
   update-alternatives --remove dhcpcd /sbin/dhcpcd3

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmVbgpUACgkQrh+Cd8S0
17bfkw/+NBPz3yOtdFHOzIDzD7DGvAQOFgtxJ2FDSu6nEvwTqc1Mlfv35x2Dqu/T
6Q9m9z2d655vuDkmVQIEbSFh5weATtCbpqLM29cZZFho5SUO7yHqB5vTqA4kQMJk
FD1FlkTjA0qFn/f8nkzCnljG2Vt3BQhLnoz70dzGV044ohKowm9q1sVXIgHADhxr
wL7mRCS3zTQe6SVvkLK9nUvmItCnn03/C3jadzZOVepowu6im5SnVULO/YFEelmA
JYsG9Oa9v0eeTv68BR0ybGG5kpVhGIF71BvELVJaZWu9VLfivXJwFug/mecq9nGO
AWqDL8bVyRfIPs8xpLXH7T5dWBVaMAA2UaYHPy4yZcFB1xwY+E01AGDTf8vFIOVP
mos75buvypjESkPetNeam1AleH2f2RM1t/mtusdJ3y3oFId5mg1S6tyEANws7VZM
TJwY7UFFA48z1Ua1/6AoFEjm0qu1eeKWEPc0hrL3L9MFZrmXTIp/mDTbjfN9vBG1
RvkxaWsBQQCoT/mLOKm68MWy7nCM9OXPJhZwBVceAQudtbIsNDcPmZM2OrmytKUw
n2Uuy+KS/Grb3seXkXjy0DWKheSaaFMrVlM3/rigWzSHxrhWfFuZ2sphiOybZbKW
zxNlwCG1fl3mWMspY8W4WTtVcSXIOaGmFT//3H2ZOg6KL31qJ/o=
=HavW
-END PGP SIGNATURE-

Bug#1051542: texlive-extra-utils: a5toa4 fails to generate pdf: No such file or directory

2023-11-20 Thread Pavel Sanda

On Sun, 10 Sep 2023 23:26:05 +0200 =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?= 
 wrote:
> > I got a response from Markus Kohm:
> > The problem is known, but he does not intent to fix it because he does
> > not have enough time.
> > He recommends pdfjam which can do the same task.
> > 
> > So I think a5toa4 should be removed.
> > 
> 
> Thanks for the effort!
> 
> I tag the bug wontfix, but I don't remove the package.

You can try proposed fix on your current setup.
https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg220760.html

I plan to push it into CTAN, so it will hopefully get fixed in trixie
(or bookworm if some cares to backport the fix).

Pavel

Bug#1056215: vulkan-tools: vulkaninfo tool can't be installed

2023-11-20 Thread Timo Aaltonen


Steven Friedrich kirjoitti 19.11.2023 klo 8.27:

Package: vulkan-tools
Severity: important

Dear Maintainer,

Vulcan Info Center missing vulkaninfo, apt can't find package.



But you managed to file a bug against vulkan-tools, which includes 
/usr/bin/vulkaninfo? So what's the problem?



--
t

Bug#1056317: libarchive-dev: missing dependencies on libarchive.pc's Libs.private packages

Package: libarchive-dev
Version: 3.6.2-1
Tags: patch

Dear Maintainer(s),

libarchive-dev ships libarchive.pc which contains:

 Libs.private: -lnettle -lacl -llzma -lzstd -llz4 -lbz2 -lz  -lxml2

In order to use this, for example when building certain configurations
of src:dpdk, the respective -dev packages need to be installed too.
Unfortunately the Debian build tools, unlike rpm, do not automatically
parse pkg-config files to generate the required dependencies.

Many -dev packages list these manually as a workaround. I have opened a
MR on Salsa to do the same on libarchive-dev:

https://salsa.debian.org/debian/libarchive/-/merge_requests/5

-- 
Kind regards,
Luca Boccassi


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

Bug#1056279: Looks like the systemctl links are gone but not the pm-utils ones

2023-11-20 Thread Helmut Grohne

Hi,

I've spend the better part of today on this thanks to Freexian.

On Mon, Nov 20, 2023 at 12:35:58AM +0100, Helmut Grohne wrote:
> Different reproducer:
> 
> mmdebstrap trixie /dev/null http://deb.debian.org/debian 
> --include=systemd-sysv,molly-guard --customize-hook='sed -i -e s/trixie/sid/ 
> $1/etc/apt/sources.list' --chrooted-customize-hook='apt-get update' 
> --customize-hook='test -e $1/lib/molly-guard/reboot' 
> --chrooted-customize-hook='apt-get -y install systemd-sysv' 
> --customize-hook='ls -l $1/lib/molly-guard/'

> I've dug into dpkg and usually when it moves a file from / to /usr,
> it'll first unpack the new file (unknowingly replacing the existing old
> one) and then removes the old one (via pkg_remove_old_files). During
> that removal, it has a check to see whether the file to be removed
> happens to match one of the files it just installed and skips the
> removal in that case. For some reason, this safety check does not work
> when the file is diverted.

I retried this a few times and still think it is correct. As a
consequence, the original approach of duplicating diversions cannot work
at all. As soon as we have two diversions whose targets equal up to
aliasing, we run into this problem and to make matters worse, we are
loosing a file that we just unpacked. We have no way of keeping (and
later restoring) it via any kind of maintainer scripts. Therefore we
really cannot do the duplicate diversion approach. It was a nice idea,
but doesn't work. Back to the drawing board.

We still must have two diversions to as unpacking either of the
locations from another package would clobber the location we want
diverted. What changes is that the diversion targets must differ in more
than aliasing.

I think an example would help. Say we divert /sbin/halt. We must divert
both /sbin/halt and /usr/sbin/halt or we risk clobbering our copy. If we
divert the latter to /usr/lib/molly-guard/halt, we must not divert the
former to /lib/molly-guard/halt or the file will be lost in unpack. So
the later might become /lib/molly-guard/halt.usr-is-merged or something.

This is fairly inconvenient as molly-guard doesn't know about
halt.usr-is-merged. I think there is three possible ways to deal with
this:
 a) molly-guard tries both locations.
 b) We add a dpkg-trigger on /sbin/halt such that when
/usr/lib/molly-guard/halt is missing but
/lib/molly-guard/halt.usr-is-merged is not, we can add a symlink.
 c) We give up on supporting /sbin/halt (as opposed to /usr/sbin/halt)
and simply declare Breaks against any provider of /sbin/halt.

I argue that we should be selecting that last option, because /sbin/halt
is something that we want to go away entirely. When we release trixie,
we want all of them moved to /usr/sbin/halt. So we'd have versioned
Breaks for systemd-sysv, sysvinit-core, runit-init and finit-sysv. Note
that since Breaks does not prevent concurrent unpack, we must still
install the extra diversion. Note that since the other package must
declare Conflicts with molly-guard, molly-guard cannot use Conflicts
without impacting upgrades. The mutual conflict would require apt to
temporarily remove molly-guard (or /sbin/init!) and that is known to
impact upgrades.  Also note that since sysvinit-core and others have not
yet moved, molly-guard must now declare unversioned Breaks for all of
them for as long as they have not moved and once they moved, it can add
a version to the Breaks.

So I went ahead an implemented this. Since I didn't want to fall into my
trap of too little testing again, I wrote some test cases (attached) and
to my surprise found another problem!

/sbin/halt actually is a symbolic link to /bin/systemctl. In 255,
/usr/sbin/halt becomes a symlink to ../bin/systemctl. Observe how we
turned an absolute symlink into a relative once since we no longer
cross a toplevel directory in line with policy. As we move this relative
symlink to /usr/lib/molly-guard, it becomes a broken symbolic link. So
if you now install molly-guard and systemd-sysv in unstable, these links
are gone. You may then reinstall systemd-sysv and see them reinstated.
And now they're broken.

There is no easy way to fix this beyond moving these programs to a
different name in the same directory. I suggest
/usr/sbin/halt.no-molly-guard. Appending a suffix is what most
diversions do and this avoids breaking symlinks.

I've attached the prospective change to this mail. It passes piuparts
and it passes my own test cases. I definitely think it should be
reviewed before uploaded. One thing I already see for possible
improvement is that since we declare Breaks against all providers of
/sbin/halt, this diversion does not actually have to persist beyond
postinst. Once molly-guard is configured, we know that any broken
package is no longer installed nor unpacked. A molly-guard.postinst
could remove the diversion of /sbin/halt to
/sbin/halt.no-molly-guard.usr-is-merged. Then we are only left with one
diversion per command which also

Bug#1056316: firefox: please add gles support for riscv64

2023-11-20 Thread Bo YU

Source: firefox
Severity: wishlist
Tags: patch
Version: 119.0.1-1
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Hi,

Now for some riscv64 real hardware, like licheepi4a/versionfive2(vf2),
there is only gles support for display. So if we use firefox on these
hardwares, we can not use hardware webrender only software webrender
works.

I just built firefox based on 119.0.1-1 with gles support then can use
hardware webrender on licheepi4a.

In the meantime, I've sent this report upstream also. see:
https://bugzilla.mozilla.org/show_bug.cgi?id=1865601

If upstream takes too long time to response with it, hoping the support
can be uploaded on the next upload so that to improve the the user 
experience on firefox for riscv64 platform.

Please let me know any issues, thanks.

-- 
Regards,
--
  Bo YU

Description: add gles support for riscv64
 Now on some riscv64 hardware like vf2/licheepi4a only has gles support.
Author: BO YU 
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1865601 
Last-Update: 2023-11-18
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/toolkit/xre/glxtest/glxtest.cpp
+++ b/toolkit/xre/glxtest/glxtest.cpp
@@ -435,7 +435,7 @@
   PFNGLGETSTRING glGetString =
   cast(eglGetProcAddress("glGetString"));
 
-#if defined(__arm__) || defined(__aarch64__)
+#if defined(__arm__) || defined(__aarch64__) || defined(__riscv) && __riscv_xlen == 64
   bool useGles = true;
 #else
   bool useGles = false;


signature.asc
Description: PGP signature

Bug#1056314: Acknowledgement (python3: double free when using PageUp in REPL)

2023-11-20 Thread Val Lorentz


reassign 1056314 readline 8.2-1.3
retitle 1056314 readline: double free when using PageDown

the same input causes bash to crash in the same way (see attachment), so 
I assume this is a bug in readline rather than Python
gdb bash
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bash...
(No debugging symbols found in bash)
(gdb) run
Starting program: /usr/bin/bash 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 809178]
val@particle:~$ 2+2
[Detaching after fork from child process 809179]
bash: 2+2 : commande introuvable
val@particle:~$ 1234+5678
[Detaching after fork from child process 809184]
bash: 1234+5678 : commande introuvable
val@particle:~$ 2+2
[Detaching after fork from child process 809217]
bash: 2+2 : commande introuvable
val@particle:~$ 1000+5678
free(): double free detected in tcache 2

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: Aucun fichier ou dossier de ce type.
(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x77e07d9f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x77db8f32 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x77da3472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x77dfc340 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x77f16459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5  0x77e116ba in malloc_printerr (str=str@entry=0x77f19098 
"free(): double free detected in tcache 2") at ./malloc/malloc.c:5660
#6  0x77e13946 in _int_free (av=0x77f4fc60 , 
p=0x556ccb00, have_lock=have_lock@entry=0) at ./malloc/malloc.c:4469
#7  0x77e15d9f in __GI___libc_free (mem=) at 
./malloc/malloc.c:3385
#8  0x55635ce5 in rl_do_undo ()
#9  0x556360b5 in rl_revert_line ()
#10 0x5561986d in readline_internal_teardown ()
#11 0x5561ac7c in readline ()
#12 0x55586fe2 in ?? ()
#13 0x55589ae1 in ?? ()
#14 0x5558bf5b in ?? ()
#15 0x555900bb in yyparse ()
#16 0x555865b6 in parse_command ()
#17 0x55586744 in read_command ()
#18 0x555868f6 in reader_loop ()
#19 0x555853d9 in main ()


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056312: zlib1g makes tex-common fail to install due to fmtutil failing

2023-11-20 Thread Hilmar Preusse

Package: zlib1g
Version: 1:1.3.dfsg-2
Followup-For: Bug #1056312
X-Debbugs-Cc: debian-tex-ma...@lists.debian.org

Hello Mark,

In 1:1.2.6.dfsg-2 an "Breaks: ... texlive-binaries (<< 2009-12)" statement
was introduced to make sure the broken tl-bin packages are phased out.
We now need the same again: 2023.20230311.66589-7 is the last broken version;
2023.20230311.66589-8 contains the fix and has been uploaded this morning.

Please bump the version in that breaks statement!

Many thanks!

-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

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

Versions of packages zlib1g depends on:
ii  libc6  2.36-9+rpt2+deb12u3

zlib1g recommends no packages.

zlib1g suggests no packages.

-- no debconf information

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1050854: xarray test failure on amd64

2023-11-20 Thread Andreas Tille

Hi Rebecca,

Am Sun, Nov 19, 2023 at 09:58:26PM + schrieb Rebecca N. Palmer:
> This bug is now a crash (not the original error message):
> https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-xarray/39962554/log.gz
> I don't know whether the same patch still works.
> 
> The Salsa repository now appears to be up to date.

I've pushed a candidate for the next upstream version.
 
> You probably also want to include the fixes for the other two RC bugs (see
> there).

I guess you might specifically think of bug #1053700 where you provided
the idea for a patch.  I would be extremely grateful if you could commit
your patch right to the Git repository.  You obviously inspected the
code while I never ever touched xarray code before.  I simply stumbled
upon it due to a testing removal warning and I'm pretty loaded with
other stuff.

Thanks a lot
Andreas. 

-- 
http://fam-tille.de

Bug#1051243: tex-common: fmtutil failed on tex-common upgrade

2023-11-20 Thread Gunnar Hjalmarsson


X-Debbugs-Cc: debian-input-met...@lists.debian.org

On 2023-11-18 21:20, Gunnar Hjalmarsson wrote:
This problem prevents the ibus-table package, where tex-common is 
indirectly in Build-Depends, from building in unstable.


https://buildd.debian.org/status/logs.php?pkg=ibus-table=1.17.4-2=all


FTR I can confirm that the latest version of texlive-bin fixed that 
problem, and ibus-table has been successfully built now.


--
Gunnar

Bug#1056151: fai-client: Diversion makes /usr/sbin/init vanish in /usr-move conditions

2023-11-20 Thread Michael Prokop

* Chris Hofstaedtler [Fri Nov 17, 2023 at 08:54:29PM +0100]:
>
> you will have noticed that systemd 255 moves its files from / to /usr.
> This includes /sbin/init.
> 
> Now a problem arises, when:
> - I use a basefile tar.gz, made with an old systemd (say, it uses
>   testing as of today)
> - During baseupdate, systemd gets updated and moves its file (say, I'm
>   actually installing unstable)
> 
> What happens is this:
> - base image gets unpacked, /sbin is a symlink to /usr/sbin,
>   /sbin/init is actually /usr/sbin/init
> - baseupdate diverts /sbin/init to /sbin/init.distrib (and using
>   symlinks, /usr/sbin/init became /usr/sbin/init.distrib)
> - baseupdate updates systemd, dpkg 'moves' /sbin/init to /usr/sbin/init,
>   but the divert stays in place for /sbin/init.
>   At this time, dpkg will have overwritten /usr/sbin/init with the new
>   file(!)
> - fai-divert -R runs, removes /sbin/init, and removes the divert of
>   /sbin/init.
>   But: at this point /sbin/init was already the new /usr/sbin/init,
>   which is now lost.
> 
> As a result /usr/sbin/init is missing, and the system does not boot.
> 
> I would suggest dropping all the fai-divert calls in baseupdate.

Thanks for the great analysis, Chris.

It seems that
https://github.com/faiproject/fai/commit/7294b415ab2982f84b293900a9610eab49184201
works around the issue, at least for my use case (though the commit
message sadly isn't really verbose and doesn't say what the
underlying reason for the change was).

The change didn't make it into any fai release yet, though.

regards
-mika-


signature.asc
Description: PGP signature

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

2023-11-20 Thread Andreas Tille

Hi Graham,

Am Mon, Nov 20, 2023 at 12:21:39PM -0100 schrieb Graham Inggs:
> For the r-cran-tmb upload, I now see only autopkgtest regressions [1] for:
> r-cran-insight/0.19.6+dfsg-1
> r-cran-parameters/0.21.2-1
> I have not investigated, but these seem to be passing in unstable, so
> can be hinted if needed.

OK, let me know if I should do something.
 
> For the r-cran-irlba upload, there's only one autopkgtest regression [2] for:
> r-cran-seurat/4.4.0-1
> This autopkgtest currently fails in unstable as well, would you please
> investigate?

By chance I tried to upgrade r-cran-seurat a couple of hours ago since
there is a new upstream version (which follows r-cran-seuratobject
version bump).  Unfortunately it needs a new dependency which I pushed
to new[5].  Since I have no idea what the failures in r-cran-seurat test
log[6] mean I would prefer to wait until we can upload the latest
version.

> It seems your r-cran-seuratobject 5.0.0-1 upload is blocked by this
> same regression for 19 days [3] and r-cran-seurat has not yet been
> updated to the new upstream version 5.0.1.  Does something prevent you
> from updating?

See above.
 
> For the r-cran-openmx upload, there are no autopkgtest regressions [4]
> \o/

Nice.
 
> > I've reverted this but in previous discussion[4] with Paul we agreed
> > upon the strict version dependency.  I think this is only necessary for
> > r-cran-tmb (where upstream is enforcing this with a test I'm hesitating
> > to patch out).  But maybe upstream can work with the freshly implemented
> > R_MATRIX_ABI_VERSION and thus we can come back to upstream if the
> > autopkgtest will fire next time (which will happen now after the next
> > r-cran-matrix update).
> 
> Thanks again.  Yes, let's wait to see how TMB upstream deals with this.

Kind regards and thank you for your work in release team
   Andreas.
 
> [1] https://qa.debian.org/excuses.php?package=r-cran-tmb
> [2] https://qa.debian.org/excuses.php?package=r-cran-irlba
> [3] https://qa.debian.org/excuses.php?package=r-cran-seuratobject
> [4] https://qa.debian.org/excuses.php?package=r-cran-openmx


[5] https://ftp-master.debian.org/new/r-cran-fastdummies_1.7.3-1.html
[6] https://ci.debian.net/packages/r/r-cran-seurat/unstable/amd64/40043272/

-- 
http://fam-tille.de

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

2023-11-20 Thread Dirk Eddelbuettel



Hi Graham,

On 20 November 2023 at 12:13, Graham Inggs wrote:
| On Sun, 19 Nov 2023 at 14:59, Dirk Eddelbuettel  wrote:
| > So it contains a patch by Mikael which had been applied _permitting Matrix
| > 1.6-2_ to get to CRAN. So for this particular pair it was the other way 
around.
| 
| Great, thanks for clearing that up.
| 
| > So I leave this in your hands. If you think that after all this needs a
| > transtion, I may shrug but will of course help.
| 
| Well, we are doing a transition (for some value of), just not a
| "rebuild everything" transition like we must do for C libraries, but a
| "rebuild only affected things" like we do for Python and other
| interpreted languages.
| 
| On Sun, 19 Nov 2023 at 17:28, Dirk Eddelbuettel  wrote:
| > Done in lme4 1.1-35.1-3.
| 
| Thanks.  I see now r-cran-lme4 now has a:
| Depends: r-cran-matrix (>= 1.6-2)
| ...however this is not correct, because dpkg considers r-cran-matrix
| 1.6-1.1-1 in testing to meet that requirement, and the tests still
| fail with that version.
| 
| $ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2 && echo True
| True
| 
| Please change that to:
| Depends: r-cran-matrix (>= 1.6-2-1)
| ... and re-upload, because dpkg considers 1.6-2 to be upstream version
| 1.6 and Debian revision 2, whereas we need upstream version 1.6-2 and
| Debian revision 1.
| 
| $ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2-1 && echo True
| 

Dang. Fell into a well-known hole there.  Will fix ASAP. Had in the back of
my mind some notion of 'cannot express Debian build number' but that is
clearly wrong.

Dirk

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

Bug#1056315: texlive-latex-base: lualatex - zlib library version does not match

2023-11-20 Thread Grégory Mounié

Package: texlive-latex-base
Version: 2023.20231007-1
Severity: normal

Dear Maintainer,

When trying to compile a Latex file with lualatex, lualatex fails immediately
with the following messages:

"""
> lualatex toto.tex
PANIC: unprotected error in call to Lua API (zlib library version does not
match - header: 1.2.13, library: 1.3)
zsh: IOT instruction (core dumped)  lualatex toto.tex
"""

zlib1g is indeed at the version 1.3 in sid.
(zlib1g is at 1.2.13 in testing/stable)



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-rw-r-- 1 root staff 80 Apr  8  2020 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 3471 Nov 20 10:35 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 12  2022 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Oct  8 22:00 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Oct  8 22:00 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Oct 13  2022 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Oct  8 22:00 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Oct  8 22:00 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3430 Nov 10 10:00 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Sep  4  2021 mktex.cnf
-rw-r--r-- 1 root root 475 Oct 13  2022 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

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

Versions of packages texlive-latex-base depends on:
ii  fonts-lmodern 2.005-1
ii  tex-common6.18
ii  texlive-base  2023.20231007-1
ii  texlive-binaries  2023.20230311.66589-7

texlive-latex-base recommends no packages.

Versions of packages texlive-latex-base suggests:
ii  texlive-latex-base-doc  2023.20231007-1
ii  wp2latex4.3+ds-2

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.8

Versions of packages texlive-latex-base is related to:
ii  tex-common6.18
ii  texlive-binaries  2023.20230311.66589-7

-- no debconf information

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

Hi Andreas

On Mon, 20 Nov 2023 at 06:59, Andreas Tille  wrote:
> > We liked the change you made to r-cran-tmb [2], as this allows the
> > affected packages to be binNMU'd and gain a versioned dependency on
> > r-cran-matrix.  Would you please apply this to the other affected
> > packages (only r-cran-irlba and r-cran-openmx, if I understand
> > correctly)?
>
> Done.

Thanks!

For the r-cran-tmb upload, I now see only autopkgtest regressions [1] for:
r-cran-insight/0.19.6+dfsg-1
r-cran-parameters/0.21.2-1
I have not investigated, but these seem to be passing in unstable, so
can be hinted if needed.

For the r-cran-irlba upload, there's only one autopkgtest regression [2] for:
r-cran-seurat/4.4.0-1
This autopkgtest currently fails in unstable as well, would you please
investigate?
It seems your r-cran-seuratobject 5.0.0-1 upload is blocked by this
same regression for 19 days [3] and r-cran-seurat has not yet been
updated to the new upstream version 5.0.1.  Does something prevent you
from updating?

For the r-cran-openmx upload, there are no autopkgtest regressions [4]
\o/

> I've reverted this but in previous discussion[4] with Paul we agreed
> upon the strict version dependency.  I think this is only necessary for
> r-cran-tmb (where upstream is enforcing this with a test I'm hesitating
> to patch out).  But maybe upstream can work with the freshly implemented
> R_MATRIX_ABI_VERSION and thus we can come back to upstream if the
> autopkgtest will fire next time (which will happen now after the next
> r-cran-matrix update).

Thanks again.  Yes, let's wait to see how TMB upstream deals with this.

Regards
Graham

[1] https://qa.debian.org/excuses.php?package=r-cran-tmb
[2] https://qa.debian.org/excuses.php?package=r-cran-irlba
[3] https://qa.debian.org/excuses.php?package=r-cran-seuratobject
[4] https://qa.debian.org/excuses.php?package=r-cran-openmx

Bug#1056314: python3: double free when using PageUp in REPL

2023-11-20 Thread Val Lorentz


Package: python3
Version: 3.11.2-1

Dear maintainers,

I am getting a crash in the Python REPL in this scenario:

1. start "python3" in a terminal
2. type "2+2", enter
3. type (or copy-paste) "1234+5678", enter
4. arrow-up, remove "234", page-down, arrow-up, enter
5. arrow-up, arrow-up, add "000" (or whatever) after the 1, enter.

this results in:

free(): double free detected in tcache 2
 [1]2319820 IOT instruction  python3


gdb log and stack trace attached.


gdb python3
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...
Reading symbols from 
/usr/lib/debug/.build-id/ac/175ec7666754cf818b271b4fdc2761ac6865f2.debug...
(gdb) run
Starting program: /usr/bin/python3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2+2
4
>>> 1234+5678
6912
>>> 2+2
4
>>> 1000+5678
free(): double free detected in tcache 2

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: Aucun fichier ou dossier de ce type.
(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x77d11d9f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x77cc2f32 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x77cad472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x77d06340 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x77e20459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5  0x77d1b6ba in malloc_printerr (str=str@entry=0x77e23098 
"free(): double free detected in tcache 2") at ./malloc/malloc.c:5660
#6  0x77d1d946 in _int_free (av=0x77e59c60 , 
p=0xe8e620, have_lock=have_lock@entry=0) at ./malloc/malloc.c:4469
#7  0x77d1fd9f in __GI___libc_free (mem=) at 
./malloc/malloc.c:3385
#8  0x776ab7cf in rl_do_undo () from 
/lib/x86_64-linux-gnu/libreadline.so.8
#9  0x776ab995 in rl_revert_line () from 
/lib/x86_64-linux-gnu/libreadline.so.8
#10 0x7768ef3d in readline_internal_teardown () from 
/lib/x86_64-linux-gnu/libreadline.so.8
#11 0x776ad432 in rl_callback_read_char () from 
/lib/x86_64-linux-gnu/libreadline.so.8
#12 0x77b1df18 in readline_until_enter_or_signal (signal=, prompt=) at ./Modules/readline.c:1352
#13 call_readline (sys_stdin=, sys_stdout=, 
prompt=) at ./Modules/readline.c:1398
#14 0x004748e0 in PyOS_Readline (sys_stdin=0x77e59a80 
<_IO_2_1_stdin_>, sys_stdout=0x77e5a760 <_IO_2_1_stdout_>, 
prompt=0x777a7ba0 ">>> ") at ../Parser/myreadline.c:392
#15 0x00538e87 in tok_underflow_interactive (tok=0xe8e740) at 
../Parser/tokenizer.c:880
#16 tok_nextc (tok=0xe8e740) at ../Parser/tokenizer.c:1064
#17 0x00529c76 in tok_get (tok=0xe8e740, p_start=0x7fffdc98, 
p_end=0x7fffdc90) at ../Parser/tokenizer.c:1419
#18 0x00527ee6 in _PyTokenizer_Get (p_end=0x7fffdc90, 
p_start=0x7fffdc98, tok=0xe8e740) at ../Parser/tokenizer.c:2121
#19 _PyPegen_fill_token (p=p@entry=0x77c20490) at ../Parser/pegen.c:213
#20 0x00633358 in statement_newline_rule (p=0x77c20490) at 
../Parser/parser.c:1407
#21 interactive_rule (p=0x77c20490) at ../Parser/parser.c:1108
#22 _PyPegen_parse (p=p@entry=0x77c20490) at ../Parser/parser.c:38924
#23 0x00632dfc in _PyPegen_run_parser (p=0x77c20490) at 
../Parser/pegen.c:837
#24 0x006510f7 in _PyPegen_run_parser_from_file_pointer 
(arena=0x77ba1bf0, errcode=0x7fffddfc, flags=0x7fffdf30, 
ps2=, ps1=0x777a7ba0 ">>> ", enc=0x77c79d60 "utf-8", 
filename_ob=, start_rule=256, fp=) at 
../Parser/pegen.c:910
#25 _PyParser_ASTFromFile (fp=, filename_ob=, 
enc=0x77c79d60 "utf-8", mode=256, ps1=0x777a7ba0 ">>> ", ps2=, flags=0x7fffdf30, errcode=0x7fffddfc, 
arena=0x77ba1bf0) at ../Parser/peg_api.c:26
#26 0x00483248 in PyRun_InteractiveOneObjectEx 
(fp=fp@entry=0x77e59a80 <_IO_2_1_stdin_>,

Bug#1036644:

2023-11-20 Thread Hutchinson,James

Apologies - had meant to report back on this thread as I found a workaround 
(for my setup at least).

I found the solution here:
https://wiki.archlinux.org/title/Intel_graphics#Crash/freeze_on_low_power_Intel_CPUs

After setting enable_dc=0 in my kernel boot parameters I have no longer 
experienced the issue on LTS 6.1.x kernel on my Intel NUC 8i3BEH running Arch 
linux.

I also tried upgrading to kernel 6.4.x where the problem also seems to be 
resolved.

Regards,

James.

On Fri, 18 Aug 2023 20:08:09 +0100 James Hutchinson 
 wrote:
> I am also affected by this, running Arch Linux on my Intel Nuc 8i3beh. I've
> seen these same random mce broadcast error kernel panics (only capturable
> via netconsole) ever since upgrading from the 5.15.x lts kernel series to
> the 6.1.x series - latest I've tried is 6.1.45 and currently back to the
> 5.15.x branch for stability.
>
> I update my Arch Linux installation on a rolling weekly basis so am right
> upto date for all packages including intel-microcode. As others have
> experienced, the problem seems more prominent (though not exclusively) when
> the machine is Idle.
>
> >>Maybe lowering "check_interval" or "monarch_timeout" in machinecheck will
> cause the bug to strike more often, so a git bisect could be possible!? Or
> raising those values may workaround the problem!?
>
> I had similar thoughts and stumbled upon
>
> /sys/kernel/debug/mce/fake_panic
>
> Writing 1 to here will cause a fake panic such that the mce event will be
> logged to dmesg but panic+reboot will not occur.
>
> Interestingly we then get a couple more messages that possibly suggest that
> the core lockup is somehow related to i915 as others suspect
>
> [5.848032] mce: CPUs not responding to MCE broadcast (may include false
> positives): 1,3
> [5.848032] mce: CPUs not responding to MCE broadcast (may include false
> positives): 1,3
> [5.848035] mce: [Hardware Error]: Fake kernel panic: Timeout: Not all
> CPUs entered broadcast exception handler
> [5.848039] Disabling lock debugging due to kernel taint
> [5.885355] mce: [Hardware Error]: Machine check events logged
> [5.888283] mce: [Hardware Error]: CPU 2: Machine Check Exception: 5
> Bank 4: ba0011000402
> [5.892145] mce: [Hardware Error]: RIP !INEXACT! 10:
> {fwtable_read32+0x7d/0x220 [i915]}
> [5.897167] mce: [Hardware Error]: TSC d44e32bae41d
> Might be interesting to see if the
> RIP !INEXACT! 10: {fwtable_read32+0x7d/0x220 [i915]}
>  message occurs for others with fake_panic enabled.
>
> Unfortunately, fake_panic does not appear to be a workaround from my
> experience; since the cores reported in the mce event become locked up
> thereafter; such that any task scheduled onto those cores becomes locked-up
> - for example I ran the sensors command which hung and eventually.
>
> 77798.629123] watchdog: BUG: soft lockup - CPU#2 stuck for 21s!
> [sensors:1229265]
> [77798.631037] Modules linked in: coretemp drivetemp netconsole
> xt_conntrack ipt_REJECT nf_reject_ipv4 xt_connmark xt_mark iptable_mangle
> xt_comment xt_addrtype iptable_raw wireguard curve25519_x86_64
> libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libcurve25519_generic
> libchacha ip6_udp_tunnel udp_tunnel rfcomm uinput xt_nat xt_tcpudp
> iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
> libcrc32c iptable_filter veth ts2020 snd_sof_pci_intel_cnl
> snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation
> soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof
> snd_sof_utils soundwire_bus snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core
> intel_rapl_msr intel_rapl_common snd_soc_sst_ipc intel_tcc_cooling

Bug#1055922: rmatrix: ABI change in Matrix 1.6-2

Hi Dirk

On Sun, 19 Nov 2023 at 14:59, Dirk Eddelbuettel  wrote:
> So it contains a patch by Mikael which had been applied _permitting Matrix
> 1.6-2_ to get to CRAN. So for this particular pair it was the other way 
> around.

Great, thanks for clearing that up.

> So I leave this in your hands. If you think that after all this needs a
> transtion, I may shrug but will of course help.

Well, we are doing a transition (for some value of), just not a
"rebuild everything" transition like we must do for C libraries, but a
"rebuild only affected things" like we do for Python and other
interpreted languages.

On Sun, 19 Nov 2023 at 17:28, Dirk Eddelbuettel  wrote:
> Done in lme4 1.1-35.1-3.

Thanks.  I see now r-cran-lme4 now has a:
Depends: r-cran-matrix (>= 1.6-2)
...however this is not correct, because dpkg considers r-cran-matrix
1.6-1.1-1 in testing to meet that requirement, and the tests still
fail with that version.

$ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2 && echo True
True

Please change that to:
Depends: r-cran-matrix (>= 1.6-2-1)
... and re-upload, because dpkg considers 1.6-2 to be upstream version
1.6 and Debian revision 2, whereas we need upstream version 1.6-2 and
Debian revision 1.

$ dpkg --compare-versions 1.6-1.1-1 ge 1.6-2-1 && echo True

Regards
Graham

Bug#1055498: greenlet needs an update to 3.x to support Python 3.12

2023-11-20 Thread Thomas Goirand


Hi,

I need this fix too, to be able to test the fixes for Eventlet. FYI, if 
this can help, the pull request added Py 3.12 support is here:


https://github.com/python-greenlet/greenlet/pull/327

Cheers,

Thomas Goirand (zigo)

Bug#1056298: riseup-vpn dns configuration don't work with systemd-resolved

2023-11-20 Thread Pirate Praveen


On 20/11/23 5:33 PM, Nilesh Patra wrote:

I need something that I could reproduce to be able to further check.


looks like none of the servers at https://servers.opennic.org/ that 
advertise DoT support works


though https://servers.opennic.org/edit.php?srv=ns5.id.dns.opennic.glue 
was working with Android Private DNS setting. So probably a bug with 
systemd-resolved.

Bug#1051243: This affects the build of the pspp package


On 20.11.2023 13:11, Luca Boccassi wrote:

Hi,


This looks like an undeclared versioning dependency issue. If there are
such constraints, please consider declaring them appropriately in the
package control file by defining a dependency on the exact upstream
version of zlib (e.g.: >= 1.3~ and << 1.3.1 or something like that).
Then every new upstream revision of zlib need to be handled as a sort-
of soname transition for tex-common.



Currently it is rather an overdone version check in the source code. In 
rev -8 we have untighten that check. Further a simple rebuild would have 
solved the issue too.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056313: network-manager: breaks networking

On 2023-11-20 12:24:36 +0100, Vincent Lefevre wrote:
> Note: the errors about /usr/libexec/nm-dhcp-helper changed to
> 
> Nov 20 12:17:42 cventin dhclient[295468]: execve 
> (/usr/libexec/nm-dhcp-helper, ...): No such file or directory
> 
> but the network is working. I don't whether this is related, though.

Forget about the "No such file or directory" error. This was the
first time I got it, and I suspect that it is due to the downgrade of
network-manager (something normally not supported), e.g. the running
dhclient was still expecting the new paths, which disappeared with
the downgrade.

So, the only issue seems the "Permission denied" with the new
network-manager versions due to the change of the paths done for

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

   * Install helper binaries into /usr/libexec (Closes: #1026388)

and the fact that /etc/apparmor.d/sbin.dhclient from
isc-dhcp-client 4.4.3-P1-4 still has the old paths.

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

Bug#1056299: ITP: gaphor -- a simple UML/SysML modeling tool

2023-11-20 Thread Zebediah Beck

May I ask what is the bug in question in relation to this tool? It sounds
like a powerful tool as UML is one of the best weapons software engineers
have against bugs!?

On Mon, 20 Nov 2023, 09:45 Alexandre Esse, 
wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Alexandre Esse 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: gaphor
>   Version : 2.21.0
>   Upstream Contact: Arjan Molenaar 
> * URL : https://github.com/gaphor/gaphor
> * License : Apache-2.0
>   Programming Lang: Python
>   Description : a simple UML/SysML modeling tool
>
> Gaphor is a UML and SysML modeling application written in Python. It is
> designed to be easy to use, while still being powerful. Gaphor implements a
> fully-compliant UML 2 data model, so it is much more than a picture drawing
> tool.
>
> The package should probably be maintained as part of the Debian Python
> Team:
> https://wiki.debian.org/Teams/PythonTeam
>
>

Bug#1026388: [Pkg-utopia-maintainers] Bug#1026388: network-manager: Please use upstream default paths for NM libexec binaries in /usr/libexec

On 2022-12-19 17:52:30 +0100, Michael Biebl wrote:
> Am 19.12.22 um 15:44 schrieb Neal Gompa:
> 
> > It does, though if all these packages are group-maintained by Utopia,
> > wouldn't it be possible to do the path migration for Bookworm through
> > NMUs?
> 
> They aren't unfortunately. Only three of the above 10 VPN plugins are
> maintained within the utopia. Otherwise I agree it would have been rather
> easy.

The VPN plugins were not the only things affected by this change.
/etc/apparmor.d/sbin.dhclient from isc-dhcp-client 4.4.3-P1-4
(currently in unstable) still contains the old paths.

This may be the cause of bug 1056313:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056313

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

Bug#1056313: network-manager: breaks networking

On 2023-11-20 12:42:14 +0100, Vincent Lefevre wrote:
> I suspect that nm-dhcp-helper has been added because it is now needed.
> But it doesn't work due to the "Permission denied".

If I understand correctly, /usr/lib/NetworkManager/nm-dhcp-helper moved
to /usr/libexec/nm-dhcp-helper, but /etc/apparmor.d/sbin.dhclient from
isc-dhcp-client was not updated.

/etc/apparmor.d/sbin.dhclient still contains the old paths.

Shouldn't there be a "Breaks:" on isc-dhcp-client (<< 4.4.3-P1-4) in
order to ensure that the user also upgrades isc-dhcp-client or block
the upgrade until isc-dhcp-clients gets modified?

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

Bug#993308: firefox-esr: You might need to add a libpci3 dependency to ESR 91

2023-11-20 Thread Osamu Aoki

Package: firefox-esr
Version: 115.4.0esr-1~deb12u1

Hi,

I installed firefox-esr to default LXD Debian 12 bookworm cloud image run as
container via APT.

This system has just firefox-esr and no GUI desktop.  Wayland on the host system
(GNOME Wayland bookworm) is used to display graphics.

Starting firefox-esr in this system without libpci3 in this container works with
following warning displayed on console but firefox is working and I can see web
pages with it.

```

osamu@wayland:~$ firefox   
[GFX1-]: glxtest: libpci missing
```

Once I installed libpci3, the above warning is gone.

So the appropriate dependency for this package is adding "Recommends: libpci3"


Normal Debian system usually have `pciutils` package (priority=standard) and it
pulls in `libpci3`.  Since I was using container, I could get real minimal
system without `libpci3`. 

Osamu

Bug#810018: New Essential package procps-base

2023-11-20 Thread Marco d'Itri

On Nov 20, Craig Small  wrote:

> Also why is killall5 not a candidate too?
Probably because it makes no sense outside of sysvinit, except that as 
a footgun.
(Also, is it equivalent to pkill --inverse?)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1051243: This affects the build of the pspp package

On Mon, 20 Nov 2023 12:50:24 +0100 =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=
 wrote:
> On 20.11.2023 10:43, Friedrich Beckmann wrote:
> 
> Hi,
> 
> > i noticed a failure in our CI pipeline for pspp probably due to
this bug. The problem occurs when I try to install "apt install
texlive-plain-generic“. The install fails with
> > 
> 
> A new package is on the way. Another adaption to zlib is needed, I'll
> trigger that later on.

PANIC: unprotected error in call to Lua API (zlib library version does
not match - header: 1.2.13, library: 1.3)

This looks like an undeclared versioning dependency issue. If there are
such constraints, please consider declaring them appropriately in the
package control file by defining a dependency on the exact upstream
version of zlib (e.g.: >= 1.3~ and << 1.3.1 or something like that).
Then every new upstream revision of zlib need to be handled as a sort-
of soname transition for tex-common.

-- 
Kind regards,
Luca Boccassi

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

Bug#1056312: zlib1g makes tex-common fail to install due to fmtutil failing

On Mon, 20 Nov 2023 11:57:20 + Luca Boccassi 
wrote:
> Control: found -1 1:1.3.dfsg-1
> 
> On Mon, 20 Nov 2023 12:20:55 +0100 Johannes Schauer Marin Rodrigues
>  wrote:
> > Package: zlib1g
> > Version: 1:1.3.dfsg-2
> > Severity: serious
> > 
> > Hi,
> > 
> > I didn't investigate this further yet but filing this as RC as it
is
> easy to
> > reproduce and it's easy to find out that only zlib1g changed using
> debbisect.
> > Downgrading to zlib1g 1:1.2.13.dfsg-3 makes the problem go away.
> Steps to
> > reproduce:
> > 
> > $ mmdebstrap --include=tex-common,texlive-base unstable /dev/null
> > Processing triggers for tex-common (6.18) ...
> > Running updmap-sys. This may take some time... done.
> > Running mktexlsr /var/lib/texmf ... done.
> > Building format(s) --all.
> >   This may take some time... 
> > fmtutil failed. Output has been stored in
> > /tmp/fmtutil.tcAsaQVq
> > Please include this file if you report a bug.
> > 
> > dpkg: error processing package tex-common (--configure):
> >  installed tex-common package post-installation script subprocess
> returned error exit status 1
> > Errors were encountered while processing:
> >  tex-common
> > E: Sub-process env returned an error code (1)
> 
> Looks like this was introduced by 1:1.3.dfsg-1, as it can be
reproduced
> in a minimal sid chroot by installing it from
>
https://snapshot.debian.org/archive/debian/20231118T151103Z/pool/main/z/zlib/zlib1g_1.3.dfsg-1_amd64.deb
> and then installing texlive-base:
> 
> <...>
> Processing triggers for tex-common (6.18) ...
> Running updmap-sys. This may take some time... done.
> Running mktexlsr /var/lib/texmf ... done.
> Building format(s) --all.
>   This may take some time... 
> fmtutil failed. Output has been stored in
> /tmp/fmtutil.ohLhbhu3
> Please include this file if you report a bug.
> 
> dpkg: error processing package tex-common (--configure):
>  installed tex-common package post-installation script subprocess
returned error exit status 1
> Errors were encountered while processing:
>  tex-common
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> # dpkg -l | grep zlib
> ii  zlib1g:amd64 1:1.3.dfsg-1  
amd64    compression library - runtime
> ii  zlib1g-dev:amd64 1:1.3.dfsg-1  
amd64    compression library - development
> 
> -- 

Looks like a problem in texlive itself, so this can probably be
moved/merged:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051243#48

-- 
Kind regards,
Luca Boccassi


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

Bug#1056298: riseup-vpn dns configuration don't work with systemd-resolved

2023-11-20 Thread Nilesh Patra

On Mon, Nov 20, 2023 at 04:41:05PM +0530, Pirate Praveen wrote:
> > This maybe a setup/configuration issue for your system. I did find a
> > similar issue on the systemd repository itself[1] and the fix was to add
> > in a "DNS=" entry in resolved.conf. Can you try this and report back?
> 
> I already have DNS= 103.87.68.194 (opennic.org dns resolver) set to and
> FallbackDNS=9.9.9.9
> 
> I also had DNSOverTLS=yes. After disabling this host command works.

I still can't reproduce after trying this setting. I set this as a global 
setting:

$ resolvctl status
Global
  Protocols: +LLMNR +mDNS +DNSOverTLS DNSSEC=yes/supported
   resolv.conf mode: uplink
 Current DNS Server: 9.9.9.9
 DNS Servers 9.9.9.9
Fallback DNS Servers 1.1.1.1
  DNS Domain ~.

And I am able to use riseup-vpn without any issues. Seems this is something 
else on
your system. Can you share all the logs you see right from the point you run 
riseup-vpn
from terminal?

I need something that I could reproduce to be able to further check.

signature.asc
Description: PGP signature

Bug#1056312: zlib1g makes tex-common fail to install due to fmtutil failing

Control: found -1 1:1.3.dfsg-1

On Mon, 20 Nov 2023 12:20:55 +0100 Johannes Schauer Marin Rodrigues
 wrote:
> Package: zlib1g
> Version: 1:1.3.dfsg-2
> Severity: serious
> 
> Hi,
> 
> I didn't investigate this further yet but filing this as RC as it is
easy to
> reproduce and it's easy to find out that only zlib1g changed using
debbisect.
> Downgrading to zlib1g 1:1.2.13.dfsg-3 makes the problem go away.
Steps to
> reproduce:
> 
> $ mmdebstrap --include=tex-common,texlive-base unstable /dev/null
> Processing triggers for tex-common (6.18) ...
> Running updmap-sys. This may take some time... done.
> Running mktexlsr /var/lib/texmf ... done.
> Building format(s) --all.
>   This may take some time... 
> fmtutil failed. Output has been stored in
> /tmp/fmtutil.tcAsaQVq
> Please include this file if you report a bug.
> 
> dpkg: error processing package tex-common (--configure):
>  installed tex-common package post-installation script subprocess
returned error exit status 1
> Errors were encountered while processing:
>  tex-common
> E: Sub-process env returned an error code (1)

Looks like this was introduced by 1:1.3.dfsg-1, as it can be reproduced
in a minimal sid chroot by installing it from
https://snapshot.debian.org/archive/debian/20231118T151103Z/pool/main/z/zlib/zlib1g_1.3.dfsg-1_amd64.deb
and then installing texlive-base:

<...>
Processing triggers for tex-common (6.18) ...
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... 
fmtutil failed. Output has been stored in
/tmp/fmtutil.ohLhbhu3
Please include this file if you report a bug.

dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 tex-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
# dpkg -l | grep zlib
ii  zlib1g:amd64 1:1.3.dfsg-1   amd64   
 compression library - runtime
ii  zlib1g-dev:amd64 1:1.3.dfsg-1   amd64   
 compression library - development

-- 
Kind regards,
Luca Boccassi


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

Bug#1055891: transition: gdal

2023-11-20 Thread Adrian Bunk

On Sun, Nov 19, 2023 at 09:34:40AM +0100, Paul Gevers wrote:
>...
> On 19-11-2023 09:06, Sebastiaan Couwenberg wrote:
>...
> > grass-core in testing depends on the old libgdal33, hence the need to
> > also get grass and libgdal-grass from unstable when running autopkgtest
> > with gdal from unstable.
> 
> Why? (In other words, what breaks exactly?) Is this a case where some
> binaries load the old library and others load the new one leading to symbol
> clashes?

It is a case where a binary tries to load the new soversion of the 
library and plugins for the old soversion of the library.

> Paul
>...

cu
Adrian

Bug#1051243: This affects the build of the pspp package


On 20.11.2023 10:43, Friedrich Beckmann wrote:

Hi,


i noticed a failure in our CI pipeline for pspp probably due to this bug. The 
problem occurs when I try to install "apt install texlive-plain-generic“. The 
install fails with



A new package is on the way. Another adaption to zlib is needed, I'll 
trigger that later on.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051243: texlive-binaries needs rebuild due to update of zlib to 1.3

2023-11-20 Thread Friedrich Beckmann

I did a rebuild of texlive-binaries from source. Then I installed the created 
packages. The build environment contains zlib1g-dev 1.3-dfsg2.

Then "apt install texlive-plain-generic“ will work.

So texlive needs a rebuild due to the zlib version update as texlive seems to 
remember which version of zlib was used during build.

Bug#1056313: network-manager: breaks networking

Control: found -1 1.44.2-3
Control: retitle -1 network-manager: breaks networking (Permission denied for 
the new /usr/libexec/nm-dhcp-helper)

On 2023-11-20 12:24:36 +0100, Vincent Lefevre wrote:
> Package: network-manager
> Version: 1.44.2-4
> Severity: grave
> Justification: renders package unusable
> 
> Just after the upgrade of network-manager from 1.44.2-1 to 1.44.2-4,
> my network is down.

The testing version 1.44.2-3 is broken too.

> The issue disappeared after downgrading back to 1.44.2-1.
> 
> Note: the errors about /usr/libexec/nm-dhcp-helper changed to
> 
> Nov 20 12:17:42 cventin dhclient[295468]: execve 
> (/usr/libexec/nm-dhcp-helper, ...): No such file or directory
> 
> but the network is working. I don't whether this is related, though.

This is because /usr/libexec/nm-dhcp-helper exists in
1.44.2-3 and 1.44.2-4, but not in 1.44.2-1.

I suspect that nm-dhcp-helper has been added because it is now needed.
But it doesn't work due to the "Permission denied".

I've attached more journalctl output, in case it is needed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Nov 20 12:26:43 cventin systemd[1]: Starting NetworkManager.service - Network 
Manager...
Nov 20 12:26:43 cventin dbus-daemon[761]: [system] Successfully activated 
service 'org.freedesktop.nm_dispatcher'
Nov 20 12:26:43 cventin systemd[1]: Started NetworkManager-dispatcher.service - 
Network Manager Script Dispatcher Service.
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.2215] 
NetworkManager (version 1.44.2) is starting... (after a restart, 
boot:69bc9a99-ac9d-4eb8-9de9-9471a74d32b3)
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.2216] Read 
config: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) 
(etc: dhcp.conf, logging.conf)
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.2284] 
manager[0x564430a339a0]: monitoring kernel firmware directory '/lib/firmware'.
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.2285] 
monitoring ifupdown state file '/run/network/ifstate'.
Nov 20 12:26:43 cventin dbus-daemon[761]: [system] Activating via systemd: 
service name='org.freedesktop.hostname1' 
unit='dbus-org.freedesktop.hostname1.service' requested by ':1.269' (uid=0 
pid=296512 comm="/usr/sbin/NetworkManager --no-daemon")
Nov 20 12:26:43 cventin systemd[1]: Starting systemd-hostnamed.service - 
Hostname Service...
Nov 20 12:26:43 cventin dbus-daemon[761]: [system] Successfully activated 
service 'org.freedesktop.hostname1'
Nov 20 12:26:43 cventin systemd[1]: Started systemd-hostnamed.service - 
Hostname Service.
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3134] 
hostname: hostname: using hostnamed
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3134] 
hostname: static hostname changed from (none) to "cventin"
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3140] 
dns-mgr: init: dns=default,systemd-resolved rc-manager=symlink (auto)
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3144] 
manager[0x564430a339a0]: rfkill: Wi-Fi hardware radio set enabled
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3145] 
manager[0x564430a339a0]: rfkill: WWAN hardware radio set enabled
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3171] 
Loaded device plugin: NMWifiFactory 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-wifi.so)
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3205] 
Loaded device plugin: NMBluezManager 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-bluetooth.so)
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3208] 
Loaded device plugin: NMWwanFactory 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-wwan.so)
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3224] 
Loaded device plugin: NMTeamFactory 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-team.so)
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3228] 
Loaded device plugin: NMAtmManager 
(/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-device-plugin-adsl.so)
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3231] 
manager: rfkill: Wi-Fi enabled by radio killswitch; enabled by state file
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3232] 
manager: rfkill: WWAN enabled by radio killswitch; enabled by state file
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3233] 
manager: Networking is enabled by state file
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3238] 
settings: Loaded settings plugin: ifupdown 
("/usr/lib/x86_64-linux-gnu/NetworkManager/1.44.2/libnm-settings-plugin-ifupdown.so")
Nov 20 12:26:43 cventin NetworkManager[296512]:   [1700479603.3239] 
settings:

Bug#1055567: Error: gscan2pdf fails to compile

2023-11-20 Thread Jeff


What about:

sudo ldconfig

cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf

If you start gscan2pdf as follows:

LD_LIBRARY_PATH=/lib/x86_64-linux-gnu/ gscan2pdf

?

Can you start xsane, simple-scan or scanimage ?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056313: network-manager: breaks networking