Bug#1006605: xserver-xorg-video-radeon: on login; any desktop which has screen orientation saved as portrait logs out

[Vasyl Gello]

Package: xserver-xorg-video-radeon
Version: 1:19.1.0-2+b1
Followup-For: Bug #1006605

Dear colleagues,

I am experiencing the same kernel OOPS everytime I log the graphical session 
out.
The screens are laptop's built-in (LVDS) and the external TV‌ plugged via HDMI.

If no patch is available soon I will try to investigate an issue and craft one.


Vasyl

Bug#1006504: bullseye-pu: package bash/5.1-6~deb11u1

[Salvatore Bonaccorso]

Hi Julien,

On Sun, Mar 27, 2022 at 09:18:06PM +0200, Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> On Sun, Mar 27, 2022 at 09:04:03PM +0200, Salvatore Bonaccorso wrote:
> > Okay attached the alternative, and only cherry-pick the 014 patch
> > upstream to address #1003012. Would that be acceptable instead?
> > 
> That's fine, thanks.

Thanks Julien. Uploaded.

Regards,
Salvatore

Bug#975505: Please package v3.0.5 or newer

[Yadd]

On 27/03/2022 21:51, Yadd wrote:

On 27/03/2022 17:03, Nicholas D Steeves wrote:

Hi Dmitry and Xavier!

Dmitry Shachnev  writes:


On Sun, Nov 22, 2020 at 10:27:43PM -0500, Nicholas D Steeves wrote:

Dear MathJax maintainers,

Debian's MathJax is out of date (2.7.9), and I've noticed that some 
packages

have had to start to resort to bundling a 3.x release.  Please package
v3.0.5 or newer.


MathJax v3 is a complete rewrite of MathJax, and it is incompatible with
MathJax v2 [1].

So MathJax v3 needs to be packaged as a new source and binary package,
therefore this bug is RFP, not a request for upgrade.

Actually, an RFP was already filed, so I am merging this bug into that.



That makes sense if MathJax v2 will remain part of the archive :-)

I am not going to do it myself because I don't have any nodejs or 
typescript
skills (the source code [2] is using them now), but if you or someone 
else

who reads this believes they can handle it, please do it.



Sounds good!  Likewise, MathJax is too important for me to make it my
first nodejs or typescript package, while also lacking skills for truly
responsible maintenance :-)

Xavier, I noticed that you tagged this bug as pending, but I couldn't
find the package in the archive, or in the NEW queue.  Maybe there is
not-yet-uploaded work somewhere?


Hi,

I'm going to build mathjax3. It will conflicts/breaks mathjax. Is it OK 
for you ?


Cheers,
Yadd


This needs to package node-mj-context-menu and node-speech-rule-engine. 
Note also that font-* files are no more included in mathjax-3

Bug#1006424: 4 weeks later

[Schubert Christian]

Is there any news?

 


TU Bergakademie Freiberg

Christian Schubert, B.Sc.
Institut fuer Informatik
Bernhard-von-Cotta Straße 2 / Zimmer 104
D-09596 Freiberg
Telefon: +49 3731 39 3342


 



smime.p7s
Description: S/MIME cryptographic signature

Bug#1008508: borgbackup: Uninstallable in Debian Unstable due dependency on python 3 < 3.10

[Axel Beckert]

Hi,

Axel Beckert wrote:
> borgbackup became uninstallable in Debian Unstable due a dependency on
> python3 < 3.10 while Python 3.10 has landed in Unstable yesterday.

Ah, I just saw
https://release.debian.org/transitions/html/python3.10-default.html so
I assume this can be fixed with a BinNMU which probably will be done
by the release team.

Sorry for the noise.

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#1008508: borgbackup: Uninstallable in Debian Unstable due dependency on python 3 < 3.10

[Axel Beckert]

Package: borgbackup
Version: 1.2.0-1
Severity: serious

Hi,

borgbackup became uninstallable in Debian Unstable due a dependency on
python3 < 3.10 while Python 3.10 has landed in Unstable yesterday.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages borgbackup depends on:
ii  libacl12.3.1-1
ii  libc6  2.33-7
ii  liblz4-1   1.9.3-2
ii  libssl1.1  1.1.1n-1
ii  libxxhash0 0.8.1-1
ii  libzstd1   1.4.9+dfsg-1
ii  python33.9.8-1
ii  python3-msgpack1.0.3-1
ii  python3-packaging  21.3-1
ii  python3-pkg-resources  59.6.0-1.2

Versions of packages borgbackup recommends:
ii  fuse3 [fuse] 3.10.5-1
ii  python3-llfuse   1.4.1+dfsg-2
pn  python3-pyfuse3  

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

Bug#1008507: libc6: pathconf("mountpont of FAT filesystem", _PC_LINK_MAX) returns 127, expected 1

[Joshua]

Package: libc6
Version: All of them
Severity: normal
Tags: newcomer

Dear Maintainer,

what lead up to the situation is well-described in my stackoverflow post:
https://stackoverflow.com/questions/71641957/how-to-check-if-a-filesystem-supports-hard-links-in-linux

Since posting it, I have traced the bug through the glibc sources and found 
that it's bugged.
There's cases for common filesystems that have nonstandard values, but you 
almost never care
what the actual value is.

On the other hand, there are no cases for writable filesystems that simply 
don't have hard links.
(FAT). EXFAT would also fall into this but that only exists as a FUSE module 
right now.

These turn out to be the ones we care about becasue they are three of the four 
widely supported
filesystems on removable media (with the fourth being UDF).

Writing a patch is trivial. Getting it into glibc, well I'm gonna try but you 
may have more luck.

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

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit-sysv
LSM: AppArmor: enabled

Bug#1008275: libsane: Reinstate libieee1284 support for parallel printers

[Ralph Little]

Hi,

On 2022-03-26 16:37, Gunnar Hjalmarsson wrote:

Control: reopen -1

Hi Jörg,

Jörg Frings-Fürst wrote:

[quote]
ifeq (,$(filter hurd-i386,$(DEB_HOST_ARCH)))
    INS_CONF = --enable-parport-directio
else
    INS_CONF = ""
endif
[/quote]

and

[quote]
  --disable-locking \
  $(INS_CONF)
[/quote]

--enable-parport-directio thus only becomes active in the hurd-i386
architecture.


No. It's the other way around, i.e. it becomes active in all 
architectures except hurd-i386. ;)


Reopening so you can take a stand on that ground.



I tried the logic here just to make sure I understood what was going on 
here:


---makefile-
ifeq (,$(filter hurd-i386,$(DEB_HOST_ARCH)))
    INS_CONF = --enable-parport-directio
else
    INS_CONF = ""
endif

test:   makefile
    echo $(INS_CONF)



$ DEB_HOST_ARCH=hurd-i386 make -n -f makefile
echo ""
$ DEB_HOST_ARCH=arm64 make -n -f makefile
echo --enable-parport-directio

The logic really does seem to be reversed, such that 
--enable-parport_directio is enabled for every arch except hurd.


What is strange though is that if I disable the sane-git PPA to use 
1.0.27 from Ubuntu standard repo, I get this:


[sanei_debug] Setting debug level of plustek_pp to 50.
[sanei_debug] Setting debug level of sanei_pp to 50.
[sanei_pp] pp_init: called for the first time
[sanei_pp] pp_init: initializing libieee1284
[sanei_pp] pp_init: 1 ports reported by IEEE 1284 library
[sanei_pp] pp_init: port 0 is `parport0`
[sanei_pp] pp_init: initialized successfully

So it really is using libieee1284 in this case.
So I'm pretty confused.
Has this build code changed recently?

Cheers,
Ralph

Bug#1008481: Add SDL_IM_MODULE to fcitx4 and fcitx5

[Osamu Aoki]

Hi,

These bugs seem somewhat similar:

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

Please check these.

> -Original Message-
> From: Shengjing Zhu 
> Reply-To: Shengjing Zhu , 1008...@bugs.debian.org
> To: Debian Bug Tracking System 
> Subject: Bug#1008481: Add SDL_IM_MODULE to fcitx4 and fcitx5
> Date: Sun, 27 Mar 2022 15:06:22 +0800
> 
> Source: im-config
> Version: 0.50-2
> Severity: wishlist
> X-Debbugs-Cc: z...@debian.org
> 
> Origin from
> https://salsa.debian.org/input-method-team/im-config/-/merge_requests/14
> 
> I asked the author to submit a bug first. But we haven't received so far.
> 
> sdl2 supports reading SDL_IM_MODULE, but the supported value is only fcitx,
> otherwise it uses ibus.
> 
> Fcitx support in sdl2 package:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881042
> Upstream code:
> https://github.com/libsdl-org/SDL/blob/120c76c8/src/core/linux/SDL_ime.c#L46-L49
> 
> So adding SDL_IM_MODULE=fcitx to fcitx4 and fcitx5 is reasonable.
> 

So question is "Does sdl upstream recommend turning on IM_MODULE as default?

Also, I am a bit concerned to add features for external program fearng some
regressions.  Please explain this has no negative side effects.

Can we resolve this by adding README for some special case situation.

Osamu

Bug#1008505: dkms: crazy UI difference between success and error case leading to admin not noticing the latter

[Thorsten Glaser]

Package: dkms
Version: 2.6.1-4
Severity: important

When DKMS is successful, we see output like this:

-BEGIN cutting here may damage your screen surface-
Preparing to unpack .../iproute2-dbgsym_5.10.0-4~jens+6_amd64.deb ...
Unpacking iproute2-dbgsym (5.10.0-4~jens+6) over (5.10.0-4~jens+5) ...
Preparing to unpack .../sch-jens-dkms_5.10.0-4~jens+6_all.deb ...

 Uninstall Beginning 
Module:  sch-jens
Version: 5.10.0
Kernel:  4.19.0-17-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

sch_jens.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.19.0-17-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod.

DKMS: uninstall completed.

 Uninstall Beginning 
Module:  sch-jens
Version: 5.10.0
Kernel:  4.19.0-18-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

sch_jens.ko:
 - Uninstallation
   - Deleting from: /lib/modules/4.19.0-18-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod

DKMS: uninstall completed.

 Uninstall Beginning 
Module:  sch-jens
Version: 5.10.0
Kernel:  5.10.0-0.bpo.8-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

sch_jens.ko:
 - Uninstallation
   - Deleting from: /lib/modules/5.10.0-0.bpo.8-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod...

DKMS: uninstall completed.

--
Deleting module version: 5.10.0
completely from the DKMS tree.
--
Done.
Unpacking sch-jens-dkms (5.10.0-4~jens+6) over (5.10.0-4~jens+5) ...
Preparing to unpack .../iproute2_5.10.0-4~jens+6_amd64.deb ...
Unpacking iproute2 (5.10.0-4~jens+6) over (5.10.0-4~jens+5) ...
Preparing to unpack .../iproute2-doc_5.10.0-4~jens+6_all.deb ...
Unpacking iproute2-doc (5.10.0-4~jens+6) over (5.10.0-4~jens+5) ...
Setting up iproute2-doc (5.10.0-4~jens+6) ...
Setting up iproute2 (5.10.0-4~jens+6) ...
Setting up iproute2-dbgsym (5.10.0-4~jens+6) ...
Setting up sch-jens-dkms (5.10.0-4~jens+6) ...
Loading new sch-jens-5.10.0 DKMS files...
Building for 4.19.0-18-amd64
Building initial module for 4.19.0-18-amd64
Done.

sch_jens.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.19.0-18-amd64/updates/dkms/

sch_jhtb.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.19.0-18-amd64/updates/dkms/

depmod...

DKMS: install completed.
Processing triggers for man-db (2.8.5-2) ...
-END cutting here may damage your screen surface-

When not, this is shown:

-BEGIN cutting here may damage your screen surface-
[…]
Setting up vim-common (2:8.1.0875-5+deb10u2) ...
Setting up linux-source-5.10 (5.10.103-1~bpo10+1) ...
Setting up libpcap0.8:amd64 (1.8.1-6+deb10u1) ...
Setting up libjbig2dec0:amd64 (0.16-1+deb10u1) ...
Setting up libfaad2:amd64 (2.10.0-1~deb10u1) ...
Setting up libssl-dev:amd64 (1.1.1n-0+deb10u1) ...
Setting up icu-devtools (63.1-6+deb10u3) ...
Setting up linux-config-4.19:amd64 (4.19.235-1) ...
Setting up libisc-export1100:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u7) ...
Setting up libcups2:amd64 (2.2.10-6+deb10u5) ...
Setting up libwavpack1:amd64 (5.1.0-6+deb10u1) ...
Setting up linux-kbuild-5.10 (5.10.103-1~bpo10+1) ...
Setting up libtiff5:amd64 (4.1.0+git191117-2~deb10u4) ...
Setting up xterm (344-1+deb10u2) ...
Setting up vim-runtime (2:8.1.0875-5+deb10u2) ...
Setting up libc-dev-bin (2.28-10+deb10u1) ...
Setting up openssl (1.1.1n-0+deb10u1) ...
Setting up libdns-export1104 (1:9.11.5.P4+dfsg-5.1+deb10u7) ...
Setting up libxml2:amd64 (2.9.4+dfsg1-7+deb10u3) ...
Setting up linux-headers-4.19.0-20-common (4.19.235-1) ...
Setting up linux-kbuild-4.19 (4.19.235-1) ...
Setting up libflac-dev:amd64 (1.3.2-3+deb10u1) ...
Setting up vim (2:8.1.0875-5+deb10u2) ...
Setting up libisc1100:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u7) ...
Setting up linux-image-amd64 (4.19+105+deb10u15) ...
Setting up liblwres161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u7) ...
Setting up libisccc161:amd64 (1:9.11.5.P4+dfsg-5.1+deb10u7) ...
Setting up libc6-dev:amd64 (2.28-10+deb10u1) ...
Setting up libicu-dev:amd64 (63.1-6+deb10u3) ...
Setting up linux-headers-4.19.0-20-amd64 (4.19.235-1) ...
/etc/kernel/header_postinst.d/dkms:
Error! Bad return status for module build on kernel: 

Bug#1008175: #1008175

[rick]

Brian:


PRINT_QUEUE_NAME is the actual name of the queue as given in Okular or
by 'lpstat -a'.


Sorry! Was out at a pub with a friend before responding!  Should have 
waited! ;^)


driverless
ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/

As root:
lpadmin -p testq -v 
"ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/" -E 
-m everywhere


as regular user:
lp -d testq -o sides=two-sided-long-edge lipsum.txt.pdf

Still printed single-sided

The printer was originally setup by the Debian netinst.

Thanks!

Rick


On 2022-03-27 17:01, Brian Potkin wrote:

On Sun 27 Mar 2022 at 15:13:30 -0500, r...@scotsgeek.com wrote:


Brian:

avahi-browse -rt _ipp._tcp
+ enp2s0 IPv6 HP LaserJet Pro M148fdw (6CA573)  Internet 
Printer

local
+ enp2s0 IPv4 HP LaserJet Pro M148fdw (6CA573)  Internet 
Printer

local
= enp2s0 IPv6 HP LaserJet Pro M148fdw (6CA573)  Internet 
Printer

local
   hostname = [NPI6CA573.local]
   address = [192.168.1.207]
   port = [631]
   txt = ["mopria-certified=1.3" "mac=f8:b4:6a:6c:a5:73" "usb_MDL=HP
LaserJet Pro M148f-M149f" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4"
"kind=document,envelope,photo" 
"UUID=564e4733-5931-3235-3934-f8b46a6ca573"
"Fax=T" "Scan=T" "Duplex=T" "Color=F" "note=unitedStates" 
"adminurl=http://NPI6CA573.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus;


The text record advertises that the printer is capable of automatic
duplex ("Duplex=T").

[Snipped text]


driverless
ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/


ipp://... is a URI for the printer. We will try setting up and printing
to a new print queue. Do

  lpadmin -p testq -v "URI" -E -m everywhere

Subdtitute URI with what is above. Test with

  lp -d testq -o sides=two-sided-long-edge test.pdf


lpoptions -p PRINT_QUEUE_NAME -l
lpoptions: Unable to get PPD file for PRINT_QUEUE_NAME: No such file 
or

directory


PRINT_QUEUE_NAME is the actual name of the queue as given in Okular or
by 'lpstat -a'.

Cheers,

Brian.

Bug#1008504: sphinx-common: dh_sphinxdoc can't find files with unicode paths

[Scott Talbert]

Package: sphinx-common
Version: 4.3.2-1
Severity: normal

Dear Maintainer,

dh_sphinxdoc doesn't seem to be able to handle paths with unicode 
characters.  I ran into this error while trying to update pygame to a 
new version:
   dh_sphinxdoc -O--buildsystem=pybuild
dh_sphinxdoc: error: 
debian/python-pygame-doc/usr/share/doc/python-pygame-doc/html/_sources/tut/ko/\ube68\uac04\ube14\ub85d
 \uac80\uc740\ube14\ub85d/1.\ud504\ub864\ub85c\uadf8/\uc18c\uac1c.rst.txt is 
missing

But that file does exist:
$ ls -l 
debian/python-pygame-doc/usr/share/doc/python-pygame-doc/html/_sources/tut/ko/빨간블록\
 검은 블록/1.프롤로그/소개.rst.txt 
-rw-r--r-- 1 talbert talbert 6138 Dec 26 19:57 
'debian/python-pygame-doc/usr/share/doc/python-pygame-doc/html/_sources/tut/ko/빨간블록
 검은블록/1.프롤로그/소개.rst.txt'

It seems like dh_sphinxdoc might need to be able to understand 
Javascript's \u escaping of unicode characters in strings?

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

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

Versions of packages sphinx-common depends on:
ii  libjs-sphinxdoc  4.3.2-1
ii  perl 5.34.0-3

Versions of packages sphinx-common recommends:
ii  python3-sphinx  4.3.2-1

sphinx-common suggests no packages.

-- no debconf information

Bug#1008503: cryptsetup-initramfs: Handle absolute keyfile path for derived key in cryptroot hook

[corubba]

Package: cryptsetup-initramfs
Version: 2:2.3.7-1+deb11u1
Severity: minor
Tags: patch

Dear Maintainer,

when using the `decrypt_derived` keyscript, the `cryptroot` initramfs hook expects the 
`key file` in `/etc/crypttab` to be the `target name` of another crypttab entry. Beside 
the runtime-use as argument to the keyscript, the `key file` is in this case also used 
during initramfs creation to make sure the "parent" is unlocked beforehand. And 
this all works fine. One thing I noticed thought is that systemd throws a few messages 
with such a setup. These appear after the initrd, so with the real root already mounted. 
(I slightly reordered the messages to increase readability)

```
ERROR systemd[1]: 
/run/systemd/generator/systemd-cryptsetup@luks\x2dtwo.service:14: 
RequiresMountsFor= path is not absolute, ignoring: luks-one
[...]
INFO systemd[1]: Starting Cryptography Setup for luks-one...
WARN systemd-cryptsetup[944]: Encountered unknown /etc/crypttab option 
'initramfs', ignoring.
INFO systemd-cryptsetup[944]: Volume luks-one already active.
INFO systemd[1]: Finished Cryptography Setup for luks-one.
INFO systemd[1]: Starting Cryptography Setup for luks-two...
WARN systemd-cryptsetup[910]: Password file path 'luks-one' is not absolute. 
Ignoring.
WARN systemd-cryptsetup[910]: Encountered unknown /etc/crypttab option 
'initramfs', ignoring.
WARN systemd-cryptsetup[910]: Encountered unknown /etc/crypttab option 
'keyscript=/lib/cryptsetup/scripts/decrypt_derived', ignoring.
INFO systemd-cryptsetup[910]: Volume luks-two already active.
INFO systemd[1]: Finished Cryptography Setup for luks-two.
```

I am not worried about the three `Encountered unknown /etc/crypttab option` 
warnings, because they are valid; these options are specific to Debian's 
cryptroot hook. But the other two regarding the non-absolute key file bothered 
me a bit, especially because one is an error. Out of pure curiosity, I changed 
the key file in my crypttab from the target name `luks-one` to the absolute 
block device path `/dev/mapper/luks-one` to see what happens. To my surprise 
does the keyscript not *require* a target name as argument, it also works fine 
with a absolute device path. You get the same result when calling 
`./decrypt_derived luks-one` and `./decrypt_derived /dev/mapper/luks-one` (also 
works with `dev/disk/by-id/...` and others). And the error/warning from systemd 
are gone, plus it now actually adds `dev-mapper-luks\x2done.device` as a proper 
dependency to `systemd-cryptsetup@luks\x2dtwo.service`. The only thing that 
breaks when using a absolute device path is the recursive unlocking, which the 
hook will warn about during initramfs creation:

```
update-initramfs: Generating /boot/initrd.img-5.10.0-13-amd64
cryptsetup: WARNING: target '/dev/mapper/luks-one' not found in /etc/crypttab
```

This can be functionally worked around by not relying on the recursion and 
explicitly setting the initramfs option for all needed entries. But being 
annoyed by that warning, I took a dive into the cryptroot hook sourcecode and 
created the attached patch, which detects a absolute key file and runs it 
through `dmsetup` to resolve it to a target name. With that, both the 
`cryptroot` hook and `systemd-cryptsetup` work.

I saw a few comments in the scripts to not trust `/dev/mapper/` so I am not 
sure if this breaks anything with regards to name-mangling, but I am sure you 
subject experts will be able to easily assess that.


I also acknowledge that one could partially or completely disable the 
systemd-cryptsetup-generator using kernel command line parameters, but that 
would prevent using the generated device/service units directly or as 
dependencies for other units. Unfortunately there is no 
systemd-cryptsetup-generator specific crypttab option to only disable unit 
generation for specific entries. I haven't tried to mask the generated services 
for the hook-handled devices, that would probably also work; the services are 
effectively no-ops in that case anyway.


-- Package-specific info:
-- /proc/cmdline
root=/dev/vgmain/lvroot ro noresume quiet

-- /etc/crypttab
#  
#these two are the pvs of vgmain
luks-one  UUID=xxnoneluks,initramfs
luks-two  UUID=yy/dev/mapper/luks-one
luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived

-- /etc/fstab
#  

/dev/vgmain/lvroot/ xfs   defaults0 
  1
/dev/disk/by-partlabel/esp/boot/efi vfat  umask=0077  0 
  2


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

Kernel: Linux 5.10.0-13-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via 

Bug#1008382: meson 0.62 regression: gtk-doc targets in src:glib2.0 lose their dependencies

[Simon McVittie]

Control: reassign -1 meson 0.62.0-1
Control: retitle -1 meson 0.62 regression: gtk-doc targets in src:glib2.0 lose 
their dependencies
Control: affects -1 + src:glib2.0

On Sat, 26 Mar 2022 at 21:44:54 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > [473/1344] /usr/bin/meson --internal gtkdoc --sourcedir=/<> 
> > --builddir=/<>/debian/build/deb 
> > --subdir=docs/reference/gio/gdbus-object-manager-example 
> > --headerdirs=gio/tests/gdbus-object-manager-example 
> > --mainfile=gdbus-object-manager-example-docs.xml 
> > --modulename=gdbus-object-manager-example --moduleversion= --mode=auto 
> > --gtkdoc-scan=/usr/bin/gtkdoc-scan 
> > --gtkdoc-scangobj=/usr/bin/gtkdoc-scangobj 
> > --gtkdoc-mkdb=/usr/bin/gtkdoc-mkdb --gtkdoc-mkhtml=/usr/bin/gtkdoc-mkhtml 
> > --gtkdoc-fixxref=/usr/bin/gtkdoc-fixxref --namespace=example --htmlargs= 
> > 

Bug#1008502: vdirsyncer: Unknown error occured: unmatched ')'

[Christof Schulze]

Package: vdirsyncer
Version: 0.16.8-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Running vdirsyncer sync causes the above error message about unmatched
')'. This renders 0.4.4 - the version in stable - unusable. The root cause is 
that
python-click-threading 0.4.4, which vdirsyncer is depending on,
introduced an incompatibility with python-click.
More info on the problem can be found in [2] and [3].

The version in testing (0.18.0-6) is working fine as it depends on a
python-click-version that does not have the problem. So installing the
version from testing including its dependencies works.

Would you please upgrade vdirsyncer in stable to the current version in
testing to make the program work again for everyone on stable?

Cheers,

Christof

[1] https://github.com/pimutils/vdirsyncer/pull/891
[2] https://github.com/click-contrib/click-threading/pull/5
[3] https://github.com/pimutils/vdirsyncer/issues/887


-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (990, 'stable'), (400, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages vdirsyncer depends on:
ii  init-system-helpers1.60
ii  python33.9.2-3
ii  python3-atomicwrites   1.4.0-2
ii  python3-click  7.1.2-1
ii  python3-click-log  0.2.1-2
ii  python3-click-threading0.4.4-2
ii  python3-requests   2.25.1+dfsg-2
ii  python3-requests-toolbelt  0.9.1-1

vdirsyncer recommends no packages.

Versions of packages vdirsyncer suggests:
pn  python3-requests-oauthlib  
pn  vdirsyncer-doc 

-- no debconf information

Bug#1008316: dpkg-fsys-usrunmess breaks system boot

[Guillem Jover]

Control: retitle -1 dpkg-fsys-usrunmess: Does not deal with untracked kernel 
modules

Hi!

On Sat, 2022-03-26 at 19:21:44 +0100, Eric Valette wrote:
> Package: dpkg
> Version: 1.21.4
> Severity: critical
> Justification: breaks the whole system

> Gobally the scripts does a very good job but it missed to copy 
> /usr/lib/modules to
> /lib/modules on a self generated kernel that has modules build via dkms and a
> few native kernel modules.

I assume the custom built kernel was installed w/o a .deb package?

> Invoquing the dkms postinstall script fails because it does not find 
> /lib/modules/x.y.z
> directories and rebooting without graphic drivers and other stff does not 
> work.

Just to understand, did dpkg-fsys-usrunmess fail (exited non-zero) while
configuring packages (with dkms)? And then you rebooted?

If so, I guess the error message should be more clear that the system
has many chances of not being in a bootable state. And perhaps add
some instructions on how to proceed or similar. And it should ideally
be restartable (as already requested in another report), which I guess
I'll be working on next.

> So you probably should copy /usr/lib/modules to /lib/modules before the 
> calling the
> postinstall.

Hmm, right, because these were not tracked, they got missed in the
migration. I've checked the Debian archive and at least there, it does
not look like anything else besides kernel modules are being current
shipped in those directories (via apt-file), but the problem is that
I've seen references in source code (via codesearch.d.o) to
/usr/lib/modules, for at least apache and python modules, so I don't
think an unconditional move for untracked files would be safe there.
I'm thinking the following special-case options (in order of decreasing
preference):

  * move only untracked «/usr/lib/modules/[0-9]*» expecting/assuming
those to be kernel modules,
  * copy (not move) all untracked files from «/usr/lib/modules/*» to
«/lib/modules», and print a message at the end, but that will leave
cruft behind if not cleaned up,
  * record them, and print a list at the end of the execution for the
user to deal with, but that can be rather unfriendly, and that can
include usual dkms built modules too,

> To fix i did:
>1) boot in recovery mode,
>2) copy /usr/lib/modules to /lib/modules
>3) dkms autoinstall
>4) update-grub
> 
> and it wworked.

I guess depending on whether the program failed or not that might
change what the better approach might be.

Thanks,
Guillem

Bug#995905: opencolorio v2.* packaging

[Matteo F. Vescovi]

Hi!

On 2022-03-25 at 20:44 (+01), Matteo F. Vescovi wrote:
> It builds for me:
>
>  https://people.debian.org/~mfv/opencolorio_2.1.1+dfsg-1.buildlog

Well, actually I had to rebuild OpenImageIO against OpenEXR v3 (and
disabling OpenVDB as well) before getting over the point where your
build failed (and I was able to rebuild only today due to work
priority).

It's clear that now I need to start the transition for OpenImageIO
before getting OCIO to build without hackery.

Gonna keep you updated on my progress.

Cheers.


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


signature.asc
Description: PGP signature

Bug#1005135: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.103.01-1~deb11u1

[Andreas Beckmann]

On 27/03/2022 19.05, Adam D. Barratt wrote:

Our QA checks noticed an installability issue - the uploaded amd64
libegl-nvidia-tesla-470-0 package depends on "libnvidia-egl-wayland1
(>= 1:1.1.7)", but stable only has 1:1.1.5-1.


Oops, looks like I accidentally uploaded a package built in sid instead
of bullseye (upload with binaries due to NEW).
Could you just binNMU it after it got accepted?

nmu nvidia-graphics-drivers-tesla-470_470.103.01-2~deb11u1 . ANY . bullseye . -m 
"Rebuild in a clean bullseye environment."

Andreas

Bug#1005833: [DRE-maint] Bug#1005833: src:ruby-redis: fails to migrate to testing for too long: autopkgtest regression

[Cédric Boutillier]

Quoting Paul Gevers (2022-03-21 21:13:29)
> Is there any progress on this issue? Is no progress is there another way 
> to move the problem forward? E.g. revert ruby-redis to the previous 
> version if redis and fakeredis can agree on the change in behavior?

I am preparing an upload of ruby-fakeredis with an upstream PR
accomodating the fact that 'exists' returns now an integer, plus some
modifications of the test suite. This should fix the issue.

Best wishes,

Cédric

Bug#1008175: #1008175

[Brian Potkin]

On Sun 27 Mar 2022 at 15:13:30 -0500, r...@scotsgeek.com wrote:

> Brian:
> 
> avahi-browse -rt _ipp._tcp
> + enp2s0 IPv6 HP LaserJet Pro M148fdw (6CA573)  Internet Printer
> local
> + enp2s0 IPv4 HP LaserJet Pro M148fdw (6CA573)  Internet Printer
> local
> = enp2s0 IPv6 HP LaserJet Pro M148fdw (6CA573)  Internet Printer
> local
>hostname = [NPI6CA573.local]
>address = [192.168.1.207]
>port = [631]
>txt = ["mopria-certified=1.3" "mac=f8:b4:6a:6c:a5:73" "usb_MDL=HP
> LaserJet Pro M148f-M149f" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4"
> "kind=document,envelope,photo" "UUID=564e4733-5931-3235-3934-f8b46a6ca573"
> "Fax=T" "Scan=T" "Duplex=T" "Color=F" "note=unitedStates" 
> "adminurl=http://NPI6CA573.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus;

The text record advertises that the printer is capable of automatic
duplex ("Duplex=T").

[Snipped text]

> driverless
> ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/

ipp://... is a URI for the printer. We will try setting up and printing
to a new print queue. Do

  lpadmin -p testq -v "URI" -E -m everywhere

Subdtitute URI with what is above. Test with

  lp -d testq -o sides=two-sided-long-edge test.pdf

> lpoptions -p PRINT_QUEUE_NAME -l
> lpoptions: Unable to get PPD file for PRINT_QUEUE_NAME: No such file or
> directory

PRINT_QUEUE_NAME is the actual name of the queue as given in Okular or
by 'lpstat -a'.

Cheers,

Brian.

Bug#1008501: pahole-flags.sh: inaccessible or not found

[Thorsten Glaser]

Package: linux-headers-5.17.0-rc8-common
Version: 5.17~rc8-1~exp1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Trying to build a kernel module against 5.17 shows several warnings:

W: /bin/sh: /usr/src/linux-headers-5.17.0-rc8-common/scripts/pahole-flags.sh: 
inaccessible or not found

According to the PTS, a file called pahole-flags.sh does not exist in
experimental *or* sid.

I haven’t checked whether this bug also occurs on sid; bullseye does
not yet have it.


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#1008498: Should hgsubversion be removed?

[Andrej Shadura]

Hi,

On Sun, 27 Mar 2022, at 23:33, Moritz Muehlenhoff wrote:
> Source: hgsubversion
> Version: 1.9.3+git20190419+6a6ce-5
> Severity: serious
>
> Your package came up as a candidate for removal from Debian:
>
> - Still depends on Python 2 and removed from testing since 2020
> - Dead upstream (no commits after 2019)

Thanks, I fully agree.

> If you disagree and want to continue to maintain this package,
> please just close this bug (and fix the open issues).
>
> If you agree with the removal, please reassign to ftp.debian.org
> by sending the following commands to cont...@bugs.debian.org:

Doing so.

-- 
Cheers,
  Andrej

Bug#1008500: Should undertaker be removed?

[Moritz Muehlenhoff]

Source: undertaker
Version: 1.6.1-4.2
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and thus removed from testing since 2019
- Last maintainer upload in 2016

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008499: Should neard be removed?

[Moritz Muehlenhoff]

Source: neard
Version: 0.16-0.1
Severity: serious

Your package came up as a candidate for removal from Debian:

- Last maintainer upload in 2013
- Depends on Python 2 and thus removed from testing since 2019

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008498: Should hgsubversion be removed?

[Moritz Muehlenhoff]

Source: hgsubversion
Version: 1.9.3+git20190419+6a6ce-5
Severity: serious

Your package came up as a candidate for removal from Debian:

- Still depends on Python 2 and removed from testing since 2020
- Dead upstream (no commits after 2019)

If you disagree and want to continue to maintain this package,
please just close this bug (and fix the open issues).

If you agree with the removal, please reassign to ftp.debian.org
by sending the following commands to cont...@bugs.debian.org:

--
severity $BUGNUM normal
reassign $BUGNUM ftp.debian.org
retitle $BUGNUM RM:  -- RoM; 
thx
--

Otherwise I'll move forward and request it's removal in a month.

Cheers,
Moritz

Bug#1008497: linux-image-5.10.0-13-arm64: 5.10.0-13-arm64 gets stuck after loading ramdisk on VMWareFusion under M1. 5.10.0-12-arm64 works.

[Andreas Fink]

Package: src:linux
Version: 5.10.106-1
Severity: critical
Tags: d-i
Justification: breaks the whole system

Dear Maintainer,

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

Brand new Mac Studio M1 Ultra
Install VMWare Fusion Pro Tech Preview for ARM/M1
Download 11.3 DVD iso
Install ISO. Install process completes
First reboot
System hangs after loading ramdisk

Same procedure under Parallels Desktop 17 however works
As I had an older Debian 11 running on my Laptop, I copied it over and
it worked. After I did apt-get update, all started to fail.

I nailed it down to the kernel version

Linux kernel 5.10.0-13-arm64 #1 SMP Debian 5.10.106-1 (2022-03-17) aarch64 
GNU/Linux  fails
Linux kernel 5.10.0-12-arm64 #1 SMP Debian 5.10.70-1 (2021-09-30) aarch64 
GNU/Linux  works
Linux kernel 5.10.0-9-arm64 #1 SMP Debian 5.10.70-1 (2021-09-30) aarch64 
GNU/Linux  works




-- Package-specific info:
** Kernel log: boot messages should be attached

Loading Linux 5.10.0-13-arm64 ...
Loading initial ramdisk ...
_


** Model information
Device Tree model: linux,dummy-virt

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug ens160
iface ens160 inet static
address 79.134.238.12
netmask 255.255.255.128
gateway 79.134.238.1

iface ens160 inet6 static
address 2a01:528:1:2::c/64


** PCI devices:
00:00.0 Host bridge [0600]: VMware Device [15ad:1976] (rev 01)
Subsystem: VMware Device [15ad:1976]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Subsystem: VMware PCI bridge [15ad:0790]

00:15.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Subsystem: VMware PCI Express Root Port [15ad:07a0]
Capabilities: [48] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE-
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 5GT/s, Width x32, ASPM L0s, Exit Latency 
L0s <64ns
ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 5GT/s (ok), Width x32 (ok)
TrErr- Train- SlotClk- DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn+ PwrCtrl+ MRL- AttnInd- PwrInd- HotPlug+ 
Surprise-
Slot #160, PowerLimit 240.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn+ PwrFlt- MRL- PresDet- CmdCplt- HPIrq+ 
LinkChg+
Control: AttnInd Unknown, PwrInd Unknown, Power- 
Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ 
Interlock-
Changed: MRL- PresDet- LinkState-
RootCap: CRSVisible-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ 
CRSVisible-
RootSta: PME ReqID , PMEStatus- PMEPending-
DevCap2: Completion Timeout: Not Supported, TimeoutDis- 
NROPrPrP- LTR-
 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- 
EETLPPrefix-
 EmergencyPowerReduction Not Supported, 
EmergencyPowerReductionInit-
 FRS- LN System CLS Not Supported, TPHComp- ExtTPHComp- 
ARIFwd-
 AtomicOpsCap: Routing- 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 
OBFF Disabled, ARIFwd-
 AtomicOpsCtl: ReqEn- EgressBlck-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- 

Bug#986474: NMU to DELAYED/5

[Pierre Gruet]

Dear Maintainer,


I have prepared a NMU of i2p fixing bugs #997213 and #986474.

Please find enclosed the corresponding source debdiff.

I made the upload to DELAYED/5, please feel free to ask me to cancel it 
if you want.


Best regards,

--
Pierre
diff -Nru i2p-0.9.48/debian/changelog i2p-0.9.48/debian/changelog
--- i2p-0.9.48/debian/changelog 2020-12-03 06:51:17.0 +0100
+++ i2p-0.9.48/debian/changelog 2022-03-27 22:11:17.0 +0200
@@ -1,3 +1,13 @@
+i2p (0.9.48-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Adding an explicit (build-)dependency on libservlet3.1-java, which was
+previously provided by libnetty9-java (Closes: #997213)
+  * Adding an explicit dependency of i2p-router on libecj-java
+(Closes: #986474)
+
+ -- Pierre Gruet   Sun, 27 Mar 2022 22:11:17 +0200
+
 i2p (0.9.48-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru i2p-0.9.48/debian/control i2p-0.9.48/debian/control
--- i2p-0.9.48/debian/control   2020-12-03 06:51:17.0 +0100
+++ i2p-0.9.48/debian/control   2022-03-27 22:09:13.0 +0200
@@ -11,6 +11,7 @@
  ,debconf
  ,default-jdk
  ,libjetty9-java (>= 9.4)
+ ,libservlet3.1-java
  ,libtaglibs-standard-jstlel-java
  ,libtomcat9-java
  ,dh-apparmor
@@ -76,9 +77,11 @@
  openjdk-14-jre-headless | openjdk-13-jre-headless | openjdk-12-jre-headless | 
openjdk-11-jre-headless | default-jre-headless | java14-runtime-headless | 
java13-runtime-headless | java12-runtime-headless | java11-runtime-headless,
  geoip-database,
  gettext-base,
+ libecj-java,
  libgetopt-java,
  libjson-simple-java (>= 2),libjson-simple-java (<< 3),
  libjetty9-java (>= 9.4),
+ libservlet3.1-java,
  libtaglibs-standard-jstlel-java,
  libtomcat9-java,
  famfamfam-flag-png,


OpenPGP_signature
Description: OpenPGP digital signature

Bug#975505: packaging mathjax3 with Breaks mathjax2: How big of a problem?

[Nicholas D Steeves]

Hi Yadd, Mattia, Jonas, Kiwamu Okabe, and Clint,

I've added you to CC since this discussion affects at least one of your
packages (see below for more info).

Yadd  writes:

> On 27/03/2022 17:03, Nicholas D Steeves wrote:
>> Dmitry Shachnev  writes:
>>> On Sun, Nov 22, 2020 at 10:27:43PM -0500, Nicholas D Steeves wrote:
 Dear MathJax maintainers,

 Debian's MathJax is out of date (2.7.9), and I've noticed that some 
 packages
 have had to start to resort to bundling a 3.x release.  Please package
 v3.0.5 or newer.
>>>
>>> MathJax v3 is a complete rewrite of MathJax, and it is incompatible with
>>> MathJax v2 [1].
>>>
>>> So MathJax v3 needs to be packaged as a new source and binary package,
>>> therefore this bug is RFP, not a request for upgrade.
>>>
>>> Actually, an RFP was already filed, so I am merging this bug into that.
>>>
>> 
>> That makes sense if MathJax v2 will remain part of the archive :-)
>> 
>>> I am not going to do it myself because I don't have any nodejs or typescript
>>> skills (the source code [2] is using them now), but if you or someone else
>>> who reads this believes they can handle it, please do it.
>>>
>> 
>> Sounds good!  Likewise, MathJax is too important for me to make it my
>> first nodejs or typescript package, while also lacking skills for truly
>> responsible maintenance :-)
>> 
>> Xavier, I noticed that you tagged this bug as pending, but I couldn't
>> find the package in the archive, or in the NEW queue.  Maybe there is
>> not-yet-uploaded work somewhere?
>
> Hi,
>
> I'm going to build mathjax3. It will conflicts/breaks mathjax. Is it OK 
> for you ?
>

Sadly I'm not able to assess if mathjax2 and mathjax3 are coinstallable,
but I'll trust you that they're not, and I support moving forward.
Mathjax3 is now at least two years old, after all!

I know of at least two annoying potential blockers: Calibre (ebook
management software with physical ebook reader device sync) requires
Mathjax3, but Sigil (ebook editor) currently requires Mathjax2.

Mattia, could Sigil's upstream be persuaded to switch to Mathjax3 before
the freeze?  Do you know of any other notable packages that this would
cause problems for?  Nothing LaTeX-related, I hope...

There are also at least some markdown-related ones: notably Pandoc,
which appears to presently require Mathjax2 to enable optional
functionality.  To the maintainers of Pandoc, could its upstream also be
persuaded to switch to Mathjax3 before the freeze?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1008496: fbless: exits with exception

[Alexander Inyukhin]

Package: fbless
Version: 0.2.3-5
Severity: normal

Dear Maintainer,

sometimes fbless throws an exception.
This error is repeatedly occured at the same place inside a file.




Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 915, in get
line = par.lines[line_index]
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/fbless", line 23, in 
MainWindow().main_loop()
  File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 88, in __init__
self.redraw_scr()
  File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 230, in 
redraw_scr
s, type = self.content.get(_par_index, _line_index)
  File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 919, in get
return self.get(par_index, line_index)
  File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 913, in get
self._split_par(par)
  File "/usr/lib/python3/dist-packages/fbless_lib/main.py", line 1011, in 
_split_par
par.split_string()
  File "/usr/lib/python3/dist-packages/fbless_lib/paragraph.py", line 155, in 
split_string
offsets.sort()  # sort by offsets
TypeError: '<' not supported between instances of 'tuple' and 'int'


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

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages fbless depends on:
ii  hyphen-de 1:7.1.0~rc3-3
ii  hyphen-en-us  2.8.8-7
ii  hyphen-es 1:7.1.0~rc3-3
ii  hyphen-fr 1:7.1.0~rc3-3
ii  hyphen-it 1:7.1.0~rc3-3
ii  hyphen-ru 20030310-1.1
ii  hyphen-uk 1:7.1.0~rc3-3
ii  python3   3.9.2-3
ii  python3-xdg   0.27-2

fbless recommends no packages.

fbless suggests no packages.

-- no debconf information

Bug#1008175: #1008175

[rick]

Brian:

avahi-browse -rt _ipp._tcp
+ enp2s0 IPv6 HP LaserJet Pro M148fdw (6CA573)  Internet 
Printer local
+ enp2s0 IPv4 HP LaserJet Pro M148fdw (6CA573)  Internet 
Printer local
= enp2s0 IPv6 HP LaserJet Pro M148fdw (6CA573)  Internet 
Printer local

   hostname = [NPI6CA573.local]
   address = [192.168.1.207]
   port = [631]
   txt = ["mopria-certified=1.3" "mac=f8:b4:6a:6c:a5:73" "usb_MDL=HP 
LaserJet Pro M148f-M149f" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4" 
"kind=document,envelope,photo" 
"UUID=564e4733-5931-3235-3934-f8b46a6ca573" "Fax=T" "Scan=T" "Duplex=T" 
"Color=F" "note=unitedStates" 
"adminurl=http://NPI6CA573.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus; 
"priority=10" "product=(HP LaserJet Pro M148f-M149f)" "ty=HP LaserJet 
Pro M148f-M149f" "URF=V1.4,CP99,W8,OB10,PQ3-4-5,DM1,IS1,MT1-3-5,RS600" 
"rfo=ipp/faxout" "rp=ipp/print" 
"pdl=image/urf,application/PCLm,application/octet-stream,application/pdf,application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,image/jpeg" 
"qtotal=1" "txtvers=1"]
= enp2s0 IPv4 HP LaserJet Pro M148fdw (6CA573)  Internet 
Printer local

   hostname = [NPI6CA573.local]
   address = [192.168.1.207]
   port = [631]
   txt = ["mopria-certified=1.3" "mac=f8:b4:6a:6c:a5:73" "usb_MDL=HP 
LaserJet Pro M148f-M149f" "usb_MFG=HP" "TLS=1.2" "PaperMax=legal-A4" 
"kind=document,envelope,photo" 
"UUID=564e4733-5931-3235-3934-f8b46a6ca573" "Fax=T" "Scan=T" "Duplex=T" 
"Color=F" "note=unitedStates" 
"adminurl=http://NPI6CA573.local./hp/device/info_config_AirPrint.html?tab=Networking=AirPrintStatus; 
"priority=10" "product=(HP LaserJet Pro M148f-M149f)" "ty=HP LaserJet 
Pro M148f-M149f" "URF=V1.4,CP99,W8,OB10,PQ3-4-5,DM1,IS1,MT1-3-5,RS600" 
"rfo=ipp/faxout" "rp=ipp/print" 
"pdl=image/urf,application/PCLm,application/octet-stream,application/pdf,application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,image/jpeg" 
"qtotal=1" "txtvers=1"]


driverless
ipps://HP%20LaserJet%20Pro%20M148fdw%20(6CA573)._ipps._tcp.local/

lpoptions -p PRINT_QUEUE_NAME -l
lpoptions: Unable to get PPD file for PRINT_QUEUE_NAME: No such file or 
directory


Thanks!

Rick

On 2022-03-27 12:49, Brian Potkin wrote:

On Sun 27 Mar 2022 at 10:25:37 -0500, r...@scotsgeek.com wrote:


The printer is"HP LaserJet Plus Pro M148fdw", connected by ethernet.

I first created a .txt file, then converted it to a .ps file, then 
converted

to a .pdf file.  I then ran the following commands:
lpr -o sides=two-sided-long-edge lipsum.txt.ps
lp -o sides=two-sided-long-edge lipsum.txt.ps
lpr -o sides=two-sided-long-edge lipsum.txt.pdf
lp -o sides=two-sided-long-edge lipsum.txt.pdf

All printed one-sided.


Thanks for doing that.


Then, as root, I ran the command
cupsctl --debug-logging

Then as regular user, I ran:
lp -o sides=two-sided-long-edge lipsum.txt.pdf

After many seconds, error reported:
lp: Error - scheduler not responding.

No output to the printer.


Pass on this for the moment. My understanding is that there is no
difference in what lp and lpr do.


I then ran:
lpr -o sides=two-sided-long-edge lipsum.txt.pdf

It printed one-sided.

This used to work correctly, then a few months ago, it stopped 
working.  I

had hoped it would have been corrected, but now I am reporting it.

Please let me know if I can help in any other way.


The error_log shows that two-sided-long-edge is sent to the printing
system. See argv[5]. It should then be sent on to the printer. The
printer supports two-sided-long-edge.

But we have

   [Job 238] Unable to do two-sided printing, setting sides to 
\'one-sided\'.


Now, where is that coming from and why? Investigating.

Rick, you can help with more information. Please give what you get for

  avahi-browse -rt _ipp._tcp
  driverless
  lpoptions -p PRINT_QUEUE_NAME -l

avahi-browse is in the avahi-utils package.

Cheers,

Brian.

Bug#1008175: #1008175

[Till Kamppeter]

The log message "Unable to do two-sided printing" comes from the "ipp" 
CUPS backend, part of CUPS. It seems that the backend does not find the 
"sides" attribute in the printer's IPP attributes.


See the code here:
--
if (ipp_status == IPP_STATUS_OK_IGNORED_OR_SUBSTITUTED || 
ipp_status == IPP_STATUS


_OK_CONFLICTING)

{

 /*

  * One or more options are not supported...

  */



  if (ippFindAttribute(response, "sides", IPP_TAG_ZERO))

  {

   /*

* The sides value is not supported, revert to one-sided as 
needed...


*/



const char *sides = cupsGetOption("sides", num_options, options);



if (!sides || !strncmp(sides, "two-sided-", 10))

{

  fputs("DEBUG: Unable to do two-sided printing, setting sides 
to 'one-sided'.\n", stderr);


  num_options = cupsAddOption("sides", "one-sided", 
num_options, );


}

  }

--

Bug#975505: Please package v3.0.5 or newer

[Yadd]

On 27/03/2022 17:03, Nicholas D Steeves wrote:

Hi Dmitry and Xavier!

Dmitry Shachnev  writes:


On Sun, Nov 22, 2020 at 10:27:43PM -0500, Nicholas D Steeves wrote:

Dear MathJax maintainers,

Debian's MathJax is out of date (2.7.9), and I've noticed that some packages
have had to start to resort to bundling a 3.x release.  Please package
v3.0.5 or newer.


MathJax v3 is a complete rewrite of MathJax, and it is incompatible with
MathJax v2 [1].

So MathJax v3 needs to be packaged as a new source and binary package,
therefore this bug is RFP, not a request for upgrade.

Actually, an RFP was already filed, so I am merging this bug into that.



That makes sense if MathJax v2 will remain part of the archive :-)


I am not going to do it myself because I don't have any nodejs or typescript
skills (the source code [2] is using them now), but if you or someone else
who reads this believes they can handle it, please do it.



Sounds good!  Likewise, MathJax is too important for me to make it my
first nodejs or typescript package, while also lacking skills for truly
responsible maintenance :-)

Xavier, I noticed that you tagged this bug as pending, but I couldn't
find the package in the archive, or in the NEW queue.  Maybe there is
not-yet-uploaded work somewhere?


Hi,

I'm going to build mathjax3. It will conflicts/breaks mathjax. Is it OK 
for you ?


Cheers,
Yadd

Bug#1008415: libnih: FTBFS: dh_auto_test: error: make -j8 check VERBOSE=1 returned exit code 2

[Mike Gabriel]

Hi Axel,

On  Sa 26 Mär 2022 23:57:57 CET, Axel Beckert wrote:


But a short look through those binary packages most likely having
reverse-dependencies (libnih-dbus1 and libnih1), I though found a
single reverse dependency not coming from the libnih package:

$ apt-cache rdepends libnih1
libnih1
Reverse Depends:
  libnih-dbus1
  libnih1-dbgsym
  nih-dbus-tool
  libnih-dev
$ apt-cache rdepends libnih-dbus1
libnih-dbus1
Reverse Depends:
  libnih-dbus-dev
  libnih-dbus1-dbgsym
  libldm-priv-common0
  ^^^

So with just one reverse dependency left and being orphaned since
2016, it's probably time for removal.

Cc'ing the package maintainers of the sole reverse dependency I've
found, lomiri-download-manager (source package of libldm-priv-common0)
for a comment how "needed" libnih is in their package.


I will bring this up in our next upstream dev meeting and see what we  
can do about this.


Personally, I think the dependency on libnih-dbus-dev looks so minimal  
in lomiri-download-manager, it should be replacable.


Mike
--

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

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



pgpBRoQ3hNGKN.pgp
Description: Digitale PGP-Signatur

Bug#1006504: bullseye-pu: package bash/5.1-6~deb11u1

[Julien Cristau]

Control: tag -1 confirmed

On Sun, Mar 27, 2022 at 09:04:03PM +0200, Salvatore Bonaccorso wrote:
> Okay attached the alternative, and only cherry-pick the 014 patch
> upstream to address #1003012. Would that be acceptable instead?
> 
That's fine, thanks.

Cheers,
Julien

Bug#1006504: bullseye-pu: package bash/5.1-6~deb11u1

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo
Control: retitle -1 bullseye-pu: package bash/5.1-2+deb11u1

Hi Julien

On Sat, Mar 19, 2022 at 10:02:54PM +0100, Salvatore Bonaccorso wrote:
> Hi Julien,
> 
> On Sat, Mar 19, 2022 at 06:36:16PM +0100, Julien Cristau wrote:
> > Control: tag -1 moreinfo
> > 
> > On Sat, Feb 26, 2022 at 03:25:09PM +0100, Salvatore Bonaccorso wrote:
> > > There was a request in #1003012 to fix an issue in bash corrupting
> > > multibyte characters in command substitutions.
> > > 
> > > While looking at it I'm proposing here instead of only picking the 014
> > > patch, to pick up all the changes done since from the bullseye release
> > > on top and so proposing a rebuilding of 5.1-6 which was expoed in
> > > testing for awhile now. Only change reverted would be the bump of
> > > standards version but still including the drop of the pre-wheezy
> > > preinst for the "dash-as-sh"-transition.
> > > 
> > > Attached is the resulting debdiff as proposed with the rebuild.
> > > 
> > > Matthias, Stable release managers what do you think on the update?
> > > 
> > I'm unconvinced.  Dropping the preinst seems way out of scope for a
> > stable update, as for the other changes it's unclear to me what their
> > impact/risk is.
> 
> This is why I hoped to see what Matthias thinks.  The alternative
> would clearly be to only cherry pick the fix for #1003012 and do
> 5.1-2+deb11u1 with it. 

Okay attached the alternative, and only cherry-pick the 014 patch
upstream to address #1003012. Would that be acceptable instead?

Regards,
Salvatore
diff -Nru bash-5.1/debian/changelog bash-5.1/debian/changelog
--- bash-5.1/debian/changelog   2021-01-03 10:44:50.0 +0100
+++ bash-5.1/debian/changelog   2022-03-27 20:40:30.0 +0200
@@ -1,3 +1,10 @@
+bash (5.1-2+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * 1-byte buffer overflow read in subst.c read_comsub (Closes: #1003012)
+
+ -- Salvatore Bonaccorso   Sun, 27 Mar 2022 20:40:30 +0200
+
 bash (5.1-2) unstable; urgency=medium
 
   * Apply upstream patches 001 - 004.
diff -Nru bash-5.1/debian/patches/bash51-014.diff 
bash-5.1/debian/patches/bash51-014.diff
--- bash-5.1/debian/patches/bash51-014.diff 1970-01-01 01:00:00.0 
+0100
+++ bash-5.1/debian/patches/bash51-014.diff 2022-03-27 20:40:30.0 
+0200
@@ -0,0 +1,26 @@
+BASH PATCH REPORT
+=
+
+Bash-Release:  5.1
+Patch-ID:  bash51-014
+
+Bug-Reported-by:   platon7pro...@gmail.com
+Bug-Reference-ID:
+Bug-Reference-URL: https://savannah.gnu.org/patch/?10035
+
+Bug-Description:
+
+Bash may produce corrupted input if a multibyte character spans a 512-byte
+boundary while reading the output of a command substitution.
+
+--- a/subst.c
 b/subst.c
+@@ -6242,7 +6242,7 @@ read_comsub (fd, quoted, flags, rflag)
+ /* read a multibyte character from buf */
+ /* punt on the hard case for now */
+ memset (, '\0', sizeof (mbstate_t));
+-mblen = mbrtowc (, bufp-1, bufn+1, );
++mblen = mbrtowc (, bufp-1, bufn, );
+ if (MB_INVALIDCH (mblen) || mblen == 0 || mblen == 1)
+   istring[istring_index++] = c;
+ else
diff -Nru bash-5.1/debian/patches/series bash-5.1/debian/patches/series
--- bash-5.1/debian/patches/series  2021-01-03 10:43:05.0 +0100
+++ bash-5.1/debian/patches/series  2022-03-27 20:40:30.0 +0200
@@ -2,6 +2,7 @@
 bash51-002.diff
 bash51-003.diff
 bash51-004.diff
+bash51-014.diff
 bashbug-editor.diff
 deb-bash-config.diff
 deb-examples.diff

Bug#913468: xauth unknown command on startx, still pertinent

[Thorsten Glaser]

Hi,

this bug still exists.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1008175: #1008175

[Brian Potkin]

On Sun 27 Mar 2022 at 10:25:37 -0500, r...@scotsgeek.com wrote:

> The printer is"HP LaserJet Plus Pro M148fdw", connected by ethernet.
> 
> I first created a .txt file, then converted it to a .ps file, then converted
> to a .pdf file.  I then ran the following commands:
> lpr -o sides=two-sided-long-edge lipsum.txt.ps
> lp -o sides=two-sided-long-edge lipsum.txt.ps
> lpr -o sides=two-sided-long-edge lipsum.txt.pdf
> lp -o sides=two-sided-long-edge lipsum.txt.pdf
> 
> All printed one-sided.

Thanks for doing that.
 
> Then, as root, I ran the command
> cupsctl --debug-logging
> 
> Then as regular user, I ran:
> lp -o sides=two-sided-long-edge lipsum.txt.pdf
> 
> After many seconds, error reported:
> lp: Error - scheduler not responding.
> 
> No output to the printer.

Pass on this for the moment. My understanding is that there is no
difference in what lp and lpr do.
 
> I then ran:
> lpr -o sides=two-sided-long-edge lipsum.txt.pdf
> 
> It printed one-sided.
> 
> This used to work correctly, then a few months ago, it stopped working.  I
> had hoped it would have been corrected, but now I am reporting it.
> 
> Please let me know if I can help in any other way.

The error_log shows that two-sided-long-edge is sent to the printing
system. See argv[5]. It should then be sent on to the printer. The
printer supports two-sided-long-edge.

But we have

   [Job 238] Unable to do two-sided printing, setting sides to \'one-sided\'.

Now, where is that coming from and why? Investigating.

Rick, you can help with more information. Please give what you get for

  avahi-browse -rt _ipp._tcp
  driverless
  lpoptions -p PRINT_QUEUE_NAME -l

avahi-browse is in the avahi-utils package.

Cheers,

Brian.

Bug#1008495: transition: tinyobjloader

[Timo Röhling]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I'd like to transition tinyobjloader for its new soname. Technically,
this is a simple transition, the reverse dependencies build fine.
However, the transition is unusual as it is not an official release, so
allow me to explain my reasons.

The initial upload was with 2.0.0~rc5 around April 2020, because it was
required by Open3D at that time. Upstream assured me that a final 2.0
release would be happening in early 2021. Some development occurred
(which broke ABI backwards compatibility) and some bugs were fixed,
among them CVE-2020-28589; however, the final release never
materialized. Now, almost two years later, I find myself with an
"in-between" ABI version that is no longer .so.1 but likely not
.so.2 yet (the TODO still includes some "API polishing").

It is impossible to predict when upstream will find the time to finish
the 2.0 release, and I would like to have the bugfixes in Debian at some
point. Given that this is only a minor package with few reverse depends,
I felt it was fine to have this "in-between" transition now and the
proper one with .so.2 whenever the final release happens. Let me know
what you think.


Cheers
Timo

PS. https://release.debian.org/transitions/html/auto-tinyobjloader.html
looks good

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmJAnnYACgkQ+C8H+466
LVk67AwAo6qohyBPGDq36lxSFbEW/E6qZHNWBr239hVMGNT63DzhvRqRO4KOdt9C
xoQYSRrFXP5oQRKXh6EosmHK/uHxVNAH1IG8xyWpe7pdD6QvzKhnVGpZiKQviGEe
iixw92dqWx0R72fuBUzojqeAT1v680t+upshDYm0SlrJWZGym5emJUBs+6LRcx5o
F6l9z3teuIacHeUyt/L1J9aoWHS9GKmFyoIgZMYWFMC+D0t03osvUuikDawc3v6P
JGrDpDU9pDpLIPUwcT9R/YP8vYq12PfTJnKgWDjCCk5vOADdYbOCgpbu7GkqZFcQ
eQBpS45aULq539W+oKpuaeMtXPMkZvFkBExdlvnVmyQ5fX4V16wRyrTci7C+vrwA
VXG4TaUF2MBmO6pNnbjCASzblz7A2IJiEdMWeXjej7XA5ZZZ7bGjJe8WcTHpXG9n
yRmP7AjJvEtID6oQbTRkJeqpz8sVxyfvqLYMjqECA/pzyX2lCtXOI/Qv16g6wHyk
pWesoHlP
=rcmR
-END PGP SIGNATURE-

Bug#1001669: closed by Debian FTP Masters

[Aniol Martí]

On Wed, 23 Mar 2022 09:09:00 +0100 Aniol Martí  
wrote:> I've tried several times and I can't reproduce the bug. I would 
need
further details or assistance. Besides, I also noticed that the last 
test passed fine: 
https://ci.debian.net/data/autopkgtest/unstable/amd64/o/openvpn-auth-ldap/20263239/log.gz


I've added some verbosity to the test and I've tried in with Salsa and 
the problem seems to be the following:


ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted 
(errno=1)


Although I've added "isolation-container" to the test restrictions it 
still fails. Maybe there have been some changes in the Docker configuration?


Regards,
Aniol

Bug#1008494: RFS: sane-backends/1.1.1-5 -- API library for scanners

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sane-backends":

   Package name: sane-backends
   Version : 1.1.1-5
   Upstream Author : 
   URL : http://www.sane-project.org
   License : GPL-3+, LGPL-2.1+, GPL-2, GFDL-1.1, Artistic, 
 GPL-2+, GPL-2+ with sane exception
   Vcs : https://jff.email/cgit/sane-backends.git
   Section : graphics

The source builds the following binary packages:

  sane-utils - API library for scanners -- utilities
  libsane-common - API library for scanners -- documentation and support files
  libsane1 - API library for scanners
  libsane-dev - API development library for scanners [development files]
  libsane - API library for scanners [transitional package]

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

  https://mentors.debian.net/package/sane-backends/

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

 dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.1.1-5.dsc

or from 

 git https://jff.email/cgit/sane-backends.git?h=release%2Fdebian%2F1.1.1-5


Changes since the last upload:

 sane-backends (1.1.1-5) unstable; urgency=medium
 .
   * debian/rules:
 - Change configure parameter --enable-parport-directio to use only on
   hurd-i386 (Closes: #1008488).
   * debian/control:
- Change Build-Depend from virtual package libltdl3-dev to libltdl-dev.
   * New debian/patches/0195-genesys_fix_total_file_size_exceeding.patch:
- Fix out off memory on high resultions (Closes: #942176)
  Cherry-picked from upstream.


CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


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

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


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


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



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

Bug#1005135: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.103.01-1~deb11u1

[Adam D. Barratt]

[readding the submitter to CC]

On Sun, 2022-03-27 at 17:17 +0100, Adam D. Barratt wrote:
> On Sat, 2022-03-19 at 17:22 +, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Mon, 2022-02-07 at 18:42 +0100, Andreas Beckmann wrote:
> > > I'd like to introduce a new source package into stable:
> > >   src:nvidia-graphics-drivers-tesla-470 (upstream EoL planned
> > > 07/2024)
> > > as a successor to
> > >   src:nvidia-graphics-drivers-tesla-460 (upstream EoL planned
> > > 01/2022)
> > >   src:nvidia-graphics-drivers-tesla-450 (upstream EoL planned
> > > 07/2023)
> > > 470 supports a superset of the GPUs supported by the 450 and 460
> > > series,
> > > but came a bit too late to be included into bullseye from the
> > > beginning.
> > 
> > Please go ahead, thanks.
> > 
> 
> Our QA checks noticed an installability issue - the uploaded amd64
> libegl-nvidia-tesla-470-0 package depends on "libnvidia-egl-wayland1
> (>= 1:1.1.7)", but stable only has 1:1.1.5-1.
> 
> Regards,
> 
> Adam
> 
> 

Bug#1008465: [Debian-pan-maintainers] Bug#1008465: python-fabio: FTBFS: Could not import extension nbsphinx (exception: No module named 'ipython_genutils')

[Jerome Kieffer]

Hi Lucas,

Thanks for the report. This looks like a bug I recently fixed in pyFAI ... I'll 
have a look tomorrow. Probably just a missing dependency like in
https://github.com/silx-kit/pyFAI/commit/7bcb6dd7419b48580d97cd91a28d05f86b301f1c

Cheers,

Jerome

On Sat, 26 Mar 2022 22:57:37 +0100
Lucas Nussbaum  wrote:

> Source: python-fabio
> Version: 0.13.0+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220326 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_build
> > I: pybuild base:237: /usr/bin/python3.10 setup.py build 
> > /<>/setup.py:49: DeprecationWarning: The distutils package is 
> > deprecated and slated for removal in Python 3.12. Use setuptools or check 
> > PEP 632 for potential alternatives
> >   from distutils.command.clean import clean as Clean
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build
> > running build_py
> > running build_ext
> > I: pybuild base:237: /usr/bin/python3 setup.py build 
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build
> > running build_py
> > running build_ext
> > dh_auto_build -- -s custom --build-args="PYTHONPATH={build_dir} xvfb-run -a 
> > --server-args=\"-screen 0 1024x768x24\" {interpreter} setup.py build_man"
> > I: pybuild base:237: 
> > PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build xvfb-run -a 
> > --server-args="-screen 0 1024x768x24" python3.10 setup.py build_man
> > /<>/setup.py:49: DeprecationWarning: The distutils package is 
> > deprecated and slated for removal in Python 3.12. Use setuptools or check 
> > PEP 632 for potential alternatives
> >   from distutils.command.clean import clean as Clean
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build_man
> > INFO:fabio.setup:Build man for entry-point target 'fabio-convert'
> > INFO:fabio.setup:Build man for entry-point target 'eiger2cbf'
> > ERROR:eiger2cbf:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'eiger2crysalis'
> > ERROR:eiger2crysalis:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'densify-Bragg'
> > INFO:fabio.setup:Build man for entry-point target 'fabio_viewer'
> > I: pybuild base:237: 
> > PYTHONPATH=/<>/.pybuild/cpython3_3.9_fabio/build xvfb-run -a 
> > --server-args="-screen 0 1024x768x24" python3.9 setup.py build_man
> > INFO:fabio.setup:Use setuptools with cython
> > INFO:fabio.setup:Install requires: numpy >=1.21.5
> > running build_man
> > INFO:fabio.setup:Build man for entry-point target 'fabio-convert'
> > INFO:fabio.setup:Build man for entry-point target 'eiger2cbf'
> > ERROR:eiger2cbf:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'eiger2crysalis'
> > ERROR:eiger2crysalis:Numexpr is needed to interpret formula ...
> > INFO:fabio.setup:Build man for entry-point target 'densify-Bragg'
> > INFO:fabio.setup:Build man for entry-point target 'fabio_viewer'
> > dh_auto_build -- -s custom --build-args="cd doc && PYTHONPATH={build_dir} 
> > http_proxy='127.0.0.1:9' {interpreter} -m sphinx -N -bhtml source 
> > build/html"
> > I: pybuild base:237: cd doc && 
> > PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build 
> > http_proxy='127.0.0.1:9' python3.10 -m sphinx -N -bhtml source build/html
> > Running Sphinx v4.3.2
> > 
> > Extension error:
> > Could not import extension nbsphinx (exception: No module named 
> > 'ipython_genutils')
> > E: pybuild pybuild:367: build: plugin custom failed with: exit code=2: cd 
> > doc && PYTHONPATH=/<>/.pybuild/cpython3_3.10_fabio/build 
> > http_proxy='127.0.0.1:9' python3.10 -m sphinx -N -bhtml source build/html
> > I: pybuild base:237: cd doc && 
> > PYTHONPATH=/<>/.pybuild/cpython3_3.9_fabio/build 
> > http_proxy='127.0.0.1:9' python3.9 -m sphinx -N -bhtml source build/html
> > Running Sphinx v4.3.2
> > 
> > Extension error:
> > Could not import extension nbsphinx (exception: No module named 
> > 'ipython_genutils')
> > E: pybuild pybuild:367: build: plugin custom failed with: exit code=2: cd 
> > doc && PYTHONPATH=/<>/.pybuild/cpython3_3.9_fabio/build 
> > http_proxy='127.0.0.1:9' python3.9 -m sphinx -N -bhtml source build/html
> > dh_auto_build: error: pybuild --build -i python{version} -p "3.10 3.9" -s 
> > custom "--build-args=cd doc && PYTHONPATH={build_dir} 
> > http_proxy='127.0.0.1:9' {interpreter} -m sphinx -N -bhtml source 
> > build/html" returned exit code 13
> > make[1]: *** [debian/rules:21: override_dh_auto_build-indep] Error 25  
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2022/03/26/python-fabio_0.13.0+dfsg-1_unstable.log
> 
> A list of 

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Lilo von Hanffstengel]

Hi,

>> > What does this call print on your machine?
>> 
>> Which call?
>
> /etc/aide/aide.conf.d/31_aide_munin-nodes

~# /etc/aide/aide.conf.d/31_aide_munin-nodes
/var/cache/munin/www/localdomain\n/(index\.html|localhost\\.localdomain/[-_[:alnum:]]+\.(png|html))$
 f VarFile/var/lib/munin/localdomain/localhost\\.localdomain\n-.*\.rrd$ f 
VarFile/@@{RUN}/munin/munin-(update|datafile|localdomain-localhost\\.localdomain|limits)\.lock$
 f VarFile

> I would like to see the original. What you sent me is with CRLF
> lineending. The rule should (must!) work with unix style line ending,
> but somehow an extra \n is written to the aide rule.

See attached tarball.


-- 
Greetings
Lilo von Hanffstengel

munin-aide-configs.tar.gz
Description: GNU Zip compressed data

Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail

[Daniel Kahn Gillmor]

Package: gnome-settings-daemon
Version: 42.1-1
Control: affects -1 gnome-control-center

I have gnome-settings-daemon 42.1-1 installed, and gnome-control-cennter
1:41.4-1

When i open gnome-control-center and go to "Keyboard" and click on "View
and Customize Shortcuts", gnome-control-center crashes, and produces
this on stderr:


(gnome-control-center:3522): GLib-GIO-ERROR **: 12:05:52.032: Settings 
schema 'org.gnome.settings-daemon.plugins.media-keys' does not contain a key 
named 'screenshot'
Trace/breakpoint trap

I reported this upstream:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1728

And Jeremy Bicha responded with:

> I think your issue is caused by a version mismatch in Debian, so I'm
> closing this as Not GNOME.

I think either gnome-settings-daemon 42.1-* should indicate that it
Breaks: earlier versions of gnome-control-center, or
gnome-control-center should indicate that it is tightly bound to the
version of gnome-settings-daemon that it ships with.

--dkg


signature.asc
Description: PGP signature

Bug#1005135: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.103.01-1~deb11u1

[Adam D. Barratt]

On Sat, 2022-03-19 at 17:22 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2022-02-07 at 18:42 +0100, Andreas Beckmann wrote:
> > I'd like to introduce a new source package into stable:
> >   src:nvidia-graphics-drivers-tesla-470 (upstream EoL planned
> > 07/2024)
> > as a successor to
> >   src:nvidia-graphics-drivers-tesla-460 (upstream EoL planned
> > 01/2022)
> >   src:nvidia-graphics-drivers-tesla-450 (upstream EoL planned
> > 07/2023)
> > 470 supports a superset of the GPUs supported by the 450 and 460
> > series,
> > but came a bit too late to be included into bullseye from the
> > beginning.
> 
> Please go ahead, thanks.
> 

Our QA checks noticed an installability issue - the uploaded amd64
libegl-nvidia-tesla-470-0 package depends on "libnvidia-egl-wayland1
(>= 1:1.1.7)", but stable only has 1:1.1.5-1.

Regards,

Adam

Bug#1008175: #1008175

[rick]

The printer is"HP LaserJet Plus Pro M148fdw", connected by ethernet.

I first created a .txt file, then converted it to a .ps file, then 
converted to a .pdf file.  I then ran the following commands:

lpr -o sides=two-sided-long-edge lipsum.txt.ps
lp -o sides=two-sided-long-edge lipsum.txt.ps
lpr -o sides=two-sided-long-edge lipsum.txt.pdf
lp -o sides=two-sided-long-edge lipsum.txt.pdf

All printed one-sided.

Then, as root, I ran the command
cupsctl --debug-logging

Then as regular user, I ran:
lp -o sides=two-sided-long-edge lipsum.txt.pdf

After many seconds, error reported:
lp: Error - scheduler not responding.

No output to the printer.

I then ran:
lpr -o sides=two-sided-long-edge lipsum.txt.pdf

It printed one-sided.

This used to work correctly, then a few months ago, it stopped working.  
I had hoped it would have been corrected, but now I am reporting it.


Please let me know if I can help in any other way.

Thank you!

Rick


On 2022-03-27 08:08, Brian Potkin wrote:

tags 1008175 moreinfo
thanks


On Wed 23 Mar 2022 at 13:01:18 -0400, Rick Stanley wrote:


Now neither option works correctly executing from the command line.
"lpr -o sides=two-sided-long-edge  test.pdf"
"lpr -o sides=one-sided  test.pdf"

And same for lp.


Thank you for your report, Rick. What is the printer make and model?

The situation is that neither command gives double-sided printing?


Printing from Okular works correctly as expected.


There is a slight difference between your lp command and what Okular
does. Okular sends a PostScript file to the ptinter. Not that I can
see why that should make any difference, but printing from Evince or
Firefox sens a PDF. You could try that.

Anyway, let's have a log. Enable debug logging with

  cupsctl --debug-logging

Empty error_log with

  >/var/log/cups/error_log

Print and send error_log as an attachment after compressing it.

Regards,

Brian.




error.7z
Description: application/7z-compressed

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Marc Haber]

On Sun, Mar 27, 2022 at 05:15:45PM +0200, Lilo von Hanffstengel wrote:
> > we can write in German if that helps. 
> 
> No, i think my english is understandable to give you all information you need.

Ok, I'm fine with that.

> > What does this call print on your machine?
> 
> Which call?

/etc/aide/aide.conf.d/31_aide_munin-nodes

> 
> > Was that file by any chance edited on a windows box and saved with Windows 
> > Line
> > Endings CR/LF? Can you please gzip /etc/munin/munin.conf and
> > /etc/aide/aide.conf.d/31_aide_munin-nodes and send me the result as an
> > attachment?
> 
> After changing to CRLF line endings in conf files (see 
> munin-aide-conf.zip) a run of aideinit -f -y in bash shell fails with 
> this err:
> 
> Running aide --init...
> ')(line: 'etc/aide/aide.conf.d/31_aide_munin-nodes:4: unexpected character: '
> AIDE --init return code 17
> 
> > Does "file /etc/munin/munin.conf" print "ASCII text" or "ASCII
> > text, with CRLF, LF line terminators"?
> 
> It prints ASCII text. So this original had the correct Linux lineending.

I would like to see the original. What you sent me is with CRLF
lineending. The rule should (must!) work with unix style line ending,
but somehow an extra \n is written to the aide rule.

> > What does your /bin/sh point to?
> 
> /usr/bin/sh
> and a ls -al /usr/bin/sh gives /usr/bin/sh -> dash

Ok, that's the same on my reference system.

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1008492: ITP: jh7100-bootloader-recovery -- StarFive JH7100 recovery bootloader

[Domenico Andreoli]

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

* Package name: jh7100-bootloader-recovery
  Version : 2021-07-14
  Upstream Author : StarFive Tech.
* URL : https://github.com/starfive-tech/bootloader_recovery
* License : GPL
  Programming Lang: C
  Description : StarFive JH7100 recovery bootloader

This firmware brings up the board enough to program all the boot stages
onto the boot flash. It recovers an otherwise unbootable system.

Bug#1008277: aideinit stops with error in rule

[Lilo von Hanffstengel]

Hi,

>> deb [arch=amd64] http://autoinstall.plesk.com/PMM_0.1.11 bullseye all
>
> I guess that the apt aide rule code doesn't handle the [arch=amd64] part
> correctly yet. That's a relatively new notation. Can you try removing it
> just to check?

Removing that in apt list file did not solve the issue.

 # aideinit -f -y
Running aide --init...
  ERROR: /etc/aide/aide.conf.d/31_aide_apt (stdout):103:70: error in rule 
'/var/lib/apt/lists/deb\.debian\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\.diff_Index)?$':
 invalid double slash (line: 
'/var/lib/apt/lists/deb\\.debian\\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\\.diff_Index)?$
 f VarFile') 
AIDE --init return code 17


-- 
Greetings

Bug#1008337: shotwell: FTBFS: ../src/Resources.vala:38.34-38.40: error: value is less accessible than constant `Resources.PREFIX'

[Jörg Frings-Fürst]

forwarded 1008337 https://gitlab.gnome.org/GNOME/shotwell/-/issues/4967
thanks


Hello Lucas,


thank you for spending your time helping to make Debian better with
this bug report. 


Am Samstag, dem 26.03.2022 um 21:48 +0100 schrieb Lucas Nussbaum:
> Source: shotwell
> Version: 0.30.14-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220326 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
>
[...]

I have forwarded this bug to upstream.

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D


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

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


Threema: SYR8SJXB
Skype: joergpenguin
Telegram: @joergfringsfuerst


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




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

Bug#1002288: mesa: migration to llvm-toolchain-13 looks viable at this time

[Nicholas D Steeves]

Hi,

It looks like 21.3.7-1 in testing has been building with
llvm-toolchain-13 since January 2022, so maybe all the issues have been
resolved, and this bug can be closed?

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#975505: Please package v3.0.5 or newer

[Nicholas D Steeves]

Hi Dmitry and Xavier!

Dmitry Shachnev  writes:

> On Sun, Nov 22, 2020 at 10:27:43PM -0500, Nicholas D Steeves wrote:
>> Dear MathJax maintainers,
>>
>> Debian's MathJax is out of date (2.7.9), and I've noticed that some packages
>> have had to start to resort to bundling a 3.x release.  Please package
>> v3.0.5 or newer.
>
> MathJax v3 is a complete rewrite of MathJax, and it is incompatible with
> MathJax v2 [1].
>
> So MathJax v3 needs to be packaged as a new source and binary package,
> therefore this bug is RFP, not a request for upgrade.
>
> Actually, an RFP was already filed, so I am merging this bug into that.
>

That makes sense if MathJax v2 will remain part of the archive :-)

> I am not going to do it myself because I don't have any nodejs or typescript
> skills (the source code [2] is using them now), but if you or someone else
> who reads this believes they can handle it, please do it.
>

Sounds good!  Likewise, MathJax is too important for me to make it my
first nodejs or typescript package, while also lacking skills for truly
responsible maintenance :-)

Xavier, I noticed that you tagged this bug as pending, but I couldn't
find the package in the archive, or in the NEW queue.  Maybe there is
not-yet-uploaded work somewhere?

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1005296: Packaging synadm

[Daniel Gröber]

Hi Sebastien,

I'm also interested in having synadm in Debian. Did you start
packaging it somehwere already? Need any help?

--Daniel


signature.asc
Description: PGP signature

Bug#1008491: nvidia-kernel-support: depends on nvidia-modprobe which does not exist

[Drew Parsons]

Package: nvidia-kernel-support
Version: 510.60.02-1
Severity: normal

nvidia-kernel-support Depends: nvidia-modprobe (>= 510)
This dependency is still in place for nvidia-kernel-support
510.60.02-1 from experimental.

Previously (510.54-1) there was a nvidia-modprobe package. But it is
no longer generated for 510.60.02-1, effectively it doesn't exist any
more.

We can workaround it for now by using nvidia-modprobe 510.54-1 from
unstable, but will that introduce errors with 510.60.02?  And that
will become a serious bug anyway once 510.60.02? is uploaded to
unstable and nvidia-modprobe is no longer available at all.

Does the nvidia-modprobe package need to be generated for 510.60.02-1,
or does nvidia-kernel-support need to be updated to stop depending on
it?



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

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

Versions of packages nvidia-kernel-support depends on:
ii  nvidia-alternative [nvidia-alternative--kmod-alias]  510.60.02-1
ii  nvidia-kernel-common 20220217+1
ii  nvidia-modprobe  510.54-1

nvidia-kernel-support recommends no packages.

nvidia-kernel-support suggests no packages.

Versions of packages nvidia-driver depends on:
ii  nvidia-alternative510.60.02-1
ii  nvidia-driver-bin 510.60.02-1
ii  nvidia-driver-libs510.60.02-1
ii  nvidia-installer-cleanup  20220217+1
ii  nvidia-kernel-dkms [nvidia-kernel-510.60.02]  510.60.02-1
ii  nvidia-legacy-check   510.60.02-1
ii  nvidia-support20220217+1
ii  nvidia-vdpau-driver   510.60.02-1
ii  xserver-xorg-video-nvidia 510.60.02-1

Versions of packages nvidia-driver recommends:
ii  libnvidia-cfg1   510.60.02-1
ii  nvidia-persistenced  470.103.01-2
ii  nvidia-settings  510.60.02-1

Versions of packages nvidia-driver suggests:
ii  nvidia-kernel-dkms  510.60.02-1

Versions of packages nvidia-driver-libs:amd64 depends on:
ii  libgl1-nvidia-glvnd-glx  510.60.02-1
ii  nvidia-egl-icd   510.60.02-1

Versions of packages nvidia-driver-libs:amd64 recommends:
ii  libgles-nvidia1 510.60.02-1
ii  libgles-nvidia2 510.60.02-1
ii  libglx-nvidia0  510.60.02-1
ii  libnvidia-cfg1  510.60.02-1
pn  libnvidia-encode1   
ii  libopengl0  1.4.0-1
ii  nvidia-driver-libs  510.60.02-1
ii  nvidia-vulkan-icd   510.60.02-1

Versions of packages xserver-xorg-video-nvidia depends on:
ii  libc6  2.33-7
ii  libnvidia-glcore   510.60.02-1
ii  nvidia-alternative 510.60.02-1
ii  nvidia-installer-cleanup   20220217+1
ii  nvidia-legacy-check510.60.02-1
ii  nvidia-support 20220217+1
ii  xserver-xorg-core [xorg-video-abi-25]  2:21.1.3-2+b1

Versions of packages xserver-xorg-video-nvidia recommends:
ii  nvidia-driver 510.60.02-1
ii  nvidia-kernel-dkms [nvidia-kernel-510.60.02]  510.60.02-1
ii  nvidia-settings   510.60.02-1
ii  nvidia-vdpau-driver   510.60.02-1

Versions of packages xserver-xorg-video-nvidia suggests:
ii  nvidia-kernel-dkms  510.60.02-1

Versions of packages nvidia-alternative depends on:
ii  dpkg1.21.4
ii  glx-alternative-nvidia  1.2.1
ii  nvidia-legacy-check 510.60.02-1

Versions of packages nvidia-kernel-dkms depends on:
ii  dkms   2.8.7-2
pn  nvidia-firmware-510.60.02  
ii  nvidia-installer-cleanup   20220217+1
ii  nvidia-kernel-support [nvidia-kernel-support--v1]  510.60.02-1

Versions of packages nvidia-kernel-dkms recommends:
ii  nvidia-driver  510.60.02-1

Versions of packages glx-alternative-nvidia depends on:
ii  dpkg  1.21.4
ii  glx-alternative-mesa  1.2.1
ii  glx-diversions1.2.1
ii  update-glx1.2.1

Versions of packages glx-alternative-nvidia suggests:
ii  nvidia-driver [nvidia-driver-any]  510.60.02-1

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.33-7
ii  libdrm-intel1  2.4.110-1
ii  libdrm22.4.110-1
ii  libpciaccess0  0.16-3
ii  libpixman-1-0  0.40.0-1
ii  libudev1   250.4-1
ii  libx11-6   2:1.7.2-2+b1
ii  libx11-xcb1  

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Lilo von Hanffstengel]

Good day Herr Haber,

am Sonntag, 27. März 2022 um 13:28 schrieben Sie:

> On Sat, Mar 26, 2022 at 03:51:00PM +0100, Lilo von Hanffstengel wrote:
>>  aideinit -f -y
>> Running aide --init...
>>   ERROR: /etc/aide/aide.conf.d/31_aide_munin-nodes (stdout):1: unexpected 
>> character: '/' (line: 
>> '/var/cache/munin/www/localdomain\n/(index\.html|localhost\\.localdomain/[-_[:alnum:]]+\.(png|html))$
>>  f VarFile/var/lib/munin/localdomain/localhost\\.localdomain\n-.*\.rrd$ f 
>> VarFile/@@{RUN}/munin/munin-(update|datafile|localdomain-localhost\\.localdomain|limits)\.lock$
>>  f VarFile')
>
> Hi,
>
> can I please see your /etc/munin/munin.conf?

Sorry, the previous sent munin.conf was from my other server.

Here is the one whose err message was reported to tracker:

# Example configuration file for Munin, generated by 'make build'

# The next three variables specifies where the location of the RRD
# databases, the HTML output, logs and the lock/pid files.  They all
# must be writable by the user running munin-cron.  They are all
# defaulted to the values you see here.
#
#dbdir  /var/lib/munin
#htmldir /var/cache/munin/www
#logdir /var/log/munin
#rundir  /var/run/munin

# Where to look for the HTML templates
#
#tmpldir/etc/munin/templates

# Where to look for the static www files
#
#staticdir /etc/munin/static

# temporary cgi files are here. note that it has to be writable by
# the cgi user (usually nobody or httpd).
#
# cgitmpdir /var/lib/munin/cgi-tmp

# (Exactly one) directory to include all files from.
includedir /etc/munin/munin-conf.d

# You can choose the time reference for "DERIVE" like graphs, and show
# "per minute", "per hour" values instead of the default "per second"
#
#graph_period second

# Graphics files are generated either via cron or by a CGI process.
# See http://munin-monitoring.org/wiki/CgiHowto2 for more
# documentation.
# Since 2.0, munin-graph has been rewritten to use the cgi code.
# It is single threaded *by design* now.
#
#graph_strategy cron

# munin-cgi-graph is invoked by the web server up to very many times at the
# same time.  This is not optimal since it results in high CPU and memory
# consumption to the degree that the system can thrash.  Again the default is
# 6.  Most likely the optimal number for max_cgi_graph_jobs is the same as
# max_graph_jobs.
#
#munin_cgi_graph_jobs 6

# If the automatic CGI url is wrong for your system override it here:
#
#cgiurl_graph /munin-cgi/munin-cgi-graph

# max_size_x and max_size_y are the max size of images in pixel.
# Default is 4000. Do not make it too large otherwise RRD might use all
# RAM to generate the images.
#
#max_size_x 4000
#max_size_y 4000

# HTML files are normally generated by munin-html, no matter if the
# files are used or not. You can change this to on-demand generation
# by following the instructions in http://munin-monitoring.org/wiki/CgiHowto2
#
# Notes:
# - moving to CGI for HTML means you cannot have graph generated by cron.
# - cgi html has some bugs, mostly you still have to launch munin-html by hand
#
#html_strategy cron

# munin-update runs in parallel.
#
# The default max number of processes is 16, and is probably ok for you.
#
# If set too high, it might hit some process/ram/filedesc limits.
# If set too low, munin-update might take more than 5 min.
#
# If you want munin-update to not be parallel set it to 0.
#
#max_processes 16

# RRD updates are per default, performed directly on the rrd files.
# To reduce IO and enable the use of the rrdcached, uncomment it and set it to
# the location of the socket that rrdcached uses.
#
#rrdcached_socket /var/run/rrdcached.sock

# Drop someju...@fnord.comm and anotheru...@blibb.comm an email everytime
# something changes (OK -> WARNING, CRITICAL -> OK, etc)
#contact.someuser.command mail -s "Munin ${var:worst}: 
${var:group}::${var:host}::${var:plugin}" someju...@fnord.comm
#contact.anotheruser.command mail -s "Munin ${var:worst}: 
${var:group}::${var:host}::${var:plugin}" anotheru...@blibb.comm
#
# For those with Nagios, the following might come in handy. In addition,
# the services must be defined in the Nagios server as well.
#contact.nagios.command /usr/bin/send_nsca nagios.host.comm -c /etc/nsca.conf

# The maximum time the munin-update may take to get updates from all nodes,
# this might be interesting when using munin-async in case of large 
transactions and/or backlog.
# When using the munin protocol to connect to a node, then this value shouldn't 
be set higher than 240.
# In case it's higher, gaps might be seen in the graphs.
timeout_fetch_all_nodes 240

# The maximum amount of time in seconds we may work on 1 node.
# The value will be limited with timeout_fetch_all_nodes.
timeout_fetch_one_node 180

# a simple host tree
[localhost.localdomain]
address 127.0.0.1
use_node_name yes

#
# A more complex example of a host tree
#
## First our "normal" host.
# [fii.foo.com]
#   address foo
#
## Then our other host...
# [fay.foo.com]
#   address 

Bug#1007110: cups printing dialogue: broad scrollbar overlaps with pull-down Icon

[Brian Potkin]

reassign 1007110 libreoffice-gtk3   

thanks



On Sun 27 Mar 2022 at 15:59:55 +0200, mh wrote:

> Hi
> 
> Can't you move it to where it belongs? libreoffice? gtk?
> Or do I really need to go through this whole reportbug thing?
> Is there a way for me to direct this already written report  to where
> it belongs?

I thought had sent it to libreoffice-gtk3 but forgot to tell the
control server.

Cheers,

Brian.

Bug#1004860: glusterfs-client: no real dependency on fuse

[Andreas Hasenack]

On Fri, Mar 25, 2022 at 11:36 AM Patrick Matthäi  wrote:
>
> Hello Andreas,

Hello Patrick,

> > a) remove fuse build-depends and Depends, since they are not needed
> > b) either disable fusermount-glusterfs, or install it suid root, or
> > leave it as is, but document that for it to work the admin needs to
> > chmod u+s that binary and use dpkg-statoverride to not lose that
> > during upgrades.
> What would be your favorite for b)?

I think I would prefer (b) + document that if the user wants
unprivileged mounts to work, they need to make the helper suid root,
and it should be a local site decision, not a packaging one. Where to
document, I think a README.Debian is best.

In fact, I got feedback from our security team strongly advising
against making that helper suid root in the packaging :)

The fact that no-one filed a bug about not being able to do
unprivileged gluster mounts yet I think means either it's not used, or
people know how to fix it. But packaging wise it's ok and better
without the suid root.

> > It would be helpful if you could double check my findings, and then
> > maybe we could drop the fuse build-depends and depends? Unless I
> > overlooked something.
> Looks fine and I think you are more in this topic than myself now :D

About the build deps, I kept them in Ubuntu, as they are not
introducing bugs or other problems for us at the moment, but I still
think they are not needed.

Bug#1007110: cups printing dialogue: broad scrollbar overlaps with pull-down Icon

[Brian Potkin]

reassign 1007110 libreoffice-gtk3
thanks.



On Fri 11 Mar 2022 at 13:26:52 +0100, Michael Hatzold wrote:

> Package: cups
> Version: 2.4.1op1-2
> Severity: normal
> 
> Dear Maintainer,
> 
> first, I file my bugreport against "cups" as I don't know to which exact
> package it really belongs. The bug shows up in the print dialogue.
> 
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> I wanted to print a document from within Libreoffice (gtk3)
> **
> apt policy libreoffice-gtk3
> libreoffice-gtk3:
>   Installiert:   1:7.3.1-1
> **
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> I opened the document which I wanted to print and clicked the file/print menue
> 
>* What was the outcome of this action?
> printing menu opened.
> But when I tried to open one of the pulldown menue using  one of the little
> triangular icons on the right the hidden scrollbar popped up overlapping the
> icon which thus could not been activated.
> 
> Please Note:
> I use a much broader scrollbar than the default one. (I find the default
> ergonimically inapt). But this customisation was made one ore two years ago 
> and
> never effected negatively any menue in whatever program. Until today when I
> wanted to print. So there must have been a change recently which now changes
> the behavior.
> 
> 
>* What outcome did you expect instead?
> Obviously I do not want the scrollbar to overlap a region meant for operating 
> a
> menue and thus making it unusable.

Thank you for your report, Michael.

Print dialogs in an application are not the responsibility of the
printing system. Hence reassigning.

Regards,

Brian.

Bug#994388: dpkg currently warning about merged-usr systems

[Ansgar]

On Thu, 2022-03-24 at 09:12 +0100, Ansgar wrote:
> On Tue, 2022-03-15 at 15:14 -0700, Josh Triplett wrote:
> > This escalation seems in direct contradiction to the tech-ctte
> > decision in 994388.
> 
> It already confuses users, for example:

It was pointed out in #-devel that there are bugs in `dpkg-fsys-
usrunmess` that might make systems no longer boot, at least #1008316
and #1008478.

As I suspect more people will try running it due to the newly
introduced warning by dpkg's postinst script, I feel this will
needlessly break user systems. While we can't avoid all such bugs in
programs to move from/to merged-/usr, I believe we should not recommend
users to do such conversions needlessly (given we have decided to move
to merged-/usr previously).

It feels quite unprofessional for the dpkg maintainer to cause this
avoidable breakage of user systems due to his disagreement with the
project's decision.

Ansgar

Bug#854818: firefox-esr: creates mimeapps.list entries for thunderbird.desktop if started from TB

[Jens Reyer]

control: found -1 thunderbird/1:91.6.2-1
control: found -1 thunderbird/1:91.7.0-2
Control: tags -1 - moreinfo



Hi Simon and all,


On 27.03.22 14:16, Simon McVittie wrote:
> I think this is a description of the same bug as #948691. If that's
> the case, then it should be fixed by thunderbird versions based on
> 1:91.7.0-2, including the 1:91.7.0-2~deb11u1 and 1:91.7.0-2~deb10u1
> versions in bullseye-security and buster-security. Please check
> whether this is still reproducible.

Unfortunately no, I can still reproduce this:

I
- enabled the default-browser check in firefox,
- updated thunderbird,
- removed ~/.local/share/applications/ and ~/.config/mimeapps.list
Then I
- rebooted the system
- started thunderbird/1:91.7.0-2 and
- clicked a link:

firefox-esr/91.7.0esr-1 asked me about becoming the default browser. I
answered yes and got this mimeapps.list:

~
[Default Applications]
x-scheme-handler/http=thunderbird.desktop
x-scheme-handler/https=thunderbird.desktop
x-scheme-handler/chrome=thunderbird.desktop
text/html=thunderbird.desktop
application/x-extension-htm=thunderbird.desktop
application/x-extension-html=thunderbird.desktop
application/x-extension-shtml=thunderbird.desktop
application/xhtml+xml=thunderbird.desktop
application/x-extension-xhtml=thunderbird.desktop
application/x-extension-xht=thunderbird.desktop

[Added Associations]
x-scheme-handler/http=thunderbird.desktop;
x-scheme-handler/https=thunderbird.desktop;
x-scheme-handler/chrome=thunderbird.desktop;
text/html=thunderbird.desktop;
application/x-extension-htm=thunderbird.desktop;
application/x-extension-html=thunderbird.desktop;
application/x-extension-shtml=thunderbird.desktop;
application/xhtml+xml=thunderbird.desktop;
application/x-extension-xhtml=thunderbird.desktop;
application/x-extension-xht=thunderbird.desktop;
~



Is there anything I missed? Because I agree this should be the same as
#948691.



Huge thanks anyway for working on this and keeping bugs.d.o in good
shape, despite my surprising test results!

Greets
jre

Bug#1008175: #1008175

[Brian Potkin]

tags 1008175 moreinfo
thanks


On Wed 23 Mar 2022 at 13:01:18 -0400, Rick Stanley wrote:

> Now neither option works correctly executing from the command line.
> "lpr -o sides=two-sided-long-edge  test.pdf"
> "lpr -o sides=one-sided  test.pdf"
> 
> And same for lp.

Thank you for your report, Rick. What is the printer make and model?

The situation is that neither command gives double-sided printing?
 
> Printing from Okular works correctly as expected.

There is a slight difference between your lp command and what Okular
does. Okular sends a PostScript file to the ptinter. Not that I can
see why that should make any difference, but printing from Evince or
Firefox sens a PDF. You could try that.

Anyway, let's have a log. Enable debug logging with

  cupsctl --debug-logging

Empty error_log with

  >/var/log/cups/error_log

Print and send error_log as an attachment after compressing it.

Regards,

Brian.

Bug#1008490: RM: librust-clap+ansi-term-dev librust-clap+term-size-dev librust-clap+vec-map-dev librust-clap+yaml-dev -- ROM; NBS; Uninstallable

[Peter Michael Green]

Package: ftp.debian.org

The rust-clap source package no longer builds librust-clap+ansi-term-dev 
librust-clap+term-size-dev librust-clap+vec-map-dev and 
librust-clap+yaml-dev . The cruft packages are uninstallable because they

depend on an exact version of librust-clap-dev.

The cruft report claims that cleaning up the cruft will cause broken 
build-dependencies. However this is not
the case because the librust-clap-2-dev package provides those packages 
as virtual packages.

Bug#1007103: Rosegarden: malloc_consolidate(): unaligned fastbin chunk detected

[Ted Felix]

On 3/27/22 1:49 AM, Ron Murray wrote:
I have the same problem here. Removing lmms and fluidsynth-dssi made no 
difference.


I did a debug build and ran it with gdb. The resullt is attached.


  Thanks.  In your case it looks like something called "whysynth" is 
the issue:


/usr/lib/dssi/whysynth.so

  This is shown in the _dl_map_object() entry in the backtrace:

#10 0x77fd59cd in _dl_map_object (loader=0x0,
loader@entry=0x77ffe220, name=name@entry=0x7fffdc1a3e30 
"/usr/lib/dssi/whysynth.so", type=type@entry=2, 
trace_mode=trace_mode@entry=0, mode=mode@entry=-1879048191, 
nsid=) at dl-load.c:2336


  Try uninstalling that.  The others might still be an issue, so don't 
be surprised if it continues to crash and more plugins need to be 
uninstalled.


  There appear to be a number of issues with the various DSSI synth 
plugins.  Someone needs to open bug reports against each of these 
crashing plugins and mention all the others.  That should get us closer 
to finding the real problem.


  This bug report against rosegarden can be closed.

Bug#1008489: dpkg: postinst should not warn about Debian's default filesystem layout

[Ansgar]

Package: dpkg
Version: 1.21.2
Severity: important

Hi,

I think the warning emitted by dpkg's postinst script about Debian's
default filesystem layout is not appropriate and at least partially
misleading. Several other people agreed with this sentiment.

So I would like to ask the dpkg maintainers to drop this warning.

This includes the slightly differently worded version in 1.21.3.

Ansgar

Bug#998101: firefox-l10n-fr: firefox often skips and is replaced by thunderbird (Gnome 41)

[Simon McVittie]

Control: reassign -1 thunderbird 1:91.3.0-1
Control: tags -1 + moreinfo

On Sat, 30 Oct 2021 at 11:44:35 +0200, alain wrote:
> often my browser skips and is replaced by thunderbird .

On Mon, 01 Nov 2021 at 17:35:07 +0100, alain wrote:
> I wonder if the error does not come from Thunderbird.
> 
> When I look at my mails (in thunderbird), the links work one time out of
> two, or even less.
> 
> Almost systematically, the links loop on themselves and not in a browser.
> and this despite a good mimeapps.list.
> 
> I can always rectify the assignment of the programs in gnome, but if I stay
> in thunderbird, the links jump systematically.

I think this is a description of the same bug as #948691. If that's
the case, then it should be fixed by thunderbird versions based on
1:91.7.0-2, including the 1:91.7.0-2~deb11u1 and 1:91.7.0-2~deb10u1
versions in bullseye-security and buster-security. Please check whether
this is still reproducible after upgrading to one of those versions.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948691#52 has the steps
I used to reproduce this.

smcv

Bug#991502: firefox-esr 78.12.0esr keeps setting Thunderbird as gnome3's default web browser

[Simon McVittie]

Control: reassign -1 thunderbird
Control: tags -1 + moreinfo

On Mon, 26 Jul 2021 at 09:24:21 +1000, Russell Stuart wrote:
> For as long as I've had bullseye installed (many months), something has
> been setting Thunderbird as the Web application in
> 
> gnome3->settings->Default Applications->Web
> 
> I finally tracked down what was doing it, and it's Firefox itself.
> Firefox displays the "Firefox is not your default web application"
> dialogue (sorry, I'm not sure of the exact wording).  At that point
> when I check Gnome3's settings page Firefox *is* the default Web
> application.  I then click the Firefox button on that dialogue that
> offers to make Firefox the default web application.  When I refresh
> the Gnome3 "Default Application" settings page Thunderbird is now
> the default Web application.

I think this is a description of the same bug as #948691. If that's
the case, then it should be fixed by thunderbird versions based on
1:91.7.0-2, including the 1:91.7.0-2~deb11u1 and 1:91.7.0-2~deb10u1
versions in bullseye-security and buster-security. Please check whether
this is still reproducible.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948691#52 has the steps
I used to reproduce this.

smcv

Bug#854818: firefox-esr: creates mimeapps.list entries for thunderbird.desktop if started from TB

[Simon McVittie]

Control: reassign -1 thunderbird
Control: tags -1 + moreinfo

On Thu, 16 Mar 2017 at 15:06:44 +0100, Jens Reyer wrote:
> $ rm -rf .local/share/applications/*
> $ rm .config/mimeapps.list
> - Start thunderbird (via launcher or from terminal)
> - Click a https link in thunderbird
> --> Firefox starts and prompts:
> "Default Browser - Firefox is not currently set as
>  your default browser.  Would you like to make it
>  your default browser?"
> --> Click "Use Firefox as my default browser"
> $ cat ~/.config/mimeapps.list
> [Default Applications]
> x-scheme-handler/http=thunderbird.desktop
> x-scheme-handler/https=thunderbird.desktop
> x-scheme-handler/ftp=thunderbird.desktop
> x-scheme-handler/chrome=thunderbird.desktop
> text/html=thunderbird.desktop
> application/x-extension-htm=thunderbird.desktop
> application/x-extension-html=thunderbird.desktop
> application/x-extension-shtml=thunderbird.desktop
> application/xhtml+xml=thunderbird.desktop
> application/x-extension-xhtml=thunderbird.desktop
> application/x-extension-xht=thunderbird.desktop

I think this is a description of the same bug as #948691. If that's
the case, then it should be fixed by thunderbird versions based on
1:91.7.0-2, including the 1:91.7.0-2~deb11u1 and 1:91.7.0-2~deb10u1
versions in bullseye-security and buster-security. Please check whether
this is still reproducible.

On Fri, 19 Nov 2021 at 21:16:09 +0100, Alex Rauch wrote:
> Do firefox and thunderbird share some code?

Yes, a lot of code: they are both based on the Mozilla codebase, and that
shared history was an important part of the root cause for #948691.

smcv

Bug#1008488: Use --enable-parport-directio only on hurd-i386

[Jörg Frings-Fürst]

Source: sane-backends
Version: 1.1.1-4
Severity: normal


Hello,

use ibieee1284-3 on all architectures change handling of 
--enable-parport-directio.



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

Kernel: Linux 5.16.0-5-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Bug#1008487: Opening trash causes to crash GNOME

[Hideo Oshima]

Package: nautilus
Version: 42.0-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
1. Start Nautilus
2. Open Trash

   * What was the outcome of this action?
Crash GNOME and return to login screen.

   * What outcome did you expect instead?
Do not crash GNOME and open trash.

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


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

Kernel: Linux 5.16.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 nautilus depends on:
ii  bubblewrap  0.6.1-1
ii  desktop-file-utils  0.26-1
ii  gsettings-desktop-schemas   42.0-1
ii  gvfs1.50.0-1
ii  libatk1.0-0 2.36.0-3
ii  libc6   2.33-7
ii  libcairo-gobject2   1.16.0-5
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf-2.0-0 2.42.6+dfsg-2
ii  libgexiv2-2 0.14.0-1
ii  libglib2.0-02.72.0-1
ii  libglib2.0-data 2.72.0-1
ii  libgnome-autoar-0-0 0.4.3-1
ii  libgnome-desktop-3-19   42.0-1
ii  libgstreamer-plugins-base1.0-0  1.20.1-1
ii  libgstreamer1.0-0   1.20.1-1
ii  libgtk-3-0  3.24.33-1
ii  libhandy-1-01.5.91-1
ii  libnautilus-extension1a 42.0-1
ii  libpango-1.0-0  1.50.6+ds-1
ii  libselinux1 3.3-1+b2
ii  libtracker-sparql-3.0-0 3.1.2-4
ii  nautilus-data   42.0-1
ii  shared-mime-info2.1-2
ii  tracker 3.1.2-4
ii  tracker-extract 3.1.3-4
ii  tracker-miner-fs3.1.3-4

Versions of packages nautilus recommends:
ii  gnome-sushi   41.0-3
ii  gvfs-backends 1.50.0-1
ii  libgdk-pixbuf2.0-bin  2.42.6+dfsg-2
ii  librsvg2-common   2.52.5+dfsg-3+b1

Versions of packages nautilus suggests:
ii  eog 42.0-1
ii  evince [pdf-viewer] 42.1-1
ii  nautilus-extension-brasero  3.12.3-1
ii  nautilus-sendto 3.8.6-4
ii  totem   42.0-1
ii  vlc [mp3-decoder]   3.0.17.3-1
ii  xdg-user-dirs   0.17-2

-- no debconf information


-- 
大島秀夫(Hideo Oshima)
http://hidenosuke.org/

Bug#1008486: dpkg-fsys-usrunmess: should include warning that systems will be unsupported

[Ansgar]

Package: dpkg
Version: 1.21.2
Severity: serious

Hi,

the `dpkg-fsys-usrunmess` program should include a warning that it
will convert the system into a state that will no longer be supported
in the future by Debian.

Ansgar

Bug#1008329: apertium-spa-arg: FTBFS: configure: error: Package requirements (apertium-lex-tools >= 0.2.7) were not met

[Lucas Nussbaum]

On 26/03/22 at 23:36 +0100, Tino Didriksen wrote:
> This was an expected failure due to new incompatible tool packages, and
> same goes for all the other Apertium-related FTBFS.
> 
> How can one prevent such a slew of superfluous automatic bugs from being
> filed? Is there a way to mark packages as "will be updated, just waiting
> for deps in NEW queue"?

Hi Tino,

First, I don't mind filing those bugs. I try to avoid filing useless
bugs, but generally, when the number of affected packages is relatively
low, investigating the root cause and determining if/where a bug should
be filed is quite hard, and it's simpler to stick to the fact that a
package fails to build, and file a bug for each package. Note that:
- it's easy to identify all bugs there were filed using the BTS usertag
- sometimes, the full set of failures is nontrivial to identify from the
  maintainer's POV, so filing all bugs also has some value to clearly
  identify the scope.

However, if you know that a set of packages FTBFS due to a change in another
package, you could document it using a single bug against the breaking
package, marking all affected packages as "affects" in the BTS.

Lucas

Bug#984897: Merge request to fix this bug

[Niels Thykier]

Santiago Garcia Mantinan:
> Hi!
> 
> This bug came in response for a proper fix in order for the problem we found
> in squid after introducing the new squid-openssl flavour, that was:
> https://bugs.debian.org/984880
> 
> At that time I spoke to Niels Thykier in order to fix this, but it was late
> in the bullseye development cycle a fix on debhelper seemed too dangerous,
> I've further thought about the problem, as the first patch I had sent was
> failing when dh_installsystemd was called with several services, like:
> 
> dh_installsystemd -ppackage first.service second.service
> 
> The new proposal takes this into account and now UNITFILES can really be
> plural, in the sense of have mor than one unit file, and thus I believe this
> is finally a full solution.
> 
> Please consider this merge request:
> https://salsa.debian.org/debian/debhelper/-/merge_requests/65
> so that we can have a proper fix for #984880 on squid in time for bookworm
> and if you need further explanations just let me know.
> 
> Regards.

Hi Santiago,

Thanks for the MR.

@fsateler/@biebl: Please have a look at
https://salsa.debian.org/debian/debhelper/-/merge_requests/65/diffs -
would it make sense to move this check into deb-systemd-helper ?   I
feel the snippet is getting a bit to complex with this.

Thanks,
~Niels

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Marc Haber]

Control: tags -1 
thanks

On Sat, Mar 26, 2022 at 03:51:00PM +0100, Lilo von Hanffstengel wrote:
>  aideinit -f -y
> Running aide --init...
>   ERROR: /etc/aide/aide.conf.d/31_aide_munin-nodes (stdout):1: unexpected 
> character: '/' (line: 
> '/var/cache/munin/www/localdomain\n/(index\.html|localhost\\.localdomain/[-_[:alnum:]]+\.(png|html))$
>  f VarFile/var/lib/munin/localdomain/localhost\\.localdomain\n-.*\.rrd$ f 
> VarFile/@@{RUN}/munin/munin-(update|datafile|localdomain-localhost\\.localdomain|limits)\.lock$
>  f VarFile')

Hi,

can I please see your /etc/munin/munin.conf?

Greetings
Marc

Bug#1008485: cpm: diff for NMU version 0.32-1.4

[Hugh McMaster]

Package: cpm
Version: 0.32-1.3
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for cpm (versioned as 0.32-1.4).

I intend to seek sponsorship for this package. Please let me know
if my sponsor should delay the upload or if you can assist.

Regards,

Hugh
diff -Nru cpm-0.32/debian/changelog cpm-0.32/debian/changelog
--- cpm-0.32/debian/changelog	2020-08-19 04:15:38.0 +1000
+++ cpm-0.32/debian/changelog	2022-03-27 22:15:18.0 +1100
@@ -1,3 +1,31 @@
+cpm (0.32-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to debhelper-compat v13.
+  * debian/changelog: Remove trailing whitespace.
+  * debian/copyright: Switch to DEP-5 format and update for 2022.
+  * debian/control:
+- Priority: extra -> optional.
+- Update Build-Depends:
+  + libgpgme11-dev -> libgpgme-dev.
+  + libncurses5-dev -> libncurses-dev (Closes: #851594).
+  + Require pkg-config.
+  + Remove autotools-dev and dh_autoreconf (no longer needed).
+  + Remove duplicate libcdk5-dev entry.
+- Declare Rules-Requires-Root: binary-targets.
+- Update Vcs-Git and homepage fields.
+- Raise Standards-Version to 4.6.0 (no changes needed).
+- Remove trailing whitespace.
+  * debian/patches:
+- Use pkg-config to find libxml2 (Closes: #949088).
+- Remove non-POSIX features from configure.in (Closes: #998786).
+- Rename 'ftbfs.patch' to fix-ftbfs-gcc-10.patch'.
+  * debian/rules: Remove unneeded dh arguments --parallel --with=autoreconf.
+  * Add debian/upstream/metadata file.
+  * Update debian/watch and point to GitHub.
+
+ -- Hugh McMaster   Sun, 27 Mar 2022 22:15:18 +1100
+
 cpm (0.32-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
@@ -17,7 +45,7 @@
 
   * Non-maintainer upload.
   * Fix ftbfs due to cdk.h moved from /usr/include/cdk to /usr/include
-(Closes: #802221) 
+(Closes: #802221)
 
  -- YunQiang Su   Sun, 18 Oct 2015 23:14:34 +0800
 
@@ -74,6 +102,6 @@
 
 cpm (0.25-1) unstable; urgency=low
 
-  * Initial release (Closes: #55, #588526) 
+  * Initial release (Closes: #55, #588526)
 
  -- Stig Sandbeck Mathisen   Mon, 17 Jan 2011 17:40:55 +0100
diff -Nru cpm-0.32/debian/compat cpm-0.32/debian/compat
--- cpm-0.32/debian/compat	2020-08-19 04:05:18.0 +1000
+++ cpm-0.32/debian/compat	1970-01-01 10:00:00.0 +1000
@@ -1 +0,0 @@
-9
diff -Nru cpm-0.32/debian/control cpm-0.32/debian/control
--- cpm-0.32/debian/control	2020-08-19 04:05:18.0 +1000
+++ cpm-0.32/debian/control	2022-03-27 22:03:31.0 +1100
@@ -1,32 +1,30 @@
 Source: cpm
 Section: utils
-Priority: extra
+Priority: optional
 Maintainer: Kacper Wysocki (Redpill-Linpro) 
 Uploaders: Stig Sandbeck Mathisen 
 Build-Depends:
- debhelper (>= 9~),
- autotools-dev,
- dh-autoreconf,
+ debhelper-compat (= 13),
  libcdk5-dev,
  libcrack2-dev,
  libdotconf-dev,
- libgpgme11-dev,
- libncurses5-dev,
- libncursesw5-dev,
+ libgpgme-dev,
+ libncurses-dev,
  libxml2-dev,
+ pkg-config,
  txt2man,
- zlib1g-dev,
- libcdk5-dev,
-Standards-Version: 3.9.5
-Vcs-Git: git://github.com/comotion/cpm.git
+ zlib1g-dev
+Standards-Version: 4.6.0
+Rules-Requires-Root: binary-targets
+Homepage: https://github.com/comotion/cpm
 Vcs-Browser: https://github.com/comotion/cpm
-Homepage: http://github.com/comotion/cpm
+Vcs-Git: https://github.com/comotion/cpm.git
 
 Package: cpm
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends},
  libxml2-utils
-Description: Curses based password manager using PGP-encryption 
+Description: Curses based password manager using PGP-encryption
  This program is a ncurses based console tool to manage passwords
  and store them public key encrypted in a file - even for more than
  one person. The encryption is handled via GnuPG so the programs data
diff -Nru cpm-0.32/debian/copyright cpm-0.32/debian/copyright
--- cpm-0.32/debian/copyright	2020-08-19 04:05:18.0 +1000
+++ cpm-0.32/debian/copyright	2022-03-27 21:54:53.0 +1100
@@ -1,37 +1,34 @@
-This package was debianized by Lars Bahner  on
-Fri, 03 Apr 2009 14:59:19 +0200.
-
-It was downloaded from http://www.harry-b.de/dokuwiki/doku.php?id=harry:cpm
-
-Upstream Author:
-
-Harry Brueckner 
-
-Copyright:
-
-Copyright (C) 2005-2009 Harry Brueckner
-Copyright (C) 2010 Kacper Wysocki
-
-License:
-
-This package is free software; you can redistribute it and/or modify
-it under the terms of the GNU General Public License as published by
-the Free Software Foundation; either version 2 of the License, or
-(at your option) any later version.
-
-This package is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with this package; if not, write to the Free Software
-

Bug#1008277: Acknowledgement (aideinit stops with error in rule)

[Marc Haber]

Control: clone -1 -2
Control: retitle -1 rule error, probably parsing plesk sources.list line
Control: retitle -2 rule error, probably parsing munin.conf
thanks

Bug#1008360: [Debian-on-mobile-maintainers] Bug#1008360: phoc: FTBFS: ../src/layer_shell.c:244:72: error: ‘struct wlr_layer_surface_v1’ has no member named ‘client_pending’

[Guido Günther]

control: tags -1 +pending

Hi,
On Sat, Mar 26, 2022 at 09:47:37PM +0100, Lucas Nussbaum wrote:
> Source: phoc
> Version: 0.12.0-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220326 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

I'll upload a version that works with wlroots 0.15.1 over the next days.
Upstream MR is here:

   https://gitlab.gnome.org/World/Phosh/phoc/-/merge_requests/329

Cheers,
 -- Guido

> 
> 
> Relevant part (hopefully):
> > cc -Isrc/libphoc.a.p -Isrc -I../src -Iprotocols -I/usr/include/libdrm 
> > -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glib-2.0 
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> > -I/usr/include/gnome-desktop-3.0 -I/usr/include/libxml2 
> > -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 
> > -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 
> > -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gio-unix-2.0 
> > -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
> > -I/usr/include/fribidi -I/usr/include/atk-1.0 -I/usr/include/pixman-1 
> > -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
> > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/x86_64-linux-gnu 
> > -I/usr/include/gsettings-desktop-schemas 
> > -I/<>/obj-x86_64-linux-gnu -fdiagnostics-color=always 
> > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O0 
> > -DWLR_USE_UNSTABLE -Wcast-align -Wdate-time -Werror=format-security 
> > -Werror=format=2 -Wendif-labels -Werror=incompatible-pointer-types 
> > -Werror=missing-declarations -Werror=overflow -Werror=return-type 
> > -Werror=shift-count-overflow -Werror=shift-overflow=2 
> > -Werror=implicit-fallthrough=3 -Wformat-nonliteral -Wformat-security 
> > -Winit-self -Wmaybe-uninitialized -Wmissing-field-initializers 
> > -Wmissing-include-dirs -Wmissing-noreturn -Wnested-externs 
> > -Wno-missing-field-initializers -Wno-sign-compare -Wno-strict-aliasing 
> > -Wno-unused-parameter -Wold-style-definition -Wpointer-arith 
> > -Wredundant-decls -Wshadow -Wstrict-prototypes -Wtype-limits -Wundef 
> > -Wunused-function -Wswitch-default -g -O2 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread -MD 
> > -MQ src/libphoc.a.p/layer_shell.c.o -MF src/libphoc.a.p/layer_shell.c.o.d 
> > -o src/libphoc.a.p/layer_shell.c.o -c ../src/layer_shell.c
> > In file included from ../src/layer_shell.c:15:
> > /usr/include/wlr/types/wlr_box.h:4:2: warning: #warning "wlr_box has been 
> > moved to wlr/util/box.h" [-Wcpp]
> > 4 | #warning "wlr_box has been moved to wlr/util/box.h"
> >   |  ^~~
> > ../src/layer_shell.c: In function ‘arrange_layer’:
> > ../src/layer_shell.c:187:25: warning: implicit declaration of function 
> > ‘wlr_layer_surface_v1_close’; did you mean ‘wlr_layer_surface_v1_destroy’? 
> > [-Wimplicit-function-declaration]
> >   187 | wlr_layer_surface_v1_close(layer);
> >   | ^~
> >   | wlr_layer_surface_v1_destroy
> > ../src/layer_shell.c:187:25: warning: nested extern declaration of 
> > ‘wlr_layer_surface_v1_close’ [-Wnested-externs]
> > ../src/layer_shell.c: In function ‘change_osk’:
> > ../src/layer_shell.c:244:72: error: ‘struct wlr_layer_surface_v1’ has no 
> > member named ‘client_pending’
> >   244 | if (!force_overlay && osk->layer != 
> > osk->surface->layer_surface->client_pending.layer) {
> >   | 
> >^~
> > ../src/layer_shell.c:246:67: error: ‘struct wlr_layer_surface_v1’ has no 
> > member named ‘client_pending’
> >   246 | 
> > wl_list_insert([osk->surface->layer_surface->client_pending.layer], 
> > >surface->link);
> >   |   ^~
> > ../src/layer_shell.c: In function ‘phoc_layer_shell_arrange’:
> > ../src/layer_shell.c:273:53: error: ‘struct wlr_layer_surface_v1’ has no 
> > member named ‘client_pending’
> >   273 |   if (seat->focused_layer && 
> > seat->focused_layer->client_pending.layer >= 
> > osk_place.surface->layer_surface->client_pending.layer) {
> >   | ^~
> > ../src/layer_shell.c:273:111: error: ‘struct wlr_layer_surface_v1’ has no 
> > member named ‘client_pending’
> >   273 |   if (seat->focused_layer && 
> > seat->focused_layer->client_pending.layer >= 
> > osk_place.surface->layer_surface->client_pending.layer) {
> >   | 
> >   ^~
> > ../src/layer_shell.c: In function ‘popup_damage’:
> > ../src/layer_shell.c:436:55: error: ‘struct wlr_xdg_surface’ has no member 
> > named ‘geometry’
> >   436 

Bug#1008277: aideinit stops with error in rule

[Marc Haber]

On Fri, Mar 25, 2022 at 09:36:12PM +0100, Gwen wrote:
>   ERROR: /etc/aide/aide.conf.d/31_aide_apt (stdout):105:70: error in rule 
> '/var/lib/apt/lists/deb\.debian\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\.diff_Index)?$':
>  invalid double slash (line: 
> '/var/lib/apt/lists/deb\\.debian\\.org_debian_dists_bullseye-updates_http://autoinstall.plesk.com/PMM_0.1.11_source_Sources(\\.diff_Index)?$
>  f VarFile')

This looks like an error parsing a sources.list line that contains an
external repository. Can you show all sources.list lines that contain
"autoinstall.plesk.com"?

Greetings
Marc

Bug#1006800: debian-installer: kernel mismatch for bookworm and sid installer. New release needed?

[Roland Clobus]

Removed: rb-gene...@lists.reproducible-builds.org

Hello Cyril,

On 05/03/2022 18:45, Cyril Brulebois wrote:

Roland Clobus  (2022-03-05):

On 05/03/2022 12:40, Cyril Brulebois wrote:

We could, and should, release a new d-i and possibly an Alpha 1 at some
point, but I don't have a specific timeline for that.


Understood. I assume that an Alpha 1 release will be made somewhere
near the release date of bookworm.


In the past I've tried to have an Alpha 1 released after a few months
into the new release cycle, then aim for something like a release every
1-2 months.

But the archive can disagree from time to time, and lately, I'm rather
busy with other things…


Understood. So I've focussed on building the daily image myself, using 
the git version.

This will
1) allow me to generate installer snapshots for testing and unstable 
that have their correct kernel version (because you diligently fix that 
in the git repo)

2) save you the time of doing new releases for testing and unstable.

After some hick-ups, I've got a working version now.
(See my aborted MR27: 
https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/27)


I'm currently preparing a 'rebuild' script for live-build, that will 
reproducibly re-generate an image, including the installer that matches 
that specific point in time.


If you are interested, it might be usable for the daily-build script as 
well, because it will not use the timestamp for SOURCE_DATE_EPOCH of 
midnight (the time the script is started), but the timestamp of the last 
completed snapshot of the archive.



How long do you need to go back / how long do you need to keep a given
build?


I can go back as far as I want right now. There is no need any more for 
the d-i.debian.org snapshots when I recreate the installer.


With kind regards,
Roland


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1004488: Update grpc to new upstream version 1.37

[GCS]

On Fri, Mar 25, 2022 at 9:45 PM Pirate Praveen  wrote:
> With ruby-grpc-tools 1.30.2,
>
> (debian-sid)pravi@mahishi:~$ dpkg -L ruby-grpc-tools
> /usr/share/rubygems-integration/all/gems/grpc-tools-1.30.2/platform_check.rb
> /usr/share/rubygems-integration/all/gems/grpc-tools-1.30.2/version.rb
>
> and with 1.44.0
>
> (debian-sid)pravi@mahishi:~$ dpkg -L ruby-grpc-tools
[...]
> So looks like two .rb files are missing from the deb.
 Update and recheck.
Please note that armel can't build gRPC at the moment due to GCC ICE
and neither mipsel due to a GCC memory allocation problem. Other than
that it should be OK. But of course need to be find out how to do the
transition when GCC has compilation issues on its own.

Regards,
Laszlo/GCS

Bug#1005180: update-mime: conffile can't update settings

[Charles Plessy]

Control: tag -1 pending

Le Tue, Feb 08, 2022 at 04:30:09PM +0200, Yair Yarom a écrit :
> 
> In update-mime, setting all variable with 'my' prevents them from
> being updated by the conf file (/etc/update-mime.conf). Setting them
> to 'our' solves this issue.

Dear Yair,

thank you for your report and the patch, and sorry for the regression.

I have pushed a commit that changes `my` to `our` in all variables of
that block, except for `$conffile` where `our` would not make sense.

I am tagging this patch "pending" but it may take a bit of time before
I upload an update, as I would like to go through of a couple of other
open issues first.

Do you think a backport or a stable update would be needed ?

Have a nice day,

Charles

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


signature.asc
Description: PGP signature

Bug#1008483: libkiwix: CVE-2022-27920

[Salvatore Bonaccorso]

Source: libkiwix
Version: 10.0.0+dfsg-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/kiwix/libkiwix/issues/728
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libkiwix.

CVE-2022-27920[0]:
| libkiwix 10.0.0 and 10.0.1 allows XSS in the built-in webserver
| functionality via the search suggestions URL parameter. This is fixed
| in 10.1.0.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-27920
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-27920
[1] https://github.com/kiwix/libkiwix/issues/728

Regards,
Salvatore

Bug#1008482: imagen use convert without Depends/Recommends on it

[Bill Allombert]

Package: hevea
Version: 2.34-2+b1
Severity: normal

Dear Debian OCaml Maintainers,

imagen use the convert utility (from imagemagick) 
but do not have Depends/Recommends or even Suggests on a package
providing it.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1008377: zanshin: FTBFS: unsatisfiable build-dependencies: libkf5akonadi-dev (>= 4:21.08.40~), libkf5akonadicalendar-dev (>= 4:21.08.40~), libkf5kontactinterface-dev (>= 21.08.40~)

[Aurélien COUDERC]

Le 26 mars 2022 21:52:54 GMT+01:00, Lucas Nussbaum  a écrit :
>
>Hi,

Dear Lucas,

>During a rebuild of all packages in sid, your package failed to build
>on amd64.

Thanks for your bug report.
I uploaded zanshin to unstable instead of experimental by mistake.

This will be fixed once KDE PIM transitions to unstable and zanshin is rebuilt.


Happy hacking !
--
Aurélien

Bug#1008156: telegram-desktop: Crash when switch account

[Mattia Monga]

Package: telegram-desktop
Version: 3.6.1+ds-2
Followup-For: Bug #1008156
X-Debbugs-Cc: mo...@debian.org

I can confirm the same problem. Moreover, my instance crashes also when I 
choose the "Settings" ("Impostazioni" in Italian) menu. 


-- Package-specific info:

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

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

Versions of packages telegram-desktop depends on:
ii  libabsl20210324 0~20210324.2-2
ii  libavcodec587:4.4.1-3+b2
ii  libavformat58   7:4.4.1-3+b2
ii  libavutil56 7:4.4.1-3+b2
ii  libc6   2.33-7
ii  libgcc-s1   12-20220319-1
ii  libglib2.0-02.72.0-1
ii  libglibmm-2.4-1v5   2.66.2-2+b1
ii  libhunspell-1.7-0   1.7.0-4
ii  libjpeg62-turbo 1:2.1.2-1
ii  libkf5waylandclient54:5.90.0-1
ii  liblz4-11.9.3-2
ii  libminizip1 1.1-8+b1
ii  libopenal1  1:1.19.1-2
ii  libopus01.3.1-0.1
ii  libqrcodegencpp11.7.0-2+b1
ii  libqt5core5a [qtbase-abi-5-15-2]5.15.2+dfsg-15
ii  libqt5gui5  5.15.2+dfsg-15
ii  libqt5network5  5.15.2+dfsg-15
ii  libqt5svg5  5.15.2-4
ii  libqt5waylandclient5 [qtwayland-client-abi-5-15-2]  5.15.2-4
ii  libqt5widgets5  5.15.2+dfsg-15
ii  librlottie0-1   0.1+dfsg-2
ii  libsigc++-2.0-0v5   2.10.4-2
ii  libssl1.1   1.1.1n-1
ii  libstdc++6  12-20220319-1
ii  libswresample3  7:4.4.1-3+b2
ii  libswscale5 7:4.4.1-3+b2
ii  libvpx7 1.11.0-2
ii  libx11-62:1.7.2-2+b1
ii  libxcb-keysyms1 0.4.0-1+b2
ii  libxcb-record0  1.14-3
ii  libxcb-screensaver0 1.14-3
ii  libxcb1 1.14-3
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.4-1
ii  libxfixes3  1:6.0.0-1
ii  libxrandr2  2:1.5.2-1
ii  libxtst62:1.2.3-1
ii  libxxhash0  0.8.1-1
ii  qt5-image-formats-plugins   5.15.2-2+b1
ii  zlib1g  1:1.2.11.dfsg-4

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans  1.11-2

telegram-desktop suggests no packages.

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal 1.14.1-1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-backend]  42.0.1-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.14.0-1

-- no debconf information
[2022.03.27 09:17:34] Launched version: 3006001, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2022.03.27 09:17:34] Executable dir: /usr/bin/, name: telegram-desktop
[2022.03.27 09:17:34] Initial working dir: 
/opt/unburden/.unburden-monga/local/share/
[2022.03.27 09:17:34] Working dir: /home/monga/.local/share/TelegramDesktop/
[2022.03.27 09:17:34] Command line: telegram-desktop
[2022.03.27 09:17:34] Executable path before check: /usr/bin/telegram-desktop
[2022.03.27 09:17:34] Logs started
[2022.03.27 09:17:34] Launcher filename: telegramdesktop.desktop
[2022.03.27 09:17:34] We use allocator from /lib/x86_64-linux-gnu/libc.so.6
[2022.03.27 09:17:34] IBus portal is present! Using it.
[2022.03.27 09:17:34] Getting DE, XDG_CURRENT_DESKTOP: 'GNOME'
[2022.03.27 09:17:34] Getting DE, XDG_SESSION_DESKTOP: 'gnome-xorg'
[2022.03.27 09:17:34] Getting DE, 

Bug#1008481: Add SDL_IM_MODULE to fcitx4 and fcitx5

[Shengjing Zhu]

Source: im-config
Version: 0.50-2
Severity: wishlist
X-Debbugs-Cc: z...@debian.org

Origin from 
https://salsa.debian.org/input-method-team/im-config/-/merge_requests/14

I asked the author to submit a bug first. But we haven't received so far.

sdl2 supports reading SDL_IM_MODULE, but the supported value is only fcitx,
otherwise it uses ibus.

Fcitx support in sdl2 package: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881042
Upstream code: 
https://github.com/libsdl-org/SDL/blob/120c76c8/src/core/linux/SDL_ime.c#L46-L49

So adding SDL_IM_MODULE=fcitx to fcitx4 and fcitx5 is reasonable.

Bug#1007103: Rosegarden: malloc_consolidate(): unaligned fastbin chunk detected

[Ron Murray]

I have the same problem here. Removing lmms and fluidsynth-dssi made no
difference.

I did a debug build and ran it with gdb. The resullt is attached.


-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761

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

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from rosegarden...
(gdb) r
Starting program: 
/home/ron/wombat/Debian/rosegarden/rosegarden-21.12/obj-x86_64-linux-gnu/rosegarden
 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7126c640 (LWP 1582992)]
[main] System Locale: "en_US"
[main] Qt translations path:  "/usr/share/qt5/translations"
[main] Qt translations loaded successfully.
[main] RG Translation: trying to load :locale/ "en_US"
[main] RG Translations loaded successfully.
[main] Loaded application icon " "rg-rwb-rose3-16x16" "
[main] Loaded application icon " "rg-rwb-rose3-32x32" "
[main] Loaded application icon " "rg-rwb-rose3-48x48" "
[main] Loaded application icon " "rg-rwb-rose3-64x64" "
[main] Loaded application icon " "rg-rwb-rose3-128x128" "
[main] Unbundling examples...
[main] Unbundling templates...
[main] Unbundling libraries (device files)...
[New Thread 0x7fffe7a9b640 (LWP 1583819)]
[main] Creating RosegardenMainWindow instance...
[New Thread 0x7fffe711d640 (LWP 1584216)]
[SequencerThread] run()
[New Thread 0x7fffe691c640 (LWP 1584223)]
[PluginFactory] PluginFactory::instance( "dssi" ): creating new 
DSSIPluginFactory
[JackDriver] initialise() begin...
[New Thread 0x7fffe611b640 (LWP 1584314)]
[New Thread 0x7fffe5f26640 (LWP 1584322)]
[JackDriver] initialise() - JACK sample rate =  48000 Hz, buffer size =  1024
[JackDriver] initialise() - creating disk thread...
[New Thread 0x7fffe5cef640 (LWP 1584368)]
[New Thread 0x7fffe59aa640 (LWP 1584372)]
[JackDriver] initialise() - found  6  JACK physical outputs
[JackDriver] initialise() - connecting from  " rosegarden:master out L " to " 
system:playback_1 "
[JackDriver] initialise() - connecting from  " rosegarden:master out R " to " 
system:playback_2 "
[JackDriver] initialise() - found  2  JACK physical inputs
[JackDriver] initialise() - connecting from  " system:capture_1 " to " 
rosegarden:record in 1 L "
[JackDriver] initialise() - connecting from  " system:capture_2 " to " 
rosegarden:record in 1 R "
[JackDriver] initialise() - initialised JACK audio subsystem
malloc_consolidate(): unaligned fastbin chunk detected

Thread 5 "QThread" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe691c640 (LWP 1584223)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
49  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x75fe8546 in __GI_abort () at abort.c:79
#2  0x7603feb8 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7615da78 "%s\n")
at ../sysdeps/posix/libc_fatal.c:155
#3  0x7604791a in malloc_printerr
(str=str@entry=0x7615fde8 "malloc_consolidate(): unaligned fastbin 
chunk detected") at malloc.c:5628
#4  0x760489c4 in malloc_consolidate (av=av@entry=0x7fffdc20) at 
malloc.c:4709
#5  0x7604a855 in _int_malloc (av=av@entry=0x7fffdc20, 
bytes=bytes@entry=1218) at malloc.c:3924
#6  0x7604d191 in __libc_calloc (n=, 
elem_size=) at malloc.c:3639
#7  0x77fd8431 in calloc (b=1, a=) at 
../include/rtld-malloc.h:44
#8  _dl_new_object
(realname=realname@entry=0x7fffdc1d9230 "/usr/lib/dssi/whysynth.so", 
libname=libname@entry=0x7fffdc1a3e30 "/usr/lib/dssi/whysynth.so", 
type=type@entry=2, loader=loader@entry=0x0, mode=mode@entry=-1879048191, 
nsid=nsid@entry=0)
at dl-object.c:89
#9  0x77fd42fa in _dl_map_object_from_fd
(name=name@entry=0x7fffdc1a3e30 "/usr/lib/dssi/whysynth.so", 
origname=origname@entry=0x0, fd=24, fbp=fbp@entry=0x7fffe691afd0, 
realname=0x7fffdc1d9230 "/usr/lib/dssi/whysynth.so", loader=loader@entry=0x0, 
l_type=2, mode=-1879048191, stack_endp=0x7fffe691afc8, nsid=0) at dl-load.c:1077
#10 0x77fd59cd in _dl_map_object (loader=0x0, 
loader@entry=0x77ffe220, name=name@entry=0x7fffdc1a3e30 
"/usr/lib/dssi/whysynth.so", type=type@entry=2,