Bug#1032365: missing manual page

[VA]

Package: python3-hatchling
Version: 1.12.2-1

hatchling has no manual page

Bug#1032364: Testing Install (update e2fsck)

[Cyril Brulebois]

Hi,

and thanks for your report.

Bud Heal  (2023-03-05):
> Boot method: DVD (3/2/2023) then daily CD (3/4/2023)
> Image version: debian-testing-amd64-DVD-1.jigdo
> <https://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-dvd/debian-testing-amd64-DVD-1.jigdo>
> debian-testing-amd64-netinst.jigdo
> <https://cdimage.debian.org/cdimage/daily-builds/daily/20230304-7/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo>
> debian-testing-amd64-netinst.template
> <https://cdimage.debian.org/cdimage/daily-builds/daily/20230304-7/amd64/jigdo-cd/debian-testing-amd64-netinst.template>
>  Date: 3/2/2023 (into 3/3/2023) and 3/4/2023

Why not using the official release? You wouldn't have run into the
e2fsprogs problems that have been plaguing unstable for weeks (a fix was
only uploaded hours ago).

> I intend to mirror the SATA and the M.2 4TB - the installer still does
> not support encrypted partitions - unless it is setting up a new one.

I'm not sure what you mean by that.

> The installer finishes and reboots but the reboot immediately aborts:
> 
> /dev/mapper/...-vg-root has unsupported feature(s): FEATURE_C12
> 
> e2fsck: Get a newer [copy] of e2fsck!

See #1031622, #1030939, etc.

Using an official release would have avoided running into that…

> It was not clear how to obtain an updated e2fsck and how to insert it
> into the workflow; I can wait for the next (pre-)release.
> 
> The daily CD's template may have been mismatched to the jigdo -
> jigdo-lite prompted for '42' in lieu of 'OK'.

No idea about that particular bit.

> The install complained about /media/lairdheal/USB
> DISK/iwlwifi-so-a0-hr-b0-71.ucode (which I found it on github) and 72
> (which I found in firmware-iwlwifi_20230210-1_all.deb)
> 
> The installer did not open the .deb to use its contents. Since I was
> not using wifi, I did not bother to unpack it either. It looks much
> neater than the wild goose chase when I set up this HP Omen in 2020 or
> 2021.

Can you please share the whole /var/log/installer/syslog file (attaching
it compressed)? iwlwifi requests many files (several dozens…), but it
should be happy once the firmware-iwlwifi found on the installation
image is found and unpacked. You shouldn't have to touch any files,
found on GitHub or in Debian packages.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1032364: Testing Install (update e2fsck)

[Bud Heal]

Package: installation-reports

Boot method: DVD (3/2/2023) then daily CD (3/4/2023)
Image version: debian-testing-amd64-DVD-1.jigdo
<https://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-dvd/debian-testing-amd64-DVD-1.jigdo>
debian-testing-amd64-netinst.jigdo
<https://cdimage.debian.org/cdimage/daily-builds/daily/20230304-7/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo>
debian-testing-amd64-netinst.template
<https://cdimage.debian.org/cdimage/daily-builds/daily/20230304-7/amd64/jigdo-cd/debian-testing-amd64-netinst.template>
 Date: 3/2/2023 (into 3/3/2023) and 3/4/2023

Machine: Acer Nitro 5
Processor: i7, 14-core
Memory: 32GB
Partitions: too hard to pick up - simple partition on a 4TB M.2 - with
the DVD install, 4TB 2.5" SATA - in each case the partitions set up
were identical

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

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

Comments/Problems:

I intend to mirror the SATA and the M.2 4TB - the installer still does
not support encrypted partitions - unless it is setting up a new one.

The installer finishes and reboots but the reboot immediately aborts:

/dev/mapper/...-vg-root has unsupported feature(s): FEATURE_C12

e2fsck: Get a newer [copy] of e2fsck!

It was not clear how to obtain an updated e2fsck and how to insert it
into the workflow; I can wait for the next (pre-)release.

The daily CD's template may have been mismatched to the jigdo -
jigdo-lite prompted for '42' in lieu of 'OK'.

The install complained about /media/lairdheal/USB
DISK/iwlwifi-so-a0-hr-b0-71.ucode (which I found it on github) and 72
(which I found in firmware-iwlwifi_20230210-1_all.deb)

The installer did not open the .deb to use its contents. Since I was
not using wifi, I did not bother to unpack it either. It looks much
neater than the wild goose chase when I set up this HP Omen in 2020 or
2021.

Maybe the 4TB partitions are throwing the monkey wrench into the
e2fsck works. The installer said that was the maximum.

Bug#1006486: gnome metapackage should recommend gnome-initial-setup

[YOSHINO Yoshihito]

Package: gnome
Followup-For: Bug #1006486
X-Debbugs-Cc: hwans...@mailbox.org, z...@debian.org

Dear Maintainer,

I see the welcome page of gnome-initial-setup should provide a pleasant
experience for a first-time user in most cases. However, unfortunately
another page severely affects some users.

For Japanese language (and perhaps Traditional Chinese language) users
its keyboard page hurts our installation badly (See Bug#984875,
Bug#1021434, and Bug#1029821.) So task-japanese-gnome-desktop
deliberately excludes the package from its Recommends, and each
task--gnome-desktop Recommends the package only if the
language really needs it in the previous Bullseye freeze (Bug#983653.)
However, this bug has broken all our efforts.

I ask you to consider the reversal of the gnome-initial-setup inclusion.

Regards,

-- 
YOSHINO Yoshihito 

Bug#872419: gimp: Toolbox icons missed

[Jeremy Bícha]

On Sat, Mar 4, 2023 at 9:16 PM Thorben T.  wrote:
> On Sat, Mar 04, 2023 at 06:41:19PM -0500, Jeremy B??cha wrote:
> > Yes, we could do this. [...]
>
> thanks for your response,
> but 94% of it appear to consist of you trying to educate me about
> recommends, which is off-topic. (and i find it inappropriate and
> offensive.)

I'm sorry if I came across as rude. I only meant that there are other
more subtle issues you will probably run into.

Your feedback was useful and this bug should be fixed as you
suggested. Debian is effectively in Hard Freeze now so there is extra
paperwork we need to do if we are going to fix this bug for Debian 12.

Thank you,
Jeremy Bícha

Bug#1017925: RM: node-request/2.88.1-5

[Yadd]

On 3/4/23 20:14, Paul Gevers wrote:

Hi Yadd,

On 22-08-2022 22:01, Paul Gevers wrote:

On 22-08-2022 17:26, Yadd wrote:

could you remove node-request from testing ? Following #956423, it
shouldn't be part of next stable release. All its reverse dependencies
are already removed from testing (yarnpkg, node-matrix-sdk).


node-request is a build-dependency of node-yarnpkg which still is in 
testing. node-yarnpkg is a key-package, so that needs to be resolved 
first.


I don't expect this to happen anymore for bookworm right? You still have 
a couple of weeks though.


Paul


Hi,

yarnpkg is not required for JS, but it seems a key package for ruby-* 
packages. It's hard to replace node-request here.


Cheers,
Yadd

Bug#1031489: why dont work LD_PRELOAD Mesa libGL.so.1?

[Alexander Procenko]

why dont work LD_PRELOAD Mesa libGL.so.1?
https://pastebin.com/raw/jCgPGPkJ

Bug#1032363: Using ansible is broken: ERROR: Ansible requires the locale encoding to be UTF-8; Detected None.

[Daniel Leidert]

Package: vmdb2
Version: 0.26-2
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I recently started to receive errors when building images using the ansible
directive:

DEBUG STDERR: ERROR: Ansible requires the locale encoding to be UTF-8; Detected 
None.

There is a check in /usr/lib/python3/dist-packages/ansible/cli/__init__.py in
initialize_locale() to ensure that the locale is an UTF-8 locale. However, the
vmdb2 ansible plugin runs ansible-playbook via vmdb.runcmd() and this sets
LC_ALL to "C", thus the ansible test is failing.

Unfortunately, there is no way for the user to override this. The quick and
easy solution would be to set:

env["LC_ALL"] = "C.UTF-8"

in vmdb/runcmd.py in runcmd().

Please consider fixing this for Bookworm, otherwise using ansible will be 
broken.

Regards, Daniel

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

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

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32.14.gcdfe14e-5
ii  debootstrap 1.0.128+nmu2
hi  e2fsprogs   1.46.6-1
ii  kpartx  0.9.4-3
ii  parted  3.5-3
ii  python3 3.11.2-1
ii  python3-jinja2  3.1.2-1
ii  python3-yaml6.0-3+b2
ii  qemu-utils  1:7.2+dfsg-4

Versions of packages vmdb2 recommends:
ii  ansible   7.3.0+dfsg-1
ii  dosfstools4.2-1
ii  qemu-user-static  1:7.2+dfsg-4

vmdb2 suggests no packages.

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/lib/python3/dist-packages/vmdb/runcmd.py (from vmdb2 
package)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmQD/o4ACgkQS80FZ8KW
0F1aoBAA2WFaRlX6pW+BNWTx+sc5MPnIh4rrK6yvWpwX0Mb0IDfFnSezlz64HHaj
MHT8mI7mdD2wpEuHyUF6jxD/7IzAIyd4L3yaUV2d7pYjL3IDfeLa6GqKRYhthfiF
UtSLuy2Q4kUnfllWxOC7Y3BUd5sAVcw/L+dwoEQKwjz0XAHLPMq1A9gHvZlt5pcX
g03dvIimobNzeELvOY4Caa2CpfVxIRkVIaSz/s99qE9p0jPgD8LDhg4oJfF3migv
VTCb6k3g/bHgyuUI0h8GWEre4J/B+H7DPfVFb3p+av5p3fI1PhgsD6Tk+U5m7OJm
nR+R0zmCTnzT5YxS45TLeSFJJ5Yq34ae6jKASup3s6UIVM288ALDgSNm18+akjdo
E50hwBH2mMGkKfqcg15MkNOc3XWJFGT9g4ymXP/lmwnucHcPIvqfl8Bjy5m0RPfg
Z3F4BwkmE83NcF6v7L1MK/YogjeRC7EO85Xsb1puuUBER2ripIj6d2c7HzpEHuAr
PqxSTIhVjBFDItINnNqY6Cd6PBbcfxkUGIBbKUEOSOJTVTIBC+baj76JzrhR92G7
rCNgQNVk+FOm4Ysau4/Qawnex0xivNvnqQUt5RR5vxv0msokoXGWI9ZUCCqGhCKc
63mspc20+PP2xvLsGjQ34ye5JnrWgjhrGIp6UQhNksPqTxPke4M=
=ZE4q
-END PGP SIGNATURE-

Bug#872419: gimp: Toolbox icons missed

[Thorben T.]

On Sat, Mar 04, 2023 at 06:41:19PM -0500, Jeremy B??cha wrote:
> Yes, we could do this. [...]

thanks for your response,
but 94% of it appear to consist of you trying to educate me about
recommends, which is off-topic. (and i find it inappropriate and
offensive.)

i was not complaining, i can deal with this just fine,
you can close this ticket as "working as intended" all you like.
(but as this had not been done five years ago, it would appear
 that my reply was necessary.)

- T.

Bug#1032362: Kernel doesn't find SATA ports on Softiron 1000 (arm64 Seattle)

[Steve McIntyre]

On Sun, Mar 05, 2023 at 12:09:24AM +, Steve McIntyre wrote:
>Source: linux
>Version: 6.1.12-1
>Severity: important
>
>Hey folks,
>
>I've just upgraded my Seattle-based system to bookworm and it no
>longer finds the onboard AHCI SATA storage so it stops at an initramfs
>prompt. Going back to the current bullseye kernel (5.10.162-1), it all
>works just fine.
>
>As far as I can see, the DTB hasn't changed in this area. The
>non-booting system still has plausible-looking entries for the sATA
>controllers:
>
>drwxr-xr-x2 000 Mar  5 00:00 
>/sys/firmware/devicetree/base/smb/sata@e030
>drwxr-xr-x2 000 Mar  5 00:00 
>/sys/firmware/devicetree/base/smb/sata@e0d0
>
>I'll try to bisect and see where things stopped working...

The failure appears in between

Linux maul 6.0.0-6-arm64 #1 SMP Debian 6.0.12-1 (2022-12-09) aarch64 GNU/Linux

and

Linux (none) 6.1.0-0-arm64 #1 SMP Debian 6.1~rc3-1~exp1 (2022-11-02) aarch64 
GNU/Linux

A quick look at the output of

"git diff -r debian/6.0.12-1..debian/6.1_rc3-1_exp1"

in the debian linux tree doesn't show me anything likely,
BICBW. Adding a CC to the debian-arm list in case any of our friendly
local ARM kernel folks might be able to help...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#1011616: RFC: Fixing golang-github-tidwall-gjson's RC bugginess for bookworm

[Thorsten Alteholz]

Hi Cyril,

On Sun, 5 Mar 2023, Cyril Brulebois wrote:

TL;DR, current plan:
1. upload 1.14.4-1 to experimental;
2. watch for fallouts;
3. decide what to consider for unstable and put the release team in the
   loop.

Comments, yay, nay, alternative takes, etc. are welcome!


as you seem to have done almost all the work already, I am for: yay
(and thanks for doing it)

  Thorsten

Bug#1032362: Kernel doesn't find SATA ports on Softiron 1000 (arm64 Seattle)

[Steve McIntyre]

Source: linux
Version: 6.1.12-1
Severity: important

Hey folks,

I've just upgraded my Seattle-based system to bookworm and it no
longer finds the onboard AHCI SATA storage so it stops at an initramfs
prompt. Going back to the current bullseye kernel (5.10.162-1), it all
works just fine.

As far as I can see, the DTB hasn't changed in this area. The
non-booting system still has plausible-looking entries for the sATA
controllers:

drwxr-xr-x2 000 Mar  5 00:00 
/sys/firmware/devicetree/base/smb/sata@e030
drwxr-xr-x2 000 Mar  5 00:00 
/sys/firmware/devicetree/base/smb/sata@e0d0

I'll try to bisect and see where things stopped working...

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

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

Bug#1000225: RFC: Fixing golang-github-tidwall-gjson's RC bugginess for bookworm

[Cyril Brulebois]

Hi,

As usual, with my crowdsec maintainer hat, I'm interested in keeping it
in testing, and the next problem is golang-github-tidwall-gjson's
autoremoval due to its security bugs (cc'd).

Currently, we have a 1.6.7 version, those bugs are supposed to be fixed
in 1.9.x, and upstream is at 1.14.4…

This library is about parsing JSON, is basically one big go file (along
with another one for the tests), and I'm not exactly sure what the best
way to go would be.

Since that's about parsing things, I suppose it wouldn't be trivial to
backport the security fixes from 1.9.2 and 1.9.3 without understanding
how parsing works, and why it was buggy in 1.6.7. Shipping the latest
1.9.x would probably be safer. But then, if we're going to have a bump
in upstream releases, maybe considering the latest would make most
sense? We would get those fixes, possible other ones, and that would
minimize the delta whenever other security fixes come up?

The reverse dependencies are quite limited:

1. according to dak:

Checking reverse dependencies...
# Broken Depends:
golang-github-appleboy-gin-jwt: golang-github-appleboy-gin-jwt-dev
golang-github-tidwall-buntdb: golang-github-tidwall-buntdb-dev
golang-github-tidwall-grect: golang-github-tidwall-grect-dev

# Broken Build-Depends:
g10k: golang-github-tidwall-gjson-dev
golang-github-appleboy-gin-jwt: golang-github-tidwall-gjson-dev
golang-github-tidwall-buntdb: golang-github-tidwall-gjson-dev
golang-github-tidwall-grect: golang-github-tidwall-gjson-dev
wuzz: golang-github-tidwall-gjson-dev

(crowdsec appears in the picture via golang-github-appleboy-gin-jwt)

2. according to ratt, a straightforward update to 1.14.4 would seem
   rather reasonable:

(unstable-amd64-crowdsec)kibi@genova:~/work/clients/crowdsec/git/salsa$ 
ratt -dist sid -sbuild_dist sid 
golang-github-tidwall-gjson_1.14.4-1_amd64.changes 
2023/03/04 22:57:32 Loading changes file 
"golang-github-tidwall-gjson_1.14.4-1_amd64.changes"
2023/03/04 22:57:32  - 1 binary packages: golang-github-tidwall-gjson-dev
2023/03/04 22:57:32 Corresponding .debs (will be injected when building):
2023/03/04 22:57:32 golang-github-tidwall-gjson-dev_1.14.4-1_all.deb
2023/03/04 22:57:32 Figuring out reverse build dependencies using 
dose-ceve(1). This might take a while
2023/03/04 22:57:51 Building package 1 of 10: crowdsec-firewall-bouncer 
2023/03/04 22:58:54 Building package 2 of 10: garagemq 
2023/03/04 22:59:59 Building package 3 of 10: crowdsec 
2023/03/04 23:02:04 Building package 4 of 10: wuzz 
2023/03/04 23:02:41 Building package 5 of 10: golang-github-tidwall-buntdb 
2023/03/04 23:03:16 Building package 6 of 10: golang-github-tidwall-grect 
2023/03/04 23:03:46 Building package 7 of 10: g10k 
2023/03/04 23:04:21 Building package 8 of 10: crowdsec-custom-bouncer 
2023/03/04 23:05:21 Building package 9 of 10: 
golang-github-appleboy-gin-jwt 
2023/03/04 23:06:01 Building package 10 of 10: 
golang-github-crowdsecurity-go-cs-bouncer 
2023/03/04 23:06:56 Build results:
2023/03/04 23:06:56 PASSED: crowdsec
2023/03/04 23:06:56 PASSED: wuzz
2023/03/04 23:06:56 PASSED: golang-github-tidwall-buntdb
2023/03/04 23:06:56 PASSED: golang-github-tidwall-grect
2023/03/04 23:06:56 PASSED: golang-github-crowdsecurity-go-cs-bouncer
2023/03/04 23:06:56 PASSED: crowdsec-firewall-bouncer
2023/03/04 23:06:56 PASSED: garagemq
2023/03/04 23:06:56 PASSED: g10k
2023/03/04 23:06:56 PASSED: crowdsec-custom-bouncer
2023/03/04 23:06:56 PASSED: golang-github-appleboy-gin-jwt

My initial plan would be to upload this 1.14.4-1 to experimental,
leaving space (version-wise) in unstable in case someone pushes for an
1.6.7 update, or something 1.9.x-based.

I think (but I'm not sure) uploading to experimental would trigger
autopkgtest in reverse dependencies, which should tell us more about
possible fallouts from this update (as ratt running locally only tests
builds on amd64). If that's indeed the case, this would mean being a
little more reassured regarding proposing this update for unstable, then
have it considered for testing? In any case, I think filing an unblock
request before any upload to unstable would make sense, asking for
pre-approval for whatever we end up considering as the target for
bookworm.

TL;DR, current plan:
 1. upload 1.14.4-1 to experimental;
 2. watch for fallouts;
 3. decide what to consider for unstable and put the release team in the
loop.

And of course, I'm happy to sign up to deal with any side effects that
might appear in the 10 reverse dependencies listed above…


Comments, yay, nay, alternative takes, etc. are welcome!


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#872419: gimp: Toolbox icons missed

[Jeremy Bícha]

On Sat, Mar 4, 2023 at 3:51 PM Thorben T.  wrote:
> i experienced the same issue, and found that this is caused by not having
> librsvg2-common installed.
> gimp depends on librsvg2-2, but librsvg2-2 merrily recommends librsvg2-common.
> i disabled installation of recommended packages on my system.
>
> i can't tell if this is the intended behaviour when disabling recommends.
> but i guess it should be considered to have gimp depend on librsvg2-common.

Yes, we could do this. Please know that you will have many missing
features (or added bugs) if you disable installing recommends. You
likely won't know why things aren't working because the missing
recommends may be far down the dependency stack like it was in this
case. Most Debian Developers do not disable recommends which means it
is not really a tested configuration. You're on your own then. Good
luck!

Thank you,
Jeremy Bícha

Bug#1032361: RFS: srcpd/2.1.5-1 [ITP] -- SRCP server daemon to control digital model railroads

[Hilmar Preusse]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : srcpd
   Version  : 2.1.5-1
   Upstream contact : Guido Scholz 
 * URL  : https://srcpd.sourceforge.net/srcpd/index.html
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/hilmar-guest/srcpd
   Section  : electronics

The source builds the following binary packages:

  srcpd - SRCP server daemon to control digital model railroads

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/s/srcpd/srcpd_2.1.5-1.dsc

Changes for the initial release:

 srcpd (2.1.5-1) UNRELEASED; urgency=medium
 .
   * Initial release. (Closes: #1032354)

Regards,
-- 
  Hilmar Preusse

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1027684: blueman: no legacy pairing with BT-Speaker

[Christopher Schramm]

Hi Michael,

sorry for the late reply.

Unfortunately blueman 2.1 has a buggy PIN database built-in that 
probably leads to a random 4-digit PIN getting provided in this case 
instead of the  that the device expects.


However, the database is not part of blueman 2.3 anymore, so I would 
expect the PIN code request to show up in testing. In case it does not, 
please see 
https://github.com/blueman-project/blueman/wiki/Troubleshooting#debugging-blueman 
on debug logging and check what you get with it when trying to pair the 
device.


Cheers

Bug#1032256: blueman: auto-connect incomplete, needs additional "bluetoothctl connect " to work

[Christopher Schramm]

Hi Alf,

those protocols are completely run by the audio server, which in your 
case seems to be PipeWire. blueman does not have any stake in it.


Regards

Bug#1032329: prometheus-node-exporter: --collector.netdev.device-include cannot be used

[Daniel Swarbrick]

You can use --collector.netdev.device-include if you simply ensure that 
--collector.netdev.device-exclude is empty, e.g.:


prometheus-node-exporter --collector.netdev.device-exclude= 
--collector.netdev.device-include=eno1




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031489: Xubuntu 23.04 (Lunar Lobster)+ 340.108 + Qt 5.15.8 = ALL QT WORKING GOOD

[Alexander Procenko]

Xubuntu 23.04 (Lunar Lobster)+ 340.108 + Qt 5.15.8 = ALL QT WORKING GOOD
https://i.imgur.com/BWdskjd.png
So its Debian issue?

Bug#1032360: ITP: google-apis-pubsub_v1 -- Simple REST client for Cloud Pub/Sub API V1

[Ravi Dwivedi]

package: wnpp
Severity: wishlist
Owner: Ravi Dwivedi 

*Package Name : google-apis-pubsub_v1
 Version : 0.7.0
 Upstream Author : Google LLC
*URL : 
https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-pubsub_v1

*License : Apache-2.0
*Description :  This is the simple REST client for Cloud Pub/Sub API V1.

I am packaging google-apis-pubsub_v1 as this gem is required to package 
gitlab. See 
https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/191.


---
Ravi Dwivedi

Bug#1032330: amanda-client: backups fail with the following summary "FAILED [no backup size line]"

[Jose M Calhariz]

Hi,

I was able to reproduce the problem on my setup.  While I search for a 
fix you may use another
workaround.  The option ``program "GNUTAR"`` is broken but ``program 
"APPLICATION" application "amgtar"``

works and you have more control still using tar.

Use man amgtar for more information.


Kind regards
Jose M Calhariz

On 3/4/23 06:17, Norman Lyon wrote:

Package: amanda-client
Version: 1:3.5.1-10
Severity: normal

Dear Maintainer,

* What led up to the situation?
upgrade of amanda-{client,common,server} from 1:3.5.1-9+b1 to 1:3.5.1-10
* What exactly did you do (or not do) that was effective (or
  ineffective)?
standard backup with normal package: failed.
* What was the outcome of this action?
runtar completes in sane manner, defaulDailySet1g to stdout; sendbackup
completes; backup works

myUser@mySystem:~$ for f in sendbackup.20230303031033.debug
runtar.20230303031033.debug ; do printf
"==\n/var/log/amanda/client/DailySet1/$f\n==\n" ; sudo cat
/var/log/amanda/client/DailySet1/$f ; done
==
/var/log/amanda/client/DailySet1/sendbackup.20230303031033.debug
==
Fri Mar 03 03:10:33.465231875 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448741 ruid 34 euid 34 version 3.5.1: start at Fri Mar  3
03:10:33 2023
Fri Mar 03 03:10:33.465266461 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Version 3.5.1
Fri Mar 03 03:10:33.465782977 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448741 ruid 34 euid 34 version 3.5.1: rename at Fri Mar  3
03:10:33 2023
Fri Mar 03 03:10:33.465876561 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup:   Parsed request as: program `GNUTAR'
Fri Mar 03 03:10:33.465885463 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup:  disk `/boot'
Fri Mar 03 03:10:33.465890405 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup:  device `/boot'
Fri Mar 03 03:10:33.465894886 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup:  level 1
Fri Mar 03 03:10:33.465899391 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup:  since NODATE
Fri Mar 03 03:10:33.465903975 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup:  options `'
Fri Mar 03 03:10:33.465908806 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup:  datapath `AMANDA'
Fri Mar 03 03:10:33.465963068 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: start: mySystem:/boot lev 1
Fri Mar 03 03:10:33.465978023 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Spawning "/bin/gzip /bin/gzip --best" in pipeline
Fri Mar 03 03:10:33.466337828 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: gnutar: pid 1448743: /bin/gzip
Fri Mar 03 03:10:33.466360045 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: pid 1448743: /bin/gzip --best
Fri Mar 03 03:10:33.48981 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: doing level 1 dump as listed-incremental from
'/var/lib/amanda/gnutar-lists/mySystem_boot_0' to
'/var/lib/amanda/gnutar-lists/mySystem_boot_1.new'
Fri Mar 03 03:10:33.467301177 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Spawning "/usr/lib/amanda/runtar runtar DailySet1 /bin/tar
--create --file - --directory /boot --one-file-system --listed-incremental
/var/lib/amanda/gnutar-lists/mySystem_boot_1.new --sparse
--ignore-failed-read --totals ." in pipeline
Fri Mar 03 03:10:33.467327842 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Dupped file descriptor 3 to 11
Fri Mar 03 03:10:33.467621737 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: gnutar: /usr/lib/amanda/runtar: pid 1448747
Fri Mar 03 03:10:33.467655460 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: shm_ring_link /amanda_shm_control-1448740-0
Fri Mar 03 03:10:33.467707662 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646e000 1
Fri Mar 03 03:10:33.467726841 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646d000 1
Fri Mar 03 03:10:33.467742817 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646c000 1
Fri Mar 03 03:10:33.467765242 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: am_sem_open 0x7fc43646b000 1
Fri Mar 03 03:10:33.467773426 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: shm_ring_producer_set_size
Fri Mar 03 03:10:33.467871033 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: Started backup
Fri Mar 03 03:10:33.467934476 2023: pid 1448741: thd-0x5643d36930c0:
sendbackup: fd_to_shm_ring
Fri Mar 03 03:10:33.467941382 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Started index creator: "/bin/tar -tf - 2>/dev/null | sed -e
's/^\.//'"
Fri Mar 03 03:10:33.483602083 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: 119: strange(?): runtar: error [runtar invalid option: -]
Fri Mar 03 03:10:33.485632813 2023: pid 1448746: thd-0x5643d3686c00:
sendbackup: Index created successfully
Fri Mar 03 03:10:34.486144166 2023: pid 1448741: thd-0x5643d3686c00:
sendbackup: critical (fatal): error [no backup size line]

Bug#1014046: netkit-telnet-ssl adoption

[Bastian Germann]

For now, I have done one more QA upload with the patch from your upload.

Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation

[Steve McIntyre]

Thanks Ben!

Looking at these now...

On Fri, Mar 03, 2023 at 09:28:26PM +0100, Ben Hutchings wrote:
>Control: tag -1 upstream fixed-upstream patch
>
>On Mon, 09 Jan 2023 12:12:19 +0100 Laurent Bigonville
> wrote:
>> Package: grub-common
>> Version: 2.06-7
>> Severity: serious
>> File: /usr/sbin/grub-probe
>> 
>> Hello,
>> 
>> On a newly installed laptop, it seems that grub-probe is not able to
>> detect that files are on an encrypted FS.
>> 
>> New laptop:
>> 
>> $ sudo grub-probe -t abstraction 
>> /usr/share/images/desktop-base/desktop-grub.png
>> lvm
>> 
>> $ sudo lsblk
>> NAME  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
>> nvme0n1   259:0    0 476,9G  0 disk
>> ├─nvme0n1p1   259:1    0   512M  0 part  /boot/efi
>> ├─nvme0n1p2   259:2    0   488M  0 part  /boot
>> └─nvme0n1p3   259:3    0   476G  0 part
>>   └─nvme0n1p3_crypt   254:0    0 475,9G  0 crypt
>> ├─new_laptop--vg-root    254:1    0  27,9G  0 lvm   /
>> ├─new_laptop--vg-swap_1  254:2    0   976M  0 lvm   [SWAP]
>> ├─new_laptop--vg-home    254:3    0    40G  0 lvm   /home
>> └─new_laptop--vg-libvirt 254:4    0    60G  0 lvm   /var/lib/libvirt
>[...]
>
>I can reproduce this. What changed is that we now use LUKS2 instead of
>LUKS1. Although GRUB has some LUKS2 support, it doesn't probe LUKS2
>volumes automatically.
>
>I found the 3 upstream commits that are enough to make the "grub-probe
>..." line work and am attaching a debdiff with those.  I don't know
>whether this is enough to completely fix the problem.
>
>Ben.
>
>-- 
>Ben Hutchings
>Never put off till tomorrow what you can avoid all together.
>

>diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog
>--- grub2-2.06/debian/changelog2023-02-25 21:16:55.0 +0100
>+++ grub2-2.06/debian/changelog2023-03-03 19:21:28.0 +0100
>@@ -1,3 +1,15 @@
>+grub2 (2.06-8.2) UNRELEASED; urgency=medium
>+
>+  * Non-maintainer upload.
>+  * Fix probing of LUKS2 devices (Closes: #1028301):
>+- disk/cryptodisk: When cheatmounting, use the sector info of the cheat
>+  device
>+- osdep/devmapper/getroot: Have devmapper recognize LUKS2
>+- osdep/devmapper/getroot: Set up cheated LUKS2 cryptodisk mount from DM
>+  parameters
>+
>+ -- Ben Hutchings   Fri, 03 Mar 2023 19:21:28 +0100
>+
> grub2 (2.06-8.1) experimental; urgency=medium
> 
>   * Non-maintainer upload.
>diff -Nru 
>grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
> 
>grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
>--- 
>grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
> 1970-01-01 01:00:00.0 +0100
>+++ 
>grub2-2.06/debian/patches/disk-cryptodisk-when-cheatmounting-use-the-sector-info-of-the-cheat-device.patch
> 2023-03-03 19:21:28.0 +0100
>@@ -0,0 +1,72 @@
>+From: Fabian Vogt 
>+Date: Thu, 12 Jan 2023 17:05:07 -0600
>+Subject: disk/cryptodisk: When cheatmounting, use the sector info of the cheat
>+ device
>+Origin: 
>https://git.savannah.gnu.org/cgit/grub.git/commit/?id=efc9c363b2aab222586b420508eb46fc13242739
>+Bug-Debian: https://bugs.debian.org/1028301
>+
>+When using grub-probe with cryptodisk, the mapped block device from the host
>+is used directly instead of decrypting the source device in GRUB code.
>+In that case, the sector size and count of the host device needs to be used.
>+This is especially important when using LUKS2, which does not assign
>+total_sectors and log_sector_size when scanning, but only later when the
>+segments in the JSON area are evaluated. With an unset log_sector_size,
>+grub_device_open() complains.
>+
>+This fixes grub-probe failing with
>+"error: sector sizes of 1 bytes aren't supported yet.".
>+
>+Signed-off-by: Fabian Vogt 
>+Reviewed-by: Patrick Steinhardt 
>+Tested-by: Glenn Washburn 
>+Reviewed-by: Glenn Washburn 
>+Reviewed-by: Patrick Steinhardt 
>+Reviewed-by: Daniel Kiper 
>+---
>+ grub-core/disk/cryptodisk.c | 20 ++--
>+ 1 file changed, 18 insertions(+), 2 deletions(-)
>+
>+--- a/grub-core/disk/cryptodisk.c
> b/grub-core/disk/cryptodisk.c
>+@@ -694,16 +694,31 @@ grub_cryptodisk_open (const char *name,
>+   if (!dev)
>+ return grub_error (GRUB_ERR_UNKNOWN_DEVICE, "No such device");
>+ 
>+-  disk->log_sector_size = dev->log_sector_size;
>+-
>+ #ifdef GRUB_UTIL
>+   if (dev->cheat)
>+ {
>++  grub_uint64_t cheat_dev_size;
>++  unsigned int cheat_log_sector_size;
>++
>+   if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
>+  dev->cheat_fd = grub_util_fd_open (dev->cheat, GRUB_UTIL_FD_O_RDONLY);
>+   if (!GRUB_UTIL_FD_IS_VALID (dev->cheat_fd))
>+  return grub_error (GRUB_ERR_IO, N_("cannot open `%s': %s"),
>+ dev->cheat, grub_util_fd_strerror ());
>++
>++  /* Use the sector size and count of the cheat device. 

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

Package: python3-django-hyperkitty
Followup-For: Bug #1031928
Control: severity -1 normal

next attempt ...

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#872419: gimp: Toolbox icons missed

[Thorben T.]

Package: gimp
Version: 2.10.22-4
Followup-For: Bug #872419

i experienced the same issue, and found that this is caused by not having
librsvg2-common installed.
gimp depends on librsvg2-2, but librsvg2-2 merrily recommends librsvg2-common.
i disabled installation of recommended packages on my system.

i can't tell if this is the intended behaviour when disabling recommends.
but i guess it should be considered to have gimp depend on librsvg2-common.
it seems that gimp depends on librsvg2-2, expecing to use it to render svg
icons, but what gimp _actually_ requires is
gdk-pixbuf-2.0/*/loaders/libpixbufloader-svg.so
which is in librsvg2-common.
(gimp executes fine without librsvg2-2 - except for the icons.)

Bug#1014046: netkit-telnet-ssl adoption

[Marcos Marado]

Hi Bastian,

On Wed, Feb 22, 2023 at 11:22 AM Bastian Germann  wrote:
>
> On Tue, 3 Jan 2023 14:27:56 + Marcos Marado  
> wrote:
> > I'm not changing this into an ITA since the original orphaning message a 
> > good
> > candidate for adoption was already mentioned, and in any case I would need a
> > sponsor. Still, I wish to register here my interest, and please let me
> > know if I can
> > be of help.
>
> Alberto does not want to adopt, so please hand in an upload with substantial 
> changes if you want to adopt the pkg.

Thanks for your reply. I did some work on the package, and have
uploaded it here:
https://mentors.debian.net/package/netkit-telnet-ssl/

The source for it can be found here:
https://salsa.debian.org/marado/netkit-telnet-ssl

One of the changes I did was to 'adopt' the package by claiming to be
the maintainer,
https://salsa.debian.org/marado/netkit-telnet-ssl/-/commit/9e2ca9aadab47bfbe1ece0b55b570d5ea5673bbd

However, lintian does not seem to want the adoption message on the
changelog marking the orphan bug (this one) as closed:

> Package closes bugs in a wrong way: Bug #1014046 is a O bug

Should I just remove the bug number in that changelog entry? Or should
I do something else/instead?

Best regards,
-- 
Marcos Marado

Bug#968388: build-rdeps: with dose-extra, lists too many rdeps

[Christian Kastner]

Hi Jakub,

On 2023-01-31 16:12, Jakub Wilk wrote:
> * Christian Kastner , 2020-08-14 10:58:
> Most of them build-depend on python3-sphinx, which depends on
> python3-pygments.

that explains it. I should have checked the man page.

> In my experience, you almost always want --old.

Indeed.

Thanks,
Christian

Bug#1032223: fbb: Segmentation fault when listing subdirectories using FBBDOS

[tony mancill]

Hello,

On Sat, Mar 04, 2023 at 05:20:44PM +, Dave Hibberd wrote:
> Hi there Mike,
> 
> Thanks for this patch.
> 
> I have built it on my devbox and it compiles fine. I’ve not tested it as I 
> don’t have the means to at the moment!
> 
> I shall look at committing this properly when I’m reunited with my yubikey 
> unless someone else wants to do it first
> 
> Cheers
> H
> 
> 
> > On 2 Mar 2023, at 17:12, Mike Quin  wrote:
> > 
> > Revised 05-fix-compile-warnings patch attached.
> > 
> > —
> > Mike Quin
> > <05-fix-compile-warnings>

I'm not familiar with fbb enough to claim to do adequate testing, but
the delta in the patch looks technically correct.  The original
src/ibm.c contains the lstat() and stat() calls in those locations; the
only difference is that it stores their return value in an unused
variable.

So I think their deletion in the prior patch was inadvertent and the
patch is good.  I can commit and upload if that's helpful.

Cheers,
tony

$ interdiff -p1 debian/patches/05-fix-compile-warnings 
/tmp/05-fix-compile-warnings
diff -u b/src/ibm.c fbb-7.011/src/ibm.c
--- b/src/ibm.c
+++ fbb-7.011/src/ibm.c
@@ -204,10 +204,13 @@
else
sprintf (filename, "%s/%s", blk->ff_base, dir->d_name);
 
+lstat (filename, );
+
if (S_ISLNK (st.st_mode))
{
/* printf ("link\n"); */
blk->ff_attrib |= FA_LINK;
+stat (filename, );
if (S_ISDIR (st.st_mode))
{
blk->ff_attrib |= FA_DIREC;



signature.asc
Description: PGP signature

Bug#1011666: need help with groff 1.23.0 (1.23.0~rc3-1 package prepared)

[Alejandro Colomar]

Hi Colin,

On 3/3/23 19:12, Colin Watson wrote:
> This isn't really analogous to your situation, though.  git-dpm is more
> like a workflow tool (such as stgit) than it is like a program you use
> to generate one-off scripted patches.  I don't think it would be
> appropriate or reasonable to try to embed this sort of thing in every
> commit generated by git-dpm, which is quite a lot of the commits that
> end up in my packaging branches.

If it's recurrent, maybe doing it only once would be nice.

> 
> I'd be happy to write a debian/README.source file, which would be a
> better place for this sort of thing.  I'm not sure exactly when I'll get
> round to it, but I've added it to my to-do list.

Sure, that would also help!

Cheers,

Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[James Addison]

Package: gnome-control-center
Followup-For: Bug #1032347

Gunnar Hjalmarsson wrote:
> James Addison wrote:
> > To explain another way: although disabling the 'Compose Key' using
> > the keyboard panel takes effect in the current session, it is
> > restored to the default value ('Left Super' in this case) after the
> > user logs out and logs back in.

> I can't reproduce that behavior on my Debian testing.

Thanks for investigating; that's puzzling to me.  Non-repro is useful
additional information, though.

> And if I disable the Compose Key control:

> $ gsettings get org.gnome.desktop.input-sources xkb-options
> @as []

To check my sanity, I followed through the repro steps again.

I agree that '@as []' is written to the 'xkb-options' config entry momentarily
after disabling the Compose Key.

However, a divergence/repro does appear (repeatably) on this system:

After logging out and back in again, the entry has been rewritten:

  $ dconf read /org/gnome/desktop/input-sources/xkb-options 
  ['compose:lwin']

Bug#1031258: Removal from unstable

[Petter Reinholdtsen]

[Ross Gammon]
> Thanks for doing this. Removal from unstable is the right thing to do
> I think.

No-one objected so far, so I guess that is the way we play it.  Some
time after 2023-03-14 someone should file for removal unless a new
maintainer (and perhaps a new upstream) show up very soon.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1032359: ITP: ruby-google-apis-sqladmin-v1beta4 -- Simple REST client for Cloud SQL Admin API V1beta4

[Vinay]

package: wnpp
Severity: wishlist
Owner: Vinay Keshava

*Package Name  : ruby-google-apis-sqladmin-v1beta4
 Version   : 0.13.0
 Upstream Author   : 2021 Google LLC
*URL   :https://github.com/googleapis/google-api-ruby-client
*License   : Apache-2.0
 Programming Lang  : Ruby
*Description: Simple REST client for Cloud SQL Admin API V1beta4
 This is the simple REST client for Cloud SQL Admin API V1beta4. Simple REST
 clients are Ruby client libraries that provide access to Google services via
 their HTTP REST API endpoints. These libraries are generated and updated
 automatically based on the discovery documents published by the service, and
 they handle most concerns such as authentication, pagination, retry, timeouts,
 and logging. You can use this client to access the Cloud SQL Admin API, but
 note that some services may provide a separate modern client that is easier to
 use.

This gem is required for Gitlab.

- Vinay Keshava



OpenPGP_0xD3FDE3D93A1FCF50.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031258: Removal from unstable

[Ross Gammon]

Hi Petter,

Thanks for doing this. Removal from unstable is the right thing to do I 
think.


Regards,

Ross

Bug#1029206: [pre-approval] unblock: webkit2gtk 2.40.0-2

[Alberto Garcia]

On Sat, Mar 04, 2023 at 05:24:04PM +0100, Paul Gevers wrote:
> > All build scripts are ready and the new GTK4 packages can
> > already be enabled by simply flipping the value of a variable in
> > debian/rules. We are just waiting to know the final SONAME.
> 
> It's been a while. Any progress? It's getting late in the freeze
> already.

I just contacted upstream to ask about this, I'll give you an answer
asap.

Berto

Bug#1032358: btllib: Depends on libsdsl-dev, breaking installability when not needed

[Steve Langasek]

Package: btllib
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi Andreas,

I see that libsdsl-dev is a commented-out build-dependency of btllib, but it
is still a runtime dependency.  This makes libbtllib-dev uninstallable on
archs here libsdsl is not available, without need.

The attached patch has been uploaded to Ubuntu, fixing libbtllib
installability on riscv64 and letting it migrate into the next release.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru btllib-1.4.10+dfsg/debian/control btllib-1.4.10+dfsg/debian/control
--- btllib-1.4.10+dfsg/debian/control   2023-02-01 23:10:47.0 -0800
+++ btllib-1.4.10+dfsg/debian/control   2023-03-04 10:34:56.0 -0800
@@ -23,9 +23,9 @@
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  libcpptoml-dev,
- libsdsl-dev,
  samtools,
  wget
+Recommends: libsdsl-dev
 Description: Bioinformatics Technology Lab common code library
  Bioinformatics Technology Lab common code library in C++ with
  Python wrappers.

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[Gunnar Hjalmarsson]

James Addison wrote:

However: in the particular case of disabling the 'Compose Key' (which
has a non-empty default), the setting is not persisted.

To explain another way: although disabling the 'Compose Key' using
the keyboard panel takes effect in the current session, it is
restored to the default value ('Left Super' in this case) after the
user logs out and logs back in.


I can't reproduce that behavior on my Debian testing.


This seems to be because when the 'Compose Key' is disabled, there is
no configuration entry for it written to the user's relevant dconf
entry, which is '/org/gnome/desktop/input-sources/xkb-options'.


For me there is. If I choose Left Super as the Compose key I can confirm 
it instantly this way:


$ gsettings get org.gnome.desktop.input-sources xkb-options
['compose:lwin']

And if I disable the Compose Key control:

$ gsettings get org.gnome.desktop.input-sources xkb-options
@as []


As a workaround it is possible to use the 'dconf' command-line
interface to configure an empty mapping for the compose key:

  $ dconf write /org/gnome/desktop/input-sources/xkb-options "['compose:none']"


I don't think "compose:none" is a valid XKB option. And you really 
shouldn't need to do that.



It looks like this could be the same issue as reported in #1027003,
except for a different key within the same settings panel.


Similar indeed, but not same issue I think. Before I added a patch as a 
fix of #1027003, there was no way to disable the Alternate Characters 
Key control. But a way to disable the Compose Key control was and is 
present via code which has been committed upstream.


--
Cheers,

Gunnar Hjalmarsson

Bug#988068: Info received (Another case where the current apparmor profile causes problems)

[Gonzalo Arreche]

On Tue, 26 Apr 2022 09:58:11 +0200 Henrik Christian Grove 
 wrote:

> I just read (and understood) Mikkel's suggestion. That won't help in my
> case, I basically need read permissions to *all* files in
> `.config/redshift`.
>
> Unfortunately I don't know apparmor well enough to suggest an addition
> to the policy that will accomplish that.
>
>

This could help until it gets fixed upstream:

Edit the file /etc/apparmor.d/usr.bin.redshift and change the line

    owner @{HOME}/.config/redshift.conf r,

To

    owner @{HOME}/.config/redshift/* r,


Then restart apparmor: sudo systemctl restart apparmor

Bug#1032246: unblock: sg3-utils/1.46-3

[Sebastian Ramacher]

On 2023-03-02 21:45:04 +, Jonathan McDowell wrote:
> On Thu, Mar 02, 2023 at 03:23:01PM +0100, Paul Gevers wrote:
> > On 02-03-2023 10:30, Jonathan McDowell wrote:
> > > This is a prerequest, before uploading to unstable. The package has
> > > already passed through NEW and is available in experimental.
> > 
> > Thanks.
> > 
> > > -Package: libsgutils2-2
> > > +Package: libsgutils2-1.46-2
> > >   Section: libs
> > >   Depends: ${shlibs:Depends}, ${misc:Depends}
> > >   Architecture: any
> > > -Conflicts: libsgutils2
> > > -Replaces: libsgutils2
> > > +Conflicts: libsgutils2-2 (= 1.46-1)
> > > +Replaces: libsgutils2-2 (= 1.46-1)
> > 
> > Any specific reason why this is a Conflicts and not a Breaks, other than
> > that was what was already there?
> > 
> > Feel free to upload with either Conflicts or Breaks.
> 
> Yeah, I don't think there's any compelling reason to keep it as a
> Conflicts, so I've downgraded it to a Breaks and uploaded 1.46-3 to
> unstable.

All reverse dependencies have been binNMUed and they built successfully.

Cheers
-- 
Sebastian Ramacher

Bug#925134: grub-efi-amd64-signed: doesn't mount cryptodisk

[Ben Hutchings]

It seems like this bug is related to GRUB lacking LUKS2 support.  Back
in buster, GRUB only supported LUKS1, so this bug could only be worked-
around by using LUKS1 for /boot.

Now GRUB has some support for LUKS2 at boot time, but grub-probe
doesn't recognise LUKS2 devices properly so the necessary modules don't
get loaded automatically.

There is a separate bug report #1028301 explicitly relating to grub-
probe.  I found the upstream commits that seem to fix it and added them
to that bug report.  Perhaps they would also fix this?

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#926689: cryptsetup-initramfs: config lines in grub.cfg for cryptodisk/luks and other modules missing

[Ben Hutchings]

This appears to be the same as #1028301, for which I've attached
upstream patchs.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#1028743: python-bottle: FTBFS: AssertionError: b'OK' != "URLError(ConnectionRefusedError(111, 'Connection refused'))"

[James Addison]

Followup-For: Bug #1028743
Control: tags -1 fixed-upstream

Note for maintainers: the patch attached to this bug has been merged into the
upstream 'release-0.12' branch and is included in the 0.12.5 release.

(so hopefully it is possible to drop the patch from packaging for that version
onwards)

Thanks,
James

Bug#1032223: fbb: Segmentation fault when listing subdirectories using FBBDOS

[Dave Hibberd]

Hi there Mike,

Thanks for this patch.

I have built it on my devbox and it compiles fine. I’ve not tested it as I 
don’t have the means to at the moment!

I shall look at committing this properly when I’m reunited with my yubikey 
unless someone else wants to do it first

Cheers
H


> On 2 Mar 2023, at 17:12, Mike Quin  wrote:
> 
> Revised 05-fix-compile-warnings patch attached.
> 
> —
> Mike Quin
> <05-fix-compile-warnings>

Bug#1032338: vfu: can not enter directories which names start from empty space

[Boian Bonev]

Hi,

Thanks for reporting this.

Can you please verify that the bug is still present with 5.07-1 (or 5.07-
1~bpo11+1 from backports)?

--
With best regards,
b.


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

Bug#1032351: wireplumber.service: fails to start, reporting 'Failed to connect to session bus'

[James Addison]

Followup-For: Bug #1032351

On Sat, 4 Mar 2023 17:40:24 +0100, Michael wrote:
> Is dbus-user-session / libpam-systemd installed?

Yes, both of those packages:

  $ apt list dbus-user-session libpam-systemd
  Listing... Done
  dbus-user-session/testing,now 1.14.6-1 amd64 [installed,automatic]
  libpam-systemd/testing,now 252.5-2 amd64 [installed]

> What's the output of systemctl --user status wireplumber.service

  $ systemctl --user status wireplumber.service
  × wireplumber.service - Multimedia Service Session Manager
   Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; 
preset: enabled)
   Active: failed (Result: exit-code) since 
 Duration: ms
  Process:  ExecStart=/usr/bin/wireplumber (code=exited, status=70)
 Main PID:  (code=exited, status=70)
  CPU: ms

Bug#1032357: shorewall6: sysvinit script for Shorewall6 is broken

[Glop]

Package: shorewall6
Version: 5.2.3.4-1
Severity: important
Tags: ipv6 patch upstream
X-Debbugs-Cc: gl0pg...@riseup.net

Dear Maintainer,

I've installed and configured Shorewall6 (5.2.3.4-1) on a Debian bullseye
using sysvinit.

However, when starting the service using the provided /etc/init.d/shorewall6
script (i.e., running "/etc/init.d/shorewall6 start"), I got this error:

/etc/init.d/shorewall6: 20: test: /sbin/shorewall: unexpected operator

and Shorewall6 did not start.

This is due to a bug on line 15 of this script: the Shorewall6 executable
is defined as

SRWL='/sbin/shorewall -6'

and then its availability is tested on line 20 with

test -x $SRWL || exit 0

which will indeed fail with the error reported above.

This was fixed upstream in the following commit:
https://gitlab.com/shorewall/code/-/commit/b7f2d1b22e42a67f75de475b28ad04d9dca81bf8

Would it be possible to cherry-pick this commit into the versions packaged
in Debian, please?

Thank you very much in advance!

Glop

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (990, 'stable-security'), (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-0.deb11.6-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 shorewall6 depends on:
ii  debconf [debconf-2.0]1.5.77
ii  iproute2 5.10.0-4
ii  iptables 1.8.7-1
ii  libio-socket-inet6-perl  2.72-2.1
ii  lsb-base 11.1.0
ii  shorewall5.2.3.4-1

shorewall6 recommends no packages.

shorewall6 suggests no packages.

-- Configuration Files:
/etc/shorewall6/conntrack [Errno 13] Permission denied: 
'/etc/shorewall6/conntrack'
/etc/shorewall6/params [Errno 13] Permission denied: '/etc/shorewall6/params'

-- debconf information excluded

Bug#1030280: general: General non-recognized errors (im novice) after the installation: drivers, battery, booting errors...

[Ben Hutchings]

Control: reassign -1 installation-reports
Control: tag -1 moreinfo

On Thu, 2023-02-02 at 00:18 +0100, Miguel González Jiménez wrote:
> Package: general
> Severity: normal
> X-Debbugs-Cc: migui...@hotmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> After the installation, I proceed to use the hardware and no correct firmware 
> had been installed. Couldn't use neither the touchpad, the wifi card (AX200 
> Intel) nor several screen caracteristics.
> I've tried to install its drivers but they dont work. I think something went 
> wrong during the installation. Besides, battery is running out quite fast and 
> fans are most of the time active. After installing wifi card Intel drivers, 
> booting errors has became to show up on the log booting screen, refeering 
> bugs about usb and bluetooth ports.
> The partition on the solid disk (what also holds Windows 10) has been made 
> fine I think.
> 

Unfortunately the official installation images for Debian 11 do not
include non-free firmware that's required to support some devices.
There are alternate images with non-free firmware included at
.

For the next release, Debian 12 "bookworm", we will include and install
non-free firmware by default.  If you want to test the next release,
installation images for that are at
.

Please report back whether you still have problems after using one of
these installers.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.


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

Bug#1032356: look: can't open /usr/lib/plan9/lib/words

[Witold Baryluk]

Package: 9base
Version: 1:6-13
Followup-For: Bug #1032356
X-Debbugs-Cc: witold.bary...@gmail.com

Just a small observation about non-english dictionaries:

Using option -f, makes look ignore lower and upper case latters, and for
example mostly work with Polish dictionary:

$ /usr/lib/plan9/bin/look -f czy /usr/share/dict/polish
czy
czyby
czybym
czybyś
czybyście
czybyśmy
Czycie
czyha
czyhacie
...


Using polish diactricts hower does not work in pattern:

$ /usr/lib/plan9/bin/look -f czł /usr/share/dict/polish
$

$ grep ^czł /usr/share/dict/polish | wc -l
574
$

Bug#1032351: [Pkg-utopia-maintainers] Bug#1032351: wireplumber.service: fails to start, reporting 'Failed to connect to session bus'

[Michael Biebl]

Control: tags -1 + moreinfo

Is dbus-user-session / libpam-systemd installed?

What's the output of systemctl --user status wireplumber.service

Am 04.03.23 um 15:11 schrieb James Addison:

Package: wireplumber
Version: 0.4.13-1
Severity: normal

Dear Maintainer,

On this Debian 12 (bookworm) system, sound output in the GNOME and Wayland
desktop environment became unavailable recently.

The only output device listed in the 'Sound' panel of gnome-control-center
is 'Dummy Output'; however, multiple devices are listed in the output of
the 'aplay -l' command:

    List of PLAYBACK Hardware Devices 
   card 0: PCH [HDA Intel PCH], device 0: CX20753/4 Analog [CX20753/4 Analog]
 Subdevices: 1/1
 Subdevice #0: subdevice #0
   ...


The following entries are present in the system journal for wireplumber, as
produced by running 'journalctl --user --merge --unit wireplumber':

   wireplumber[pid]: Failed to connect to session bus: Unable to autolaunch a 
dbus-daemon without a $DISPLAY for X11
   wireplumber[pid]: Error acquiring bus address: Cannot autolaunch D-Bus 
without X11 $DISPLAY
   wireplumber[pid]: <12-digit-hex>: leaked proxy <12-digit-hex> id:
   wireplumber[pid]: disconnected from pipewire


As a workaround, running 'wireplumber' from the command-line (using the
logged-in user account) restores the expected behaviour: sound is emitted
again, and audio output devices are listed in gnome-control-center.

Thank you,
James

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

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

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.65.2
ii  libc6 2.36-8
ii  libglib2.0-0  2.74.5-1
ii  libpipewire-0.3-0 0.3.65-3
ii  libwireplumber-0.4-0  0.4.13-1
ii  pipewire  0.3.65-3

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.65-3

Versions of packages wireplumber suggests:
ii  libspa-0.2-bluetooth  0.3.65-3
pn  wireplumber-doc   

-- no debconf information

___
Pkg-utopia-maintainers mailing list
pkg-utopia-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032356: look: can't open /usr/lib/plan9/lib/words

[Witold Baryluk]

Package: 9base
Version: 1:6-13
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

As installed, look is not very usable:

$ /usr/lib/plan9/bin/look
look: can't open /usr/lib/plan9/lib/words
$

This is most likely a porting bug, as man page, says by default it uses

/usr/share/dict/words

Using explicitly this file, makes it work:

$ /usr/lib/plan9/bin/look foo /usr/share/dict/words
foo
foobar
food
...


Note: /usr/share/dict/words is usually provided by wamerican. Users are
free to divert the symlink to other word lists.

Additionally:

I am pretty sure look uses UTF-8 (obviously), and in Debian now, all word
dictionaries are now using UTF-8 too. However, not all dictionaries use
Unicode or UTF-8 sorting.

I tested it with Polish word list, and look does not work on it. Even
without using polish dictrics in a pattern or a word. I am guessing this
is because from quick tests, it looks like plan9 look looks to be doing a
binary search in file, but many locale specific dictionaries are sorted
using locale specific collation rules, not Unicode rules. For example,
for Polish wordlist:

...
Aaseny
ab
Ab
aba
ABA
abace
...


because this is what official Polish language rules say to do (as used
for centuries in encyclopedias and paper dictionaries). In dictionaries,
usually character-after-character rules are used. In encylopedias
word-after-word (so for example Jan Sobieski, is before Janina). (Polish
dictionary does not have any multi-word words, so that is moot anyway).

Whetever it is useful for spell checking purposes, is another matter.

(not util-linux's look also does not work)


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

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

Versions of packages 9base depends on:
ii  debianutils  5.7-0.4
ii  libc62.36-8

9base recommends no packages.

9base suggests no packages.

-- no debconf information

Bug#1028722: prody: FTBFS: AssertionError: 3205 != 3211

[Adrian Bunk]

On Wed, Feb 08, 2023 at 12:22:09PM +0100, Santiago Vila wrote:
> El 8/2/23 a las 9:33, Andrius Merkys escribió:
> > Hi Santiago,
> > 
> > On 2023-02-06 19:36, Santiago Vila wrote:
> > > This is fully reproducible at least on Hetzner virtual instances of type 
> > > CX21 and CX31.
> > 
> > Thanks for giving this a look. Could you please provide the versions of 
> > python3-biopython and python3-numpy on your setup? ci.debian.net uses the 
> > following:
> > 
> > python3-biopython (1.80+dfsg-4+b1)
> > python3-numpy (1:1.24.1-2+b1)
> 
> That's what I'm using as well.
> 
> > I would like to rule out the possibility that version differences are to 
> > blame here.
> 
> I think you can definitely rule out such possibility.
> 
> See the two attached build logs. They were made the same day at nearly the
> same time. One of them succeeded, and the other failed.
> 
> The one that succeeded was made in a self-hosted virtual machine.
> The one that failed was made in a Hetzner machine.
> 
> So this seems to be machine-specific, maybe different optimizations for 
> Intel/AMD,
> or failure to pass the tests when building in parallel (my self-hosted kvm 
> machine
> has only one CPU),

The build succeeds on all little endian buildds[1] and in reproducible 
builds, therefore building in parallel is not the issue.

> or any other similar thing which depends on the machine being used
> (hence my offer to ssh into a Hetzner machine for you to test if you need it).

The problem is that someone has to understand both chemistry and this 
software well enough, apparrently better than upstream so far:
https://github.com/prody/ProDy/issues/1594#issuecomment-1419174201

> Thanks.

cu
Adrian

[1] the tests never passed on big endian

Bug#1032355: systemd-boot: bootctl install/update completely broken with /boot on ZFS

[наб]

Package: systemd-boot
Version: 252.6-1
Severity: important
Tags: patch upstream
Control: forwarded -1 https://github.com/systemd/systemd/pull/26660

Dear Maintainer,

I already forwarded this upstream, but I found this in Debian and I have
a patch that works for 252.6-1, so I'm hoping this can land for
bookworm.

In short, when updating sd-boot:
dpkg: error processing package systemd-boot (--configure):
 installed systemd-boot package post-installation script subprocess
 returned error exit status 1

And indeed:
❯ sudo bootctl update --graceful
❯ echo $?
1

With no more information. This is because statx(/boot) (when that's on
ZFS) returns stx_dev_major=0, which forces a "this filesystem is btrfs"
path, which errors out and silently exits 1 when it's actually not.

-- >8 --
$ git diff
diff --git a/src/shared/find-esp.c b/src/shared/find-esp.c
index fa234c8b5f..1af643da5e 100644
--- a/src/shared/find-esp.c
+++ b/src/shared/find-esp.c
@@ -814,7 +814,7 @@ int find_xbootldr_and_warn(
 r = verify_xbootldr(p, /* searching= */ true, unprivileged_mode, 
ret_uuid, ret_devid);
 if (r >= 0)
 goto found;
-if (!IN_SET(r, -ENOENT, -EADDRNOTAVAIL, -ENOTDIR)) /* This one is not 
it */
+if (!IN_SET(r, -ENOENT, -EADDRNOTAVAIL, -ENOTDIR, -ENOTTY)) /* This 
one is not it */
 return r;
 
 return -ENOKEY;
-- >8 --

This patch, effectively, understands that -ENOTTY means "this is not an
XBOOTLDR partition" and lets the installation progress normally.

Please consider applying this.

наб

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

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

Versions of packages systemd-boot depends on:
ii  libc6  2.31-13+deb11u5
pn  libsystemd-shared  
pn  systemd-boot-efi   

Versions of packages systemd-boot recommends:
ii  efibootmgr  17-1

systemd-boot suggests no packages.


signature.asc
Description: PGP signature

Bug#1032067: linux-image-5.10.0-19-amd64: recurring btrfs errors and warning related to ibm websphere mq operating files

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Mon, Feb 27, 2023 at 11:49:49AM +0100, IT wrote:
> Package: src:linux
> Version: 5.10.149-2
> Severity: normal
> X-Debbugs-Cc: i...@bsi.sm
> 
> Dear Maintainer,
> 
> on a server with IBM WebSphere MQ, BTRFS returns these messages:
> 
> BTRFS warning (device vda2): csum failed root 256 ino 647789 off 9109504 csum 
> 0x2d57cc4b expected csum 0x58676c1e mirror 1
> BTRFS error (device vda2): bdev /dev/vda2 errs: wr 0, rd 0, flush 0, corrupt 
> 2869, gen 0
> BTRFS warning (device vda2): csum failed root 256 ino 647789 off 9109504 csum 
> 0x2d57cc4b expected csum 0x58676c1e mirror 1
> BTRFS error (device vda2): bdev /dev/vda2 errs: wr 0, rd 0, flush 0, corrupt 
> 2870, gen 0
> BTRFS warning (device vda2): csum failed root 256 ino 647789 off 9109504 csum 
> 0x2d57cc4b expected csum 0x58676c1e mirror 1
> BTRFS error (device vda2): bdev /dev/vda2 errs: wr 0, rd 0, flush 0, corrupt 
> 2871, gen 0
> BTRFS warning (device vda2): csum failed root 256 ino 647789 off 9109504 csum 
> 0x2d57cc4b expected csum 0x58676c1e mirror 1
> BTRFS error (device vda2): bdev /dev/vda2 errs: wr 0, rd 0, flush 0, corrupt 
> 2872, gen 0
> BTRFS warning (device vda2): csum failed root 256 ino 647789 off 9109504 csum 
> 0x2d57cc4b expected csum 0x58676c1e mirror 1
> BTRFS error (device vda2): bdev /dev/vda2 errs: wr 0, rd 0, flush 0, corrupt 
> 2873, gen 0
> 
> These are the last ten lines from dmesg, the rest is filled with similar
> lines. The complete dmesg refers to these inodes/files (some characters
> are redacted with ?):
> 
> $ ls -il $(..)
> 647486 -rw-rw 1 mqm mqm 16785408 23 feb 11.31 
> IBM/MQ/data/log/??0/active/S001.LOG
> 647487 -rw-rw 1 mqm mqm 16785408 27 feb 10.19 
> IBM/MQ/data/log/??0/active/S002.LOG
> 647789 -rw-rw 1 mqm mqm 16785408 27 feb 07.30 
> IBM/MQ/data/log/??1/active/S000.LOG
> 649095 -rw-rw 1 mqm mqm 16785408 25 gen 09.10 
> IBM/MQ/data/log/??0/active/S000.LOG
> 650011 -rw-rw 1 mqm mqm 16785408 27 feb 10.23 
> IBM/MQ/data/log/??P/active/S000.LOG
> 650012 -rw-rw 1 mqm mqm 16785408  8 feb 16.49 
> IBM/MQ/data/log/??P/active/S001.LOG
> 650013 -rw-rw 1 mqm mqm 16785408 20 feb 07.45 
> IBM/MQ/data/log/??P/active/S002.LOG
> 
> An example directory containing these files: 
> 
> $ ls -il IBM/MQ/data/log/??0/active/
> 647485 -rw-rw 1 mqm mqm 16785408 20 feb 07.36 S000.LOG
> 647486 -rw-rw 1 mqm mqm 16785408 23 feb 11.31 S001.LOG
> 647487 -rw-rw 1 mqm mqm 16785408 27 feb 11.17 S002.LOG
> 
> This is a relatively new install of Debian 11 running in a virtual
> machine. BTRFS is mounted with:
> 
> $ grep btrfs /etc/fstab
> UUID=? / btrfs subvol=@rootfs,lazytime 0 0
> 
> Previously the filesystem was mounted with compression enabled (with
> mount option compress=zstd:1) and WebSphere MQ crashed with messages
> like this (some values are redacted with ?):
> 
> - amqrcsia.c : 820 
> 
> 01/08/2023 10:21:45 PM - Process(7948.81351) User(mqm) Program(amqrmppa)
> Host(?) Installation(?)
> VRMF(9.3.0.0) QMgr(?)
> Time(2023-01-08T21:21:45.811Z)
> CommentInsert1(?)
> CommentInsert2(7948)
> CommentInsert3(? (?))
> 
> AMQE: Channel '?' to host '? (?)' ended
> abnormally.
> 
> EXPLANATION:
> The channel program running under process ID 7948 for channel
> '?' ended abnormally. The host name is '? (?)'; in
> some cases the host name cannot be determined and so is shown as ''.
> ACTION:
> Look at previous error messages for the channel program in the error logs to
> determine the cause of the failure. Note that this message can be excluded
> completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
> attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
> found in the System Administration Guide.
> - amqrmrsa.c : 632 
> 
> 
> With compression disabled the kernel writes the messages reported at the
> beginning but WebSphere MQ works. While worrying the program works as
> expected. I might be wrong but the affected files seems to be some sort
> of log similar in purpose to PostgreSQL WAL files (both binary).
> 
> Any hints or ideas are appreciated.

As 5.10.149-2 is not the most recent kernel in bullseye, please try in
any case as well the newest one, 5.10.162-1, this might not resolve
your problem but gives you at least the correct baseline.

Regards,
Salvatore

Bug#1022015: elasticsearch-curator: diff for NMU version 5.8.1-4.1

[Adrian Bunk]

Control: tags 1022015 + pending

Dear maintainer,

I've prepared an NMU for elasticsearch-curator (versioned as 5.8.1-4.1) 
and uploaded it to DELAYED/7. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru elasticsearch-curator-5.8.1/debian/changelog elasticsearch-curator-5.8.1/debian/changelog
--- elasticsearch-curator-5.8.1/debian/changelog	2022-10-16 19:58:04.0 +0300
+++ elasticsearch-curator-5.8.1/debian/changelog	2023-03-04 18:17:29.0 +0200
@@ -1,3 +1,11 @@
+elasticsearch-curator (5.8.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream fix for compatibility with newer pyyaml.
+(Closes: #1022015)
+
+ -- Adrian Bunk   Sat, 04 Mar 2023 18:17:29 +0200
+
 elasticsearch-curator (5.8.1-4) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru elasticsearch-curator-5.8.1/debian/patches/0001-Version-bump-to-pyyaml-5.4.1-1596.patch elasticsearch-curator-5.8.1/debian/patches/0001-Version-bump-to-pyyaml-5.4.1-1596.patch
--- elasticsearch-curator-5.8.1/debian/patches/0001-Version-bump-to-pyyaml-5.4.1-1596.patch	1970-01-01 02:00:00.0 +0200
+++ elasticsearch-curator-5.8.1/debian/patches/0001-Version-bump-to-pyyaml-5.4.1-1596.patch	2023-03-04 18:16:49.0 +0200
@@ -0,0 +1,155 @@
+From e2c3983c04bb91d0a1367e1f16ebf081e3a00658 Mon Sep 17 00:00:00 2001
+From: Tero Saarni 
+Date: Wed, 21 Apr 2021 16:40:43 +0300
+Subject: Version bump to pyyaml 5.4.1 (#1596)
+
+diff --git a/curator/utils.py b/curator/utils.py
+index 3af2c78..0309a4f 100644
+--- a/curator/utils.py
 b/curator/utils.py
+@@ -56,7 +56,7 @@ def get_yaml(path):
+ yaml.add_constructor('!single', single_constructor)
+ 
+ try:
+-return yaml.load(read_file(path))
++return yaml.load(read_file(path), Loader=yaml.FullLoader)
+ except yaml.scanner.ScannerError as err:
+ print('Unable to read/parse YAML file: {0}'.format(path))
+ print(err)
+diff --git a/test/unit/test_class_index_list.py b/test/unit/test_class_index_list.py
+index 1cf20f4..cfc4621 100644
+--- a/test/unit/test_class_index_list.py
 b/test/unit/test_class_index_list.py
+@@ -800,7 +800,7 @@ class TestIterateFiltersIndex(TestCase):
+ client.cluster.state.return_value = testvars.clu_state_four
+ client.indices.stats.return_value = testvars.stats_four
+ ilo = curator.IndexList(client)
+-config = yaml.load(testvars.pattern_ft)['actions'][1]
++config = yaml.load(testvars.pattern_ft, Loader=yaml.FullLoader)['actions'][1]
+ ilo.iterate_filters(config)
+ self.assertEqual(['a-2016.03.03'], ilo.indices)
+ def test_age_filtertype(self):
+@@ -810,7 +810,7 @@ class TestIterateFiltersIndex(TestCase):
+ client.cluster.state.return_value = testvars.clu_state_two
+ client.indices.stats.return_value = testvars.stats_two
+ ilo = curator.IndexList(client)
+-config = yaml.load(testvars.age_ft)['actions'][1]
++config = yaml.load(testvars.age_ft, Loader=yaml.FullLoader)['actions'][1]
+ ilo.iterate_filters(config)
+ self.assertEqual(['index-2016.03.03'], ilo.indices)
+ def test_space_filtertype(self):
+@@ -821,7 +821,7 @@ class TestIterateFiltersIndex(TestCase):
+ client.indices.stats.return_value = testvars.stats_four
+ client.field_stats.return_value = testvars.fieldstats_four
+ ilo = curator.IndexList(client)
+-config = yaml.load(testvars.space_ft)['actions'][1]
++config = yaml.load(testvars.space_ft, Loader=yaml.FullLoader)['actions'][1]
+ ilo.iterate_filters(config)
+ self.assertEqual(['a-2016.03.03'], ilo.indices)
+ def test_forcemerge_filtertype(self):
+@@ -832,7 +832,7 @@ class TestIterateFiltersIndex(TestCase):
+ client.indices.stats.return_value = testvars.stats_one
+ client.indices.segments.return_value = testvars.shards
+ ilo = curator.IndexList(client)
+-config = yaml.load(testvars.forcemerge_ft)['actions'][1]
++config = yaml.load(testvars.forcemerge_ft, Loader=yaml.FullLoader)['actions'][1]
+ ilo.iterate_filters(config)
+ self.assertEqual([testvars.named_index], ilo.indices)
+ def test_allocated_filtertype(self):
+@@ -842,7 +842,7 @@ class TestIterateFiltersIndex(TestCase):
+ client.cluster.state.return_value = testvars.clu_state_two
+ client.indices.stats.return_value = testvars.stats_two
+ ilo = curator.IndexList(client)
+-config = yaml.load(testvars.allocated_ft)['actions'][1]
++config = yaml.load(testvars.allocated_ft, Loader=yaml.FullLoader)['actions'][1]
+ ilo.iterate_filters(config)
+ self.assertEqual(['index-2016.03.04'], ilo.indices)
+ def test_kibana_filtertype(self):
+@@ -857,7 +857,7 @@ class TestIterateFiltersIndex(TestCase):
+ ilo.indices = [
+ '.kibana', '.kibana-5', '.kibana-6', 'dummy'
+ ]
+-config = 

Bug#1029206: [pre-approval] unblock: webkit2gtk 2.40.0-2

[Paul Gevers]

Hi Alberto,

On 24-01-2023 11:39, Alberto Garcia wrote:

On Sat, Jan 21, 2023 at 05:43:11PM +0100, Sebastian Ramacher wrote:

As soon as the new SONAME is known, an upload to experimental would
be appreciated to go through NEW. Please let us know once it's
available in experimental and the test builds have been performed.


Yes, that's the plan.

All build scripts are ready and the new GTK4 packages can already be
enabled by simply flipping the value of a variable in debian/rules. We
are just waiting to know the final SONAME.


It's been a while. Any progress? It's getting late in the freeze already.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Paul Gevers]

Hi,

On 04-03-2023 17:19, Salvatore Bonaccorso wrote:

So would agree, it make sense to update all remaining hosts and then
look into it again in case the problem arise again.


All but s390x are up-to-date and liburing testing works. I can't upgrade 
s390x because of bug #1031753 (which is worse for ci.d.n than this bug 
as far as I see).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Salvatore Bonaccorso]

Hi,

On Thu, Mar 02, 2023 at 12:47:53PM +0100, Guillem Jover wrote:
> Hi!
> 
> On Thu, 2023-03-02 at 12:12:06 +0100, Paul Gevers wrote:
> > Control: fixed -1 5.10.162-1 6.1.8-1
> 
> > On Sun, 21 Aug 2022 21:35:58 +0200 Bastian Blank  wrote:
> > > On Sun, Aug 21, 2022 at 07:42:10PM +0200, Guillem Jover wrote:
> > > > It seems like there was a regression with the latest stable update
> > > > that affects the autopkgtest for liburing. Reassigning.
> > > 
> > > Please provide enough information to make isolating the problem
> > > possible.
> > > 
> > > https://ci.debian.net/packages/libu/liburing/ is completely silent as
> > > there are not results for any of the failed runs.
> 
> > I decided to try again to see if I could collect more information. The test
> > now passes on amd64, arm64, i386 and ppc64el, all running 5.10.162-1 and on
> > riscv64 running unstable. However, on armhf, armel (amd64 kernel) and s390x
> > (all running 5.10.158-2), it seems that the observation of brian is still
> > true, some test in test-unit test segfaults, the test exits and hangs.
> > @Guillem, do you see something more in the output below (armhf log) that may
> > be of interest? And maybe spot something to run in isolation?
> 
> > Reading the changelog of 5.10.162-1 I see io_uring mentioned a couple of
> > times. Therefor I assume this bug is fixed in that version. Is it worth
> > pursuing the real issue here?
> 
> Thanks for looking into this! As this appears fixed in latest Linux
> releases, then I'd honestly not bother further, and just try to get the
> remaining hosts upgraded to the fixed versions. If this was to reappear
> then it might make sense to look into it again.

FWIW, it is correct, the 5.10.162 release upstream was basically the
one to bring the io_uring implementation inline with 5.15.y series
(with the io_uring codebase from 5.15.85).

So would agree, it make sense to update all remaining hosts and then
look into it again in case the problem arise again.

Regards,
Salvatore

Bug#1023577: RM: python-matrix-nio/0.16.0-1

[Paul Gevers]

Control: tag -1 bullseye

On 06-11-2022 23:18, Jochen Sprickerhof wrote:

please remove python-matrix-nio from stable as it has an open security
bug (CVE-2022-39254) and no longer works as reported in [1] and I tested
myself.

Please also remove it's downstream dependencies, i.e. pantalaimon and
weechat-matrix.


Adding the missing tag to put it on the radar of SRM.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032354: ITP: srcpd -- SRCP server daemon to control digital model railroads

[Hilmar Preusse]

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

* Package name: srcpd
  Version : 2.1.5
  Upstream Contact: Guido Scholz 
* URL : https://sourceforge.net/projects/srcpd/
* License : GPL2
  Programming Lang: C, Shell
  Description : SRCP server daemon to control digital model railroads

The srcpd is a server daemon that enables you to control and play with
a digital model railroad using any SRCP client. Currently it supports many
interface (both self made and commercally) and direct signal generation.

More information about SRCP and links to many really cool clients (and
other servers for different hardware) can be found at
http://srcpd.sourceforge.net/ and http://www.der-moba.de/

 - The package seems to be interesting for people running
   a model railroad, which should be controlled by a computer.
   Currently I'm not aware of similar packages in Debian.
 - I plan to maintain the package myself. I'm a Debian Maintainer
   with upload permits, hence I would not need a regular sponsor.

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#1017925: RM: node-request/2.88.1-5

[Paul Gevers]

Hi Yadd,

On 22-08-2022 22:01, Paul Gevers wrote:

On 22-08-2022 17:26, Yadd wrote:

could you remove node-request from testing ? Following #956423, it
shouldn't be part of next stable release. All its reverse dependencies
are already removed from testing (yarnpkg, node-matrix-sdk).


node-request is a build-dependency of node-yarnpkg which still is in 
testing. node-yarnpkg is a key-package, so that needs to be resolved first.


I don't expect this to happen anymore for bookworm right? You still have 
a couple of weeks though.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032353: tryton-sao: migrate Build-Dependency away from node-uglify

[Paul Gevers]

Source: tryton-sao
Severity: serious

tryton-sao build depends on node-uglify which is deprecated and will be 
removed from bookworm very shortly (#958117), please update your (build) 
dependency in favor of uglifyjs or uglifyjs.terser.


https://bugs.debian.org/958117

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032352: RFS: cldump/0.11~dfsg-6 [QA] -- Clarion database files extractor

[Hugo Torres]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : cldump
   Version  : 0.11~dfsg-6
   Upstream contact : Julien BLACHE 
 * URL  : [fill in URL of upstream's web site]
 * License  : GPL-2
 * Vcs  : [fill in URL of packaging vcs]
   Section  : misc

The source builds the following binary packages:

  cldump - Clarion database files extractor

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/cldump/cldump_0.11~dfsg-6.dsc

Changes since the last upload:

 cldump (0.11~dfsg-6) unstable; urgency=medium
 .
   * QA upload.
   * debian/control: Updated Standards-Version for 4.6.2.
   * debian/copyright: Updated.
   * debian/patches: Created 01-hardening.patch.

Regards,
--
  Hugo Torres de Lima

Bug#1006996: mate-polkit: On arm64 architecture mate-polkit tries to open an amd64 file and fails

[Thomas Uhle]

On Fri, 3 Mar 2023, Mike Gabriel wrote:


Hi Thomas,

I'll try to take a look the coming week. Sorry for the delay.

Mike



Thanks!

Bug#1032061: puppetserver setup ca results in incomplete cert chain

[Jérôme Charaoui]

Le 2023-03-04 à 03 h 09, Bastian Blank a écrit :

On Fri, Mar 03, 2023 at 04:04:55PM -0500, Jérôme Charaoui wrote:

I'm not able to reproduce this issue.


Okay, then _what_ do you see?


I'm seeing puppetserver generate its CA without errors, it's able to 
sign agent signing requests and agents are able to retrieve their 
catalogs from the server (including the server node itself) without any 
kind of PKI errors or issues.




Easy check:

| # grep BEGIN /etc/puppet/puppetserver/ca/ca_crt.pem 
/etc/puppet/puppetserver/ca/signed/*
| /etc/puppet/puppetserver/ca/ca_crt.pem:-BEGIN CERTIFICATE-
| /etc/puppet/puppetserver/ca/ca_crt.pem:-BEGIN CERTIFICATE-
| /etc/puppet/puppetserver/ca/signed/debian-sid.home.arpa.pem:-BEGIN 
CERTIFICATE-

>

The CA file must only include one certificate, the trust root.  The
entity file needs to contain two: the intermediate CA and the entity
cert.


In a Debian container with the upstream Puppetlabs agent/server 
packages, running "puppetserver ca setup" results in a similiar (and 
working) certificate setup as seen with the Debian packages.


The upstream documentation is light on details (it doesn't mention the 
intermediate cert anywhere...) but it doesn't otherwise appear to 
suggest that what we're seeing is wrong:


https://www.puppet.com/docs/puppet/7/dirs_ssldir.html



And using openssl:

| # openssl s_client -connect localhost:8140 -CAfile 
/var/lib/puppet/ssl/certs/ca.pem -cert 
/var/lib/puppet/ssl/certs/debian-sid.home.arpa.pem -key 
/var/lib/puppet/ssl/private_keys/debian-sid.home.arpa.pem
| CONNECTED(0003)
| Can't use SSL_get_servername
| depth=2 CN = Puppet Root CA: 74ab090112e6f0
| verify return:1
| depth=1 CN = Puppet CA: debian-sid.home.arpa
| verify return:1
| depth=0 CN = debian-sid.home.arpa
| verify return:1
| ---
| Certificate chain
|  0 s:CN = debian-sid.home.arpa
|i:CN = Puppet CA: debian-sid.home.arpa
|a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
|v:NotBefore: Mar  3 08:01:08 2023 GMT; NotAfter: Feb 28 08:01:12 2038 GMT
| ---

The certificate chain needs to contain two certificates, the entity one
and the intermediate CA, otherwise it's incomplete.


If the cert chain is indeed incomplete, we would see verification 
errors, no? Is this what you're encountering?


Are you facing any failures in agent/server communications because of 
this? Any logs or errors messages you could share?



Thanks.

-- Jérôme

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

[James Addison]

Followup-For: Bug #1030284

There is one part of this patch that worries me, and it is the line:

> -//See issue crbug.com/405338

I'm not able to access that bug: neither anonymously nor when logged into my
gmail account.  The comment would seem to indicate that it contains relevant
context about why the stack limit was reduced on ARM architectures.

Bug#1032351: wireplumber.service: fails to start, reporting 'Failed to connect to session bus'

[James Addison]

Package: wireplumber
Version: 0.4.13-1
Severity: normal

Dear Maintainer,

On this Debian 12 (bookworm) system, sound output in the GNOME and Wayland
desktop environment became unavailable recently.

The only output device listed in the 'Sound' panel of gnome-control-center
is 'Dummy Output'; however, multiple devices are listed in the output of
the 'aplay -l' command:

   List of PLAYBACK Hardware Devices 
  card 0: PCH [HDA Intel PCH], device 0: CX20753/4 Analog [CX20753/4 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
  ...


The following entries are present in the system journal for wireplumber, as
produced by running 'journalctl --user --merge --unit wireplumber':

  wireplumber[pid]: Failed to connect to session bus: Unable to autolaunch a 
dbus-daemon without a $DISPLAY for X11
  wireplumber[pid]: Error acquiring bus address: Cannot autolaunch D-Bus 
without X11 $DISPLAY
  wireplumber[pid]: <12-digit-hex>: leaked proxy <12-digit-hex> id:
  wireplumber[pid]: disconnected from pipewire


As a workaround, running 'wireplumber' from the command-line (using the
logged-in user account) restores the expected behaviour: sound is emitted
again, and audio output devices are listed in gnome-control-center.

Thank you,
James

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

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

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.65.2
ii  libc6 2.36-8
ii  libglib2.0-0  2.74.5-1
ii  libpipewire-0.3-0 0.3.65-3
ii  libwireplumber-0.4-0  0.4.13-1
ii  pipewire  0.3.65-3

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.65-3

Versions of packages wireplumber suggests:
ii  libspa-0.2-bluetooth  0.3.65-3
pn  wireplumber-doc   

-- no debconf information

Bug#1032350: lcl-gtk2-2.2: lazarus-src should be rebuilt with lcl-gtk2 so ide/version.inc matches

[Marcel Partap]

Package: lcl-gtk2-2.2
Version: 2.2.4+dfsg1-2+b1
Severity: normal
X-Debbugs-Cc: mpar...@gmx.net

Any divergence will show a

> Warning: wrong version in ide/version.inc: 2.2.4+dfsg1-2

marked with a red exclamation mark when starting the IDE for the first time,
which does not convey a working setup even though it's actually just a cosmetic
issue. So I propose rebuilding the arch-independent packages too when bumping
the others.


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

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

Versions of packages lcl-gtk2-2.2 depends on:
ii  fp-units-base3.2.2+dfsg-18
ii  fp-units-base-3.2.2 [fp-units-base]  3.2.2+dfsg-18
ii  fp-units-fcl 3.2.2+dfsg-18
ii  fp-units-fcl-3.2.2 [fp-units-fcl]3.2.2+dfsg-18
ii  fp-units-gtk23.2.2+dfsg-18
ii  fp-units-gtk2-3.2.2 [fp-units-gtk2]  3.2.2+dfsg-18
pn  fp-units-rtl 
ii  fp-units-rtl-3.2.2 [fpc-abi-3.2.2]   3.2.2+dfsg-18
ii  lcl-nogui-2.22.2.4+dfsg1-2+b1

lcl-gtk2-2.2 recommends no packages.

Versions of packages lcl-gtk2-2.2 suggests:
ii  gdb  12.1-4+b1

-- no debconf information

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[James Addison]

Followup-For: Bug #1032347
Control: forwarded -1 
https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/910#note_1688598

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[James Addison]

Package: gnome-control-center
Followup-For: Bug #1032347

It looks like this could be the same issue as reported in #1027003, except for
a different key within the same settings panel.

Bug#1032349: libopenmpi-dev: MPI_Win_create fails with MPI_ERR_WIN for v4.1.0 and ob1

[Pavel Stishenko]

Package: libopenmpi-dev
Version: 4.1.0-10
Severity: important
Tags: newcomer

Dear Maintainer,


I have initially reported the issue at OpenMPI GiHub here:
https://github.com/open-mpi/ompi/issues/11466
But I can't reproduce it for the recent version 4.1.5 that I built from
source.
Also I can't reproduce it for the currently reported version 4.1.0 for
Fedora
So I believe that the issue is somehow related to Debian peculiarities.

The essence of the issue:

The following code:
```
#include 

int main(int argc, char *argv[]) {
  void   *buf;
  MPI_Win window;

  MPI_Init(, );
  MPI_Alloc_mem(16, MPI_INFO_NULL, );
  MPI_Win_create(buf, 16, 1, MPI_INFO_NULL, MPI_COMM_WORLD, );
  MPI_Win_free();
  MPI_Free_mem(buf);
  MPI_Finalize();
}
```
compiled as

```
gcc testwin2.c  `pkg-config --cflags --libs ompi-c`   -o testwin.x
```

and being launched as

```
mpiexec.openmpi -n 2 --mca osc_base_verbose 100 --mca pml_base_verbose 100
 --mca btl_base_verbose 100  ./testwin.x
```

fails with error messages:
```
[localhost:43128] *** An error occurred in MPI_Win_create
[localhost:43128] *** reported by process [2029780993,1]
[localhost:43128] *** on communicator MPI_COMM_WORLD
[localhost:43128] *** MPI_ERR_WIN: invalid window
[localhost:43128] *** MPI_ERRORS_ARE_FATAL (processes in this communicator
will now abort,
[localhost:43128] ***and potentially your MPI job)
```

The same code works well on Fedora PC both with ucx and ob1 PML
implementations with the same OpenMPI version 4.1.0




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

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

Versions of packages libopenmpi-dev depends on:
ii  gfortran [gfortran-mod-15] 4:10.2.1-1
ii  gfortran-10 [gfortran-mod-15]  10.2.1-6
ii  libevent-dev   2.1.12-stable-1
ii  libhwloc-dev   2.4.1+dfsg-1
ii  libibverbs-dev 33.2-1
ii  libjs-jquery   3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-ui1.12.1+dfsg-8+deb11u1
ii  libopenmpi34.1.0-10
ii  libpmix-dev4.0.0-4.1
ii  openmpi-bin4.1.0-10
ii  openmpi-common 4.1.0-10
ii  zlib1g-dev 1:1.2.11.dfsg-2+deb11u2

Versions of packages libopenmpi-dev recommends:
ii  libcoarrays-openmpi-dev  2.9.2-3

Versions of packages libopenmpi-dev suggests:
pn  openmpi-doc  

Bug#1032348: vim-pathogen: "vim-addons install pathogen" (per README.Debian) fails (unknown addons)

[Henry House]

Package: vim-pathogen
Version: 2.4-7
Severity: minor

Dear Maintainer,

The instruction for installation in README.Debian failed for me:---

$ vim-addons install pathogen
Warning: Ignoring unknown addons: pathogen

Possibly this is because there exists nothing from this package in
/usr/share/vim/addons/. But I am new to vim-addons, so I merely speculate.

Vim-Addon's installed version:

ii  vim-addon-manager 0.5.10
 all  manager of addons for the Vim editor

Thanks.


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

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

Versions of packages vim-pathogen depends on:
ii  vim  2:9.0.1000-4
ii  vim-gtk3 [vim]   2:9.0.1000-4
ii  vim-motif [vim]  2:9.0.1000-4

Versions of packages vim-pathogen recommends:
ii  vim-scripts  20210124.2

vim-pathogen suggests no packages.

-- no debconf information

-- 
Henry House
House Agricultural Consultants
+1 530-753-3361

Bug#1032347: gnome-control-center: Keyboard settings: disabling the 'Compose Key' is not persisted in user dconf settings

[James Addison]

Package: gnome-control-center
Version: 1:43.4.1-1
Severity: normal

Dear Maintainer,

The 'Keyboard' panel in gnome-control-center allows configuration of 'Special
Character Entry' keys, and on my system this currently displays two entries:

  - Alternative Characters Key (value: Disabled)
  - Compose Key (value: Left Super)

Updating these values takes effect during the current gnome-shell session, and
when the keys are given assignments, those assignments are correctly persisted
across sessions.

However: in the particular case of disabling the 'Compose Key' (which has a
non-empty default), the setting is not persisted.

To explain another way: although disabling the 'Compose Key' using the keyboard
panel takes effect in the current session, it is restored to the default value
('Left Super' in this case) after the user logs out and logs back in.

This seems to be because when the 'Compose Key' is disabled, there is no
configuration entry for it written to the user's relevant dconf entry, which
is '/org/gnome/desktop/input-sources/xkb-options'.

As a workaround it is possible to use the 'dconf' command-line interface to
configure an empty mapping for the compose key:

  $ dconf write /org/gnome/desktop/input-sources/xkb-options "['compose:none']"

This may be an upstream issue and I plan to report it there if & when it is
confirmed.

Thanks,
James

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

Package: python3-django-hyperkitty
Version: 1.3.4-4
Severity: normal

Bug#1032346: dropbear-initramfs: long delay when no network is attached

[Michel Lespinasse]

Package: dropbear-initramfs
Version: 2020.81-3

I am using dropbear-initramfs on a laptop (running debian 11 / stable
with encrypted rootfs). The intention is that most of the time I will
be entering the cryptsetup password from the laptop keyboard, but
occasionally I might connect the laptop to a local network and unlock
it through the dropbear shell. I think this is similar to the b/964187
use case.

In that bug, you noted difficulties with killing ipconfig with
SIGTERM; the resolution (introducing DROPBEAR_SHUTDOWN_TIMEOUT) left a
race when the cryptsetup password is entered on the console while
there is no attached network cable. By default wait_for_dropbear()
will wait 60 seconds for dropbear to start, while
configure_networking() will try for up to
2+3+4+6+9+16+25+36+64+100=265 seconds to initialize the unconnected
interface. That means an undesired 60 second wait, and the race is
still present.

I was wondering why ipconfig did not respond to SIGTERM, and I can not
reproduce this issue (again, using debian 11 here, so this is with
klibc-utils version 2.0.8-6.1).

The diff below seems to avoid the wait and resolve the race as far as I can see:

--- /usr/share/initramfs-tools/scripts/init-bottom/dropbear.orig
 2021-01-14 12:14:26.0 -0800
+++ /usr/share/initramfs-tools/scripts/init-bottom/dropbear
2023-03-04 04:18:18.365776747 -0800
@@ -23,25 +23,34 @@
 IFDOWN="*"
 DROPBEAR_SHUTDOWN_TIMEOUT=60
 if [ -e /etc/dropbear/config ]; then
 . /etc/dropbear/config
 fi

 wait_for_dropbear() {
 local pid exe timer="$DROPBEAR_SHUTDOWN_TIMEOUT"
 pid="$(cat "$PIDFILE" 2>/dev/null)" || return 1

+# XXX tell configure_networking to stop
+touch /run/net-dummy.conf
+
 # when configure_networking() is run asynchronously dropbear might
 # not have started yet; ipconfig doesn't react to SIGTERM so we wait
 # for the network stack to be configured (and dropbear to start)
 # rather than terminating the shell and its children
 while [ $timer -gt 0 ] && exe="$(readlink -f "/proc/$pid/exe"
2>/dev/null)"; do
+
+# XXX kill ipconfig children
+sed -nr "s/^([0-9]+) \\(ipconfig\\) \\S $pid [0-9]+ .*/\\1/p" \
+/proc/[0-9]*/stat 2>/dev/null | \
+while read pidxxx; do kill -TERM "$pidxxx"; done
+
 if [ "$exe" = "$EXE" ]; then
 echo "$pid"
 return 0
 fi
 sleep 1
 timer=$(( timer - 1 ))
 done
 return 1
 }

Hope this helps,

-- 
Michel Lespinasse

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[James Addison]

Package: python3-django-hyperkitty
Followup-For: Bug #1031928
X-Debbugs-Cc: h...@hjp.at

> Can I change the severity of the bug?

You should be able to do that, yes: by placing BTS (bug tracking system)
control commands (as 'pseudoheaders') at the start of your email messages to
bug threads: https://www.debian.org/Bugs/Reporting#additionalpseudoheaders

> > Would you be willing to send your patch to the upstream hyperkitty 
> > project[1]
> > as well?  (likely as a merge request on their GitLab instance)

> Sure, but it seems to be fixed in upstream already, presumably because
> they use a significantly newer version of django-compressor (4.3.1
> instead of 2.4). The newer version of django-compressor reformats
>  to  even if COMPRESS_ENABLED = False.

Fair point.. hmm.  Ideally we'd want test coverage to ensure that it doesn't
happen again, though.

The upstream codebase does appear to assert on the contents[1] of the HTML
response in some cases; something similar could work as a regression test
for this bug.

[1] - 
https://gitlab.com/mailman/hyperkitty/-/blob/aae84b89184b9ae048ca693d332b7478f8734d4e/hyperkitty/tests/views/test_index.py#L214-220

Bug#1032334: webp-pixbuf-loader: Segmentation fault in xfce4-screenshooter when using copy to clipboard

[David Heidelberg]

Thanks for the report!

0.2.1 which including the fix is already on the way!

David

On 04/03/2023 09:41, Niels de Jong wrote:

Package: webp-pixbuf-loader
Version: 0.2.0-1
Severity: normal
X-Debbugs-Cc: shikonshi...@gmail.com

Dear Maintainer,

* What led up to the situation?
Since the update from 0.0.5-5 to 0.2.0-1 when using xfce4-screenshooter the
Copy to clipboard funtion stopped working.

* What exactly did you do (or not do) that was effective (or
  ineffective)?
* What was the outcome of this action?
Uninstalling webp-pixbuf-loader fixes any issues with screenshooter.

I ran screenshooter in gdb and it came with this error:
Thread 1 "xfce4-screensho" received signal SIGSEGV, Segmentation fault.
0x71ce88e0 in ?? () from /usr/lib/x86_64-linux-gnu/gdk-
pixbuf-2.0/2.10.0/loaders/libpixbufloader-webp.so


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

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

Versions of packages webp-pixbuf-loader depends on:
ii  libc62.36-8
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libwebp7 1.2.4-0.1
ii  libwebpdemux21.2.4-0.1

webp-pixbuf-loader recommends no packages.

webp-pixbuf-loader suggests no packages.

-- no debconf information


--
David Heidelberg
Consultant Software Engineer

Bug#1032345: [INTL:ro] Romanian debconf templates translation of lxc

[Remus-Gabriel Chelu]

Package: lxc
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the lxc file.

Thanks,
Remus-Gabriel

lxc_debconf_ro.po
Description: Binary data

Bug#1032057: pyproject-api: please make the build reproducible

[Faidon Liambotis]

Hi Chris!

On Mon, Feb 27, 2023 at 07:53:12AM +, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed
> that pyproject-api could not be built reproducibly.

That's unfortunate! Sorry for not realizing it before you did.

For what it's worth, this package was uploaded as a new dependency of
tox 4. It looks like tox 4.4.6-1 (uploaded to experimental last week)
suffers from the same issue as well. I will handle it there as soon as
we conclude our resolution of this one -- no need for a separate bug :)

> This is because the documentation embeds the current date in the
> build system's current timezone. A patch is attached that uses
> SOURCE_DATE_EPOCH [1] if available.
>
> ...
>
> + html_theme = "furo"
> +-html_title, html_last_updated_fmt = "pyproject-api docs", 
> datetime.now().isoformat()
> ++build_date = datetime.utcfromtimestamp(
> ++int(os.environ.get('SOURCE_DATE_EPOCH', time.time()))
> ++)
> ++html_title, html_last_updated_fmt = "pyproject-api docs", 
> build_date.isoformat()

Looking at Sphinx's documentation, it looks like html_last_updated_fmt,
as the name hints, is supposed to be the format string, not the actual
date. (A literal date works as a format because anything that's not
percent-encoded is passed on unmodified. So I think that's just a happy
accident.)

I checked the Sphinx source code, and it looks like the string is used
in prepare_writing() from builders/html/__init__.py, which in turn
passes it on as an argument to format_date() from util/i18n.py. It looks
like format_date() has support for SOURCE_DATE_EPOCH.

So from what I can tell, a much simpler patch would be to set
html_last_updated_fmt to "%Y-%m-%dT%H:%M:%S.%f" for the equivalent ISO
8601 string (or even something with less accuracy) -- no need to fiddle
with the datetime module, or SOURCE_DATE_EPOCH at all.

I know you've gone to great lengths to make Sphinx docs reproducible
across the board, so I'm leaning on your experience to let me know if
I'm missing something here before I patch it locally and pass it on to
the two upstream projects. Looking forward to your feedback.

Best,
Faidon

Bug#1032344: [INTL:ro] Romanian debconf templates translation of lsh-utils

[Remus-Gabriel Chelu]

Package: lsh-utils
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the lsh-utils file.

Thanks,
Remus-Gabriel

lsh-utils_debconf_ro.po
Description: Binary data

Bug#1022126: New mainline kernel is out fixes for example 1022126 bug

[Marc-Robin Wendt]

Its actually not my game, but if it speeds things up, I will help
testing (if anyone tells me, what to do).

On Sat, 2023-03-04 at 10:11 +0100, Salvatore Bonaccorso wrote:
> Hi Marc-Robin,
> 
> On Sat, Mar 04, 2023 at 09:36:35AM +0100, Marc-Robin Wendt wrote:
> > Ok folks. That's it now. I have a server farm with Debian+Xen and
> > I'm
> > stuck in a dead end, because this Bug gets not fixed. I delayed
> > kernel
> > updates since 5 month now, but can't delay anymore, because of CVE-
> > 2022-42328, CVE-2022-42329 and CVE-2022-3643.
> > 
> > So I have to change to Redhat now? Means my servers will be lost
> > for
> > Debian for a pretty while. It's a pity, because like this, Debian
> > Project goes down the drain. Maybe the maintainers should think
> > about
> > priorities. Bugs like this usually don't affect end consumer
> > devices,
> > but the big server farm provider, who btw. donate a pretty much of
> > ressources to the Debian Project.
> 
> People involved appear to prefer to rant on this bug instead of
> providing help and taking note of what was mentioned in
> https://bugs.debian.org/1022126#117 and earlier replies and the fact
> that the discussion was brought up to upstream by the Debian
> maintainers an happens on the upstream regression list:
> 
> https://lore.kernel.org/regressions/754b030c-ba14-167c-e2d0-2f4f5bf55...@leemhuis.info/
> 
> I take your mail such that you are willing to test accordingly
> patches
> which would be followed by the above thread? Including adding
> Tested-by on needed-to-backport patches?
> 
> Regards,
> Salvatore
> 

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

On 2023-03-02 20:30:04 +0100, Peter J. Holzer wrote:
> On 2023-03-02 19:53:12 +0100, Peter J. Holzer wrote:
> > So it seems that my suspicion that {% compress js %}...{% endcompress %}
> > wasn't working properly was correct. But of course that raises the
> > question why that would fail on one system and work on another. I'll
> > investigate that and then get back to you.
> 
> Found it (RTFM helps). I had set DEBUG = True in
> /etc/mailman3/mailman-web.py. This implicitly sets COMPRESS_ENABLED =
> False, so it was just passing the wrong HTML from the template through
> to the browser.

Can I change the severity of the bug?

Since it only happens if the admin sets DEBUG = True, it won't affect
most users. So normal or even minor seems to be more appropriate than
grave.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#1032343: curl: FTBFS on amd64, arm64: stunnel fails to connect to backend: Connection refused

[Simon McVittie]

Source: curl
Version: 7.88.1-2
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=curl=amd64=7.88.1-2=1677835010=0
https://buildd.debian.org/status/fetch.php?pkg=curl=arm64=7.88.1-2=1677835482=0

> TESTFAIL: These test cases failed: 300 301 303 304 306 309 310 325 364 400 
> 401 403 406 407 408 409 410 414 417 560 678 1112 1272 1561 1562 1630 1631 
> 1632 2034 2037 2041 3000 3001

I've given these builds back in the hope that it's only an intermittent
failure. If I'm understanding the failure correctly, the test suite is
running stunnel to provide SSL/TLS in front of a backend server, but the
test is connecting to stunnel before the backend is ready, leading to
"Connection refused" errors:

> === Start of file https_stunnel.log
>  2023.03.03 09:09:04 LOG5[ui]: stunnel 5.68 on x86_64-pc-linux-gnu platform
>  2023.03.03 09:09:04 LOG5[ui]: Compiled/running with OpenSSL 3.0.8 7 Feb 2023
>  2023.03.03 09:09:04 LOG5[ui]: Threading:PTHREAD Sockets:POLL,IPv6,SYSTEMD 
> TLS:ENGINE,OCSP,PSK,SNI Auth:LIBWRAP
>  2023.03.03 09:09:04 LOG5[ui]: Reading configuration from file 
> /<>/debian/build/tests/https_stunnel.conf
>  2023.03.03 09:09:04 LOG5[ui]: UTF-8 byte order mark not detected
>  2023.03.03 09:09:04 LOG5[ui]: FIPS mode disabled
>  2023.03.03 09:09:04 LOG5[ui]: Configuration successful
>  2023.03.03 09:09:05 LOG5[0]: Service [curltest] accepted connection from 
> :::127.0.0.1:51722
>  2023.03.03 09:09:05 LOG3[0]: s_connect: connect ::1:34321: Connection 
> refused (111)
>  2023.03.03 09:09:05 LOG3[0]: No more addresses to connect
>  2023.03.03 09:09:05 LOG5[0]: Connection reset: 0 byte(s) sent to TLS, 0 
> byte(s) sent to socket
> === End of file https_stunnel.log
> === Start of file stderr300
>% Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>   Dload  Upload   Total   SpentLeft  Speed
> 
>0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- > 0
>0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- > 0
>  curl: (56) Recv failure: Connection reset by peer
> === End of file stderr300

smcv

Bug#1032342: [INTL:ro] Romanian debconf templates translation of lprng

[Remus-Gabriel Chelu]

Package: lprng
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the lprng file.

Thanks,
Remus-Gabriel

lprng_debconf_ro.po
Description: Binary data

Bug#1031928: python3-django-hyperkitty: Javascript not loaded because of HTML error

[Peter J. Holzer]

On 2023-03-03 11:57:14 +, James Addison wrote:
> Package: python3-django-hyperkitty
> Followup-For: Bug #1031928
> X-Debbugs-Cc: h...@hjp.at
> 
> Hi Peter - one more thought from me:
> 
> Would you be willing to send your patch to the upstream hyperkitty project[1]
> as well?  (likely as a merge request on their GitLab instance)

Sure, but it seems to be fixed in upstream already, presumably because
they use a significantly newer version of django-compressor (4.3.1
instead of 2.4). The newer version of django-compressor reformats
 to  even if COMPRESS_ENABLED = False.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature

Bug#1032341: [INTL:ro] Romanian debconf templates translation of localepurge

[Remus-Gabriel Chelu]

Package: localepurge
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the localepurge file.

Thanks,
Remus-Gabriel

localepurge_debconf_ro.po
Description: Binary data

Bug#1032340: vfu: new macros for shell

[Anonymous 648]

Package: vfu
Version: 4.21-1
Severity: wishlist
X-Debbugs-Cc: gmtmpa...@gmail.com

Dear Maintainer,

Currently vfu has following macroses for opening files:
%f  -- replaced w. current filename (w/o path)
%g  -- same as %f but for each selected filename

Seems to me it would be a good idea to have additional macros
which works as %f if nothing selected (you just hit ENTER or RIGHT ARROW)
and works as %g if you have selected at least one file.

Now you need to add 2 separate lines into config file.
For cases when you want to open one file by hitting ENTER. And for cases when 
you want to
open multiple files at a time.


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

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

Versions of packages vfu depends on:
ii  bzip2 1.0.8-4
ii  libc6 2.31-13+deb11u5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libpcre3  2:8.39-13
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  unzip 6.0-26+deb11u1

vfu recommends no packages.

vfu suggests no packages.

-- no debconf information

Bug#1032339: pulseaudio: Policy is installed in /etc instead of /usr

[Gioele Barabucci]

Package: pulseaudio
Version: 16.1+dfsg1-2
Tags: patch

Dear pulseaudio maintainers,

pulseaudio installs the `pulseaudio-system.conf` policy in 
`/etc/dbus-1`. Since Debian 9 the standard directory for 
package-installed dbus policies is `/usr/share/dbus-1`.


See: https://bugs.debian.org/1006631

Lintian complains with `dbus-policy-in-etc`.

A patch to fix this issue is available at

https://salsa.debian.org/pulseaudio-team/pulseaudio/-/merge_requests/25

Regards,

--
Gioele Barabucci

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[Hideki Yamane]

On Thu, 2 Mar 2023 09:42:36 +
Simon McVittie  wrote:
> Is there consensus among Japanese-speaking users of Debian that mozc is
> a better default for all Japanese speakers, including new users who are
> not familiar with GNOME or Debian?

 anthy vs mozc : mozc is better to default now

 - As a user, I prefer mozc than anthy. When I used anthy on Debian long
   ago, its hiragana-kanji conversion quality did not satisfy me, lower
   than IM on Windows. However, mozc is good - almost same quality as Google
   Japanese Input Method on Windows since its code base is same one.

 - Upsteam: anthy development is not active, almost dead since years.
   Original author says "This is unmaintained ancient stuff and not for
   general use." in his repo [1] and now I found some other staff tries to
   restart it as anthy-unicode [2]
 
   While mozc is still alive [3]. mozc did not accept patches from outside
   of Google in early days, but it seems that they relax their policies [4].

 
 1) https://github.com/yt76/anthy/blob/master/README
 2) https://github.com/fujiwarat/anthy-unicode
 3) https://github.com/google/mozc/commits/master
 4) https://github.com/google/mozc/blob/master/PULL_REQUEST_TEMPLATE.md



> Looking at #984875 and #983653, I also see a mention of mozc only being
> available on certain architectures: it's available on x86, ARM and riscv64,
> but not on mips*el, ppc64el or s390x.

 Well, it's better to be on every archs, but we can ignore them since
 nearly 100% Japanese desktop users use it on i386, amd64 and arm[hf|64].


> I'm also concerned that mozc still depends on GTK 2 (a switch to GTK
> 3 was tried and then reverted, see #967641). This is OK for bookworm,
> but will probably not be supportable in Debian 13.

 It should be reported to mozc upstream, they don't aware of it now, I guess.


> > Upstream prefers ibus-anthy for Japanese input
> 
> Please talk to upstream about this: if mozc is a better default for Debian,
> then it's probably also a better default for upstream.

 Okay, I'll do.



-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#1032337: devscripts: missing dep list in package description

[Jakub Wilk]

Package: devscripts
Version: 2.23.2

The dependency list is missing from the package description:

   $ dpkg -I devscripts_2.23.2_i386.deb | tail -n3
Description: scripts to make the life of a Debian Package maintainer easier
 Contains the following scripts, dependencies/recommendations shown in
 brackets afterwards:

--
Jakub Wilk

Bug#1032336: [INTL:ro] Romanian debconf templates translation of linux-base

[Remus-Gabriel Chelu]

Package: linux-base
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the linux-base file.

Thanks,
Remus-Gabriel

linux-base_debconf_ro.po
Description: Binary data

Bug#1022126: New mainline kernel is out fixes for example 1022126 bug

[Salvatore Bonaccorso]

Hi Marc-Robin,

On Sat, Mar 04, 2023 at 09:36:35AM +0100, Marc-Robin Wendt wrote:
> Ok folks. That's it now. I have a server farm with Debian+Xen and I'm
> stuck in a dead end, because this Bug gets not fixed. I delayed kernel
> updates since 5 month now, but can't delay anymore, because of CVE-
> 2022-42328, CVE-2022-42329 and CVE-2022-3643.
> 
> So I have to change to Redhat now? Means my servers will be lost for
> Debian for a pretty while. It's a pity, because like this, Debian
> Project goes down the drain. Maybe the maintainers should think about
> priorities. Bugs like this usually don't affect end consumer devices,
> but the big server farm provider, who btw. donate a pretty much of
> ressources to the Debian Project.

People involved appear to prefer to rant on this bug instead of
providing help and taking note of what was mentioned in
https://bugs.debian.org/1022126#117 and earlier replies and the fact
that the discussion was brought up to upstream by the Debian
maintainers an happens on the upstream regression list:

https://lore.kernel.org/regressions/754b030c-ba14-167c-e2d0-2f4f5bf55...@leemhuis.info/

I take your mail such that you are willing to test accordingly patches
which would be followed by the above thread? Including adding
Tested-by on needed-to-backport patches?

Regards,
Salvatore

Bug#1032335: [INTL:ro] Romanian debconf templates translation of libvirt

[Remus-Gabriel Chelu]

Package: libvirt
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the nume_pachet file.

Thanks,
Remus-Gabriel

libvirt_debconf_ro.po
Description: Binary data

Bug#1022126: New mainline kernel is out fixes for example 1022126 bug

[Marc-Robin Wendt]

Ok folks. That's it now. I have a server farm with Debian+Xen and I'm
stuck in a dead end, because this Bug gets not fixed. I delayed kernel
updates since 5 month now, but can't delay anymore, because of CVE-
2022-42328, CVE-2022-42329 and CVE-2022-3643.

So I have to change to Redhat now? Means my servers will be lost for
Debian for a pretty while. It's a pity, because like this, Debian
Project goes down the drain. Maybe the maintainers should think about
priorities. Bugs like this usually don't affect end consumer devices,
but the big server farm provider, who btw. donate a pretty much of
ressources to the Debian Project.

Greetings
Marc-Robin Wendt


On Mon, 2023-02-20 at 10:30 +0100, vmxevils...@gmail.com wrote:
> Hello dear mantainers,
> 
> I have stopped sending kernel packages as per your request (you
> defined it spamming).
> For who might be interested I am making the 6.2.0 kernel amd64
> packages myself (the 6.2.0 kernel announcement is not yet
> on https://tracker.debian.org/pkg/linux).
> Since this version fixes bug 1022126  (and, I am sure others),
> Since all the CVE announcements on the site I read are about past
> kernels..
> If you would like I can send the packages to debian mentor or
> wherever is most convenient for you, for testing and review.
> Sorry for my past mistakes (still have to fully comprehend where was
> I failing, since I was following the manuals, including the source
> etc, I'd like you to be more clear for what concerns where just
> following your procedures was failing).
> 
> 
> Thanks
> Renato Gallo

Bug#1032334: webp-pixbuf-loader: Segmentation fault in xfce4-screenshooter when using copy to clipboard

[Niels de Jong]

Package: webp-pixbuf-loader
Version: 0.2.0-1
Severity: normal
X-Debbugs-Cc: shikonshi...@gmail.com

Dear Maintainer,

   * What led up to the situation?
Since the update from 0.0.5-5 to 0.2.0-1 when using xfce4-screenshooter the
Copy to clipboard funtion stopped working.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
Uninstalling webp-pixbuf-loader fixes any issues with screenshooter.

I ran screenshooter in gdb and it came with this error:
Thread 1 "xfce4-screensho" received signal SIGSEGV, Segmentation fault.
0x71ce88e0 in ?? () from /usr/lib/x86_64-linux-gnu/gdk-
pixbuf-2.0/2.10.0/loaders/libpixbufloader-webp.so


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

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

Versions of packages webp-pixbuf-loader depends on:
ii  libc62.36-8
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libwebp7 1.2.4-0.1
ii  libwebpdemux21.2.4-0.1

webp-pixbuf-loader recommends no packages.

webp-pixbuf-loader suggests no packages.

-- no debconf information

Bug#1031784: hplip: hp-plugin : lacks dependency impossible to install plugin : scanning is not possible

[Claudio Saavedra]

I checked further and I think the problem might actually be in this
patch: 

https://salsa.debian.org/printing-team/hplip.v2/-/commit/18478a1d60f3d304cc36ceed4a471a222ae59011


The method get_distro_std_name() is removed in this patch but in the
update to 3.22.10 the method is used. You should check that patch again
before applying it.

Claudio

Bug#1032333: [INTL:ro] Romanian debconf templates translation of libpaper

[Remus-Gabriel Chelu]

Package: libpaper
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the libpaper file.

Thanks,
Remus-Gabriel

libpaper_debconf_ro.po
Description: Binary data

Bug#1032326: [Pkg-utopia-maintainers] Bug#1032326: network-manager: need more systemd security features

[Michael Biebl]

See also:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/751

"Each sandboxing option will need an individual merge requests and be 
reviewed and discussed one at a time. Patches welcome!"



Am 04.03.23 um 09:16 schrieb Michael Biebl:

Control: tags -1 + upstream

Hi Russel,

it's definitely too late to do that for bookworm, so it will have to 
wait for trixie.


This also would benefit from upstream feedback and is ideally applied 
directly to the upstream provided NetworkManager.service.


Could you thus raise this at 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/ please?


Michael


Am 04.03.23 um 03:55 schrieb Russell Coker:

Package: network-manager
Version: 1.42.0-1
Severity: normal
Tags: patch

Here is a set of additions to the systemd security policy for this.  I 
have
tested them with wifi networking and they work.  They need more 
testing before
including in Debian.  We may be able to get a few of them at a 
suitable level

of testing for the freeze but probably not most of them.

[Service]
# no new privs is an obvious one, no setuid programs etc run
NoNewPrivileges=true
# protecting kernel logs should be safe
ProtectKernelLogs=true
# this program does no CG or namespace management
ProtectControlGroups=true
RestrictNamespaces=true
# protecting modules is probably safe
ProtectKernelModules=true
# changing system call arch and personality not needed
SystemCallArchitectures=native
LockPersonality=true
# should be safe probably has no real impact
UMask=077
# tested and seems to work, should be obvious if it breaks thingfs
PrivateTmp=true
# this would obviously break if it was needed, well written programs 
wont need it

MemoryDenyWriteExecute=true
# no need for realtime stuff
RestrictRealtime=true
# no need to create SETUID/SETGID programs
RestrictSUIDSGID=true

# not sure it needs rfkill, definitely doesnt need most devices
DeviceAllow=/dev/rfkill
DevicePolicy=closed

# dhcp hostname and ntp should be a different process, right?
ProtectHostname=true
ProtectClock=true

# only needs the @resources group
SystemCallFilter=~@mount @cpu-emulation @debug @raw-io @reboot @swap 
@obsolete @privileged


# SE Linux does not allow CAP_SYS_CHROOT
CapabilityBoundingSet=~CAP_SYS_CHROOT








OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032326: [Pkg-utopia-maintainers] Bug#1032326: network-manager: need more systemd security features

[Michael Biebl]

Control: tags -1 + upstream

Hi Russel,

it's definitely too late to do that for bookworm, so it will have to 
wait for trixie.


This also would benefit from upstream feedback and is ideally applied 
directly to the upstream provided NetworkManager.service.


Could you thus raise this at 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/ please?


Michael


Am 04.03.23 um 03:55 schrieb Russell Coker:

Package: network-manager
Version: 1.42.0-1
Severity: normal
Tags: patch

Here is a set of additions to the systemd security policy for this.  I have
tested them with wifi networking and they work.  They need more testing before
including in Debian.  We may be able to get a few of them at a suitable level
of testing for the freeze but probably not most of them.

[Service]
# no new privs is an obvious one, no setuid programs etc run
NoNewPrivileges=true
# protecting kernel logs should be safe
ProtectKernelLogs=true
# this program does no CG or namespace management
ProtectControlGroups=true
RestrictNamespaces=true
# protecting modules is probably safe
ProtectKernelModules=true
# changing system call arch and personality not needed
SystemCallArchitectures=native
LockPersonality=true
# should be safe probably has no real impact
UMask=077
# tested and seems to work, should be obvious if it breaks thingfs
PrivateTmp=true
# this would obviously break if it was needed, well written programs wont need 
it
MemoryDenyWriteExecute=true
# no need for realtime stuff
RestrictRealtime=true
# no need to create SETUID/SETGID programs
RestrictSUIDSGID=true

# not sure it needs rfkill, definitely doesnt need most devices
DeviceAllow=/dev/rfkill
DevicePolicy=closed

# dhcp hostname and ntp should be a different process, right?
ProtectHostname=true
ProtectClock=true

# only needs the @resources group
SystemCallFilter=~@mount @cpu-emulation @debug @raw-io @reboot @swap @obsolete 
@privileged

# SE Linux does not allow CAP_SYS_CHROOT
CapabilityBoundingSet=~CAP_SYS_CHROOT






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032061: puppetserver setup ca results in incomplete cert chain

[Bastian Blank]

On Fri, Mar 03, 2023 at 04:04:55PM -0500, Jérôme Charaoui wrote:
> I'm not able to reproduce this issue.

Okay, then _what_ do you see?

Easy check:

| # grep BEGIN /etc/puppet/puppetserver/ca/ca_crt.pem 
/etc/puppet/puppetserver/ca/signed/*
| /etc/puppet/puppetserver/ca/ca_crt.pem:-BEGIN CERTIFICATE-
| /etc/puppet/puppetserver/ca/ca_crt.pem:-BEGIN CERTIFICATE-
| /etc/puppet/puppetserver/ca/signed/debian-sid.home.arpa.pem:-BEGIN 
CERTIFICATE-

The CA file must only include one certificate, the trust root.  The
entity file needs to contain two: the intermediate CA and the entity
cert.

And using openssl:

| # openssl s_client -connect localhost:8140 -CAfile 
/var/lib/puppet/ssl/certs/ca.pem -cert 
/var/lib/puppet/ssl/certs/debian-sid.home.arpa.pem -key 
/var/lib/puppet/ssl/private_keys/debian-sid.home.arpa.pem
| CONNECTED(0003)
| Can't use SSL_get_servername
| depth=2 CN = Puppet Root CA: 74ab090112e6f0
| verify return:1
| depth=1 CN = Puppet CA: debian-sid.home.arpa
| verify return:1
| depth=0 CN = debian-sid.home.arpa
| verify return:1
| ---
| Certificate chain
|  0 s:CN = debian-sid.home.arpa
|i:CN = Puppet CA: debian-sid.home.arpa
|a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
|v:NotBefore: Mar  3 08:01:08 2023 GMT; NotAfter: Feb 28 08:01:12 2038 GMT
| --- 

The certificate chain needs to contain two certificates, the entity one
and the intermediate CA, otherwise it's incomplete.

> This seems likely to be related to bug #1032060 where the certificate name
> of "debian-sid." (with a trailing dot) was found to be the cause of PKI
> issues in puppetserver.

This was worked around long ago, so no.  And then the ca setup would
also be unreliable.

Bastian

-- 
All your people must learn before you can reach for the stars.
-- Kirk, "The Gamesters of Triskelion", stardate 3259.2

Bug#1032332: apt-xapian-index: Fails to install due to missing dependency on python3-six

[Roland Clobus]

Package: apt-xapian-index
Version: 0.53
Severity: normal

Hello maintainer of apt-xapian-index,

While working on program-specific hooks in the live-build package, I noticed an
issue in apt-xapian-index.
When a minimal Python environment is used, not all dependencies are listed:
'python3-six' is missing.

I've used the 'normal' severity, because on most systems 'python3-six' will
already be installed and the package is working properly.

With kind regards,
Roland Clobus

--- Commands to reproduce the test cases
--- Note: I work on /dev/shm and use my apt-cacher-ng proxy on 192.168.0.15

Commands:
mount /dev/shm -odev,exec,remount,size=24G
mkdir /dev/shm/test-apt-xapian-index
cd /dev/shm/test-apt-xapian-index
debootstrap testing chroot http://deb.debian.org/debian/
chroot chroot /bin/bash -c "http_proxy=http://192.168.0.15:3142
DEBIAN_FRONTEND=noninteractive apt --yes install apt-xapian-index"

Output:
Setting up apt-xapian-index (0.53) ...
grep: /proc/self/status: No such file or directory
apt-xapian-index: Building new index in background...
Processing triggers for systemd (252.5-2) ...
Processing triggers for libc-bin (2.36-8) ...
Processing triggers for ca-certificates (20211016) ...
Updating certificates in /etc/ssl/certs...
Traceback (most recent call last):
  File "/usr/sbin/update-apt-xapian-index", line 61, in 
import axi.indexer
  File "/usr/lib/python3/dist-packages/axi/indexer.py", line 39, in 
from six.moves.urllib_parse import unquote
ModuleNotFoundError: No module named 'six'
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.


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

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

Versions of packages apt-xapian-index depends on:
ii  python3 3.11.2-1
ii  python3-apt 2.5.2+b1
ii  python3-debian  0.1.49
ii  python3-xapian  1.4.22-1

apt-xapian-index recommends no packages.

Versions of packages apt-xapian-index suggests:
ii  python3-xdg  0.28-2

-- no debconf information