Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common

[Otto Kekäläinen]

After some experimentation I found out that updating libkrb5-3 so that
/usr/lib/x86_64-linux-gnu/libkrb5.so.3 upgrades will stop MariaDB from
crashing.

$ apt install libk5crypto3 libkrb5-3
...
libssl3 amd64 3.0.8-1
libgssapi-krb5-2 amd64 1.20.1-1+b1
libkrb5support0 amd64 1.20.1-1+b1
libkrb5-3 amd64 1.20.1-1+b1

I made a quick bash one-liner to install all packages from 'apt
upgrade' step one-by-one to find out which one exactly causes MariaDB
to crash, and the result was also libk5crypto3.

Here is a more complete stack trace with debug symbols installed and
addr2line working:


230514  5:19:28 [ERROR] mysqld got signal 11 ;
Server version: 10.5.19-MariaDB-0+deb11u2 source revision:
f8a85af8ca1c937b8d4f847477bd282f80251cde
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
467880 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x0 thread_stack 0x49000
2023-05-14  5:19:28 0 [Note] InnoDB: Buffer pool(s) load completed at
230514  5:19:28
??:0(my_print_stacktrace)[0x556f175e616e]
??:0(handle_fatal_signal)[0x556f170def45]
libc_sigaction.c:0(__restore_rt)[0x7f443ea8cf90]
krb/prng.c:151(krb5_c_random_os_entropy)[0x7f443cd95de0]
??:0(krb5_init_context_profile)[0x7f443ce06cbf]
??:0(plugin_init())[0x7f443cee7569]
/usr/lib/mysql/plugin/auth_gssapi.so(+0x2330)[0x7f443cee7330]
??:0(sys_var_pluginvar::sys_var_pluginvar(sys_var_chain*, char const*,
st_plugin_int*, st_mysql_sys_var*, char const*))[0x556f16ef3562]
??:0(plugin_init(int*, char**, int))[0x556f16ef44d7]
??:0(unireg_abort)[0x556f16e1c0e6]
??:0(mysqld_main(int, char**))[0x556f16e21dc4]
x86/libc-start.c:74(__libc_start_call_main)[0x7f443ea7818a]
csu/libc-start.c:128(call_init)[0x7f443ea78245]
??:0(_start)[0x556f16e16daa]


I think the solution would be for libk5crypto3 to have instead of

Depends: libc6 (>= 2.33), libkrb5support0 (>= 1.16)

to have

Depends: libc6 (>= 2.33), libkrb5support0 (>= 1.20)

Bug#1035913: fixed in doc-debian 11.2

[Joost van Baal-Ilić]

Hi josch,

On Fri, May 12, 2023 at 08:12:46PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Quoting Joost van Baal-Ilić (2023-05-12 09:12:23)
> > TL;DR: I believe I can upload a fix to experimental & ask for unblock in the
> > coming weekend.
> 
> cool!


> > I am very sorry it took me so long to find some time to work on these long
> > standing issues.  (In my defense: I've explicitly asked for more hands:
> > https://lists.debian.org/msgid-search/20230201193812.gb28...@beskar.mdcc.cx 
> > .
> > And: I'm am not the doc-debian maintainer; I'm merely an uploader.)
> 
> Sorry, I didn't want to come across as rude. I'm also just doing all this as a
> volunteer in my limited free time just like you. Though it seems in practice
> you have become the de-facto doc-debian maintainer now -- congratulations. :)

Hehe :)

> > Anyway, I'll likely have time to work on this during the coming weekend; I
> > believe I can do a fixed upload then, thanks to your very helpful hints.
> > (And, risking stating the obvious here: NMU's very welcome.)
> 
> If you want me to do something, just mail me what you need and I'll see 
> whether
> I can find some time to take care of it.

Thanks for this kind message.

I've just uploaded doc-debian/11.3 to experimental and reopened the unblock
request in #1035710 (unblock: doc-debian/11.3).

Thanks!

Bye

Joost

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Cyril Brulebois]

Hi Ben,

Thanks for all those details!

Ben Hutchings  (2023-05-14):
> > 
> >   +-+-+-+-+
> >   |  Graphics   |  Bullseye 11.7  |  Bookworm RC 2  |  Daily builds   |
> >   +-+++++++
> >   | |  BIOS  |  UEFI  |  BIOS  |  UEFI  |  BIOS  |  UEFI  |
> >   +-+++++++
> >   | |   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga std|   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
> >   | -vga cirrus |   OK   |   OK   |   OK   |  KO-S  |   OK   |  KO-S  |
> >   | -vga qxl|   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga virtio |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   | -vga vmware |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
> >   +-+++++++
> 
> I started testing with QEMU and OVMF from unstable, and I'm instead
> seeing Xorg failing to start in the same cases you see glitches.  The
> relevant error message seems to be this one:
> http://codesearch.debian.net/show?file=xorg-server_2%3A21.1.7-3%2Fhw%2Fxfree86%2Ffbdevhw%2Ffbdevhw.c=504

Checking RC 1, I'm seeing OK results for both `-vga std` (or no options)
and `-vga cirrus`. I should note GRUB itself is “text-like” with RC 1,
while it's “graphical” with RC 2.

Reverting the following commit in debian-installer.git and building a
netboot-gtk image against unstable gives me a working graphical
installer with `-vga std` (or no options) and `-vga cirrus`. I didn't
check the rest of the matrix though.
  
https://salsa.debian.org/installer-team/debian-installer/-/commit/a4dc8c0fe7ad1a0c1506125ad9985f78819a1bb2

So it looks to me the GRUB config fix uncovered a pre-existing bug, and
the linux version bump (6.1.20-1 → 6.1.20-2) between RC 1 and RC 2 isn't
a factor (xserver-xorg-* udebs didn't change).

Interestingly, switching to the bullseye branch and cherry-picking the
same GRUB config fix there, and rebuilding d-i against current bullseye,
I'm getting exactly the same problem: KO-G for std, KO-S for cirrus!

So it looks like this might be a rather old issue, rather than a
regression during the Bookworm release cycle.


Also, I should note that while my focus was on netboot-gtk mini.iso
(because it's much quicker to rebuild/tweak than a netinst image), I'm
replicating those results with the netinst images:
 - Bullseye has a “text-like” GRUB, all good.
 - Bookworm RC 1 has a “text-like” GRUB, all good.
 - Bookworm RC 2 has a “graphical” GRUB, issues!

> > Questions
> > =
> > 
> >  - Is it really to be expected that X and standard drivers would regress
> >this way when moving from Bullseye to Bookworm?
> 
> No.
> 
> >  - Or is it expected to require specific kernel modules while that wasn't
> >the case before? I've discovered this in VM environments, but maybe
> >similar things could be happening on bare metal as well, and maybe
> >some more modules should be considered for inclusion?
> 
> No.
> 
> >  - Is it acceptable to just bundle bochs, cirrus, and vboxvideo for the
> >time being (i.e. RC 3, RC 4, 12.0.0), be it via the nasty approach
> >or via a proper linux fb-modules inclusion?
> >  - Or does shipping those few modules risk breaking the kernel and/or X
> >on other platforms? (I'd definitely hope not!)
> 
> I would not expect so.  They get used on the installed system, so they
> probably work.

Copy all!

Note for a further session: instead of debugging d-i itself, it should
be possible to reproduce those issues in the installed system, by
keeping only a specific list of kernel modules and X drivers. Of course,
that means having GRUB in “graphical” mode as well (a quick check
suggests installing desktop-base, without plymouth*, is sufficient for
that part).

As a very quick experiment, I tried:
 - installing xfce4 and desktop-base;
 - rebooting;
 - X doesn't start directly, one needs to run startxfce4 from the
   console.

Then:
 - manually removing all X drivers except fbdev_drv.so;
 - manually removing both tiny/ drivers (bochs and cirrus);
 - rebuilding the initramfs;
 - rebooting.

This gives me the following:
 - std: black screen, not even seeing a console prompt;
 - cirrus: “garbled/split” screen symptoms in the console, and in X;
 - qxl: all good in the console and in X.

Interestingly, purging desktop-base gets me back to a “text-only” GRUB
prompt, but both std and cirrus are exhibiting “garbled/split” screen
symptoms in the console and in X.

I'll stop here, I just wanted to confirm one could reproduce those
issues within the installed system, which should almost always be a
debug-friendlier environment than d-i…

> > Proposal plan for d-i (Bookworm RC 3, RC 4, and 12.0.0)
> > =
> > 
> > Unless I received strong negative feedback before Monday (May 15th),
> > I 

Bug#1017466: Datei … ist ein symbolische Verknüpfung, während Datei … ein normale leere Datei ist.

[Al Ma]

retitle 1017466 Datei … ist ein symbolische Verknüpfung, während Datei … ein 
normale leere Datei ist.
severity 1017466 important
thanks
I confirm the bug. The German message when comparing a symlink with a regular 
file contains grammatical errors. To reproduce:
$ echo $LANG
de_DE.UTF-8
$ touch f g
$ ln -s f fl
$ diff --no-dereference fl g
Datei fl ist ein symbolische Verknüpfung, während Datei g ein normale leere 
Datei ist.
The grammatically correct message should be this:
Datei fl ist eine symbolische Verknüpfung, während Datei g eine normale leere 
Datei ist.
Alternatively, if you prefer to have the definite article:
Die Datei fl ist eine symbolische Verknüpfung, während die Datei g eine normale 
leere Datei ist.
Raising the severity because the errors annoy me as a corrector each time I see 
them.
Gratefully,
Alma

Bug#1035944: mariadb: upgrade issue: mariadb-server-10.5 fails to restart after upgrading mariadb-common

[Otto Kekäläinen]

Hi!

I was able to reproduce this with:

apt install mariadb-plugin-gssapi-server mariadb-plugin-gssapi-client
sed s/bullseye/bookworm/g -i /etc/apt/sources.list
apt update
apt-get upgrade

Upgrade only updates mysql-common and mariadb-common:

$ dpkg -l | grep -e mysql -e maria
ii  libdbd-mariadb-perl1.21-3
ii  libmariadb3:amd64  1:10.5.19-0+deb11u2
ii  mariadb-client-10.51:10.5.19-0+deb11u2
ii  mariadb-client-core-10.5   1:10.5.19-0+deb11u2
ii  mariadb-common 1:10.11.2-1
ii  mariadb-plugin-gssapi-client:amd64 1:10.5.19-0+deb11u2
ii  mariadb-plugin-gssapi-server   1:10.5.19-0+deb11u2
iF  mariadb-server-10.51:10.5.19-0+deb11u2
ii  mariadb-server-core-10.5   1:10.5.19-0+deb11u2
ii  mysql-common   5.8+1.1.0



I applied manually the debugging patch I have in
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/26
on /etc/init.d/mariadb and it resulted in:

$ /etc/init.d/mariadb restart
Stopping MariaDB database server: mariadbd.
Starting MariaDB database server: mariadbd . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
230514 01:36:00 mysqld_safe Can't log to error log and syslog at the
same time.  Remove all --log-error configuration options for --syslog
to take effect.
230514 01:36:00 mysqld_safe Logging to '/tmp/tmp.AQ6kA9uzuH.err'.
230514 01:36:00 mysqld_safe Starting mariadbd daemon with databases
from /var/lib/mysql
Running '/etc/init.d/mariadb start' failed with error log:
230514 01:36:00 mysqld_safe Starting mariadbd daemon with databases
from /var/lib/mysql
2023-05-14  1:36:00 0 [Note] Starting MariaDB
10.5.19-MariaDB-0+deb11u2 source revision
f8a85af8ca1c937b8d4f847477bd282f80251cde as process 9189
2023-05-14  1:36:00 0 [Note] InnoDB: Uses event mutexes
2023-05-14  1:36:00 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2023-05-14  1:36:00 0 [Note] InnoDB: Number of pools: 1
2023-05-14  1:36:00 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2023-05-14  1:36:00 0 [Note] InnoDB: Using Linux native AIO
2023-05-14  1:36:00 0 [Note] InnoDB: Initializing buffer pool, total
size = 134217728, chunk size = 134217728
2023-05-14  1:36:00 0 [Note] InnoDB: Completed initialization of buffer pool
2023-05-14  1:36:00 0 [Note] InnoDB: Starting crash recovery from
checkpoint LSN=45127,45127
2023-05-14  1:36:00 0 [Note] InnoDB: 128 rollback segments are active.
2023-05-14  1:36:00 0 [Note] InnoDB: Removed temporary tablespace data
file: "ibtmp1"
2023-05-14  1:36:00 0 [Note] InnoDB: Creating shared tablespace for
temporary tables
2023-05-14  1:36:00 0 [Note] InnoDB: Setting file './ibtmp1' size to
12 MB. Physically writing the file full; Please wait ...
2023-05-14  1:36:00 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2023-05-14  1:36:00 0 [Note] InnoDB: 10.5.19 started; log sequence
number 45163; transaction id 20
2023-05-14  1:36:00 0 [Note] InnoDB: Loading buffer pool(s) from
/var/lib/mysql/ib_buffer_pool
2023-05-14  1:36:00 0 [Note] Plugin 'FEEDBACK' is disabled.
230514  1:36:00 [ERROR] mysqld got signal 11 ;
...
/usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x5613bb07516e]
/usr/sbin/mariadbd(handle_fatal_signal+0x485)[0x5613bab6df45]
/lib/x86_64-linux-gnu/libc.so.6(+0x3bf90)[0x7f4b7a2faf90]
/usr/lib/x86_64-linux-gnu/libk5crypto.so.3(krb5_c_random_os_entropy+0x0)[0x7f4b785fcde0]
/usr/lib/x86_64-linux-gnu/libkrb5.so.3(krb5_init_context_profile+0x22f)[0x7f4b7866dcbf]
/usr/lib/mysql/plugin/auth_gssapi.so(_Z11plugin_initv+0x129)[0x7f4b7874e569]
/usr/lib/mysql/plugin/auth_gssapi.so(+0x2330)[0x7f4b7874e330]
/usr/sbin/mariadbd(+0x77b562)[0x5613ba982562]
/usr/sbin/mariadbd(_Z11plugin_initPiPPci+0x887)[0x5613ba9834d7]
/usr/sbin/mariadbd(+0x6a40e6)[0x5613ba8ab0e6]
/usr/sbin/mariadbd(_Z11mysqld_mainiPPc+0x3f4)[0x5613ba8b0dc4]
/lib/x86_64-linux-gnu/libc.so.6(+0x2718a)[0x7f4b7a2e618a]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85)[0x7f4b7a2e6245]
/usr/sbin/mariadbd(_start+0x2a)[0x5613ba8a5daa]


I suspect that some of the dependencies on the system (libc?) that
updated causes GSSAPI to crash.

Bug#1034824: tomcat9 should not be released with Bookworm

[Emmanuel Bourg]

Le 2023-05-13 22:38, Markus Koschany a écrit :


The question is: If we ship libtomcat9-java in Bookworm and change the
dependency from tomcat9-user to tomcat10-user, will a web application 
like
dogtag-pki, which is designed for Tomcat 9, continue to work with 
Tomcat 10?


I'm pretty sure it won't work. dogtag-pki depends on tomcatjss which is 
tightly
coupled with Tomcat's internal code. Unfortunately tomcatjss upstream is 
lagging
with the Tomcat 10 adoption [1], and we can't hold back Tomcat 10 in 
Debian
indefinitely just for that (for the reminder, Tomcat 10 is a very 
important
release implementing the new Jakarta EE specification, not having it in 
Bookworm

would be a real disservice to our users).

The thing I don't understand is why a CA webapp needs a custom Tomcat
connector (tomcatjss), maybe it could be patched to work without it?

Emmanuel Bourg

[1] https://github.com/dogtagpki/tomcatjss/issues/68

Bug#1034796: kio-gdrive: Does not work. Network account create does not propose gogle drive

[Nicholas D Steeves]

Eric Valette  writes:

> On 30/04/2023 00:48, Nicholas D Steeves wrote:
>> 
>> Justification: Package is not unusable for everyone.  See the following
>> for further info: https://www.debian.org/Bugs/Developer#severities
>
> It is hard to know if it is broken for you or for many others. As I saw 
> exactly the same reports on other distrib I assume this is a general 
> problem.

It may be that Google disconnected a bunch of people again...  This
happened to me sometime in the last three weeks, for no reason, and only
on my laptop.  Reauthenticating solved it.

>>> Using dolphin for network, you can select gdrive but it does not propose to 
>>> add
>>> a google account.
>>>
>> 
>> That's odd, mine shows a "New account" button.
>
>
> I tested on another computer with exactly the same setup unstable + 
> experimental, nearly same package set (well execpt I use a generic 
> debian kernel on this one). And there it kinda works:
>
> 1)I cannot access an old account,
> 2) but I can create a new one
> 3) and relaucching kdeinit5 I can even access the content,
>
> So this is probably incompatible left over in the .config or similar. I 
> will try to search for gdrive or kio there.
>

Yes, that could be!

>> Are you able to reproduce this bug with a pure testing/bookworm or
>> sid/unstable system?  If so, please provide steps to reproduce, and
>> remove the moreinfo tag from this bug at that time.
>
> Well the package are now in testing I guess due to the hard freeze.

Yes, and my experience is that they work fine without the addition of
experimental packages.

> Thnaks for replying. More later when I can put my hands back on the 
> problematic config.

You're welcome!  I appreciate your efforts, and if there is a bug that
affects bookworm/testing, then we need to figure out how to reproduce
it, so we can fix up asap :)  Of course it would also be nice to fix
experimental and unstable, but bookworm has top priority.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk

[Adam Hough]

Copying /boot/grub/grub.cfg to /boot/efi/EFI/debian/ to replace the
grub.cfg that was located there does allow for a complete boot. This does
result in having to type in the unlock password a second time which is
different than before.

The contents of the /boot/efi/EFI/debian/grub.cfg was:

cryptomount -u 707fed618803485ea28d54b3b229be77
cryptomount -u 2ef006b2262c49b5bac3a51ddefcbfe6
search.fs_uuid 904c1ede-e04b-4102-a982-2333af179474 root
cryptouuid/707fed618803485ea28d54b3b229be77
cryptouuid/2ef006b2262c49b5bac3a51ddefcbfe6
set prefix=($root)'/activeroot/boot/grub'
configfile $prefix/grub.cfg

So I have 2 work arounds though for some reason when pasting from a pikvm
after grub has loaded results in characters not always pasting correctly
which make it more difficult to enter the password.

- Adam Hough

On Sun, May 14, 2023 at 12:06 AM Adam Hough  wrote:

> Package: grub-efi-amd64-bin
> Version: 2.06-12
> Followup-For: Bug #924151
>
> Dear Maintainer,
>
>* What led up to the situation?
> Upgraded to the latest grub2 packages on 2023-05-02 and then had a
> power outage today resulting in a reboot.
>
> grep grub dpkg.log | grep upgrade
> 2023-05-02 16:44:00 upgrade grub-efi:amd64 2.06-8 2.06-12
> 2023-05-02 16:44:00 upgrade grub-efi-amd64:amd64 2.06-8 2.06-12
> 2023-05-02 16:44:01 upgrade grub2-common:amd64 2.06-8 2.06-12
> 2023-05-02 16:44:01 upgrade grub-efi-amd64-bin:amd64 2.06-8 2.06-12
> 2023-05-02 16:44:03 upgrade grub-ieee1275-bin:amd64 2.06-8 2.06-12
> 2023-05-02 16:44:05 upgrade grub-emu:amd64 2.06-8 2.06-12
> 2023-05-02 16:44:07 upgrade grub-common:amd64 2.06-8 2.06-12
> 2023-05-02 16:44:08 upgrade grub-efi-amd64-signed:amd64 1+2.06+8 1+2.06+12
> 2023-05-02 16:44:09 upgrade grub-firmware-qemu:amd64 2.06-8 2.06-12
> 2023-05-13 19:18:55 upgrade grub-efi:amd64 2.06-12 2.06-12
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
>  Current setup is a fully encrypted via luks1 BTRFS based root
> partition spanning 2 SSD devices in a raid1 configuration. Each drive has a
> ESP EFI partition on partition 2 and a Mdraid 10 on partition 3 with the
> BTRFS root on partition 4. The first partition is a vfat partition to store
> bios firmware updates and some recovery scripts information to make
> recovery easier.
>
> On reboot, grub will ask for my password to decrypt the btrfs root
> partitions. This is successful and will will load the grub screen. When
> trying to boot the linux kernel entry there is an error as grub cannot find
> the linux kernel.
>
> The command "search.fs_uuid 904c1ede-e04b-4102-a982-2333af179474 root
> cryptouuid/707fed618803485ea28d54b3b229be77
> cryptouuid/2ef006b2262c49b5bac3a51ddefcbfe6" fails to find t
> he uuid "904c1ede-e04b-4102-a982-2333af179474" so cannot find the vmlinuz
> and initrd files.
>
> I have not tried the previous work around listed here yet.
>
>After a few hours switch to systemd-boot but would prefer to switch
> back to a fully encrypted boot as the linux and initrd images are not in
> the ESP partition.
>
>* What was the outcome of this action?
>
>The systemd-boot boot method did work.
>
>* What outcome did you expect instead?
>
>Expect it to work like it did previously as it did on the last boot on
> Sat Mar 25 12:32:12 CET 2023 which was with grub 2.06-8.
>
>
> -- Package-specific info:
>
> *** BEGIN /proc/mounts
> /dev/mapper/crypt_samsung870evo / btrfs
> rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/activeroot 0 0
> /dev/mapper/crypt_samsung870evo /mnt/btrfsrootencrypted btrfs
> rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/ 0 0
> /dev/mapper/crypt_samsung870evo /timemachine_ahough01 btrfs
> rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/timemachine_ahough01 0 0
> /dev/mapper/crypt_8tb1 /btrfs_pool btrfs
> rw,relatime,compress=zlib:3,space_cache,subvolid=5,subvol=/ 0 0
> /dev/mapper/crypt_8tb1 /virt btrfs
> rw,relatime,compress=zlib:3,space_cache,subvolid=263,subvol=/virt_machines
> 0 0
> /dev/mapper/crypt_8tb1 /data btrfs
> rw,relatime,compress=zlib:3,space_cache,subvolid=258,subvol=/data 0 0
> /dev/mapper/crypt_samsung870evo /var/lib/docker/btrfs btrfs
> rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/activeroot 0 0
> /dev/nvme0n1p2 /boot/efi vfat
> rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
> 0 0
> /dev/sdb2 /boot/efi2 vfat
> rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
> 0 0
> /dev/nvme0n1p1 /mnt/VFATNVME vfat
> rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
> 0 0
> /dev/sdb1 /mnt/VFATSSD vfat
> rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
> 0 0
> *** END /proc/mounts
>
> *** BEGIN /boot/grub/grub.cfg
> #
> # DO NOT EDIT THIS FILE
> #
> # It is automatically 

Bug#879989: calibre registers as application/pdf handler, overrides better ones

[Nicholas D Steeves]

Hi Yokota,

yokota  writes:

> System default application choice may vary on your applications
> installation order, or some other reasons.
> For example, .docx uses LibreOffice even I installs Calibre on my machine.
>
> You can choose your favorite applications as default application from
> GNOME file manager application: "Files"
> or other file managers.
>
> The help file of this application describes how to change default
> application choice (See blow).
> Don't forget to set "Always use for this file type" switch to keep your 
> choice.
>

You're writing about the XDG case, which can be tested in a
desktop-agnostic way with "xdg-open".

Alexandre is writing about mailcap-defined MIME types.  These can be
tested with  "run-mailcap".

There's a nice article on this topic here:
  
https://unix.stackexchange.com/questions/472245/how-to-make-xdg-open-follow-mailcap-settings-in-debian

Alexandre Lymberopoulos  writes:

> Reinstalling libreoffice again in aptitude didn't fixed anything. The
> workaournd I found here is to edit the mailcap (/etc/mailcap) file,
> commenting the lines linking that type of file to ebook-edit and
> ebook-viewer programs.

Have you tried /etc/mailcap.order?  It might let you work around this
bug while you wait for it to be resolved, and IIRC it means your
customisation[s] won't be  cloberred by a future update.  I vaguely
remember that mimeview or mimeopen might be able to define per-user
mappings, but I'm not sure, because it's been so many years.

If I remember correctly mailcap.order is for admin use only, and not for
Debian packages, but it might be worth asking someone if this would be
alternative to patching upstream `resources/mime.types`.

> I insist on my suggestion to keep associtaion of files to its more
> obvious options programs and let specific users change it to their
> needs. In this concrete situation calibre, or any other software, should
> not claim the preference for opening .docx files over libreoffice.

To be fair, would you please install "antiword" and then try to open a
.doc (not a docx) from mutt?  I'm not sure if antiword supports docx,
but the point is to use a well-established Debian package with
well-established mailcap behaviour.

Alternatively, install upstream `resources/mime.types` to
/usr/share/doc/calibre/examples, and let users opt-in.  The XDG
mechanism should continue to work correctly in this case, it may break
the workflows of users who use minimal window managers.  This solution
is the least work.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1036038: debian-installer: Debian installer, graphical installer, live image, hang on Dell Inspiron 27

[Cyril Brulebois]

Hi Ernesto,

Ernesto Alfonso  (2023-05-13):
> I'm attempting to setup Debian on a Dell Inspiron All-in-One system,
> either as dual boot or replacing the existing windows 10 OS.
> 
> The installer hangs after entering either the "graphical install",
> "install" or "live" options from the initial menu. I used the latest
> 64-bit installer: debian-11.7.0-amd64-netinst.iso, burned onto a USB
> drive using the dd command:
> 
> sudo dd if=/debian-11.7.0-amd64-netinst.iso of=/dev/sda

OK, all of that looks good to me. You could try and replace “quiet” with
“debug” on any entry to see if you're getting some error messages.

> I've tried to disable most or all of the UEFI secure boot options on
> the BIOS and also the RAID/storage related settings: […]

That really shouldn't be needed, we've been supporting Secure Boot for a
while. And yes, it's starting to be rather common for systems to come
without any support for BIOS/Legacy booting (and I kind of like the way
some hardware manufacturers are up-front about it, with a clear message
in their UEFI firmware interface).

> Is it possible to install Debian on this type of system?

At this stage, I'd suggest giving Bookworm a shot, e.g. using the D-I
Bookworm RC 2 installer. Or wait a few hours (maybe days), at which
point an RC 3 should become available.

  https://www.debian.org/devel/debian-installer/


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


signature.asc
Description: PGP signature

Bug#1036038: debian-installer: Debian installer, graphical installer, live image, hang on Dell Inspiron 27

[Ernesto Alfonso]

Package: debian-installer
Severity: important
Tags: d-i
X-Debbugs-Cc: erjoa...@gmail.com

Dear Maintainer,

I'm attempting to setup Debian on a Dell Inspiron All-in-One system, either as 
dual boot or replacing the existing windows 10 OS.

The installer hangs after entering either the "graphical install", "install" or 
"live" options from the initial menu. I used the latest 64-bit installer: 
debian-11.7.0-amd64-netinst.iso, burned onto a USB drive using the dd command:

sudo dd if=/debian-11.7.0-amd64-netinst.iso of=/dev/sda
Here's a picture of the initial menu, and the hang:

Initial menu:
https://i.stack.imgur.com/2IVCf.jpg

Hang:
https://i.stack.imgur.com/z0iTB.jpg

I've tried to disable most or all of the UEFI secure boot options on the BIOS 
and also the RAID/storage related settings:

Boot Configuration (1/3). Legacy Mode not supported??
https://i.stack.imgur.com/coiev.jpg

Boot Configuration (2/3)
https://i.stack.imgur.com/BAGWU.jpg

Boot Configuration (3/3)
https://i.stack.imgur.com/Pjbpz.jpg

Storage/RAID Configuration Storage/RAID Configuration
https://i.stack.imgur.com/63Deb.jpg

I just noticed the "Legacy Mode not supported" note in the BIOS,
which I suspect may be to blame.

Is it possible to install Debian on this type of system?


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

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

Bug#1036037: unblock: emacs/1:28.2+1-15

[Rob Browning]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: em...@packages.debian.org
Control: affects -1 + src:emacs

Please unblock package emacs

The only changes are two bug fixes, one for a file conflict with
bullseye emacs-bin-common and one for a conflict with older elpa-cider:

  https://bugs.debian.org/1034941
  https://bugs.debian.org/1035781

diff -Nru emacs-28.2+1/debian/changelog emacs-28.2+1/debian/changelog
--- emacs-28.2+1/debian/changelog	2023-04-01 22:38:56.0 -0500
+++ emacs-28.2+1/debian/changelog	2023-05-13 15:17:27.0 -0500
@@ -1,3 +1,16 @@
+emacs (1:28.2+1-15) unstable; urgency=medium
+
+  * emacs-common: add breaks/replaces emacs-bin-common (<< 1:28) since the
+emacs.service file moved from emacs-bin-common to emacs-common.
+Thanks to Helmut Grohne for reporting the problem and Andreas Beckmann
+for providing and testing the fix. (Closes: 1034941)
+
+  * emacs-common: add breaks elpa-cider (<< 0.19.0+dfsg-4~).  Thanks to
+Andreas Beckmann for reporting the problem and providing and testing
+the fix. (Closes: 1035781)
+
+ -- Rob Browning   Sat, 13 May 2023 15:17:27 -0500
+
 emacs (1:28.2+1-14) unstable; urgency=medium
 
   * Fix gnus nnml crash on some invalid headers.  Add
diff -Nru emacs-28.2+1/debian/control emacs-28.2+1/debian/control
--- emacs-28.2+1/debian/control	2023-03-31 13:22:31.0 -0500
+++ emacs-28.2+1/debian/control	2023-05-13 14:31:35.0 -0500
@@ -142,7 +142,9 @@
  apel (<< 10.8+0.20120427-4),
  edb (<< 1.32),
  egg (<< 4.2.0-2),
+ elpa-cider (<< 0.19.0+dfsg-4~),
  emacs (<< 1:25),
+ emacs-bin-common (<< 1:28),
  emacs-gtk (<< 1:25),
  emacs-lucid (<< 1:25),
  emacs-nox (<< 1:25),
@@ -159,7 +161,9 @@
  emacs24-nox,
  emacs25,
  emacs25-lucid,
- emacs25-nox,
+ emacs25-nox
+Replaces:
+ emacs-bin-common (<< 1:28)
 Description: GNU Emacs editor's shared, architecture independent infrastructure
  GNU Emacs is the extensible self-documenting text editor.
  This package contains the architecture independent infrastructure

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Ben Hutchings]

On Sat, 2023-05-13 at 10:22 +0200, Cyril Brulebois wrote:
[...]
> Kernel-side
> ===
> 
> The fb-modules udeb hasn't changed much since 4+ years, with some DRM
> modules getting added alongside existing ones, leading to the following
> contents in Bullseye (5.10.178-3):
[...]
> Those contents are defined via those files in linux.git:
> 
> kibi@tokyo:~/debian-kernel/linux.git (sid=)$ cat 
> debian/installer/modules/amd64/fb-modules
> #include 
> 
> vesafb ?
> vga16fb
> 
> kibi@tokyo:~/debian-kernel/linux.git (sid=)$ cat 
> debian/installer/modules/fb-modules
> # We don't include all DRM drivers here as on many platforms we can
> # call system firmware to get hold of a simple framebuffer

To expand on this comment, in the case of UEFI boot the efifb driver
should provide a simple framebuffer, and on BIOS vesafb should do it. 
Those are both built-in on x86, and efifb is also built-in on arm64 and
armhf.


[...]
> X-side
> ==

Both of the kernel drivers are old-style framebuffer drivers so in
Xorg, the appropriate generic driver is "fbdev", not "modesetting".

> Now, we know that the contents of xserver-xorg-core-udeb have changed a
> little between Bullseye and Bookworm (#1035014), but that doesn't seem
> to be a factor here.
> 
> I've tested 3 netboot/gtk/mini.iso to assess the situation:
> 
>  - mini-20210731+deb11u8.iso from Bullseye 11.7
>  - mini-20230427.iso from D-I Bookworm RC 2
>  - mini-daily.isofrom D-I daily builds (downloaded today)
> 
> If people want to replicate those tests, they're available at:
>   https://people.debian.org/~kibi/bug-drm-vs-uefi/
> 
> Or:
> 
> wget 
> https://deb.debian.org/debian/dists/bullseye/main/installer-amd64/20210731+deb11u8/images/netboot/gtk/mini.iso
>  -O mini-20210731+deb11u8.iso
> wget 
> https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/20230427/images/netboot/gtk/mini.iso
>  -O mini-20230427.iso
> wget https://d-i.debian.org/daily-images/amd64/daily/netboot/gtk/mini.iso 
> -O mini-daily.iso

These all include fbdev_drv.so, and Xorg.log shows that the fbdev
driver is being used.

So I suppose there's a regression in either efifb or fbdev_drv.

> Via QEMU, under BIOS and UEFI, results are:
> 
>   +-+-+-+-+
>   |  Graphics   |  Bullseye 11.7  |  Bookworm RC 2  |  Daily builds   |
>   +-+++++++
>   | |  BIOS  |  UEFI  |  BIOS  |  UEFI  |  BIOS  |  UEFI  |
>   +-+++++++
>   | |   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
>   | -vga std|   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
>   | -vga cirrus |   OK   |   OK   |   OK   |  KO-S  |   OK   |  KO-S  |
>   | -vga qxl|   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
>   | -vga virtio |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
>   | -vga vmware |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
>   +-+++++++

I started testing with QEMU and OVMF from unstable, and I'm instead
seeing Xorg failing to start in the same cases you see glitches.  The
relevant error message seems to be this one:
http://codesearch.debian.net/show?file=xorg-server_2%3A21.1.7-3%2Fhw%2Fxfree86%2Ffbdevhw%2Ffbdevhw.c=504

[...]
> Questions
> =
> 
>  - Is it really to be expected that X and standard drivers would regress
>this way when moving from Bullseye to Bookworm?

No.

>  - Or is it expected to require specific kernel modules while that wasn't
>the case before? I've discovered this in VM environments, but maybe
>similar things could be happening on bare metal as well, and maybe
>some more modules should be considered for inclusion?

No.

>  - Is it acceptable to just bundle bochs, cirrus, and vboxvideo for the
>time being (i.e. RC 3, RC 4, 12.0.0), be it via the nasty approach
>or via a proper linux fb-modules inclusion?
>  - Or does shipping those few modules risk breaking the kernel and/or X
>on other platforms? (I'd definitely hope not!)

I would not expect so.  They get used on the installed system, so they
probably work.



[...]
> Proposal plan for d-i (Bookworm RC 3, RC 4, and 12.0.0)
> =
> 
> Unless I received strong negative feedback before Monday (May 15th),
> I plan on including the nasty approach in RC 3, and to revert it
> altogether in RC 4 if big bad regressions are reported:
>   
> https://salsa.debian.org/installer-team/debian-installer/-/commit/9fceca63273d0b501ea64d7b719acafc93a5b7fa
> 
> As a side note, keeping the bundling in src:debian-installer for the
> next few weeks makes us autonomous: we can enable and disable those
> extra modules without requiring a new linux upload… so it's nasty but I
> actually thought about the few advantages we were getting out of 

Bug#1033471: maximize* commands don't work for Emacs is working for GNOME (Debian Stable (devilspie2_0.43-4_amd64.deb) + MATE installed from tasksel), and MATE (Debian Unstable (devilspie2_0.43-5_amd6

[David Hedlund]

###

* Debian Stable (devilspie2_0.43-4_amd64.deb) + MATE installed from tasksel


   *    Works!: Open GNOME. Open $ devilspie in the terminal. Open
   emacs. It actually opens maximized!*

        Note that MATE is required. Without MATE: Debian Stable 
(devilspie2_0.43-4_amd64.deb). Open GNOME. Cannot run $ devilspie in the 
terminal: "An X11 display is required for devilspie2."[1]


    Does not work: Open MATE. Open $ devilspie in the terminal. Open 
emacs. The Emacs window is not maximized.



* Debian Testing (devilspie2_0.43-5_amd64.deb) + MATE installed from tasksel

   Does not work: Open GNOME. Cannot run $ devilspie in the terminal: 
"An X11 display is required for devilspie2."[1]


   Does not work: Open MATE. Open $ devilspie in the terminal. Open 
emacs. The Emacs window is not maximized.



* Debian Unstable (devilspie2_0.43-5_amd64.deb) + MATE installed from 
tasksel


   Does not work: Open GNOME. Cannot run $ devilspie in the terminal: 
"An X11 display is required for devilspie2."[1]



   Works!: Open MATE. Open $ devilspie in the terminal. Open
   emacs. It actually opens maximized!




References

1: Devilspie2 fails to run under Xwayland - 
http://savannah.nongnu.org/bugs/?46746

Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk

[Adam Hough]

Package: grub-efi-amd64-bin
Version: 2.06-12
Followup-For: Bug #924151

Dear Maintainer,

   * What led up to the situation?
Upgraded to the latest grub2 packages on 2023-05-02 and then had a power 
outage today resulting in a reboot.

grep grub dpkg.log | grep upgrade
2023-05-02 16:44:00 upgrade grub-efi:amd64 2.06-8 2.06-12
2023-05-02 16:44:00 upgrade grub-efi-amd64:amd64 2.06-8 2.06-12
2023-05-02 16:44:01 upgrade grub2-common:amd64 2.06-8 2.06-12
2023-05-02 16:44:01 upgrade grub-efi-amd64-bin:amd64 2.06-8 2.06-12
2023-05-02 16:44:03 upgrade grub-ieee1275-bin:amd64 2.06-8 2.06-12
2023-05-02 16:44:05 upgrade grub-emu:amd64 2.06-8 2.06-12
2023-05-02 16:44:07 upgrade grub-common:amd64 2.06-8 2.06-12
2023-05-02 16:44:08 upgrade grub-efi-amd64-signed:amd64 1+2.06+8 1+2.06+12
2023-05-02 16:44:09 upgrade grub-firmware-qemu:amd64 2.06-8 2.06-12
2023-05-13 19:18:55 upgrade grub-efi:amd64 2.06-12 2.06-12

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

 Current setup is a fully encrypted via luks1 BTRFS based root 
partition spanning 2 SSD devices in a raid1 configuration. Each drive has a ESP 
EFI partition on partition 2 and a Mdraid 10 on partition 3 with the BTRFS root 
on partition 4. The first partition is a vfat partition to store bios firmware 
updates and some recovery scripts information to make recovery easier.

On reboot, grub will ask for my password to decrypt the btrfs root 
partitions. This is successful and will will load the grub screen. When trying 
to boot the linux kernel entry there is an error as grub cannot find the linux 
kernel.

The command "search.fs_uuid 904c1ede-e04b-4102-a982-2333af179474 root 
cryptouuid/707fed618803485ea28d54b3b229be77 
cryptouuid/2ef006b2262c49b5bac3a51ddefcbfe6" fails to find t
he uuid "904c1ede-e04b-4102-a982-2333af179474" so cannot find the vmlinuz and 
initrd files.

I have not tried the previous work around listed here yet.

   After a few hours switch to systemd-boot but would prefer to switch back to 
a fully encrypted boot as the linux and initrd images are not in the ESP 
partition.

   * What was the outcome of this action?

   The systemd-boot boot method did work.

   * What outcome did you expect instead?

   Expect it to work like it did previously as it did on the last boot on Sat 
Mar 25 12:32:12 CET 2023 which was with grub 2.06-8.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/crypt_samsung870evo / btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/activeroot 0 0
/dev/mapper/crypt_samsung870evo /mnt/btrfsrootencrypted btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/mapper/crypt_samsung870evo /timemachine_ahough01 btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/timemachine_ahough01 0 0
/dev/mapper/crypt_8tb1 /btrfs_pool btrfs 
rw,relatime,compress=zlib:3,space_cache,subvolid=5,subvol=/ 0 0
/dev/mapper/crypt_8tb1 /virt btrfs 
rw,relatime,compress=zlib:3,space_cache,subvolid=263,subvol=/virt_machines 0 0
/dev/mapper/crypt_8tb1 /data btrfs 
rw,relatime,compress=zlib:3,space_cache,subvolid=258,subvol=/data 0 0
/dev/mapper/crypt_samsung870evo /var/lib/docker/btrfs btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/activeroot 0 0
/dev/nvme0n1p2 /boot/efi vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/sdb2 /boot/efi2 vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/nvme0n1p1 /mnt/VFATNVME vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/sdb1 /mnt/VFATSSD vfat 
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
insmod usb
insmod usb_keyboard
insmod ohci
insmod uhci
insmod ehci
insmod cryptodisk
insmod crypto
insmod search_fs_uuid
insmod search_label
insmod search
insmod btrfs
insmod part_gpt
insmod part_msdos
insmod luks
insmod disk
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function 

Bug#879989: calibre registers as application/pdf handler, overrides better ones

[Alexandre Lymberopoulos]

Hi, Yokota!

I use XFCE here and despite choosing LibreOffice to open the docx files
are opened by ebook-edit or ebokk-viewer when selecting them as
attachments of an e-mail message in mutt.

Reinstalling libreoffice again in aptitude didn't fixed anything. The
workaournd I found here is to edit the mailcap (/etc/mailcap) file,
commenting the lines linking that type of file to ebook-edit and
ebook-viewer programs.

I insist on my suggestion to keep associtaion of files to its more
obvious options programs and let specific users change it to their
needs. In this concrete situation calibre, or any other software, should
not claim the preference for opening .docx files over libreoffice.

Best, Alexandre

On May 14 2023, yokota wrote:
> Hello, Alexandre.
> 
> > Just to confirm that this "bug" remains in the current version and
> > state that IMHO the mimetypes associated to calibre is "too
> > greedy". For instance it doesn't make sense to me open a .docx file
> > sent by e-mail in ebook-edit or ebook-viewer instead of libreofffice.
> 
> System default application choice may vary on your applications
> installation order, or some other reasons.
> For example, .docx uses LibreOffice even I installs Calibre on my machine.
> 
> You can choose your favorite applications as default application from
> GNOME file manager application: "Files"
> or other file managers.
> 
> The help file of this application describes how to change default
> application choice (See blow).
> Don't forget to set "Always use for this file type" switch to keep your 
> choice.
> 
> > Change the default application
> > You can change the default application that is used to open files of a 
> > given type. This will allow you
> > to open your preferred application when you double-click to open a file. 
> > For example, you might want
> > your favorite music player to open when you double-click an MP3 file.
> >
> > 1. Select a file of the type whose default application you want to change. 
> > For example, to change
> > which application is used to open MP3 files, select a .mp3 file.
> > 2. Right-click the file and select "Open with...".
> > 3. Open "Open File" window.
> > 4. Select the application you want and click "Always use for this file 
> > type".
> > 5. Click "Open" button to open the file with selected application.
> > 6. Next time, selected application will uses as default application.
> >
> > This changes the default application not just for the selected file, but 
> > for all files with the same type.
> 
> --
> YOKOTA

-- 
===
Alexandre Lymberopoulos - lym...@gmail.com
===

Bug#1035690: libfinance-quote-perl: GNUCash quotes from Yahoo stopped working

[Bill Wohler]

Here too on bullseye with 1.50~rc2-2.

Editing YahooJSON.pm and changing the URL in $YIND_URL_HEAD as you did
worked for me as well. Thanks for that.

-- 
Bill Wohler  aka 
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Bug#1036036: bsd-mailx: empty HOME then out of memory for mailrc

[Leszek Dubiel]

Package: bsd-mailx
Version: 8.1.2-0.20180807cvs-2
Severity: normal


This command sends email correctly:

 echo test | mail -s test leszek


Running this one displays error, but mail is sent anyway:

  echo test | HOME="" mail -s test leszek
  "~/.mailrc": Out of memory.



-- System Information:
Debian Release: 11.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-22-amd64 (SMP w/8 CPU threads)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bsd-mailx depends on:
ii  base-files 11.1+deb11u7
ii  exim4-daemon-light [mail-transport-agent]  4.94.2-7
ii  libbsd0    0.11.3-1
ii  libc6  2.31-13+deb11u6
ii  liblockfile1   1.17-1+b1

bsd-mailx recommends no packages.

bsd-mailx suggests no packages.

-- no debconf information

Bug#1035976: [Aptitude-devel] Bug#1035976: aptitude dies with SEGV

[Axel Beckert]

Control: tag -1 + unreproducible moreinfo

Hi Harald,

Harald Dunkel wrote:
> For testing I scanned all additional repositories in my sources.list.d.
> It dies about
> 
> deb [arch=amd64 
> signed-by=/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg] 
> https://apt.releases.hashicorp.com bookworm main
> 
> see https://www.hashicorp.com/official-packaging-guide.

Sorry to bother you again, but while this looked very good as
potential cause (or actually still does), I can't reproduce it inside
a Sid pbuilder chroot. So I assume there's another detail which is
required, too, to reproduce it.

Some more ideas to check:

* Do you have any custom settings for settings influencing aptitude's
  package display like "Aptitude::UI::Package-Display-Format" or
  "Aptitude::UI::Default-Grouping"?

* Under which locale settings does it happen for you?

If you neither use any of these settings nor use a non-english locale,
is there any chance that you can install these packages (for
bookworm/sid, otherwise run "find-dbgsym-packages aptitude" from the
debian-goodies package) on one of the affected machines:

strace aptitude-dbgsym libapt-pkg6.0-dbgsym
libboost-iostreams1.74.0-dbgsym libbz2-1.0-dbgsym libc6-dbg
libcap2-dbgsym libcwidget4-dbgsym libelogind0-dbgsym libgcc-s1-dbgsym
libgcrypt20-dbgsym libgpg-error0-dbgsym liblz4-1-dbgsym
liblzma5-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym
libsqlite3-0-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libudev1-dbgsym
libuuid1-dbgsym libxapian30-dbgsym libxxhash0-dbgsym libzstd1-dbgsym
zlib1g-dbgsym

And then run "strace -o aptitude-1035976.strace aptitude" and send me
that file? (Probably best in compressed form.)

Because that's what I just wanted to do if I would have been able to
reproduce it. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1035976: [Aptitude-devel] Bug#1035976: aptitude dies with SEGV

[Axel Beckert]

Hi Harald,

Harald Dunkel wrote:
> For testing I scanned all additional repositories in my sources.list.d.
> It dies about
> 
> deb [arch=amd64 
> signed-by=/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg] 
> https://apt.releases.hashicorp.com bookworm main

Thanks for figuring out that. Will see if I can figure out more.

> I don't know who is to blame here, but I hope this helps

I currently asssume that there is some field unset in their repo meta
data, which aptitude's GUI (and only the GUI) expects to be set
unconditionally. I guess stracing will reveal some more details.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1002856: dependencies

[matthias . geiger1024]

Regarding hueplusplus: https://github.com/enwi/hueplusplus/issues/90

regards,
---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

Hi Salvatore,

adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC

Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso:
> Hi Markus,
> 
> On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote:
> > I have just pushed the necessary changes to our Git repository. 
> > 
> > https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993
> 
> Do we need to have done more here? When Paul asked on #debian-release
> I noted that pki-server depends on tomcat9-user, so reducing
> libtomcat9-java only would now cause a broken dpeends for pki-server:
> 
> $ dak rm --suite=bookworm -n -R -b tomcat9-user
> Will remove the following packages from bookworm:
> 
> tomcat9-user |   9.0.70-1 | all

We could simply replace tomcat9-user with tomcat10-user because it only ships a
script to create a standalone tomcat instance. We have to do
s/tomcat9/tomcat10/ in some debian service files as well.

The question is: If we ship libtomcat9-java in Bookworm and change the
dependency from tomcat9-user to tomcat10-user, will a web application like
dogtag-pki, which is designed for Tomcat 9, continue to work with Tomcat 10? I
don't know yet and maybe Timo can chime in here. 

Regards,

Markus


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

Bug#1036035: gnome-boxes: can't launch since upgrading Kernel to 6.1.0-9

[Tim McConnell]

Package: gnome-boxes
Version: 43.2-1
Severity: normal

Upgraded my Kernel to 6.1.0-9 and now I get a spinning MATE Symbol and Boxes
never launches (See screenshot)


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

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

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  genisoimage  9:1.1.11-3.4
ii  libarchive13 3.6.2-1
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libgudev-1.0-0   237-2
ii  libhandy-1-0 1.8.1-1
ii  libosinfo-1.0-0  1.10.0-2
ii  libosinfo-bin1.10.0-2
ii  libsecret-1-00.20.5-3
ii  libsoup-3.0-03.2.2-2
ii  libspice-client-glib-2.0-8   0.42-1
ii  libspice-client-gtk-3.0-50.42-1
ii  libtracker-sparql-3.0-0  3.4.2-1
ii  libusb-1.0-0 2:1.0.26-1
ii  libvirt-daemon   9.0.0-3
ii  libvirt-glib-1.0-0   4.0.0-2
ii  libwebkit2gtk-4.1-0  2.40.1-1
ii  libxml2  2.9.14+dfsg-1.2
ii  tracker  3.4.2-1

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:7.2+dfsg-6

Versions of packages gnome-boxes suggests:
pn  gnome-connections  

-- debconf-show failed

Bug#940960: ITP: linenoise -- Minimal replacement for readline

[Jeremy Sowden]

I came across linenoise because of a request to support it in nftables.
The request came from someone who wanted to install nftables in a
resource-constrained environment where the existing libreadline support
was too heavyweight.  In the case of osquery, would it possible to go
the other way?  Do you think that upstream would be open to adding
support for libreadline if we offered patches?

J.


signature.asc
Description: PGP signature

Bug#1030545: qemu-(img|system-s390x) hang on s390x bullseye kernel

[James Addison]

Followup-For: Bug #1030545
X-Debbugs-Cc: ben...@debian.org, dipak.zo...@ibm.com

Hi Hilko (plus Dipak, fix author on cc for awareness),

Debian kernel package 5.10.179-1 that includes a fix for this has been accepted
into the stable-security (bullseye-security) suite today, and should resolve
this bug.

(note: I'm uncertain when/whether that update may be applied to zelenka, the
porterbox host, however)

Thanks,
James

[1] - https://tracker.debian.org/media/packages/l/linux/changelog-5.10.179-1

Bug#1034824: tomcat9 should not be released with Bookworm

[Salvatore Bonaccorso]

Hi Markus,

On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote:
> I have just pushed the necessary changes to our Git repository. 
> 
> https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993

Do we need to have done more here? When Paul asked on #debian-release
I noted that pki-server depends on tomcat9-user, so reducing
libtomcat9-java only would now cause a broken dpeends for pki-server:

$ dak rm --suite=bookworm -n -R -b tomcat9-user
Will remove the following packages from bookworm:

tomcat9-user |   9.0.70-1 | all

Maintainer: Debian Java Maintainers 


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
dogtag-pki: pki-server

Dependency problem found.

Does that means that though given the dependency on tomcat9-user only for
pki-server that the package could switch to tomcat10-user instead? Would that
already solve the problem?

Regards,
Salvatore

Bug#1034814: debian-installer: bootable flag not toggling

[Pascal Hambourg]

Control: reassign -1 partman-partitioning
Control: tags -1 patch

On 30/04/2023 at 16:22, Cyril Brulebois wrote:

Pascal Hambourg  (2023-04-30):

On 30/04/2023 at 10:16, Matt Taggart wrote:

IMO "hide the bootable option if GPT" (but maybe that is non-trivial).


It should not be too hard. I can work on a patch against
partman-partitioning if the d-i developers agree with this solution.


Trivial patch attached. Sorry for the delay, I was busy on other topics 
and forgot a bit about this one. Should I open a MR too ?



I'm happy to defer to Steve's expertise and yours on those topics.


I'm no expert on partman, so that means Steve's.From 2216090668c175fe158c6935122b60aa09474d26 Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Sat, 13 May 2023 12:46:18 +0200
Subject: [PATCH] Hide the "Bootable" option on GPT

On GPT, the boot flag is the same as esp and means the partition
has the EFI type, so showing the Bootable option makes no sense.
Toggling it does not work anyway.

Closes: #1034814
---
 active_partition/toggle_bootable/choices | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/active_partition/toggle_bootable/choices b/active_partition/toggle_bootable/choices
index ed8d8d2..6cfb324 100755
--- a/active_partition/toggle_bootable/choices
+++ b/active_partition/toggle_bootable/choices
@@ -7,6 +7,12 @@ id=$2
 
 cd $dev
 
+open_dialog GET_LABEL_TYPE
+read_line label_type
+close_dialog
+# on GPT, the boot flag means type ESP, so hide the boot option
+[ "$label_type" != gpt ] || exit 0
+
 valid_boot=no
 open_dialog VALID_FLAGS $id
 while { read_line flag; [ "$flag" ]; }; do
-- 
2.30.2

Bug#1035693: debian-sa List - Please be more specific

[Meshari E]

Hello,


Thanks Cord for your response.
The purpose was from mail list i requested before it's for help users and
try to create a community for debian in Saudi Arabia, the aiming is not for
translation, Arabic language in all Arab countries it's same and does not
need translation each separate country.
I understood now what you mean about "you'll have to proof that there are
some people out there to support and use it."


Best regards,

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

Followup-For: Bug #1030284

I decline to participate further with this bugreport, although others are
welcome to pick up from the patches I've submitted (please don't merge them
as-is; modify them to apply corrections).

Bug#1002856: dependencies

[matthias . geiger1024]

running qmake against the latest source with removed dependencies folder shows 
those missing libraries:

- hueplusplus [1]
- libe131 [2]
- libcmmk [3]

At least those would need packaging. I might work on this, but it's really 
low-priority for me.

[1] https://github.com/enwi/hueplusplus[2] 
https://github.com/hhromic/libe131[3] https://github.com/chmod222/libcmmk

regards,

---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1036034: plymouth: tribar theme should be treated as other text themes

[Raphaël Halimi]

Package: plymouth
Version: 0.9.5-3
Tags: patch

Dear developer,

Plymouth ships text themes, and graphical themes in a separate 
plymouth-themes package, which have many more dependencies.


Installing only plymouth (without plymouth-themes) and selecting the 
tribar theme currently makes update-initramfs fail because it can't find 
the file /etc/fonts/fonts.conf (shipped with fontconfig-config), which 
tribar doesn't need at all, since it's a actually a text theme 
(correctly shipped with the main plymouth package, and not in the 
plymouth-themes package).


This probably stayed off the radar since plymouth is rarely installed on 
a system without a desktop (and thus, no fonts). That's why the 
probability to mess up the initramfs is quite low, but it's nevertheless 
a possibility.


This can be easily fixed by adding tribar to the dependencies test in 
the initramfs hook (see provided patch).


I tested it in a VM on a standard headless system (bullseye), with and 
without encrypted root; the text prompts for entering the passphrase and 
reporting success or failure are correctly displayed.


Regards,

--
Raphaël Halimi--- debian/local/plymouth.hook.orig	2023-02-01 18:20:20.0 +0100
+++ debian/local/plymouth.hook	2023-05-13 19:49:20.260777891 +0200
@@ -86,7 +86,7 @@
 fi
 
 case "${THEME_NAME}" in
-	text|details)
+	text|details|tribar)
 
 		;;
 

Bug#1036030: asciidoc-base: asciidoc fails to find icons for embedding; iconsdir apparently mismatching asciidoc-common layout

[Leon Marz]

Thanks for the bug report :)

The iconsdir attribute is set wrong in asciidoc. I updated a patch to
set it correctly to '/usr/share/asciidoc/icons'[1].

Since this issue is not release critical it sadly won't be fixed in
Debian bookworm. I will upload the fixed version after it released.

In the meantime you could set the attribute iconsdir to
'/usr/share/asciidoc/icons' to fix the warning.

- Leon

[1]: 
https://salsa.debian.org/debian/asciidoc/-/commit/42ed115af50ae6be20422d1574c966b27b4bce76


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Thorsten Glaser]

James Addison dixit:

>AssertionError [ERR_ASSERTION]: The input did not match the regular 
> expression /RangeError: Maximum call stack size exceeded/. Input:
>
>'Segmentation fault\n'

You removed the subtraction of V8_STACK_RESERVE when mutilating
my patch; this may be related (if it still appears with, raise
the constant).

You also removed the integer safety check (the comparison with
2³¹-1). Don’t.

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#879989: calibre registers as application/pdf handler, overrides better ones

[yokota]

Hello, Alexandre.

> Just to confirm that this "bug" remains in the current version and
> state that IMHO the mimetypes associated to calibre is "too
> greedy". For instance it doesn't make sense to me open a .docx file
> sent by e-mail in ebook-edit or ebook-viewer instead of libreofffice.

System default application choice may vary on your applications
installation order, or some other reasons.
For example, .docx uses LibreOffice even I installs Calibre on my machine.

You can choose your favorite applications as default application from
GNOME file manager application: "Files"
or other file managers.

The help file of this application describes how to change default
application choice (See blow).
Don't forget to set "Always use for this file type" switch to keep your choice.

> Change the default application
> You can change the default application that is used to open files of a given 
> type. This will allow you
> to open your preferred application when you double-click to open a file. For 
> example, you might want
> your favorite music player to open when you double-click an MP3 file.
>
> 1. Select a file of the type whose default application you want to change. 
> For example, to change
> which application is used to open MP3 files, select a .mp3 file.
> 2. Right-click the file and select "Open with...".
> 3. Open "Open File" window.
> 4. Select the application you want and click "Always use for this file type".
> 5. Click "Open" button to open the file with selected application.
> 6. Next time, selected application will uses as default application.
>
> This changes the default application not just for the selected file, but for 
> all files with the same type.

--
YOKOTA

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de

It does seem to (continue to) function, at least on x86:

  ~/dygraphs-2.2.0$ NODE_PATH=/usr/share/nodejs 
../nodejs-18.13.0+dfsg1/out/Release/node /usr/bin/babeljs --config-file 
$PWD/babel.config.json --compact false --source-maps inline -d tests5 auto_tests
  Successfully compiled 59 files with Babel (2744ms).

(NOTE: this was an x86 system, not an ARM64 system)


And the relevant v8 help text output appears to update accordingly:

  ~/dygraphs-2.2.0$ ../nodejs-18.13.0+dfsg1/out/Release/node --v8-options | 
grep -i stack-size
--stack-size (default size of stack region v8 is allowed to use (in kBytes))
  type: int  default: --stack-size=8192

Bug#1034824: tomcat9 should not be released with Bookworm

[Markus Koschany]

I have just pushed the necessary changes to our Git repository. 

https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993


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

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de

Hmm.. although the build itself succeeded, there was a unit test failure that
appears related to the change:

not ok 3213 sequential/test-fs-stat-sync-overflow
  ---
  duration_ms: 1.111
  severity: fail
  exitcode: 1
  stack: |-
node:assert:1027
throw err;
^

AssertionError [ERR_ASSERTION]: The input did not match the regular 
expression /RangeError: Maximum call stack size exceeded/. Input:

'Segmentation fault\n'

at 
/root/nodejs-18.13.0+dfsg1/test/sequential/test-fs-stat-sync-overflow.js:40:10
at ChildProcess.exithandler (node:child_process:427:5)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1091:16)
at Socket. (node:internal/child_process:449:11)
at Socket.emit (node:events:513:28)
at Pipe. (node:net:321:12) {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: 'Segmentation fault\n',
  expected: /RangeError: Maximum call stack size exceeded/,
  operator: 'match'
}

Node.js v18.13.0

Bug#953997: obsolete conffiles after upgrade

[Christoph Anton Mitterer]

On Sat, 2023-05-13 at 12:09 +0200, Andrea Bolognani wrote:
> However, I'm afraid we might have missed our chance.
> 
> At this point, nobody is going to be upgrading from 5.6.0-3, but from
> a more recent version of libvirt-daemon-system where the conffiles in
> question are already not considered part of the package.

As said in my message #10 in this bug,... I don't think it's necessary
that the conffiles are cleaned up exactly the version after they have
been dropped.

AFAIU, you'd simply replace the rm_conffile with a version right before
that of the next upload.

E.g. currently we have 9.0.0-3 in sid.

If your next upload were 9.0.0-4, you'd have to use 9.0.0-4~ (note the
tilde) in rm_conffile.


At least that's how I understand the manpage.


> Note that these conffiles are not actually gone, they've just been
> migrated to the libvirt-daemon-system-sysv. So we can't simply delete
> them from the system without a version check, otherwise we'd break
> all sysvinit users.
> 
> I can't think of a simple, reliable way to handle cleaning up under
> our current circumstances.

I guess Michael (the original reporter) is considerably more
knowledgable than myself and has done such moves previously in systemd
packages... so he may tell you way better about the proper way to
handle that.

But blindly I'd assume, one would do something like:
- cp -a the file that is still considered a conffile for
  libvirt-daemon-system (despite being actually considered as part of
  libvirt-daemon-system-sysv) to some safe mktemp location
- do the rm_conffile  libvirt-daemon-system
- mv the file back to the old location

Then it should no longer be a conffile for libvirt-daemon-system,
should still be identical (with any possible set
XATTRs/ACLs/whatsoever) and you could from then on consider it as
belonging to libvirt-daemon-system-sysv.


The only thing I'm not sure about:
You still want the files to be conffiles (just in another package)...
with rm_conffile you can specify the package,... not sure if dpkg is
smart enough to keep the file as is (and you could just skip the whole
copying stuff) if it sees that the file is a conffile for another
package.

@Michael? What's the expert saying? :-)


Cheers,
Chris.

Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed

[Tim Small]

Package: upgrade-reports
Severity: normal
X-Debbugs-Cc: t...@seoss.co.uk

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release is: bullseye
I am upgrading to: bookworm
Upgrade date: 2023-05-06
Method: apt dist-upgrade

Contents of /etc/apt/sources.list:


deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib
deb-src http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib

# Security updates
deb http://security.debian.org bookworm-security main contrib non-free 
non-free-firmware
deb-src http://security.debian.org bookworm-security main contrib non-free 
non-free-firmware

# bookworm-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware


deb http://deb.debian.org/debian-debug/ bookworm-debug main
# for security updates
deb http://deb.debian.org/debian-debug/ bookworm-proposed-updates-debug main

- Was the system pre-update a 'pure' system only containing packages
  from the previous release? If not, which packages were not from that
  release?

  yes

- Did any packages fail to upgrade?

linux-image-6.1.0-7-amd64

With the ddcci-dkms installed, and enabled for building before the
upgrade, the following occurred during upgrade:

/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-7-amd64.
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist.
dkms: autoinstall for kernel: 6.1.0-7-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 4
dpkg: error processing package linux-image-6.1.0-7-amd64 (--configure):
 installed linux-image-6.1.0-7-amd64 package post-installation script 
subprocess returned error exit status 1
Setting up linux-headers-6.1.0-7-amd64 (6.1.20-2) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-7-amd64.
Error! Could not locate dkms.conf file.
File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist.
dkms: autoinstall for kernel: 6.1.0-7-amd64 failed!
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 4
Failed to process /etc/kernel/header_postinst.d at 
/var/lib/dpkg/info/linux-headers-6.1.0-7-amd64.postinst line 11.
dpkg: error processing package linux-headers-6.1.0-7-amd64 (--configure):
 installed linux-headers-6.1.0-7-amd64 package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-headers-amd64:
 linux-headers-amd64 depends on linux-headers-6.1.0-7-amd64 (= 6.1.20-2); 
however:
  Package linux-headers-6.1.0-7-amd64 is not configured yet.

dpkg: error processing package linux-headers-amd64 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-6.1.0-7-amd64 (= 6.1.20-2); however:
  Package linux-image-6.1.0-7-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-6.1.0-7-amd64
 linux-headers-6.1.0-7-amd64
 linux-headers-amd64
 linux-image-amd64


- Were there any problems with the system after upgrading?


Further Comments/Problems:


Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...",
depending on your shell) from before and after the upgrade so that we
know what packages were installed on your system.

Bug#1036032: upgrade-reports: mariadb upgrade fails when KDE akonadi installed

[Tim Small]

Package: upgrade-reports
Severity: normal
X-Debbugs-Cc: t...@seoss.co.uk

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release is: Bullseye
I am upgrading to: Bookworm
Archive date: 
Upgrade date: 2023-05-06 20:00 UTC
uname -a before upgrade: 
uname -a after upgrade: 
Method: apt dist-upgrade

Contents of /etc/apt/sources.list:


deb http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib
deb-src http://deb.debian.org/debian/ bookworm main non-free non-free-firmware 
contrib

# Security updates
deb http://security.debian.org bookworm-security main contrib non-free 
non-free-firmware
deb-src http://security.debian.org bookworm-security main contrib non-free 
non-free-firmware

# bookworm-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware


deb http://deb.debian.org/debian-debug/ bookworm-debug main
# for security updates
deb http://deb.debian.org/debian-debug/ bookworm-proposed-updates-debug main

- Were there any non-Debian packages installed before the upgrade?  If
  so, what were they?

signal, element-desktop

- Was the system pre-update a 'pure' system only containing packages
  from the previous release? If not, which packages were not from that
  release?

Yes

- Did any packages fail to upgrade?

Errors were encountered while processing:
 default-mysql-server
 kdepim-runtime
 kmail
 kaddressbook
 korganizer
 knotes

With mariadb-server installed (but startup disabled), and also KDE
akonadi/kde-pim installed (and using its own mysqld instance), the
mariadb-server package upgrade fails:

Preparing to unpack .../mariadb-server_1%3a10.11.2-1_amd64.deb ...
/var/lib/mysql: found previous version 10.5
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
Attempt to stop MariaDB/MySQL server returned exitcode 5
There is a MariaDB/MySQL server running, but we failed in our attempts to stop 
it.
Stop it yourself and try again!
dpkg: error processing archive 
/var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb (--unpack):
 new mariadb-server package pre-installation script subprocess returned error 
exit status 1
Preparing to unpack .../libconfig-inifiles-perl_3.03-2_all.deb ...
Unpacking libconfig-inifiles-perl (3.03-2) over (3.03-1) ...
Preparing to unpack .../default-mysql-client_1.1.0_all.deb ...
Unpacking default-mysql-client (1.1.0) over (1.0.7) ...
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
: Warning: unknown DEBIAN_VERSION 12. Valid values are from 9 to 11, inclusive.
Errors were encountered while processing:
 /var/cache/apt/archives/mariadb-server_1%3a10.11.2-1_amd64.deb
needrestart is being skipped since dpkg has failed



Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...",
depending on your shell) from before and after the upgrade so that we
know what packages were installed on your system.

Bug#939170: linux: does not suspend completely, locks up

[Jean-Michel Zwygart]

May 13. 2023 UPDATE same issue back again on Bookworm RC2

As I use my Thinkpad X1 Yoga (is detected as X1 Carbon 4th gen) also as 
test machine, I made a fresh Bookworm install and had the same issue 
(even worse) as on Bullseye. I say worse because on bullseye the issue 
was at least visible, as the screen didn't power off completely. But now 
on Bookworm the display power off... but not the machine. This is why I 
even didn't realize it after installation... but only when my TP didn't 
want to start 2-3 days later... the battery was drained off!


After recharging, I  it saw that after shutdown, only sign was that the 
small led on the ESC/FnLk key was still on! Something that I didn't see 
earlier when closing the the laptop lid.


I added, as per Felix Rublack recommendation, the same entries in 
/etc/modprobe.d/blacklist-tpm.conf (Message #40),



blacklist tpm
blacklist tpm_crb
blacklist tpm_tis
blacklist tpm_tis_core


but unfortunately this doesn't work on Bookworm!

As I'm a relatively new Linux/Debian user with limited knowledge I would 
appreciate any suggestion how to solve the problem.


Thanks in advance for any suggestion!

Jean-Michel Zwygart

On Mon, 25 Jul 2022 17:13:29 +0200 Jean-Michel Zwygart 
 wrote:


> I updated a Thinkpad X1 Yoga (is detected as X1 Carbon 4th gen) from
> Buster to Bullseye a few months ago and after the update the shutdown
> reached status power off but didn't power off the machine. Tried
> different shutdown command options from terminal, with always the same
> result. As relatively new Linux Debian user with I fist thought that I
> did something wrong or that my Thinkpad had a problem. I installed other
> distro's and the problem disappeared... so I assumed it was a Debian 
issue.

>
> But as I want to stay on Debian, I register to the Forum and fortunately
> found this post.
>
> I modified blacklisted tpm, as mentioned by Frank Löffler, and the
> solution worked also for me!
>
> Thanks a lot to Frank for his suggestion, and the others who confirmed
> this solution, that made me confident, as new user, to made the change.
>
> Best regards
>
> Jean-Michel
>
>
>
>

Bug#1034830: qtbase5-private-dev ships header that requires cbor.h without dependency

[Dmitry Shachnev]

Hi all, again.

On Tue, Apr 25, 2023 at 05:56:36PM +0200, Steve Langasek wrote:
> Dear maintainers,
>
> As part of an investigation to establish the feasibility of moving 32-bit
> archs to 64-bit time_t, I am running an analysis of all header files in the
> archive to determine which libraries' ABIs are affected.  This requires the
> headers in question to be compilable.
>
> qtbase5-private-dev ships header files which have includes that are not
> satisfied by its dependencies.  For my purposes, I've worked around these
> unusable headers by adding quirks to my scripts, but it seems worth
> reporting as a bug that headers are being shipped that aren't usable.
>
> - qt5/QtCore/5.15.8/QtCore/private/qcborcommon_p.h, which #includes cbor.h,
>   found in libcbor-dev; but does not provide the CborValue type

Actually, Qt uses tinycbor [1], not libcbor. tinycbor is not packaged in
Debian, and Qt doesn't have an option to build with system tinycbor anyway,
so we are using the bundled version.

[1]: https://github.com/intel/tinycbor

> - qt5/QtCore/5.15.8/QtCore/private/qcfsocketnotifier_p.h, which #includes
>   CoreFoundation/CoreFoundation.h, not found in any package in the archive.
> - qt5/QtGui/5.15.8/QtGui/private/qcoregraphics_p.h: same
> - qt5/QtCore/5.15.8/QtCore/private/qcore_mac_p.h, same
> - 
> qt5/QtFontDatabaseSupport/5.15.8/QtFontDatabaseSupport/private/qcoretextfontdatabase_p.h,
>   depends on the preceding
> - 
> qt5/QtFontDatabaseSupport/5.15.8/QtFontDatabaseSupport/private/qfontengine_coretext_p.h:
>   same
> - qt5/QtTest/5.15.8/QtTest/private/qappletestlogger_p.h: same

These headers are macOS-specific, but the Qt build system installs all
headers unconditionally.

> - qt5/QtCore/5.15.8/QtCore/private/qcollator_p.h, which #includes
>   unicode/ucol.h, found in libicu-dev
> - qt5/QtCore/5.15.8/QtCore/private/qdoublescanprint_p.h, which #includes
>   double-conversion/double-conversion.h, found in libdouble-conversion-dev
> [...]

I have added these two and the other packages you mentioned to Suggests.
Thank you for providing such a list.

As earlier discussed, I don't want to depend on 16 packages that most of
qtbase5-private-dev users won't actually need.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1036031: unblock: python-mitogen/0.3.3-9

[Stefano Rivera]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-mito...@packages.debian.org
Control: affects -1 + src:python-mitogen

Please unblock package python-mitogen

[ Reason ]

This resolves bug 1036018. Apparently ansible has grown the number of
open file handles over time, causing select() to become unusable.
Use poll() instead of select.

python-mitogen development is somewhat sporadic at the moment. We
patched it to support Ansible 6, even though upstream hadn't declared
support, yet. That probably contributed to this bug appearing.

Upstream hasn't picked up this patch, yet. But it's been sitting on
GitHub since early Feb, and resolves the issue.

[ Impact ]

Some users will hit "filedescriptor out of range in select()" errors
when using ansible with miteogen.

[ Tests ]

I've manually tested ansible with mitogen, and it seems to work.
The automated test suite passes.

Some of the GitHub actions tests for this PR failed. But the affected
platforms don't seem relevant to us.

[ Risks ]

Patch is relatively straightforward. Replacing one drop-in class in
place of another.

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

unblock python-mitogen/0.3.3-9
diff -Nru python-mitogen-0.3.3/debian/changelog 
python-mitogen-0.3.3/debian/changelog
--- python-mitogen-0.3.3/debian/changelog   2022-12-13 22:43:51.0 
-0400
+++ python-mitogen-0.3.3/debian/changelog   2023-05-13 09:45:14.0 
-0400
@@ -1,3 +1,10 @@
+python-mitogen (0.3.3-9) unstable; urgency=medium
+
+  * Patch: Use poll() in the broker to handle more file descriptors.
+(Closes: #1036018)
+
+ -- Stefano Rivera   Sat, 13 May 2023 09:45:14 -0400
+
 python-mitogen (0.3.3-8) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-mitogen-0.3.3/debian/patches/poll-poller 
python-mitogen-0.3.3/debian/patches/poll-poller
--- python-mitogen-0.3.3/debian/patches/poll-poller 1969-12-31 
20:00:00.0 -0400
+++ python-mitogen-0.3.3/debian/patches/poll-poller 2023-05-13 
09:45:14.0 -0400
@@ -0,0 +1,28 @@
+From: Luca Berruti 
+Date: Wed, 8 Feb 2023 14:05:25 +0100
+Subject: Fix: filedescriptor out of range in select()
+
+Bug-Debian: https://bugs.debian.org/1036018
+Bug-Upstream: https://github.com/mitogen-hq/mitogen/issues/957
+Origin: https://github.com/mitogen-hq/mitogen/pull/984
+---
+ ansible_mitogen/process.py | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/ansible_mitogen/process.py b/ansible_mitogen/process.py
+index 63caa88..8c19c37 100644
+--- a/ansible_mitogen/process.py
 b/ansible_mitogen/process.py
+@@ -285,8 +285,10 @@ class Broker(mitogen.master.Broker):
+ the exuberant syscall expense of EpollPoller, so override it and restore
+ the poll() poller.
+ """
+-poller_class = mitogen.core.Poller
+-
++if mitogen.parent.PollPoller.SUPPORTED:
++poller_class = mitogen.parent.PollPoller
++else:
++poller_class = mitogen.core.Poller
+ 
+ class Binding(object):
+ """
diff -Nru python-mitogen-0.3.3/debian/patches/series 
python-mitogen-0.3.3/debian/patches/series
--- python-mitogen-0.3.3/debian/patches/series  2022-12-13 20:24:51.0 
-0400
+++ python-mitogen-0.3.3/debian/patches/series  2023-05-13 09:45:14.0 
-0400
@@ -6,3 +6,4 @@
 skip-python2.7-test
 ansible-6
 hack-remove-cleanup
+poll-poller

Bug#1036030: asciidoc-base: asciidoc fails to find icons for embedding; iconsdir apparently mismatching asciidoc-common layout

[Matthias Andree]

Package: asciidoc-base
Version: 10.2.0-1
Severity: important

Dear Maintainer,

as a maintainer of the fetchmail upstream package,
I want to build documentation with asciidoc.

As part of fetchmail's build with meson on the legacy_6x branch of
fetchmail, asciidoc is being run, but cannot find icons:

[68/70] Generating Mailbox-Names-UTF7.html with a custom command
sh: 1: cannot open /etc/asciidoc/icons/warning.png: No such file
asciidoc: WARNING: Mailbox-Names-UTF7.txt: line 157: {sys:"/usr/bin/python3" -u 
-c "import base64,sys; base64.encode(sys.stdin.buffer,sys.stdout.buffer)" < 
"/etc/asciidoc/icons/warning.png"}: non-zero exit status
[70/70] Generating fetchmail-man.html with a custom command (wrapped by meson 
to capture output)

dpkg -L asciidoc-common suggests that asciidoc-base should either refer to
/usr/share/asciidoc/icons, or maintain proper links directly or through the
alternatives mechanism.


Minimal reproducer:

apt install --no-install-recommends -y asciidoc
cat >test.adoc <<'_EOF'
:icons:
WARNING: test text,
 more test text
_EOF
/usr/bin/asciidoc --attribute=data-uri -o test.html test.adoc


Yields:

# /usr/bin/asciidoc --attribute=data-uri -o test.html test.adoc
sh: 1: cannot open /etc/asciidoc/icons/warning.png: No such file
asciidoc: WARNING: test.adoc: line 3: {sys:"/usr/bin/python3" -u -c "import 
base64,sys; base64.encode(sys.stdin.buffer,sys.stdout.buffer)" < 
"/etc/asciidoc/icons/warning.png"}: non-zero exit status


Note this is in a podman-based container setup of debian:testing per:

REPOSITORY TAG   IMAGE ID  CREATED
SIZE
docker.io/library/debian   testing   4601c669d9dc  10 days ago
121 MB

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

Kernel: Linux 6.2.14-300.fc38.x86_64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages asciidoc-base depends on:
ii  asciidoc-common  10.2.0-1
ii  docbook-xsl  1.79.2+dfsg-2
ii  libxml2-utils2.9.14+dfsg-1.2
ii  python3  3.11.2-1+b1
ii  xsltproc 1.1.35-1

Versions of packages asciidoc-base recommends:
pn  xmlto  

Versions of packages asciidoc-base suggests:
pn  asciidoc-doc  
pn  docbook-utils 
pn  source-highlight  

-- no debconf information

Bug#1036029: unblock: glewlwyd/2.7.5-3

[Nicolas Mora]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian-iot-maintain...@lists.alioth.debian.org

Please unblock package glewlwyd 2.7.5-3

[ Reason ]
This new version in unstable fixes #1035503 : glewlwyd-common: prompting due to
modified conffiles which were not modified by the user:
/etc/glewlwyd/config.json

It also updates the default glewlwyd.conf file provided in the package which
prevents a startup error due to missing empty directory
/usr/lib/glewlwyd/user-middleware

[ Impact ]
The package glewlwyd will not be available in Debian Bookwork due to #1035503

[ Risks ]
The change doesn't affect the program nor the build, only the upgrade procedure

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

unblock glewlwyd/2.7.5-3
diff -Nru glewlwyd-2.7.5/debian/changelog glewlwyd-2.7.5/debian/changelog
--- glewlwyd-2.7.5/debian/changelog 2023-01-17 07:24:23.0 -0500
+++ glewlwyd-2.7.5/debian/changelog 2023-05-04 07:21:27.0 -0400
@@ -1,3 +1,10 @@
+glewlwyd (2.7.5-3) unstable; urgency=medium
+
+  * Install config.json as config-2.7.json (Closes: #1035503)
+  * d/glewlwyd-debian.conf.properties: disable user_middleware_module_path
+
+ -- Nicolas Mora   Thu, 04 May 2023 07:21:27 -0400
+
 glewlwyd (2.7.5-2) unstable; urgency=medium
 
   * d/control: add adduser as glewlwyd package dependency, fix piuparts issue
diff -Nru glewlwyd-2.7.5/debian/glewlwyd-common.install 
glewlwyd-2.7.5/debian/glewlwyd-common.install
--- glewlwyd-2.7.5/debian/glewlwyd-common.install   2023-01-17 
07:24:23.0 -0500
+++ glewlwyd-2.7.5/debian/glewlwyd-common.install   2023-05-04 
07:21:27.0 -0400
@@ -7,5 +7,5 @@
 webapp-src/favicon.ico usr/share/glewlwyd/webapp/
 
 debian/config.json usr/share/glewlwyd/templates/
-debian/config.json etc/glewlwyd/
+debian/config.json etc/glewlwyd/config-2.7.json
 debian/glewlwyd-apache.conf etc/glewlwyd/
diff -Nru glewlwyd-2.7.5/debian/glewlwyd-common.links 
glewlwyd-2.7.5/debian/glewlwyd-common.links
--- glewlwyd-2.7.5/debian/glewlwyd-common.links 2023-01-17 07:24:23.0 
-0500
+++ glewlwyd-2.7.5/debian/glewlwyd-common.links 2023-05-04 07:21:27.0 
-0400
@@ -15,4 +15,4 @@
 usr/share/fonts/woff/fork-awesome/forkawesome-webfont.woff 
usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.woff
 usr/share/fonts/woff/fork-awesome/forkawesome-webfont.woff2 
usr/share/glewlwyd/webapp/fonts/forkawesome-webfont.woff2
 
-etc/glewlwyd/config.json usr/share/glewlwyd/webapp/config.json
+etc/glewlwyd/config-2.7.json usr/share/glewlwyd/webapp/config.json
diff -Nru glewlwyd-2.7.5/debian/glewlwyd-debian.conf.properties 
glewlwyd-2.7.5/debian/glewlwyd-debian.conf.properties
--- glewlwyd-2.7.5/debian/glewlwyd-debian.conf.properties   2023-01-17 
07:24:23.0 -0500
+++ glewlwyd-2.7.5/debian/glewlwyd-debian.conf.properties   2023-05-04 
07:21:27.0 -0400
@@ -94,7 +94,7 @@
 user_module_path="/usr/lib/glewlwyd/user"
 
 # user_middleware_module path
-user_middleware_module_path="/usr/lib/glewlwyd/user_middleware"
+#user_middleware_module_path="/usr/lib/glewlwyd/user_middleware"
 
 # client_module path
 client_module_path="/usr/lib/glewlwyd/client"
diff -Nru glewlwyd-2.7.5/debian/NEWS glewlwyd-2.7.5/debian/NEWS
--- glewlwyd-2.7.5/debian/NEWS  2023-01-17 07:24:23.0 -0500
+++ glewlwyd-2.7.5/debian/NEWS  2023-05-04 07:21:27.0 -0400
@@ -9,13 +9,19 @@
 
  -- Nicolas Mora   Mon, 15 Mar 2021 18:18:01 -0400
 
-glewlwyd (2.7.5-2) unstable; urgency=medium
+glewlwyd (2.7.5-3) unstable; urgency=medium
 
   Upgrading Glewlwyd package from Debian Bullseye requires to update the
   database. It's also recommended to disable the config property
   'static_files_path', and serve the static files application located
   in /usr/share/glewlwyd/webapp/ using a static file web server (Apache,
   NGINX).
+  The webapp config.json has been updated, the new config.json file is now
+  located in /etc/glewlwyd/config-2.7.json and linked to
+  /usr/share/glewlwyd/webapp/config.json.
+  If you have made changes to your original config.json, you can backport them
+  to the new config-2.7.json file or keep your current config.json file if you
+  don't need the new properties.
   
   See /usr/share/doc/glewlwyd/INSTALL.md for more details.
 

Bug#1034867: smplayer: crash when playing video files using mplayer under Wayland

[Beatrice Torracca]

Hi!

I am adding this information in this bug rather then reopening a new one 
because I think it might be the same problem, even if I am not using 
smplayer with mplayer, but with mpv . I hope I am not mistaken.


Since I updated my Debian testing circa 1 month ago I have the same 
problem when opening video files in Gnome with Wayland options enabled 
in smplayer preferences.


I am not using mplayer underneath but mpv. I get a black screen with 
audio only. If I disable the "Wayland support" in Options -> Preferences 
-> Video tab; then I see the video in a detached mpv window, which is 
kinda annoying since it cannot be resized on the fly and also the 
controls are still in the smplayer window.


Similar things happen if I choose another output driver (other then the 
default one) in the video tab of the Preferences


I copy below what appears in the error register of smaplayer when the 
problem occurs (I only obscured the info on the file name).


If there is any additional info I can provide let me know.

Thanks for any work on Debian. Always appreciated!

beatrice


/usr/bin/mpv --no-quiet --terminal --no-msg-color 
--input-ipc-server=/tmp/smplayer-mpv-4be05 
--msg-level=ffmpeg/demuxer=error --video-rotate=no --no-config --no-fs 
--hwdec=no --sub-auto=fuzzy --vo=xv,x11, --no-input-default-bindings 
--input-vo-keyboard=no --no-input-cursor --cursor-autohide=no 
--no-keepaspect --wid=8 --monitorpixelaspect=1 --osd-level=1 
--osd-scale=0.6001 --osd-bar-align-y=0.6 --sub-ass 
--embeddedfonts --sub-ass-line-spacing=0 --sub-scale=1 --sub-font=Arial 
--sub-color=# --sub-shadow-color=#ff00 
--sub-border-color=#ff00 --sub-border-size=0.75 
--sub-shadow-offset=2.5 --sub-font-size=50 --sub-bold=no --sub-italic=no 
--sub-margin-y=8 --sub-margin-x=20 --sub-codepage=ISO-8859-1 --vid=1 
--sub-pos=100 --volume=110 --cache=auto --start=8 
--screenshot-template=cap_%F_%p_%02n --screenshot-format=jpg 
--screenshot-directory=/home/beatrice/Immagini/smplayer_screenshots 
--audio-pitch-correction=yes --volume-max=110 
--term-playing-msg=MPV_VERSION=${=mpv-version:}

INFO_VIDEO_WIDTH=${=width}
INFO_VIDEO_HEIGHT=${=height}
INFO_VIDEO_ASPECT=${=video-params/aspect}
INFO_VIDEO_FPS=${=container-fps:${=fps}}
INFO_VIDEO_FORMAT=${=video-format}
INFO_VIDEO_CODEC=${=video-codec}
INFO_DEMUX_ROTATION=${=track-list/0/demux-rotation}
INFO_AUDIO_FORMAT=${=audio-codec-name}
INFO_AUDIO_CODEC=${=audio-codec}
INFO_AUDIO_RATE=${=audio-params/samplerate}
INFO_AUDIO_NCH=${=audio-params/channel-count}
INFO_LENGTH=${=duration:${=length}}
INFO_DEMUXER=${=current-demuxer:${=demuxer}}
INFO_SEEKABLE=${=seekable}
INFO_TITLES=${=disc-titles}
INFO_CHAPTERS=${=chapters}
INFO_TRACKS_COUNT=${=track-list/count}
METADATA_TITLE=${metadata/by-key/title:}
METADATA_ARTIST=${metadata/by-key/artist:}
METADATA_ALBUM=${metadata/by-key/album:}
METADATA_GENRE=${metadata/by-key/genre:}
METADATA_DATE=${metadata/by-key/date:}
METADATA_TRACK=${metadata/by-key/track:}
METADATA_COPYRIGHT=${metadata/by-key/copyright:}
INFO_MEDIA_TITLE=${=media-title:}
INFO_STREAM_PATH=${stream-path}
 --audio-client-name=SMPlayer --term-status-msg=STATUS: ${=time-pos} / 
${=duration:${=length:0}} P: ${=pause} B: ${=paused-for-cache} I: 
${=core-idle} VB: ${=video-bitrate:0} AB: ${=audio-bitrate:0} 
/home/beatrice/Scaricati/


 (+) Video --vid=1 (*) (hevc 1280x718 23.976fps)
 (+) Audio --aid=1 (*) (ac3 6ch 48000Hz)
[vo/xv/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)
[vo/xv/x11] Type: 0, display: 0x7f75940449e0, resourceid: 8, serial: 12
[vo/xv/x11] Error code: 9, request code: e, minor code: 0
[vo/xv/x11] X11 error: BadWindow (invalid Window parameter)
[vo/xv/x11] Type: 0, display: 0x7f75940449e0, resourceid: 8, serial: 13
[vo/xv/x11] Error code: 3, request code: 28, minor code: 0
[vo/xv/x11] X11 error: BadWindow (invalid Window parameter)
[vo/xv/x11] Type: 0, display: 0x7f75940449e0, resourceid: 8, serial: 14
[vo/xv/x11] Error code: 3, request code: 2, minor code: 0
[vo/xv/x11] X11 error: BadWindow (invalid Window parameter)
[vo/xv/x11] Type: 0, display: 0x7f75940449e0, resourceid: 8, serial: 18
[vo/xv/x11] Error code: 3, request code: 1, minor code: 0
[vo/xv/x11] X11 error: BadWindow (invalid Window parameter)
[vo/xv/x11] Type: 0, display: 0x7f75940449e0, resourceid: 102, 
serial: 1b

[vo/xv/x11] Error code: 3, request code: 12, minor code: 0
[vo/xv/x11] X11 error: BadWindow (invalid Window parameter)
[vo/xv/x11] Type: 0, display: 0x7f75940449e0, resourceid: 102, 
serial: 1e

[vo/xv/x11] Error code: 3, request code: 91, minor code: 3
[vo/xv/x11] X11 error: BadWindow (invalid Window parameter)
[vo/xv/x11] Type: 0, display: 0x7f75940449e0, resourceid: 102, 
serial: 20

[vo/xv/x11] Error code: 3, request code: 12, minor code: 0
[vo/xv/x11] X11 error: BadWindow (invalid Window parameter)
[vo/xv/x11] Type: 0, display: 0x7f75940449e0, resourceid: 102, 
serial: 21

[vo/xv/x11] Error code: 3, request code: 12, minor code: 0

Bug#1036015: linux-image-6.3.0-0-amd64: Bluetooth mouse connect very delay after wake up from suspend

[肖盛文]

在 2023/5/13 17:09, Diederik de Haas 写道:

Control: tag -1 moreinfo

On Saturday, 13 May 2023 03:02:50 CEST xiao sheng wen wrote:

When I use Debian 11.6, the kernel is linux-image-5.10.0-21-rt-amd64,
there is not this bug. After I upgrade to Debian 11.7, the kernel is
linux-image-5.10.0-22-rt-amd64, this bug take place.

Does the same regression happen with the non-rt versions of those 5.10
kernels?

Yes, in non-rt versions of 5.10 kernel, this bug exist.

uname -a
Linux atzlinux-d0 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22) 
x86_64 GNU/Linux


This time ,it delay 35 seconds:
[Sat May 13 21:54:16 2023] Bluetooth: hci0: Applying Intel DDC 
parameters completed
[Sat May 13 21:54:16 2023] Bluetooth: hci0: Reading supported features 
failed (-16)
[Sat May 13 21:54:16 2023] Bluetooth: hci0: Telemetry exception format 
not supported
[Sat May 13 21:54:16 2023] Bluetooth: hci0: Firmware revision 0.0 build 
14 week 44 2021
[Sat May 13 21:54:51 2023] input: RAPOO BT4.0 Mouse as 
/devices/virtual/misc/uhid/0005:000E:3412.0007/input/input29
[Sat May 13 21:54:51 2023] input: RAPOO BT4.0 Mouse Consumer Control as 
/devices/virtual/misc/uhid/0005:000E:3412.0007/input/input30
[Sat May 13 21:54:51 2023] hid-generic 0005:000E:3412.0007: 
input,hidraw1: BLUETOOTH HID v67.01 Mouse [RAPOO BT4.0 Mouse] on 
a0:c5:89:47:0c:10




The best way to track down the cause of this regression is to do a `git
bisect` of the kernel between 5.10.162 and 5.10.178.
https://wiki.debian.org/DebianKernel/GitBisect has instructions for it.

The change of the kernel module bluetooth perhaps is the reason of this bug.
I'm not a kernel developer, so I'm not familiar with GitBisect, but I'll 
try GitBisect.


Thanks!

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008602: Thic client (X2Go) workaround

[Juri Grabowski]

Hello together,

On Thu, Oct 27, 2022 at 12:36:14PM +0200, Dashamir Hoxha wrote:
> But only for the users that make the first login after this configuration
> is done. For the users that already made the first login, it seems like the
> old settings have been cached somehow and this does not fix it.
on existing setups you can use following Xsession script, if
x2goserver-xsession is installed:

cat <<'EOF'>/etc/x2go/Xsession.d/57xfce4-session_bug_1008602_workaround
BASESTARTUP=$(basename "$STARTUP" | cut -d\  -f1)
if [ "$BASESTARTUP" = x-session-manager ]; then
BASESTARTUP=$(basename $(readlink /etc/alternatives/x-session-manager))
fi
case "$BASESTARTUP" in
  xfce4-session|startxfce4)
/usr/bin/xfconf-query -c xfwm4 -p /general/use_compositing -s false
;;
esac
EOF

But, like Mike wrote it's just a workaround, the prefferable solution is
to patch xfwm4 to use librda, because so users can use compositing if
it's possible.

Best Regards,
Juri Grabowski

Bug#1035976: Info received (aptitude dies with SEGV)

[Harald Dunkel]

PS: We are using hashicorp to access the terraform package (and maybe
some others). Its in my list of repositories since Aug 8th, 2022, but
aptitude stumbles over this for only a few weeks. No problems with
"aptitude upgrade" and other, non-interactive commands.


Regards

Harri

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

Followup-For: Bug #1030284
X-Debbugs-Cc: t...@mirbsd.de

Thanks, Thorsten.  I'm currently rebuilding (on x86) from the attached patch,
adapted from yours.

  * prefers a one-time repeat division over the clever-but-fragile div-assign

  * removes the upperbound check because integer greater-than checks can be
problematic

  * places comparison constants on the lhs for safety

I'll post test results when they are available.

Cheers,
James
Description: Request an rlimit-determined stack size from V8
Author: James Addison 
Bug-Debian: https://bugs.debian.org/1030284
--- /dev/null
+++ nodejs-18.13.0+dfsg1/foo.c
@@ -0,0 +1,7 @@
+#include 
+
+int main() {
+if (4 > (int)(8 / 3)) {
+printf("Hello world!");
+}
+}
--- nodejs-18.13.0+dfsg1.orig/src/node.cc
+++ nodejs-18.13.0+dfsg1/src/node.cc
@@ -785,6 +785,22 @@ int InitializeNodeWithArgs(std::vector (int)(lim.rlim_cur / 1024))
+   fprintf(stderr, "W: stack size adjustment: RLIMIT_STACK is too 
small\n");
+   else
+   V8::SetFlagsFromString(stackSize, snprintf(stackSize, 
sizeof(stackSize),
+   "--stack-size=%d", (int)(lim.rlim_cur / 1024)));
+}
+
   HandleEnvOptions(per_process::cli_options->per_isolate->per_env);
 
 #if !defined(NODE_WITHOUT_NODE_OPTIONS)

Bug#1036028: squidguard relies on packet squid instead of squid or squid-openssl

[domele]

Package: squidguard
Version: 1.6.0-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
installing squid-openssl

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
apt install squid-openssl

   * What was the outcome of this action?
squidguard gets uninstalled due it relay only on squid

   * What outcome did you expect instead?
it should be possible to use squid-openssl as well as squid already

the way howto get it working for now is
-> apt install squidguard
-> Installs SquidGuard and SQUID
-> apt-mark hold squidguard
-> apt install squid-openssl
-> now it works else, it will get uninstalled and you will not be able 
to use the software

*** End of the template - remove these template lines ***


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

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

Versions of packages squidguard depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.31-13+deb11u6
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libldap-2.4-2  2.4.57+dfsg-3+deb11u1

Versions of packages squidguard recommends:
ii  liburi-perl  5.08-1
ii  libwww-perl  6.52-1
pn  squid

Versions of packages squidguard suggests:
pn  ldap-utils  
pn  squidguard-doc  

-- debconf information:
  squidguard/dbreload: true

Bug#1036027: unblock: kitty/0.26.5-5

[James McCoy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ki...@packages.debian.org
Control: affects -1 + src:kitty

Please unblock package kitty

[ Reason ]
Kitty registers itself as a handler for various MIME types (via
kitty-open.desktop), but some of those (e.g., application/x-sh) are
unexpectedly executed instead of viewed.  This upload removes the
installation of the desktop file, instead providing it as an example.

README.Debian is updated to explain how to enable the functionality as
well as warning about the implications.

[ Impact ]
Untrusted files may be executed rather than viewed (e.g., trying to view
a shell script attached to an email).

[ Tests ]
n/a

[ Risks ]
Trivial change in a leaf package.

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

unblock kitty/0.26.5-5

Bug#1036026: unblock: libssh/0.10.5-1

[Martin Pitt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: lib...@packages.debian.org
Control: affects -1 + src:libssh

Hello,

a few days ago, a new libssh upstream microrelease [1] was published which fixes
two CVEs. I packaged it for unstable four days ago, it built everywhere, and
thus passed the (rather extensive) upstream tests, as well as the autopkgtest
integration tests everywhere [2]. I know one big consumer of libssh well -- 
cockpit
-- which also has successful tests against 0.10.5.

The packaging git already had a few rather harmless updates from the Debian
janitor [3] which I included into the unstable upload. I attached the debian/*
parts of the debdiff between current testing and unstable. If you want to
inspect the full upstream diff as  well, I suggest the upstream git view for
the stable 0.10 branch [4], or the full debdiff view  on salsa[5].

Salvatore Bonaccorso from the security team pointed out that libssh won't
auto-migrate any more at this point in time, so I'd like to coordinate these
two CVEs with you for fixing testing. If you consider 0.10.5 too risky at this
point, I can also prepare a backport similar to the update that I prepared for
stable-security, but it's more work, and backporting non-trivial patches is
also not risk-free. This gets coordinated in [6].

Thanksk,

Martin

unblock libssh/0.10.5-1


[1] 
https://www.libssh.org/2023/05/04/libssh-0-10-5-and-libssh-0-9-7-security-releases/
[2] https://tracker.debian.org/pkg/libssh
[3] 
https://salsa.debian.org/debian/libssh/-/commit/45b9437b4c4711584dba7debe6600aa2a2d7f6c4

https://salsa.debian.org/debian/libssh/-/commit/5feb4c4e0405e6af69d6d448ab934f7876d2ea90

https://salsa.debian.org/debian/libssh/-/commit/8e55b07477c194630bd60c049ca28c57da2881fd
[4] https://git.libssh.org/projects/libssh.git/log/?h=stable-0.10
[5] 
https://salsa.debian.org/debian/libssh/-/compare/4066480562aa1d2682bd5c831c1acd2a2777...debian?from_project_id=20695=false
[6] https://bugs.debian.org/1035832
--- libssh-0.10.4/debian/changelog  2022-09-19 08:41:22.0 +
+++ libssh-0.10.5/debian/changelog  2023-05-10 06:00:26.0 +
@@ -1,3 +1,26 @@
+libssh (0.10.5-1) unstable; urgency=high
+
+  [ Martin Pitt ]
+  * New upstream security release (thus high urgency):
+- Fix authenticated remote DoS through potential NULL dereference during 
rekeying
+  with algorithm guessing (CVE-2023-1667)
+  https://www.libssh.org/security/advisories/CVE-2023-1667.txt
+- Client authentication bypass in pki_verify_data_signature() in low-memory
+  conditions with OpenSSL backend; gcrypt backend is not affected
+  https://www.libssh.org/security/advisories/CVE-2023-2283.txt
+  (CVE-2023-2283, Closes: #1035832)
+  * Bump Standards-Version to 4.6.2. No changes necessary.
+  * Drop debian/source/lintian-overrides. It now causes a "mismatched-override"
+warning, and apparently is not necessary any more.
+  * debian/copyright: Drop files which don't exist any more.
+Spotted by lintian's "superfluous-file-pattern" warnings.
+
+  [ Debian Janitor ]
+  * Bump debhelper from old 12 to 13.
+  * Avoid explicitly specifying -Wl,--as-needed linker flag.
+
+ -- Martin Pitt   Wed, 10 May 2023 08:00:26 +0200
+
 libssh (0.10.4-2) unstable; urgency=medium

   * autopkgtest: Drop valgrind run. This hasn't worked for years on many
diff -Nru libssh-0.10.4/debian/control libssh-0.10.5/debian/control
--- libssh-0.10.4/debian/control2022-09-19 08:41:22.0 +
+++ libssh-0.10.5/debian/control2023-05-10 06:00:26.0 +
@@ -4,7 +4,7 @@
 Maintainer: Laurent Bigonville 
 Uploaders: Mike Gabriel , Martin Pitt 
 Build-Depends: cmake (>= 2.8.5),
-   debhelper-compat (= 12),
+   debhelper-compat (= 13),
libcmocka-dev ,
libgcrypt-dev,
libkrb5-dev | heimdal-dev,
@@ -15,7 +15,7 @@
pkg-config,
python3:any ,
 Build-Depends-Indep: doxygen , graphviz 
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Vcs-Git: https://salsa.debian.org/debian/libssh.git
 Vcs-Browser: https://salsa.debian.org/debian/libssh
@@ -97,6 +97,7 @@
 Suggests: doc-base
 Depends: ${misc:Depends}
 Build-Profiles: 
+Multi-Arch: foreign
 Description: tiny C SSH library - Documentation files
  The ssh library was designed to be used by programmers needing a working SSH
  implementation by the mean of a library. The complete control of the client
diff -Nru libssh-0.10.4/debian/copyright libssh-0.10.5/debian/copyright
--- libssh-0.10.4/debian/copyright  2022-09-19 08:41:22.0 +
+++ libssh-0.10.5/debian/copyright  2023-05-10 06:00:26.0 +
@@ -23,7 +23,6 @@
tests/client/torture_connect.c
tests/client/torture_knownhosts.c
tests/client/torture_session.c
-   tests/test_pcap.c

Bug#1036018: ansible-mitogen: filedescriptor out of range in select()

[Stefano Rivera]

Control: forwarded -1 https://github.com/mitogen-hq/mitogen/issues/957
Control: tag -1 + patch

>   File "/usr/lib/python3/dist-packages/mitogen/core.py", line 2465, in _poll
> (rfds, wfds, _), _ = io_op(select.select,
>  
>   File "/usr/lib/python3/dist-packages/mitogen/core.py", line 567, in io_op
> return func(*args), None
>^^^
> ValueError: filedescriptor out of range in select()

Good news, this has been reported upstream, and there's a proposed
patch. I'll apply it, because it looks sane.

https://github.com/mitogen-hq/mitogen/pull/984

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1035976: aptitude dies with SEGV

[Harald Dunkel]

Control: tag -1 -moreinfo

Hi Axel,

For testing I scanned all additional repositories in my sources.list.d.
It dies about

deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg] 
https://apt.releases.hashicorp.com bookworm main

see https://www.hashicorp.com/official-packaging-guide.


I don't know who is to blame here, but I hope this helps

Harri

Bug#1036025: unblock: exim4/4.96-15

[Andreas Metzler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ex...@packages.debian.org
Control: affects -1 + src:exim4

Please unblock package exim4

This fixes an initialzation error which caused a crash in the smtp
transport. See https://bugs.exim.org/show_bug.cgi?id=2996

It is a one-line change, I have also removed garbage (unapplied patch)
from debian/patches.

cu Andreas

unblock exim4/4.96-15

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
diff -Nru exim4-4.96/debian/changelog exim4-4.96/debian/changelog
--- exim4-4.96/debian/changelog	2023-02-04 13:33:50.0 +0100
+++ exim4-4.96/debian/changelog	2023-05-10 18:30:35.0 +0200
@@ -1,3 +1,12 @@
+exim4 (4.96-15) unstable; urgency=medium
+
+  * Pull from upstream GIT master:
++ 75_70-Fix-variable-initialisation-in-smtp-transport.-Bug-2.patch
+  Fix a crash in the smtp transport.
+  https://bugs.exim.org/show_bug.cgi?id=2996
+
+ -- Andreas Metzler   Wed, 10 May 2023 18:30:35 +0200
+
 exim4 (4.96-14) unstable; urgency=medium
 
   * Pull from upstream GIT master:
diff -Nru exim4-4.96/debian/patches/75_42-Fix-run-arg-parsing.patch exim4-4.96/debian/patches/75_42-Fix-run-arg-parsing.patch
--- exim4-4.96/debian/patches/75_42-Fix-run-arg-parsing.patch	2022-12-04 08:02:50.0 +0100
+++ exim4-4.96/debian/patches/75_42-Fix-run-arg-parsing.patch	1970-01-01 01:00:00.0 +0100
@@ -1,99 +0,0 @@
-From 44b6e099b76f403a55e77650821f8a69e9d2682e Mon Sep 17 00:00:00 2001
-From: Jeremy Harris 
-Date: Sat, 3 Dec 2022 23:13:53 +
-Subject: [PATCH] Fix ${run } arg parsing
-
-Broken-by: cfe6acff2ddc

- doc/ChangeLog|  4 
- src/expand.c | 13 ++---
- src/transport.c  |  4 +++-
- test/scripts/-Basic/0002 |  2 ++
- test/stdout/0002 |  2 ++
- 5 files changed, 21 insertions(+), 4 deletions(-)
-
 a/doc/ChangeLog
-+++ b/doc/ChangeLog
-@@ -28,10 +28,14 @@
- JH/14 Bug 2933: Fix regex substring match variables for null matches. Since 4.96
-   a capture group which obtained no text (eg. "(abc)*" matching zero
-   occurrences) could cause a segfault if the corresponding $ was
-   expanded.
- 
-+JH/15 Fix argument parsing for ${run } expansion. Previously, when an argument
-+  included a close-brace character (eg. it itself used an expansion) an
-+  error occurred.
-+
- 
- 
- Exim version 4.96
- -
- 
 a/src/expand.c
-+++ b/src/expand.c
-@@ -5529,11 +5529,11 @@
-   {
-   FILE * f;
-   const uschar * arg, ** argv;
-   BOOL late_expand = TRUE;
- 
--  if ((expand_forbid & RDO_RUN) != 0)
-+  if (expand_forbid & RDO_RUN)
- {
- expand_string_message = US"running a command is not permitted";
- goto EXPAND_FAILED;
- }
- 
-@@ -5561,16 +5561,23 @@
- 	}
-   s++;
- 
-   if (late_expand)		/* this is the default case */
- 	{
--	int n = Ustrcspn(s, "}");
-+	int n;
-+	const uschar * t;
-+	/* Locate the end of the args */
-+	(void) expand_string_internal(s,
-+	  ESI_BRACE_ENDS | ESI_HONOR_DOLLAR | ESI_SKIPPING, , NULL, NULL);
-+	n = t - s;
- 	arg = skipping ? NULL : string_copyn(s, n);
- 	s += n;
- 	}
-   else
- 	{
-+	DEBUG(D_expand)
-+	  debug_printf_indent("args string for ${run} expand before split\n");
- 	if (!(arg = expand_string_internal(s, TRUE, , skipping, TRUE, )))
- 	  goto EXPAND_FAILED;
- 	Uskip_whitespace();
- 	}
- 			/*{*/
 a/src/transport.c
-+++ b/src/transport.c
-@@ -2187,10 +2187,12 @@
-   BOOL allow_dollar_recipients = addr && addr->parent
- && Ustrcmp(addr->parent->address, "system-filter") == 0;
- 
-   for (int i = 0; argv[i]; i++)
- {
-+DEBUG(D_expand) debug_printf_indent("arg %d\n", i);
-+
- /* Handle special fudge for passing an address list */
- 
- if (addr &&
- (Ustrcmp(argv[i], "$pipe_addresses") == 0 ||
-  Ustrcmp(argv[i], "${pipe_addresses}") == 0))
-@@ -2361,11 +2363,11 @@
-   }
- else *errptr = msg;
- return FALSE;
- }
- 
--  if ( f.running_in_test_harness && is_tainted(expanded_arg)
-+  if (  f.running_in_test_harness && is_tainted(expanded_arg)
- 	 && Ustrcmp(etext, "queryprogram router") == 0)
- 	{			/* hack, would be good to not need it */
- 	DEBUG(D_transport)
- 	  debug_printf("SPECIFIC TESTSUITE EXEMPTION: tainted arg '%s'\n",
- 		  expanded_arg);
diff -Nru exim4-4.96/debian/patches/75_70-Fix-variable-initialisation-in-smtp-transport.-Bug-2.patch exim4-4.96/debian/patches/75_70-Fix-variable-initialisation-in-smtp-transport.-Bug-2.patch
--- exim4-4.96/debian/patches/75_70-Fix-variable-initialisation-in-smtp-transport.-Bug-2.patch	1970-01-01 01:00:00.0 +0100
+++ exim4-4.96/debian/patches/75_70-Fix-variable-initialisation-in-smtp-transport.-Bug-2.patch	2023-05-10 18:30:35.0 +0200
@@ -0,0 +1,46 @@
+From 

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Thorsten Glaser]

James Addison dixit:

>... to add something like this:

Ouch, by going via a string?! I wouldn’t have thought of that…

>  if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
>struct rlimit lim;
>if (getrlimit(RLIMIT_STACK, ) == 0) {
>  char stackSize[32];

32 is magic and may also be wrong here.

>  int buflen = snprintf(stackSize, sizeof(stackSize),
>"--stack-size=%d", lim.rlim_cur);

%d isn’t right for lim.rlim_cur, which is of type rlim_t.
--stack-size seems to take in KiB, and we’d want a reserve.

>  if (buflen < sizeof(stackSize)) {
>V8::SetFlagsFromString(stackSize, buflen);
>  }
>}
>  }


So, taking your next post into account, probably something more
like this:

#define V8_STACK_RESERVE 128
if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
struct rlimit lim;
char stackSize[sizeof("--stack-size=") + /* 2³¹ */ 10];

if (getrlimit(RLIMIT_STACK, ))
fprintf(stderr, "W: stack size adjustment: cannot get 
RLIMIT_STACK\n");
else if (lim.rlim_cur == RLIM_INFINITY)
fprintf(stderr, "W: stack size adjustment: RLIMIT_STACK is 
unlimited\n");
else if ((lim.rlim_cur /= 1024) <= V8_STACK_RESERVE)
fprintf(stderr, "W: stack size adjustment: RLIMIT_STACK is too 
small\n");
else if ((lim.rlim_cur -= V8_STACK_RESERVE) >= /* 2³¹ */ 2147483647)
fprintf(stderr, "W: stack size adjustment: RLIMIT_STACK is too 
large\n");
else
V8::SetFlagsFromString(stackSize, snprintf(stackSize, 
sizeof(stackSize),
"--stack-size=%d", (int)lim.rlim_cur));
}

Untested, still not back to full health, take with grains of salt.

bye,
//mirabilos
-- 
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant.  Therefore you cannot use ' in a preproces-
sing file in c99 mode.  -- Ragge
No faith left in ISO C99, undefined behaviour, etc.

Bug#1036015: linux-image-6.3.0-0-amd64: Bluetooth mouse connect very delay after wake up from suspend

[肖盛文]

Control: found -1 6.1.27-1

Hi,

在 2023/5/13 17:25, Diederik de Haas 写道:

On Saturday, 13 May 2023 11:09:46 CEST Diederik de Haas wrote:

On Saturday, 13 May 2023 03:02:50 CEST xiao sheng wen wrote:

Package: src:linux
Version: 6.3.1-1~exp1

You reported the issue against version 6.3.1-1, but that version isn't
mentioned in your bug report. What's the status with that version?

This bug exist in version 6.3.1-1.
The dmesg Kernel log is come from 6.3.1-1 in bug report.

I would normally advise against installing 'random' kernel versions on a
Debian Stable system, but as you already installed the kernel from
Experimental, can you also try 6.1.0-9?
Earlier today we had a user who reported that that version fixed a bluetooth
issue for them.
I install linux-image-6.1.0-9-amd64  6.1.27-1 and boot from it, this bug 
still exist.


I had done several repeat test :

This test delay 6 seconds, from 19:52:53 to 19:52:59.
[Sat May 13 19:52:53 2023] Bluetooth: hci0: Applying Intel DDC 
parameters completed
[Sat May 13 19:52:53 2023] Bluetooth: hci0: Firmware revision 0.0 build 
14 week 44 2021

[Sat May 13 19:52:53 2023] Bluetooth: MGMT ver 1.22
[Sat May 13 19:52:53 2023] Bluetooth: hci0: Bad flag given (0x1) vs 
supported (0x0)

[Sat May 13 19:52:57 2023] wlp1s0: authenticate with 44:f9:71:69:42:20
[Sat May 13 19:52:57 2023] wlp1s0: send auth to 44:f9:71:69:42:20 (try 1/3)
[Sat May 13 19:52:57 2023] wlp1s0: authenticated
[Sat May 13 19:52:57 2023] wlp1s0: associate with 44:f9:71:69:42:20 (try 
1/3)
[Sat May 13 19:52:57 2023] wlp1s0: RX AssocResp from 44:f9:71:69:42:20 
(capab=0x1011 status=0 aid=2)

[Sat May 13 19:52:57 2023] wlp1s0: associated
[Sat May 13 19:52:57 2023] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link 
becomes ready
[Sat May 13 19:52:59 2023] input: RAPOO BT4.0 Mouse as 
/devices/virtual/misc/uhid/0005:000E:3412.0004/input/input21
[Sat May 13 19:52:59 2023] input: RAPOO BT4.0 Mouse Consumer Control as 
/devices/virtual/misc/uhid/0005:000E:3412.0004/input/input22
[Sat May 13 19:52:59 2023] hid-generic 0005:000E:3412.0004: 
input,hidraw1: BLUETOOTH HID v67.01 Mouse [RAPOO BT4.0 Mouse] on 
a0:c5:89:47:0c:10
[Sat May 13 19:53:04 2023] wlp1s0: Limiting TX power to 35 (35 - 0) dBm 
as advertised by 44:f9:71:69:42:20
[Sat May 13 19:53:37 2023] wlp1s0: deauthenticating from 
44:f9:71:69:42:20 by local choice (Reason: 3=DEAUTH_LEAVING)


This time, delay 34 seconds, from 20:38:53 to 20:39:27.
[Sat May 13 20:38:53 2023] Bluetooth: hci0: Applying Intel DDC 
parameters completed
[Sat May 13 20:38:53 2023] Bluetooth: hci0: Firmware revision 0.0 build 
14 week 44 2021

[Sat May 13 20:38:53 2023] Bluetooth: MGMT ver 1.22
[Sat May 13 20:38:53 2023] Bluetooth: hci0: Bad flag given (0x1) vs 
supported (0x0)

[Sat May 13 20:38:55 2023] wlp1s0: authenticate with 32:e7:6c:92:45:ab
[Sat May 13 20:38:55 2023] wlp1s0: send auth to 32:e7:6c:92:45:ab (try 1/3)
[Sat May 13 20:38:55 2023] wlp1s0: authenticated
[Sat May 13 20:38:55 2023] wlp1s0: associate with 32:e7:6c:92:45:ab (try 
1/3)
[Sat May 13 20:38:55 2023] wlp1s0: RX AssocResp from 32:e7:6c:92:45:ab 
(capab=0x1531 status=0 aid=11)

[Sat May 13 20:38:55 2023] wlp1s0: associated
[Sat May 13 20:38:55 2023] IPv6: ADDRCONF(NETDEV_CHANGE): wlp1s0: link 
becomes ready
[Sat May 13 20:39:27 2023] input: RAPOO BT4.0 Mouse as 
/devices/virtual/misc/uhid/0005:000E:3412.0007/input/input27
[Sat May 13 20:39:27 2023] input: RAPOO BT4.0 Mouse Consumer Control as 
/devices/virtual/misc/uhid/0005:000E:3412.0007/input/input28
[Sat May 13 20:39:27 2023] hid-generic 0005:000E:3412.0007: 
input,hidraw1: BLUETOOTH HID v67.01 Mouse [RAPOO BT4.0 Mouse] on 
a0:c5:89:47:0c:10



Thanks!

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036020: RFS: lighttpd/1.4.70-1 [NMU] -- light, fast, functional web server

[Andrey Rakhmatullin]

Control: retitle -1 RFS: lighttpd/1.4.70-1 -- light, fast, functional web server

On Sat, May 13, 2023 at 04:27:36AM -0400, Glenn Strauss wrote:
> (This is not actually an NMU, but a non-DD maintainer upload.)
If it's not a NMU it shouldn't be tagged as a NMU.

> Please help me to get lighttpd 1.4.70 into Debian Bookworm.
The time to get new upstream versions into Debian Bookworm ended 3 months
ago. Please check the freeze policy every time there is a freeze if you
maintain packages in testing.
If you want you can change this upload to target experimental instead, or
just postpone it until the Bookworm release. You can make a backport for
bookworm-backports after that.
If, on the other hand, 1.4.70 fixes some serious bugs in the testing
version, you should make an upload based on the testing version that
includes these fixes.

Bug#1029734: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Bastian Germann]

Control: forwarded -1 https://github.com/dragotin/kraft/issues/199

Bug#1036024: RM: orangeassassin -- RoQA; RC-buggy; old experimental package

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: h...@debian.org

Please remove orangeassassin. The package is RC-buggy and has never been 
released or updated since it got into experimental in 2017.

Bug#1029739: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf

[Bastian Germann]

Upstream switched to pypdf with 0.2.9.

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

On Sat, 13 May 2023 at 12:15, James Addison  wrote:
>
> On Sat, 13 May 2023 at 11:14, James Addison  wrote:
> >
> > On Sat, 13 May 2023 at 02:18, Thorsten Glaser  wrote:
> > >
> > > James Addison dixit:
> > >
> > > >I'm going to stay involved with this thread, but I think that it is
> > > >upon you to develop or provide further guidance towards a patch if
> > > >it's something you'd like to have implemented, Thorsten.
> > >
> > > I actually have looked into that but I don’t understand the nodejs
> > > and v8 source code enough to be able. I know C, but not CFrustFrust.
> > > I would rather prefer asm…
> >
> > Ok, thanks.  We may be stalled temporarily in that case.
> >
> > On Sat, 13 May 2023 at 00:20, James Addison  wrote:
> > > That said: perhaps it could be useful if someone could check whether
> > > the following commit is relevant to this:
> > > https://github.com/libuv/libuv/commit/18c7530a75d813801f819caae4dff47fc4a1d4a1
> >
> > I ran the repro case (with some simplifications) from the GitHub
> > thread using 'strace' and grepped for rlimit-related syscalls:
> >
> >   # on arm64, this currently replicates the problem using debian bookworm
> >   $ strace babeljs --config-file $PWD/babel.config.json --compact
> > false --source-maps inline -d tests5 auto_tests 2>&1 | grep -i rlimit
> >
> > All of the resulting calls (on an ARM64 host) are to the 'prlimit64'
> > syscall and have a zero exit-code (success).
>
> How about extending the code around after this block:
> https://github.com/nodejs/node/blob/2bb4b59fa5529569ad38d3bf7d3c926d8e47/src/node.cc#L781-L786
>
> ... to add something like this:
>
>   if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
> struct rlimit lim;
> if (getrlimit(RLIMIT_STACK, ) == 0) {
>   char stackSize[32];
>   int buflen = snprintf(stackSize, sizeof(stackSize),
> "--stack-size=%d", lim.rlim_cur);
>   if (buflen < sizeof(stackSize)) {
> V8::SetFlagsFromString(stackSize, buflen);
>   }
> }
>   }
>
> ?

Note: probably worth adjusting that to add another conditional to
check that the stack limit isn't unset/infinity:

if (getrlimit(RLIMIT_STACK, ) == 0 && lim.rlim_max != RLIM_INFINITY) {

I'm not sure that I have an ARM64 machine with enough memory and/or
non-flash-based disk to want to compile and test this on.  But
hopefully it would be fairly straightforward (apt source nodejs, apt
build-dep ., dpkg-buildpackage, or something along those lines).

Bug#1036023: cabal-install: cabal install fails on i686: fdTryLock: invalid argument (Invalid argument)

[Uroš Knupleš]

Package: cabal-install
Version: 3.4.1.0-3
Severity: important
X-Debbugs-Cc: u...@knuples.net

Hi,

I'm experiencing a persistent issue with the 'cabal install' on an i686. 

Regardless of the package I attempt to install, the command consistently fails 
with the error: fdTryLock: invalid argument (Invalid argument).

Here is a typical example of the error occurring when trying to install the 
'hello' package:

$ cabal install hello
Resolving dependencies...
Build profile: -w ghc-9.0.2 -O1
In order, the following will be built (use -v for more details):
 - hello-1.0.0.2 (exe:hello) (requires download & build)
Downloading  hello-1.0.0.2
Downloaded   hello-1.0.0.2
Starting hello-1.0.0.2 (all, legacy fallback)
Building hello-1.0.0.2 (all, legacy fallback)
Installing   hello-1.0.0.2 (all, legacy fallback)
cabal: Failed to build hello-1.0.0.2. The failure occurred during the final
install step. The exception was:
fdTryLock: invalid argument (Invalid argument)

For the moment, I am able to work around the issue by using the upstream build, 
which does not seem to produce this error. 

However, I would prefer to use the Debian packaged version.

Greetings,
Uros

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 6.1.0-7-686-pae (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cabal-install depends on:
ii  ghc9.0.2-4
ii  libc6  2.36-9
ii  libffi83.4.4-1
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  sgml-base  1.31
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages cabal-install recommends:
ii  curl  7.88.1-9
ii  wget  1.21.3-1+b1

cabal-install suggests no packages.

-- no debconf information

Bug#1035732: libkscreenlocker5: Endless loop when using PAM

[Patrick Franz]

Hi Andreas,

On Mon, 8 May 2023 14:15:17 +0200 "Poenicke, Andreas (TKM)" 
 wrote:
> Package: libkscreenlocker5
> Version: 5.20.5-1
> Severity: critical
> Tags: patch upstream
> Justification: breaks the whole system
[...]
> Please include the short patch
> https://invent.kde.org/plasma/kscreenlocker/-/commit/fca315cf72826f93eda7a026016b33818b9d1f39
> to kscreenlocker-5.20.5 in bullseye.

Thanks for reporting this. I have applied the patch onto the version
in bullseye and uploaded it here: 

https://people.debian.org/~deltaone/kscreenlocker/

Could be so kind and install it ? If you can confirm it fixes your issue,
I'll prepare the upload for stable.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

On Sat, 13 May 2023 at 11:14, James Addison  wrote:
>
> On Sat, 13 May 2023 at 02:18, Thorsten Glaser  wrote:
> >
> > James Addison dixit:
> >
> > >I'm going to stay involved with this thread, but I think that it is
> > >upon you to develop or provide further guidance towards a patch if
> > >it's something you'd like to have implemented, Thorsten.
> >
> > I actually have looked into that but I don’t understand the nodejs
> > and v8 source code enough to be able. I know C, but not CFrustFrust.
> > I would rather prefer asm…
>
> Ok, thanks.  We may be stalled temporarily in that case.
>
> On Sat, 13 May 2023 at 00:20, James Addison  wrote:
> > That said: perhaps it could be useful if someone could check whether
> > the following commit is relevant to this:
> > https://github.com/libuv/libuv/commit/18c7530a75d813801f819caae4dff47fc4a1d4a1
>
> I ran the repro case (with some simplifications) from the GitHub
> thread using 'strace' and grepped for rlimit-related syscalls:
>
>   # on arm64, this currently replicates the problem using debian bookworm
>   $ strace babeljs --config-file $PWD/babel.config.json --compact
> false --source-maps inline -d tests5 auto_tests 2>&1 | grep -i rlimit
>
> All of the resulting calls (on an ARM64 host) are to the 'prlimit64'
> syscall and have a zero exit-code (success).

How about extending the code around after this block:
https://github.com/nodejs/node/blob/2bb4b59fa5529569ad38d3bf7d3c926d8e47/src/node.cc#L781-L786

... to add something like this:

  if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
struct rlimit lim;
if (getrlimit(RLIMIT_STACK, ) == 0) {
  char stackSize[32];
  int buflen = snprintf(stackSize, sizeof(stackSize),
"--stack-size=%d", lim.rlim_cur);
  if (buflen < sizeof(stackSize)) {
V8::SetFlagsFromString(stackSize, buflen);
  }
}
  }

?

Bug#993625: RFP: wezterm -- A GPU-accelerated cross-platform terminal emulator in rust

[Matthias Geiger]

Package: wnpp

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: wezterm
   Version : 20230408-112425-69ae8472
   Upstream Author : Wez Furlong
* URL : https://github.com/wez/wezterm/
* License : MIT
   Programming Lang: Rust
   Description :  A GPU-accelerated cross-platform terminal emulator and 
multiplexer 

Looks interesting. I tried it for a bit. Missing dependencies (gathered from 
cargo-debstatus):

wezterm
wezterm-blob-leases
wezterm-client
wezterm-dynamic
wezterm-font
wezterm-gui
wezterm-gui-subcommands
wezterm-input-types
wezterm-mux-server
wezterm-mux-server-impl
wezterm-open-url
wezterm-ssh
wezterm-toast-notification
wezterm-version

Those would need packaging first.

regards,

werdahias


- - -- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.1-surface (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
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

- -BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmRfW64gHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHVNXQ//RbEpcxNXFd3h
MLS7+981jC0SUEmnn6QnGSi++8TMfMscjKuRv2CFw9IWXoWcWB7uPWgr41kq8VPa
hKeMHie6dp4MdXuPeHOotjigUTbNZklYABoq5cwzC4+XzZgLmbBpH1nnfsaJTZCN
c3N80kmz8ipSdW35saQsdf9nccaSX4qiwuCyTlUlGx5BIAMPgsP2TuHVgIsE8ou8
e7jUylNqThvSDBQUMxh0SIAOSrg2MqJRBGi1dLU5H0hSg3lcVhPi1cVkUGiy7dSo
0rKAWmrO8w1mcdJFe3vC1zCt2/xZejUo9FIkBbR26WuifV3u2ghTnO1u2fBuDp4K
pNISU4DVPVyqNwmNyxQgbaDDhPPk4lbco/o+UdBq34RkdI1DgTBDSB5nlCh4PvHJ
xh9Rq9yRXt/CE2fcJQ8GOfMEm2QtdFOrS3N42LanaDkPgcVsJEdVZVv2xIgE4Xb2
lyxyTqsTdZd2lZNf97bRsaMVSJF1QQRED5Bn77L75ltGVzNRASBTUOBrkzl/3er/
zIj0ofuM2akwd5djcJGmo3Yr2tlddhgW7kdcU7CaREWLHbtIlmYP7u9xyxH+3Eci
8yTvusKq8oCCCk6kMsSjeb0Lfrz8FQp4CN6FJaAQocZ1x2JboSWyYumpatjAjuFO
+9dDUQ4DvyGscr1cvcF3B9vlMWAeHjw=
=K4I8
- -END PGP SIGNATURE-

-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmRfb0cgHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHUdvA/+IuTSoZc1wCJs
9wASWUh7lwiiaORTYnQEbbrdTVOlB/ERA/Fkk9QJ6lI9kwellFBjPgmQG7NLWJbJ
Ln6++0Kofls4y1tvpgySIajLaYYlwZYUh1piyzYXMI3MLgn1IK59d8O9lsGVz/cl
ZHMqTL9NR/TWo9WtZwcCdiPsX6H3+C4gG6ia3Lh1xiYbuBiFKxiBFJHF0ztGPNFe
ETKrpKRTR2MeHKxr8IGIc4Ue8HbR8BAY+dtt/zebtVA2k3hzHwcuctYI6QsWjxD2
jCNybiGmaQyT3L27oHCCdQCPWFmqo0ovk7LlzD8uFAklZAhFCtB1IGYqZ438LbM/
7PPVj8GSNkCRxaAvBs2vZDJR1e63F8Hoq1i+98mmwYeP6KwVtDrBWVTHW2kurzaK
1NrIe0vzGfqBXHvpTxmkn60Aec2pL0082wXi7VqrG7haAkSU0UQIP50LxWgIUDsL
H/lE1KOx53U5Go7kLi66J6kbSb9prl7uHdBw6DmSgSpHQfGRvwEil8GiBxuqkwnU
rlqUzTATFuKivq1bk4jZa0BlIZRG8/u38qsT7rYcmWIKnBBDmvljYzgY044fImWP
VBkxjNiUYnbs6nBwNiHbITLmB40q2bvxhL2RThYCFeyKEMtSKPxna7uOlTWpChUX
KSumkNhJ3XPGb5L/bQKSLO3MtNna3ZI=
=uBLb
-END PGP SIGNATURE-

Bug#1034406:

[David Bisbal]

Have you received it

Bug#1035009: libocct-data-exchange-dev: missing Breaks+Replaces for liboce-modeling-dev when upgrading from bullseye

[Helmut Grohne]

Control: retitle -1 libocct-data-exchange-dev missing Conflicts: 
liboce-modeling-dev, liboce-visualization-dev

Hi Tobi,

Please Cc me if you want a reply.

On Mon, May 01, 2023 at 11:30:31AM +0200, Tobias Frost wrote:
> I cannot reproduce this.  liboce-foundation-dev liboce-modeling-dev is 
> deinstalled here when
> trying to installing libocct-data-exchange-dev. 
> libocct-data-exchange-dev depends on libocct-foundation-dev, which conflicts 
> liboce-foundation-dev.
> liboce-modeling-dev is depending on liboce-foundation-dev, so the conflict is 
> inherited.
> 
> Any hints what I am missing?

This is a tough one and you may say it is hair splitting. Due to the
dependencies involved, you cannot actually coinstall these packages.
When apt encounters this situation it will usually remove packages
before installing others, so when using apt, you usally cannot observe
this situation. That said, the resolver's decisions are subtle, so the
fact that you cannot presently observe it is an implementation detail
not to be relied on. You can observe it when using dpkg directly
however.

Keep in mind that Depends don't have to be satisfied in order to unpack
a package, so libocct-data-exchange-dev can be unpacked without its
dependency on libocct-foundation-dev being satisfied. Doing so is legal.
When libocct-foundation-dev is not installed, its conflicts are not in
effect either, so you really can get this unpack error (though not
easily).

I think this is worth fixing in bookworm anyhow.
 * Adding these Conflicts is a very simple measure with low risk.
 * The underlying Conflicts are an implementation detail that might
   change down the road, so changes to other packages may render this
   package rc buggy later.
 * Spelling out all of these "hidden" conflicts with Conflicts
   declarations makes static analysis of the archive way simpler as we
   can just treat this situation as an error in all cases. In reality,
   it's just this instance left since Thorsten fixed python3-meep, which
   had a similar instance.

As such, I'd appreciate if you could bump up the severity again and push
this simple change to bookworm.

Helmut

Bug#793740: kwrite: spell checking does not work at all

[Bryan F. Ritter]

Having both `hspell` and `sonnet-plugins` installed will at least get rid of 
Hspell error messages.*


* On Debian 12. Didn't test if it changes/fixes/breaks anything else.
Hspell: can't open /usr/share/hspell/hebrew.wgz.sizes.
kf.sonnet.clients.hspell: HSpellDict::HSpellDict: Init failed

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[James Addison]

On Sat, 13 May 2023 at 02:18, Thorsten Glaser  wrote:
>
> James Addison dixit:
>
> >I'm going to stay involved with this thread, but I think that it is
> >upon you to develop or provide further guidance towards a patch if
> >it's something you'd like to have implemented, Thorsten.
>
> I actually have looked into that but I don’t understand the nodejs
> and v8 source code enough to be able. I know C, but not CFrustFrust.
> I would rather prefer asm…

Ok, thanks.  We may be stalled temporarily in that case.

On Sat, 13 May 2023 at 00:20, James Addison  wrote:
> That said: perhaps it could be useful if someone could check whether
> the following commit is relevant to this:
> https://github.com/libuv/libuv/commit/18c7530a75d813801f819caae4dff47fc4a1d4a1

I ran the repro case (with some simplifications) from the GitHub
thread using 'strace' and grepped for rlimit-related syscalls:

  # on arm64, this currently replicates the problem using debian bookworm
  $ strace babeljs --config-file $PWD/babel.config.json --compact
false --source-maps inline -d tests5 auto_tests 2>&1 | grep -i rlimit

All of the resulting calls (on an ARM64 host) are to the 'prlimit64'
syscall and have a zero exit-code (success).

Bug#953997: obsolete conffiles after upgrade

[Andrea Bolognani]

On Fri, May 12, 2023 at 04:36:14PM +0200, Christoph Anton Mitterer wrote:
> On Fri, 2023-05-12 at 14:27 +0200, Andrea Bolognani wrote:
> > I think at this point we can assume that most people who have hit the
> > issue on upgrade will have cleaned things up manually by now, so I'd
> > be inclined to close the bug and move on.
> > 
> > Any objections?
> 
> Well not a strong objection from my side, but I think typically most
> people will rather simply not even notice that they have leftover
> files, so they'll stay there forever unless cleaned up properly.

I understand that, and ideally I would love to keep things tidy.
However, I'm afraid we might have missed our chance.

At this point, nobody is going to be upgrading from 5.6.0-3, but from
a more recent version of libvirt-daemon-system where the conffiles in
question are already not considered part of the package.

Note that these conffiles are not actually gone, they've just been
migrated to the libvirt-daemon-system-sysv. So we can't simply delete
them from the system without a version check, otherwise we'd break
all sysvinit users.

I can't think of a simple, reliable way to handle cleaning up under
our current circumstances.

Another thing to keep in mind is that we're likely going to move
these conffiles *back* for trixie[1], or possibly move them to some
newly-introduced packages. That's going to be tricky (ah!) already,
and I'd rather not complicate things further by layering that work on
top of some late cleanup code.


[1] https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/169
-- 
Andrea Bolognani 
Resistance is futile, you will be garbage collected.


signature.asc
Description: PGP signature

Bug#1035438: cl-quicklisp: installation instructions do not work

[Sébastien Villemot]

Le samedi 13 mai 2023 à 04:45 -0400, Michael P. Soulier a écrit :
> On 13/05/23 Sébastien Villemot said:
> 
> > Indeed it looks like the recommendation to use “sbcl --script …” is
> > incorrect, since SBCL terminates after loading the file, without giving
> > access to a REPL from which you could do the installation.
> > 
> > You should follow the other installation option given in the same
> > README file, which is to use (load #p"/usr/share/common-
> > lisp/source/quicklisp/quicklisp.lisp") in the REPL before running
> > (quicklisp-quickstart:install).
> 
> I found that it did not work for me. I had to grab the latest quicklisp from 
> the
> website.

I tested it locally and this alternative method works. Can you share
the error message you get?

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1036015: linux-image-6.3.0-0-amd64: Bluetooth mouse connect very delay after wake up from suspend

[Diederik de Haas]

On Saturday, 13 May 2023 11:09:46 CEST Diederik de Haas wrote:
> On Saturday, 13 May 2023 03:02:50 CEST xiao sheng wen wrote:
> > Package: src:linux
> > Version: 6.3.1-1~exp1
> 
> You reported the issue against version 6.3.1-1, but that version isn't
> mentioned in your bug report. What's the status with that version?

I would normally advise against installing 'random' kernel versions on a 
Debian Stable system, but as you already installed the kernel from 
Experimental, can you also try 6.1.0-9?
Earlier today we had a user who reported that that version fixed a bluetooth 
issue for them.

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

Bug#1036022: altos,lprint: undeclared file conflict on /usr/lib/x86_64-linux-gnu/systemd/system

[Helmut Grohne]

Package: altos,lprint
Severity: serious
X-Debbugs-Cc: a...@debian.org

Hi,

while Andreas usually files bugs about file conflicts, his tooling seems
to have missed this one. It's quite special. While altos ships
/usr/lib/x86_64-linux-gnu/systemd/system as a directory containing a
systemd unit, lprint ships this location as a regular file containing a
systemd unit. So this is a case of a directory versus regular file
conflict and it is the only instance in the archive. Trying to unpack
both results in an error from dpkg, e.g.:

| Unpacking altos (1.9.16-1) ...
| dpkg: error processing archive 
/tmp/apt-dpkg-install-buVwGL/106-altos_1.9.16-1_amd64.deb (--unpack):
|  trying to overwrite '/usr/lib/x86_64-linux-gnu/systemd/system', which is 
also in package lprint 1.1.0-2
| dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

Quite evidently, this is wrong on multiple levels. systemd does not
search multiarch paths for service units and the way lprint packages up
its service file is just plain wrong. I think both altos and lprint need
to be fixed to properly place their unit files.

Helmut

Bug#1036021: cadabra2,python3-notebook: undeclared file conflict on /usr/lib/python3/dist-packages/notebook/static/components/codemirror

[Helmut Grohne]

Package: cadabra2,python3-notebook
Severity: serious
X-Debbugs-Cc: a...@debian.org, debian-d...@lists.debian.org

Hi,

I noticed a suprising undeclared file conflict. While Andreas' tooling
finds most of these, it missed this one.  It's about
/usr/lib/python3/dist-packages/notebook/static/components/codemirror. In
cadabra2, this is a directory. In python3-notebook, this is a symbolic
link. Since dpkg does not yet track the type of files, it does not
notice this conflict and the result depends on the unpack order. Worse,
due to the symbolic link, aliasing (and its bad effects) may happen.

As such, these packages should coordinate what to do about the file.
Failing that, they must declare Conflicts for one another.

I think this is the only instance of a directory vs symlink conflict in
unstable at present.

Helmut

Bug#1036015: linux-image-6.3.0-0-amd64: Bluetooth mouse connect very delay after wake up from suspend

[Diederik de Haas]

Control: tag -1 moreinfo

On Saturday, 13 May 2023 03:02:50 CEST xiao sheng wen wrote:
> Package: src:linux
> Version: 6.3.1-1~exp1

You reported the issue against version 6.3.1-1, but that version isn't 
mentioned in your bug report. What's the status with that version?

> When I use Debian 11.6, the kernel is linux-image-5.10.0-21-rt-amd64,
> there is not this bug. After I upgrade to Debian 11.7, the kernel is
> linux-image-5.10.0-22-rt-amd64, this bug take place.

Does the same regression happen with the non-rt versions of those 5.10 
kernels?
The best way to track down the cause of this regression is to do a `git 
bisect` of the kernel between 5.10.162 and 5.10.178.
https://wiki.debian.org/DebianKernel/GitBisect has instructions for it.

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

Bug#1035438: cl-quicklisp: installation instructions do not work

[Michael P. Soulier]

On 13/05/23 Sébastien Villemot said:

> Indeed it looks like the recommendation to use “sbcl --script …” is
> incorrect, since SBCL terminates after loading the file, without giving
> access to a REPL from which you could do the installation.
> 
> You should follow the other installation option given in the same
> README file, which is to use (load #p"/usr/share/common-
> lisp/source/quicklisp/quicklisp.lisp") in the REPL before running
> (quicklisp-quickstart:install).

I found that it did not work for me. I had to grab the latest quicklisp from the
website.

Cheers,
Mike


signature.asc
Description: PGP signature

Bug#1035438: cl-quicklisp: installation instructions do not work

[Sébastien Villemot]

Control: severity -1 minor

Dear Michael,

Le mercredi 03 mai 2023 à 09:23 -0400, Michael P. Soulier a écrit :
> Package: cl-quicklisp
> Version: 20150128-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: msoul...@digitaltorque.ca
> 
> Dear Maintainer,
> 
> I followed the instructions in the README
> 
> msoulier@cortado:~$ sbcl --script /usr/share/common-
> lisp/source/quicklisp/quicklisp.lisp
> 
>    quicklisp quickstart 2015-01-28 loaded 
> 
> To continue with installation, evaluate: (quicklisp-quickstart:install)
> 
> For installation options, evaluate: (quicklisp-quickstart:help)
> 
> So I loaded sbcl and ran the command:
> 
> * (quicklisp-quickstart:install)
> 
> debugger invoked on a SB-INT:SIMPLE-READER-PACKAGE-ERROR in thread
> #:
>   Package QUICKLISP-QUICKSTART does not exist.
> 
> So the installation did not make the library available, and it cannot be used.

Thanks for your report.

Indeed it looks like the recommendation to use “sbcl --script …” is
incorrect, since SBCL terminates after loading the file, without giving
access to a REPL from which you could do the installation.

You should follow the other installation option given in the same
README file, which is to use (load #p"/usr/share/common-
lisp/source/quicklisp/quicklisp.lisp") in the REPL before running
(quicklisp-quickstart:install).

Best regards,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1036020: RFS: lighttpd/1.4.70-1 [NMU] -- light, fast, functional web server

[Glenn Strauss]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: gs-bugs.debian@gluelogic.com

Dear mentors,

I am looking for a DD sponsor for my package "lighttpd":

https://salsa.debian.org/debian/lighttpd/

I am an upstream lighttpd developer and have participated in
maintaining lighttpd on Debian for a number of years.

I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd

lighttpd-1.4.70-1 is passes autopkgtests and CI, and is tagged.
(This is not actually an NMU, but a non-DD maintainer upload.)

 * Package name : lighttpd
   Version  : 1.4.70-1
   Upstream contact : team+light...@tracker.debian.org
 * URL  : https://lighttpd.net/
 * License  : BSD-3-Clause
 * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4

Please help me to get lighttpd 1.4.70 into Debian Bookworm.

Thank you.  Glenn

Bug#1036019: debian-installer: Broken X display with QEMU under UEFI with cirrus and std graphics

[Cyril Brulebois]

Package: debian-installer
Version: 20230427
Severity: important
X-Debbugs-Cc: debian-...@lists.debian.org, debian-ker...@lists.debian.org, 
debia...@lists.debian.org

Hi everyone,

I'm reaching out to all the aforementioned teams because I know nothing
about UEFI, kernel-side DRM modules, or X drivers, and I'd like to get
some feedback here.

If you need a TL;DR, you can skip to “Proposal plan for d-i”, which is
about my plans for the very next few hours, unless someone tells me the
proposal is crazy, unsafe, etc.


Backstory
=

Since we've been hitting and/or (re)discovering UEFI-specific issues
lately (#1033913), I decided to spend some time extending my usual
tests, traditionally run under QEMU with default settings, therefore
booted under BIOS, to also run them under UEFI (meaning also testing
Secure Boot without having to switch to baremetal).

I've been kindly pointed by regular image testers to the following page:
  https://wiki.debian.org/SecureBoot/VirtualMachine

But I was a little shocked to discover a broken X display when booting
under UEFI! It seems I'm not the only one since that page has the
following, even if there are no references to any bug reports:

-vga virtio - The Debian installer seems to have difficulties
  working with the standard VGA driver (and virtio
  should anyway have better performance) 

The test setup is described at the very end of this report, with my
current test target being specifically netboot/gtk/mini.iso for amd64.


Kernel-side
===

The fb-modules udeb hasn't changed much since 4+ years, with some DRM
modules getting added alongside existing ones, leading to the following
contents in Bullseye (5.10.178-3):

./lib/modules/5.10.0-22-amd64/kernel/drivers/gpu/drm/drm_kms_helper.ko
./lib/modules/5.10.0-22-amd64/kernel/drivers/gpu/drm/drm.ko
./lib/modules/5.10.0-22-amd64/kernel/drivers/gpu/drm/virtio/virtio-gpu.ko
./lib/modules/5.10.0-22-amd64/kernel/drivers/media/cec/core/cec.ko
./lib/modules/5.10.0-22-amd64/kernel/drivers/video/fbdev/vga16fb.ko
./lib/modules/5.10.0-22-amd64/kernel/drivers/video/vgastate.ko
./lib/modules/5.10.0-22-amd64/kernel/drivers/virtio/virtio_dma_buf.ko

and the following contents in Bookworm (6.1.27-1):

./lib/modules/6.1.0-9-amd64/kernel/drivers/gpu/drm/drm_kms_helper.ko
./lib/modules/6.1.0-9-amd64/kernel/drivers/gpu/drm/drm.ko
./lib/modules/6.1.0-9-amd64/kernel/drivers/gpu/drm/drm_shmem_helper.ko
./lib/modules/6.1.0-9-amd64/kernel/drivers/gpu/drm/virtio/virtio-gpu.ko
./lib/modules/6.1.0-9-amd64/kernel/drivers/video/fbdev/vga16fb.ko
./lib/modules/6.1.0-9-amd64/kernel/drivers/video/vgastate.ko
./lib/modules/6.1.0-9-amd64/kernel/drivers/virtio/virtio_dma_buf.ko

Those contents are defined via those files in linux.git:

kibi@tokyo:~/debian-kernel/linux.git (sid=)$ cat 
debian/installer/modules/amd64/fb-modules
#include 

vesafb ?
vga16fb

kibi@tokyo:~/debian-kernel/linux.git (sid=)$ cat 
debian/installer/modules/fb-modules
# We don't include all DRM drivers here as on many platforms we can
# call system firmware to get hold of a simple framebuffer

drm
drm_kms_helper
virtio-gpu ?


X-side
==

Now, we know that the contents of xserver-xorg-core-udeb have changed a
little between Bullseye and Bookworm (#1035014), but that doesn't seem
to be a factor here.

I've tested 3 netboot/gtk/mini.iso to assess the situation:

 - mini-20210731+deb11u8.iso from Bullseye 11.7
 - mini-20230427.iso from D-I Bookworm RC 2
 - mini-daily.isofrom D-I daily builds (downloaded today)

If people want to replicate those tests, they're available at:
  https://people.debian.org/~kibi/bug-drm-vs-uefi/

Or:

wget 
https://deb.debian.org/debian/dists/bullseye/main/installer-amd64/20210731+deb11u8/images/netboot/gtk/mini.iso
 -O mini-20210731+deb11u8.iso
wget 
https://deb.debian.org/debian/dists/bookworm/main/installer-amd64/20230427/images/netboot/gtk/mini.iso
 -O mini-20230427.iso
wget https://d-i.debian.org/daily-images/amd64/daily/netboot/gtk/mini.iso 
-O mini-daily.iso


Via QEMU, under BIOS and UEFI, results are:

  +-+-+-+-+
  |  Graphics   |  Bullseye 11.7  |  Bookworm RC 2  |  Daily builds   |
  +-+++++++
  | |  BIOS  |  UEFI  |  BIOS  |  UEFI  |  BIOS  |  UEFI  |
  +-+++++++
  | |   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
  | -vga std|   OK   |   OK   |   OK   |  KO-G  |   OK   |  KO-G  |
  | -vga cirrus |   OK   |   OK   |   OK   |  KO-S  |   OK   |  KO-S  |
  | -vga qxl|   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
  | -vga virtio |   OK   |   OK   |   OK   |   OK   |   OK   |   OK   |
  | -vga vmware |   OK   |   OK   |   OK   |   OK   |   OK   

Bug#1035832: libssh: CVE-2023-1667 CVE-2023-2283

[Salvatore Bonaccorso]

Hi Martin,

On Wed, May 10, 2023 at 08:19:42AM +0200, Martin Pitt wrote:
> Control: tag -1 pending
> 
> Hello Salvatore,
> 
> Salvatore Bonaccorso [2023-05-09 22:30 +0200]:
> > The following vulnerabilities were published for libssh.
> >
> > CVE-2023-1667[0]:
> > | Potential NULL dereference during rekeying with algorithm guessing
> >
> > CVE-2023-2283[1]:
> > | Authorization bypass in pki_verify_data_signature
> >
> > If you fix the vulnerabilities please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> I uploaded the new upstream release to unstable, with urgency=high to 
> hopefully
> make it into the release in time. With upstream's extensive unit tests and
> Debian's reverse dependency autopkgtesting etc. I have enough confidence in
> that.

Thanks for preparing the update. Note that at this stage of the freeze
it won't migrate anymore automatically. Can you please request for an
unblock by the release team? Note there is a strict deadline
approaching, so that should happen quickly. Note I'm not sure if
release team will want to have

  * Bump Standards-Version to 4.6.2. No changes necessary.
and
  * Bump debhelper from old 12 to 13.
  * Avoid explicitly specifying -Wl,--as-needed linker flag.

included in this stage of the release.

> I also checked buster. It's not affected by CVE-2023-2283, that code does not
> exist in the 0.8 branch at all. The code for CVE-2023-1667 does exist, but it
> is wildly different. Upstream does not maintain the 0.8 branch any more, and
> I'm afraid I will not have the time/skills to analyze, understand, and 
> backport
> the patches myself, at least not to an extent where I'd have faith in them.
> 
> I'll attempt to backport the fixes for stable now.
> https://git.libssh.org/projects/libssh.git/log/?h=stable-0.9 has quite some
> changes before and beyond the actual security fix: some memory leak fixes,
> moving some code around, indentation fixes, more unit tests. Personally I'd
> rather trust upstream's release validation and update to 0.9.7 wholesale than
> trying to pick it apart, but how is the Debian security team stanza wrt.
> upstream microreleases these days?

Thanks for this mail and the followup with the proposed update. We
come back to you on it.

Regards,
Salvatore

Bug#1031850: gcc-13: Change "loongarch64-linux-gnuf64" into "loongarch64-linux-gnu"

[Matthias Klose]

On 13.05.23 09:41, zhangdandan wrote:

Control: tags -1 moreinfo

Hi gcc maintainers,

     I am particularly sorry for the lack of replies under this bug.

在 2023/3/5 下午5:12, Matthias Klose 写道:

Control: tags -1 + moreinfo

This needs documentation in
https://wiki.debian.org/Multiarch/Tuples


We have added documentation in https://wiki.debian.org/Multiarch/Tuples.
Please review the added information [1] related to LoongArch64.

[1]: 
https://wiki.debian.org/Multiarch/Tuples#fnref-607863550593b35d97abb9ba30075128dc27d0cc


thanks,
Dandan Zhang



that link describes four different ABIs. I cannot see which one is the one 
proposed for Debian. Please clarify on the wiki page.


Please also note that these changes cannot be made before this support is 
backported in dpkg for the Debian stable release.

Bug#1031850: gcc-13: Change "loongarch64-linux-gnuf64" into "loongarch64-linux-gnu"

[zhangdandan]

Control: tags -1 moreinfo

Hi gcc maintainers,

    I am particularly sorry for the lack of replies under this bug.

在 2023/3/5 下午5:12, Matthias Klose 写道:

Control: tags -1 + moreinfo

This needs documentation in
https://wiki.debian.org/Multiarch/Tuples


We have added documentation in https://wiki.debian.org/Multiarch/Tuples.
Please review the added information [1] related to LoongArch64.

[1]: 
https://wiki.debian.org/Multiarch/Tuples#fnref-607863550593b35d97abb9ba30075128dc27d0cc


thanks,
Dandan Zhang

Bug#1036018: ansible-mitogen: filedescriptor out of range in select()

[Slavko]

Package: ansible-mitogen
Version: 0.3.3-8
Severity: important

I have small (6 hosts) ansible setup with mitogen, today i start to get this
exception:

ERROR! [task 13753] 09:30:44.072256 E mitogen: broker crashed
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/mitogen/core.py", line 3588, in 
_do_broker_main
self._loop_once()
  File "/usr/lib/python3/dist-packages/mitogen/core.py", line 3543, in 
_loop_once
for side, func in self.poller.poll(timeout):
  File "/usr/lib/python3/dist-packages/mitogen/core.py", line 2465, in _poll
(rfds, wfds, _), _ = io_op(select.select,
 
  File "/usr/lib/python3/dist-packages/mitogen/core.py", line 567, in io_op
return func(*args), None
   ^^^
ValueError: filedescriptor out of range in select()
An exception occurred during task execution. To see the full traceback, use 
-vvv. The error was: mitogen.core.ChannelError: the respondent Context has 
disconnected
fatal: [servac2]: FAILED! => {"msg": "Unexpected failure during module 
execution: the respondent Context has disconnected", "stdout": ""}

Raising ulimit -n doesnþt solve this, it was working with the same
setup about week ago... Running it with single host works as expected...

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=sk_SK.UTF-8, LC_CTYPE=sk_SK.UTF-8 (charmap=UTF-8), LANGUAGE=sk:cs
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ansible-mitogen depends on:
ii  ansible  7.3.0+dfsg-1
ii  ansible-core 2.14.3-1
ii  python3  3.11.2-1+b1
ii  python3-mitogen  0.3.3-8

ansible-mitogen recommends no packages.

ansible-mitogen suggests no packages.

-- no debconf information

Bug#1035685: unblock: mpdscribble/0.24-2+b1

[kaliko]

control: tags -1 - moreinfo

On 11/05/23, Paul Gevers wrote:
> Control: tags -1 confirmed moreinfo
> Control: retitle -1 unblock: mpdscribble/0.24-3
> 
> Hi,
> 
>  On 07-05-2023 20:58, kaliko wrote:
> > During bookworm development the package was refactored and
> > a bug was introduced in the conf file management.
> > piuparts recently spotted the issue and #1035603 was reported.
> 
> Please go ahead and remove the moreinfo tag once the upload happened.
Uploaded
Thanks


signature.asc
Description: PGP signature