Bug#1032104: linux: ppc64el iouring corrupted read

[Otto Kekäläinen]

Any updates on this one?

I am still seeing the main.index_merge_innodb failure in
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=ppc64el&ver=1%3A10.11.2-2%7Eexp1&stamp=1678728871&raw=0
and rebuild 
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=ppc64el&ver=1%3A10.11.2-2%7Eexp1&stamp=1679174850&raw=0.

Logs show: Kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian
5.10.162-1 (2023-01-21) ppc64el (ppc64le)

Bug#918681: A initramfs boot script that wait lvmraid become complete for root device

[gold holk]

Sorry, a bug in script about prereq

gold holk 於 2023/3/19 14:01 寫道:

Hey Paul and LVM team:

I faced this issue and manage to write a initramfs-tool boot script to 
fix this.


Put the enclosure script in `/etc/initramfs-tools/scripts/local-top` 
and run `update-initramfs -k all -u`, the initramfs boot stage will 
run this script and wait for the root device becoming `complete` 
status. If it does not complete in 2 minutes, it will stop waiting and 
continue boot.


To write or debug the initramfs script, the `initramfs-tools(7)` would 
be helpful.


As my realization, to fix this issue in lvm2 package, we should make 
`/usr/share/initramfs-tools/scripts/local-top/lvm2` check the status 
of the activated LV. Please tell me if I can help to merge my script 
into the existing lvm2 initramfs script.


I am new to debian community. This is the first time I write a 
initramfs-script, though I am already experienced in normal  shell 
script.


I also asked and answered this issue on stack-exchange community; it 
may be helpful if you want to know more details:
tabopen 
https://superuser.com/questions/1773241/raid-1-lv-partially-up-and-unable-to-repair-the-down-rimage-is-missing


May the source be with you


--
linux user, amateur web developer, geomatics major.
blog: http://gholk.github.io


initramfs-lvm-raid-wait.sh
Description: application/shellscript

Bug#918681: A initramfs boot script that wait lvmraid become complete for root device

[gold holk]

Hey Paul and LVM team:

I faced this issue and manage to write a initramfs-tool boot script to 
fix this.


Put the enclosure script in `/etc/initramfs-tools/scripts/local-top` and 
run `update-initramfs -k all -u`, the initramfs boot stage will run this 
script and wait for the root device becoming `complete` status. If it 
does not complete in 2 minutes, it will stop waiting and continue boot.


To write or debug the initramfs script, the `initramfs-tools(7)` would 
be helpful.


As my realization, to fix this issue in lvm2 package, we should make 
`/usr/share/initramfs-tools/scripts/local-top/lvm2` check the status of 
the activated LV. Please tell me if I can help to merge my script into 
the existing lvm2 initramfs script.


I am new to debian community. This is the first time I write a 
initramfs-script, though I am already experienced in normal  shell script.


I also asked and answered this issue on stack-exchange community; it may 
be helpful if you want to know more details:
tabopen 
https://superuser.com/questions/1773241/raid-1-lv-partially-up-and-unable-to-repair-the-down-rimage-is-missing


May the source be with you

--
linux user, amateur web developer, geomatics major.
blog: http://gholk.github.io


initramfs-lvm-raid-wait.sh
Description: application/shellscript

Bug#1033175: FTBFS: setup.py install is deprecated

[Vincent Cheng]

Control: notfound -1 0.0.26-3
Control: close -1

On Sat, Mar 18, 2023 at 4:48 PM David W. Kennedy  wrote:
>
> Package: 0ad
> Version: 0.0.26-3
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the
> past)
> X-Debbugs-Cc: dav...@reasoned.us
>
> Hello,
>
> When I try to build 0ad version 0.0.26-3 in Debian unstable with
> python3.11 and python3-virtualenv, build fails.
>
> I think that the key error message is
> "/usr/lib/python3/dist-packages/setuptools/command/install.py:34:
> SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build
> and pip and other standards-based tools."
>
> The commands that I use to build the package:
>
> # apt-get update
> # apt-get build-dep 0ad
> $ apt-get source 0ad
> $ cd 0ad-0.0.26
> $ debuild

0ad/0.0.26-3 builds fine for me with an up-to-date pbuilder sid
chroot. I highly recommend building packages in a clean chroot
environment, using tools such as pbuilder or sbuild. Packages failing
to build from source in a dirty environment is not a RC bug and I
can't really help you debug why it's not working in your particular
environment.

Regards,
Vincent

Bug#1033184: AnyMeal: The desktop file is missing an additional category 'Viewer'

[Joerg Schiermeier, Bielefeld/Germany]

Package: anymeal
Version: 1.18-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

The desktop file for Linux/Debian 
(/usr/share/applications/de.wedesoft.anymeal.desktop) is missing the additional 
category: 'Viewer'.

For further information please see the documentation about desktop files here:


As a viwer for recipes this additional category should be added.

- --
Yours sincerely
Joerg Schiermeier



- -- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB:es
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages anymeal depends on:
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libqt5core5a 5.15.8+dfsg-3
ii  libqt5gui5   5.15.8+dfsg-3
ii  libqt5printsupport5  5.15.8+dfsg-3
ii  libqt5widgets5   5.15.8+dfsg-3
ii  librecode0   3.6-25
ii  libsqlite3-0 3.40.1-2
ii  libstdc++6   12.2.0-14

anymeal recommends no packages.

anymeal suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Comment: This was created by GnuPG for Linux.

iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAmQWepoACgkQodFQ9YsO
8GMCpQ//SLObrccAKd3QB/Xeg0o5suFhUzjfq44fhCcUtBD4zCLcCtzl1d+8frHU
Qt9mSgEH77F6RYSy1cUVUn3rV2q7tfnoA/h6OT61LNpVtGY6evj24lYTWTt9CzA/
K7B3oZKSxBBXcgVNDuHW0n/rGZCxtrZfXzMtW+UhWwmWqIG+Y8o5tMXcfVw2NaNX
iNKKI/0S9idi2hRMCuGgRsH79IO03Kolqg1U3+KASWoMxEo5RI5vuZrnFaSLdr/r
dCsbHFTHc+dUdRMu6N0eXlqEaepFFn5KNiLfVKYW7PqKTe901qwrzHgGhooONZqV
vDv+L11h4ssFCXnmMOxjgna7OjsNv/Y38I5E1aaujdjIJOhZeHGWRaLmJV7Yp89x
yXjUhjUIS+O1LMZnqtUepV9CNQn0gB3lkhasZzyuFoLVK5LYTYBC/6jo0vlArOU2
x+p4GWtYIQ05+S2uPTGpn32/lzXxRIZp9Tj/eElERoCWu8TyV4oGBwTUoYVTvKWU
D8txPQtqRhGOY81kP6um7E/GGeyhDPz3gIr+FZqBmQTwl22sDAYmBlqEBWGKIgzC
U8v/d/lQbu8LGzcCgv3foGsAu6KcJRLEfYmCIk6/OepbNXyOL6cz1MtHtlM+ZAZx
X1MdB20bIJHrWZsvJVg3NGCW5cStTjVDkld70Ql1/H8yzHEbDmA=
=3NDi
-END PGP SIGNATURE-

Bug#1032480: xen: Important cherry-picks for bookworm/updates

[Elliott Mitchell]

On Tue, Mar 07, 2023 at 01:13:56PM -0800, Elliott Mitchell wrote:
> 
> ad15a0a8ca2515d8ac58edfc0bc1d3719219cb77
> x86/time: prevent overflow with high frequency TSCs

Okay, looks like this one had already been grabbed.  Sorry for the way
too late alert.  Thanks for staying on top of what was happening with
upstream Xen.


> I haven't found a patch for the other one yet.  There is some issue with
> the latest generation which needs "x2apic=false" on Xen's command-line
> in order to get interrupts to domain 0.  I'm guessing the latest from AMD
> broke the PIC emulation.
> 
> If this isn't actually patched yet, I suspect it soon will be.  I haven't
> observed anything on xen-devel, so perhaps the workaround was found too
> quickly to get noticed as urgent.

This one though looks potentially more and less serious.  The workaround
is simpler than the above ("x2apic=false" on Xen's command-line, instead
of "tsc_mode = 1" for *every* VM).  Yet the underlying problem could be
more severe.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#1033183: ERROR: Unable to extract uploader id

[James Connolly]

Package: youtube-dl
Version: 2021.06.06-1
Severity: important
X-Debbugs-Cc: jconnolly...@gmail.com

Dear Maintainer,

Debian Stable keeps a very outdated version of youtube-dl which no longer works 
because Youtube has changed, leaving youtube-dl dysfunctional. I believe this 
is one of those cases where the package in Stable needs to be upgraded, 
otherwise the program remains dysfunctional and the user has to take the 
situation into their own hands and upgrade the program manually, defeating the 
purpose of a package.

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

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

Versions of packages youtube-dl depends on:
ii  python33.9.2-3
ii  python3-pkg-resources  52.0.0-4

Versions of packages youtube-dl recommends:
ii  ca-certificates  20210119
ii  ffmpeg   7:4.3.5-0+deb11u1
ii  mpv  0.32.0-3
ii  python3-pyxattr  0.7.2-1+b1
ii  rtmpdump 2.4+20151223.gitfa8646d.1-2+b2
ii  wget 1.21-1+deb11u1

Versions of packages youtube-dl suggests:
pn  libfribidi-bin | bidiv  
pn  phantomjs   

-- no debconf information

Bug#1033097: im-config: Fcitx5 does not start automatically in KDE plasma Wayland

[Gunnar Hjalmarsson]

Submitted an im-config merge request:

https://salsa.debian.org/input-method-team/im-config/-/merge_requests/18

Feedback welcome!

Bug#1033182: TuxCommander: The tuxcmd.desktop file is missing an additional category 'Core'

[Joerg Schiermeier, Bielefeld/Germany]

Package: tuxcmd
Version: 0.6.70+dfsg-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello!

The desktop file for Linux/Debian (/usr/share/applications/tuxcmd.desktop) is 
missing the additional category: 'Core'.
Alternativly possible may be the category 'FileManager'.

For further information please see the documentation about desktop files here:


As a file manager one of this additional category should be added. I recommend 
'Core' more than 'FileManger'.

- --
Yours sincerely
Joerg Schiermeier



- -- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB:es
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages tuxcmd depends on:
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-1
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.50.12+ds-1

tuxcmd recommends no packages.

Versions of packages tuxcmd suggests:
pn  tuxcmd-modules  

- -- no debconf information

-BEGIN PGP SIGNATURE-
Comment: This was created by GnuPG for Linux.

iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAmQWc98ACgkQodFQ9YsO
8GN2xw/+NetHK1PxPJ7+CTg7E4DgoU7vYmuj/+uwN9Ro8W4qfSOSKDQL8m9RnfY+
sbcHJYkmidscUP5/dvcVFXxge18RjrvKD8bIXbnKONOL+L3Tc5tmK9rkY9n/j7rS
C+V9STaejv6g75QwB0TDZzDHSsW7VBF5HFsDzdtsoDp8hbSjxlBrVP71qfpFW6aw
h/IEPP3AKrOkb90hd3oiOywPn4NNBfZeRbENz8Lw0VTJC551lBtEeIYY+e7BGJ15
jWhqbSoyMivaz6xr8HjU15qFANpuAr/k+TLHkz/rOYareI2jEjUFlg404IZLLNk7
MT6/kQM22mIkHnJ0De2wpQj3gu3ylAxKikdVtzFes+f0TlKN5Wf/9F78v9e5KfxP
atbkxzQHuVH0pDgJNl+yCi9h4tAOiiv6GryT/3xk2IN3a3NJMXMS1vWIUfB134hc
ZM3OqkBCbc8NaaGR6+cVLRuZe0EMNcDj52DxdFxegbYTh83+snyJsBVoVK0cnj3Z
5VHYRi0mDhGhTWXpk3CWW6cgbsqeP257ui0ocB/wKsdvKbl5ykubkYDcG3rP+BIY
KUmeI5Gp23mLVIL54N1j0inu3tG9YOzjwzqp14IhMf+MIsYYkIEMEwaMSu6QIJwq
WbpWus4/+xjLXfOrI14/dUx6e3XHx8UVF4Fnvob0AQXaZM4bzEA=
=C9/x
-END PGP SIGNATURE-

Bug#1033181: dwww: The dwww.desktop file is missing an additinal category

[Joerg Schiermeier, Bielefeld/Germany]

Package: dwww
Version: 1.15
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Hello!

The desktop file for Linux/Debian (/usr/share/applications/dwww.desktop) is 
missing the additional category: 'Core'

For further information please see the documentation about desktop files here:


As a help browser this additional category should be added.

- --
Yours sincerely
Joerg Schiermeier



- -- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB:es
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages dwww depends on:
ii  apache2 [httpd-cgi] 2.4.56-1
ii  debconf [debconf-2.0]   1.5.82
ii  debianutils 5.7-0.4
ii  doc-base0.11.1
ii  file1:5.44-3
ii  libc6   2.36-8
ii  libfile-ncopy-perl  0.36-3
ii  libmime-types-perl  2.24-1
ii  lighttpd [httpd-cgi]1.4.69-1
ii  man-db  2.11.2-2
ii  mini-httpd [httpd-cgi]  1.30-3
ii  nginx [httpd-cgi]   1.22.1-9
ii  perl5.36.0-7
ii  sensible-utils  0.0.17+nmu1
ii  ucf 3.0043+nmu1

Versions of packages dwww recommends:
ii  apache2 [httpd] 2.4.56-1
ii  apt 2.5.6devuan1
ii  dlocate 1.12
ii  info2www1.2.2.9-24.2
ii  lighttpd [httpd]1.4.69-1
ii  mini-httpd [httpd]  1.30-3
ii  nginx [httpd]   1.22.1-9
ii  swish++ 6.1.5-6

Versions of packages dwww suggests:
ii  brave-browser [www-browser]1.49.120
ii  chromium [www-browser] 111.0.5563.64-1
ii  dillo [www-browser]3.0.5-7+b1
ii  doc-debian 6.5
pn  dpkg-www   
ii  edbrowse [www-browser] 3.7.7-5
ii  elinks [www-browser]   0.13.2-1+b4
ii  falkon [www-browser]   22.12.1-2
ii  firefox [www-browser]  110.0.1-1
ii  konqueror [www-browser]4:22.12.3-1
ii  librewolf [www-browser]111.0-3
ii  luakit [www-browser]   1:2.3.3-1
ii  lynx [www-browser] 2.9.0dev.12-1
ii  netsurf-fb [www-browser]   3.10-1+b3
ii  netsurf-gtk [www-browser]  3.10-1+b3
ii  opera-legacy [www-browser] 12.16.1860-2
ii  opera-stable [www-browser] 96.0.4693.80
ii  qutebrowser [www-browser]  2.5.3-1
ii  vivaldi-stable [www-browser]   5.7.2921.63-1
ii  w3m [www-browser]  0.5.3+git20230121-2
ii  yandex-browser-beta [www-browser]  22.1.3.907-1

- -- debconf information:
  dwww/nosuchdir:
* dwww/serverport: 80
* dwww/docrootdir: /var/www
* dwww/cgiuser: www-data
  dwww/index_docs: false
* dwww/cgidir: /usr/lib/cgi-bin
  dwww/nosuchuser:
* dwww/servername: Archimedes.fritz.box
  dwww/badport:


-BEGIN PGP SIGNATURE-
Comment: This was created by GnuPG for Linux.

iQIzBAEBCAAdFiEERMHJSMoKBiNrvtXJodFQ9YsO8GMFAmQWcmkACgkQodFQ9YsO
8GOKbRAAne8b6OH6oPEtOicx8znpGGP6vDOCaI14GeX7bSXfhjkq0xxj+BtF+IXt
CgRk5/uZJ2prtKpg85yxlIVwfY6fQmGoY6kAriW1AewRYH5nHmaxZyMAoMXudGe2
4xjANYgAfGq8gmTJGMPxRvxLXWlI6BVV86nHIurXVaSvqQLAYpjHJfPe7fh4FGFK
6RwDEkspePWoYBa2G3z4lEz4rR4K2gPDS9Fm4vMOhfIxnZ8ds7QyXuHPWmmiQKDy
5WctxQcrIAcdDIYFgbdp9HUlAPF2QanCv2d0hRkZr2p7r/YbQ1S4D6Xew/upmM43
1ul2bf6brc9Xh78+qAbrz2pyCmfWeQ1lff7edxmAhzMfw5oxM5qV1Yivs27ILi/U
RVn3Lsvky1+BXV/vU+Dn8ii0SYKN111eJrj9q4SM8ccQ8fXdNRL0DvAMOJDj+53X
1BwO2jqVOtH6ZQleWBep5q2ZMp9KsXAHYLaWB/E/W7FCBTiVsonYxEKGi7OolACw
x3ERv9CPP7Rq4Nw5AxAREHrQQksWPNm2miNfYjEcZc2cujye5ZUnRNoAioNHHCQj
4F0xMJURA/r/b0tvL4YDz0hpoBdg6tZVJ1cSc6Z02Bbu29cogTss1/1mQLSN5Rho
4ML3pFfZDsV1bpKIKp7S6LEDTxPm7Cs7RZNPfmc9QyCiPp4MOUQ=
=ZoNJ
-END PGP SIGNATURE-

Bug#778849: Support restoring initrd on shutdown and pivoting into it

[Gervase]

The following initrd info may or may not be pertinent to this bug in
respect to how initrds may be created in future versions of Debian...

> To: debian-de...@lists.debian.org
> Cc: debian-de...@lists.debian.org
> Subject: Re: Unlock LUKS with login/password
> From: Marco d'Itri 
> Date: Fri, 10 Mar 2023 17:57:40 +0100

> On Mar 10, Stephan Verbücheln  wrote:
> 
> > On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:
> > > In the future the initramfs will (usually) be static as well.
> > Can you provide more information on that?
> Due to multiple reasons, mostly related to secure boot and boot 
> attestation, there is significant interest by distributions in
> providing 
> static and signed initrds.
> BTW, I have been informed that "initramfs" is an obsolete term and
> that 
> we are back to "initrd" like in the '90s.
> 
> Some people in Debian are interested in working on 
> https://github.com/systemd/mkosi-initrd, which will provide a static 
> initrd built from system binaries and extensible using the 
> systemd-sysext and future systemd-sysconf mechanisms for things like 
> SAN boot or sshd in the initrd.
> Do not look too hard at it at this point: the upstream developers are 
> going to make soon a new release with significant changes.
> 
> I expect that people interested in working on initramfs-tools can 
> probably extend it with little work to generate static images
> suitable 
> for the most common deployments.
> People with uncommon ones will have to do without the modern boot 
> attestation features or else sign their own images (which will be
> very 
> easy once I, or somebody else, will have packaged sbctl).
> Obviously there are no new requirements for the systems without
> secure 
> boot.
> 
> -- 
> ciao,
> Marco
> 

Bug#1033167: usrmerge: messes with /etc/shells

[Marco d'Itri]

On Mar 18, Helmut Grohne  wrote:

> I think that it is quite obvious that /etc/shells is debianutils'
> territory. When I found that on some systems /etc/shells was out of sync
> with /var/lib/shells.state, I was quite puzzled until I noticed that
> usrmerge messes with this file. This really is debianutils'
It is expected that /etc/shells can be edited by system administrators, 
I have been doing that forever in my career as a professional system 
administrator and until now I was not even aware of these programs from 
debianutils.
Hence my reasoning that having convert-etc-shells modify the file would 
not be harmful, and so far I am not aware of any practical problem that 
this has ever caused.

I also see that you wrote update-shells in 2021, but convert-etc-shells 
was added to usrmerge in 2016.

> If and only if usrmerge is used, convert-etc-shells turns /bin/sh into
> /usr/bin/sh. So whenever we start out merged and use usr-is-merged,
> /usr/bin/sh goes missing.
Right. But both update-shells and usr-is-merged are new to bookworm, and 
I remember that having the /usr/ paths in /etc/shells is not usually 
needed, so this explains why nobody has reported actual problems so far.

> I think the best solution here would be merging convert-etc-shells into
> update-shells.
No objections if you can do the work, I will not miss it.

> Whenever we run update-shells, it should check whether
> the system is already merged and when it is, perform the equivalent to
> convert-etc-shells. Then usrmerge can just install an empty (except for
> a comment) /usr/share/debianutils/shells.d/usrmerge to trigger
> update-shells and things become fully reproducible in all cases, because
OK.

(Also, would you mind moving /var/lib/shells.state to /var/lib/misc/?)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1033180: unblock: stayrtr/0.5.1-1

[Marco d'Itri]

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

Please unblock package stayrtr

The new upstream release contains only an important bug fix, needed to 
stop the daemon from crashing in specific conditions.
(This is the upstream bug report of a Debian user who was stuck with the 
version in testing: https://github.com/bgp/stayrtr/issues/96.)

diff attached, edited for clarity.

unblock stayrtr/0.5.1-1

-- 
ciao,
Marco
diff -Nru stayrtr-0.5.0/cmd/stayrtr/stayrtr.go 
stayrtr-0.5.1/cmd/stayrtr/stayrtr.go
--- stayrtr-0.5.0/cmd/stayrtr/stayrtr.go2023-02-23 22:35:40.0 
+0100
+++ stayrtr-0.5.1/cmd/stayrtr/stayrtr.go2023-03-01 15:36:19.0 
+0100
@@ -261,6 +261,38 @@
vrplist = append(vrplist, vrp)
}
 
+   sort.Slice(vrplist, func(i, j int) bool {
+   // Sort VRPs as per draft-ietf-sidrops-8210bis-10
+   /*
+   11. ROA PDU Race Minimization
+   When a cache is sending ROA (IPv4 or IPv6) PDUs 
to a router, especially an initial
+   full load in response to a Reset Query PDU, two 
undesirable race conditions are possible:
+
+   Break Before Make:
+   For some prefix P, an AS may announce two (or 
more) ROAs because they are in the
+   process of changing what provider AS is 
announcing P. This is a case of "make before break."
+   If a cache is feeding a router and sends the 
one not yet in service a significant time
+   before sending the one currently in service, 
then BGP data could be marked invalid during
+   the interval. To minimize that interval, the 
cache SHOULD announce all ROAs for the same
+   prefix as close to sequentially as possible.
+   Shorter Prefix First:
+   If an AS has issued a ROA for P0, and another 
AS (likely their customer) has issued a ROA
+   for P1 which is a sub-prefix of P0, a router 
which receives the ROA for P0 before that for
+   P1 is likely to mark a BGP prefix P1 invalid. 
Therefore, the cache SHOULD announce the
+   sub-prefix P1 before the covering prefix P0.
+   */
+   CIDRSizei, _ := vrplist[i].Prefix.Mask.Size()
+   CIDRSizej, _ := vrplist[j].Prefix.Mask.Size()
+   if CIDRSizei == CIDRSizej {
+   if vrplist[i].MaxLen != vrplist[j].MaxLen {
+   return vrplist[i].MaxLen > vrplist[j].MaxLen
+   }
+   return bytes.Compare(vrplist[i].Prefix.IP, 
vrplist[j].Prefix.IP) < 1
+   } else {
+   return CIDRSizei > CIDRSizej
+   }
+   })
+
for _, v := range brklistjson {
if v.Expires != nil {
// Prevent stale VRPs from being considered
@@ -299,7 +331,7 @@
}
 
// Ensure that these are sorted, otherwise they
-   // don't has right.
+   // don't hash right.
sort.Slice(v.Providers, func(i, j int) bool {
return v.Providers[i] < v.Providers[j]
})
diff -Nru stayrtr-0.5.0/cmd/stayrtr/stayrtr_test.go 
stayrtr-0.5.1/cmd/stayrtr/stayrtr_test.go
--- stayrtr-0.5.0/cmd/stayrtr/stayrtr_test.go   2023-02-23 22:35:40.0 
+0100
+++ stayrtr-0.5.1/cmd/stayrtr/stayrtr_test.go   2023-03-01 15:36:19.0 
+0100
@@ -103,11 +103,6 @@
got, _, _, count, v4count, v6count := processData(stuff, nil, nil)
want := []rtr.VRP{
{
-   Prefix: mustParseIPNet("192.168.0.0/24"),
-   MaxLen: 24,
-   ASN:123,
-   },
-   {
Prefix: mustParseIPNet("2001:db8::/32"),
MaxLen: 33,
ASN:123,
@@ -117,6 +112,11 @@
MaxLen: 25,
ASN:123,
},
+   {
+   Prefix: mustParseIPNet("192.168.0.0/24"),
+   MaxLen: 24,
+   ASN:123,
+   },
}
if count != 3 || v4count != 2 || v6count != 1 {
t.Errorf("Wanted count = 3, v4count = 2, v6count = 1, but got 
%d, %d, %d", count, v4count, v6count)
diff -Nru stayrtr-0.5.0/debian/changelog stayrtr-0.5.1/debian/changelog
--- stayrtr-0.5.0/debian/changelog  2023-02-27 03:36:29.0 +0100
+++ stayrtr-0.5.1/debian/changelog  2023-03-05 01:11:49.0 +0100
@@ -1,3 +1,9 @@
+

Bug#1033179: [INTL:ro] Romanian debconf templates translation of openvpn

[Remus-Gabriel Chelu]

Package: openvpn
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «openvpn» file.

Thanks,
Remus-Gabriel

openvpn_debconf_ro.po
Description: Binary data

Bug#1033178: [INTL:ro] Romanian debconf templates translation of openssh

[Remus-Gabriel Chelu]

Package: openssh
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «openssh» file.

Thanks,
Remus-Gabriel

openssh_debconf_ro.po
Description: Binary data

Bug#1033177: [INTL:ro] Romanian debconf templates translation of openldap

[Remus-Gabriel Chelu]

Package: openldap
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «openldap» file.

Thanks,
Remus-Gabriel

openldap_debconf_ro.po
Description: Binary data

Bug#1033090: unblock: dhcpdump/1.8-6

[Boian Bonev]

Control: tags -1 - moreinfo

Hi Sebastian,

On Sat, 2023-03-18 at 09:06 +0100, Sebastian Ramacher wrote:


> Unfortunately these fixes come with a complete overhaul of debian/ which
> is no longer appopriate at this point of the freeze. Please upload a new
> version with targetted fixes only.

Thanks!

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

Adam, please sponsor it and add DM rights, if you find appropriate.

Here is my reasoning for the additional changes to the old packaging:

- not installing copyright is a lintian error
- not stripped binary is a lintian error
- dhcpdump runs as root and processes data from the network, building with
hardening flags is essential (IMHO)

I allowed myself to change maintainer and close the ITA, not sure how good is
that at this time. I can easily change it back to a QA upload and postpone for
trixie.

--
With best regards,
b.
diff -Nru dhcpdump-1.8/debian/changelog dhcpdump-1.8/debian/changelog
--- dhcpdump-1.8/debian/changelog	2022-12-05 15:08:35.0 +
+++ dhcpdump-1.8/debian/changelog	2023-03-18 21:43:18.0 +
@@ -1,3 +1,57 @@
+dhcpdump (1.8-7) unstable; urgency=medium
+
+  * Revert all non-targeted changes since 1.8-4
+  * New maintainer (Closes: #934419)
+  * Fix old packaging
+- install copyright
+- hardening flags
+- proper strip
+  * Add 2 missing checks to d/p/dhcpdump-bugfix_strcounts.patch
+
+ -- Boian Bonev   Sat, 18 Mar 2023 21:43:18 +
+
+dhcpdump (1.8-6) unstable; urgency=medium
+
+  * QA upload.
+  * Upload 1.8-5 fixes to unstable.
+
+ -- Adam Borowski   Wed, 08 Mar 2023 17:43:02 +0100
+
+dhcpdump (1.8-5) experimental; urgency=medium
+
+  [ Boian Bonev ]
+  * QA upload.
+  * Install binary and man page.
+  * Add patches that fix:
+- build options in Makefile (hardening and cross)
+- ethertype handling (Closes: #873635)
+- flags calculation
+- opt82 processing
+- counts in string arrays (OOB access)
+- spelling errors
+- wrong description in man page (Closes: #647228)
+  * Do not depend on tcpdump.
+  * Bump standards to 4.6.2, no changes.
+  * Remove unrelated key and override source not signed.
+  * wrap-and-sort
+
+  [ Joao Paulo Lima de Oliveira ]
+  * debian/control:
+- Set Rules-Requires-Root:no.
+- Set homepage-field.
+- Bumped Standards-Version to 4.6.1.
+- Set debhelper-compat version in Build-Depends.
+- Added Depends ${shlibs:Depends} in Depends fields.
+  * debian/rules:
+- Rewrite to use dh-sequencer.
+  * debian/metadata:
+- Added missing upstream metadata.
+- Added upstream's key.
+  * debian/watch:
+- Add watch file.
+
+ -- Boian Bonev   Thu, 23 Feb 2023 08:31:03 +
+
 dhcpdump (1.8-4) unstable; urgency=medium
 
   * QA upload.
diff -Nru dhcpdump-1.8/debian/control dhcpdump-1.8/debian/control
--- dhcpdump-1.8/debian/control	2022-12-05 15:08:35.0 +
+++ dhcpdump-1.8/debian/control	2023-03-18 21:43:18.0 +
@@ -1,13 +1,20 @@
 Source: dhcpdump
 Section: admin
 Priority: optional
-Maintainer: Debian QA Group 
-Build-Depends: libpcap0.8-dev
-Standards-Version: 3.8.0.1
+Maintainer: Boian Bonev 
+Build-Depends:
+ debhelper-compat (= 13),
+ libpcap-dev,
+Standards-Version: 4.6.2
+Rules-Requires-Root: no
+Homepage: http://www.mavetju.org/download/
 
 Package: dhcpdump
 Architecture: any
-Depends: ${shlibs:Depends}, tcpdump
-Description: Parse DHCP packets from tcpdump
- This package provides a tool for visualization of DHCP packets as
- recorded and output by tcpdump to analyze DHCP server responses.
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: Parse DHCP packets from interface
+ This package provides a tool for visualization of DHCP packets
+ on a network interface to analyze DHCP client requests and
+ server responses.
diff -Nru dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch
--- dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch	1970-01-01 00:00:00.0 +
+++ dhcpdump-1.8/debian/patches/dhcpdump-bugfix_ethertype.patch	2023-03-18 21:33:55.0 +
@@ -0,0 +1,22 @@
+Description: Fix network order 16bit value
+ Get the packet's ethertype in a way that works on any
+ kind of endian machine
+ .
+Author: Ben Hildred <426...@gmail.com>
+Origin: vendor
+Forwarded: BTS #873635
+Last-Update: 2017-08-29
+
+--- a/dhcpdump.c
 b/dhcpdump.c
+@@ -132,8 +132,8 @@ void pcap_callback(u_char *user, const s
+ 	offset += ETHER_HDR_LEN;
+ 
+ 	// Check for IPv4 packets
+-	if (eh->ether_type != 8) { 
+-		printf("Ignored non IPv4 packet: %d\n", eh->ether_type);
++	if (eh->ether_type != htons(0x800)) { 
++		printf("Ignored non IPv4 packet: %x\n", ntohs(eh->ether_type));
+ 		return;
+ 	}
+ 
diff -Nru dhcpdump-1.8/debian/patches/dhcpdump-bugfix_flags.patch dhcpdump-1.8/debian/patches/dhcpdump-bugfix_flags.patch
--- dhcpdump-1.8/debian/patches/dhcpdump-bugfix_flags.patch	1970-01-01 00:00:00.0 +
+++ dhcpdump-1.8/debian/pa

Bug#1033176: linux: Future Android/Waydroid support

[Diederik de Haas]

Source: linux
Version: Future Android/Waydroid support
Severity: wishlist
Forwarded: https://github.com/waydroid/waydroid/issues/811

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In https://salsa.debian.org/kernel-team/linux/-/merge_requests/651 I had
initially removed the 2 Android related patches for the following
reason:

Drop patches:
- debian/android-enable-building-ashmem-and-binder-as-modules.patch
- debian/export-symbols-needed-by-android-drivers.patch
After https://bugs.debian.org/901492 the preceding 2 patches were
created for anbox support. However in kernel 5.18 `ashmem` was removed
from the upstream kernel and since then, anbox has not been working as
reported in https://bugs.debian.org/1014329.
Then in https://bugs.debian.org/1032304, titled "RM: anbox -- ROM;
Upstream discontinued", the anbox package has been removed from the
Debian archive. And on Anbox's GH page one can see the following:
"It's development has however stalled in the past years and it's only
fair to say that now in 2023 it's no longer actively developed."
So it's of no use to continue carrying these patches.

Even though anbox is removed from the Debian archive and upstream more
or less 'dead', it turns out that Waydroid (= ~ anbox's successor) could
probably benefit from support in the Debian kernel too.

So I undid/reverted the dropping of those patches.
Removal of Android support should be done separately and ideally based on
a bug report in the BTS, hence this bug report.

In https://github.com/waydroid/waydroid/issues/811 I asked 'upstream'
for recommendations on which/how/what kernel modules to enable.

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZBZPHwAKCRDXblvOeH7b
bpbCAPsFqbmYhJzizpispzGdw+ksgNnm59ZQDtmSMSYcNk5S5gD9FcHWbGx6XtJ2
5YefJ1PVNv1BbtdAkofzw2Nz5gLLDgE=
=pyYQ
-END PGP SIGNATURE-

Bug#1033175: FTBFS: setup.py install is deprecated

[David W. Kennedy]

Package: 0ad
Version: 0.0.26-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: dav...@reasoned.us

Hello,

When I try to build 0ad version 0.0.26-3 in Debian unstable with 
python3.11 and python3-virtualenv, build fails.


I think that the key error message is 
"/usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build 
and pip and other standards-based tools."


The commands that I use to build the package:

# apt-get update
# apt-get build-dep 0ad
$ apt-get source 0ad
$ cd 0ad-0.0.26
$ debuild

Here is an excerpt of the output.

[...]

patching file python/mozbuild/mozbuild/preprocessor.py
patching file python/mozbuild/mozbuild/util.py
Creating Python 3 environment
/usr/lib/python3/dist-packages/setuptools/command/install.py:34: 
SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build 
and pip and other standards-based tools.

  warnings.warn(
created virtual environment CPython3.11.2.final.0-64 in 139ms
  creator 
CPython3Posix(dest=/home/myusername/0ad-0.0.26/libraries/source/spidermonkey/mozjs-78.6.0/build-debug/_virtualenvs/init_py3, 
clear=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, 
wheel=bundle, via=copy, 
app_data_dir=/home/myusername/.local/share/virtualenv)

added seed packages: pip==20.2.2, setuptools==49.6.0, wheel==0.35.1
  activators 
BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator

Traceback (most recent call last):
  File 
"/home/myusername/0ad-0.0.26/libraries/source/spidermonkey/mozjs-78.6.0/build-debug/../js/src/../../configure.py", 
line 181, in 

sys.exit(main(sys.argv))
 ^^
  File 
"/home/myusername/0ad-0.0.26/libraries/source/spidermonkey/mozjs-78.6.0/build-debug/../js/src/../../configure.py", 
line 52, in main
sandbox.run(os.path.join(os.path.dirname(__file__), 
'moz.configure'))


[...]

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[James Addison]

Package: release-notes
Followup-For: Bug #1033065
X-Debbugs-Cc: martin-eric.rac...@iki.fi

Hi Martin-Éric - I intended to send my previous comment to you, but forgot to
add you to on carbon-copy.

Roughly speaking: I'm wondering whether there is a way that we can scan i386
architecture packages in (bookworm only?) archives to figure out the scale of
the problem.

Bug#1033174: [INTL:ro] Romanian debconf templates translation of opendnssec

[Remus-Gabriel Chelu]

Package: opendnssec
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «opendnssec» file.

Thanks,
Remus-Gabriel

opendnssec_debconf_ro.po
Description: Binary data

Bug#1032999: unblock: mesa/22.3.6-1

[Jonathan Wiltshire]

On Sat, Mar 18, 2023 at 05:33:02PM +0100, Paul Gevers wrote:
> Oh, we were going to unblock this mesa, but we're waiting for
> llvm-toolchain-15 to get fixed. I think that might take some more time, so I
> propose that the version in unstable is uploaded to testing-proposed-updates
> such that it gets build against the version of llvm-toolchain-15 in testing.
> Please, changelog only (with a correct version).

That sounds like a plan.

J




-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1033173: materia-gtk-theme: Materia issues with Mate and Caja

[Damon Thomas]

Package: materia-gtk-theme
Version: 20210322-1
Severity: normal
X-Debbugs-Cc: asme...@gmail.com

Dear Maintainer,

With caja on a mate desktop materia/materia-light displays black text on a 
black background. Icons are visible but the text is unreadable. 

materia-dark works as expected.

Thanks!
Damon

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

Kernel: Linux 6.1.0-6-amd64 (SMP w/4 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

materia-gtk-theme depends on no packages.

Versions of packages materia-gtk-theme recommends:
ii  gnome-themes-extra3.28-2
ii  gtk2-engines-murrine  0.98.2-3+b1
ii  libgtk-3-common   3.24.37-2
ii  libgtk-4-common   4.8.3+ds-2
ii  libgtk2.0-common  2.24.33-2

materia-gtk-theme suggests no packages.

-- no debconf information

Bug#1033172: /usr/bin/sieve-test: panicks, dumps backtrace, aborts, when mail-file not seekable

[наб]

Package: dovecot-sieve
Version: 1:2.3.19.1+dfsg1-2.1
Severity: normal
File: /usr/bin/sieve-test

Dear Maintainer,

$ sieve-test /dev/null /dev/stdin
sieve-test(nabijaczleweli): Error: sieve: file storage: script: Sieve script 
file '/dev/null' is not a regular file.
error: failed to open script: internal error occurred: refer to server log for 
more information. [2023-03-18 23:55:35].
sieve-test(nabijaczleweli): Fatal: failed to compile sieve script

$ > script
$ sieve-test script /dev/stdin
From: ardema...@gmail.com
sieve-test(nabijaczleweli): Panic: stream /dev/stdin doesn't support seeking 
backwards
sieve-test(nabijaczleweli): Error: Raw backtrace: 
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x3e) [0xf7c6663e] -> 
/usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1d) [0xf7c6676d] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xe9611) [0xf7c70611] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xe964f) [0xf7c7064f] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x43efd) [0xf7bcaefd] -> 
/usr/lib/dovecot/libdovecot.so.0(+0xf78db) [0xf7c7e8db] -> 
/usr/lib/dovecot/libdovecot.so.0(i_stream_seek+0x78) [0xf7c7db08] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(index_mail_parse_headers+0x59) 
[0xf7df8d49] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0xb9ffb) [0xf7df8ffb] 
-> /usr/lib/dovecot/libdovecot-storage.so.0(index_mail_get_first_header+0xba) 
[0xf7df945a] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(mail_get_first_header+0x3e) 
[0xf7d8241e] -> 
/usr/lib/dovecot/libdovecot-storage.so.0(mail_get_message_id+0x2f) [0xf7d8274f] 
-> /bin/sieve-test(main+0x26a) [0x5659f90a] -> 
/lib/x86_64-linux-gnux32/libc.so.6(+0x2023c) [0xf79ca23c] -> 
/lib/x86_64-linux-gnux32/libc.so.6(__libc_start_main+0x81) [0xf79ca2f1] -> 
/bin/sieve-test(_start+0x23) [0x565a0013]
Aborted

Probably not what you want, is it.

Best,
наб

-- Package-specific info:

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

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

Versions of packages dovecot-sieve depends on:
ii  dovecot-core  1:2.3.19.1+dfsg1-2.1
ii  libc6 2.36-8
ii  ucf   3.0043+nmu1

dovecot-sieve recommends no packages.

dovecot-sieve suggests no packages.

Versions of packages dovecot-sieve is related to:
ii  dovecot-core [dovecot-common]  1:2.3.19.1+dfsg1-2.1
pn  dovecot-dev
pn  dovecot-gssapi 
pn  dovecot-imapd  
pn  dovecot-ldap   
pn  dovecot-lmtpd  
pn  dovecot-managesieved   
pn  dovecot-mysql  
pn  dovecot-pgsql  
pn  dovecot-pop3d  
ii  dovecot-sieve  1:2.3.19.1+dfsg1-2.1
pn  dovecot-sqlite 

-- no debconf information


signature.asc
Description: PGP signature

Bug#1033171: [INTL:ro] Romanian debconf templates translation of opendmarc

[Remus-Gabriel Chelu]

Package: opendmarc
Version: N/A
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «opendmarc» file.

Thanks,
Remus-Gabriel

opendmarc_debconf_ro.po
Description: Binary data

Bug#985769: xwayland: 100% of CPU, The system gets stuck.

[Timo Lindfors]

Hi,

indeed. Debian 11 desktop is very unstable under VMware Workstation Pro. I 
tracked this down to 
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1132 and managed to 
fix it by applying 
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1061/diffs?commit_id=ba644a64a415962956de72936d21b6527ee8cd57




-Timo

Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify

[Diederik de Haas]

On Saturday, 18 March 2023 21:33:10 CET Salvatore Bonaccorso wrote:
> > The following looks similar, though it is reported to happen on dock
> > unplug. I assume your issue is independent on that?

I guess that is https://bugzilla.kernel.org/show_bug.cgi?id=217106 ?

> And if you do some bisection/tests with the above questions from
> Diederik, might you try as well
> 
> https://patchwork.kernel.org/project/linux-usb/patch/20230306103359.6591-2-h
> dego...@redhat.com/

Not sure why patchwork still shows v2 of the patch as v4 is available here:
https://lore.kernel.org/all/20230308154244.722337-1-hdego...@redhat.com/

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

Bug#1033095: Disable TIOCSTI for trixie

[Diederik de Haas]

On Saturday, 18 March 2023 22:42:15 CET Salvatore Bonaccorso wrote:
> "early", i.e. it can be in one of the first uploads to experimental we
> will do. But I will prefer to have it separate from the rebase to new
> upstream version, i.e. as own dedicated change/mr.
> 
> So please keep the default in the !651 merge request.

Will do.

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

Bug#1032592: libzstd: FTBFS on hppa and others - numeric value overflows 32-bit unsigned int

[Peter Pentchev]

On Sat, Mar 18, 2023 at 11:25:52PM +0200, Peter Pentchev wrote:
> On Thu, Mar 09, 2023 at 04:39:16PM +, John David Anglin wrote:
> > Source: libzstd
> > Version: 1.5.4+dfsg2-4
> > Severity: normal
> > Tags: ftbfs
[snip]
> > 1.5.2+dfsg2-3 was okay.
> 
> Well... it's not that it was okay, it's that some of the tests failed in -1,
> so I disabled them in -2, then I applied an upstream fix and reenabled them in
> -3, thinking that everything would be fine, but it was not :)

...and of course I messed up the revisions there, but you get the gist...

> So yeah, thanks again for keeping track and filing this bug!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1033095: Disable TIOCSTI for trixie

[Salvatore Bonaccorso]

Hi,

On Sat, Mar 18, 2023 at 10:26:08PM +0100, Diederik de Haas wrote:
> On Saturday, 18 March 2023 21:17:52 CET Salvatore Bonaccorso wrote:
> > > https://www.openwall.com/lists/oss-security/2023/03/14/2
> > > 
> > > Filing a bug (for trixie (added in 6.2), can be applied early to notice
> > > potentially affected applications early on)
> > 
> > Just for reference in the bug, this possible since 83efeeeb3d04 ("tty:
> > Allow TIOCSTI to be disabled") in 6.2-rc1.
> > 
> > Early on trixie cycle, we can set it to be disabled (unless even
> > upstream changes the default) and see where it will cause issues.
> > 
> > https://git.kernel.org/linus/83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d
> 
> How early do you want it? ;-)
> Should I set it to 'n' or "CONFIG_LEGACY_TIOCSTI is not set" in my MR?

"early", i.e. it can be in one of the first uploads to experimental we
will do. But I will prefer to have it separate from the rebase to new
upstream version, i.e. as own dedicated change/mr.

So please keep the default in the !651 merge request.

Regards,
Salvatore

Bug#1033170: libitext-rups-java: Does not work at all

[Jorge Moraleda]

Package: libitext-rups-java
Version: 2.1.7-13
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: jorge.moral...@gmail.com

Dear Maintainer,

The package does not work at all. Based on the following Ubuntu bug report it
appears the version packaged is too old to work:
https://bugs.launchpad.net/ubuntu/+source/libitext-java/+bug/802021


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

Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, 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 libitext-rups-java depends on:
ii  libitext-java  2.1.7-13

libitext-rups-java recommends no packages.

libitext-rups-java suggests no packages.

-- no debconf information

Bug#1033169: mirrors: ssl certificate error for ftp.pl.debian.org

[Boud Roukema]

Package: mirrors
Severity: normal

Dear Maintainer,

* What led up to the situation?

I tried to access

https://ftp.pl.debian.org/debian

in firefox, which gave

'Warning: Potential Security Risk Ahead'

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

I selected 'advanced', 'accept the risk and continue', and continued through
to 'View Certificate'.

* What was the outcome of this action?

I found the entries:

Common Name  ftp.task.gda.pl

Subject Alt Names

DNS Name   debian.task.gda.pl
DNS Name   ftp.task.gda.pl
DNS Name   pl.archive.ubuntu.com
DNS Name   pl.releases.ubuntu.com
DNS Name   releases.ubuntu.task.gda.pl
DNS Name   ubuntu.task.gda.pl


* What outcome did you expect instead?

I expected that an ssl certificate for ftp.pl.debian.org would have been
considered to be secure. The bug is presumably because the certificate
only includes the six domain names listed above, and not ftp.pl.debian.org
itself.


* Suggested solution: update DNS records.

Cheers
Boud

Bug#1032592: libzstd: FTBFS on hppa and others - numeric value overflows 32-bit unsigned int

[Peter Pentchev]

On Thu, Mar 09, 2023 at 04:39:16PM +, John David Anglin wrote:
> Source: libzstd
> Version: 1.5.4+dfsg2-4
> Severity: normal
> Tags: ftbfs
> 
> Dear Maintainer,
> 
> Build fails testing basic decompression:
[snip]

Actually this is a red herring, these error messages appear in the logs of
the successful builds for the other architectures. The tests for zstd have
some... questionable reporting.

> Full log is here:
> https://buildd.debian.org/status/fetch.php?pkg=libzstd&arch=hppa&ver=1.5.4%2Bdfsg2-4&stamp=1678356348&raw=0

Yeah, I noticed that pretty much as soon as I uploaded -4, but it was some
time before I could get into it, investigate it, and experiment properly.
Thanks for filing the bug, though - it does help keep me honest :)

> 1.5.2+dfsg2-3 was okay.

Well... it's not that it was okay, it's that some of the tests failed in -1,
so I disabled them in -2, then I applied an upstream fix and reenabled them in
-3, thinking that everything would be fine, but it was not :)

So yeah, thanks again for keeping track and filing this bug!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1033095: Disable TIOCSTI for trixie

[Diederik de Haas]

On Saturday, 18 March 2023 21:17:52 CET Salvatore Bonaccorso wrote:
> > https://www.openwall.com/lists/oss-security/2023/03/14/2
> > 
> > Filing a bug (for trixie (added in 6.2), can be applied early to notice
> > potentially affected applications early on)
> 
> Just for reference in the bug, this possible since 83efeeeb3d04 ("tty:
> Allow TIOCSTI to be disabled") in 6.2-rc1.
> 
> Early on trixie cycle, we can set it to be disabled (unless even
> upstream changes the default) and see where it will cause issues.
> 
> https://git.kernel.org/linus/83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d

How early do you want it? ;-)
Should I set it to 'n' or "CONFIG_LEGACY_TIOCSTI is not set" in my MR?

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

Bug#1032939: unblock: network-manager/1.42.4-1

[Paul Gevers]

Control: tags -1 moreinfo

Hi Michael,

On 14-03-2023 13:47, Michael Biebl wrote:

please unblock package network-manager.

The current version in testing is 1.42.0-1 and upstream has created two
stable point releases 1.42.2 and 1.42.4, cherry-picking various fixes
into the nm-1.42 stable branch, most notably a fix for #1031891,
a regression in the dnsmasq DNS backend when using a global DNS
configuration.

Upstream is rather conservative in cherry-picking fixes into their
stable branches and the package ships an extensive test-suite, which is
run during build.


What does "rather conservative" mean? Do you have a link to their policy?

Normally we'd like to have a more verbose description of the changes. 
The diff is uncomfortably big. Please try to avoid white space changes 
next time too (debian/org.freedesktop.NetworkManager.rules), those are 
horrible to review. Is there a reason why you "Use execute_before 
instead of override for dh_install" now?


> I've filtered out generated files (like Makfile.in) and po/*

Next time, please provide the full filter that you used. I would not 
have guessed from that line that you stripped a lot of docs/ too.



No new regressions were reported for 1.42.4-1.

I would thus like to see 1.42.4-1 unblocked for bookworm.


Ack. I'm leaning to let it in now, but later in the freeze, please 
cherry-pick or defer.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031084: opendoas: Misleading comment in example config file

[Vesset Rebane]

Hello!
Thank you for reporting this, I fixed this in the latest commit in the git repo.
The next version of this package will include the fix.


signature.asc
Description: PGP signature

Bug#1029123: bullseye-pu: package apache2/2.4.55-1~deb11u1

[Salvatore Bonaccorso]

Hi,

On Sat, Mar 18, 2023 at 05:42:40PM +, Adam D. Barratt wrote:
> On Wed, 2023-01-18 at 11:25 +0400, Yadd wrote:
> > Apache2 has 3 new security issues:
> >  * CVE-2006-20001: mod_dav out of bounds read, or write of zero byte.
> >A carefully crafted If: request header can cause a memory read, or
> > write
> >of a single zero byte, in a pool (heap) memory location beyond the
> > header
> >value sent. This could cause the process to crash.
> >  * CVE-2022-36760: mod_proxy_ajp Possible request smuggling.
> >Inconsistent Interpretation of HTTP Requests ('HTTP Request
> > Smuggling')
> >vulnerability in mod_proxy_ajp of Apache HTTP Server allows an
> > attacker
> >to smuggle requests to the AJP server it forwards requests to.
> >  * CVE-2022-37436: mod_proxy prior to 2.4.55 allows a backend to
> > trigger HTTP
> >response splitting.
> >A malicious backend can cause the response headers to be truncated
> > early,
> >resulting in some headers being incorporated into the response
> > body. If
> >the later headers have any security purpose, they will not be
> > interpreted
> >by the client.
> 
> Apologies for letting this fall through the cracks until now.
> 
> >From comments in #1032977, it sounds as if this request has been
> effectively superseded by an impending DSA release?

Yes, there will be a DSA release for apache2 based on 2.4.56 upstream
(versioned 2.4.56-1~deb11u1), which will include those changes as
well.

Regards,
Salvatore

Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify

[Salvatore Bonaccorso]

On Sat, Mar 18, 2023 at 09:13:01PM +0100, Salvatore Bonaccorso wrote:
> On Thu, Mar 16, 2023 at 08:39:51PM +0100, Diederik de Haas wrote:
> > On Thursday, 16 March 2023 18:11:27 CET Julien Cristau wrote:
> > > > I rebooted on 6.1.15-1 last night and things are still looking good so
> > > > I'll call this fixed.  Thanks.
> > > 
> > > Spoke too soon:
> > > > [84564.498495] BUG: kernel NULL pointer dereference, address:
> > > > 0398 [84564.498502] #PF: supervisor write access in kernel
> > > > mode
> > > > [84564.498504] #PF: error_code(0x0002) - not-present page
> > > > [84564.498506] PGD 4c9444067 P4D 4c9444067 PUD 0
> > > > [84564.498510] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > > > [84564.498512] CPU: 0 PID: 140651 Comm: kworker/0:0 Not tainted
> > > > 6.1.0-6-amd64 #1  Debian 6.1.15-1 [84564.498516] Hardware name: LENOVO
> > > > 20XW00ABUS/20XW00ABUS, BIOS N32ET82W (1.58 ) 12/05/2022 [84564.498518]
> > > > Workqueue: kacpi_notify acpi_os_execute_deferred
> > 
> > Bummer.
> > 
> > Since 6.1.8 I found the following 2 commits in drivers/usb/typec/ucsi:
> > 
> > 3d7f77e55da3455c8844b651e37779c90e201f48 titled
> > "usb: ucsi: Ensure connector delayed work items are flushed"
> > 
> > fdd11d7136fd070b3a74d6d8799d9eac28a57fc5 titled
> > "usb: typec: ucsi: Don't attempt to resume the ports before they exist"
> > 
> > Especially the first one looks 'promising'.
> > Can you make a patch which reverts that commit and use 'test-patches' from
> > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html
> > to build a kernel and test that?
> 
> The following looks similar, though it is reported to happen on dock
> unplug. I assume your issue is independent on that?

And if you do some bisection/tests with the above questions from
Diederik, might you try as well

https://patchwork.kernel.org/project/linux-usb/patch/20230306103359.6591-2-hdego...@redhat.com/

(it is not yet applied mainline).

Regards,
Salvatore

Bug#1033168: zeal: inaccurate man page

[Louie S.]

Package: zeal
Version: 1:0.6.1-1.2~bpo11+1
Severity: normal
X-Debbugs-Cc: lshpr...@tutanota.com

Dear Maintainer,

The zeal man page is inaccurate (most likely out of date) regarding the
`OPTIONS` section. The options listed by the help message differ from those
listed in the man page. In particular, the `-q` or `--query` option listed in
the man page appears to be obsolete.


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
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 zeal depends on:
ii  libarchive13   3.4.3-2+deb11u1
ii  libc6  2.31-13+deb11u5
ii  libgcc-s1  10.2.1-6
ii  libqt5concurrent5  5.15.2+dfsg-9
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5sql5-sqlite  5.15.2+dfsg-9
ii  libqt5webkit5  5.212.0~alpha4-11
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libqt5x11extras5   5.15.2-2
ii  libsqlite3-0   3.34.1-3
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.2-1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb11.14-3

zeal recommends no packages.

zeal suggests no packages.

Bug#1033095: Disable TIOCSTI for trixie

[Salvatore Bonaccorso]

Control: tags -1 + confirmed

Hi,

On Fri, Mar 17, 2023 at 09:54:33AM +0100, Moritz Muehlenhoff wrote:
> Source: linux
> Severity: wishlist
> 
> https://www.openwall.com/lists/oss-security/2023/03/14/2
> 
> Filing a bug (for trixie (added in 6.2), can be applied early to notice
> potentially affected applications early on)

Just for reference in the bug, this possible since 83efeeeb3d04 ("tty:
Allow TIOCSTI to be disabled") in 6.2-rc1.

Early on trixie cycle, we can set it to be disabled (unless even
upstream changes the default) and see where it will cause issues.

https://git.kernel.org/linus/83efeeeb3d04b22aaed1df99bc70a48fe9d22c4d

Regards,
Salvatore

Bug#1032902: genx won't start: TypeError: Pen(): arguments did not match any overloaded call

[Andrey Rakhmatullin]

On Mon, Mar 13, 2023 at 07:58:48PM +0100, s3v wrote:
>   File "/usr/lib/python3/dist-packages/genx/datalist.py", line 350, in 
> _CreateBmpIcon
>     dc.SetPen(wx.Pen(color_data,0.0))
>   ^^
> TypeError: Pen(): arguments did not match any overloaded call:
This part should likely be fixed by
https://sourceforge.net/p/genx/git/ci/221e3207b045e7d3a59de1876a675ce017312d9c
(I haven't checked if it helps and if there are no more errors).

Bug#1033164: Samba mount bug related to using the wrong krb5 credential cache

[Karl O. Pinc]

Debian bug #986168

Bug#717825: please allow ghostscript to cross build

[Helmut Grohne]

On Sat, Mar 18, 2023 at 12:52:57PM +0100, Håvard F. Aasen wrote:
> Helmut, do you have an opinion on the importance of this issue?

In general, cross build bugs are not release-critical. Regressions
affecting architecture bootstrap tend to be considered important and
fixed during freeze. Everything else is best effort. Given that
ghostscript is a key package, this would need an unblock.

Thanks for pointing at the fix however.

Helmut

Bug#986168: Related Debian & Ubuntu bugs re mounting with multiuser,sec=krb5

[Karl O. Pinc]

See Debian bug #1033164

Ubuntu bugs:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/2012140
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/2012143
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/2012145
https://bugs.launchpad.net/ubuntu/+source/cifs-utils/+bug/2012147

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#1033167: usrmerge: messes with /etc/shells

[Helmut Grohne]

Package: usrmerge
Version: 25
Severity: serious
Justification: violates policy section 10.7.4
Control: affects -1 + debianutils dash
X-Debbugs-Cc: jo...@debian.org, cl...@debian.org, andre...@debian.org, 
debian-rele...@lists.debian.org

Hi,

I think that it is quite obvious that /etc/shells is debianutils'
territory. When I found that on some systems /etc/shells was out of sync
with /var/lib/shells.state, I was quite puzzled until I noticed that
usrmerge messes with this file. This really is debianutils'
configuration file and usrmerge has no business in touching it in
uncoordinated ways. Refer to policy section 10.7.4 for details, so
usrmerge is technically rc-buggy. However, usrmerge does have reason to
touch it, so the solution is not simply to drop convert-etc-shells with
no replacement.

Let us dive a bit into how an essential system can come to be.

1. We start either merged (e.g. debootstrap or mmdebstrap with
   --hook-dir=.../merged-usr) or unmerged (mmdebstrap without hook or
   an old debootstrap --no-merged-usr).

2. We either install usrmerge or usr-is-merged. Though we cannot
   combine starting unmerged with usr-is-merged for obvious reasons.

3. The last invocation of update-shells happens before or after
   usrmerge.postinst. (Not relevant in case of usr-is-merged)

So what happens in these cases?

If and only if usrmerge is used, convert-etc-shells turns /bin/sh into
/usr/bin/sh. So whenever we start out merged and use usr-is-merged,
/usr/bin/sh goes missing.

If usrmerge is used, the order of entries in /etc/shells depends on
whether update-shells is run after it or not. Likewise
/var/lib/shells.state also depends. This is not some mmdebstrap-specific
problem. You can easily observe this with debootstrap --no-merged-usr
and installing usrmerge vs just doing debootstrap.

This is bad from a reproducibility point of view and it is rooted in
usrmerge not cooperating with other packages, but instead doing things
behind their back, which happens to violate policy.

So how to fix this?

For one thing, the /bin/sh difference is rooted in the fact that /bin/sh
is a standard value of debianutils and not managed using shells.d even
though dash ships plain /bin/sh these days. I think dash should just add
/bin/sh to /usr/share/debianutils/shells.d/dash and we'd be done as all
entries in shells.d are correctly managed wrt. merged-/usr by
update-shells.

The next thing is that convert-etc-shells needs to go away from
usrmerge. In the age of systems with usr-is-merged, there is no
convert-etc-shells (as there is no usrmerge), so it must work without
somehow anyway. When you run update-shells after a merge, it will pick
up the merged shell locations (for shells managed in shells.d) and add
them to /etc/shells. So usrmerge should ensure that update-shells is
called after having performed the merge. This is the only way to get
reproducibility. (That doesn't quite answer yet when to run it, how to
run it, nor whether that makes convert-etc-shells unnecessary though.)

Then we still have add-shell and remove-shell and most packages using
them induce policy violations (reverting admin changes on upgrade), so
we want to change them to the shells.d mechanism in the long run, but
that's not where we are today and especially not what we can rely on in
bookworm. So for these entries, we still do need convert-etc-shells and
indeed we cannot just delete it. convert-etc-shells compensates for the
difference in behaviour of add-shell pre-merge vs post-merge.

I think the best solution here would be merging convert-etc-shells into
update-shells. Whenever we run update-shells, it should check whether
the system is already merged and when it is, perform the equivalent to
convert-etc-shells. Then usrmerge can just install an empty (except for
a comment) /usr/share/debianutils/shells.d/usrmerge to trigger
update-shells and things become fully reproducible in all cases, because
no matter how we started, we will run update-shells post merge and
that'll do the right thing. And since usrmerge now uses the tools
provided by debianutils, this fully resolves the policy violation. Also
note that usr-is-merged does not have to invoke the trigger as
debianutils is configured after /usr is merged.

So unless I am mistaken, this leads to the following action items:
 * update-shells absorbs convert-etc-shells.
 * dash adds /bin/sh to shells.d/dash.
 * usrmerge creates an empty shells.d/usrmerge file.
 * usrmerge depends on a version of debianutils that has absorbed
   convert-etc-shells.

Does that make sense to you? I haven't actually implemented and tested
this yet. Do you see any obvious flaws in the arguments or the proposed
solution?

I'm Ccing release managers as it looks like we're starting a transition
of an essential package right in the middle of the freeze. Not good, but
this looks still manageable to me.

Helmut

Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify

[Salvatore Bonaccorso]

On Thu, Mar 16, 2023 at 08:39:51PM +0100, Diederik de Haas wrote:
> On Thursday, 16 March 2023 18:11:27 CET Julien Cristau wrote:
> > > I rebooted on 6.1.15-1 last night and things are still looking good so
> > > I'll call this fixed.  Thanks.
> > 
> > Spoke too soon:
> > > [84564.498495] BUG: kernel NULL pointer dereference, address:
> > > 0398 [84564.498502] #PF: supervisor write access in kernel
> > > mode
> > > [84564.498504] #PF: error_code(0x0002) - not-present page
> > > [84564.498506] PGD 4c9444067 P4D 4c9444067 PUD 0
> > > [84564.498510] Oops: 0002 [#1] PREEMPT SMP NOPTI
> > > [84564.498512] CPU: 0 PID: 140651 Comm: kworker/0:0 Not tainted
> > > 6.1.0-6-amd64 #1  Debian 6.1.15-1 [84564.498516] Hardware name: LENOVO
> > > 20XW00ABUS/20XW00ABUS, BIOS N32ET82W (1.58 ) 12/05/2022 [84564.498518]
> > > Workqueue: kacpi_notify acpi_os_execute_deferred
> 
> Bummer.
> 
> Since 6.1.8 I found the following 2 commits in drivers/usb/typec/ucsi:
> 
> 3d7f77e55da3455c8844b651e37779c90e201f48 titled
> "usb: ucsi: Ensure connector delayed work items are flushed"
> 
> fdd11d7136fd070b3a74d6d8799d9eac28a57fc5 titled
> "usb: typec: ucsi: Don't attempt to resume the ports before they exist"
> 
> Especially the first one looks 'promising'.
> Can you make a patch which reverts that commit and use 'test-patches' from
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html
> to build a kernel and test that?

The following looks similar, though it is reported to happen on dock
unplug. I assume your issue is independent on that?

Regards,
Salvatore

Bug#1021034: Gtk{Grid,List}View scrolling fix backport into Debian's 4.8 branch

[Алексей Шилин]

Hi,

I've backported all relevant upstream patches fixing this issue into my
Debian gtk4 bookworm/sid package branch [1]. *Maybe* it can be used as
a base for an official backport, but the diff is unfortunately not
particularly small, so it's up to gtk4 maintainers and the Release
Team. Anyway, testing is welcome.

This bug affects all GTK4 applications using GtkListView and/or
GtkGridView when there are enough items inside. The most prominent one
is nautilus, but there are others, too, like gnome-font-viewer. For
nautilus, it makes scrolling from bottom to top (and also from top to
almost-bottom as it just jumps to the end of the grid) impossible for
any directory with large enough items count, like /usr/share/doc or
/usr/bin.

 [1]
https://salsa.debian.org/AleksejShilin-guest/gtk4/-/tree/fixes/1021034-gtklistview-scrolling

Bug#1033166: openssh: CVE-2023-28531

[Salvatore Bonaccorso]

Source: openssh
Version: 1:9.2p1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for openssh.

CVE-2023-28531[0]:
| ssh-add in OpenSSH before 9.3 adds smartcard keys to ssh-agent without
| the intended per-hop destination constraints.


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-2023-28531
https://www.cve.org/CVERecord?id=CVE-2023-28531

Regards,
Salvatore

Bug#1033165: dnsmasq: CVE-2023-28450

[Salvatore Bonaccorso]

Source: dnsmasq
Version: 2.89-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for dnsmasq.

CVE-2023-28450[0]:
| An issue was discovered in Dnsmasq before 2.90. The default maximum
| EDNS.0 UDP packet size was set to 4096 but should be 1232 because of
| DNS Flag Day 2020.


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-2023-28450
https://www.cve.org/CVERecord?id=CVE-2023-28450
[1] 
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=eb92fb32b746f2104b0f370b5b295bb8dd4bd5e5

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033164: krb5-doc: The documented DEFCCNAME is, probably, not the actual credential cache name

[Karl O. Pinc]

Package: krb5-doc
Severity: normal

Hi,

I have not actually setup the necessary environment to reproduce this
bug on Debian, but I have (tried to) examine the source code and
believe the bug exists in Debian.  I do know that this bug exists on
Ubuntu, and have examined the Ubuntu-specific patches and found
nothing that I can see affects the bug.

Here is a copy of the Ubuntu bug report:

The krb5 documentation says that DEFCCNAME is /tmp/krb5cc_%{uid}. But
actual credential cache file names look like:
/tmp/krb5cc_127408622_wH2NwY

Setting [libdefaults] default_ccache_name to krb5cc_%{uid} in
/etc/krb5.conf produces the expected credential cache file.

Unless you know this, using "mutiuser" in fstab with cifs/samba/smb
mounts is nigh impossible.


The Ubuntu bug can be found at:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/2012140

Above /tmp/krb5cc_127408622_wH2NwY cached credential file produced by
an MS Active Directory user login.

(This bug also makes username= cifs mounts fail.)

Apologies if this bug report is nothing but noise.  But I'd like to
get the attention of somebody, so cifs/smb3 per-user mounts don't take
gobs of research.  I will file a related cifs-utils bug and update this
bug with the bug number.  I'm hoping that a "kerberos person" can easily
verify the issue and so I'm not wasting too much of your time.

Thanks.

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

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

Bug#1031827: rsyslog: please mention changes that affect log parsing in NEWS.Debian

[Richard Lewis]

On Thu, 23 Feb 2023 21:12:23 +0100 Michael Biebl  wrote:
> Am 23.02.23 um 18:44 schrieb Simon McVittie:
> > According to
> > https://lists.debian.org/debian-backports/2023/02/msg8.html
> > it seems that people might be (rightly or wrongly) relying on the old
> > timestamp format, and the ability to read messages from /var/log/messages.
> >
> > I think it would be more obvious that these are intentional changes if
> > there was a NEWS entry for the bullseye -> bookworm

> Do you think I can copy the changelog from [1] or does it have too
> much/little detail?
>
> [1]
> https://tracker.debian.org/news/1379692/accepted-rsyslog-822100-3-source-into-unstable/
>

As a user it would really help to have this in rsyslog's NEWS.Debian.
I've been using rsyslog for a long time but ive never had to customise
it before, and while im sure there was a reason for this change it
does make the logs longer, less readable, and different to what you
get from journalctl. Im not complaining - im sure the new format is
better, but i think a log of people might need some
help understanding it

This change also breaks most people's locally-written logcheck rules.
We are trying to explain how users
can update everything via logcheck's NEWS.Debian (#1033059) and I
expect it breaks other consumers of syslog files as well. Which is
fine, but better to have it documented if we can

If it helps, the information i would be hoping to see in NEWS.Debian
from rsyslog is:
- what has changed
- why it was changed - from the pov of a casual user, i didn't find
the 'benefits' listed in the tracker link before very compelling, but
it would be better than nothing. Is the point that if you have
huge numbers of log messages a second (is this likely?) a more precise
timestamp is needed to allow accurate sorting? (but isn't the log
already in a sorted order?)
- and especially: how to change/revert/customise it, as this is not
obvious for a casual user: i tried and failed to quickly locate this
info in the man-page! (or if the old format is not supported any
more then definitely include that)

Happy to help with drafting - I have started something for the release
notes here:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/150

- grateful for any views from you on that as well, if you have time

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Richard Lewis]

On Sat, 18 Mar 2023, 15:12 Holger Levsen,  wrote:

> On Thu, Mar 16, 2023 at 06:00:06PM +, Holger Levsen wrote:
> > aaah, thanks! I only checked
> /usr/share/doc/logcheck/NEWS.Debian.gz
> > but not /usr/share/doc/logcheck-database/NEWS.Debian.gz
>
> now that I read it and followed the advice and the very nice
> sed example there, I can they that it worked flawlessly and was
> very easy to do. Thank you for that NEWS entry!
>
> > so maybe reassign this bug to src:release-notes?
>
> this question is still open... though maybe cloning the bug is even
> better, I'd really appreciated a small pointer to logcheck-database's NEWS
> file in the NEWS for logcheck...
>


I have submitted something against release-notes so that is in hand.

rsyslog has #1031827 which seems to at least have had a response  in 2023

I dont mind adding an entry for logcheck's NEWS as well as/instead of
logcheck-database's NEWS, @Mathias Gibbens what do you think?

The one drawback i see is that 99.9% of people will upgrade both logcheck
and logcheck-database together so will get 2 emails from apt-listchanges if
we put it in both. So we should delete it from logcheck-database's NEWS
I think?  - logcheck does require the same layout of rules even if you dont
use logcheck-database so i think this makes sense.  I hope this would not
crash apt-listchanges fir unstable users if the NEWS file
shrinks/disappears due to whatever culls.old entries...?

Bug#1033163: phpldapadmin: unable to login

[William Desportes]

Package: phpldapadmin
Version: 1.2.6.3-0.2
Severity: important
Control: -1 patch
Control: forwarded 1009117 
https://github.com/leenooks/phpLDAPadmin/commit/34d4f2022214780f93e17a5c8dba15cabc8b82b0
Control: fixed 1009117 phpldapadmin/1.2.6.3-0.1

On phpldapadmin, you can not login.
Here is attached all the patches you need to apply.
The final one "Fix-ldap-connect-PHP-8.1-is-now-a-class.patch" makes this bug 
report more true than ever.

Please remove the 149.patch, it's a bundle of patches.
And import all my attachements, I sorted this out and applied DEP-3 headers.

--
William DesportesFrom: Patrick Monnerat 
Date: Sat, 18 Mar 2023 16:28:44 +0100
Subject: Fix class name Attribute to PLAAttribute because of PHP8 class name
 clash

It has been introduced when class Attribute has been renamed
to PLAAttribute to avoid a name clash with the built-in
class of PHP 8.

Origin: upstream
Forwarded: https://github.com/leenooks/phpLDAPadmin/commit/c90dc06af20b4ec549e43b2b90c018ba0f030cad

Ref: https://www.php.net/manual/en/class.attribute.php
---
 lib/Attribute.php| 917 ---
 lib/AttributeFactory.php |   2 +-
 lib/BinaryAttribute.php  |   2 +-
 lib/DateAttribute.php|   2 +-
 lib/DnAttribute.php  |   2 +-
 lib/GidAttribute.php |   2 +-
 lib/MultiLineAttribute.php   |   2 +-
 lib/ObjectClassAttribute.php |   2 +-
 lib/PLAAttribute.php | 917 +++
 lib/PasswordAttribute.php|   2 +-
 lib/SelectionAttribute.php   |   2 +-
 lib/ShadowAttribute.php  |   2 +-
 lib/Visitor.php  |  24 +-
 13 files changed, 941 insertions(+), 937 deletions(-)
 delete mode 100644 lib/Attribute.php
 create mode 100644 lib/PLAAttribute.php

diff --git a/lib/Attribute.php b/lib/Attribute.php
deleted file mode 100644
index 3d040db..000
--- a/lib/Attribute.php
+++ /dev/null
@@ -1,917 +0,0 @@
-getServer($server_id);
-
-		$sattr = $server->getSchemaAttribute($name);
-		if ($sattr) {
-			$this->name = $sattr->getName(false);
-			$this->setLDAPdetails($sattr);
-
-		} else
-			$this->name = $name;
-
-		$this->source = $source;
-
-		# XML attributes are shown by default
-		switch ($source) {
-			case 'XML': $this->show();
-$this->setXML($values);
-
-break;
-
-			default:
-if (! isset($values['values']))
-	debug_dump_backtrace('no index "values"',1);
-
-$this->initValue($values['values']);
-		}
-
-		# Should this attribute be hidden
-		if ($server->isAttrHidden($this->name))
-			$this->forcehide = true;
-
-		# Should this attribute value be read only
-		if ($server->isAttrReadOnly($this->name))
-			$this->readonly = true;
-
-		# Should this attribute value be unique
-		if ($server->isAttrUnique($this->name))
-			$this->unique = true;
-	}
-
-	/**
-	 * Return the name of the attribute.
-	 *
-	 * @param boolean $lower - Return the attribute in normal or lower case (default lower)
-	 * @param boolean $real - Return the real attribute name (with ;binary, or just the name)
-	 * @return string Attribute name
-	 */
-	public function getName($lower=true,$real=false) {
-		if (DEBUG_ENABLED && (($fargs=func_get_args())||$fargs='NOARGS'))
-			debug_log('Entered (%%)',5,0,__FILE__,__LINE__,__METHOD__,$fargs,$this->name);
-
-		if ($real)
-			return $lower ? strtolower($this->name) : $this->name;
-		else
-			return $lower ? strtolower($this->real_attr_name()) : $this->real_attr_name();
-	}
-
-	public function getValues() {
-		if (DEBUG_ENABLED && (($fargs=func_get_args())||$fargs='NOARGS'))
-			debug_log('Entered (%%)',5,1,__FILE__,__LINE__,__METHOD__,$fargs,$this->values);
-
-		return $this->values;
-	}
-
-	public function getOldValues() {
-		if (DEBUG_ENABLED && (($fargs=func_get_args())||$fargs='NOARGS'))
-			debug_log('Entered (%%)',5,1,__FILE__,__LINE__,__METHOD__,$fargs,$this->oldvalues);
-
-		return $this->oldvalues;
-	}
-
-	public function getValueCount() {
-		if (DEBUG_ENABLED && (($fargs=func_get_args())||$fargs='NOARGS'))
-			debug_log('Entered (%%)',5,0,__FILE__,__LINE__,__METHOD__,$fargs,$this->values);
-
-		return count($this->values);
-	}
-
-	public function getSource() {
-		if (DEBUG_ENABLED && (($fargs=func_get_args())||$fargs='NOARGS'))
-			debug_log('Entered (%%)',5,1,__FILE__,__LINE__,__METHOD__,$fargs,$this->source);
-
-		return $this->source;
-	}
-
-	/**
-	 * Autovalue is called after the attribute is initialised, and thus the values from the ldap server will be set.
-	 */
-	public function autoValue($new_val) {
-		if (DEBUG_ENABLED && (($fargs=func_get_args())||$fargs='NOARGS'))
-			debug_log('Entered (%%)',5,0,__FILE__,__LINE__,__METHOD__,$fargs);
-
-		if ($this->values)
-			return;
-
-		$this->values = $new_val;
-	}
-
-	public function initValue($new_val) {
-		if (DEBUG_ENABLED && (($fargs=func_get_args())||$fargs='NOARGS'))
-			debug_log('Entered (%%)',5,0,__FILE__,__LINE__,__METHOD__,$fargs);
-
-		if ($this->values || $this->oldvalues) {
-			debug_dump(array('new_val'=>$new

Bug#1029123: bullseye-pu: package apache2/2.4.55-1~deb11u1

[Adam D. Barratt]

On Wed, 2023-01-18 at 11:25 +0400, Yadd wrote:
> Apache2 has 3 new security issues:
>  * CVE-2006-20001: mod_dav out of bounds read, or write of zero byte.
>A carefully crafted If: request header can cause a memory read, or
> write
>of a single zero byte, in a pool (heap) memory location beyond the
> header
>value sent. This could cause the process to crash.
>  * CVE-2022-36760: mod_proxy_ajp Possible request smuggling.
>Inconsistent Interpretation of HTTP Requests ('HTTP Request
> Smuggling')
>vulnerability in mod_proxy_ajp of Apache HTTP Server allows an
> attacker
>to smuggle requests to the AJP server it forwards requests to.
>  * CVE-2022-37436: mod_proxy prior to 2.4.55 allows a backend to
> trigger HTTP
>response splitting.
>A malicious backend can cause the response headers to be truncated
> early,
>resulting in some headers being incorporated into the response
> body. If
>the later headers have any security purpose, they will not be
> interpreted
>by the client.

Apologies for letting this fall through the cracks until now.

>From comments in #1032977, it sounds as if this request has been
effectively superseded by an impending DSA release?

Regards,

Adam

Bug#1032104: linux: ppc64el iouring corrupted read

[Paul Gevers]

On Mon, 6 Mar 2023 13:25:36 +1100 Daniel Black  wrote:

Since revering to linux-image-5.10.0-20 we've been free of the same errors.


On ci.debian.net I upgraded all ppc64el hosts to bookworm on 2023-03-09.

debian@ci-worker-ppc64el-04:~$ uname -a
Linux ci-worker-ppc64el-04 6.1.0-5-powerpc64le #1 SMP Debian 6.1.12-1 
(2023-02-15) ppc64le GNU/Linux


Can you check if the errors are still the same (yes, there's still 
intermittent failures).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030595: dkms autoinstall fails if headers are not available but a module could be built

[Paul Gevers]

Hi Andreas,

[Release Team member question]

On Mon, 6 Feb 2023 13:14:01 +0100 Andreas Beckmann  wrote:

This is actually a regression from bullseye:

If foobar-dkms is installed and linux-image-foo, but not 
linux-headers-foo gets installed, dkms will

on bullseye) emit a warning about the missing headers and exit 0
on bookworm) emit a warning about the missing headers and exit 11
making the linux-image-foo installation fail in bookworm. This is 
probably the same issue in all the similar bug reports that were 
reassigned against dkms.
I'm trying to understand this bug and what it means for the bookworm 
release. How bad do you judge this issue to be? Is there any solution in 
sight?


Shouldn't any foobar-dkms (or dkms helpers) depend on linux-headers? Or 
doesn't that work the way linux-headers-* are setup?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032622: cups-ipp-utils: Please enable translation of ippeveps(7)

[Helge Kreutzmann]

Hello Thorsten,
On Sat, Mar 11, 2023 at 01:53:27PM +0100, Thorsten Alteholz wrote:
> On 10.03.23 12:14, Helge Kreutzmann wrote:
> > Extra great would be, if could you send the updated de.po, fr.po and
> > pt.po to the previous translators asking for input (I can do this, if
> > you want)
> 
> it would be great if you could do this for me.

Done. DE, PT and FR are now up to date in the CUPS repository.

Could you kindly enable them[1] and prepare an upload targetted at
bookworm?

Thanks!

Greetings

  Helge

[1] I'm a bit lost in your build system, as stated earlier. I believe
the follwing patch is a good start, however it is not sufficient.
Please complete.

--- a/debian/rules
+++ b/debian/rules
@@ -72,12 +72,15 @@ override_dh_auto_configure:
 override_dh_auto_install:
dh_auto_install -- install BUILDROOT=$(shell pwd)/debian/tmp

-MANPAGES_L10N_CUPS=man1/cups.1 man5/subscriptions.conf.5 man5/mime.convs.5 
man7/filter.7 man8/cupsfilter.8 man8/cups-exec.8 man8/cups-deviced.8 
man8/cups-driverd.8 man8/cupsd-helper.8 man8/cupsd-lpd.8
-MANPAGES_L10N_CUPS_SERVER_COMMON=man5/cupsd-logs.conf.5
+MANPAGES_L10N_CUPS=man1/cups.1 man5/subscriptions.conf.5 man5/mime.convs.5 
man7/filter.7 man8/cupsfilter.8 man8/cups-exec.8 man8/cups-deviced.8 
man8/cups-driverd.8 man8/cupsd-helper.8 man8/cupsd-lpd.8 man8/cups-lpd.8
+MANPAGES_L10N_CUPS_SERVER_COMMON=man5/cupsd-logs.conf.5 man5/cupsd-logs.5
 MANPAGES_L10N_CUPS_DAEMON=man5/classes.conf.5 man5/cupsd.conf.5 
man5/cups-files.conf.5 man5/cups-snmp.conf.5 man5/mailto.conf.5 
man5/mime.types.5 man5/printers.conf.5 man7/backend.7 man7/notifier.7 
man8/cupsd.8 man8/cups-snmp.8
 MANPAGES_L10N_CUPS_CLIENT=man1/cupstestppd.1 man1/lp.1 man1/lpoptions.1 
man1/lppasswd.1 man1/lpstat.1 man1/cancel.1 man5/client.conf.5 
man8/cupsenable.8 man8/lpadmin.8 man8/lpinfo.8 man8/lpmove.8 man8/cupsreject.8 
man8/cupsdisable.8
+man8/cupsaccept.8 man8/cupsctl.8
 MANPAGES_L10N_CUPS_BSD=man1/lpr.1 man1/lprm.1 man1/lpq.1 man8/lpc.8
-MANPAGES_L10N_CUPS_IPP_UTILS=man1/ippeveprinter.1 man1/find.1 man1/ippserver.1 
man1/ipptool.1 man5/ipptoolfile.5
+#MANPAGES_L10N_CUPS_IPP_UTILS=man1/ippeveprinter.1 man1/find.1 
man1/ippserver.1 man1/ipptool.1 man5/ipptoolfile.5
+MANPAGES_L10N_CUPS_IPP_UTILS=man1/ippeveprinter.1 man1/ippfind.1 
man1/ipptool.1 man5/ipptoolfile.5 man7/ippeveps.7 man7/ippevepcl.7
+MANPAGES_L10N_CUPS_LIBCUPS2_DEV=man1/cups-config.1
+MANPAGES_L10N_CUPS_PPDC=man1/ppdc.1 man1/ppdhtml.1 man1/ppdi.1 man1/ppdmerge.1 
man1/ppdpo.1 man5/ppdcfile.5

 override_dh_installman:
dh_installman
+ifneq (,$(filter libcups2-dev,$(shell dh_listpackages)))
+   # Try to install the translated manpages to libcups2-dev
+   set -e; for m in $(MANPAGES_L10N_CUPS_LIBCUPS2_DEV); do \
+   for manp in $$(ls debian/tmp/usr/share/man/*/$$m); do \
+   if [ -r $$manp ]; then \
+   if [ -L $$manp ]; then \
+   ln -sf $$(readlink $$manp) $$(echo $$manp | sed -e 
's#^debian/tmp#debian/libcups2-dev#');\
+   else \
+   install -D -m 644 $$manp $$(echo $$manp | sed -e 
's#^debian/tmp#debian/libcups2-dev#');\
+   fi; \
+   fi; \
+   done; \
+   done
+endif
+ifneq (,$(filter cups-ppdc,$(shell dh_listpackages)))
+   # Try to install the translated manpages to cups-ppdc
+   set -e; for m in $(MANPAGES_L10N_CUPS_PPDC); do \
+   for manp in $$(ls debian/tmp/usr/share/man/*/$$m); do \
+   if [ -r $$manp ]; then \
+   if [ -L $$manp ]; then \
+   ln -sf $$(readlink $$manp) $$(echo $$manp | sed -e 
's#^debian/tmp#debian/cups-ppdc#');\
+   else \
+   install -D -m 644 $$manp $$(echo $$manp | sed -e 
's#^debian/tmp#debian/cups-ppdc#');\
+   fi; \
+   fi; \
+   done; \
+   done
+endif

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1033162: Document proper strict depends like main-dev (= ${source:Version})) but NMU, backport and piupart safe

[Bastien Roucariès]

Package: developers-reference
Version: 12.18
Severity: normal

Dear Maintainer,

Sometime (think a header only dev package) you need to depend on a strict 
version of an other package.

However,  (= ${source:Version})) is not NMU, backport, piupart and user 
recompile safe.

That is the best pratice ?

gpg use something like:
Depends: dirmngr (<< ${source:Version}.1~), dirmngr (>= ${source:Version}),
Breaks: dirmngr (<< ${binary:Version})

What do you think ? That is the consensus ?

Bastien


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

Bug#1015261: Additional issues in man pages found

[Helge Kreutzmann]

Dear Jose,
several new (additional) issues were found:

Man page: at.allow.5
Issue 1:  Final fullstop should not be marked bold
Issue 2:  which user → which users

"The I and I files determine which user can "
"submit commands for later execution via B(1)  or B(1)B<.>"
--
Man page: at.allow.5
Issue:B → B(1)

"If the file I exists, only usernames mentioned in it are "
"allowed to use B."

--
Man page: at.allow.5
Issue:B → B(1)

"If I does not exist, I is checked, every "
"username not mentioned in it is then allowed to use B."

"An empty I means that every user may use B."

"If neither exists, only the superuser is allowed to use at."

Thanks for taking care!

Greetings

  Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1006223: "stack smashing detected" error in ld while linking with Map-file specified

[Sergey Vlasov]

Looks like the upstream fix for this issue is
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1273da0414a2f2a31288749a17fe44cbef615ab5
(it also fixes another problematic place with similar code).

Also the bug cannot be reproduced in locales like en_US.UTF-8 and
appears only when some longer translations are used (e.g., in the
ru_RU.UTF-8 locale).

-- 
Sergey Vlasov

Bug#1033161: ITP: obs-vintage-filter -- plugin for OBS Studio to make sources black and white or sepia

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, cg2121 

* Package name: obs-vintage-filter
  Version : 1.0.0
  Upstream Contact: cg2121 
* URL : https://obsproject.com/forum/resources/vintage-filter.818/
* License : GPL-2
  Programming Lang: C
  Description : plugin for OBS Studio to make sources black and white or 
sepia

 This plugin provides a filter that adds the ability for sources to be black
 and white or sepia. This is useful to create vintage effects over photos,
 movies, webcam images, etc.

Bug#1033160: bullseye-pu: package flatpak/1.10.8-0+deb11u1

[Simon McVittie]

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

[ Reason ]
New upstream stable release fixing a security issue.

[ Impact ]
The same two CVEs that were fixed in 1.14.4-1 (#1033078), which the
security team have indicated are not going to get a DSA:

CVE-2023-28101: A malicious Flatpak app could prevent the flatpak(1) CLI
from displaying its permissions as intended, by having crafted permissions
or other metadata containing terminal escape sequences or other special
characters. (#1033098)

CVE-2023-28100: A malicious Flatpak app could execute code outside the
sandbox if run from a Linux virtual console. (#1033099)

Additionally, the new upstream stable release has some other bug fixes
backported from 1.12.x and 1.14.x for:
- temporary directories not being cleaned up if an upgrade is cancelled,
  in particular if it's blocked by parental controls (libmalcontent);
- the `flatpak history` command, which didn't previously work in bullseye;
- a build bug fix which isn't directly relevant to bullseye, but was
  necessary to get the upstream release out, and is harmless in bullseye

[ Tests ]
The automated test suite is run at build-time and by autopkgtest,
and still passes. It includes tests for the two CVE issues and the
`flatpak history` fixes. Coverage on buildds and lxc is not great,
because we're unable to actually run Flatpak apps in that environment,
but I ran the autopkgtest in autopkgtest-virt-qemu before upload (which
does get full coverage) and that also passes.

The new upstream stable release also adds unit test coverage for the
seccomp filter changes in previous security updates (CVE-2021-41133,
etc.), which were previously backported without automated tests.

A manual smoke-test on my partner's Debian 11 system was successful.

[ Risks ]
The security fixes are new, but are narrowly-targeted and seem rather safe.

The other changes have been in testing/unstable and in bullseye-backports
for a long time without regression reports.

[ 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 attached debdiff has been filtered to remove Autotools noise. The
diffstat is unfiltered.

* app/flatpak-builtins-info.c, app/flatpak-builtins-remote-info.c,
  app/flatpak-cli-transaction.c, common/flatpak-context.c,
  common/flatpak-utils.c, common/flatpak-utils-private.h: CVE-2023-28101

* common/flatpak-run.c: CVE-2023-28100

* configure.ac, Makefile.am: unrelated bug fix for ability to compile with
  newer gpgme (unnecessary for bullseye, but necessary to get the
  upstream release out)

* app/flatpak-builtins-history.c, app/flatpak-main.c: unrelated bug fixes
  for `flatpak history` backported from the version in testing/unstable

* common/flatpak-dir.c: unrelated bug fix for a temporary directory not
  being cleaned up if an upgrade is cancelled

* tests: Test coverage for CVE-2023-28101, CVE-2023-28100, previous
  CVE fixes, and the history bugfix
debdiff *.dsc | filterdiff -p1 -xMakefile.in -x'*/Makefile.in' -xaclocal.m4 -xconfig.guess -xconfig.sub -xconfigure
-x'doc/reference/html/*.html' -xdoc/reference/html/style.css -xltmain.sh -x'm4/l*.m4' -x'po/*.po' -x'po/*.pot'

diffstat for flatpak-1.10.7 flatpak-1.10.8

 Makefile.am|4 
 Makefile.in|   94 
 NEWS   |   36 
 aclocal.m4 |  193 
 app/flatpak-builtins-history.c |   59 
 app/flatpak-builtins-info.c|8 
 app/flatpak-builtins-remote-info.c |5 
 app/flatpak-cli-transaction.c  |   12 
 app/flatpak-main.c |5 
 common/flatpak-context.c   |   36 
 common/flatpak-dir.c   |   15 
 common/flatpak-ref-utils-private.h |1 
 common/flatpak-run.c   |4 
 common/flatpak-utils-private.h |   14 
 common/flatpak-utils.c |  119 
 common/flatpak-version-macros.h|2 
 config.guess   | 1502 +++--
 config.sub  

Bug#1032977: unblock: apache2/2.4.56-1

[Moritz Muehlenhoff]

On Sat, Mar 18, 2023 at 09:17:25AM +0100, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> Hi security team
> 
> On 2023-03-15 06:46:32 +0400, Yadd wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: apac...@packages.debian.org
> > Control: affects -1 + src:apache2
> > 
> > Please unblock package apache2
> > 
> > [ Reason ]
> > Apache2 < 2.4.56 is vulnerable to 2 CVE, the major is CVE-2023-25690
> > (bypass access control using HTTP Request Smuggling attack)
> 
> What's the plan regarding apache2 in bookworm? Will future DSAs update
> apache2 with update bugfix releases?

Indeed, that's also what was done for bullseye as well, e.g. DSA 4982 moved
to 2.4.51 or DSA 5035 moved to 2.4.52.

As such, it would be good to age apache to 10 days; we'd like to release
2.4.56 for bullseye-security and otherwise the higher version in stable
over testing might cause upgrade issues.

Cheers,
Moritz

Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed

[Dominique Dumont]

On Tue, 14 Feb 2023 22:21:26 +0100 Lee Garrett  wrote:
> Bumped severity as this makes bts currently unusable, and probably 
> breaks for quite a few DDs their workflow.

This does not break on my system where bts is connected to local sendmail 
(which is the default setup).

Which hints at a workaround: have bts connect to local sendmail and have 
sendmail forward the mail to the SMTPS server.

The change mentioned by Daniel affects only a setup where the host if 
configured via its IP address, not via a host name:
See the change in SSL.pm in commit 
https://github.com/noxxi/p5-io-socket-ssl/commit/c0a063b70f0a3ad033da0a51923c65bd2ff118a0

Which is not the case here:

$ perl -S -MDevel::SimpleTrace bts --smtp-host smtps://mail.wgdd.de usertag 
1029588 + dod-test-with-tls
bts: failed to open SMTPS connection to smtps://mail.wgdd.de
(hostname verification failed)
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(/usr/bin/bts:2839)
at main::(/usr/bin/bts:825)

Unfortunately, I can no longer investigate this issue as it looks like that my 
IP address is now blacklisted on Daniel's server:

$ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de 
usertag 1029588 + dod-test-with-tls
bts.pl: failed to open SMTPS connection to smtps://mail.wgdd.de
(Connection refused)
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(scripts/bts.pl:2849)
at main::(scripts/bts.pl:834)

On a hunch, I would guess that Daniel's server is configured to handle 
STARTTLS, which is not supported by bts. But I cannot verify this. 
In any case this does not explain why Daniel sees bts working with 
libio-socket-ssl-perl 2.077 but not with 2.078.

All the best

Bug#1033159: terminology: When using vim with Terminology the underline atribute gets turned on when scrolling.

[Jon Westgate]

Package: terminology
Version: 1.13.0-1
Severity: important

Dear Maintainer,

I noticed this bug a few months ago, but it seemed intermittent.
I can now trigger it 100% on multiple boxes.
Its rather annoying but very simple to trigger I'm not sure if it's a
bug in vim because it only seems to happen when using terminology in
vim. I'm running KDE / Plasma (I've not tried in gnome)
Nvi does not trigger this bug nore does Nano. Using vim with the linux
console, xterm rxvt and konsole does not produce this bug.

How to produce:
open vim inside terminology enit a file that is larger than the
terminal and requires scrolling (it shows best with a 2 page document
with a reasonable coverage of text) simply scroll up of down past the
current view point and you will note that new text has the underline
atribute set. Scrolling back up will result in off screen text being
rendered with underline attribute set as it comes back down into view.

This works even if you are connecting to another box over ssh.
If the underlined text is at the bottom of the page then if you exit vim
then the terminal continues to have underlined text.

Typing reset clears it.

I have my terminal set to 256 colour xterm.

Any ideas?
It's even doing it in this bug report.

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

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

Versions of packages terminology depends on:
ii  libc6 2.36-8
ii  libecore-con1 1.26.3-1+b1
ii  libecore-evas11.26.3-1+b1
ii  libecore-file11.26.3-1+b1
ii  libecore-imf1 1.26.3-1+b1
ii  libecore-input1   1.26.3-1+b1
ii  libecore-ipc1 1.26.3-1+b1
ii  libecore1 1.26.3-1+b1
ii  libedje1  1.26.3-1+b1
ii  libeet1   1.26.3-1+b1
ii  libefreet-bin 1.26.3-1+b1
ii  libefreet1a   1.26.3-1+b1
ii  libeina1a 1.26.3-1+b1
ii  libelementary11.26.3-1+b1
ii  libemotion1   1.26.3-1+b1
ii  libethumb-client-bin  1.26.3-1+b1
ii  libethumb-client1 1.26.3-1+b1
ii  libevas1  1.26.3-1+b1
ii  libevas1-engines-wayland  1.26.3-1+b1
ii  libevas1-engines-x1.26.3-1+b1
ii  terminology-data  1.13.0-1

terminology recommends no packages.

Versions of packages terminology suggests:
ii  libelementary-bin  1.26.3-1+b1

-- no debconf information

Bug#1033158: dracut-core: hard-depends kpartx, other dependencies for the modules are just recommends; please downgrade

[наб]

Package: dracut-core
Version: 059-4
Severity: minor
Tags: patch

Dear Maintainer,

I just got these NEWS:
  multipath-tools (0.8.5-2+deb11u1) bullseye-security; urgency=high
  
This uploaded fixes CVE-2022-41973:
The fix involves switching from /dev/shm to systemd-tmpfiles.
The tmpfs is mounted to /run/multipath.
  
If you have previously accessed /dev/shm directly in your setup,
please update to the new path to facilitate this change.
  
   -- Tobias Frost   Tue, 27 Dec 2022 09:46:24 +0100

I don't use multipath-tools, and never will. Or any part of that suite.
However:
  $ apt info kpartx | grep Source:
  Source: multipath-tools
  $ apt-cache rdepends --installed kpartx
  kpartx
  Reverse Depends:
dracut-core
dracut-core
dracut-core
  $ apt info dracut-core | grep -e Depends -e Recommends
  Depends: cpio, kmod, udev, kpartx, libkmod2 (>= 22~), e2fsprogs, libc6 (>= 
2.34)
  Recommends: cryptsetup, dmsetup, dmraid, lvm2, mdadm, console-setup, 
binutils, systemd, pigz, pkg-config

Odd! Especially given that the only modules that want kpartx (90multipath, 
90dmraid):
  $ grep -r kpartx
  debian/control:Depends: cpio, kmod, udev, kpartx, libkmod2, e2fsprogs, 
${shlibs:Depends}, ${misc:Depends}
  debian/changelog:  * control: add Depends on kpartx Closes: #636549
  pkgbuild/dracut.spec:Recommends: kpartx
  pkgbuild/dracut.spec:Requires: kpartx
  NEWS.md:- install kpartx's 11-dm-parts.rules
  test/TEST-14-IMSM/create-root.sh:[ -e "/dev/mapper/$s" ] && kpartx -a -p 
p "/dev/mapper/$s"
  test/TEST-14-IMSM/create-root.sh:[ -e "/dev/mapper/$s" ] && kpartx -a -p 
p "/dev/mapper/$s"
  modules.d/90multipath/module-setup.sh:require_binaries kpartx || return 1
  modules.d/90multipath/module-setup.sh:kpartx \
  modules.d/90multipath/module-setup.sh:66-kpartx.rules 
67-kpartx-compat.rules \
  modules.d/90dmraid/dmraid.sh:[ -e "/dev/mapper/$s" ] && kpartx -a 
"/dev/mapper/$s" 2>&1 | vinfo
  modules.d/90dmraid/module-setup.sh:require_binaries kpartx || return 1
  modules.d/90dmraid/module-setup.sh:inst_multiple -o kpartx
  modules.d/90dmraid/module-setup.sh:inst_rules 66-kpartx.rules 
67-kpartx-compat.rules

Have these check()s:
  $ awk '/check\(\)/,/^}/' modules.d/90{multipath,dmraid}/module-setup.sh
  check() {
  [[ $hostonly ]] || [[ $mount_needs ]] && {
  for_each_host_dev_and_slaves is_mpath || return 255
  }
  
  # if there's no multipath binary, no go.
  require_binaries multipath || return 1
  require_binaries kpartx || return 1
  
  return 0
  }
  check() {
  local holder
  local dev
  
  # if we don't have dmraid installed on the host system, no point
  # in trying to support it in the initramfs.
  require_binaries dmraid || return 1
  require_binaries kpartx || return 1
  
  [[ $hostonly ]] || [[ $mount_needs ]] && {
  for dev in "${!host_fs_types[@]}"; do
  [[ ${host_fs_types[$dev]} != *_raid_member ]] && continue
  
  DEVPATH=$(get_devpath_block "$dev")
  
  for holder in "$DEVPATH"/holders/*; do
  [[ -e $holder ]] || continue
  [[ -e "$holder/dm" ]] && return 0
  break
  done
  
  done
  return 255
  }
  
  return 0
  }

I.e. they require both their respective binary /and/ kpartx.

multipath is part of multipath-tools and dmraid is part of dmraid.
dmraid is a Recommends:. I don't have it installed. The module doesn't run for 
me:
  # dracut -f
  ...
  dracut: dracut module 'dmraid' will not be installed, because command 
'dmraid' could not be found!
  ...
I don't want to have kpartx installed, especially if it's full of privesc CVEs.
Please downgrade it to a Recommends:.

Patch attached.

Best,
наб

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

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

Versions of packages dracut-core depends on:
ii  cpio 2.13+dfsg-7.1
ii  dracut-core-kpartx [kpartx]  1.0
ii  e2fsprogs1.47.0-2
ii  kmod 30+20221128-1
ii  libc62.36-8
ii  libkmod2 30+20221128-1
ii  udev 252.6-1

Versions of packages dracut-core recommends:
ii  binutils   2.40-2
pn  console-setup  
pn  cryptsetup 
pn  dmraid 
ii  dmsetup2:1.02.185-2
pn  lvm2   
pn  mdadm  
ii  pigz   2.6-1
pn  pkg-config 
ii  systemd252.6-1

dracut-core suggests no packages.

-- no debconf in

Bug#1033157: bullseye-pu: package debian-archive-keyring/2021.1.1+deb11u1

[Jonathan Wiltshire]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-archive-keyr...@packages.debian.org, j...@debian.org
Control: affects -1 + src:debian-archive-keyring

[ Reason ]
The bookworm archive keys need adding to stable to ensure smooth
upgrades for users.

[ Impact ]
Users cannot upgrade.

[ Tests ]
Build-time consistency checks, manual testing.

[ Risks ]
Low risk, this is basically only data changes.

[ 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
diff -Nru debian-archive-keyring-2021.1.1/active-keys/add-bookworm-automatic 
debian-archive-keyring-2021.1.1+deb11u1/active-keys/add-bookworm-automatic
--- debian-archive-keyring-2021.1.1/active-keys/add-bookworm-automatic  
1970-01-01 01:00:00.0 +0100
+++ debian-archive-keyring-2021.1.1+deb11u1/active-keys/add-bookworm-automatic  
2023-03-18 14:53:41.0 +
@@ -0,0 +1,191 @@
+Comment: add bookworm automatic key (archive)
+Date: Thu, 16 Mar 2023 08:31:32 +
+Action: import
+Data: 
+  -BEGIN PGP PUBLIC KEY BLOCK-
+  
+  mQINBGPL0BUBEADmW5NdOOHwPIJlgPu6JDcKw/NZJPR8lsD3K87ZM18gzyQZJD+w
+  ns6TSXOsx+BmpouHZgvh3FQADj/hhLjpNSqH5IH0xY7nic9BuSeyKx2WvfG62yxw
+  XcFkwTxoWpF3tg0cv+kT4VA3MfVj5GebuS4F9Jv01WuGkxUllzdzeAoC70IYNOKV
+  +Av7hX5cOaCAgvDCQmhVnQ6Nz4fXdPdMHVodlPsKbv8ymVsfvb8UzQ6dl9w1gIu9
+  4S0FCQeEePSii23jHISYwku/f6huQGxSjAy8yxab0aZshl98c3pGGfOJHntmHwOG
+  gqV+Gm1hbcBjc6X8ybL2KEr/Lu4xAK3xSQmP+tO6MNxfBTCeo8fXRT95pqj7t3QH
+  Iu+LbVYrkLQ6St9mdOgUUsAdVYXJ3eh8Y+CfjmBywNRizOGHrEp8JsAcS0+a9yBL
+  +BYWhS4BL/EeeacRLT9kfzIqS1OD/RL/4Qbi2GLGFsiHaKFUn4xse20ZXq5XtEL6
+  ltQVIr/iAlBtdSOnge/ZkNvd3SQIyC2QBNAy67QutS8yiaCE2vtr8i5GQOu2fgr1
+  NJ0VjuwshmgJvbZ2m/9Zq1Yp1iMnPVJtOWcNxTZAWJDN4L5OdoqbaOkqS/+cgLy2
+  UTsc0A7cxt/2ugOtln/utXsfgb3Qno69yCuSbQmVM1NrwvZVxPIWi7B2gQARAQAB
+  iQJOBB8BCgA4FiEEuLgLW2I+q2rYd1xFt8XX1jUJR/gFAmPL0BcXDIABgOl28UpQ
+  ikjpyj/pvDciUsoc+WQCBwAACgkQt8XX1jUJR/jTMRAAt6Mltzz7xk7RGIGaF+ug
+  0QSoh9n07Y0oxEAb1cPSvo3o5wnxQ6ZYIukr2KTFkXaDh35XpXoA2Z9Uf6wz4h8B
+  nF8DWhbo+2sSq9au0J16bsLuIHfhzJWXSwyekHOrLiiiSfhjey9eQzgOT8jJsEjy
+  FzfxtMOTepXX8yQdp4SK3WYdVjAcbwjFGcbh5VqQIsr1+MdlaVchqWP1vm1ADvQF
+  C87hQjhpMzQoU7WVkJWsqlMuXh95h59h/SndBiHKXHQfs/LAM7M2K/fgS9+EbPWW
+  fC97/8SqpXheDsvCvueumTyzUCNXFpNGwUUA1qO6GTaMwHjaX/AeCaRMxCQcLdQ0
+  7b6zc13dqiMAAL1eSQ10TFP9kD2QoyPjF6lh0S5xshHWET5duw71KjYAAOGdv8J3
+  9DGMvT8OdL8UklIJy7KLjxJOjY21oPCHgx1cQKLONCgOAcQ4ZmzBOP8sWZ7ld8OV
+  Ke4c/bOqwbRMLNXUwuVJuejwvoypCOxbdlYUnfL633wVMQBM8ilog+2TydStV4AU
+  CQVsICw4iaXUU+B6gh1euvgvCW13q7pMFJDPbpC+EFC1Fl4RT+CFLE8XG0kXHQ3x
+  HWo+/b49x3MYv5wS33+NZpfdHEuHKwybfTIVshlPU8rXmrwmVXO9iRmAczjcoeYZ
+  OTI5EJz20PBi65wAdpAFVBeJAk4EHwEKADgWIQS4uAtbYj6rath3XEW3xdfWNQlH
+  +AUCY8vQFxcMgAH7+r21QbXclVvZum7bFs9bsSUlxAIHAAAKCRC3xdfWNQlH+KbZ
+  D/4uoBtdR5LdZGh5sDBjhcDJ+09vhagDh4/lLsiH5/HEmY5M0fwUTvnzV00Bsu3y
+  u/blyKaX/oram1jBzwucqkIXFx/KF6ErMkHBQi0w7Kqb+nY1s24rD6++VL/ZIA5A
+  CLoMxD/xWNN0GA3IMa5HquAxejhgpKB1Dm7QcEab2Jk2hnlCFBgmjun1xEqb2IO0
+  fmfXjREpRBbzvmOTCkEUm8CIikJy7CHmAIVOJnxQZyK5bua05fKZOJQvb7VmmhJw
+  /1eE5+VU0fMHbZDkVeL0LOAecpPGH3uCEXaf4J0Pu4jXCHqz9UPMNRawNWEcBRTZ
+  oq5M5GpRkIpPpt8j7jGoQaKM5bUxtsS0+8L56n03J5xWBy+yEQPYnBJs5n61/dcc
+  aRwqO47TJsADIqg7T5Q+v97+1xXzMc8KkTbtQatWdukNuVrbLNXlLYI/sPChqMtZ
+  J7yW9Qhz+ljJnBKkYTjG5OLjsInB80cNFOkZMjsj9gQgAagSwqll/IIXry0zKF/Z
+  A3ARmy7G5vjvqP8HjSWbcqbjdz27/H8Zn/HaGRK5GwoBS/4CyDiuvrq9bS6bk7E4
+  Ql6Ni2UF7brjEULiYfbMdL0HHaKHuU3rWBCZtFRyVJ3yUKP/UAdxtS8VwbkYBOIp
+  gS4Y6RwXeQmC9G6crnXR6hsODs5E47hiugf/HkhvyQ6CJokCTgQfAQoAOBYhBLi4
+  C1tiPqtq2HdcRbfF19Y1CUf4BQJjy9AYFwyAAYyCPe0QqoBBY54SEFrOjW4MFKRw
+  AgcAAAoJELfF19Y1CUf4uo0P/i+m8SnrFF7IcsppML6dsxOvioUt5dBbXgkSbCUh
+  dciW583S04mqS8iicMoUSXg+WKXWJ+UaAnfh6yWLcbeYpH8SZ+TX+J3WuLj4ECPe
+  MYfLGY4eehKIJqnEDfVqtoc8g5w9JxFglZBTZ/PJeyj6I2ovzVG1YH2ZER0cvRvi
+  tywWBP3edDBa/KPHzBVLaeWuuH28aAGHF2pHtEh+nDfQ/EblDlPUkGclnu79E82g
+  dl3W0GvcbMXccVIvik9IHPI042me4KJwy7X3qoNGbn3+XditIA+6rb1N+wGDdQkD
+  s9MvGmoQoxs5iFi5kW/AIdIMHCR+A6MMO4KGQ6E6UDd/DM3iFh2V+gavktk85sIk
+  Thy378l3JQRidRptifTJjESnyM/NUjN8JMb6peyn0xKyYE6uNK9cZAmbEWGCdZfp
+  62gPUo6dR7BHe2a1qJokvfSJdjZtczBuWotFs6EQcCuRDqpySzrLYitCNxNqJ0FG
+  +kryruObVXgr4y+r1C7+CczmGF0m8zp1BuGaT6pbx7X6VqazYSfOkQSk4Wyk89Ry
+  45RZmg79Mgv1s6NNz4ngW7LYNJgMZXwYHL99UiL47dOFBCIXTqVXURwU+BkVxwqZ
+  Bq10BWd+qdMPGl8hsA3zi64PJMg0u4YaWs/jasZaWaJI6tv/M1WsfQ3TCZrtT6YE
+  nhieiQJOBB8BCgA4FiEEuLgLW2I+q2rYd1xFt8XX1jUJR/gFAmPL0BgXDIABMJkR
+  vqlm0GEwUwRXEbTl/xWw/YICBwAACgkQt8XX1jUJR/ilGw//W+ckV1lt00dA+S2T
+  L7qaQehp//03GXnC4CRVEWalaoEylcqHlvyUiQc6+r44ZkoLTRSadNWt6EIISFaZ
+  OiIEDrzzpNUVu/9heQeJeeOzPOFQ0LBNI86xo8e1EmvWMBLDf6NGJZtoG1qBNIyJ
+  k0x7x51pOGf7h8xlvEDo3F0JNC5/N1FjtdAHdyA8HLQFkePIWHUm+h76lgF3Z5cE
+  3Myh7XA0NfKe33pgI7CWhbNiF62XhOMAVM6Lrjk+Zp7FWDplSiNu+J3TTjR0sAkp
+  H5Uf4V3i7zIhlVKKhV+Ktr5ojuj805U1tocrH68bBn4weLDfPzGp4rZ5aMoKqK+

Bug#1033025: unblock: socklog/2.1.0+repack-5

[Mathieu Mirmont]

On Sat, Mar 18, 2023 at 09:13:50AM +0100, Sebastian Ramacher wrote:
> On 2023-03-16 17:32:25 +0100, Mathieu Mirmont wrote:
> > On Thu, Mar 16, 2023 at 02:57:52PM +0100, Sebastian Ramacher wrote:
> > > Control: tags -1 moreinfo
> > > 
> > > Hi Mathieu
> > > 
> > > On 2023-03-15 23:05:39 +0100, Mathieu Mirmont wrote:
> > > > diff -Nru socklog-2.1.0+repack/debian/changelog 
> > > > socklog-2.1.0+repack/debian/changelog
> > > > --- socklog-2.1.0+repack/debian/changelog   2020-12-22 
> > > > 22:40:42.0 +0100
> > > > +++ socklog-2.1.0+repack/debian/changelog   2023-03-06 
> > > > 22:01:18.0 +0100
> > > > @@ -1,3 +1,15 @@
> > > > +socklog (2.1.0+repack-5) unstable; urgency=medium
> > > > +
> > > > +  * Various uninteresting changes
> > > 
> > > What are these uninteresting changes?
> > 
> > Sorry that's not the greatest description indeed. Looking at the git
> > commit this is:
> > 
> > - Use spaces instead of tabs to align columns in d/socklog.install and
> >   d/socklog-run.runit.
> 
> This is unnecessary noise at this stage of the freeze. For the next
> time, please defer such changes. Anyway, unblocked.

Yeah I agree, I was hoping to get it uploaded before the hard freeze
deadline. Otherwise I would have just pushed the one commit that
addressed the RC bug.

Thanks for unblocking.

Cheers,

-- 
Mathieu Mirmont 


signature.asc
Description: Digital signature

Bug#1033067: unblock: glide/2002.04.10ds1-21

[Jonathan Wiltshire]

severity 1033067 minor
user release.debian@packages.debian.org
usertag 1033067 bookworm-can-defer

On Thu, Mar 16, 2023 at 11:05:11PM +0100, Guillem Jover wrote:
> This non-key package does not currently contain autopkgtests.
> 
> These two releases include a couple of changes to make the package
> finally reproducible, as the generated shared libraries would change
> the optimized objects being linked to depending on the build system
> (for host=i386 build=amd64).

This feels like something for the first point release, it's not release
critical.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1031368: Accepted php8.2 8.2.4-1 (source) into unstable

[Salvatore Bonaccorso]

Source: php8.2
Source-Version: 8.2.4-1

Hi Ondrej,

This update fixes as well #1031368, closing manually. Can you make
sure the release team can accept it to bookworm?

If you do not forget, please as well mention the CVE id's fixed with
the upload, that makes tracking it much easier :)

REgards,
Salvatore

- Forwarded message from Debian FTP Masters 
 -

From: Debian FTP Masters 
Resent-From: debian-devel-chan...@lists.debian.org
Reply-To: debian-de...@lists.debian.org
Date: Thu, 16 Mar 2023 15:52:30 +
To: debian-devel-chan...@lists.debian.org
Subject: Accepted php8.2 8.2.4-1 (source) into unstable
Message-Id: 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 16 Mar 2023 15:24:40 +0100
Source: php8.2
Architecture: source
Version: 8.2.4-1
Distribution: unstable
Urgency: medium
Maintainer: Debian PHP Maintainers 
Changed-By: Ondřej Surý 
Changes:
 php8.2 (8.2.4-1) unstable; urgency=medium
 .
   * New upstream version 8.2.4
Checksums-Sha1:
 1c3a3f94ff8082b8813a429f9c0af6f5f07ed2df 5684 php8.2_8.2.4-1.dsc
 d564d284a5d2982e12b6108961b53cd67a5a5d3a 11991796 php8.2_8.2.4.orig.tar.xz
 ca31239391a1606ff7ead4b800dd7b0937544ad8 833 php8.2_8.2.4.orig.tar.xz.asc
 02ce04c2a19626b23f9ceb42c7e0364e1e99cd99 68464 php8.2_8.2.4-1.debian.tar.xz
 c6dedb3419e9d6ca098aa8d4beb897c54b7e0ccd 32425 php8.2_8.2.4-1_amd64.buildinfo
Checksums-Sha256:
 82a80c1d577a94ce2bc42007458629b45699f3ff5e0cf0642dcc86c7a9d4fb38 5684 
php8.2_8.2.4-1.dsc
 bc7bf4ca7ed0dd17647e3ea870b6f062fcb56b243bfdef3f59ff7f94e96176a8 11991796 
php8.2_8.2.4.orig.tar.xz
 d06a3c1d62347e07538a68c4cacc3adffdfc687800fb21226a166ff061f8a20e 833 
php8.2_8.2.4.orig.tar.xz.asc
 0ce2de0825cb73f300f0ef989ccdf88d328d4ab04433e3dfc74c11c5c9c6dca9 68464 
php8.2_8.2.4-1.debian.tar.xz
 607293d0352a7f5bfe3f40428f1f4ec4a8b7536f99549b8dd90a7821485a646a 32425 
php8.2_8.2.4-1_amd64.buildinfo
Files:
 e8175b9ad40d765b7c49428d016e562c 5684 php optional php8.2_8.2.4-1.dsc
 43c5fa2cf3428e9692cd9d424e71664f 11991796 php optional php8.2_8.2.4.orig.tar.xz
 9a3209241530ae9673bbc89f06589465 833 php optional php8.2_8.2.4.orig.tar.xz.asc
 ce69c5c515bb48b1b4ff25e97bcd1fbc 68464 php optional 
php8.2_8.2.4-1.debian.tar.xz
 634b068125bbf68e013adb4c7c469561 32425 php optional 
php8.2_8.2.4-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmQTNORfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcLQ/w//VBvPkvlDopic6Bv0xzTtClz+hjDmGdlYSQW5jJQtQwGCoXecPwVE505o
sMnyfpjl3mDNlSbIF4yYvlMxvFz0+SVapTVSkqgQ0HnFAKNOKhBJCL0b6tZdFxyW
zcisyir8tO7lHHKSYCllICZg/iZOiz5Of9NUGHzO9qhNmv8mQEKhRkS/5aP43VU4
qWIthvOD3lRP2do/ReGU9HkH/7hE85cuyTAUB3fF49OrkDyZy82LVCmmjSWUr6Uw
k0dr++ZJxjIcTsBx/HpGDUhaD2+YitK3Nb89PeGK67TvyO913N6Ey9NUtl2+s1/f
J9jnhuuYc5Hx5Xx17T3qRihoixOSm0jQz32lir4Iqlz8GApH7IHcmRaZsRkk3n61
td6fOS0xSzccBVgY/RCsmy9qCP4axkIdTPfuAKog03QmegvI3s4saqvwwqa7Zwmb
AwhOviv217WDcqr5et8yRnd+bS0AMY5h6tE3QGokTbBPQLiBMwWSYWkKYREst+Rv
XXQMEzUC3pLIRSEq36ZBAFqlzXj1aobFd9jH7Rj1RW5E41OZ4hwh+CGDh/bPbLvV
R+j3bGTdSFMU9dRqNEy++68XtQ9veYuMJsztN0rrH8PqIzAGOBg441f8s62r+W9f
sp71zHObJzVPSO9NDI4zC0mpNm8z+me06lVS1WhXm29hOtHXYhs=
=+GM0
-END PGP SIGNATURE-


- End forwarded message -

Bug#1033156: gtg: Global generic exception when opening recurring task

[WhilelM]

Package: gtg
Version: 0.6-2
Severity: normal




here's a traceback I encountered on 0.6 when trying to open/edit a recurring
task


**Context:** Global generic exception

```python-traceback
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/GTG/gtk/browser/main_window.py", line 
1060, in on_edit_active_task
self.app.open_task(tid)
  File "/usr/lib/python3/dist-packages/GTG/gtk/application.py", line 553, in 
open_task
editor = TaskEditor(requester=self.req, app=self, task=task,
 ^^^
  File "/usr/lib/python3/dist-packages/GTG/gtk/editor/editor.py", line 98, in 
__init__
self.recurring_menu = RecurringMenu(self.req, task.tid, self.builder)
  ^^^
  File "/usr/lib/python3/dist-packages/GTG/gtk/editor/recurring_menu.py", line 
45, in __init__
self.update_header()
  File "/usr/lib/python3/dist-packages/GTG/gtk/editor/recurring_menu.py", line 
121, in update_header
month_day=self.task.get_recurring_updated_date().strftime('%d')))
  ^^^
AttributeError: 'Date' object has no attribute 'strftime'
```

**Software versions:**
* Getting Things GNOME! 0.6.0
* CPython 3.11.2 (main, Feb 12 2023, 00:48:52) [GCC 12.2.0]
* GTK 3.24.37, GLib 2.74.4
* PyGLib 3.42.2, PyGObject 3.42.2
* Linux-6.1.0-6-amd64-x86_64-with-glibc2.36



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

Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gtg depends on:
ii  gir1.2-gtk-3.0 [gir1.2-gdk-3.0]  3.24.37-2
ii  gir1.2-gtksource-4   4.8.4-4
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-secret-1  0.20.5-3
ii  pdftk2.02-5+b1
ii  pdftk-java [pdftk]   3.3.2-1
ii  python3  3.11.2-1
ii  python3-caldav   0.11.0-1
ii  python3-cheetah  3.3.1-1
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1
ii  python3-liblarch 3.2.0-3
ii  python3-lxml 4.9.2-1+b1
ii  texlive-extra-utils  2022.20230122-2
ii  texlive-latex-base   2022.20230122-2

gtg recommends no packages.

gtg suggests no packages.

-- no debconf information

Bug#1033059: logcheck: NEWS advice how to deal with timestamps in different formats

[Holger Levsen]

On Thu, Mar 16, 2023 at 06:00:06PM +, Holger Levsen wrote:
> aaah, thanks! I only checked /usr/share/doc/logcheck/NEWS.Debian.gz
> but not /usr/share/doc/logcheck-database/NEWS.Debian.gz

now that I read it and followed the advice and the very nice
sed example there, I can they that it worked flawlessly and was
very easy to do. Thank you for that NEWS entry!

> so maybe reassign this bug to src:release-notes?

this question is still open... though maybe cloning the bug is even 
better, I'd really appreciated a small pointer to logcheck-database's NEWS
file in the NEWS for logcheck...


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Bottled water companies don't produce water, they produce plastic bottles.


signature.asc
Description: PGP signature

Bug#1032916: ca-certificates: More expired CA certificates

[Philipp Hahn]

Package: ca-certificates
Version: 20210119
Followup-For: Bug #1032916

Dear fellow Debian Maintainer,

FYI: ca-certificates conatins many more CA certificates, which are
expired by now:

> $ for crt in /usr/share/ca-certificates/mozilla/*; do openssl x509 -in "$crt" 
> -noout -checkend 0 >/dev/null || printf "%s\t%s\n" "$(openssl x509 -noout 
> -enddate -in "$crt")" "$crt";  done
> notAfter=Dec 15 08:00:00 2021 GMT   
> /usr/share/ca-certificates/mozilla/Cybertrust_Global_Root.crt
> notAfter=Sep 30 14:01:15 2021 GMT   
> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
> notAfter=Mar  3 12:09:48 2023 GMT   
> /usr/share/ca-certificates/mozilla/E-Tugra_Certification_Authority.crt
> notAfter=Dec 15 08:00:00 2021 GMT   
> /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt
> notAfter=Mar 17 18:33:33 2021 GMT   
> /usr/share/ca-certificates/mozilla/QuoVadis_Root_CA.crt
> notAfter=Apr  6 07:29:40 2021 GMT   
> /usr/share/ca-certificates/mozilla/Sonera_Class_2_Root_CA.crt
> notAfter=Dec  8 11:10:28 2022 GMT   
> /usr/share/ca-certificates/mozilla/Staat_der_Nederlanden_EV_Root_CA.crt

Especially the "DST_Root_CA_X3" is probelmatic as they provided the
Let's encrypt cross-sign certificate:


At least `sa-update` from SpamAssassin fails to contact
https://spamassassin.apache.org/

> # curl -I https://spamassassin.apache.org/updates/MIRRORED.BY
> curl: (60) SSL certificate problem: certificate has expired

It works after removing the "DST Root CA X3":

> [ -f /etc/ca-certificates.conf/etc/ca-certificates.conf ] &&
> sed -i -e 's=^mozilla/DST_Root_CA_X3.crt=!&=' /etc/ca-certificates.conf &&
> update-ca-certificates ||
> true

1. Why are these old CAs still included?
   I know of some implementations, where the dates are not checked, so
   for them the expired trust anchors would still work.

2. Can we have an option to `update-ca-certificate` to remove/disable
   expired CAs?

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

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  openssl1.1.1n-0+deb11u4

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/new_crts:
* ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, 
mozilla/AC_RAIZ_FNMT-RCM.crt, mozilla/Actalis_Authentication_Root_CA.crt, 
mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, 
mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, 
mozilla/Amazon_Root_CA_1.crt, mozilla/Amazon_Root_CA_2.crt, 
mozilla/Amazon_Root_CA_3.crt, mozilla/Amazon_Root_CA_4.crt, 
mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Certigna.crt, mozilla/Certigna_Root_CA.crt, 
mozilla/certSIGN_ROOT_CA.crt, mozilla/certSIGN_Root_CA_G2.crt, 
mozilla/Certum_Trusted_Network_CA_2.crt, mozilla/Certum_Trusted_Network_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, 
mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/Cybertrust_Global_Root.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_Trusted_Root_G4.crt, mozilla/DST_Root_CA_X3.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, mozilla/EC-ACC.crt, 
mozilla/emSign_ECC_Root_CA_-_C3.crt, mozilla/emSign_ECC_Root_CA_-_G3.crt, 
mozilla/emSign_Root_CA_-_C1.crt, mozilla/emSign_Root_CA_-_G1.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G2.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G4.crt, 
mozilla/ePKI_Root_Certification_Authority.crt, 
mozilla/e-Szigno_Root_CA_2017.crt, mozilla/E-Tugra_Certification_Authority.crt, 
mozilla/GDCA_TrustAUTH_R5_ROOT.crt, mozilla/Global_Chambersign_Root_-_2008.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R4.crt, 
m

Bug#1033155: migration test fails when EC key present in test keyrings

[Jonathan Wiltshire]

Source: gnupg2
Version: 2.2.40-1
Severity: important
Tags: patch
X-Debbugs-Cc: j...@debian.org

Hi,

The stable release key for bookworm is EC, and this causes gpg1 to bail
out when it is imported as part of the migration test. Attached patch
limits the keyrings used to the archive's automatic keys, which are
still RSA.


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

Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Index: gnupg2-2.2.40/debian/tests/migration
===
--- gnupg2-2.2.40.orig/debian/tests/migration
+++ gnupg2-2.2.40/debian/tests/migration
@@ -11,7 +11,7 @@ gpg1=(gpg1 --homedir "$GPG_HOME" --batch
 mkdir "$GPG_HOME"
 chmod 700 "$GPG_HOME"
 
-cat /usr/share/keyrings/debian-archive-*.gpg | "${gpg1[@]}" --import
+cat /usr/share/keyrings/debian-archive-*-automatic.gpg | "${gpg1[@]}" --import
 "${gpg1[@]}" --list-keys
 "${gpg[@]}" --list-keys > "$DIR/key.list.before"
 migrate-pubring-from-classic-gpg "$GPG_HOME"

Bug#1033154: aspell-en: should not have /var/lib files in the package

[Russell Coker]

Package: aspell-en
Version: 2020.12.07-0-1
Severity: minor

The FHS describes /var/lib as "State information. Persistent data modified by
programs as they run (e.g., databases, packaging system metadata, etc.)."

The files that are included in a package are expected not to change in normal
operation and therefore aren't "modified by programs".  So /var/lib isn't the
right place for this.  Maybe /usr/lib would be the right place.

One reason that this matters is for security systems that treat /usr and /var
differently.

-- 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-6-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 aspell-en depends on:
ii  aspell   0.60.8-4+b1
ii  dictionaries-common  1.29.4

aspell-en recommends no packages.

aspell-en suggests no packages.

-- no debconf information

Bug#1033039: kde-config-flatpak: Verified

[Matthew Adie]

Package: kde-config-flatpak
Version: 5.27.2-1
Followup-For: Bug #1033039

Dear Maintainer,

I can verify this bug.  I have installed the kde-config-flatpak package
and I can access the "Flatpak Permissions Settings", but when I select
an application from the list all I get is "Select an application from the
list to view it's permissions here".

I also cannot find any information on a missing dependecy or setting
that might be preventing me from accessing the permissions.

Matthew


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

Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 kde-config-flatpak depends on:
ii  libc6   2.36-8
ii  libflatpak0 1.14.3-1
ii  libglib2.0-02.74.6-1
ii  libkf5configcore5   5.103.0-1
ii  libkf5coreaddons5   5.103.0-1
ii  libkf5i18n5 5.103.0-1
ii  libkf5quickaddons5  5.103.0-1
ii  libqt5core5a5.15.8+dfsg-3
ii  libqt5qml5  5.15.8+dfsg-3
ii  libstdc++6  12.2.0-14
ii  systemsettings  4:5.27.2-1

kde-config-flatpak recommends no packages.

kde-config-flatpak suggests no packages.

-- no debconf information

Bug#1031802: fuse3: inaccurate information in symbols file (was: Re: libvirt-daemon-driver-lxc: Incorrect dependencies)

[Andrea Bolognani]

On Thu, Feb 23, 2023 at 01:03:50AM +0100, Vincent Danjean wrote:
> After doing a partial upgrade of my system (i.e. only libvirt-daemon
> with its required dependencies), libvirtd refused to start.
> In systemd journal, I can see:
> 
> févr. 23 00:53:32 eyak libvirtd[3010536]: internal error: Failed to load 
> module 
> '/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_lxc.so': 
> /usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_lxc.so: 
> undefined symbol: fuse_new_31, version FUSE_3.1
> 
> Upgrading libfuse3-3 from 3.12.0-1 to 3.14.0-2 fixed the problem.
> libvirt-daemon-driver-lxc should bump its dependency on libfuse3-3.
> For now, there is:
> Depends: [...] libfuse3-3 (>= 3.2.3) [...]
> 
> If this dependency is automaticcaly generated, then it probably
> means there is a bug in the libfuse3-3 package (its shlibs file)

Hi Vincent,

thanks for taking the time to report this issue, and sorry it took me
a few weeks to get back to you.

After successfully reproducing it by downgrading my machine to
libvirt 9.0.0-1 and fuse3 3.12.0-1 builds obtained from snapshot.d.o,
I have spent some time trying to figure out the root cause.

tl;dr it's indeed an issue with fuse3's symbols file.

Comparing the exported symbols for libfuse3.so.3, we can see that
3.12.0-1 contains

  00013af0 gDF .text0111  FUSE_3.1
fuse_new_30
  00013af0 gDF .text0111 (FUSE_3.0)   fuse_new
  000134f0 gDF .text05f8  FUSE_3.1fuse_new

and 3.14.0-2 contains

  00014a70 gDF .text0111  FUSE_3.1
fuse_new_30
  00014470 gDF .text05f8  FUSE_3.1
fuse_new_31
  00014a70 gDF .text0111 (FUSE_3.0)   fuse_new
  00014470 gDF .text05f8  FUSE_3.1fuse_new

Notice how fuse_new_31, the function that libvirt_driver_lxc.so
references, only shows up in the latter.

Looking at the build log for libvirt 9.0.0-1

  
https://buildd.debian.org/status/fetch.php?pkg=libvirt&arch=amd64&ver=9.0.0-1&stamp=1674930232&raw=0

we can see that it was built against fuse3 3.13.0-2. That version
exports the same symbols as 3.14.0-2, so we can use them
interchangeably for the purpose of this discussion.

Now, there are some shenanigans in include/fuse.h from version 3.13.0
onwards that result in libvirt (which defines FUSE_USE_VERSION=31 in
its source) referencing fuse_new_31@FUSE_3.1. If you look at older
builds of libvirt, for example 8.10.0-3 (which was built against
fuse3 3.12.0-2), you'll see that fuse_new@FUSE_3.1 is referenced
instead.

To be honest I haven't looked too hard at the logic there, but the
outcome is self-apparent. Building against fuse3 3.13 results in
picking up the new symbol, which 3.12 didn't have, and so libvirt
will only work with fuse3 >= 3.13.

This wouldn't be a problem per se: libraries introduce new symbols
all the time, and once programs start referencing them it's expected
that they won't work with older versions of the library.

In this case, however, as you've noticed libvirt-daemon-driver-lxc
contains an inaccurate dependency: it claims that it can work with
fuse3 >= 3.2.3, while we've just demonstrated that it really needs
fuse3 >= 3.13.0-1. Why is this happening?

Comparing the upstream version scripts for fuse 3.12 and 3.13, we can
see the following differences:

  --- 12/lib/fuse_versionscript 2022-09-08 12:02:45.0 +0200
  +++ 13/lib/fuse_versionscript 2023-01-13 11:33:35.0 +0100
  @@ -39,6 +39,7 @@
fuse_session_new;
fuse_main_real;
fuse_mount;
  + fuse_session_custom_io;
fuse_session_mount;
fuse_new;
fuse_opt_insert_arg;
  @@ -139,6 +140,7 @@
fuse_lib_help;
fuse_invalidate_path;
fuse_new_30;
  + fuse_new_31;
fuse_new;
   } FUSE_3.0;
  
  @@ -184,6 +186,7 @@
fuse_parse_cmdline;
fuse_parse_cmdline_30;
fuse_parse_cmdline_312;
  + fuse_lowlevel_notify_expire_entry;
   } FUSE_3.4;
  
   # Local Variables:

In other words, upstream developers have retroactively added symbols
(fuse_new_31) to existing symbol groups (FUSE_3.1). This was probably
done with good intentions, as the name of the function clearly
indicates that it was introduced in version 3.1 and the fact that it
was missing from the symbol group was almost certainly a bug.
However, addressing the issue the way they've done it also has the
unintended consequence that you've experienced.

I believe it should be possible to work around this in Debian by
adding an entry like

  fuse_new_31@FUSE_3.1 3.13.0

to debian/libfuse3-3.symbols, but really this looks like an upstream
bug in my opinion: even if the function was present in the source
code all the way back

Bug#1025453: Is there any update

[graeme vetterlein]

I see this is marked as the only "important" bug in pipewire.


I, for one, have had no sound for the past 4 months. Not personally 
critical as it's an unstable dev system, not main dev machine.



But I'm guessing this is being targeted as the new "sound system" in 
Debian 12 . Is it being


worked on?  Is there a major problem?


I'm wondering if pipewire is no longer destined for "Debian 12" ?


--


Graeme

Bug#1033075: unblock: strongswan/5.9.8-5

[Yves-Alexis Perez]

On Sat, 2023-03-18 at 09:04 +0100, Sebastian Ramacher wrote:
> Could you please provide a diff between testing und unstable? Thanks

Sure, here it is.
-- 
Yves-Alexis
diff --git a/debian/changelog b/debian/changelog
index 0c44889a4f..d652c79fa1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+strongswan (5.9.8-5) unstable; urgency=medium
+
+  * No-change upload for source-only upload.
+
+ -- Yves-Alexis Perez   Fri, 03 Mar 2023 18:56:58 +0100
+
+strongswan (5.9.8-4) unstable; urgency=medium
+
+  * d/patches: libtls-Fix-authentication-bypass-and-expired-pointer added.
+Fix authentication bypass and use-after-free in libtls (CVE-2023-26463)
+  * d/control: replace lsb-base dependency by sysvinit-utils
+  * d/control: update standards version to 4.6.2
+
+ -- Yves-Alexis Perez   Sun, 26 Feb 2023 09:40:09 +0100
+
 strongswan (5.9.8-3) unstable; urgency=medium
 
   * d/tests: also drop _copyright test since the util is gone as well
diff --git a/debian/control b/debian/control
index 8d79682193..3035fc5818 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: net
 Priority: optional
 Maintainer: strongSwan Maintainers 
 Uploaders: Yves-Alexis Perez 
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/debian/strongswan
 Vcs-Git: https://salsa.debian.org/debian/strongswan.git
 Build-Depends: bison,
@@ -209,7 +209,7 @@ Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Depends: adduser,
  libstrongswan (= ${binary:Version}),
- lsb-base (>= 3.0-6),
+ sysvinit-utils (>= 3.05-3),
  ${misc:Depends},
  ${shlibs:Depends}
 Recommends: strongswan-charon
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 48731a6968..b872cdb2e8 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,4 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
-upstream-branch = upstream/latest
+debian-branch = debian/bookworm
+upstream-branch = upstream/bookworm
diff --git a/debian/patches/0005-libtls-Fix-authentication-bypass-and-expired-pointer.patch b/debian/patches/0005-libtls-Fix-authentication-bypass-and-expired-pointer.patch
new file mode 100644
index 00..5826e2e64a
--- /dev/null
+++ b/debian/patches/0005-libtls-Fix-authentication-bypass-and-expired-pointer.patch
@@ -0,0 +1,43 @@
+From: Tobias Brunner 
+Date: Fri, 17 Feb 2023 15:07:20 +0100
+Subject: libtls: Fix authentication bypass and expired pointer dereference
+
+`public` is returned, but previously only if a trusted key was found.
+We obviously don't want to return untrusted keys.  However, since the
+reference is released after determining the key type, the returned
+object also doesn't have the correct refcount.
+
+So when the returned reference is released after verifying the TLS
+signature, the public key object is actually destroyed.  The certificate
+object then points to an expired pointer, which is dereferenced once it
+itself is destroyed after the authentication is complete.  Depending on
+whether the pointer is valid (i.e. points to memory allocated to the
+process) and what was allocated there after the public key was freed,
+this could result in a segmentation fault or even code execution.
+
+Fixes: 63fd718915b5 ("libtls: call create_public_enumerator() with key_type")
+Fixes: CVE-2023-26463
+---
+ src/libtls/tls_server.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/src/libtls/tls_server.c b/src/libtls/tls_server.c
+index c9c3009..573893f 100644
+--- a/src/libtls/tls_server.c
 b/src/libtls/tls_server.c
+@@ -183,11 +183,11 @@ public_key_t *tls_find_public_key(auth_cfg_t *peer_auth, identification_t *id)
+ 	cert = peer_auth->get(peer_auth, AUTH_HELPER_SUBJECT_CERT);
+ 	if (cert)
+ 	{
+-		public = cert->get_public_key(cert);
+-		if (public)
++		current = cert->get_public_key(cert);
++		if (current)
+ 		{
+-			key_type = public->get_type(public);
+-			public->destroy(public);
++			key_type = current->get_type(current);
++			current->destroy(current);
+ 		}
+ 		enumerator = lib->credmgr->create_public_enumerator(lib->credmgr,
+ 			key_type, id, peer_auth, TRUE);
diff --git a/debian/patches/series b/debian/patches/series
index 3bd034cee4..488dca9c13 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 03_systemd-service.patch
 04_disable-libtls-tests.patch
 dont-load-kernel-libipsec-plugin-by-default.patch
+0005-libtls-Fix-authentication-bypass-and-expired-pointer.patch


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

Bug#1033001: darktable: Missing application icon after launching

[Guy Rutenberg]

On Sat, 18 Mar 2023 at 12:42, David Bremner  wrote:

>
>
> For the record, this issue is wayland specific.
>
> Adding
>
> StartupWMClass=darktable
>
> to the end of /usr/share/applications/org.darktable.darktable.desktop
> seems to fix it for me.
>
>
Thanks, David, that seems to fix it for me as well.

Bug#1033077: keys from /usr/share/keyrings/debian-archive-keyring.gpg are missing from /etc/apt/trusted.gpg.d

[Jonathan Wiltshire]

Hi,

On Fri, Mar 17, 2023 at 01:07:17PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> could you give me a quick notice whether the missing keys are intentional or 
> an
> oversight? If it's the former, I need to start working on a way for mmdebstrap
> to cope with this situation which will be a bit tricky because the part of the
> code that relies on it is quite complex and was already the source of a number
> of bugs in the past...

Intentional, but consequences unintended. Sorry about the disruption.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1033153: Old gpg variant of apt/trusted.gpg.d buster keys not removed

[David Kalnischkies]

Package: debian-archive-keyring
Version: 2023.2
Severity: normal
Tags: patch

Hi,

2023.2 reinstanced the buster keys, but ships them as asc file as the
rest, while in a later commit removes the cleanup of the gpg files, so
that an upgrader who has skipped 2023.1 has the obsolete gpg conf files
remaining. While mostly harmless it should be cleaned up properly as
in the grant scheme of things most people will skip the 2023.1 release…


I have push (well updated) an MR request implementing this clean up at:
https://salsa.debian.org/release-team/debian-archive-keyring/-/merge_requests/3
(Although I was as of yet to lazy to login to salsa again and update
 the MR description as it isn't as pointless as it once was. I might
 have but I get the impression MRs aren't followed so I invested the
 time into this bugreport instead)


I built+tested this both with an upgrade from 2023.1 as well as 2023.2,
but only very lightly; at the very least apt is still happy and the
files are gone for me as intended.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#717825: please allow ghostscript to cross build

[Håvard F . Aasen]

Control: tags -1 fixed-upstream patch
Control: forwarded -1 
https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=4c3575346b9c7d394ebc73b4e5fabebadd8877ec


On Thu, 25 Jul 2013 15:03:50 +0200 Matthias Klose  wrote:
> Package: ghostscript
> Version: 9.05~dfsg-6.3
> Severity: wishlist
> User: debian-cr...@lists.debian.org
> Usertags: cross-build
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu saucy
> 
> Please allow ghostscript to cross build. There are unfortunately many packages
> having ghostscript in their build dependencies, not in their indep build
> dependencies.
> 
> 
> 

Though not the original issue, but a cross-build problem resurfaces with
the latest version of Ghostscript, 10.00.0.

It is fixed upstream, two lines in 'configure.ac', but we are now late
in the freeze and Ghostscript is a key package, which means we need an
approved unblock request to get the changes in.

Helmut, do you have an opinion on the importance of this issue?


Håvard

Bug#1033152: ITP: obs-3d-effect -- plugin for OBS Studio to add a static 3D effect to sources

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, Exeldro 

* Package name: obs-3d-effect
  Version : 0.0.2
  Upstream Contact: Exeldro 
* URL : https://obsproject.com/forum/resources/3d-effect.1692/
* License : GPL-2
  Programming Lang: C
  Description : plugin for OBS Studio to add a static 3D effect to sources

 This plugin provides a filter that creates a static 3D effect over a
 source. In other words is possible to rotate a source around three axis.
 Also is possible to move the source over three axis and scale it over
 two axis.

Bug#941966: Hibernate bug still occuring?

[Tomas Pospisek]

Hi Thorsten,

does the bug you described in https://bugs.debian.org/941966 still occur? 
I.e.:


* do you still have that system?
* did you maybe upgrade it to a more recent bullseye kernel?

Greetings,
*t

Bug#970819: Hibernate bug still occuring?

[Tomas Pospisek]

Hi Cameron,

does the bug you described in https://bugs.debian.org/970819 still occur? 
I.e.:


* do you still have that system?
* did you maybe upgrade it from Debian buster to bullseye?

Greetings,
*t

Bug#929077: Hibernate bug still occuring?

[Tomas Pospisek]

Hi Chris,

does the bug you described in https://bugs.debian.org/929077 still occur? 
I.e.:


* do you still have that system?
* did you maybe upgrade it from Debian buster to bullseye?

Greetings,
*t

Bug#1033001: darktable: Missing application icon after launching

[David Bremner]

There is a relevant pull request upstream:

  https://github.com/darktable-org/darktable/pull/13961

Bug#929077: Hibernate bug still occuring?

[Chris Danis]

Hi Tomas,

Unfortunately the motherboard of this system has long since failed, before
bullseye was released.

Fine by me if you want to close this bug :)

On Sat, Mar 18, 2023 at 7:08 AM Tomas Pospisek  wrote:

> Hi Chris,
>
> does the bug you described in https://bugs.debian.org/929077 still occur?
> I.e.:
>
> * do you still have that system?
> * did you maybe upgrade it from Debian buster to bullseye?
>
> Greetings,
> *t
>

Bug#1026445: mutter: test failure on armhf and sometimes armel: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' failed

[Diederik de Haas]

Hi Simon,

On Tue, 20 Dec 2022 11:47:10 + Simon McVittie  wrote:
> Source: mutter
> Version: 43.2-1
> Tags: ftbfs
> 
> Recent uploads of mutter have had a FTBFS on armhf and sometimes armel,
> with this test failure in "mutter:core+mutter/wayland / xwayland":
> 
> > mutter-xwayland: ../../src/xcb_io.c:626: _XAllocID: Assertion 
> > `ret != inval_id' failed.

I assume this is a PEBKAC issue, but I got this error too in a different 
condition and as such it might help with this bug. If not, please ignore.

I cloned mutter's Salsa repo and added Salsa's default CI pipeline and it 
consistently fails on the 'build i386' job in the same test case 
("mutter:core+mutter/wayland / xwayland") with the same assertion failure.
See https://salsa.debian.org/diederik/mutter/-/jobs/4063218

I _think_ Salsa's CI runners run on amd64 and thus fails on an i386 job.
I also _think_ that armhf and armel are (often?) build on an arm64 native 
host, but this could be dependent on which specific host it happens to get 
build and thus cause the inconsistent error/non-error situation?

HTH and if not, sorry for the noise,
  Diederik


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

Bug#1032977: unblock: apache2/2.4.56-1

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo

hi Sebastian,

On Sat, Mar 18, 2023 at 09:17:25AM +0100, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> Hi security team
> 
> On 2023-03-15 06:46:32 +0400, Yadd wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: apac...@packages.debian.org
> > Control: affects -1 + src:apache2
> > 
> > Please unblock package apache2
> > 
> > [ Reason ]
> > Apache2 < 2.4.56 is vulnerable to 2 CVE, the major is CVE-2023-25690
> > (bypass access control using HTTP Request Smuggling attack)
> 
> What's the plan regarding apache2 in bookworm? Will future DSAs update
> apache2 with update bugfix releases?

Yes that is the plan. We do have e.g. already for bullseye-security
2.4.56-1~deb11u1 pending (we were waiting to move the version to
bookworm and get some more coverage).

The plan for bookworm is the same and do sas we switched for bullseye.

Regards,
Salvatore

Bug#1033001: darktable: Missing application icon after launching

[David Bremner]

Guy Rutenberg  writes:

> Package: darktable
> Version: 4.2.1-3
> Severity: normal
> X-Debbugs-Cc: guyrutenb...@gmail.com
>
> Dear Maintainer,
>
> Under GNOME (43.3), the Darktable icon is visible when searching for the app,
> but once the window is spawned, it is associated with a generic missing icon
> (for example in Alt+Tab or the Activities overview).
>
> The associated wmclass is "darktable", which seems fine. Not sure why the icon
> disappears.
>
> Thanks,
> Guy
>

For the record, this issue is wayland specific.

Adding

StartupWMClass=darktable

to the end of /usr/share/applications/org.darktable.darktable.desktop
seems to fix it for me.

Bug#981454: (no subject)

[Alexander Galanin]

This version is two years old. May be it's a time to package it for 
unstable?


--
Alexander Galanin

Bug#1031868: kde-cli-tools: kstart5 : does not return after launching command since upgrade to KDE Fralework 5.103

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce this issue and found a difference between
a minimal Bookworm VM with just running jwm window manager and my
regular Plasma desktop.

In the minimal VM a `kstart5 kcalc` returns immediately,
while at my regular Plasma desktop it blocks until the started
application is closed.

I found in the non-blocking case `KStart::windowAdded` gets executed
and therefore `QCoreApplication::exit` is called.

This seems to be caused by having useRule to be true
in the `KStart::KStart` constructor,
and therefore the connect call is not reached.

Kind regards,
Bernhard


(rr) bt
#0  0x7ffb802b1860 in QCoreApplication::exit 
(returnCode=returnCode@entry=0) at kernel/qcoreapplication.cpp:1430
#1  0x55a5e93fd065 in KStart::windowAdded (this=0x7fff2864b760, w=6291470) 
at ./kstart/kstart.cpp:201
#2  0x7ffb802e8f4f in QtPrivate::QSlotObjectBase::call (a=0x7fff2864adc0, 
r=0x7fff2864b760, this=0x55a5e9b58230) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#3  doActivate (sender=0x7ffb8174a440 <(anonymous 
namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal_index=4, 
argv=0x7fff2864adc0) at kernel/qobject.cpp:3923
#4  0x7ffb802e21ef in QMetaObject::activate (sender=sender@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
m=m@entry=0x7ffb81748700 , 
local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fff2864adc0) at 
kernel/qobject.cpp:3983
#5  0x7ffb8170e522 in KWindowSystem::windowAdded (this=this@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
_t1=, _t1@entry=6291470) at 
./obj-x86_64-linux-gnu/src/KF5WindowSystem_autogen/EWIEGA46WW/moc_kwindowsystem.cpp:409
#6  0x7ffb7b07363d in NETEventFilter::addClient (this=0x55a5e9b6baf0, 
w=6291470) at ./src/platforms/xcb/kwindowsystem.cpp:412
#7  0x7ffb8172ea51 in NETRootInfo::update (this=0x55a5e9b6baf0, 
properties=..., properties2=...) at ./src/platforms/xcb/netwm.cpp:2033
#8  0x7ffb7b071af7 in NETEventFilter::activate (this=) at 
./src/platforms/xcb/kwindowsystem.cpp:183
#9  KWindowSystemPrivateX11::init (this=this@entry=0x7ffb74006730, 
what=what@entry=KWindowSystemPrivateX11::INFO_BASIC) at 
./src/platforms/xcb/kwindowsystem.cpp:575
#10 0x7ffb7b071d4c in KWindowSystemPrivateX11::connectNotify 
(this=0x7ffb74006730, signal=...) at ./src/platforms/xcb/kwindowsystem.cpp:536
#11 0x7ffb8171fc35 in KWindowSystem::connectNotify (this=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
signal=...) at ./src/kwindowsystem.cpp:380
#12 0x7ffb802dea6a in QObjectPrivate::connectImpl (sender=sender@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal_index=4, 
receiver=receiver@entry=0x7fff2864b760, slot=slot@entry=0x7fff2864b670, 
slotObj=slotObj@entry=0x55a5e9b58230, type=, types=, 
senderMetaObject=) at kernel/qobject.cpp:5108
#13 0x7ffb802ded45 in QObject::connectImpl (sender=0x7ffb8174a440 <(anonymous 
namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
signal=signal@entry=0x7fff2864b660, receiver=receiver@entry=0x7fff2864b760, 
slot=slot@entry=0x7fff2864b670, slotObj=0x55a5e9b58230, type=Qt::AutoConnection, types=0x0, 
senderMetaObject=) at kernel/qobject.cpp:5038
#14 0x55a5e93fc7bb in QObject::connect (type=Qt::AutoConnection, slot=(void (KStart::*)(KStart * const, 
unsigned long long)) 0x55a5e93fcfc0 , 
receiver=0x7fff2864b760, signal=(void (KWindowSystem::*)(KWindowSystem * const, unsigned long long)) 
0x7ffb8170e4e0 , sender=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:268
#15 KStart::KStart (this=0x7fff2864b760) at ./kstart/kstart.cpp:78
#16 0x55a5e93fac84 in main (argc=, argv=) at 
./kstart/kstart.cpp:424


kde-cli-tools-5.27.2/kstart/kstart.cpp
62  KStart::KStart()
63  : QObject()
64  {
65  bool useRule = false;
66
67  #ifdef HAVE_X11
68  if (QX11Info::isPlatformX11()) {
69  NETRootInfo i(QX11Info::connection(), NET::Supported);
70  useRule = i.isSupported(NET::WM2KDETemporaryRules);
71  }
72  #endif
73
74  if (useRule) {
75  sendRule();
76  } else {
77  // connect to window add to get the NEW windows
78  connect(KWindowSystem::self(), &KWindowSystem::windowAdded, this, 
&KStart::windowAdded);
79  }

Bug#1032429: RFS: radsecproxy/1.9.2-2 -- RADIUS protocol proxy supporting RadSec

[Sven Hartge]

On Mon, 6 Mar 2023 17:02:07 +0100 Sven Hartge  wrote:


Changes since the last upload:

  radsecproxy (1.9.2-2) unstable; urgency=medium
  .
* Improve logcheck patterns to reduce noise
* Make logcheck rules compatible with all syslog timestamp formats



I really would like to get those changes into Bookworm to avoid 
unnecessary mail spam for those using logcheck.


If anyone could quickly review the changes and do an upload, this would 
be appreciated tremendously.


Thank you!

Grüße,
Sven.

Bug#1000794: Intent to NMU fakeroot to fix longstanding l10n bugs (again)

[Helge Kreutzmann]

Hello Clint,
On Sun, Mar 12, 2023 at 10:29:56AM +0100, Helge Kreutzmann wrote:
> I intend to NMU fakeroot end of next week to fix longstanding l10n
> bugs again. My previous NMU (1.30.1-1.1) was ignored in subsequent 
> uploads by you and without any comment.
> 
> The changelog would be something like the following:
> 
>  fakeroot (1.31-1.1) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Update manpage translation
>  - German translation.
>Thanks Erik Pfannenstein (Closes: #977854)
>  - Portuguese translation.
>Thanks Américo Monteiro (Closes: #1000794)
> 
> Of course, a maintainer upload instead would be highly welcome as 
> well. If you have any questions about the patches, do not hesitate to
> ask me.

I just send this to my sponsor (in CC). 

I intend to ask for an unblock next weekend, after it has been a few
days in unstable. As the translation itself was already in unstable
for ~ 1 month, and is a documentation change only, I'm rather
confident.

Greetings

  Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1033097: im-config: Fcitx5 does not start automatically in KDE plasma Wayland

[Gunnar Hjalmarsson]

On 2023-03-18 08:54, Gunnar Hjalmarsson wrote:

Is there some buggy systemd feature, which takes over XDG autostart
files, and which KDE/Plasma makes use of while GNOME does not?


It looks like that's close to the truth. I googled around, and found a 
command which disables the thing:


kwriteconfig5 --file startkderc --group General --key systemdBoot false

(+ reboot)

That made Fcitx5 start automatically for me on Plasma (Wayland).

Source: https://bugs.kde.org/show_bug.cgi?id=455252

So this may well be a KDE bug or a systemd bug — pick your choice.

Should we do something with im-config in the meantime to work around the 
problem?


--
Gunnar

Bug#1033119: thunderbird: cannot auth against Oauth2 microsoft365 account

[Kamil Jońca]

version 1:102.9.0-1+b1  seems to works correctly.

Thank you.



Carsten Schoenert  writes:

[...]
>
> it seems that the depending library libnss3-dev, that got an update
> right after the update of the Thunderbird package, had introduced some
> regressions that could result in the problems you did encounter.
>
> Please see https://bugs.debian.org/1033101
>
> Please pull the new binary package and check the usability again.

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Bug#1033151: unblock: firefox-esr/102.9.0esr-2

[Mike Hommey]

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

Please unblock package firefox-esr

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
New version fixes CVEs and the RC bug that was putting the package in
the autorm list.

[ Impact ]
No firefox in bookwork.

[ Tests ]
Package was smoke-tested.

[ Risks ]
Apart from the upstream differences from the CVE fixes/new upstream
release, that we'd take (and have taken) in stable, the differences are
very limited in scope (see attached diff)

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

unblock firefox-esr/102.9.0esr-2
diff -Nru firefox-esr-102.8.0esr/debian/browser.mozconfig.in 
firefox-esr-102.9.0esr/debian/browser.mozconfig.in
--- firefox-esr-102.8.0esr/debian/browser.mozconfig.in  2023-02-15 
08:44:35.0 +0900
+++ firefox-esr-102.9.0esr/debian/browser.mozconfig.in  2023-03-18 
06:53:04.0 +0900
@@ -30,6 +30,6 @@
 ac_add_options --with-unsigned-addon-scopes=app,system
 ac_add_options --allow-addon-sideload
 ac_add_options --enable-alsa
-%if DIST == bullseye || DIST == buster || DIST == stretch
+%if DIST == bullseye || DIST == buster || DIST == stretch || DEB_HOST_ARCH == 
s390x
 ac_add_options --without-wasm-sandboxed-libraries
 %endif
diff -Nru firefox-esr-102.8.0esr/debian/changelog 
firefox-esr-102.9.0esr/debian/changelog
--- firefox-esr-102.8.0esr/debian/changelog 2023-02-15 08:45:08.0 
+0900
+++ firefox-esr-102.9.0esr/debian/changelog 2023-03-18 06:53:38.0 
+0900
@@ -1,3 +1,22 @@
+firefox-esr (102.9.0esr-2) unstable; urgency=medium
+
+  * gfx/skia/generate_mozbuild.py, gfx/skia/moz.build: Remove explicit NEON
+flags from skia build. Closes: #982794. Thanks Emanuele Rocca.
+
+ -- Mike Hommey   Sat, 18 Mar 2023 06:53:38 +0900
+
+firefox-esr (102.9.0esr-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Fixes for mfsa2023-10, also known as:
+CVE-2023-25751, CVE-2023-28164, CVE-2023-28162, CVE-2023-25752,
+CVE-2023-28176.
+
+  * debian/browser.mozconfig.in: Disable wasm sandboxing on s390x for now.
+It doesn't work at the moment.
+
+ -- Mike Hommey   Wed, 15 Mar 2023 07:26:00 +0900
+
 firefox-esr (102.8.0esr-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
firefox-esr-102.8.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
 
firefox-esr-102.9.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
--- 
firefox-esr-102.8.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
  2023-02-15 08:44:54.0 +0900
+++ 
firefox-esr-102.9.0esr/debian/patches/debian-hacks/Add-a-2-minutes-timeout-on-xpcshell-tests.patch
  2023-03-18 06:53:24.0 +0900
@@ -7,7 +7,7 @@
  1 file changed, 18 insertions(+), 3 deletions(-)
 
 diff --git a/testing/xpcshell/runxpcshelltests.py 
b/testing/xpcshell/runxpcshelltests.py
-index 212bfeb..6761334 100755
+index c3de2a2..0636219 100755
 --- a/testing/xpcshell/runxpcshelltests.py
 +++ b/testing/xpcshell/runxpcshelltests.py
 @@ -13,6 +13,7 @@ import os
@@ -18,7 +18,7 @@
  import shutil
  import signal
  import subprocess
-@@ -835,9 +836,23 @@ class XPCShellTestThread(Thread):
+@@ -837,9 +838,23 @@ class XPCShellTestThread(Thread):
  if self.interactive:
  self.log.info("%s | Process ID: %d" % (name, self.proc_ident))
  
diff -Nru 
firefox-esr-102.8.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
 
firefox-esr-102.9.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
--- 
firefox-esr-102.8.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
1970-01-01 09:00:00.0 +0900
+++ 
firefox-esr-102.9.0esr/debian/patches/porting/Bug-1822827-Remove-explicit-NEON-flags-from-skia-bui.patch
2023-03-18 06:53:24.0 +0900
@@ -0,0 +1,44 @@
+From: Emanuele Rocca 
+Date: Sat, 18 Mar 2023 06:48:32 +0900
+Subject: Bug 1822827 - Remove explicit NEON flags from skia build
+
+While Firefox builds for Android ARMv7 don't support non-NEON
+processors, downstreams (including non-Android ones) may still want to
+support them.
+
+Because those Firefox builds don't support non-NEON processors, the NEON
+flags are actually already passed globally, and they don't need to be
+explicitly added. NEON_FLAGS is actually only meant to be used for
+sources that specifically need NEON support even when the target doesn't
+support it, for, e.g. specialized code behind runtime CPU detection.
+---
+ gfx/skia/generate_mozbuild.py | 2 --
+ gfx/skia/moz.build| 2 --
+ 2 files changed, 4 deletions(-)
+
+diff --git a/gfx/skia/generate_mozbuild.py b/gfx/skia/g

Bug#1033079: bullseye-pu: package intel-microcode/3.20230214.1~deb11u1

[Adam D. Barratt]

On Sat, 2023-03-18 at 08:54 +0100, Tobias Frost wrote:
> On Fri, Mar 17, 2023 at 09:15:36PM +0100, Salvatore Bonaccorso wrote:
> > Yes this is correct, you do not need to mention it. I just wanted
> > to
> > make double sure it's as well on the radar (and have not checked if
> > you have uploaded with -v to incude the intermediate changelog
> > entries
> > as well).
> 
> I think I've forgotten that part…
> So please reject my upload and I'll fix that…
> 

The changelog has them, but the .changes indeed doesn't

Flagged for rejection, pending dak actually processing that (we're mid-
dinstall currently).

Regards,

Adam