Bug#1032331: dictd: should use systemd security features

[Russell Coker]

Package: dictd
Version: 1.13.0+dfsg-1
Severity: normal
Tags: patch


It would be good if dictd was configure to use the systemd security features
when running on systemd systms.  The below are settings that I have tested and
found to work.

If we had dictd use all the systemd features instead of just running init.d
scripts then we could make it a little stricter, we could remove CAP_SETUID
CAP_SETGID and CAP_KILL for starters.

I know it's close to freeze, but dictd isn't a particularly complex daemon
and it won't break things badly if it has a problem.

The probability of a system being pwned via dictd is very low but it would
be good to get the "systemd-analyze security" score for Debian as low as
possible.

[Service]
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_KILL CAP_SYS_PTRACE
SystemCallFilter=~@mount @cpu-emulation @debug @raw-io @reboot @resources @swap 
@module @obsolete @clock
ProtectSystem=strict
ProtectProc=invisible
SystemCallArchitectures=native
DevicePolicy=closed
UMask=077
NoNewPrivileges=true
ProtectKernelLogs=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectSystem=true
ProtectHome=true
PrivateTmp=true
MemoryDenyWriteExecute=true
ProtectHostname=true
LockPersonality=true
RestrictRealtime=true
RestrictSUIDSGID=true
ProtectClock=true
RestrictNamespaces=true
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

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

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

Versions of packages dictd depends on:
ii  adduser3.131
ii  debconf [debconf-2.0]  1.5.82
ii  dictzip1.13.0+dfsg-1
ii  init-system-helpers1.65.2
ii  libc6  2.36-8
ii  libmaa41.4.7-1
ii  lsb-base   11.6
ii  netbase6.4
ii  sysvinit-utils [lsb-base]  3.06-2
ii  ucf3.0043+nmu1
ii  update-inetd   4.52
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages dictd recommends:
ii  dict [dict-client]  1.13.0+dfsg-1

Versions of packages dictd suggests:
ii  dict-elements [dictd-dictionary]  20001107-a-9.1
ii  dict-foldoc [dictd-dictionary]20230119-1
ii  dict-gcide [dictd-dictionary] 0.48.5+nmu2
ii  dict-jargon [dictd-dictionary]4.4.7-3.1
ii  dict-vera [dictd-dictionary]  1:1.24-1
ii  dict-wn [dictd-dictionary]1:3.0-37

-- Configuration Files:
/etc/init.d/dictd [Errno 13] Permission denied: '/etc/init.d/dictd'

-- debconf information:
  dictd/run_mode: daemon

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

[Norman Lyon]

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]
/usr/lib/x86_64-linux-gnu/amanda/libamanda-3.5.1.so
(+0x38fea)[0x7fc4364a8fea]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_logv+0x227)[0x7fc436364e67]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_log+0x8f)[0x7fc4363650ff]
/usr/lib/amanda/sendbackup(parse_backup_messages+0x471)[0x5643d183ca61]
/usr/lib/amanda/sendbackup(main+0x121e)[0x5643d1839b2e]

Bug#1029736: Odoo-14 fails to start

[Glenn L. McGrath]

thanks Seb;

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

[Christoph Anton Mitterer]

Package: prometheus-node-exporter
Version: 1.1.2+ds-2.1
Severity: important


Hey.

Since Debian seems to set a default falue to --collector.netdev.device-exlude,
--collector.netdev.device-include can never be used, as the two are mutually
exclusive and when setting the latter in /etc/default/prometheus-node-exporter
the service just fails with:
Mar 04 05:40:21 lcg-lrz-dcache0 prometheus-node-exporter[1048667]: panic: 
Couldn't create metrics handler: couldn't create collector: device-exclude & 
device-include are mutually exclusive

I guess the same is the case for other such mutually exclusive options
where you give a default.

Can this be fixed for bookwork, too?

Cheers,
Chris.

Bug#1032328: ITP: python-ctranslate2 -- Optimized inference engine for OpenNMT-py and OpenNMT-tf models

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 
X-Debbugs-Cc: debian-de...@lists.debian.org, kar...@debian.org

* Package name: python-ctranslate2
  Version : 3.7.0
  Upstream Contact: guillaume.kl...@systrangroup.com
* URL : https://github.com/OpenNMT/CTranslate2
* License : MIT
  Programming Lang: Python
  Description : Optimized inference engine for OpenNMT-py and OpenNMT-tf 
models

CTranslate2 is an optimized inference engine for OpenNMT-py and OpenNMT-tf
models supporting both CPU and GPU execution. It also aims to be a place for
experimentation around model compression and inference acceleration.

Bug#1032327: auditd: should have support for systemd security features

[Russell Coker]

Package: auditd
Version: 1:3.0.9-1
Severity: normal
Tags: patch

In my tests the following systemd security settings allow auditd to do
everything it needs to do in a default configuration.  While the freeze is
getting close this is a simple thing to test and we should be able to get
most of these settings tested well enough before the release.

[Service]
CapabilityBoundingSet=CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_CHOWN CAP_FSETID 
CAP_NET_BIND_SERVICE CAP_SYS_NICE CAP_SYS_RESOURCE
ProtectSystem=true
ProtectProc=invisible
SystemCallArchitectures=native
DevicePolicy=closed
UMask=077
NoNewPrivileges=true
ProtectControlGroups=true
ProtectKernelModules=true
ProtectSystem=true
ProtectHome=true
PrivateTmp=true
ProtectHostname=true
LockPersonality=true
RestrictRealtime=true
RestrictSUIDSGID=true
# needs @resources and @privileged syscall groups
SystemCallFilter=~@mount @cpu-emulation @debug @raw-io @reboot @swap @module 
@obsolete @clock
ProtectClock=true
RestrictNamespaces=true
ProtectKernelTunables=true
PrivateDevices=true
PrivateNetwork=true
RestrictAddressFamilies=~AF_(INET|INET6)

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

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

Versions of packages auditd depends on:
ii  gawk 1:5.2.1-2
ii  init-system-helpers  1.65.2
ii  libaudit11:3.0.9-1
ii  libauparse0  1:3.0.9-1
ii  libc62.36-8
ii  libcap-ng0   0.8.3-1+b3
ii  libgssapi-krb5-2 1.20.1-1
ii  libkrb5-31.20.1-1
ii  libwrap0 7.6.q-32
ii  mawk 1.3.4.20200120-3.1

auditd recommends no packages.

Versions of packages auditd suggests:
pn  audispd-plugins  

-- Configuration Files:
/etc/audit/audit-stop.rules [Errno 13] Permission denied: 
'/etc/audit/audit-stop.rules'
/etc/audit/auditd.conf [Errno 13] Permission denied: '/etc/audit/auditd.conf'
/etc/audit/plugins.d/af_unix.conf [Errno 13] Permission denied: 
'/etc/audit/plugins.d/af_unix.conf'
/etc/audit/plugins.d/syslog.conf [Errno 13] Permission denied: 
'/etc/audit/plugins.d/syslog.conf'
/etc/audit/rules.d/audit.rules [Errno 13] Permission denied: 
'/etc/audit/rules.d/audit.rules'
/etc/init.d/auditd [Errno 13] Permission denied: '/etc/init.d/auditd'

-- no debconf information

Bug#986740: forked-daapd : please package new upstream release

[Nicholas D Steeves]

P.S. It seems someone uploaded forked-daapd when it had no human
uploader...  That's a Debian Policy/Standards-Version violation and
another RC bug.

  https://www.debian.org/doc/debian-policy/ch-controlfields.html#uploaders

and the package was pseudo-orphaned here:

  
https://salsa.debian.org/multimedia-team/forked-daapd/-/commit/1e75e9e6fc1c1365441df6d7b4dcd49760e19abd

which means it has been four years since forked-daapd has had a human
maintainer...without one, the package must not be included in Debian 12
(bookworm).


signature.asc
Description: PGP signature

Bug#1026062: Upstream bugs

[Hank Barta]

This is on Debian Bookworm (install about a week old.) The last
seemingly normal event in `syslog` was

2023-03-03T08:02:36.250204-06:00 olive PackageKit: get-updates
transaction /328_cccbceda from uid 1000 finished with success after
526ms

More at https://pastebin.com/VJtW4skv

I found this when searching logs after I found this host solidly hung.
No response to mouse, keyboard or ping. The screen was still visible
and had not gone blank or into low power mode.

This is on an X68_64 host running mostly Bookworm. There were some
pending packages but none that appeared to relate to KDE or
Packagekit. If there is further information I can provide, let me
know.

I do not know how to reproduce this. It happened once when I was not
at the console.

-- 
Beautiful Sunny Winfield

Bug#1032326: network-manager: need more systemd security features

[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

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

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

Versions of packages network-manager depends on:
ii  adduser 3.131
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libaudit1   1:3.0.9-1
ii  libbluetooth3   5.66-1
ii  libc6   2.36-8
ii  libcurl3-gnutls 7.88.1-1
ii  libglib2.0-02.74.5-1
ii  libgnutls30 3.7.9-1
ii  libjansson4 2.14-2
ii  libmm-glib0 1.20.4-1
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.23-1+b1
ii  libnm0  1.42.0-1
ii  libpsl5 0.21.2-1
ii  libreadline88.2-1.3
ii  libselinux1 3.4-1+b5
ii  libsystemd0 252.5-2
ii  libteamdctl01.31-1
ii  libudev1252.5-2
ii  policykit-1 122-3
ii  polkitd 122-3
ii  udev252.5-2

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd   252.5-2
pn  modemmanager 
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-11

Versions of packages network-manager suggests:
ii  iptables   1.8.9-2
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-1.1

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf [Errno 13] Permission denied: 
'/etc/NetworkManager/NetworkManager.conf'
/etc/NetworkManager/dispatcher.d/01-ifupdown [Errno 13] Permission denied: 
'/etc/NetworkManager/dispatcher.d/01-ifupdown'

-- no debconf information

Bug#1032325: osmo: recurring task option for repeating event nonfunctional

[Ed lawson]

Package: osmo
Version: 0.4.4-2
Severity: normal
X-Debbugs-Cc: elaw...@grizzy.com

Dear Maintainer,

When using the Advanced option page to create a recurring task you are given
the options to select the how often a recurring task is repeat in days or
months and how many times the recurring task is to repeat.  Logically you
should be able to have a task occur monthly and then set the number of
repetitions to say 36 so the task would repeat monthly for three years.
However, it does not.  If you put in any number other than 0, the task will not
repeat. Only if you select 0 will the task repeat, and apparent it will repeat
endlessly.  Logically it should not repeat if set to 0, but it does just the
opposite.


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

Kernel: Linux 6.1.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 osmo depends on:
ii  libarchive13  3.6.2-1
ii  libc6 2.36-8
ii  libcairo2 1.16.0-7
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-1
ii  libgringotts2 1:1.2.1-16
ii  libgspell-1-2 1.12.0-1+b1
ii  libgtk-3-03.24.36-4
ii  libical3  3.0.16-1+b1
ii  libnotify40.8.1-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libwebkit2gtk-4.0-37  2.38.5-1
ii  libxml2   2.9.14+dfsg-1.1+b3
ii  xdg-utils 1.1.3-4.1

osmo recommends no packages.

osmo suggests no packages.

-- no debconf information

Bug#1032323: ITP: moulin -- A meta build system capable of building multiple images at once.

[Johannes Schauer Marin Rodrigues]

Quoting Sudip Mukherjee (2023-03-04 00:31:56)
>   Description : A meta build system capable of building multiple images 
> at once.
> 
> Main purpose of moulin is to build complex images for embedded devices. 
> Imagine that
> you are running hypervisor (like Xen or KVM) on your device and you want to 
> build
> multiple VM images with one simple command. moulin is made exactly for this 
> task.
> 
> As part of my role in Elisa (https://elisa.tech/) I had to use moulin, but 
> being
> a Debian user I did not like installing moulin from their git. So, this ITP.

Don't forget to add this tool into this long list:

https://wiki.debian.org/SystemBuildTools#Embedded_related

Bug#1031489: OpenSUSE Leap 15.4 + 340.108 + Qt 6.2.2 = ALL QT WORKING GOOD

[Alexander Procenko]

OpenSUSE Leap 15.4 + 340.108 + Qt 6.2.2 = ALL QT WORKING GOOD
https://i.imgur.com/u5WOQD0.png
So its Debian issue?

Bug#612464: Привет

[Віталій Альохін]

Отправлено с iPhone

Bug#1032320: yt-dlp: Please include built manpage into package

[debian.fab]

Hmm,

my bad, this only appears on the backported package:

% dpkg -c yt-dlp_2023.02.17-1_all.deb | grep -F yt-dlp.1
-rw-r--r-- root/root     39545 2023-02-18 00:37 
/usr/share/man/man1/yt-dlp.1.gz


% dpkg -c yt-dlp_2023.02.17-1\~bpo11+1_all.deb | grep -F yt-dlp.1
-rw-r--r-- root/root    133597 2023-02-28 06:30 
/usr/lib/python3/dist-packages/share/man/man1/yt-dlp.1


Maybe the build tools are behaving differently on Bullseye.

The patch I suggested makes the man available on the backported deb file 
built on Bullseye.


Do you think applying it would make the man available in both cases?

Thanks,
Fab

On 04/03/2023 01:00, Unit 193 - unit...@unit193.net wrote:

Howdy,

On Fri, 3 Mar 2023, Fab wrote:


Package: yt-dlp
Version: 2023.02.17-1
Severity: normal
Tags: patch
X-Debbugs-Cc: debian.fab@erine.email

Hello,

provided patch just adds the debian/yt-dlp.manpages

The file only contains "yt-dlp.1" (built in the root dir).

This allows one to use `man yt-dlp`.


Umm.  Did you try that now?  Perhaps you should.

unit193@Loki:~$ dpkg -L yt-dlp | grep man1/yt-dlp
/usr/share/man/man1/yt-dlp.1.gz
unit193@Loki:~$ man yt-dlp | wc -l
2462
unit193@Loki:~$ apt-cache policy yt-dlp
yt-dlp:
  Installed: 2023.02.17-1
  Candidate: 2023.02.17-1
  Version table:
 *** 2023.02.17-1 500
        100 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status


As you can see here, the package already ships a manpage.  Perhaps you 
installed from somewhere else?


You can also view it online: 
https://manpages.debian.org/testing/yt-dlp/yt-dlp.1.en.html



~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1032320: yt-dlp: Please include built manpage into package

[Unit 193]

Howdy,

On Fri, 3 Mar 2023, Fab wrote:


Package: yt-dlp
Version: 2023.02.17-1
Severity: normal
Tags: patch
X-Debbugs-Cc: debian.fab@erine.email

Hello,

provided patch just adds the debian/yt-dlp.manpages

The file only contains "yt-dlp.1" (built in the root dir).

This allows one to use `man yt-dlp`.


Umm.  Did you try that now?  Perhaps you should.

unit193@Loki:~$ dpkg -L yt-dlp | grep man1/yt-dlp
/usr/share/man/man1/yt-dlp.1.gz
unit193@Loki:~$ man yt-dlp | wc -l
2462
unit193@Loki:~$ apt-cache policy yt-dlp
yt-dlp:
  Installed: 2023.02.17-1
  Candidate: 2023.02.17-1
  Version table:
 *** 2023.02.17-1 500
100 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


As you can see here, the package already ships a manpage.  Perhaps you 
installed from somewhere else?


You can also view it online: 
https://manpages.debian.org/testing/yt-dlp/yt-dlp.1.en.html


~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1000209: Bug #1000209

[Couret Charles-Antoine]

Hello,

I'd a look into this bug this evening and it looks like the problem was 
related to


update-rc.d (provided by #DEBHELPER#) which is called after "invoke-rc.d 
timidity stop" which stops the service.



It means systemd was not able to find the relevant service to stop at 
this moment in time. Making this update just before does the trick.


The patch is in attachment.


Regards,

Charles-Antoine Couret
diff --git a/debian/timidity-daemon.postinst b/debian/timidity-daemon.postinst
index a3610f9..573bc09 100644
--- a/debian/timidity-daemon.postinst
+++ b/debian/timidity-daemon.postinst
@@ -55,10 +55,13 @@
 
 # make sure we really stop, because packaging system doesn't
 # understand what we're trying to do with migration to timidity-daemon
-[ -f "/etc/init.d/timidity" ] && if which invoke-rc.d >/dev/null 2>&1; then
-  invoke-rc.d timidity stop
-else
-  /etc/init.d/timidity stop
+if [ -f "/etc/init.d/timidity" ]; then
+  if [ which invoke-rc.d >/dev/null 2>&1 ] ; then
+update-rc.d timidity defaults
+invoke-rc.d timidity stop
+  else
+/etc/init.d/timidity stop
+  fi
 fi
 
 #DEBHELPER#

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Jeremy Bícha]

On Fri, Mar 3, 2023 at 4:33 PM Sam Hartman  wrote:
> Where can I find the focus mode in the GUI to confirm it is set correctly?

Open the GNOME Tweaks app.
Scroll down the left sidebar to the panel named Windows.
In the main panel, scroll down to the Window Focus section.
Click to Focus should be selected.

I haven't spent much time trying to navigate the GNOME Tweaks app with
the keyboard and screen reader. It may not be a great experience.

Thank you,
Jeremy Bícha

Bug#1032324: pybind11-dev: Missing dependency on libpython3.11-dev or python3-dev

[Martin Quinson]

Package: pybind11-dev
Version: 2.10.3-1
Severity: normal

Dear maintainers,

pybind11 is using Python.h, which is installed by libpython3.11-dev on my
machine. I thus think that pybind11-dev should really depend on that package,
or on another package that ensure that Python.h is installed, regardless of the
current version of Python. I'm not very versed in python packaging, but I think
that python3-dev is a safe guess here.

Thanks for this package, that's really helpful.
Mt


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

pybind11-dev depends on no packages.

Versions of packages pybind11-dev recommends:
ii  libeigen3-dev  3.4.0-4

Versions of packages pybind11-dev suggests:
pn  pybind11-doc  

-- no debconf information

-- 
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.



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

Bug#1032323: ITP: moulin -- A meta build system capable of building multiple images at once.

[Sudip Mukherjee]

Package: wnpp
Severity: wishlist
Owner: Sudip Mukherjee 
X-Debbugs-Cc: debian-de...@lists.debian.org, sudipm.mukher...@gmail.com

* Package name: moulin
  Version : 0.0~git20230227.1630f49
  Upstream Author : many
* URL : https://github.com/xen-troops/moulin
* License : Apache
  Programming Lang: Python
  Description : A meta build system capable of building multiple images at 
once.

Main purpose of moulin is to build complex images for embedded devices. Imagine 
that
you are running hypervisor (like Xen or KVM) on your device and you want to 
build
multiple VM images with one simple command. moulin is made exactly for this 
task.

As part of my role in Elisa (https://elisa.tech/) I had to use moulin, but being
a Debian user I did not like installing moulin from their git. So, this ITP.

I can maintain it under the umbrella of Debian Python team.


-- 
Regards
Sudip

Bug#1013594: insubstantial: FTBFS: Caused by: : java.lang.VerifyError: Expecting a stackmap frame at branch target 33

[Ben Hutchings]

The laf-widget library that's part of this package generates some Java
bytecode directly:
.
Since Java 11, additional metadata (the "stackmap frame") appears to be
required for Java bytecode, and is not generated by laf-widget.

However, this code generation is apparently only used to "augment" the
rendering of other widget classes and does not seem to be essential for
the function of the library.  In fact, it was completely removed in a
later version of laf-widget:
https://github.com/kirill-grouchnikov/laf-widget/commit/8b0871e84ca6b6c0c479a6033998eb39e0fc767d

I patched the Gradle build files to disable this code generation and
the build succeeded.  I tested triplea with the old and new binaries
built from insubstantial: start the program, install the "Tutorial"
map, and start a local game with that map.  I didn't see any
regressions.  As I expected, the GUI rendering is different but only
slightly; see the attached "old" and "new" screenshots.

scilab is already broken (#1030205) so I couldn't test it.

I will NMU with the attached changes shortly.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
diff -Nru insubstantial-7.3+dfsg3/debian/changelog insubstantial-7.3+dfsg3/debian/changelog
--- insubstantial-7.3+dfsg3/debian/changelog	2019-08-26 13:49:59.0 +0200
+++ insubstantial-7.3+dfsg3/debian/changelog	2023-03-03 23:42:05.0 +0100
@@ -1,3 +1,10 @@
+insubstantial (7.3+dfsg3-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Java 11: disable augmentation (fixes FTBFS) (Closes: #1013594)
+
+ -- Ben Hutchings   Fri, 03 Mar 2023 23:42:05 +0100
+
 insubstantial (7.3+dfsg3-5) unstable; urgency=medium
 
   [ Andrius Merkys ]
diff -Nru insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch
--- insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch	1970-01-01 01:00:00.0 +0100
+++ insubstantial-7.3+dfsg3/debian/patches/java-11-disable-augmentation.patch	2023-03-03 23:11:22.0 +0100
@@ -0,0 +1,51 @@
+From: Ben Hutchings 
+Subject: Java 11: disable augmentation
+Date: Fri, 03 Mar 2023 23:11:14 +0100
+Bug-Debian: https://bugs.debian.org/1013594
+
+Since Java 11, Java bytecode is required to include some additional
+metadata.  The bytecode generated by laf-widget for "augmentation" of
+other widget libraries does not follow this requirement, resulting in
+a build failure.
+
+A later version of laf-widget has removed this augmentation rather
+than fixing it:
+https://github.com/kirill-grouchnikov/laf-widget/commit/8b0871e84ca6b6c0c479a6033998eb39e0fc767d
+
+This augmentation does not seem to be essential, so disable it until
+it is fixed or properly removed.
+
+---
+--- a/substance-flamingo/build.gradle
 b/substance-flamingo/build.gradle
+@@ -24,6 +24,8 @@ dependencies {
+ 
+ task augmentation(dependsOn: classes) {
+   description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++  // Broken under Java 11 - see Debian bug #1013594
++  enabled = false
+ 
+   doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath + File.pathSeparator + configurations.compile.asPath
+--- a/substance-swingx/build.gradle
 b/substance-swingx/build.gradle
+@@ -25,6 +25,8 @@ dependencies {
+ 
+ task augmentation(dependsOn: classes) {
+   description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++  // Broken under Java 11 - see Debian bug #1013594
++  enabled = false
+ 
+   doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath + File.pathSeparator + configurations.compile.asPath
+--- a/substance/build.gradle
 b/substance/build.gradle
+@@ -28,6 +28,8 @@ dependencies {
+ 
+ task augmentation(dependsOn: classes) {
+   description = "Performs code augmentaiton for the laf-plugin and laf-widget libraries on the substance jar classes"
++  // Broken under Java 11 - see Debian bug #1013594
++  enabled = false
+ 
+   doLast {
+ def augmentClassPath = configurations.toolsCompile.asPath
diff -Nru insubstantial-7.3+dfsg3/debian/patches/series insubstantial-7.3+dfsg3/debian/patches/series
--- insubstantial-7.3+dfsg3/debian/patches/series	2019-08-26 13:49:59.0 +0200
+++ insubstantial-7.3+dfsg3/debian/patches/series	2023-03-03 22:31:44.0 +0100
@@ -4,3 +4,4 @@
 asm5.patch
 java9-compatibility.patch
 fix-56.patch
+java-11-disable-augmentation.patch


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

Bug#1032322: RFS: ultimatedailywallpaper/1.0-1 [ITP] -- Wallpaper changer and automatic wallpaper downloader

[Patrice Coni]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : ultimatedailywallpaper
   Version  : 3.2.0-1
   Upstream contact : Patrice Coni 
 * URL  : https://github.com/pagaco-swita/ultimatedailywallpaper
 * License  : GPL-3.0+
 * Vcs  : [fill in URL of packaging vcs]
   Section  : misc

The source builds the following binary packages:

  ultimatedailywallpaper - Wallpaper changer and automatic wallpaper downloader

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/u/ultimatedailywallpaper/
ultimatedailywallpaper_3.2.0-1.dsc

Changes for the initial release:

 ultimatedailywallpaper (3.2.0-1) experimental; urgency=medium
 .
   * Fixes for automatic plugins-directory detection
   * Language files updated

Regards,
-- 
  Patrice Coni

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Sam Hartman]

> "Simon" == Simon McVittie  writes:
Simon> If click-to-focus is suitable for your workflow, the focus
Simon> mode can be reset to the default with this command:

Simon> gsettings reset org.gnome.desktop.wm.preferences focus-mode

I tried running that and can still reproduce the issue.
Do I need to do anything to make that take effect?  Where can I find the
focus mode in the GUI to confirm it is set correctly?

Bug#1008313: lxpolkit: no authentication dialog can't use it

[Scorpion2185]

I didn't try that on LXDE.
I apologize I didn't start lxpolkit.

If I open gparted it opens the lxpolkit prompt.
And also pkexec opens it.

--- Original Message ---
On Thursday, March 2nd, 2023 at 10:37 AM, Simon McVittie  
wrote:


> Control: severity -1 normal
> Control: tags -1 + moreinfo unreproducible
> 
> On Fri, 30 Dec 2022 at 21:33:06 +0200, Andriy Grytsenko wrote:
> 
> > I use LXDE myself each day, I cannot say it's nearly useless
> > but many people use it and rarely have problems.
> 
> 
> I happen to have installed a Debian 12 virtual machine with LXDE recently
> while investigating a different bug, so I tried checking what happens in a
> default installation.
> 
> By default, task-desktop-lxde installs both lxpolkit (lxsession dependency)
> and policykit-1-gnome (gnome-system-tools dependency). With these installed,
> when I am logged in to a LXDE session, pkexec works as expected. I didn't
> test gparted.
> 
> I also tried removing policykit-1-gnome (which requires removing
> gnome-system-tools) so that lxpolkit was the only polkit agent on the
> system, and then rebooting. With only lxpolkit installed, when I am
> logged in to a LXDE session, pkexec and gparted both work as expected.
> 
> LXDE is not my preferred desktop environment and has more dependencies on
> unmaintained components than I'm really happy about, but I confirm that
> it works, is not useless, and does not need to be removed from bookworm.
> 
> On Sat, 26 Mar 2022 at 17:59:53 +0100, realroot wrote:
> 
> > If I try to use pkexec:
> > 
> >  AUTHENTICATING FOR org.freedesktop.policykit.exec ===
> > Authentication is needed to run `/usr/bin/env' as the super user
> > Authenticating as: root
> > Password:
> > polkit-agent-helper-1: error response to PolicyKit daemon:
> > GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
> >  AUTHENTICATION FAILED ===
> > Error executing command as another user: Not authorized
> 
> ...
> 
> > If I try to launch a program tha requires root like gparted:
> > 
> > /usr/sbin/gparted
> > Error executing command as another user: No authentication agent found.
> 
> 
> I suspect the situation here might be that the user reporting the bug is
> not using a complete desktop environment, but has installed individual
> packages to make their own desktop environment out of components.
> 
> This is something that can be made to work, but if you do this, it's up
> to you to make sure you're running all the necessary pieces, and that
> includes choosing and running a suitable polkit agent.
> 
> For example, if I log in to a plain Openbox session, that doesn't
> include a polkit authentication agent, and running gparted will fail;
> but if I run `lxpolkit &` and then run gparted again, this time I get
> a lxpolkit prompt. A more realistic setup would be to run both openbox
> and lxpolkit from ~/.xsession.
> 
> It is not possible to auto-start a polkit agent via D-Bus activation,
> because the system does not know which of potentially several polkit
> agents is the one you wanted to include in your desktop environment.
> 
> pkexec is meant to be able to operate without a polkit agent, but
> something is wrong in its implementation, leading to the "No session for
> cookie" error message (this is a known bug, #1031676). systemctl is an
> example of a component that can do the equivalent thing correctly. If
> someone works out what pkexec is doing wrong, patches would be welcome.
> 
> smcv

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5146

On Fri, 03 Mar 2023 at 13:41:43 -0700, Sam Hartman wrote:
> In bullseye I could hit ctrl-alt-tab to switch up to the top bar, and then 
> use shift-tab to get to the system menu and do things like turn on/off 
> networking.
> 
> On bookworm, that doesn't work.  ctrl-alt-tab does announce "top bar", but 
> when I release it, I'm dropped back into whatever application I was in.

This seems like upstream issue
, which was
apparently a regression in GNOME 42.

On the upstream issue, a bug reporter mentions that to reproduce the bug,
you need two things: the focus mode needs to be set to "sloppy focus", and
there needs to be at least one window open on the current workspace.

That suggests some workarounds: either set the focus mode to the default
click-to-focus, or use Ctrl + Alt + arrow keys to move to an empty
workspace. By default, GNOME Shell keeps one empty workspace available:
after the change from vertical to horizontal workspaces in GNOME 43, it's
the one on the right.

If click-to-focus is suitable for your workflow, the focus mode can be
reset to the default with this command:

gsettings reset org.gnome.desktop.wm.preferences focus-mode

(I don't know why this regressed, and upstream don't seem to have any
ideas either.)

smcv

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

[Jérôme Charaoui]

Hello,

I'm not able to reproduce this issue.

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.


Do you think we can close this as a duplicate of that bug?

Thanks,

-- Jérôme

Bug#1032241: puppetserver - service unit fails to realize the main process died

[Jérôme Charaoui]

Control: severity -1 minor

This is by design.

The ExecStartPost command mirrors the upstream behavior of the startup 
shell script, only with much less bash:


https://github.com/puppetlabs/ezbake/blob/main/resources/puppetlabs/lein-ezbake/template/global/ext/cli/start.erb

The purpose is to ensure that systemd is aware of the puppetserver's 
internal state of readiness, because once java is spawned it can take up 
to minutes for the service to be ready to accept connections.


Without ExecStartPost, systemd will consider the service started too 
early, and this could cause failures in the unit's dependents.


The bug you describe is an unfortunate, yet minor side-effect, because 
the service manager does eventually realize the unit is failed (after 
300 seconds, by default). If needed, this delay may be shortened by 
overriding the TimeoutStartSec unit parameter.


I'm keeping this bug opened because the right solution is to implement 
support for sd_notify() signals in puppetserver, instead of the current 
clunky text-file method.


This needs to actually be be implemented in trapperkeeper-clojure 
itself, and a new-feature ticket has already been filed upstream to 
track this:


https://tickets.puppetlabs.com/projects/TK/issues/TK-499

Once this lands in Debian we'll be able to switch to Type=notify and get 
rid of the ExecStartPost commands altogether.


-- Jérôme

Bug#1032321: ipmitool: There are no autopkgtests in ipmitool

[Michal Maloszewski]

Package: ipmitool
Version: 1.8.19-4
Severity: wishlist
Tags: patch

Dear Maintainer,

I have been doing package merging of ipmitool and I bumped into the  
delta that includes tests for ipmitool.
Autopkgtests are important to test the package and that's why I am 
writing to you to propose those tests.
I'll attach a debdiff.
Among these tests, we also have the "Add a qemu + virtualbmc dep-8 test for 
ipmitool", but there is no virtualbmc in Debian. Simply, it will not 
work. You can decide whether you want to drop them or not. At the end
Debian gains one smoke test.

Best regards,
Michal Maloszewski

Kernel: Linux 5.15.0-60-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ipmitool-1.8.19/debian/changelog ipmitool-1.8.19/debian/changelog
--- ipmitool-1.8.19/debian/changelog2022-12-30 10:07:51.0 +0100
+++ ipmitool-1.8.19/debian/changelog2023-01-16 16:28:56.0 +0100
@@ -1,3 +1,13 @@
+ipmitool (1.8.19-4ubuntu1~ppa1) lunar; urgency=medium
+
+  * Merge with Debian unstable. Remaining changes:
+- Add dep8 tests
+  + d/t/smoke: Add a smoke dep-8 test to confirm ipmitool installs
+  + d/t/qemuvbmc: Add a qemu + virtualbmc dep-8 test for ipmitool
+  + d/t/vbmc-qemu-vm-session.xml: define the qemu vm for qemuvbmc
+
+ -- Michal Maloszewski   Mon, 16 Jan 2023 
16:28:56 +0100
+
 ipmitool (1.8.19-4) unstable; urgency=medium
 
   * debian/patches/0110-unpdate_IANA_URL.patch:
@@ -23,6 +33,16 @@
 
  -- Jörg Frings-Fürst   Sun, 25 Dec 2022 14:32:31 +0100
 
diff -Nru ipmitool-1.8.19/debian/control ipmitool-1.8.19/debian/control
--- ipmitool-1.8.19/debian/control  2022-10-30 19:30:24.0 +0100
+++ ipmitool-1.8.19/debian/control  2023-01-16 16:28:56.0 +0100
@@ -1,7 +1,8 @@
 Source: ipmitool
 Section: utils
 Priority: optional
-Maintainer: Jörg Frings-Fürst 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Jörg Frings-Fürst 
 Build-Depends:
  debhelper-compat (= 13),
  init-system-helpers (>= 1.58),
diff -Nru ipmitool-1.8.19/debian/tests/control 
ipmitool-1.8.19/debian/tests/control
--- ipmitool-1.8.19/debian/tests/control1970-01-01 01:00:00.0 
+0100
+++ ipmitool-1.8.19/debian/tests/control2023-01-16 16:26:29.0 
+0100
@@ -0,0 +1,16 @@
+Tests: smoke
+Depends: ipmitool
+Restrictions: allow-stderr, superficial
+
+Tests: qemuvbmc
+Depends: ipmitool,
+ python3-libvirt,
+ virtualbmc,
+ bridge-utils,
+ libvirt-clients,
+ libvirt-daemon-system,
+ libxml2-utils,
+ linux-image-amd64 [amd64] | linux-generic [amd64],
+ qemu-kvm,
+ qemu-system,
+Restrictions: allow-stderr, isolation-container, skippable, 
skip-not-installable, needs-root
diff -Nru ipmitool-1.8.19/debian/tests/qemuvbmc 
ipmitool-1.8.19/debian/tests/qemuvbmc
--- ipmitool-1.8.19/debian/tests/qemuvbmc   1970-01-01 01:00:00.0 
+0100
+++ ipmitool-1.8.19/debian/tests/qemuvbmc   2023-01-16 16:26:29.0 
+0100
@@ -0,0 +1,55 @@
+#!/bin/sh
+
+set -e
+
+# dep8 qemu + virtualbmc test for ipmitool
+# Start by defining and creating a qemu vm, then attach vbmc to it.
+# Afterward test ipmitool commands on the vm.
+
+XML=debian/tests/vbmc-qemu-vm-session.xml
+DOMAIN=bmctest
+
+# Clean vm setup on exit
+cleanup()
+{
+if [ -z "$CLEANED_UP" ]; then
+virsh destroy ${DOMAIN} > /dev/null 2>&1 || true
+virsh undefine ${DOMAIN} > /dev/null 2>&1 || true
+CLEANED_UP=1
+fi
+}
+
+trap cleanup EXIT
+
+# Confirm the test is running on amd64
+if [ $(uname -m) != "x86_64" ]; then
+echo "Not on x86_64...skipping"
+exit 77
+fi
+
+# Confirm kernel and initrd are available for running vm
+if [ ! -f /boot/vmlinuz ] || [ ! -f /boot/initrd.img ]; then
+echo "Kernel or initrd not found...fail".
+exit 1
+fi
+
+# We don't want libvirt using xattrs
+# 
https://discuss.linuxcontainers.org/t/cant-run-libvirt-qemu-kvm-in-an-unprivileged-domain-anymore-unable-to-set-xattr/9466/3
+sed -r -i 's,^(#|[[:blank:]])*(remember_owner).*$,\2 = 0,' 
/etc/libvirt/qemu.conf
+systemctl restart libvirtd.service
+
+# Setup vm
+virt-xml-validate ${XML}
+virsh define ${XML}
+virsh start ${DOMAIN}
+
+# Attach virtualbmc to vm
+vbmc add ${DOMAIN} --port 6230 --username testuser --password pass
+vbmc start ${DOMAIN}
+
+# Test ipmitool
+ipmitool -I lanplus -U testuser -P pass -H 127.0.0.1 -p 6230 power up
+ipmitool -I lanplus -U testuser -P pass -H 127.0.0.1 -p 6230 power status
+ipmitool -I lanplus -U testuser -P pass -H 127.0.0.1 -p 6230 chassis status
+ipmitool -I lanplus -U testuser -P pass -H 127.0.0.1 -p 6230 power down
+ipmitool -I lanplus -U testuser -P pass -H 127.0.0.1 -p 6230 power status
diff -Nru ipmitool-1.8.19/debian/tests/smoke ipmitool-1.8.19/debian/tests/smoke
--- ipmitool-1.8.19/debian/tests/smoke  

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

[Ben Hutchings]

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/changelog	2023-02-25 21:16:55.0 +0100
+++ grub2-2.06/debian/changelog	2023-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. */
++  cheat_dev_size = grub_util_get_fd_size (dev->cheat_fd, dev->cheat, _log_sector_size);
++  if (cheat_dev_size == -1)
++{
++  const char *errmsg = grub_util_fd_strerror ();
++  grub_util_fd_close (dev->cheat_fd);
++  dev->cheat_fd 

Bug#1032320: yt-dlp: Please include built manpage into package

[Fab]

Package: yt-dlp
Version: 2023.02.17-1
Severity: normal
Tags: patch
X-Debbugs-Cc: debian.fab@erine.email

Hello,

provided patch just adds the debian/yt-dlp.manpages

The file only contains "yt-dlp.1" (built in the root dir).

This allows one to use `man yt-dlp`.

Thank you, 
Fab

-- System Information:
(not relevant here)

-- no debconf information
>From fb65a6efaa4be71950351ab0daeed12b0bd52563 Mon Sep 17 00:00:00 2001
From: Fab 
Date: Fri, 3 Mar 2023 21:22:16 +0100
Subject: [PATCH] Include built yt-dlp manpage into package

---
 debian/yt-dlp.manpages | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 debian/yt-dlp.manpages

diff --git a/debian/yt-dlp.manpages b/debian/yt-dlp.manpages
new file mode 100644
index 000..dd76032
--- /dev/null
+++ b/debian/yt-dlp.manpages
@@ -0,0 +1 @@
+yt-dlp.1
-- 
2.30.2

Bug#1032259: conky: High CPU usage

[Vincent Cheng]

Control: severity -1 important

On Fri, Mar 3, 2023 at 5:48 AM Antoine Le Gonidec
 wrote:
>
> I think I can confirm that the high Xorg memory usage is due to this update, 
> I am now sitting at 3.30GB after a dozen hours.
>
> To make really sure of the cause, I am going to revert to the 1.17 build of 
> Conky and let it run for a dozen hours too.
>
> In the meantime I am bumping the bug severity again to prevent this memory 
> leak to reach Bookworm, once again feel free to revert that if you think that 
> is not such a big deal (I guess not everyone have X sessions running for 
> several days).

I'm downgrading severity because I can't repro it on my end, and I
don't think it qualifies as a RC bug unless it's more widespread. I'd
be happy to cherrypick a patch for this for bookworm once upstream
fixes the issue.

Regards,
Vincent

Bug#1032319: gnome-shell: Accessibility Regression: ctrl-alt-tab doesn't stay on top bar

[Sam Hartman]

Package: gnome-shell
Version: 43.1-2
Severity: normal
Tags: a11y

I've also reproduced against 43.3-1, but it's harder to send email from that 
system.

I'm blind, running gnome on X using orca as a screen reader.
In bullseye I could hit ctrl-alt-tab to switch up to the top bar, and then use 
shift-tab to get to the system menu and do things like turn on/off networking.

On bookworm, that doesn't work.  ctrl-alt-tab does announce "top bar", but when 
I release it, I'm dropped back into whatever application I was in.
For example, I had Firefox focused, and hit ctrl-alt-tab.
I hear
" top bar"
"activities toggle button not pressed"
"Element [1] #debian-devel Mozilla firefox"
I.E. I was briefly on the top bar, but then found myself back in Firefox.

In Bullseye I would have stayed on the top bar.

I can get to the top bar, but it's involved.
I hit the windows key, to get to what is spoken as the "overview" screen.
I then hit ctrl-alt-tab until I get to the top bar, and it sticks.
That's a lot more keystrokes, and ends up being a fair bit slower.


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-1+b1
ii  gir1.2-adw-1 1.2.0-1
ii  gir1.2-atk-1.0   2.46.0-4
ii  gir1.2-atspi-2.0 2.46.0-4
ii  gir1.2-freedesktop   1.74.0-2
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1
ii  gir1.2-gdm-1.0   43.0-1
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-2
ii  gir1.2-gnomebluetooth-3.042.5-1
ii  gir1.2-gnomedesktop-3.0  43-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.20.5-1
ii  gir1.2-gtk-3.0   3.24.36-1
ii  gir1.2-gtk-4.0   4.8.2+ds-4
ii  gir1.2-gweather-4.0  4.2.0-1
ii  gir1.2-ibus-1.0  1.5.27-4
ii  gir1.2-mutter-11 43.2-4
ii  gir1.2-nm-1.01.40.8-1
ii  gir1.2-nma-1.0   1.10.4-2
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-1
ii  gir1.2-rsvg-2.0  2.54.5+dfsg-1
ii  gir1.2-soup-3.0  3.2.2-1
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.38.3-1
ii  gnome-backgrounds43-1
ii  gnome-settings-daemon43.0-3
ii  gnome-shell-common   43.1-2
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.63-4
ii  libatk-bridge2.0-0   2.46.0-4
ii  libatk1.0-0  2.46.0-4
ii  libc62.36-7
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.2-1
ii  libedataserver-1.2-273.46.2-1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1
ii  libgirepository-1.0-11.74.0-2
ii  libgjs0g 1.74.1-1
ii  libgles2 1.5.0-1
ii  libglib2.0-0 2.74.4-1
ii  libglib2.0-bin   2.74.4-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.36-1
ii  libgtk-4-1   4.8.2+ds-4
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.2-4
ii  libnm0   1.40.8-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpolkit-agent-1-0  

Bug#1027844: btrfsmaintenance: noted BTRFS_BALANCE_PERIOD default in /etc/default/btrfsmaintenance is inconsistent w/systemd timer

[andy]

hi - thank you for closing Bug#1027846, my turn to apologize for the
delay.  february was busy...

On Tue, 2023-02-07 at 18:13 -0500, Nicholas D Steeves wrote:
> 
[...]
> > regarding balance recommendations, my initial thought would be to
> > make
> > the language in the README.Debian stronger.
> 
> Would this be enough to guard naive users from potential data loss? 
> You
> know, the people who read docs as an afterthought, or the "it will be
> fine; it won't happen to me" crowd...  At the same time, I worry that
> there might be a social cost to using stronger language (it could
> demotivate developers or scare people off of trying btrfs).  What do
> you
> think?

one question would be: should the btrfsmaintenance package provide a
convenient way to use an (unnecessary?) feature that might cause data
loss?  are there cases in which it is recommended for the average (or
even somewhat adventurous) user to regularly schedule a btrfs balance?
if so, maybe spell out those cases explicitly in the README?  from this
conversation it does not sound like something that i would regard as
"maintenance" in the vein of max-mount-counts/interval-between-checks
driven fsck's in the ext{2,3,4} world or periodic btrfs scrubs.  otoh,
see below...

> I agree, the docs should be updated; however, I'll also need to be
> prepared to provide citations and reasoning.  To be honest, I'm
> trusting
> a recurring upstream statements on the question of metadata
> rebalancing.

from a user's perspective it's really hard to judge.  for instance,
https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Balancing states:
"It is _quite_ [their emphasis] useful to balance periodically any
Btrfs volume subject to updates."

> > i had read that "Some advocate not running it at all" but to me
> > that
> > implies "may be unnecessary" rather than "may be actively harmful."
> > on the basis of the latter i am certainly considering setting the
> > balance.timer back to disabled.
> 
> Btw, I'm curious to learn why you've enabled balancing!

been a long time, but i _think_ that at one point (related to a disk
failure/replacement in raid1 that may not have gone 100% smoothly?) i
ended up in an unbalanced situation where i couldn't write even though
there was apparently space available.  iirc `balance` was needed to get
me out of that corner.  and then i found Marc MERLIN's `btrfs-scrub`
script which included `btrfs balance` commands and he seemed like a
knowledgeable source.  that in combination w/the btrfs wiki led me to
believe it was a safe operation.  e.g., in addition to the above,
https://btrfs.wiki.kernel.org/index.php/Status lists it as "stable"
with only a note about performance.

> The "may be actively harmful" bit is tricky, because Btrfs gets way
> too
> complicated way too fast...  My hope to put in place safe defaults
> that
> work for most people, that don't bait users/sysadmins into taking on
> risk, and that are good enough for the general case.  Of course you
> know
> that a solid enough replication and backup strategy makes it ok to
> take
> risks for optimisation, but that's the "educated/experienced
> sysadmin"
> class of cases ;)  If rebalancing does something like keeping
> database
> performance from degrading, then it would be worth documenting this
> somewhere, along with the fact that several core devs upstream have
> written statements to the effect of this: never balance metadata,
> unless
> necessary.  Rebalancing to a new profile counts as "necessary",
> obviously, and the only other corner case I'm aware is noted two
> paragraphs below.

yes, it sounds like one viable approach may be to explicitly document
cases where balance is recommended.

> > alternatively/additionally are there default options that might
> > make
> > it safe(r)?
> 
> I believe that [metadata] balancing should probably be disabled in
> upstream btrfsmaintenance.  If I remember correctly, it's enabled by
> default because upstream targets 10year LTS releases such as SUSE's
> 11
> series, which uses linux 3.0.76, where the harm reduction of metadata
> balancing is significant enough to make the risk worthwhile on
> server-grade hardware.

based on what has come up in this thread, my feedback would be that the
debian pkg should diverge from upstream wrt balancing.

> > e.g., Marc MERLIN's
> > `btrfs-scrub`[1] (which i used previously) suggested that "a null
> > [metadata] rebalance should help corner cases."
> > 
> 
> Has that corner case existed since linux-3.18?
> 
>   https://btrfs.wiki.kernel.org/index.php/Balance_Filters
> 
> Or are you referring to cleaning up inefficient use of metadata after
> a batch deletion of thousands of snapshots or subvolumes (all at
> once)?

sorry, i don't know any details beyond the comments in the script.

> > from my pov i'd still like to see the values harmonized.  i
> > originally
> > noticed the inconsistency because what i believed was the default
> > setting was creating a seemingly unnecessary systemd 

Bug#1025350: qt6ct: Font changes are not saved in configuration file

[Peter B]

Raised upstream
https://github.com/trialuser02/qt6ct/issues/25

I've noticed that the font settings are saved if one just hits [OK],
but lost if one hits [Apply] first.

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

[Kurt Roeckx]

Hi,

Is the issue that with older glibc versions, it was silently casted
to a 32 bit value, but now that glibc supports 64 bit, it knows
it can't represent it, and gives an error?

Maybe for bookworm, we should just ignore the test error?


Kurt

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

[Emanuele Rocca]

Hi,

On Wed, Mar 01, 2023 at 02:41:05PM +0100, Jérémy Lal wrote:
> For now I'm unlucky with the porterbox, because /var/run/schroot
> disappeared yesterday.

I can confirm that the issue isn't reproducible with V8_DEFAULT_STACK_SIZE_KB
set to 984. Built and tested on a Macbook M1.

  (sid-arm64)ema@sarzana:~/debian/dygraphs-2.2.1
  $ babeljs --config-file $PWD/babel.config.json --compact false --source-maps 
inline -d tests5 auto_tests
  Successfully compiled 59 files with Babel (994ms).

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

[Mike Gabriel]

Hi Thomas,

On  Fr 03 Mär 2023 18:55:27 CET, Thomas Uhle wrote:


Dear maintainers,

Mike seems to be quite busy.  I think it would be good if this issue  
could be fixed for Debian bookworm.  So please can anyone of you  
step in?

If there is something else I could do to help, please let me know.

Thank you in advance!

Cheers,

Thomas


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

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpgQeHhmFulL.pgp
Description: Digitale PGP-Signatur

Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

[Sandro Tosi]

> This bug is about the warning, not about the fact that the bundled zoninfo
> database is missing.

not exactly

even if these APIs are deprecated upstream, i think breaking them on
purpose (by removing the bundled timezone file) is uncalled for.

Either we reintroduce the timezone file (that may not be a good idea)
or translate these deprecated APIs into the recommended one, or we do
something else entirely, it's up for debate.

simply silencing the warning message is providing 0 value to a proper solution.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'

[Kurt Roeckx]

Hi,

Are you waiting for something before uploading this fix?


Kurt

Bug#1031821: libreswan: remote crash, CVE-2023-23009

[Salvatore Bonaccorso]

Hi Daniel,

On Fri, Mar 03, 2023 at 09:31:26AM -0500, Daniel Kahn Gillmor wrote:
> On Thu 2023-03-02 17:34:10 -0500, Daniel Kahn Gillmor wrote:
> > yep, works for me, thanks.  I'll do that later this evening or tomorrow
> > morning.
> 
> This has been uploaded now, thanks for bearing with me.

DSA 5368-1 is released with your update. Thank you!

On a related note: I saw the 4.10-1 upload, but wouldn't it have been
better to make first 4.9-2 move to bookworm? Can you get in touch with
the release team so that the fix enters as well bookworm asking for an
unblock?

Regards,
Salvatore

Bug#1023284: libevent: FTBFS with glibc 2.36

[Nicolas Mora]

Hello,

The patch was submitted upstream for their feedback [1], and was finally 
agreed. So I will upload a new package very soon then.


/Nicolas

[1] https://github.com/libevent/libevent/issues/1393#issuecomment-1453924054

Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

[Arnout Vandecappelle]

 [I picked up this bug as part of a Debian bugsquashing sprint together with my 
colleagues.]

 Since there's been some back-and-forth in this thread, let me first summarize 
the status.

- The following will print an ugly warning:

In [1]: from dateutil import zoneinfo

In [2]: zoneinfo.get_zonefile_instance()
/usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26:
UserWarning: I/O error(2): No such file or directory
 warnings.warn("I/O error({0}): {1}".format(e.errno, e.strerror))
Out[2]: 


- It's just a warning, but it may confuse tools that consume stderr, or build
  scripts may fail if anything is emitted on stderr.

- The warning can also be triggered by requesting a timezone that doesn't exist:

In [1]: from dateutil import tz In [2]: tz.gettz('foo') 
/usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: UserWarning: 
I/O error(2): No such file or directory  warnings.warn("I/O error({0}): 
{1}".format(e.errno, e.strerror)) - In this case, the warning is in fact 
useless: if a timezone doesn't exist in the system database, it doesn't exist. - 
Thus, the only case where the warning is relevant is when the bundled database 
is used explicitly (by calling zoneinfo.get_zonefile_instance()).

  However, this is not really a valid use case.


 I conclude from this that all that really has to be done is to remove the
warning. Since the debian package doesn't have the bundled zoneinfo database,
it is not useful to issue a warning when there is no bundled zoneinfo database.
This bug is about the warning, not about the fact that the bundled zoninfo
database is missing.

 Therefore, the attached patch removes the warning. This is done as part of
Remove_Zoneinfo_Tarball.patch because removing the database should really go 
hand in hand with removing the warning. [Note that this is my first time 
contribution to Debian packaging. I'm actually using Fedora myself :-). The 
patch was tested by building it with pbuilder and running it in a bookworm 
container. Please let me know if there is anything else I should do, or if there 
is anything I should have done differently.] Regards, Arnout
diff -Nru python-dateutil-2.8.2/debian/changelog python-dateutil-2.8.2/debian/changelog
--- python-dateutil-2.8.2/debian/changelog	2022-10-14 13:10:49.0 +0200
+++ python-dateutil-2.8.2/debian/changelog	2023-03-03 18:58:30.0 +0100
@@ -1,3 +1,10 @@
+python-dateutil (2.8.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove warning about missing bundled zoneinfo database (closes: #1003044) 
+
+ -- Arnout Vandecappelle   Fri, 03 Mar 2023 18:58:30 +0100
+
 python-dateutil (2.8.2-1) unstable; urgency=medium
 
   * Team upload
diff -Nru python-dateutil-2.8.2/debian/patches/Remove_Zoneinfo_Tarball.patch python-dateutil-2.8.2/debian/patches/Remove_Zoneinfo_Tarball.patch
--- python-dateutil-2.8.2/debian/patches/Remove_Zoneinfo_Tarball.patch	2022-10-14 13:10:49.0 +0200
+++ python-dateutil-2.8.2/debian/patches/Remove_Zoneinfo_Tarball.patch	2023-03-03 18:58:30.0 +0100
@@ -5,9 +5,10 @@
 ---
  MANIFEST.in  | 1 +
  dateutil/test/test_tz.py | 2 ++
+ dateutil/zoneinfo/__init__.py| 1 -
  python_dateutil.egg-info/SOURCES.txt | 3 +--
  setup.cfg| 3 ---
- 4 files changed, 4 insertions(+), 5 deletions(-)
+ 5 files changed, 4 insertions(+), 6 deletions(-)
 
 diff --git a/MANIFEST.in b/MANIFEST.in
 index d4d9f32..3e8b3fb 100644
@@ -38,6 +39,18 @@
  def testPickleZoneFileGettz(self):
  zoneinfo_file = zoneinfo.get_zonefile_instance()
  tzi = zoneinfo_file.get('America/New_York')
+diff --git a/dateutil/zoneinfo/__init__.py b/dateutil/zoneinfo/__init__.py
+index 34f11ad..18021dc 100644
+--- a/dateutil/zoneinfo/__init__.py
 b/dateutil/zoneinfo/__init__.py
+@@ -23,7 +23,6 @@ def getzoneinfofile_stream():
+ try:
+ return BytesIO(get_data(__name__, ZONEFILENAME))
+ except IOError as e:  # TODO  switch to FileNotFoundError?
+-warnings.warn("I/O error({0}): {1}".format(e.errno, e.strerror))
+ return None
+ 
+ 
 diff --git a/python_dateutil.egg-info/SOURCES.txt b/python_dateutil.egg-info/SOURCES.txt
 index c0d2a0f..ae4d43f 100644
 --- a/python_dateutil.egg-info/SOURCES.txt

Bug#1032306: postfix: autopkgtest fails with saslauthd installed

[Bastian Germann]

Am 03.03.23 um 20:32 schrieb Scott Kitterman:

How did you run the test that it failed?


https://ci.debian.net/data/autopkgtest/testing/amd64/p/postfix/31855201/log.gz

Bug#1023284: libevent: FTBFS with glibc 2.36

[Kurt Roeckx]

Hi,

It seems a fix for this is sitting git, but hasn't been uploaded. Is
there a reason it's not been uploaded yet?


Kurt

Bug#1032293: debian-timeline: validation errors in timeline.debian.net

[Laura Arjona Reina]

Control: retitle -1 Using  makes timeline empty (only 
header and footer are displayed)


Hello again
After researching a bit more, I think that the timeline software is not 
compatible with HTML5, at least the way it's used by debian-timeline.


Similar issue was raised long time ago to upstream project:

https://code.google.com/archive/p/simile-widgets/issues/450

with no answer :-/

I think I'll leave this bug here, my HTML/js skills are not enough to 
try to solve it, and rename it to reflect that the only validation issue 
left is the HTML5 doctype compatibility.


Kind regards



El 3/3/23 a las 11:14, Laura Arjona Reina escribió:

Hello again

I have committed the changes and later removed the DOCTYPE declaration, 
and it seems all the validation erros have been gone, except the one 
about the DOCTYPE declaration.


I don't know which DOCTYPE is the best one to use with the timeline.
I've had searched for info in
http://simile-widgets.org/timeline/
https://github.com/simile-widgets/timeline/
https://groups.google.com/g/simile-widgets
and I guess we can use  but we would need to make some 
adjustments to correctly load the xml files with the events, releases 
and release eras.


I'll continue working on this.

Kind regards,

El 3/3/23 a las 9:09, Laura Arjona Reina escribió:

Package: debian-timeline
Version: 45
Followup-For: Bug #1032293

Hello, I have tried to fix the validation errors with commit
8d6c753ecb6be22915a9c8430b3db50ec1a566a3 (patch attached), but 
deploying it in

timeline.debian.net resulted in the headers and footers of the page being
rendered, but not the actual body with the timeline of events (i.e. 
the same
result than installing the package locally (bugs #1032166 and maybe 
#655664
(this time in Firefox too)) . So I guess more fixes are needed. I'll 
try to

work on this.

Kind regards





--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#1032318: pyparted FTBFS: missing Build-Depends: libpython3-all-dev

[Helmut Grohne]

Source: pyparted
Version: 3.12.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pyparted fails to cross build from source, because it misses a build
dependency on libpython3-all-dev. The python3-all-dev dependency was
weakened using a :any annotation. While this annotation is necessary for
cross builds (and meaningless otherwise), it must be compensated by a
libpython3-all-dev dependency. I'm attaching a patch for your
convenience.

Helmut
diff --minimal -Nru pyparted-3.12.0/debian/changelog 
pyparted-3.12.0/debian/changelog
--- pyparted-3.12.0/debian/changelog2022-11-22 11:27:53.0 +0100
+++ pyparted-3.12.0/debian/changelog2023-03-03 18:38:01.0 +0100
@@ -1,3 +1,10 @@
+pyparted (3.12.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: libpython3-all-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 03 Mar 2023 18:38:01 +0100
+
 pyparted (3.12.0-3) unstable; urgency=medium
 
   * d/watch: Scan GitHub release API
diff --minimal -Nru pyparted-3.12.0/debian/control 
pyparted-3.12.0/debian/control
--- pyparted-3.12.0/debian/control  2022-11-22 11:27:03.0 +0100
+++ pyparted-3.12.0/debian/control  2023-03-03 18:37:59.0 +0100
@@ -6,6 +6,7 @@
 Build-Depends: debhelper-compat (= 12),
dh-python,
libparted-dev,
+   libpython3-all-dev,
parted,
pkg-config,
python3-all-dev:any,

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

[Colin Watson]

On Mon, Feb 27, 2023 at 03:26:52PM +0100, Alejandro Colomar wrote:
> On 2/27/23 13:56, G. Branden Robinson wrote:
> > At 2023-02-26T13:30:58+, Colin Watson wrote:
> >> First, move your current branch somewhere for reference, then make a new
> >> one.  Then, my routine for pulling in new upstreams looks roughly like
> >> this:
> >>
> >>   git-dpm import-new-upstream -p $UPSTREAMTAG^{} --rebase-patched 
> >> ../foo.orig.tar.gz
> >>   # this imports the unpacked upstream tarball onto an upstream branch
> >>   # based on $UPSTREAMTAG, then drops you into a rebase session
> >>
> >>   ... continue with rebase as needed, then once you're finished ...
> >>
> >>   git-dpm update-patches --amend
> >>   # the --amend is just because the import-new-upstream step will
> >>   # already have recorded the new upstream on the branch you started
> >>   # from, but the history looks clearer if you bundle the rebase with
> >>   # that in a single merge commit, which this does
> 
> May I ask something from you, Colin?  Could you please embed that
> info in the commit messages in salsa?  That would help those who
> want to learn Debian packaging from actual practice rather than
> tutorials (I've read and watched many of those, and my confusion
> only grows; I mean, just look at
>  :p).
> 
> In the Linux man pages I write the scripts or commands run to produce
> a scripted or semi-scripted patch, or when some important information
> needed to write a patch was gotten from some script.  See for example:

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.

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.

> > Please find attached my much more modest proposal.  Let's make sure the
> > groff in Debian bookworm will not throw confusing undefined register
> > warnings or drop text from man pages that begin to embrace groff 1.23's
> > new features.

I'm fine with this, modulo sorting out minor commit formatting details.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

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

[Thomas Uhle]

Dear maintainers,

Mike seems to be quite busy.  I think it would be good if this issue could 
be fixed for Debian bookworm.  So please can anyone of you step in?

If there is something else I could do to help, please let me know.

Thank you in advance!

Cheers,

Thomas


On Sun, 12 Feb 2023, Thomas Uhle wrote:


Hello Mike,

it seems that you are short of time.  That is why I have updated my patch 
adopting Simon's proposal.  I hope it helps to get this issue fixed for 
Debian bookworm.


Thank you in advance!

Cheers,

Thomas


On Fri, 2 Dec 2022, Mike Gabriel wrote:

> On  Fr 02 Dez 2022 20:55:32 CET, Thomas Uhle wrote:
> 
> > I think that moving polkit-mate-authentication-agent-1 to /usr/libexec and 
> > updating debian/control appropriately would be just enough to close this 
> > ticket.
> 
> Sorry, I am delayed with this. I'll see to an upload the coming days. 
> Thanks to Simon for the various solution approaches, I'll agree with the 
> /usr/libexec switch as the best and least invasive solution.
> 
> Thanks!

> Mike

Bug#1029010: llvm-toolchain-15: autopkgtest regression

[Simon McVittie]

On Fri, 03 Mar 2023 at 17:41:22 +0100, Sylvestre Ledru wrote:
> Le 16/01/2023 à 16:44, Adrian Bunk a écrit :
> > /usr/include/wasm32-wasi/c++/v1/__type_traits/is_array.h:40:22: error: 
> > reference to unresolved using declaration
> > template  struct _LIBCPP_TEMPLATE_VIS 
> > is_array<_Tp[_Np]>
> >   ^
> > /usr/include/wasm32-wasi/c++/v1/cstddef:52:1: note: using declaration 
> > annotated with 'using_if_exists' here
> > using ::size_t _LIBCPP_USING_IF_EXISTS;

I've cut down what I think is the root cause of this compile failure to
a more minimal bug report: see #1032317.

I don't think this is *really* a regression, because in the version in
bookworm, the autopkgtest didn't exercise compilation of C++ into
WebAssembly at all.

If I understand correctly, when compared with bookworm, the version in
sid adds a new feature (the necessary -dev packages for compiling C++ into
WebAssembly) and also adds a smoke-test for that feature, but the feature
doesn't yet work as intended. Is that accurate?

Did the new autopkgtest coverage pass on the maintainers' systems? I don't
seen any sign of it having passed on ci.debian.net since 1:15.0.6-5~exp1
(see https://ci.debian.net/packages/l/llvm-toolchain-15/unstable/amd64/
which includes test results with all packages from unstable, and also test
results with llvm-toolchain-15 taken from experimental and everything else
from unstable).

If you don't consider full C++ wasm support to be release-critical for
bookworm, one option would be to remove the packages that enable it,
together with their test coverage; that should get the autopkgtest passing
again. However, I haven't looked at the diff between 15.0.6 and 15.0.7,
so I don't know whether the release team would be likely to accept an
unblock request or not.

When enabling new features in experimental, please check the CI results
before re-uploading to unstable. This can be done conveniently via
,
which asks the question: if the packages in unstable were all in
testing, and the packages in experimental were all in unstable, would
llvm-toolchain-15 be able to migrate?

Thanks,
smcv

Bug#1032317: libc++-15-dev: after installing libc++-15-dev, wasi-wasm32 stddef.h stops declaring size_t

[Simon McVittie]

Package: libc++-15-dev
Version: 1:15.0.7-1
Severity: important

This is a simplification of the compilation failure in #1029010.

To reproduce:

$ podman run --rm -it debian:sid-slim
# cat > stddef.cpp <
int main () { return sizeof (size_t); }
EOF
# apt-get update
# apt-get upgrade
# apt-get install --no-install-recommends make wasi-libc clang-15 
libc++-15-dev-wasm32
# clang++-15 -c --target=wasi-wasm32 -ostddef-cpp.o stddef.cpp
# apt-get install --no-install-recommends libc++-15-dev
# clang++-15 -c --target=wasi-wasm32 -ostddef-cpp.o stddef.cpp

Expected result: both clang++-15 calls succeed (stddef.h declares size_t)

Actual result: the second clang++-15 call fails:

> stddef.cpp:2:30: error: use of undeclared identifier 'size_t'; did you mean 
> 'sizeof'?
> int main () { return sizeof (size_t); }   
> 
>  ^~
>  sizeof
> stddef.cpp:2:36: error: expected expression
> int main () { return sizeof (size_t); }   
> 
>^
> 2 errors generated.

If I just preprocess (clang++-15 -E -dI --target=wasi-wasm32 stddef.cpp),
I get this (after removing blank lines):

# 1 "stddef.cpp"
# 1 "" 1
# 1 "" 3
# 368 "" 3
# 1 "" 1
# 1 "" 2
# 1 "stddef.cpp" 2
#include  /* clang -E -dI */
# 1 "stddef.cpp"
# 1 "/usr/include/wasm32-wasi/c++/v1/stddef.h" 1 3
# 39 "/usr/include/wasm32-wasi/c++/v1/stddef.h" 3
#include <__config> /* clang -E -dI */
# 39 "/usr/include/wasm32-wasi/c++/v1/stddef.h" 3
# 1 "/usr/include/wasm32-wasi/c++/v1/__config" 1 3
# 13 "/usr/include/wasm32-wasi/c++/v1/__config" 3
#include <__config_site> /* clang -E -dI */
# 13 "/usr/include/wasm32-wasi/c++/v1/__config" 3
# 1 "/usr/include/wasm32-wasi/c++/v1/__config_site" 1 3
# 37 "/usr/include/wasm32-wasi/c++/v1/__config_site" 3
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wmacro-redefined"
#pragma clang diagnostic pop
# 14 "/usr/include/wasm32-wasi/c++/v1/__config" 2 3
# 23 "/usr/include/wasm32-wasi/c++/v1/__config" 3
# 660 "/usr/include/wasm32-wasi/c++/v1/__config" 3
namespace std { inline namespace __2 { }}
# 40 "/usr/include/wasm32-wasi/c++/v1/stddef.h" 2 3
# 43 "/usr/include/wasm32-wasi/c++/v1/stddef.h" 3
#include_next  /* clang -E -dI */
# 45 "/usr/include/wasm32-wasi/c++/v1/stddef.h" 3
# 1 "/usr/include/c++/v1/stddef.h" 1 3
# 46 "/usr/include/wasm32-wasi/c++/v1/stddef.h" 2 3
typedef decltype(nullptr) nullptr_t;
# 2 "stddef.cpp" 2
int main () { return sizeof (size_t); }

which you will notice doesn't declare size_t as you might expect.

If I remove libc++-15-dev and re-run preprocessing with the same
command-line, I get this, which looks better in some ways but worse in
others (it defines ptrdiff_t, size_t and max_align_t, but not nullptr_t):

# 1 "stddef.cpp"
# 1 "" 1
# 1 "" 3
# 368 "" 3
# 1 "" 1
# 1 "" 2
# 1 "stddef.cpp" 2
#include  /* clang -E -dI */
# 1 "stddef.cpp"
# 1 "/usr/lib/llvm-15/lib/clang/15.0.7/include/stddef.h" 1 3
# 35 "/usr/lib/llvm-15/lib/clang/15.0.7/include/stddef.h" 3
typedef long int ptrdiff_t;
# 46 "/usr/lib/llvm-15/lib/clang/15.0.7/include/stddef.h" 3
typedef long unsigned int size_t;
# 102 "/usr/lib/llvm-15/lib/clang/15.0.7/include/stddef.h" 3
#include "__stddef_max_align_t.h" /* clang -E -dI */
# 102 "/usr/lib/llvm-15/lib/clang/15.0.7/include/stddef.h" 3
# 1 "/usr/lib/llvm-15/lib/clang/15.0.7/include/__stddef_max_align_t.h" 1 3
# 19 "/usr/lib/llvm-15/lib/clang/15.0.7/include/__stddef_max_align_t.h" 3
typedef struct {
  long long __clang_max_align_nonce1
  __attribute__((__aligned__(__alignof__(long long;
  long double __clang_max_align_nonce2
  __attribute__((__aligned__(__alignof__(long double;
} max_align_t;
# 103 "/usr/lib/llvm-15/lib/clang/15.0.7/include/stddef.h" 2 3
# 2 "stddef.cpp" 2
int main () { return sizeof (size_t); }

I think this is leading to the autopkgtest failure seen in #1029010.
The autopkgtest uses "Depends: @" which installs all binary packages built
by the llvm-toolchain-15 source package, and as a result of this bug,
/usr/include/wasm32-wasi/c++/v1/cstddef doesn't define std::size_t because
there is no declaration for ::size_t, which should have come from stddef.h.

Sorry, I don't know enough about the internals of libc++ to suggest
a solution.

smcv

Bug#1013668: RFP: openseachest -- utilities for operations on SATA/SAS/NVMe/USB storage devices

[Christoph Anton Mitterer]

On Fri, 2023-03-03 at 08:38 +0100, Gürkan Myczko wrote:
> I have some packaging of it here, but I'm not yet sure how to fix 
> remaining lintian problems,
> their manpages are of non optimal quality:
> 
> http://sid.ethz.ch/debian/openseachest/

Looks nice... have you asked a sponsor for help with the lintian
problems?

Cheers,
Chris.

Bug#1029010: llvm-toolchain-15: autopkgtest regression

[Sylvestre Ledru]

Hello

Sorry, I missed this issue.

Faidon, does it ring a bell ?

Thanks

Sylvestre


Le 16/01/2023 à 16:44, Adrian Bunk a écrit :

Source: llvm-toolchain-15
Version: 1:15.0.7-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/l/llvm-toolchain-15/30436521/log.gz

...
In file included from cout.cpp:1:
In file included from /usr/include/wasm32-wasi/c++/v1/iostream:41:
In file included from /usr/include/wasm32-wasi/c++/v1/ios:221:
In file included from /usr/include/wasm32-wasi/c++/v1/__locale:18:
In file included from /usr/include/wasm32-wasi/c++/v1/memory:841:
In file included from /usr/include/wasm32-wasi/c++/v1/__algorithm/copy.h:12:
In file included from 
/usr/include/wasm32-wasi/c++/v1/__algorithm/unwrap_iter.h:13:
In file included from 
/usr/include/wasm32-wasi/c++/v1/__iterator/iterator_traits.h:14:
In file included from 
/usr/include/wasm32-wasi/c++/v1/__iterator/incrementable_traits.h:15:
In file included from /usr/include/wasm32-wasi/c++/v1/concepts:133:
In file included from 
/usr/include/wasm32-wasi/c++/v1/__concepts/arithmetic.h:15:
In file included from /usr/include/wasm32-wasi/c++/v1/type_traits:421:
In file included from /usr/include/wasm32-wasi/c++/v1/__functional/invoke.h:17:
In file included from /usr/include/wasm32-wasi/c++/v1/__type_traits/decay.h:16:
/usr/include/wasm32-wasi/c++/v1/__type_traits/is_array.h:40:22: error: 
reference to unresolved using declaration
template  struct _LIBCPP_TEMPLATE_VIS is_array<_Tp[_Np]>
  ^
/usr/include/wasm32-wasi/c++/v1/cstddef:52:1: note: using declaration annotated 
with 'using_if_exists' here
using ::size_t _LIBCPP_USING_IF_EXISTS;
^
In file included from cout.cpp:1:
In file included from /usr/include/wasm32-wasi/c++/v1/iostream:41:
In file included from /usr/include/wasm32-wasi/c++/v1/ios:221:
In file included from /usr/include/wasm32-wasi/c++/v1/__locale:18:
In file included from /usr/include/wasm32-wasi/c++/v1/memory:841:
In file included from /usr/include/wasm32-wasi/c++/v1/__algorithm/copy.h:12:
In file included from 
/usr/include/wasm32-wasi/c++/v1/__algorithm/unwrap_iter.h:13:
In file included from 
/usr/include/wasm32-wasi/c++/v1/__iterator/iterator_traits.h:14:
In file included from 
/usr/include/wasm32-wasi/c++/v1/__iterator/incrementable_traits.h:15:
In file included from /usr/include/wasm32-wasi/c++/v1/concepts:133:
In file included from 
/usr/include/wasm32-wasi/c++/v1/__concepts/arithmetic.h:15:
In file included from /usr/include/wasm32-wasi/c++/v1/type_traits:421:
In file included from /usr/include/wasm32-wasi/c++/v1/__functional/invoke.h:17:
In file included from /usr/include/wasm32-wasi/c++/v1/__type_traits/decay.h:20:
/usr/include/wasm32-wasi/c++/v1/__type_traits/remove_extent.h:25:22: error: 
reference to unresolved using declaration
template  struct _LIBCPP_TEMPLATE_VIS 
remove_extent<_Tp[_Np]>
  ^
/usr/include/wasm32-wasi/c++/v1/cstddef:52:1: note: using declaration annotated 
with 'using_if_exists' here
using ::size_t _LIBCPP_USING_IF_EXISTS;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
autopkgtest [04:43:27]: test command1: ---]
autopkgtest [04:43:27]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 1
...
autopkgtest [04:47:28]:  summary
command1 FAIL non-zero exit status 1
integration-test-suite-test PASS
cmake-test   PASS
command2 PASS
command3 PASS

___
Pkg-llvm-team mailing list
pkg-llvm-t...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team

Bug#1032316: llvm-toolchain-15: is this version intended for Debian 12 'bookworm'?

[Simon McVittie]

Source: llvm-toolchain-15
Version: 1:15.0.7-1
Severity: serious
Justification: blocking RC bug fixes in Mesa from migrating
X-Debbugs-Cc: debian-rele...@lists.debian.org

llvm-toolchain-15/1:15.0.7-1 was uploaded several weeks ago, shortly
after the transition freeze, but has not migrated to testing due to an
autopkgtest regression (#1029010).

Mesa uses LLVM 15, so the new upstream release is preventing Mesa bug fixes
from migrating, some of them important or even release-critical.

Is this version intended to enter testing in time for Debian 12 'bookworm'?
It seems quite late in the release process for the restructuring that
happened in 1:15.0.6-5~exp1 to be uploaded to unstable, for example.

If this version is meant to enter testing, then please fix the autopkgtest
(I'll follow up to #1029010 with more about that) and coordinate with
the release team to get it into unstable.

Or, if this version is not meant to enter testing, please upload a
version to unstable that is intended for testing (which might involve
reverting some of the changes and/or using a "+really" version), and
then re-upload the newer version to experimental.

For more details of the freeze timeline, please refer to
,
 and
.

Thanks,
smcv

Bug#1031364: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Gunnar Wolf]

tags 1031364 + upstream,forwarded,patch
thanks

I have reported this bug to the upstream author as issue #69:

https://gitlab.com/larswirzenius/vmdb2/-/issues/69

And proposed a simplistic patch as merge request #106:

https://gitlab.com/larswirzenius/vmdb2/-/merge_requests/106

Just for completeness sake, I'm including the patch in this report as
well:

diff --git a/vmdb/plugins/mkfs_plugin.py b/vmdb/plugins/mkfs_plugin.py
index 7bb32b6..f0bef3b 100644
--- a/vmdb/plugins/mkfs_plugin.py
+++ b/vmdb/plugins/mkfs_plugin.py
@@ -51,6 +51,17 @@ class MkfsStepRunner(vmdb.StepRunnerInterface):
 cmd.append("-L")
 cmd.append(label)
 
+# Ext4 filesystem features large_dir and metadata_csum_seed
+# are known to make versions of GRUB older than 2.06-8 unable
+# to boot. Keep this around at least until it is no longer
+# likely enough(?) users will try to build older target
+# systems.
+if fstype == "ext4":
+cmd.append("-O")
+cmd.append("^large_dir")
+cmd.append("-O")
+cmd.append("^metadata_csum_seed")
+
 options = values["options"] or None
 if options:
 for opt in options.split(" "):

Bug#1032315: provide separate packages for legacy and nft iptables

[Harald Dunkel]

Package: iptables
Version: 1.8.9-2
Severity: wishlist

Please move legacy iptables into separate packages to support
installing just the nft versions. We will never get rid of legacy
iptables/ip6tables if it is packaged together with nft for each
release.


Thank you very much in advance

Harri

Bug#1032314: autopkgtest: Specifying --apt-pocket causes wrong unwanted pinning to default release

[Paride Legovini]

Package: autopkgtest
Severity: normal
X-Debbugs-Cc: par...@debian.org

Adding a pocket via --apt-pocket= causes the
_get_default_release() function to be called. This is needed to
construct the sources.list entry for the pocket, which will be in the
form of:

  deb  - ...

The _get_default_release() function caches the detected default
release in the default_release variable, which is the same variable
used to store the --apt-default-release= value. This has
no effect when only one test is present in d/t/control, but when
more than one test is present the tests after the first will have
unwanted/wrong pinning (as if --apt-default-release was specified).

Bug#1032313: node-mermaid: CVE-2022-48345

[Salvatore Bonaccorso]

Source: node-mermaid
Version: 8.14.0+~cs11.4.14-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-mermaid.

CVE-2022-48345[0]:
| sanitize-url (aka @braintree/sanitize-url) before 6.0.2 allows XSS via
| HTML entities.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-48345
https://www.cve.org/CVERecord?id=CVE-2022-48345
[1] 
https://github.com/braintree/sanitize-url/commit/d4bdc89f1743fe3cdb7c3f24b06e4c875f349b0c

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1031905: riseup-vpn: fails to connect, when pressing cancel some the ui elements will dissapear.

[Nilesh Patra]

Control: tags -1 moreinfo

On Sat, 25 Feb 2023 00:59:05 +0200 georgeu  wrote:
> Package: riseup-vpn
> Version: 0.21.11+ds1-3
> Severity: normal
> X-Debbugs-Cc: g...@tutanota.com
>
>* What led up to the situation? * tried to connect.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? * on my desktop works fine.

I am confused -- if it works fine on your desktop, then what is the
issue exactly?

>* What was the outcome of this action? * unable to connect
>* What outcome did you expect instead? * Connecting to VPN

I am unable to reproduce this behaviour. Can you provide me more
details:

* Which Desktop environment are you on?
* Have you installed any external go-packages?
* Is your (testing) system upto date?
* There was some issue with snowflake recently, due to which it wasn't
  able to function properly, are you based in Russia by any chance?
* Can you please run riseup-vpn via your terminal and share with me the
  output you get on terminal when riseup-vpn is choking/not connecting?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1032312: llvm-toolchain-15: debian/1%15.0.6-4 tag missing from git

[Simon McVittie]

Source: llvm-toolchain-15
Version: 1:15.0.6-4
Severity: minor
Tags: patch

The version of llvm-toolchain-15 currently available in bookworm,
1:15.0.6-4, doesn't have a tag in the git repository. By comparing the
packaging git history with what's in the archive, it seems that commit
ab536f6e8ce4fd9a55a8cc9266507a96f56c71d2 "rebase of the patches" is the
right one.

Please push a tag if you already have one, or fetch the tag from
https://salsa.debian.org/smcv/llvm-toolchain (assuming I've located the
correct commit to tag).

Thanks,
smcv

Bug#1032311: Mirror mirrors.nic.cz not listed on "https://www.debian.org/mirror/list.html"

[Alexandr Šabacký]

Package: mirrors
Severity: minor

The mirror"http://mirrors.nic.cz/debian/;  is not present 
on"https://www.debian.org/mirror/list.html;. The mirror was added to masterlist on September 27. 2022 . It 
is active and up-to-date as can be seen 
here"https://mirror-master.debian.org/status/mirror-status.html#[results]=0-0[results]=mirrors.nic.cz---;.

Trace Url:http://mirrors.nic.cz/debian/project/trace/

Is there any particular reason for this and is there anything we can do to 
remedy this?
Thanks,
Alexandr Šabacký

--
Alexandr Šabacký
nic-admin
-
CZ.NIC, z.s.p.o.
Milešovská 5
130 00 Praha 3
e-mail:alexandr.saba...@nic.cz
web:http://www.nic.cz/
-

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

[James Addison]

Package: libgnome-desktop-4-2
Followup-For: Bug #1029821
X-Debbugs-Cc: gunna...@debian.org

On Fri, 3 Mar 2023 15:10:30 +0100, Gunnar wrote:
> On 2023-03-03 13:21, James Addison wrote:
> > I also noticed that some of gnome-desktop's default locale-to-input-source
> > mappings provide multiple entries, delimited by the '+' character:
> > 
> > https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/43.2/libgnome-desktop/default-input-sources.h#L31

> That's a misconception. The '+' character is there to specify a layout 
> variant. So "ch+fr" means the "French (Switzerland)" keyboard layout.

Ok, that's good to have clarified - thank you Gunnar for the correction.

Unrelated to that: I think I'll pause from providing any further comments on
this bug thread for at least a few days.

Bug#1032166: timeline data not shown in browser (from local install)

[Laura Arjona Reina]

Hello, I have done some tests and I think that the issue is related to 
CORS policy of the browsers.


If I install debian-timeline and I do:
 chromium  --allow-file-access-from-files 
file:///usr/share/debian-timeline/index.html &


I cannot see the events, but if I press F12 I can see them. So I think 
it's because 62-63  lines in media/debian-timeline.js:


	Timeline.loadXML("xml/events.xml?" + random, function(xml, url) { 
events.loadXML(xml, url); });
	Timeline.loadXML("xml/releases.xml?" + random, function(xml, url) { 
releases.loadXML(xml, url); });
	Timeline.loadXML("xml/release_eras.xml?" + random, function(xml, url) { 
release_eras.loadXML(xml, url); });


result in trying to load the data with the file:/// scheme, and thus, 
blocked by the browser. I think this does not happen in 
https://timeline.debian.net because there is a web server serving the 
files, so no file:/// is used.


I'll try to see if there is other way to load the data so a browser is 
happy with a local install; I'll also investigate if this issue is also 
related to the problems declaring the DOCTYPE as html5 (bug #1032293: 
when we set DOCTYPE html, the data is not rendered either and the 
timeline appears as empty).


Kind regards
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#1031794: socklog: fails to extract source package: dpkg-source: error: pathname 'socklog-2.1.0+repack/debian/service/socklog-unix/log/supervise' points outside source root (to '/run/runit/supervis

[Mathieu Mirmont]

On Wed, Feb 22, 2023 at 10:17:23PM +0100, Sven Joachim wrote:
> On 2023-02-22 21:45 +0100, Lucas Nussbaum wrote:
> 
> > Source: socklog
> > Version: 2.1.0+repack-4
> > Severity: serious
> >
> > dpkg-source: info: extracting socklog in socklog-2.1.0+repack
> > dpkg-source: info: unpacking socklog_2.1.0+repack.orig.tar.gz
> > dpkg-source: info: unpacking socklog_2.1.0+repack-4.debian.tar.xz
> > dpkg-source: info: using patch list from debian/patches/series
> > dpkg-source: info: applying 0001-socklog-conf-update-service.patch
> > dpkg-source: info: applying 0002-tryto-c.patch
> > dpkg-source: info: applying 0003-patches-fix-build-warnings.patch
> > dpkg-source: error: pathname 
> > 'socklog-2.1.0+repack/debian/service/socklog-unix/log/supervise' points 
> > outside source root (to '/run/runit/supervise/socklog-unix.log')
> >
> > That's on a system with a mix of testing and unstable. I'm not sure of
> > which package introduced that additional check. Let me know if you
> > cannot reproduce.
> 
> I can reproduce this, but only if the target directory
> (/run/runit/supervise) actually exists.  Otherwise dpkg-source does not
> complain.
> 
> Lintian reports the absolute symlink as a warning, but maybe turning it
> into an error would be more appropriate.

Thanks for checking, I'll be having a look soon. I haven't touched
this package in years and a bit of refreshing wouldn't hurt.

-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

Bug#1031821: libreswan: remote crash, CVE-2023-23009

[Daniel Kahn Gillmor]

On Thu 2023-03-02 17:34:10 -0500, Daniel Kahn Gillmor wrote:
> yep, works for me, thanks.  I'll do that later this evening or tomorrow
> morning.

This has been uploaded now, thanks for bearing with me.

 --dkg


signature.asc
Description: PGP signature

Bug#1028019: RFP: fonts-overpass -- Font family inspired by Highway Gothic

[Gürkan Myczko]

Hi Bastian

I just wanted to let you know about:

https://github.com/RedHatOfficial/Overpass/issues/68

and:

# apt install fnt
$ fnt update
$ fnt search overpass
google-overpass
google-overpassmono
$ fnt install overpass
$ fnt install overpassmono

Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf

[Emanuele Rocca]

Hi,

On Sun, Feb 14, 2021 at 02:12:17PM +, Vincent Arkesteijn wrote:
> Firefox is killed with SIGILL shortly after startup:
> $ firefox-esr -safe-mode
> Illegal instruction
> $ 

This is due to the fact that some armhf CPUs do not have support for NEON
instructions.

skia used to detect such support at runtime, but that behavior was removed in
https://github.com/google/skia/commit/809ccf37ec836d0df64afd0b13023fd968d505a4

Firefox seems to erroneously enable NEON in places where it shouldn't. Trying
to figure out exactly where and what's the best way to address this.

Meanwhile, to reproduce and debug this issue on a amd64 machine:

  apt install debootstrap qemu-user-static binfmt-support schroot

Trying to run a armhf binary on the x86 host will invoke qemu-arm-static, see:

  /usr/sbin/update-binfmts --display qemu-arm
  ls -l /usr/libexec/qemu-binfmt/arm-binfmt-P

Create a armhf chroot:

  debootstrap --arch=armhf sid /srv/sid-armhf
  printf '[armhf]\ntype=directory\ndirectory=/srv/sid-armhf\n' >> 
/etc/schroot/schroot.conf

Install and run firefox-esr in the chroot:

  schroot -c armhf
  (armhf)root@ariel:/home/ema# apt install --no-install-recommends firefox-esr

Firefox seems to be working:

  (armhf)root@ariel:/home/ema# firefox --help | head -1
  Usage: firefox-esr [ options ... ] [URL]

The reason why firefox does not crash here is that the default armhf CPU
emulated by qemu-arm-static has NEON support. We can override that by setting
QEMU_CPU to cortex-r5f (which cannot execute NEON instructions) and reproduce
the issue:

  (armhf)root@ariel:/home/ema# QEMU_CPU=cortex-r5f firefox
  qemu: uncaught target signal 4 (Illegal instruction) - core dumped
  Illegal instruction

To get a backtrace, install Firefox's debugging symbols in the chroot:

  (armhf)root@ariel:/home/ema# echo 'deb http://deb.debian.org/debian-debug 
sid-debug main' > /etc/apt/sources.list.d/debug.list
  (armhf)root@ariel:/home/ema# apt update && apt install firefox-esr-dbgsym

And do the following on the x86 host:

  dpkg --add-architecture armhf
  apt install libc6:armhf libc6-dbg:armhf gdb-multiarch

  LD_LIBRARY_PATH=/srv/sid-armhf/usr/lib/arm-linux-gnueabihf qemu-arm-static -g 
1234 -cpu cortex-r5f /srv/sid-armhf/usr/bin/firefox-esr --private-window

In another terminal, again on the host, this should give you a backtrace:

  gdb-multiarch -q /srv/sid-armhf/usr/bin/firefox-esr -ex 'set architecture 
arm' -ex 'target remote :1234' -ex 'set debug-file-directory 
/srv/sid-armhf/usr/lib/debug' -ex 'set pagination off' -ex 'continue' -ex 'bt' 
-ex 'continue' -ex 'exit'

Something like:

  Program received signal SIGILL, Illegal instruction.
  0x37071dc6 in _GLOBAL__sub_I_SkOpts.cpp () from 
/srv/sid-armhf/usr/lib/firefox-esr/libxul.so
  #0  0x37071dc6 in _GLOBAL__sub_I_SkOpts.cpp () from 
/srv/sid-armhf/usr/lib/firefox-esr/libxul.so
  #1  0x3f7d144c in call_init (env=0x3f208340, argv=0x3c94, argc=1, 
l=) at dl-init.c:70
  #2  call_init (l=, argc=1, argv=0x3c94, env=0x3f208340) at 
dl-init.c:26
  #3  0x3f7d14f2 in _dl_init (main_map=0x3f245f00, argc=1, argv=0x3c94, 
env=0x3f208340) at dl-init.c:117
  #4  0x3f56664a in _dl_catch_exception () from 
/srv/sid-armhf/usr/lib/arm-linux-gnueabihf/libc.so.6
  #5  0x3f7d5b60 in dl_open_worker (a=0x3fffd7b0) at dl-open.c:808
  #6  0x3f566614 in _dl_catch_exception () from 
/srv/sid-armhf/usr/lib/arm-linux-gnueabihf/libc.so.6
  #7  0x3f7d5da2 in _dl_open (file=0x3fffda64 
"/srv/sid-armhf/usr/lib/firefox-esr/libxul.so", mode=-2147483391, 
  caller_dlopen=0x4000af81 <_start+4560>, nsid=-2, argc=1, argv=0x3c94, 
env=0x3f208340) at dl-open.c:884
  #8  0x3f4d9da0 in ?? () from 
/srv/sid-armhf/usr/lib/arm-linux-gnueabihf/libc.so.6

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

[Gunnar Hjalmarsson]

On 2023-03-03 13:21, James Addison wrote:

I also noticed that some of gnome-desktop's default locale-to-input-source
mappings provide multiple entries, delimited by the '+' character:

https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/43.2/libgnome-desktop/default-input-sources.h#L31


That's a misconception. The '+' character is there to specify a layout 
variant. So "ch+fr" means the "French (Switzerland)" keyboard layout.


--
Gunnar

Bug#1032259: conky: High CPU usage

[Antoine Le Gonidec]

I think I can confirm that the high Xorg memory usage is due to this update, I 
am now sitting at 3.30GB after a dozen hours.

To make really sure of the cause, I am going to revert to the 1.17 build of 
Conky and let it run for a dozen hours too.

In the meantime I am bumping the bug severity again to prevent this memory leak 
to reach Bookworm, once again feel free to revert that if you think that is not 
such a big deal (I guess not everyone have X sessions running for several days).


OpenPGP_signature
Description: OpenPGP digital signature

Bug#939615: rtkit: Flooding syslog

[Michal Politowski]

Package: rtkit
Version: 0.13-5
Followup-For: Bug #939615

I can also confirm that setting LogLevelMax=info stops the flooding.
If you don't want to override upstream by default here, then please
at least make note of it in README.Debian.
Although I would say that flooding syslog with _debug_ messages is
something that should be overriden by the distribution if necessary.


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

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

Versions of packages rtkit depends on:
ii  adduser 3.131
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libc6   2.36-8
ii  libcap2 1:2.66-3
ii  libdbus-1-3 1.14.6-1
ii  libsystemd0 252.6-1
ii  policykit-1 122-3
ii  polkitd 122-3

rtkit recommends no packages.

rtkit suggests no packages.

-- no debconf information

-- 
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

Bug#1032255: pulseaudio: sound keeps dying (on Tiger Lake)

[James Addison]

Package: pulseaudio
Followup-For: Bug #1032255
Control: retitle -1 pulseaudio: application restart required to restore sound
Control: severity -1 normal
Control: tags -1 moreinfo

Hi Dave,

Are there any clues (error messages, service start/stops, or things like that)
in the affected system's journal logs?

The following command might be helpful along those lines:

  $ journalctl --user --merge --unit pulseaudio.service

Also, the following page provides some information (and some problem-solving
techniques) for PulseAudio on Debian - have you had any luck with any of these?

https://wiki.debian.org/PulseAudio

Cheers,
James

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

[Gunnar Hjalmarsson]

X-Debbugs-CC: s...@debian.org, z...@debian.org, ken...@xdump.org, 
yy.y.ja...@gmail.com, iwama...@debian.org, debian-i...@lists.debian.org, 
debian-japan...@lists.debian.org, m...@packages.debian.org, 
ibus-an...@packages.debian.org


On 2023-03-03 12:52, James Addison wrote:

If it's true that the cause is that 'tasksel' and 'gnome-initial-setup'
are mismatched, then we could apply a fix in either one.

Given that we have an existing patch available for 'gnome-initial-desktop',
I've opened a corresponding 'tasksel' changeset with the mirrored side of
the fix at:

https://salsa.debian.org/installer-team/tasksel/-/merge_requests/25


While either one would address the inconsistency, most Japanese users 
seem to prefer mozc over anthy. So the two routes are not equally good.


Please do not ignore the user preferences.

--
Gunnar Hjalmarsson

Bug#1030942: PC Hangs on Boot

[Rainer Kupke]

This may be related to


The provided workaround works for me.


My machine has the RTL8723DE and boots after blacklisting rtw88_8723de.

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

[James Addison]

Package: libgnome-desktop-4-2
Followup-For: Bug #1029821

I also noticed that some of gnome-desktop's default locale-to-input-source
mappings provide multiple entries, delimited by the '+' character:

https://gitlab.gnome.org/GNOME/gnome-desktop/-/blob/43.2/libgnome-desktop/default-input-sources.h#L31

It's probably a question to ask them, but I am wondering whether it'd be
possible (and/or sensible) to provide *both* anthy and mozc in the default
input sources (which would correspond to adding ibus-anthy and ibus-mozc both
as 'Recommends', instead of a choice between them).

Bug#1032309: sddm: [INTL:tr] turkish debconf translation update

[Atila KOÇ]

Package: sddm
Version: N/A
Severity: wishlist
Tags: l10n patch

Hello,

Find attached the updated Turkish translation of the sddm debconf 
template.
It has been submitted for review to the debian-l10n-turkish mailing 
list.

Please include it in your next upload.

Regards,
Atila KOÇ
--- YASAL UYARI ---

# Turkish debconf translation of sddm package
# This file is distributed under the same license as the sddm package.
# Recai Oktaş , 2004.
# Osman Yüksel , 2004, 2006.
# Atila KOÇ , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: sddm\n"
"Report-Msgid-Bugs-To: s...@packages.debian.org\n"
"POT-Creation-Date: 2015-07-11 06:12+0200\n"
"PO-Revision-Date: 2023-02-10 10:22+0300\n"
"Last-Translator: Atila KOÇ \n"
"Language-Team: Debian L10n Turkish \n"
"Language: tr\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: select
#. Description
#: ../sddm.templates:3001
msgid "Default display manager:"
msgstr "Ön tanımlı ekran yöneticisi:"

#. Type: select
#. Description
#: ../sddm.templates:3001
msgid ""
"A display manager is a program that provides graphical login capabilities "
"for the X Window System."
msgstr ""
"Ekran yöneticisi programı, X Pencere Sistemi'ne görsel arayüz ile giriş "
"yapma yeteneği kazandırır."

#. Type: select
#. Description
#: ../sddm.templates:3001
msgid ""
"Only one display manager can manage a given X server, but multiple display "
"manager packages are installed. Please select which display manager should "
"run by default."
msgstr ""
"Sisteminizde birden fazla ekran yöneticisi kurulu durumda; ancak eldeki bir "
"X sunucusunu yalnızca bir ekran yöneticisi yönetebilir. Ön tanımlı olarak "
"kullanmak istediğiniz ekran yöneticisini seçin."

#. Type: select
#. Description
#: ../sddm.templates:3001
msgid ""
"Multiple display managers can run simultaneously if they are configured to "
"manage different servers; to achieve this, configure the display managers "
"accordingly, edit each of their init scripts in /etc/init.d, and disable the "
"check for a default display manager."
msgstr ""
"Farklı sunucuları yönetecek şekilde yapılandırılmaları koşulu ile birden "
"fazla ekran yöneticisi eş zamanlı çalışabilir. Bunu mümkün kılmak için, "
"ekran yöneticilerini buna göre yapılandırın, hepsinin /etc/init.d "
"dizinindeki başlangıç betiklerini değiştirin ve ön tanımlı ekran yöneticisi "
"denetleme işlevini devre dışı bırakın."

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

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)

Since we've found the conditions for the problem to occur and since it looks
like a fairly safe patch, they might welcome it as a fix.

Thanks,
James

[1] - https://gitlab.com/mailman/hyperkitty/

Bug#1032308: unblock: gnome-tweaks/42~beta-4

[Simon McVittie]

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

Please unblock package gnome-tweaks

[ Reason ]
Remove an option that no longer does anything from the UI (#1032286)
and take the opportunity to update translations from upstream.

[ Impact ]
If not accepted, users will report duplicates of #1032286 thinking that
the option is meant to do something. It has no effect since GNOME 42.

[ Tests ]
Manual test: gnome-tweaks still runs, the obsolete option isn't shown.

[ Risks ]
Trivial changes to a leaf package.

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

[ Other info ]
The attached gnome-tweaks_42~beta-4-excluding-l10n.diff excludes the
content of debian/patches/*.patch and po/*.po to show the functional
change most clearly.

If a more full diff is desired, gnome-tweaks_42~beta-4.diff.gz excludes
the content of debian/patches/*.patch but does include po/*.po.

unblock gnome-tweaks/42~beta-4


gnome-tweaks_42~beta-4.diff.gz
Description: application/gzip
diffstat for gnome-tweaks-42~beta gnome-tweaks-42~beta

 debian/changelog   |   10 
 debian/patches/Add-Abkhazian-translation.patch |  708 +
 debian/patches/Add-Georgian-translation.patch  |  710 +
 debian/patches/Remove-deprecated-option-for-separate-Lock-screen-wallpap.patch |  979 ++
 debian/patches/Update-Abkhazian-translation-1.patch|   58 
 debian/patches/Update-Abkhazian-translation-2.patch| 4043 ++
 debian/patches/Update-Abkhazian-translation-3.patch| 3145 +++
 debian/patches/Update-Abkhazian-translation-4.patch|  924 ++
 debian/patches/Update-Abkhazian-translation.patch  |  133 
 debian/patches/Update-Basque-translation-1.patch   |  174 
 debian/patches/Update-Basque-translation.patch |   31 
 debian/patches/Update-Belarusian-translation.patch |  659 +
 debian/patches/Update-Danish-translation.patch |   40 
 debian/patches/Update-Dutch-translation.patch  |  779 +
 debian/patches/Update-Georgian-translation.patch   |  179 
 debian/patches/Update-German-translation.patch |  735 +
 debian/patches/Update-Greek-translation.patch  |  773 +
 debian/patches/Update-Hungarian-translation.patch  |  712 +
 debian/patches/Update-Icelandic-translation-1.patch|   59 
 debian/patches/Update-Icelandic-translation.patch  |  484 +
 debian/patches/Update-Italian-translation.patch|  679 +
 debian/patches/Update-Japanese-translation.patch   |   62 
 debian/patches/Update-Kazakh-translation.patch |  733 +
 debian/patches/Update-Latvian-translation.patch|  777 +
 debian/patches/Update-Nepali-translation.patch |  895 ++
 debian/patches/Update-Russian-translation-1.patch  |   60 
 debian/patches/Update-Russian-translation-2.patch  |   69 
 debian/patches/Update-Russian-translation.patch|   45 
 debian/patches/Update-Serbian-translation.patch|  757 +
 debian/patches/Update-Turkish-translation.patch|  329 
 debian/patches/Update-Vietnamese-translation.patch |  778 +
 debian/patches/Updated-Lithuanian-translation.patch|  773 +
 debian/patches/series  |   31 
 gtweak/tweaks/tweak_group_appearance.py|5 
 po/LINGUAS |2 
 po/ab.po   |  675 +
 po/af.po   |4 
 po/ar.po   |4 
 po/as.po   |5 
 po/be.po   |  403 
 po/bg.po   |4 
 po/bs.po 

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

[James Addison]

Package: libgnome-desktop-4-2
Followup-For: Bug #1029821

(comment to bug-thread only)

If it's true that the cause is that 'tasksel' and 'gnome-initial-setup'
are mismatched, then we could apply a fix in either one.

Given that we have an existing patch available for 'gnome-initial-desktop',
I've opened a corresponding 'tasksel' changeset with the mirrored side of the
fix at:

https://salsa.debian.org/installer-team/tasksel/-/merge_requests/25

Bug#1032275: gcc-12-cross: gfortran-12-ARCH is missing Provides: virtual packages

[Helmut Grohne]

Control: tags -1 + wontfix
Control: close -1
Control: block 983600 by 666743

Hi Dima,

On Thu, Mar 02, 2023 at 09:15:41AM -0800, Dima Kogan wrote:
> Hi. This is the underlying cause of
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983600

Thank you for working on this and thank you for consulting with
d-cross@l.d.o.

> Installing libopenmpi-dev:foreign is impossible because it depends on
> some virtual gfortran packages that the cross-compiler is not providing.
> I see this:
> 
>   # dpkg --print-architecture
>   amd64
> 
>   # dpkg --print-foreign-architectures
>   arm64
> 
>   # apt install libopenmpi-dev:arm64
>   ...
>   The following packages have unmet dependencies:
>libopenmpi-dev:arm64 : Depends: gfortran-12:arm64 but it is not going to 
> be installed or
>gfortran-mod-15:arm64
> 
>   # apt show libopenmpi-dev:arm64
>   Package: libopenmpi-dev:arm64
>   Depends: gfortran-12 | gfortran-mod-15, ...
> 
> So to install libopenmpi-dev:arm64 we need gfortran-mod-15. This is
> provided by the native compiler:
> 
>   # apt show gfortran-12 | grep Provides
>   Provides: fortran95-compiler, gfortran-mod-15
> 
> But not by the cross compiler:
> 
>   # apt show gfortran-12-aarch64-linux-gnu | grep Provides
>    nothing printed 

Good summary of the problem. Thanks.

> Should the cross-compiler Provide this? Or is libopenmpi-dev wrong to
> Depend on it?

If gfortran-- were to provide gfortran-mod-15, bad things
were to happen. Provides inherit the Multi-Arch property, and since
gfortran-- is M-A:foreign, so would be gfortran-mod-15 and
that would mean that gfortran-12-sparc-linux-gnu would satisfy
libopenmpi-dev:arm64, which is something we really don't want.

The other alternative here is changing dependencies of libopenmpi-dev
and while that sounds workable initially, it isn't immediately obvious
what to change it to. Fortunately, the answer is already being worked
on. libopenmpi-dev should Depends: gfortran-12-for-host as its first
alternative. The minor downside is that gfortran-12-for-host doesn't
exist (yet). Since gfortran-12-for-host will be M-A:same, it can indeed
provide gfortran-mod-15 and thus solve the issue from the other side.

The bug that adds -for-host is #666743. It needs desperately needs more
people working on it, especially with reviewing and testing.

For these reasons, I'm going to close this bug report and hope you
agree. It really isn't actionable on the gcc side and #666743 should
entirely solve the issue.

Helmut

Bug#1032307: kwin FTCBFS: the devil is in the detail

[Helmut Grohne]

Source: kwin
Version: 4:5.27.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-Cc: debian-cr...@lists.debian.org

Hi,

I noticed that kwin fails to cross build from source and while looking
into it, it turned ever more complex. I'll copy it to d-cross@l.d.o for
instruction purposes.

The immediate failure looked fairly simple to me:

| In file included from 
/<>/obj-mipsel-linux-gnu/src/kwin_autogen/IEXH3JLKNG/moc_drmlease_v1_interface_p.cpp:10,
|  from 
/<>/obj-mipsel-linux-gnu/src/kwin_autogen/mocs_compilation.cpp:159:
| 
/<>/obj-mipsel-linux-gnu/src/kwin_autogen/IEXH3JLKNG/../../../../src/wayland/drmlease_v1_interface_p.h:52:10:
 error: ‘void 
KWaylandServer::DrmLeaseDeviceV1Interface::wp_drm_lease_device_v1_destroy_global()’
 marked ‘override’, but does not override
|52 | void wp_drm_lease_device_v1_destroy_global() override;
|   |  ^
| make[3]: *** [src/CMakeFiles/kwin.dir/build.make:235: 
src/CMakeFiles/kwin.dir/kwin_autogen/mocs_compilation.cpp.o] Error 1

I thought, this probably also fails natively and I can file a FTBFS.
Nope, it builds natively. Then I actually looked into the source and
found that wp_drm_lease_device_v1_destroy_global is a method in a class
DrmLeaseDeviceV1Interface supposedly inherited from
QtWaylandServer::wp_drm_lease_device_v1, for which I couldn't locate any
source with codesearch. That's when Sune Vuorela reminded me of
qtwaylandscanner. I thought that since we're using the same
qtwaylandscanner binary for both the native amd64 build and the amd64 ->
mipsel cross build, the difference must be the compiler invocation, so I
compared it and found that really the only difference was the compiler
binary name. Bummer. After a little more time, I actually went down and
compared the qtwaylandscanner invocation lines and observed that
qtwaylandscanner (cross build) != qtwaylandscanner_kde (native build)
and that their outputs would differ in precisely the method that is
missing here. So then I looked for where qtwaylandscanner_kde would come
from and learned that we aren't supposed to pass it but rather
src/wayland/tools/CMakeLists.txt wants to build it itself and you should
be passing a KF5_HOST_TOOLING path. Note that when kde says "host", GNU
people need to read "build". So I tried setting that, but it influences
a ton of other packages and would require me to install the entire KF5
stack natively. I then noticed that it only really is being used to
derive a NATIVE_PREFIX, which only actually needs to contain a native
qt5 base. So I tried patching out the requirement for passing
KF5_HOST_TOOLING and that actually happened to work.

I hope that this was educational or entertaining to read. If not, you
can just apply the attached patch and have kwin cross build again.

Helmut
diff --minimal -Nru kwin-5.27.0/debian/changelog kwin-5.27.0/debian/changelog
--- kwin-5.27.0/debian/changelog2023-02-18 17:08:46.0 +0100
+++ kwin-5.27.0/debian/changelog2023-03-02 08:43:06.0 +0100
@@ -1,3 +1,15 @@
+kwin (4:5.27.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ qtwaylandscanner != qtwaylandscanner_kde. Don't pass it.
++ Instead pass NATIVE_PREFIX of a qt5 base installation to build
+  a native qtwaylandscanner_kde as ExternalProject.
++ Do not require a full native KF5 toolchain.
++ Require a native qt5 base.
+
+ -- Helmut Grohne   Thu, 02 Mar 2023 08:43:06 +0100
+
 kwin (4:5.27.0-1) unstable; urgency=medium
 
   [ Pino Toscano ]
diff --minimal -Nru kwin-5.27.0/debian/control kwin-5.27.0/debian/control
--- kwin-5.27.0/debian/control  2023-02-17 22:43:47.0 +0100
+++ kwin-5.27.0/debian/control  2023-03-02 08:43:06.0 +0100
@@ -85,6 +85,7 @@
plasma-wayland-protocols (>= 1.9.0~),
python3:any,
qtbase5-dev (>= 5.15.2~),
+   qtbase5-dev:native (>= 5.15.2~),
qtbase5-private-dev,
qtdeclarative5-dev (>= 5.15.2~),
qttools5-dev (>= 5.15.2~),
diff --minimal -Nru kwin-5.27.0/debian/patches/cross.patch 
kwin-5.27.0/debian/patches/cross.patch
--- kwin-5.27.0/debian/patches/cross.patch  1970-01-01 01:00:00.0 
+0100
+++ kwin-5.27.0/debian/patches/cross.patch  2023-03-02 08:43:06.0 
+0100
@@ -0,0 +1,19 @@
+--- kwin-5.27.0.orig/src/wayland/tools/CMakeLists.txt
 kwin-5.27.0/src/wayland/tools/CMakeLists.txt
+@@ -13,13 +13,12 @@
+ add_executable(qtwaylandscanner_kde IMPORTED GLOBAL)
+ set_target_properties(qtwaylandscanner_kde PROPERTIES IMPORTED_LOCATION 
${QTWAYLANDSCANNER_KDE_EXECUTABLE})
+ elseif(CMAKE_CROSSCOMPILING)
+-if (NOT KF5_HOST_TOOLING)
+-message(FATAL_ERROR "Please provide a prefix with a native Qt build 
and pass -DKF5_HOST_TOOLING=path")
+-endif()
+-
+ # search native tooling prefix
+ set(NATIVE_PREFIX "" CACHE STRING 

Bug#1032306: postfix: autopkgtest fails with saslauthd installed

[Bastian Germann]

Source: postfix
Severity: important
Version: 3.7.4-2

sasl2-bin now contains a systemd service file. That makes postfix's chrooted autopkgtest fail because it is preferred 
over the SYSV init script. There should be a way to make the autopkgtest system prefer the init script. If you cannot

make that happen I can still revert the service introduction.

Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Paul Boddie]

On Friday, 3 March 2023 08:37:05 CET Otto Kekäläinen wrote:
> 
> I have this now as
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/36

Thanks for looking into this! I saw that the package build pipeline failed 
with various Lintian errors, so there was no package to download and test as 
far as I could see. Nevertheless, I tested an equivalent package myself and it 
resolved the problem, as noted previously.

> and I also sent it upstream at
> https://github.com/mariadb-corporation/mariadb-connector-c/pull/219.
> You can +1 these if you want to increase the odds of them being
> merged.

I will probably do this and also add a comment.

> If somebody wants to make a bug report upstream at jira.mariadb.org it
> would help, in particular if you can find any other library than just
> libqt5sql5-mysql that is affected by this.

"apt-cache rdepends libmariadb3 | wc -l" yields 175 entries on my system, 
although this is a very crude way of assessing the impact.

If I limit myself to "apt-cache rdepends libqt5sql5-mysql", I see the 
following packages with dependencies on that package:

akonadi-backend-mysql
digikam

There are these packages which recommend it:

actiona
kraft
xca

So, the direct exposure to the same problem as reported in the original bug is 
fairly limited. Had I kept using digiKam, I would probably have encountered 
problems with that, too, but I stopped using it given various concerns about 
its behaviour.

As for the broader dependencies on libmariadb3, I did a source code search for 
mysql_get_client_version using sources.debian.org and found a few candidates 
of note:

vtk6 and vtk9 both test for the client version to assess prepared query 
availability:

https://sources.debian.org/src/vtk6/6.3.0+dfsg2-8.1/IO/MySQL/
vtkMySQLDatabase.cxx/?hl=108#L108

https://sources.debian.org/src/vtk9/9.1.0+really9.1.0+dfsg2-5/IO/MySQL/
vtkMySQLDatabase.cxx/?hl=108#L108

paraview appears to embed VTK code and thus exhibits a similar potential 
issue:

https://sources.debian.org/src/paraview/5.11.0+dfsg-1/VTK/IO/MySQL/
vtkMySQLDatabase.cxx/?hl=109#L109

tango has two places with client version testing:

https://sources.debian.org/src/tango/9.3.4+dfsg1-2/cppserver/
tangoaccesscontrol/DbUtils.cpp/?hl=137#L137

https://sources.debian.org/src/tango/9.3.4+dfsg1-2/cppserver/database/
DataBaseUtils.cpp/?hl=782#L782

kamailio also seems to have code which might be affected:

https://sources.debian.org/src/kamailio/5.6.3-2/src/modules/db_mysql/
db_mysql.c/?hl=133#L133

Obviously, it is entirely possible that relatively few people use these 
packages and that there are few, if any, reverse dependencies on these 
packages, so nobody will have noticed any problems.

Paul

Bug#1032305: open-vm-tools: ld reports cannot find -labsl_synchronization when building

[陈天宇]

Source: open-vm-tools
Version: 2:12.1.5-3
Severity: normal
Tags: ftbfs patch
X-Debbugs-Cc: chentian...@uniontech.com

Hi,

When building open-vm-tools on Deepin 23 (beige), open-vm-tools fails to
build with ld errors. It seems that libgrpc++-dev Depends libabsl-dev,
causing build success on sid.

libtool: link: g++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/11/crtbeginS.o  
.libs/libcontainerInfo_la-containerInfo.o 
.libs/libcontainerInfo_la-containerInfo_docker.o 
.libs/libcontainerInfo_la-gogo.pb.o .libs/libcontainerInfo_la-mount.pb.o 
.libs/libcontainerInfo_la-metrics.pb.o 
.libs/libcontainerInfo_la-descriptor.pb.o .libs/libcontainerInfo_la-task.pb.o 
.libs/libcontainerInfo_la-tasks.pb.o .libs/libcontainerInfo_la-containers.pb.o 
.libs/libcontainerInfo_la-tasks.grpc.pb.o 
.libs/libcontainerInfo_la-containers.grpc.pb.o 
.libs/libcontainerInfo_la-containerInfo_grpc.o  -Wl,--whole-archive 
../../../lib/jsmn/.libs/libJsmn.a -Wl,--no-whole-archive  -Wl,-rpath 
-Wl,/<>/open-vm-tools/libvmtools/.libs -lcurl -lprotobuf -lgrpc++ 
-lgpr -labsl_synchronization 
/<>/open-vm-tools/libvmtools/.libs/libvmtools.so -lgobject-2.0 
-lglib-2.0 -L/usr/lib/gcc/x86_64-linux-gnu/11 
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. -lstdc++ -lm -lc -lgcc_s 
/usr/lib/gcc/x86_64-linux-gnu/11/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/crtn.o  -g -O2 
-fstack-protector-strong -Wl,-z -Wl,defs -Wl,-lc -Wl,--as-needed -Wl,-z 
-Wl,relro   -Wl,-soname -Wl,libcontainerInfo.so -o .libs/libcontainerInfo.so
/usr/bin/ld: cannot find -labsl_synchronization: No such file or directory
collect2: error: ld returned 1 exit status
make[5]: *** [Makefile:648: libcontainerInfo.la] Error 1
make[5]: Leaving directory 
'/<>/open-vm-tools/services/plugins/containerInfo'
make[4]: *** [Makefile:814: all-recursive] Error 1
make[4]: Leaving directory 
'/<>/open-vm-tools/services/plugins/containerInfo'
make[3]: *** [Makefile:519: all-recursive] Error 1
make[3]: Leaving directory '/<>/open-vm-tools/services/plugins'
make[2]: *** [Makefile:502: all-recursive] Error 1
make[2]: Leaving directory '/<>/open-vm-tools/services'
make[1]: *** [Makefile:566: all-recursive] Error 1
make[1]: Leaving directory '/<>/open-vm-tools'
dh_auto_build: error: cd open-vm-tools && make -j8 returned exit code 2
make: *** [debian/rules:13: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


Declaring libabsl-dev in debian/control could fix it.

(sid-amd64-sbuild) # aptitude why libabsl-dev
i   libgrpc++-dev Depends libabsl-dev (>= 20220623.1)

(beige-amd64-sbuild) # apt -s install libgrpc++-dev
Inst libgrpc10 (1.30.2-deepin1 Deepin:127.0.0.1 [amd64])
Inst libgrpc++1 (1.30.2-deepin1 Deepin:127.0.0.1 [amd64])
Inst libgrpc-dev (1.30.2-deepin1 Deepin:127.0.0.1 [amd64])
Inst libgrpc++-dev (1.30.2-deepin1 Deepin:127.0.0.1 [amd64])
Conf libgrpc10 (1.30.2-deepin1 Deepin:127.0.0.1 [amd64])
Conf libgrpc++1 (1.30.2-deepin1 Deepin:127.0.0.1 [amd64])
Conf libgrpc-dev (1.30.2-deepin1 Deepin:127.0.0.1 [amd64])
Conf libgrpc++-dev (1.30.2-deepin1 Deepin:127.0.0.1 [amd64])
(No libabsl-dev)

libabsl-dev.patch
Description: Binary data

Bug#1032292: Ledger 3.3.0 regression: specifying format for commodity

[Martin Michlmayr]

I've made 3.3.1 upstream.

I was going to cherry pick only fixes, but really the changes since
3.3.0 are mostly minor cleanups (docs and code) plus this fix plus a
small change to the output of `--version` (and an update to the Nix
file, which is not relevant to Debian).

You can either upload 3.3.1 or, if you don't feel comfortable with the
unrelated changes, take this commit:
https://github.com/ledger/ledger/commit/87b6a1e43fcf3d0f33e37ff811679486637f0809

Personally, I believe the release team would find the changes in
3.3.1 acceptable, but who knows...

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1031864: bazel-bootstrap: Please re-enable building on mips64el

[Adrian Bunk]

On Thu, Mar 02, 2023 at 12:44:42AM -0500, Olek Wojnar wrote:
>...
> I disabled mips64el leading up to the soft freeze since -4 was not building
> correctly at that time on that architecture. Lacking the time to
> troubleshoot, I made the decision to sacrifice the one problem architecture
> in favor of all the others that were working correctly.
>...

#1030783 was also required for that to work, I am not blaming you for
trying to get your package into testing before the freeze deadline.

> -Olek

cu
Adrian

Bug#1032065: ola: request RT acknowledgement for update to upstream version 0.10.9

[Wouter Verhelst]

Hi Paul,

On Tue, Feb 28, 2023 at 09:06:25PM +0100, Paul Gevers wrote:
> Hi Wouter,
> 
> On 27-02-2023 23:37, Wouter Verhelst wrote:
> > To be clear: this would require a pass through NEW, for the RDM tester
> > package ("ola-rdm-tester"). That's okay then? If so, can you add the
> > unblock? If not, I'll leave the rdm-tester for after the release.
> 
> No, adding new binaries is not OK.

Thanks. I had assumed that, but my email was a bit muddled and so I just
wanted to be clear.

I've uploaded 0.10.9 without the RDM tester (so no NEW cycle is needed).
That will wait until after the release.

Kind regards,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1032286: gdm3: fails to change the background for the lock screen.

[Simon McVittie]

Control: reassign -1 gnome-tweaks
Control: forwarded -1 
https://gitlab.gnome.org/GNOME/gnome-tweaks/-/merge_requests/74

On Fri, 03 Mar 2023 at 04:15:07 +0100, eve wrote:
>I can't seem to change the background for the lock screen.

GNOME 43 (and even 42, according to
https://gitlab.gnome.org/GNOME/gnome-tweaks/-/issues/404)
no longer has independent settings to change the background for the lock
screen and for normal desktop use. We should remove the now-useless option
from gnome-tweaks.

The intended design since GNOME 42 is that the background of the lock
screen is a blurred and desaturated version of your normal desktop
background.

>   When i lock/unlock my system

To be clear: this is when you are logged in to a desktop session, and
you lock the screen, without logging out?

If yes, then that's gnome-shell, not gdm3 (gdm3's only involvement in
that situation is that its non-GUI part is used to check your password).

smcv

Bug#1005190: gbp dch: add trailing dot when updating changelog

[Guido Günther]

Hi,
On Fri, Mar 03, 2023 at 12:16:27AM -0800, Otto Kekäläinen wrote:
> Hi!
> 
> To summarize here:
> 
> - Good git commit message titles should NOT end with a dot. Titles

I think there's consensus about that.

> (and e.g. subject lines in an email) should not end with a dot based
> on general English grammar rules and also software development / git
> conventions as long as we have had patches and git commits.
> 
> - By convention, many people use full sentences in changelogs (as
> pointed out by e.g. Mattia in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959665). In a
> changelog it makes sense to have full sentences if the texts are
> longer. This is also what English grammar rules say: a (bullet point)
> list with just titles are not sentences and have no trailing dot, but
> if the list has longer and *some* items that are sentences, then all
> items in the list should end with a dot.

I think the reason this is not moving forward is that people have different
preferences. "English grammar rule" seems to be interpreted differently
e.g. by the Imperial college for their brand:

  
https://www.imperial.ac.uk/brand-style-guide/writing/grammar/punctuation/bullet-points/

which would only use fulls top if there's an introductory sentence (which
isn't usually the case for changelogs). And there's other recommendation
all around.

I think a good way to move this forward is to at least have a
recommendation in the developers reference (if not in policy itself) as
everyone can already have the changelog configured by `gbp dch` as they
see fit (via a customization-file) already.

> Therefore, can we please make sure that Lintian-brush and things that
> do git commits do NOT add trailing space, and that tools that write
> changelogs add trailing dots when needed?

Note that 'gbp dch' already figures out if a dot is needed based on the
commit body for *multiline* git commit messages. So the simplest thing
would be to add yet another option that (optionally) does that for one
line changelog messages as well which would break down the debate to
what is the right default (for which developer reference and policy are
usually strong indicators). I've added a note along those lines to
#959665.

Cheers,
 -- Guido

Bug#1032304: RM: anbox -- ROM; Upstream discontinued

[Shengjing Zhu]

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


As stated in https://github.com/anbox/anbox/pull/2121 this project is no
longer maintained.

Bug#959665: git-buildpackage: please put a full stop after "New upstrem version X."

[Guido Günther]

Hi,
On Mon, May 11, 2020 at 12:08:30PM +0200, Guido Günther wrote:
> Hi,
> On Mon, May 11, 2020 at 11:13:20AM +0200, Matthijs Kooijman wrote:
> > Package: git-buildpackage
> > Followup-For: Bug #959665
> > 
> > Hi,
> > 
> > It does seem that having a full stop at the end of debian/changelogs is
> > conventional. However, this is already easy to configure locally. I had
> > this in my debian/gbp.conf for a long time:
> > 
> >   [import-orig]
> >   import-msg = New upstream release %(version)s.
> > 
> > I've since removed the dot again, since for *git* commit messages, it is
> > conventional to *not* have a full stop at the end of the first line and
> > I kept forgetting to add it for my Debian packages, so now my changelogs
> > also omit the full stop.
> > 
> > Also, it seems that Debian policy does not mention the full stop at all:
> > https://www.debian.org/doc/debian-policy/ch-source.html#debian-changelog-debian-changelog
> > 
> > Anyway, this is already easy to configure, so I wonder if this would be
> > worth changing?
> 
> That's what i'm unsure about too and the reason i was asking for the
> pattern behind this. I'm leaning more to leave things as is for the
> moment too - so thanks for your input!

Note that gbp dch already figures out if a dot is needed based on the
commit body so the git commit message goes without a dot while the
changelog entry gets a dot in multiline messages (See
terminate_first_line_if_needed) if the body starts with a capital letter.

The only thing needed would be to make it act on one line messages at
all - either by adding yet another option or by reaching consensus.
Policy section 4.4. Debian changelog: "debian/changelog" does not
make any recommendations along these lines.

Cheers,
 -- Guido

Bug#1032283: python3-sphinx: sphinx-build ignores virtual env

[Dmitry Shachnev]

Hi Marc!

On Thu, Mar 02, 2023 at 11:21:06PM +0100, Marc Glisse wrote:
> Dear Maintainer,
>
> I used to install tensorflow with pip, and sphinx-build had no trouble
> building my documentation which includes `import tensorflow`.
>
> Since we are not supposed to use pip directly anymore, I created a
> virtual environment, with the option --system-site-packages since I only
> want to add a few things not packaged in Debian, and installed
> tensorflow in it. I now activate the environment, run sphinx-build,
> and... it fails to find tensorflow.
>
> The issue is that sphinx-build starts with #!/usr/bin/python3 , it does
> not use the python3 symlink that the activation added at the beginning
> of PATH, and thus does not look for packages in my active virtual
> environment.

As you noted, /usr/bin/python3 shebang is part of the Debian Python Policy:

https://www.debian.org/doc/packaging-manuals/python-policy/#interpreter-directive-shebang

https://www.debian.org/doc/packaging-manuals/python-policy/#interpreter-location

> I have many possible workarounds:
> * execute python3 -m sphinx.cmd.build
> * execute python3 /usr/bin/sphinx-build
> * export a PYTHONPATH pointing to the virtual environment
> * install another copy of sphinx in the virtual environment
> etc

I would just install another copy of Sphinx in a virtualenv. This will also
help pip to make sure all packages are compatible with each other.

I don't think your use case deserves changing the policy, but it's better to
discuss it on debian-python, maybe there are other opinions.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1032293: debian-timeline: validation errors in timeline.debian.net

[Laura Arjona Reina]

Hello again

I have committed the changes and later removed the DOCTYPE declaration, 
and it seems all the validation erros have been gone, except the one 
about the DOCTYPE declaration.


I don't know which DOCTYPE is the best one to use with the timeline.
I've had searched for info in
http://simile-widgets.org/timeline/
https://github.com/simile-widgets/timeline/
https://groups.google.com/g/simile-widgets
and I guess we can use  but we would need to make some 
adjustments to correctly load the xml files with the events, releases 
and release eras.


I'll continue working on this.

Kind regards,

El 3/3/23 a las 9:09, Laura Arjona Reina escribió:

Package: debian-timeline
Version: 45
Followup-For: Bug #1032293

Hello, I have tried to fix the validation errors with commit
8d6c753ecb6be22915a9c8430b3db50ec1a566a3 (patch attached), but deploying 
it in

timeline.debian.net resulted in the headers and footers of the page being
rendered, but not the actual body with the timeline of events (i.e. the 
same

result than installing the package locally (bugs #1032166 and maybe #655664
(this time in Firefox too)) . So I guess more fixes are needed. I'll try to
work on this.

Kind regards



--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#1032303: RM: odoo-14 -- ROM; 14.x can't work in testing/unstable

[Sebastien Delafond]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: o...@packages.debian.org
Control: affects -1 + src:odoo

As per #1032300, odoo-14 doesn't work in testing/unstable. 14.x is not
maintained anymore, 16.x will be uploaded to unstable once bookworm is
released, and later pushed to bookworm-backports, so there is no point
in having odoo-14 in bookworm at all.

Cheers,

-- 
Seb

Bug#1032047: mariadb-server: Preinst fails if user has mariadb running while system service stopped.

[Steven De Herdt]

Small addendum: I'm running Debian testing.

Bug#1032302: sbuild: Lintian exit status confusion

[Jakub Wilk]

Package: sbuild
Version: 0.85.0

The following code in Sbuild/Build.pm is for interpreting Lintian exit 
status:


   my $status = $? >> 8;
   my $why = "unknown reason";
   $self->set('Lintian Reason', 'fail') if ($status == 1);
   $why = "runtime error" if ($status == 2);
   $why = "policy violation" if ($status == 1);

This used to match what Lintian did (and what was documented it did); 
but the exist status semantics has been changed in Lintian 2.77.0:


   * Reverse the exit statuses for program errors and policy violations.
 (Re: #709932)

So now when Lintian reports a policy violation, sbuild says it's a 
runtime error, and other way round.


--
Jakub Wilk

Bug#1029736: Odoo-14 fails to start

[Sébastien Delafond]

On Thu, Mar 02 2023, Glenn wrote:
> I think this bug could be more serious than wishlist, as the server
> doesnt start, for me at least.
>
> When trying to start it with the same line from its init file, it
> concludes with the error; No module named 'PyPDF2.utils'

Hi Glenn,

the bug you're hitting is actually #1032300.

Cheers,

-- 
Seb

Bug#1032301: The KDE Plasma Widget is showing the "lo" interface

[only4com]

This is a known upstream bug and has been fixed in Plasma 5.27.1.
We have 5.27.2 in Debian unstable with the fix, that will migrate to testing in 
a couple of days.


Thank you Aurélien!

Sorry for the duplicate.

You guys are fantastic !

Chapeau !

Bug#1032301: The KDE Plasma Widget is showing the "lo" interface

[Aurélien COUDERC]

control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=465655
control: fixed -1 4:5.27.2-1

Dear only4com,


Le 3 mars 2023 10:12:19 GMT+01:00, only4com  a écrit :
>Package: plasma-nm
>Version: 4:5.27.0-1
>
>Dear Maintainer
>
>the Plasma Widget Networks has started to show also the "lo" interface, which 
>is confusing (with a button to disable it, which obviously is no possible).

This is a known upstream bug and has been fixed in Plasma 5.27.1.
We have 5.27.2 in Debian unstable with the fix, that will migrate to testing in 
a couple of days.


Happy hacking,
--
Aurélien

Bug#1018023: Update on this bug?

[Matthew Vernon]

Hi,

On 14/02/2023 18:36, Jose Antonio Jimenez Madrid wrote:


I will test this patch and let you to know whether the bug is fixed.


Any joy? We're approaching the time that eterm is going to be 
autoremoved from bookworm...


Thanks,

Matthew

Bug#1032301: The KDE Plasma Widget is showing the "lo" interface

[only4com]

Package: plasma-nm
Version: 4:5.27.0-1

Debian distribution: bookworm

$ uname -a
Linux linbox 6.1.0-5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1 (2023-02-15) 
x86_64 GNU/Linux

libc-bin Version: 2.36-8

KDE Plasma Version: 5.26.90
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-5-amd64 (64-bit)
Graphics Platform: Wayland



Dear Maintainer

the Plasma Widget Networks has started to show also the "lo" interface, which 
is confusing (with a button to disable it, which obviously is no possible).

Thank you

Bug#1032300: odoo-14: Not functional with pypdf2 2.x

[Sebastien Delafond]

Package: odoo-14
Version: 14.0.0+dfsg.4-1
Severity: grave

odoo 14.x is not compatible with pypdf2 2.x, and the server cannot be
started:

  ModuleNotFoundError: No module named 'PyPDF2.utils'

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

Kernel: Linux 6.1.0-5-amd64 (SMP w/36 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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages odoo-14 depends on:
ii  adduser 3.131
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  fonts-glyphicons-halflings  1.009~3.4.1+dfsg-3
pn  fonts-inconsolata   
ii  fonts-roboto-unhinted   2:0~20170802-3
ii  init-system-helpers 1.65.2
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libjs-underscore1.13.4~dfsg+~1.11.4-3
ii  lsb-base11.6
pn  postgresql-client   
ii  python3 3.11.2-1
ii  python3-babel   2.10.3-1
ii  python3-chardet 5.1.0+dfsg-2
ii  python3-dateutil2.8.2-1
ii  python3-decorator   5.1.1-3
ii  python3-docutils0.19+dfsg-6
ii  python3-feedparser  6.0.10-1
pn  python3-freezegun   
pn  python3-gevent  
ii  python3-html2text   2020.1.16-2
ii  python3-idna3.3-1
ii  python3-jinja2  3.0.3-2
pn  python3-libsass 
ii  python3-lxml4.9.2-1+b1
pn  python3-mako
ii  python3-mock4.0.3-4
pn  python3-num2words   
ii  python3-ofxparse0.21-2
ii  python3-passlib 1.7.4-3
ii  python3-pil 9.4.0-1.1+b1
pn  python3-polib   
ii  python3-psutil  5.9.4-1+b1
ii  python3-psycopg22.9.5-1+b1
pn  python3-pydot   
ii  python3-pyparsing   3.0.9-1
ii  python3-pypdf2  2.12.1-3
pn  python3-qrcode  
ii  python3-renderpm3.6.12-1+b1
ii  python3-reportlab   3.6.12-1
ii  python3-requests2.28.1+dfsg-1
pn  python3-serial  
pn  python3-stdnum  
pn  python3-suds
ii  python3-tz  2022.7.1-1
pn  python3-usb 
ii  python3-vobject 0.9.6.1-2
ii  python3-werkzeug2.2.2-2
pn  python3-xlrd
pn  python3-xlsxwriter  
pn  python3-xlwt
pn  python3-zeep
ii  sysvinit-utils [lsb-base]   3.06-2
ii  wkhtmltopdf 0.12.6-2+b1

Versions of packages odoo-14 recommends:
pn  postgresql
pn  python3-ldap  

odoo-14 suggests no packages.

Bug#1032299: bullseye-pu: package node-css-what/4.0.0-3

[Bastien Roucariès]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: node-css-w...@packages.debian.org
Control: affects -1 + src:node-css-what

[ Reason ]
CVE-2022-21222/CVE-2021-33587 The package css-what before 2.1.3 are vulnerable
to Regular Expression Denial of Service (ReDoS) due to the usage of insecure
regular expression in the re_attr variable of index.js. The exploitation of
this vulnerability could be triggered via the parse function.

[ Impact ]
DoS due to exponential regexp search.

[ Tests ]
Package testsuite was run, code modification was tested.
recheck tested the absence of reDos

[ Risks ]
* no backport is possible due to upstream rewrite in typescript. Modification
of the regex was chosen in order to be least disruptive.

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

[ Changes ]
The ReDoS sensible regexp was rewritten in a linear form, step by step (5
patches).

[ Other info ]
None
diff -Nru node-css-what-4.0.0/debian/changelog 
node-css-what-4.0.0/debian/changelog
--- node-css-what-4.0.0/debian/changelog2021-01-09 21:06:15.0 
+
+++ node-css-what-4.0.0/debian/changelog2023-03-01 13:47:23.0 
+
@@ -1,3 +1,15 @@
+node-css-what (4.0.0-3+deb11u1) bullseye-security; urgency=medium
+
+  * Team upload
+  * node-css-what was vulnerable to Regular Expression Denial of Service
+(ReDoS) due to the usage of insecure regular expression in the
+re_attr variable.
+The exploitation of this vulnerability could be triggered
+via the parse function.
+Fix CVE-2022-21222, CVE-2021-33587 (Closes: #989264, #1032188)
+
+ -- Bastien Roucariès   Wed, 01 Mar 2023 13:47:23 +
+
 node-css-what (4.0.0-3) unstable; urgency=medium
 
   * Team upload
diff -Nru 
node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
 
node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
--- 
node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
  1970-01-01 00:00:00.0 +
+++ 
node-css-what-4.0.0/debian/patches/0001-Partial-fix-of-reDos-CVE-2022-21222-CVE-2021-33587-a.patch
  2023-03-01 13:47:23.0 +
@@ -0,0 +1,36 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 08:12:48 +
+Subject: Partial fix of reDos CVE-2022-21222/CVE-2021-33587: attribute
+ selector
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Per https://w3c.github.io/csswg-drafts/selectors/#attribute-selectors only = 
~= |= ^= $= *= are supported.
+
+Add also != that is checked as invalid latter in order to pass testsuite.
+
+So replace \S by [~|^$*!]
+
+Signed-off-by: Bastien Roucariès 
+bug-debian: https://bugs.debian.org/989264
+bug-debian: https://bugs.debian.org/1032188
+bug: https://www.cve.org/CVERecord?id=CVE-2022-21222
+bug: https://www.cve.org/CVERecord?id=CVE-2021-33587
+---
+ src/parse.ts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/parse.ts b/src/parse.ts
+index 677a029..628561b 100644
+--- a/src/parse.ts
 b/src/parse.ts
+@@ -81,7 +81,7 @@ export type TraversalType =
+ const reName = /^[^\\#]?(?:\\(?:[\da-f]{1,6}\s?|.)|[\w\-\u00b0-\u])+/;
+ const reEscape = /\\([\da-f]{1,6}\s?|(\s)|.)/gi;
+ // Modified version of 
https://github.com/jquery/sizzle/blob/master/src/sizzle.js#L87
+-const reAttr = 
/^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:(\S?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
++const reAttr = 
/^\s*(?:(\*|[-\w]*)\|)?((?:\\.|[\w\u00b0-\u-])+)\s*(?:([~|^$*!]?)=\s*(?:(['"])((?:[^\\]|\\[^])*?)\4|(#?(?:\\.|[\w\u00b0-\u-])*)|)|)\s*([iI])?\]/;
+ 
+ const actionTypes: { [key: string]: AttributeAction } = {
+ undefined: "exists",
diff -Nru 
node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
 
node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
--- 
node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
  1970-01-01 00:00:00.0 +
+++ 
node-css-what-4.0.0/debian/patches/0002-Partial-fix-of-ReDos-CVE-2022-21222-CVE-2021-33587-t.patch
  2023-03-01 13:47:23.0 +
@@ -0,0 +1,55 @@
+From: =?utf-8?q?Bastien_Roucari=C3=A8s?= 
+Date: Wed, 1 Mar 2023 10:10:47 +
+Subject: Partial fix of ReDos CVE-2022-21222/CVE-2021-33587: trim string
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+Trim left the string avoiding a \s* at the beginning of the string, thus 
avoiding part of complexity.
+
+bug-debian: https://bugs.debian.org/989264
+bug-debian: