Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[Cyril Brulebois]

Hi,

Cyril Brulebois  (2023-05-03):
> It's entirely untested for the time being, but I've tested a few things
> inside an installer context, checking how hostname behaves when setting
> and when getting the hostname (even if I already alluded to it in the
> other bug report), and picking one of two possible options. You can find
> details in the comments above the command getting added:
>   
> https://salsa.debian.org/installer-team/preseed/-/commit/2d83a156b3e50e3a35dd9964090967ac1761f85f
> 
> I'll probably just find a dnsmasq config to tweak to force hostnames,
> check a netboot/gtk/mini.iso against it, and upload if that behaves
> better than D-I Bookworm RC 2.

Setting “hostname=foo” at the very end of the ISOLINUX or GRUB prompts,
respectively under KVM and its default configuration (no DHCP-provided
hostnames) and on a Dell laptop connected to a dnsmasq assigning DHCP
hostnames:

 - With RC 2, the hostname prompt is skipped, and “foo” is used in both
   cases.

 - With the modified netboot/gtk/mini.iso, the hostname prompt is
   skipped as well, “foo” is used under KVM, but “dellicious” is used on
   baremetal despite the hostname=foo trap.

And when I say “is used”, I mean ends up being stored for cdebconf under
netcfg/get_hostname (at least according to /var/lib/preseed/log), instead
of “foo” previously.

Notes:
 - I didn't actually perform any of those 4 installations in full.
 - Package just uploaded.
 - Daily builds dated 2023-05-04 should have all the required bits;
   I might trigger an out-of-crontab build for amd64/i386 later today
   if that helps people start testing right away.

> In the meanwhile, if you spot something fishy in the reasoning or in
> the implementation, please let me know.

Still valid.


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


signature.asc
Description: PGP signature

Bug#1034586: always reports inactive/expired certificate on armhf

[gs-debian . org]

On Tue, May 02, 2023 at 02:35:05AM -0400, gs-debian@gluelogic.com wrote:
> On Fri, Apr 21, 2023 at 01:47:22PM -0400, gs-debian@gluelogic.com wrote:
> > On Fri, Apr 21, 2023 at 06:14:25PM +0200, Marco d'Itri wrote:
> > > On Apr 21, gs-debian@gluelogic.com wrote:
> > > 
> > > > I probably should have started with the most basic thing:
> > > > 
> > > > What is the date on your device?
> > > NTP-accurate.
> > 
> > Perhaps there is something amiss in the Debian 32-bit build of lighttpd
> > or openssl for aarch64.  (Is there any particular reason that you are
> > running 32-bit lighttpd on aarch64 rather than running 64-bit lighttpd?)
> 
> Apologies for the delay.  I installed Debian Bookworm onto a QEMU
> aarch64 VM and the (64-bit!) lighttpd package for Debian aarch64 works
> as expected when I tested with an expired LE cert (warning issued), and
> when I tested with a current LE cert (no warning issued).
> 
> From where did you obtain a 32-bit build of lighttpd for aarch64?
> If you know, how was that 32-bit lighttpd built?  I would like to try to
> reproduce (as closely as possible) the 32-bit build.

Is your system based on raspbian?  My understanding is that a while
back, raspbian was using a 32-bit kernel and 32-bit userland, even on
aarch64-capable ARM chips.  Then, they upgraded the kernel to be 64-bit
on aarch64-capable ARM chips, but userland may still be 32-bit.

In any case, I have tested that things work as expected for me on a
physical 32-bit ARM processor running 32-bit lighttpd, and on a 64-bit
ARM VM running 64-bit lighttpd.  I'll need more info to get any further.

You might try testing using lighttpd mod_gnutls instead of mod_openssl
to see if that makes a difference.  If it does, then the issue might be
in the 32-bit armhf build of openssl that you are running under your
aarch64 kernel.

Cheers, Glenn

Bug#1035412: does not grok search expression from release notes

[Marc Haber]

Package: apt
Version: 2.6.0
Severity: minor

Hi

the release notes suggest using the command line

aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

to display alist of packages that is obsolete or from a third-party
repo.

apt doesn't grok that search:

$ apt search '?narrow(?installed, ?not(?origin(Debian)))'
E: Regex compilation error

Is this expected and intended behavior? Isn't apt supposed to be
aptitude compatible regarding searches? Wouldn't it be nice to have this
supported by apt as well?

Greetings
Marc

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

Kernel: Linux 6.3.0-zgws1 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt depends on:
ii  adduser 3.132
ii  base-passwd 3.6.1
ii  debian-archive-keyring  2023.3
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.6.0
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgnutls30 3.7.9-2
ii  libseccomp2 2.5.4-1+b3
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.6-1

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
ii  apt-doc 2.6.0
ii  aptitude0.8.13-5
ii  dpkg-dev1.21.21
ii  gnupg   2.2.40-1.1
ii  gnupg2  2.2.40-1.1
ii  powermgmt-base  1.37

-- no debconf information

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[Cyril Brulebois]

Control: tag -1 patch

Hi again,

Cyril Brulebois  (2023-05-03):
> In summary:
>  - It looks to me the first patch did make sure hostname=foo is still
>seen and acted on in userland, using the traditional logic.
>  - It looks to me tweaking it to unset the hostname if it's set should
>restore “hostname is only a fallback, not actually taking priority”
>problem, while retaining the “abracadebconf” part.
>  - It looks to me the kernel change should have zero impact on the
>hostname?=foo case.
> 
> 
> Having performed the quick checking leading to this very mail, I fear
> I might back out of what I thought I was going to do (testing various
> combinations in some systematic manner), and instead: concentrate on
> unsetting hostname in Linux/UTS, run a test or two, upload the
> package, and let the rest of you all check all the combinations you
> want (hostname=foo, hostname?=foo, before/after ---, with or without
> DHCP supplied hostnames, etc.) using daily builds.

It's entirely untested for the time being, but I've tested a few things
inside an installer context, checking how hostname behaves when setting
and when getting the hostname (even if I already alluded to it in the
other bug report), and picking one of two possible options. You can find
details in the comments above the command getting added:
  
https://salsa.debian.org/installer-team/preseed/-/commit/2d83a156b3e50e3a35dd9964090967ac1761f85f

I'll probably just find a dnsmasq config to tweak to force hostnames,
check a netboot/gtk/mini.iso against it, and upload if that behaves
better than D-I Bookworm RC 2.

In the meanwhile, if you spot something fishy in the reasoning or in the
implementation, please let me know.


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


signature.asc
Description: PGP signature

Bug#1033088: ntpsec: mssntp in ntp.conf breaks time service to all clients

[Steven Monai]

On 2023-04-29 9:04 p.m., Richard Laager wrote:

Quick approach is try this:
python3 waf configure ...
python3 waf build


I tried this, but the bundled 'waf' tool did not work in Python3. I 
could not get past the 'configure' step. Here's the output I got on a 
Bookworm host with all the ntpsec build dependencies installed:


t...@book.test:~$ python3 -V
Python 3.11.2
t...@book.test:~$ wget -q 
https://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz

t...@book.test:~$ tar -xf ntpsec-1.1.3.tar.gz
t...@book.test:~$ cd ntpsec-1.1.3/
t...@book.test:~/ntpsec-1.1.3$ python3 waf configure
Waf: The wscript in '/home/tech/ntpsec-1.1.3' is unreadable
Traceback (most recent call last):
  File 
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py", 
line 106, in waf_entry_point


set_main_module(os.path.normpath(os.path.join(Context.run_dir,Context.WSCRIPT_FILE)))
  File 
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Scripting.py", 
line 137, in set_main_module

Context.g_module=Context.load_module(file_path)
 ^^
  File 
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Context.py", 
line 352, in load_module

code=Utils.readf(path,m='rU',encoding=encoding)
 ^^
  File 
"/home/tech/ntpsec-1.1.3/.waf3-1.9.15-7481b2b5d90177d4bb747dbff06bef90/waflib/Utils.py", 
line 127, in readf

f=open(fname,m)
  ^
ValueError: invalid mode: 'rUb'


A longer, but possibly better, approach might be something like:
git clone g...@salsa.debian.org:debian/ntpsec.git
cd ntpsec
git checkout debian/1.1.3+dfsg1-1
debuild -uc -us


I tried this too, but the result was similar: the bundled 'waf' failed 
to work, which broke the build.


I don't believe I will be able to "forward-port" old ntpsec releases to 
Bookworm without a lot more time and effort. Perhaps someone more 
familiar with the build system would have better luck?


An intermediate approach might be to test with the binary package from 
buster. You can get download links here, by architecture, plus there are 
links to related packages, some of which (like python3-ntp) you might need:

https://packages.debian.org/buster/ntpsec


I could spin up a Buster VM to try this. I don't have a domain 
controller running on Buster, so I can't test whether Windows clients 
will get properly signed responses from the server. But I can still test 
whether the 'mssntp' configuration in ntp.conf causes ntpsec to stop 
serving non-auth clients. I will try to get to this in the next few days.


-S.M.

Bug#1035349: regression: 'hostname' preseed alias for netcfg/get_hostname takes precedence over DHCP hostname

[Cyril Brulebois]

Hi James,

[ Sorry, insisting on a new bug report lost us a valuable thing: the
people you had cc'd initially. Adding them now. ]

James Addison  (2023-05-01):
> On Mon, 1 May 2023 at 17:53, Cyril Brulebois  wrote:
> > And that user mentioned hostname=unassigned-hostname which would be
> > addressed if we were to implement what I mentioned?
> 
> Yep, fair point!

OK. :)

> I do see that guestfs-tools references[1] them, and I suppose other
> downstream software could do as well.  But within the installer's
> components, I don't think that they have any special meaning.

Thanks for mentioning guestfs-tools, we have other occurrences of that
particular setting in various packages:
  https://codesearch.debian.net/search?q=unassigned-hostname

As usual (not the first time you'll see me write this, not the last one):
a quick glance suggests those are mostly used inside preseed files, not on
the command line, for netcfg/get_hostname or netcfg/hostname, though.

> > I have some pending yet unrelated things to investigate on the preseed
> > side; I'm not sure I'll want to be testing each and every possible
> > combination (esp. tweaking the configuration of the DHCP server behind
> > the virtualization layer), but I should be able to test the water.
> 
> Totally reasonable, yep.

OK, thanks for the sanity check.

> Currently I think that a relevant patch should:
> 
>   * Unset the hostname, or set the hostname to '(none)', so that the
> installer's netcfg ignores[2] and is unaware of an install-time
> hostname.

Yes.

>   * Within env2debconf, attempt to find a hostname specified on the
> kernel command-line:
> * The parameter may appear as a 'hostname=value', or
> 'hostname?=value' key=value pair.
> * The parameter must appear strictly before any '---' delimiter_
> in the line.
>   * If a hostname was found:
> * Create a local 'hostname' variable within the env2debconf'
> script containing the hostname's value.
> * Ensure that the 'seen' flag is assigned appropriately:
>   * The value should be empty if the hostname was matched using
> 'hostname=value'.
>   * The value should be non-empty if the hostname as matched using
> 'hostname?=value'.
>   * If no hostname was found:
> * Do nothing.

FWIW: This kind of heavy headscratching is exactly why I was wondering
whether to fix #1031643 in the first place. :) Spoiler alert though, I
don't think it's actually that complicated, thanks to Andreas and the
clever side-stepping of the entire problem.


Call me an optimist (famous last words…), but isn't that sufficient?
 - hostname=foo case:
+ The kernel consumes the parameter, acts on it.
+ We detect it in env2debconf (the hostname isn't “(none)”) and I
  guess we set the variable as today, but unset the hostname in
  Linux/UTS.
+ We get all the rest of the logic as previously?
 - hostname?=foo case:
+ The kernel doesn't consume the parameter, so there's no change
  from previous situation.
+ Things are as they have always been?

I don't think before/after --- changes anything there (see my initial
report, filed on Salvatore's behalf, and the red herring section there)
and I clearly don't see why one would prefer a specific one anyway.

A bit of warning: if one opens up a shell right after passing the
bootloader (e.g. the language screen is still shown, and the network
screen hasn't been reached yet – let's keep things simple), one won't
see hostname=foo there; but one will see vga=788 (assuming graphical
installer). That's probably because this particular env is inherited
from the kernel, who ate the variable away already. That doesn't mean
it's not taken into account, as can be checked in /var/lib/preseed/log:

d-i netcfg/get_hostname string foo

IOW: It has been created within the env2debconf process, acted on, but
 it's not going to show up in other places, like in a random shell.


In summary:
 - It looks to me the first patch did make sure hostname=foo is still
   seen and acted on in userland, using the traditional logic.
 - It looks to me tweaking it to unset the hostname if it's set should
   restore “hostname is only a fallback, not actually taking priority”
   problem, while retaining the “abracadebconf” part.
 - It looks to me the kernel change should have zero impact on the
   hostname?=foo case.


Having performed the quick checking leading to this very mail, I fear
I might back out of what I thought I was going to do (testing various
combinations in some systematic manner), and instead: concentrate on
unsetting hostname in Linux/UTS, run a test or two, upload the
package, and let the rest of you all check all the combinations you
want (hostname=foo, hostname?=foo, before/after ---, with or without
DHCP supplied hostnames, etc.) using daily builds.

And if there are still actual and relevant changes from Bullseye,
please open up a new bug report detailing the use case, the past
behaviour (Bullseye) and the new behaviour (latest preseed)?

Bug#1035411: lxqt: debian 12 lxqt desktop does not have network driver and no networ icon tray

[dudy]

Package: lxqt
Version: 31
Severity: important
X-Debbugs-Cc: dudyke...@yahoo.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages lxqt depends on:
ii  featherpad 1.3.5-1
ii  kwin-x11 [x-window-manager]4:5.27.2-1
ii  lximage-qt 1.2.0-2
ii  lxqt-about 1.2.0-1
ii  lxqt-admin 1.2.0-1
ii  lxqt-branding-debian [lxqt-branding]   0.14.0.3
ii  lxqt-core  31
ii  lxqt-openssh-askpass   1.2.0-1
ii  lxqt-powermanagement   1.2.0-1
ii  lxqt-sudo  1.2.0-1
ii  openbox [x-window-manager] 3.6.1-10
ii  pavucontrol5.0-2
ii  qlipper1:5.1.2-1+b1
ii  qps2.6.0-1
ii  qterminal  1.2.0-2
ii  qttranslations5-l10n   5.15.8-2
ii  sddm [x-display-manager]   0.19.0-5
ii  sddm-theme-breeze [sddm-theme] 4:5.27.2-1
ii  sddm-theme-debian-breeze [sddm-theme]  4:5.27.2-1
ii  sddm-theme-debian-elarun [sddm-theme]  0.19.0-5
ii  xarchiver  1:0.5.4.20-2
ii  xfwm4 [x-window-manager]   4.18.0-1

Versions of packages lxqt recommends:
ii  audacious  4.2-1
ii  feathernotes   1.1.0-1
ii  firefox-esr [www-browser]  102.10.0esr-1
ii  gucharmap  1:15.0.2-1
ii  hexchat2.16.1-1+b3
ii  lynx [www-browser] 2.9.0dev.12-1
ii  meteo-qt   3.3-1
ii  nm-tray0.5.0-1
ii  plasma-nm  4:5.27.2-1
ii  preload0.6.4-5
ii  qpdfview   0.5.0+ds-2
ii  screengrab 2.5.0-1
ii  smplayer   22.7.0~ds0-1
ii  smtube 21.7.0-1+b1
ii  thunderbird [mail-reader]  1:102.10.0-1

Versions of packages lxqt suggests:
pn  calibre
pn  compton-conf   
pn  juffed 
pn  nomacs 
pn  obconf-qt  
pn  qt5-style-kvantum  
pn  qtpass 
pn  shutter
pn  vokoscreen 

-- no debconf information

Bug#1032994: unblock: node-webpack/5.76.1+dfsg1+~cs17.16.16-1

[Yadd]

On 5/2/23 23:26, Paul Gevers wrote:

Hi Yadd,

On 02-05-2023 10:15, Yadd wrote:

extracting only CVE patch means:
  * keep some (unimportant) bugs in Bullseye
  * publish such version number:
    5.76.1+dfsg1+~cs17.16.16+really~5.75.0+dfsg+~cs17.16.14-1


Indeed, both are totally acceptable. Can we have a debdiff please?

Paul


Hi,

here is the current debdiff (without the big removal of useless 
discoveryjs-json-ext/benchmarks)


Regards,
Yadddiff --git a/README.md b/README.md
index c712d27f..a6549c1c 100644
--- a/README.md
+++ b/README.md
@@ -158,11 +158,11 @@ or are automatically applied via regex from your webpack 
configuration.
 
  Transpiling
 
-|
Name
|Status |  Install Size  | Description  
 |
-| 
::
 | :---: | :: | 
:
 |
-| https://github.com/babel/babel-loader;>https://worldvectorlogo.com/logos/babel-10.svg;> 
| ![babel-npm]  | ![babel-size]  | Loads ES2015+ code and transpiles to ES5 
using https://github.com/babel/babel;>Babel |
-|  https://github.com/TypeStrong/ts-loader;>https://cdn.rawgit.com/Microsoft/TypeScript/master/doc/logo.svg;>  |  
![type-npm]  |  ![type-size]  | Loads TypeScript like JavaScript
  |
-|https://github.com/webpack-contrib/coffee-loader;>https://worldvectorlogo.com/logos/coffeescript.svg;>| 
![coffee-npm] | ![coffee-size] | Loads CoffeeScript like JavaScript 
   |
+|  
   Name 

|Status |  Install Size  | Description  
 |
+| 
:--:
 | :---: | :: | 
:
 |
+|  https://github.com/babel/babel-loader;>https://worldvectorlogo.com/logos/babel-10.svg;>  
| ![babel-npm]  | ![babel-size] 
 | Loads ES2015+ code and transpiles to ES5 using https://github.com/babel/babel;>Babel |
+| https://github.com/TypeStrong/ts-loader;>https://raw.githubusercontent.com/microsoft/TypeScript-Website/f407e1ae19e5e990d9901ac8064a32a8cc60edf0/packages/typescriptlang-org/static/branding/ts-logo-128.svg;>
 |  ![type-npm]  |  ![type-size]  | Loads TypeScript like JavaScript
  |
+| https://github.com/webpack-contrib/coffee-loader;>https://worldvectorlogo.com/logos/coffeescript.svg;>   
  | ![coffee-npm] | ![coffee-size] 
| Loads CoffeeScript like JavaScript
|
 
 [babel-npm]: https://img.shields.io/npm/v/babel-loader.svg
 [babel-size]: https://packagephobia.com/badge?p=babel-loader
@@ -175,7 +175,7 @@ or are automatically applied via regex from your webpack 
configuration.
 
 |  
 Name   
 | Status  |   Install Size   | Description 
|
 | 
:---:
 | :-: | :--: | 
:--
 |
-|https://github.com/webpack-contrib/html-loader;>https://worldvectorlogo.com/logos/html5.svg;>   
 |   ![html-npm]   |   ![html-size]   | Exports HTML as string, 
requires references to static resources |
+|   https://github.com/webpack-contrib/html-loader;>https://worldvectorlogo.com/logos/html5-2.svg;> 
  |   

Bug#1035410: reportbug: debian 12 lxqt desktop does not have network driver and no network icon

[dudy]

Package: reportbug
Version: 11.6.0
Severity: important
X-Debbugs-Cc: dudyke...@yahoo.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/dudy/.reportbugrc:
reportbug_version "11.6.0"
mode novice
ui gtk
email "dudyke...@yahoo.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt2.6.0
ii  python33.11.2-1+b1
ii  python3-reportbug  11.6.0
ii  sensible-utils 0.0.17+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
ii  debconf   1.5.82
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
pn  python3-urwid 
ii  reportbug-gtk 11.6.0
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.6.0
ii  file   1:5.44-3
ii  python33.11.2-1+b1
ii  python3-apt2.5.3
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17+nmu1

python3-reportbug suggests no packages.

-- no debconf information

Bug#1035409: xscreensaver: can not launch xscreensaver setting

[dudy]

Package: xscreensaver
Version: 6.06+dfsg1-3
Severity: important
X-Debbugs-Cc: dudyke...@yahoo.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.65.2
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9
ii  libcrypt11:4.4.33-2
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libpam0g 1.5.2-6
ii  libsystemd0  252.6-1
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1.2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxt6   1:1.2.1-1.1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data6.06+dfsg1-3

Versions of packages xscreensaver recommends:
ii  fonts-urw-base35  20200910-7
ii  libjpeg-turbo-progs   1:2.1.5-2
ii  perl  5.36.0-7
ii  wamerican [wordlist]  2020.12.07-2
ii  xfonts-100dpi 1:1.0.5

Versions of packages xscreensaver suggests:
ii  firefox-esr [www-browser]  102.10.0esr-1
pn  fortune
pn  gdm3 | kdm-gdmcompat   
ii  lynx [www-browser] 2.9.0dev.12-1
pn  qcam | streamer
pn  xdaliclock 
pn  xfishtank  
pn  xscreensaver-data-extra
pn  xscreensaver-gl
pn  xscreensaver-gl-extra  

-- no debconf information

Bug#1035408: reportbug: network icon tray not shown on lxqt

[dudy]

Package: reportbug
Version: 11.6.0
Severity: important
X-Debbugs-Cc: dudyke...@yahoo.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/dudy/.reportbugrc:
reportbug_version "11.6.0"
mode novice
ui gtk
email "dudyke...@yahoo.com"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

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

Versions of packages reportbug depends on:
ii  apt2.6.0
ii  python33.11.2-1+b1
ii  python3-reportbug  11.6.0
ii  sensible-utils 0.0.17+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
ii  debconf   1.5.82
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.44-3
ii  gnupg 2.2.40-1.1
pn  python3-urwid 
ii  reportbug-gtk 11.6.0
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.6.0
ii  file   1:5.44-3
ii  python33.11.2-1+b1
ii  python3-apt2.5.3
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.17+nmu1

python3-reportbug suggests no packages.

-- no debconf information

Bug#1035407: connman: failed to start connman-wait-online.service when logout kde plasma

[dudy]

Package: connman
Version: 1.41-3
Severity: important
X-Debbugs-Cc: dudyke...@yahoo.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages connman depends on:
ii  dbus   1.14.6-1
ii  init-system-helpers1.65.2
ii  iptables   1.8.9-2
ii  libc6  2.36-9
ii  libdbus-1-31.14.6-1
ii  libglib2.0-0   2.74.6-2
ii  libgnutls303.7.9-2
ii  libreadline8   8.2-1.3
ii  libxtables12   1.8.9-2
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages connman recommends:
ii  bluez  5.66-1
ii  ofono  1.31-3+b1
ii  wpasupplicant  2:2.10-12

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Cyril Brulebois]

Hi,

James Addison  (2023-05-03):
> I think that the vendor name is coming from a DMI fallback:
> https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487

I smiled. :)

The (still quick) glance I had earlier stopped when I reached “DMI”
which I wasn't sure was valid for ARM devices. :)

> Whether the model name is from DMI or from the DTS file's 'model'
> field is less clear to me:
> 
> https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-400.dts/#L7
> 
> I'll try to rebuild the kernel module and test some changes 'soon'
> (within the next few days, most likely).

I'm not sure how many things rely on this particular model field in the
DT (and how badly it could break the boot sequence among other things),
but it might be much quicker for you to confirm whether the DTB is
relevant, before thinking about patching the module, and figuring out
whether that involves vmlinuz, the initramfs, etc.

In a linux tree (maybe prepared from the src:linux git tree, cf. kernel
handbook for details), with a proper .config in place (e.g. copied from
your /boot):

# you might need some linux build-deps, but that one is for
# crossbuilding from another arch:
sudo apt-get install gcc-aarch64-linux-gnu
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dtbs

Then make your change in the DTS, re-run, you should see only a single
file get updated, deploy it in /boot/firmware, profit (hopefully).

(Beware of the raspi-firmware hook, that will redeploy DTBs from the
linux-image packages when you least expect it; but that becomes an ally
to scratch your local test files and restore the packaged ones once you
keep its existence in mind.)

Another way can be to use device-tree-compiler's dtc to turn the DTB
into a DTS, run sed, then run dtc again to get an updated DTB from the
updated DTS.

> Also, to clarify an error/thinko in my previous message: the style of
> filename we agreed to map to, and that both linux-firmware.git and the
> RPi operating system distro[1] use, is
> "brcmfmac43456-sdio.raspberrypi,400.txt" (not the short-format
> "brcmfmac43455-sdio.txt" that I mentioned).  We should include
> specificity for vendor and model in the filename, all lowercased, and
> without spaces.

I didn't comment on that part in my previous reply but that definitely
looks better (or at least what I'd naïvely expect to be needed, i.e.
supporting possible per-model settings).

> The RPi 400 model firmware files are not yet represented in
> linux-firmware.git, although they do appear in the RPi operating
> system distro.

So many things that are there and only there…


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


signature.asc
Description: PGP signature

Bug#1035014: installation-reports: Graphical installer has Xorg "no screens found" error

[Cyril Brulebois]

Hi Timo!

Timo Aaltonen  (2023-05-02):
> Hi, fine by me!

Thanks, uploaded.

I'll keep an eye on it, and request an unblock (letting debian-x@ know via
X-Debbugs-Cc) once I've checked britney doesn't report any red flags.

It's going to be on two different radars of mine anyway:
 - https://d-i.debian.org/testing-summary.html#udebs
 - https://salsa.debian.org/installer-team/debian-installer/-/issues/1

So I shouldn't forget about it…


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


signature.asc
Description: PGP signature

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[James Addison]

Control: retitle -1 hw-detect: firmware file path handling is fragile
Control: clone -1 -2
Control: reassign -2 src:linux
Control: retitle -2 brcmfmac: firmware filename inconsistency with
linux-firmware.git

On Wed, 3 May 2023 at 00:34, Cyril Brulebois  wrote:
>
> James Addison  (2023-05-02):
> It looks to me someone should understand the Linux kernel code, and
> possibly where inputs/variables come from (there might be stuff coming
> from the DTB, some bootloader thing, etc.), and why spaces show up in
> there. Then decide whether the “external” source (if any!) or the kernel
> should be adjusted to use more straightforward names.

Thanks - OK.


I think that the vendor name is coming from a DMI fallback:

https://sources.debian.org/src/linux/6.1.25-1/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c/?hl=487#L487

Whether the model name is from DMI or from the DTS file's 'model'
field is less clear to me:

https://sources.debian.org/src/linux/6.1.25-1/arch/arm/boot/dts/bcm2711-rpi-400.dts/#L7

I'll try to rebuild the kernel module and test some changes 'soon'
(within the next few days, most likely).


Also, to clarify an error/thinko in my previous message: the style of
filename we agreed to map to, and that both linux-firmware.git and the
RPi operating system distro[1] use, is
"brcmfmac43456-sdio.raspberrypi,400.txt" (not the short-format
"brcmfmac43455-sdio.txt" that I mentioned).  We should include
specificity for vendor and model in the filename, all lowercased, and
without spaces.

The RPi 400 model firmware files are not yet represented in
linux-firmware.git, although they do appear in the RPi operating
system distro.

Thanks,
James

[1] - 
http://archive.raspberrypi.org/debian/dists/bullseye/main/binary-arm64/Packages

Bug#1035101: Failed to detect HD if Intel RST-RAID is active

[Cyril Brulebois]

Control: clone -1 -2
Control: retitle -2 installation-guide: investigate adding some hint about 
Intel RST-RAID
Control: reassign -2 installation-guide

Hi Thomas,

Thanks for testing.

Thomas Viehweger  (2023-05-02):
> I made an installation test, but no change. In the shell of the
> installer lsmod does not list intel-rst as loaded.

Have you tried a manual modprobe, just in case?

> I think that there is more necessary than just providing the module.
> Don't know what the Ubuntu installer does.
> At least a hint in the installation guide would be nice to switch off
> the RST RAID mode in the BIOS if the HDD is not detected.

Having no affected hardware, I thought the module addition could maybe
help a little, and thought it'd be easy to check, hence the suggestion.
Hardware visibility (or lack thereof) from the operating system is some
extremely unpleasant business…

I'm cloning this bug report against the installation guide so that it
can be augmented with some information about this. Let's keep the
original report against installation-reports; someone willing to work
on that can reassign to the most relevant component once that's been
determined.


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


signature.asc
Description: PGP signature

Bug#1035326: greetd: Refers to nonexistent wlgreet package

[duck]

Quack,

On 2023-05-01 07:11, Marie Janssen wrote:


The greetd package suggests: wlgreet but it is not available, causing
the confusing situation where it's recommended (and seems likely to be
preferred, given the lightdm situation that caused greetd to be added)
but not available.

I'd recommend removing it from Suggests: until #1010248 is resolved.


Indeed it's confusing. wlgreet packaging is taking more time than 
expected but should not be too far from completion.
Now it's only a Suggests and not a Recommends, so it's not going to 
cause any harm during installation.
As for the release this is way too late to change the recommendation as 
we're deep in the freeze and this is not severe enough for an exception.
As for unstable it should not deviate from the release target so as not 
to block last minute fixes, therefore I'll hopefully get wlgreet 
finished soon and it would be solved. If I hit problems then I'll 
consider your suggestion.


Thanks for report.
\_o<

--
Marc Dequènes

Bug#1035405: bnd: reproducible-builds: build timestamps in files inside of .jar

[Vagrant Cascadian]

Source: bnd
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded inside a jar embedded inside
/usr/share/java/bnd-5.0.1.jar:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/bnd.html

  embedded-repo.jar

  Timestamp:·1715504316639\xd
  vs.
  Timestamp:·1681094408754\xd

The attached patch fixes this from debian/rules by replacing the
Timestamp field with SOURCE_DATE_EPOCH.


Alternately, a better fix might be to figure out exactly where the
${_@tstamp} value is derived from, and add SOURCE_DATE_EPOCH support to
that. There are various functions throughout the codebase that affect
TSTAMP, _tstamp and _@tstamp, but I could not find the right one to fix
this particular issue. In debian/patches there are a few which
presumably fix other issues by adding SOURCE_DATE_EPOCH support.


According to my local tests, with this patch applied, bnd should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining bnd!

live well,
  vagrant
From c8c6878d524525062c7637e3215ac2758f3885aa Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 2 May 2023 16:27:07 -0700
Subject: [PATCH] debian/rules: Override the timestamp used in embedded.bnd
 with SOURCE_DATE_EPOCH.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 17eca1c..3243b3b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -82,6 +82,9 @@ override_dh_auto_build:
 	ln -s /usr/share/java/snakeyaml.jar cnf/cache/$(VERSION)/bnd-cache/org.yaml.snakeyaml/org.yaml.snakeyaml-latest.jar
 	ln -s /usr/share/java/xz.jarcnf/cache/$(VERSION)/bnd-cache/org.tukaani.xz/org.tukaani.xz-latest.jar
 	$(RM) -r biz.aQute.repository/src/aQute/bnd/jpm # This package depends on non-free code
+
+	# Use SOURCE_DATE_EPOCH for the timestamp
+	sed -i -e "s,Timestamp:.*,Timestamp: $(SOURCE_DATE_EPOCH),g" biz.aQute.bnd.embedded-repo/bnd/embedded-repo.bnd
 	dh_auto_build -- :biz.aQute.bnd:assemble \
 	 :biz.aQute.launcher:assemble \
 	 :biz.aQute.junit:assemble \
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1035343: racket: Consider using CS on all architectures

[David Bremner]

Philip McGrath  writes:

> I don't fully understand the nuances of the bookworm freeze policy. (I'm 
> sorry 
> I didn't report this sooner.) It seems at least plausible that this could be 
> a 
> "small, targeted fix[]", especially from the perspective that it would amount 
> to bringing a few niche architectures to parity with the popular ones, but I 
> could also understand an argument to the contrary.

Sorry, this is too large of a change for bookworm.

I'm on vacation, but I'll examine the situation more fully in a few
weeks.

d

Bug#1035404: release-notes: Document that VLC 3.x no longer supports VA-API decoding due to ffmpeg 5 transition

[Tom Maneiro]

Package: release-notes
Severity: normal
Tags: upstream
X-Debbugs-Cc: tom...@gmail.com

Dear Maintainer,

With the transition to FFmpeg 5.0, the current stable version line of VLC
(3.0.x) dropped VA-API hardware decoding support due to important changes on
the FFmpeg API, which will mainly impact Intel GPU users:

https://code.videolan.org/videolan/vlc/-/issues/26772
https://code.videolan.org/videolan/vlc/-/merge_requests/1245
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021601

Just like every media player using FFmpeg, VLC had to deal with this change,
and they indeed fixed VA-API support... but only on the upcoming 4.0 version,
whose release date is still not set (not even a public beta period has been
announced yet). Since they're focusing their development efforts on VLC 4, they
do not intend to fix VA-API support for VLC 3, which means anyone using VLC
will have to fall back to software decoding (with predictable impact on
performance / power usage), try using vdpau-va-gl as a bridge between VDPAU and
VA-API (this wrapper is known to have stability issues on some setups), or
switch to an alternative media player application like mpv.

This breakage has the potential to negatively impact the experience of those
using VLC as their preferred video player solution on Debian, especially on
Intel IGPs, which are a rather large part of the Linux userbase nowadays. Given
that upstream is unwilling to provide an acceptable solution (especially
considering the current situation of the next major release of VLC), it's
important to at least inform the users to be aware of this problem so they can
act accordingly to have a smoother video playback experience on their Debian
setups.

Bug#1035398: [pre-approval] unblock: dwarves/1.24-4.1

[Cyril Brulebois]

Hi!

Aurelien Jarno  (2023-05-02):
> > [ Reason ]
> > Back in #1033301, Aurelien reported that the arm64 kernel size did
> > increase significantly due to issues with BTF deduplication. First
> > suspected to be a Linux kernel upstream issue, Aurelien discussed this
> > on with upstream and it was found that the issue is caused by a
> > src:dwarves regression (applied in 1.24-4).
> > 
> > Details in https://bugs.debian.org/1033301#31
> > 
> > The (not yet uploaded) dwarves upload with attache debdiff
> > cherry-picks the upstream commit.
> > 
> > (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.)
> > 
> > [ Impact ]
> > Increased arm64 kernel size.
> > 
> > [ Tests ]
> > Apart from the report from Aurelien[1], package passes its autopkgtest.
> > 
> >  [1]  https://lore.kernel.org/linux-arm-kernel/zezhajup21ln5...@aurel32.net/
> 
> Thanks a lot for preparing this pre-approval request and the
> corresponding upload. I confirm that I tested the exact same change on
> arm64, on both native and cross-compiled build and that it fixes the
> issue I reported.
> 
> > [ Risks ]
> > The upstream commit zero-initializes memory which previous was not
> > initialized after allocation, and might have contained garbage values
> > which were used. The fix is isolated as a oneliner.
> 
> I agree that the risk is quite low. The fix also likely improves
> reproducibility by removing a dependence on build time random data which
> is always good think.

Thanks from me as well for the d-i side: this issue worried me earlier
but didn't reach my list of topics to keep an eye on for Bookworm
(https://salsa.debian.org/installer-team/debian-installer/-/issues/1),
I'm glad you kept track!

I'll let someone else from the release team comment on the actual
unblock request though.


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


signature.asc
Description: PGP signature

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Cyril Brulebois]

Hi James,

I've just finished a very long debugging session[1], so the following is
really best effort and probably not 100%.

 1. 
https://lore.kernel.org/all/20230428223500.23337-1-jim2101...@gmail.com/T/#m846b07884ef687d3669654c782aa3b61216f15b7

James Addison  (2023-05-02):
> Could either of you (Cyril, Diederik) recommend where I should ask
> (and/or clone this bug) to follow up on the firmware filename issue,
> given that the filename(s) seem to be generated from the kernel
> module?

It looks to me someone should understand the Linux kernel code, and
possibly where inputs/variables come from (there might be stuff coming
from the DTB, some bootloader thing, etc.), and why spaces show up in
there. Then decide whether the “external” source (if any!) or the kernel
should be adjusted to use more straightforward names.

> Thank you; yep, I've followed _most_ of that (and arrived back here
> again).  I will admit that most of what I've cognitively loaded from
> it is "this script could use refactoring post-bookworm", and have not
> processed the complete details.

Yes; my point was really to say “sorry it's _so_ not perfect yet”, but
seeing this kind of things get uncovered is definitely *not* unexpected…

Let's take a step back and check summarize where we come from, so that
the picture is not only clear in my own head. :)


During the bullseye release cycle, I've tried to deal with GPU problems
by adding modalias support (no specific modules in d-i means no messages
in dmesg, meaning we needed something else), to avoid abysmal experience
once reaching the post-install reboot. (And being able to work on that
only late in the release cycle had some impact on the release date…
which is definitely *not* a feeling I wish anyone else to experience!)

During the bookworm release cycle, getting official support for firmware
packages has been basically a solo effort in each and every component
(even if I got some help from firmware package maintainers and members
of some infrastructure teams, you know who you are <3). While Pascal has
been submitting a bunch of patches for hw-detect already, there are
still some gaps to fill. But again, I'll take *not* supporting _some_
use cases right away over risking losing support for _most_ use cases;
that's a no-brainer, especially just days away from the next RC(s), and
from the actual release.

But enough meta-talk now! :)


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


signature.asc
Description: PGP signature

Bug#1034886: docker.io: CVE-2022-37708

[Tianon Gravi]

On Wed, 26 Apr 2023 at 13:21, Shengjing Zhu  wrote:
> On Thu, Apr 27, 2023 at 1:39 AM Moritz Mühlenhoff  wrote:
> >
> > Source: docker.io
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: important
> > Tags: security
> >
> > Hi,
> >
> > The following vulnerability was published for docker.io.
> >
> > CVE-2022-37708[0]:
> > | Docker version 20.10.15, build fd82621 is vulnerable to Insecure
> > | Permissions. Unauthorized users outside the Docker container can
> > | access any files within the Docker container.
> >
> > The only reference here seems to be
> > upstream: https://github.com/thekevinday/docker_lightman_exploit
> >
> > Not sure if this was reported upstream
>
> I have talked to Tianon on 2023-02-28, and we concluded that it's not
> a security issue, just working as expected.
>
> Tianon said he will ask someone inside the Docker company. Not sure if
> they have successfully invalidated this CVE.

My colleague disputed it, but we apparently never heard back about the
dispute. 路

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1034054: ../../src/xcb_io.c:626: _XAllocID Assertion `ret != inval_id' failed

[Jaimos Skriletz]

On Fri, Apr 7, 2023 at 8:09 AM Marco d'Itri  wrote:
>
> Package: fvwm
> Version: 1:2.7.0-1
> Severity: important
>
> Since a few days/weeks fvwm has started crashing frequently with this
> "ret != inval_id" assertion.
>

It appears there was a change in libX11 1.8.1 which causes fvwm to
crash due to thread locking. This bug was fixed in fvwm3, and a
backport of the fix has been made for fvwm. You can find the fix here:

https://github.com/fvwmorg/fvwm/pull/102

I haven't had time to reproduce the bug and see if this fixes it, but
all signs point to yes. I have made a new package and uploaded to
mentors. It would be nice if I can get confirmation this fixes the
issue before getting the fix into Debian.

jaimos

Bug#998325: akonadi-server: akonadi_indexing_agent crashes when kmail is active

[Hefee]

Control: tags -1 +moreinfo

Hey,

that is properly a email, that triggers the indexer to crash. To get more 
details please install libkf5akonadisearchpim5-dbgsym to get a propper 
backtrace. Additionally, run akonadi with debug logging enabled:

QT_LOGGING_RULES="*.debug=true;qt.*=false" akonadictl restart

that should points you to the mail, that triggers this crash.

Regards,

hefee

--

On Dienstag, 2. November 2021 13:44:03 CEST Hans-J. Ullrich wrote:
> Package: akonadi-server
> Version: 4:20.08.3-3
> Severity: important
> 
> Dear Maintainer,
> 
> I hope, this is the right package. I have the following problem with akonadi
> on debian/bullseye, amd64.
> 
> Problem: When I start kmail, then akoandi is crashing with the message,
> "akonadi_indexing_agent is crashed"
> 
> This is the output of the error:
> 
>  snip -
> 
> 
> Application: akonadi_indexing_agent (akonadi_indexing_agent), signal:
> Aborted
> 
> [KCrash Handler]
> #4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
> #5  0x7f5ad974f537 in __GI_abort () at abort.c:79
> #6  0x7f5ad99a57ec in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
> #7  0x7f5ad99b0966 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
> #8  0x7f5ad99b09d1 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
> #9  0x7f5ad99b0c65 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
> #10 0x7f5adb19bd0f in  () at /lib/x86_64-linux-gnu/libxapian.so.30
> #11 0x7f5adb2516be in  () at /lib/x86_64-linux-gnu/libxapian.so.30
> #12 0x7f5adb2517e2 in  () at /lib/x86_64-linux-gnu/libxapian.so.30
> #13 0x7f5adb252e0c in  () at /lib/x86_64-linux-gnu/libxapian.so.30
> #14 0x7f5adb23d7c9 in  () at /lib/x86_64-linux-gnu/libxapian.so.30
> #15 0x7f5adb1b2101 in  () at /lib/x86_64-linux-gnu/libxapian.so.30
> #16 0x7f5adb2b1140 in  () at /lib/x86_64-linux-gnu/libxapian.so.30
> #17 0x7f5adb1c2fd8 in Xapian::Enquire::Internal::get_mset(unsigned int,
> unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider
> const*) const () at /lib/x86_64-linux-gnu/libxapian.so.30 #18
> 0x7f5adb1c3245 in Xapian::Enquire::get_mset(unsigned int, unsigned int,
> unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () at
> /lib/x86_64-linux-gnu/libxapian.so.30 #19 0x7f5adb3be231 in  () at
> /lib/x86_64-linux-gnu/libKF5AkonadiSearchPIM.so.5 #20 0x7f5adb3be611 in
>  () at /lib/x86_64-linux-gnu/libKF5AkonadiSearchPIM.so.5 #21
> 0x55ebc1bd976a in  ()
> #22 0x7f5ad9dbc5a6 in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
> #23 0x7f5ada7aed29 in KJob::finished(KJob*, KJob::QPrivateSignal) () at
> /lib/x86_64-linux-gnu/libKF5CoreAddons.so.5 #24 0x7f5ada7af97c in
> KJob::finishJob(bool) () at /lib/x86_64-linux-gnu/libKF5CoreAddons.so.5 #25
> 0x7f5ad9db1ff1 in QObject::event(QEvent*) () at
> /lib/x86_64-linux-gnu/libQt5Core.so.5 #26 0x7f5ada96b15f in
> QApplicationPrivate::notify_helper(QObject*, QEvent*) () at
> /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #27 0x7f5ad9d85fca in
> QCoreApplication::notifyInternal2(QObject*, QEvent*) () at
> /lib/x86_64-linux-gnu/libQt5Core.so.5 #28 0x7f5ad9d88a01 in
> QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
> at /lib/x86_64-linux-gnu/libQt5Core.so.5 #29 0x7f5ad9ddde93 in  () at
> /lib/x86_64-linux-gnu/libQt5Core.so.5 #30 0x7f5ad83f1e6b in
> g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #31
> 0x7f5ad83f2118 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #32
> 0x7f5ad83f21cf in g_main_context_iteration () at
> /lib/x86_64-linux-gnu/libglib-2.0.so.0 #33 0x7f5ad9ddd51f in
> QEventDispatcherGlib::processEvents(QFlags)
> () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #34 0x7f5ad9d8498b in
> QEventLoop::exec(QFlags) () at
> /lib/x86_64-linux-gnu/libQt5Core.so.5 #35 0x7f5ad9d8cc00 in
> QCoreApplication::exec() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #36
> 0x55ebc1bc8ca8 in  ()
> #37 0x7f5ad9750d0a in __libc_start_main (main=0x55ebc1bc3090, argc=3,
> argv=0x7ffccce092a8, init=, fini=,
> rtld_fini=, stack_end=0x7ffccce09298) at
> ../csu/libc-start.c:308 #38 0x55ebc1bc30ca in  ()
> [Inferior 1 (process 12884) detached]
> 
> 
>  snap 
> 
> Restarting akonadi-server and mysql does not help. Dunno, if this has
> something to do with it, but this appeared after the last upgrade of
> openjdk (however, it is not clear for me, that openjdk should cause this
> issue, maybe it is just a coincidence.
> 
> Hope, this mails does help though.
> 
> Best regards
> 
> Hans
> 
> 
> -- System Information:
> Debian Release: 11.1
>   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-8-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, 

Bug#1008885: loops endlessly about (failed?) mariadb start

[Hefee]

Control: tags -1 moreinfo
Hi,

About the loop: I never seen that before - It normally just fails and than not 
try again to start up again. It maybe related with systemd integration of 
Plasma. Or do you have any special autostart scripts? And with the newer 
versions the wayland support got better, so maybe the issue is solved in 
meanwhile?

if you don't use any Akonadi feature and don't want to remove meta-packages. I 
would suggest to use akonadi-backend-sqlite and remove the mysql one. 
Unfortunatelly you really need to modify your akonadiserverrc config. That at 
least should make it start more easily. See the blog entry:

https://euroquis.nl//freebsd/2023/04/24/akonadi.html

Regards,

hefee


On Sonntag, 3. April 2022 13:57:05 CEST Marc Haber wrote:
> Package: akonadi-server
> Version: 4:21.12.3-2
> Severity: normal
> 
> Hi,
> 
> to see whether KDE Wayland works better when started via gdm3 instead of
> sddm (spoiler: No, same way of broken as with sddm), I exchanged sddm
> with gdm3. After going back to KDE X11 Session, I found my log being
> spammed with the following pattern, repeated endlessly:
> 
> Apr  3 13:33:47 fan /usr/libexec/gdm-x-session[723825]:
> org.kde.pim.akonadiserver: Starting up the Akonadi Server... Apr  3
> 13:33:47 fan /usr/libexec/gdm-x-session[723821]:
> org.kde.pim.akonadicontrol: Service org.freedesktop.Akonadi.Control.lock
> already registered, terminating now. Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: database
> server stopped unexpectedly Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: Database
> process exited unexpectedly during initial connection! Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: executable:
> "/usr/sbin/mysqld" Apr  3 13:33:52 fan /usr/libexec/gdm-x-session[723825]:
> org.kde.pim.akonadiserver: arguments:
> ("--defaults-file=/home/mh/.local/share/akonadi/mysql.conf",
> "--datadir=/home/mh/.local/share/akonadi/db_data/",
> "--socket=/run/user/1001/akonadi/mysql.socket",
> "--pid-file=/run/user/1001/akonadi/mysql.pid") Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: stdout: ""
> Apr  3 13:33:52 fan /usr/libexec/gdm-x-session[723825]:
> org.kde.pim.akonadiserver: stderr: "2022-04-03 13:33:47 0 [Note]
> /usr/sbin/mysqld (server 10.6.7-MariaDB-3) starting as process 723831
> ...\n" Apr  3 13:33:52 fan /usr/libexec/gdm-x-session[723825]:
> org.kde.pim.akonadiserver: exit code: 1 Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: process
> error: "Unknown error" Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: Shutting
> down AkonadiServer... Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723819]: org.kde.pim.akonadicontrol: Application
> '/usr/bin/akonadiserver' exited normally... Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[716950]: qt.qpa.xcb: QXcbConnection: XCB error:
> 3 (BadWindow), sequence: 58290, resource id: 67108869, major code: 18
> (ChangeProperty), minor code: 0 Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723843]: Connecting to deprecated signal
> QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) Apr 
> 3 13:33:52 fan /usr/libexec/gdm-x-session[723845]:
> org.kde.pim.akonadicontrol: Service org.freedesktop.Akonadi.Control.lock
> already registered, terminating now. Apr  3 13:33:52 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: Starting up
> the Akonadi Server... Apr  3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: database
> server stopped unexpectedly Apr  3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: Database
> process exited unexpectedly during initial connection! Apr  3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: executable:
> "/usr/sbin/mysqld" Apr  3 13:33:57 fan /usr/libexec/gdm-x-session[723849]:
> org.kde.pim.akonadiserver: arguments:
> ("--defaults-file=/home/mh/.local/share/akonadi/mysql.conf",
> "--datadir=/home/mh/.local/share/akonadi/db_data/",
> "--socket=/run/user/1001/akonadi/mysql.socket",
> "--pid-file=/run/user/1001/akonadi/mysql.pid") Apr  3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: stdout: ""
> Apr  3 13:33:57 fan /usr/libexec/gdm-x-session[723849]:
> org.kde.pim.akonadiserver: stderr: "2022-04-03 13:33:52 0 [Note]
> /usr/sbin/mysqld (server 10.6.7-MariaDB-3) starting as process 723855
> ...\n" Apr  3 13:33:57 fan /usr/libexec/gdm-x-session[723849]:
> org.kde.pim.akonadiserver: exit code: 1 Apr  3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: process
> error: "Unknown error" Apr  3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: Shutting
> down AkonadiServer... Apr  3 13:33:57 fan
> /usr/libexec/gdm-x-session[723843]: org.kde.pim.akonadicontrol: 

Bug#1035403: unblock: src:texlive-extra/2022.20230122-4

[Hilmar Preusse]

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

Please unblock package src:texlive-extra. It was already uploaded
to unstable.

Recently we were informed (#1035313), that color handling for some
dvi viewers is broken due to a bug in pstricks. The upstream author
released a simple fix, which was tested and was proven to solve this
specific issue.

[ Reason ]
We would like to unbreak the color handling in dvi previewers, which
is confusing for end users, if the displayed fonts do not have the
expected color.

[ Impact ]
Wrong color in previewed documents is confusing and could reduce
credibility of used software.

[ Tests ]
There were no automated tests. We applied the (one line) patch we got
from upstream. The submitter confirmed that the patch solved
the specific issue.

[ Risks ]
Code change is rather trivial and should not affect source packages.
The human end users already confirmed that the change is useful.

[ 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

Thanks,
  Hilmar

unblock src:texlive-extra/2022.20230122-4/2022.20230122-4

-- 
sigmentation fault
diff -Nru texlive-extra-2022.20230122/debian/changelog texlive-extra-2022.20230122/debian/changelog
--- texlive-extra-2022.20230122/debian/changelog	2023-03-24 09:56:36.0 +0100
+++ texlive-extra-2022.20230122/debian/changelog	2023-05-02 12:56:07.0 +0200
@@ -1,3 +1,10 @@
+texlive-extra (2022.20230122-4) unstable; urgency=medium
+
+  * Apply patch for pstricks.tex to fix dvi color handling
+(Closes: #1035313).
+
+ -- Hilmar Preusse   Tue, 02 May 2023 12:56:07 +0200
+
 texlive-extra (2022.20230122-3) unstable; urgency=medium
 
   * Apply patch for ooffice.4ht to fix conversion LaTeX ->
diff -Nru texlive-extra-2022.20230122/debian/patches/pstricks_color texlive-extra-2022.20230122/debian/patches/pstricks_color
--- texlive-extra-2022.20230122/debian/patches/pstricks_color	1970-01-01 01:00:00.0 +0100
+++ texlive-extra-2022.20230122/debian/patches/pstricks_color	2023-05-02 09:30:12.0 +0200
@@ -0,0 +1,14 @@
+--- texlive-extra-2022.20230122.orig/texmf-dist/tex/generic/pstricks/pstricks.tex
 texlive-extra-2022.20230122/texmf-dist/tex/generic/pstricks/pstricks.tex
+@@ -4246,8 +4251,9 @@
+ \@namedef{endpspicture*}{\endpspicture}
+ %
+ \ifx\pstcustomize\relax \input pstricks.con \fi
+-\pstVerb{0.8 setlinewidth 0 setgray}%default setting (needed for lualatex)
+-
++%%% changed 20230430 by hv, confuses otherwise the dvi color handling
++\ifluatex\pstVerb{0.8 setlinewidth 0 setgray}\fi%default setting (needed for lualatex)
++%%%
+ \catcode`\@=\PstAtCode\relax
+ %
+ \endinput
diff -Nru texlive-extra-2022.20230122/debian/patches/series texlive-extra-2022.20230122/debian/patches/series
--- texlive-extra-2022.20230122/debian/patches/series	2023-03-15 21:17:39.0 +0100
+++ texlive-extra-2022.20230122/debian/patches/series	2023-05-01 23:30:44.0 +0200
@@ -14,3 +14,4 @@
 # fix-jadetex-new-latex
 #tex4ht-babel
 update_ooffice.4ht
+pstricks_color


signature.asc
Description: PGP signature

Bug#906693: akonadi-server: Akonadi waits to short for password

[Hefee]

Control: tags -1 +moreinfo unreproducible 

Hey,

Sorry that I haven't found time to look to it further.

Well times runs and we already have 20.8 version on current stable 
additionally upstream has moved from direct KWallet support to use QtKeychain 
so also support other key storages. So it is a good time to retest it again, 
if it is still an issue.

Myself hasn't seen this issue for several years.

Regards,

hefee

--


On Sonntag, 19. August 2018 20:57:07 CEST Valentin Petzel wrote:
> Package: akonadi-server
> Version: 4:17.12.3-3
> Severity: normal
> 
> Dear Maintainer,
> 
> When establishing a connection to an account, where the password is
> stored in KWallet, Akonadi prompts the password apparently if it doesn't
> respond for some time. This is set so short that on login one is often
> prompted for the e-Mail accounts' passwords before one has the chance to
> enter the password for KWallet's encryption. You might want to consider
> increasing the time Akonadi waits for the passwords.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500,
> 'oldstable-proposed-updates'), (500, 'unstable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.11-towo.2-siduction-amd64 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de
> (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages akonadi-server depends on:
> ii  akonadi-backend-mysql  4:17.12.3-3
> ii  akonadi-backend-sqlite 4:17.12.3-3
> ii  libc6  2.27-5
> ii  libgcc11:8.2.0-2
> ii  libkf5akonadiprivate5abi1  4:17.12.3-3
> ii  libkf5akonadiwidgets5abi1  4:17.12.3-3
> ii  libkf5configcore5  5.47.0-1
> ii  libkf5coreaddons5  5.47.0-1
> ii  libkf5crash5   5.47.0-1
> ii  libkf5i18n55.47.0-1
> ii  libqt5core5a   5.11.1+dfsg-6
> ii  libqt5dbus55.11.1+dfsg-6
> ii  libqt5gui5 5.11.1+dfsg-6
> ii  libqt5network5 5.11.1+dfsg-6
> ii  libqt5sql5 5.11.1+dfsg-6
> ii  libqt5widgets5 5.11.1+dfsg-6
> ii  libqt5xml5 5.11.1+dfsg-6
> ii  libstdc++6 8.2.0-2
> 
> akonadi-server recommends no packages.
> 
> Versions of packages akonadi-server suggests:
> ii  akonadi-backend-mysql   4:17.12.3-3
> pn  akonadi-backend-postgresql  
> ii  akonadi-backend-sqlite  4:17.12.3-3
> 
> -- no debconf information



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

Bug#1035402: libtpm2-pkcs11-1: libtpm2_pkcs11.so.1 exposes too many symbols, fails to work with strongswan

[Andrew Brown]

Package: libtpm2-pkcs11-1
Version: 1.9.0-0.1
Severity: important
Tags: patch
X-Debbugs-Cc: andr...@twosigma.com

The patch set-version-of-library.patch inadvertently suppresses the
use of "-Wl,--version-script" later in Makefile.am, which leads to
many internal symbols being exposed and/or resolved improperly at
runtime.  One of these is mutex_create().  Strongswan also has a
symbol by that name, so when libstrongswan calls C_Initialize(), the
resulting call (from inside libtpm2_pkcs11.so.1) resolves to the
strongswan symbol.  That function returns a pointer (not an unsigned
long), the C_Initialize() call fails, and Strongswan cannot use the
PKCS11 stack.

The charon process logs a message like this when this happens:

   2023-04-11T21:59:51.231215+00:00 spindle charon: 00[CFG] C_Initialize() 
error for 'tpm2-pkcs11': (-2052707168)

The attached patch (against the offending patch) arranges for the
version-script to be used properly, and also reduces the
libtpm2-pkcs11-1.symbols file to the list of symbols that are now
supposed to be exported.

-- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/1 CPU thread; 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)

Versions of packages libtpm2-pkcs11-1 depends on:
ii  libc6 2.36-9
ii  libsqlite3-0  3.40.1-2
ii  libssl3   3.0.8-1
ii  libtss2-esys-3.0.2-0  3.2.1-3
ii  libtss2-mu0   3.2.1-3
ii  libtss2-rc0   3.2.1-3
ii  libtss2-tctildr0  3.2.1-3
ii  libyaml-0-2   0.2.5-1

libtpm2-pkcs11-1 recommends no packages.

libtpm2-pkcs11-1 suggests no packages.

-- no debconf information
diff --git a/debian/libtpm2-pkcs11-1.symbols b/debian/libtpm2-pkcs11-1.symbols
index d51dfe31..e8b9113f 100644
--- a/debian/libtpm2-pkcs11-1.symbols
+++ b/debian/libtpm2-pkcs11-1.symbols
@@ -68,379 +68,3 @@ libtpm2_pkcs11.so.1 libtpm2-pkcs11-1 #MINVER#
  C_VerifyUpdate@Base 1.2.0
  C_WaitForSlotEvent@Base 1.2.0
  C_WrapKey@Base 1.2.0
- __real_db_tobject_new@Base 1.5.0
- __real_init_pobject@Base 1.5.0
- __real_init_sealobjects@Base 1.5.0
- __real_init_tobjects@Base 1.5.0
- __real_tobject_new@Base 1.5.0
- __real_twistbin_new@Base 1.5.0
- _db_update_tobject_attrs@Base 1.6.0
- _g_ecc_curve_nids_templ@Base 1.5.0
- _g_rsa_keysizes_templ@Base 1.5.0
- _session_ctx_opdata_get@Base 1.2.0
- _tobject_user_decrement@Base 1.6.0
- _tobject_user_increment@Base 1.6.0
- aes256_gcm_decrypt@Base 1.2.0
- aes256_gcm_encrypt@Base 1.2.0
- apply_pkcs7_pad@Base 1.6.0
- attr_CK_BBOOL@Base 1.2.0
- attr_CK_KEY_TYPE@Base 1.2.0
- attr_CK_OBJECT_CLASS@Base 1.2.0
- attr_CK_ULONG@Base 1.2.0
- attr_add_missing_attrs@Base 1.2.0
- attr_common_add_RSA_publickey@Base 1.2.0
- attr_common_add_data@Base 1.3.2
- attr_common_add_storage@Base 1.5.0
- attr_get_attribute_by_type@Base 1.2.0
- attr_get_attribute_by_type_raw@Base 1.2.0
- attr_get_name@Base 1.7.0
- attr_list_add_bool@Base 1.2.0
- attr_list_add_buf@Base 1.2.0
- attr_list_add_int@Base 1.2.0
- attr_list_add_int_seq@Base 1.9.0
- attr_list_append_attrs@Base 1.2.0
- attr_list_append_entry@Base 1.3.2
- attr_list_dup@Base 1.5.0
- attr_list_free@Base 1.2.0
- attr_list_get_CKA_CLASS@Base 1.3.2
- attr_list_get_CKA_KEY_TYPE@Base 1.6.0
- attr_list_get_CKA_PRIVATE@Base 1.3.2
- attr_list_get_CKA_TOKEN@Base 1.5.0
- attr_list_get_count@Base 1.2.0
- attr_list_get_ptr@Base 1.2.0
- attr_list_invoke_handlers@Base 1.2.0
- attr_list_new@Base 1.2.0
- attr_list_raw_invoke_handlers@Base 1.2.0
- attr_list_update_entry@Base 1.3.2
- attr_pfree_cleanse@Base 1.3.2
- attr_typify@Base 1.2.0
- backend_add_object@Base 1.5.0
- backend_create_token_seal@Base 1.5.0
- backend_ctx_free@Base 1.5.0
- backend_ctx_new@Base 1.5.0
- backend_ctx_reset@Base 1.5.0
- backend_destroy@Base 1.5.0
- backend_esysdb_add_object@Base 1.5.0
- backend_esysdb_create_token_seal@Base 1.5.0
- backend_esysdb_ctx_free@Base 1.5.0
- backend_esysdb_ctx_new@Base 1.5.0
- backend_esysdb_ctx_reset@Base 1.5.0
- backend_esysdb_destroy@Base 1.5.0
- backend_esysdb_get_tokens@Base 1.5.0
- backend_esysdb_init@Base 1.5.0
- backend_esysdb_init_user@Base 1.5.0
- backend_esysdb_rm_tobject@Base 1.5.0
- backend_esysdb_token_changeauth@Base 1.5.0
- backend_esysdb_token_unseal_wrapping_key@Base 1.5.0
- backend_esysdb_update_tobject_attrs@Base 1.5.0
- backend_esysdb_update_token_config@Base 1.5.0
- backend_fapi_add_object@Base 1.5.0
- backend_fapi_add_tokens@Base 1.5.0
- backend_fapi_create_token_seal@Base 1.5.0
- backend_fapi_ctx_free@Base 1.5.0
- backend_fapi_ctx_new@Base 1.5.0
- backend_fapi_destroy@Base 1.5.0
- backend_fapi_init@Base 1.5.0
- backend_fapi_init_user@Base 1.5.0
- backend_fapi_rm_tobject@Base 1.5.0
- backend_fapi_token_changeauth@Base 1.5.0
- backend_fapi_token_unseal_wrapping_key@Base 1.5.0
- backend_fapi_update_tobject_attrs@Base 1.5.0
- backend_get_tokens@Base 1.5.0
- backend_init@Base 1.5.0
- 

Bug#1029841: binutils-mingw-w64-x86-64: x86_64-w64-mingw32-ld internal error in ldlang.c

[Dennis Kempin]

Hi Stephen,

would you be able to build a new release that includes the upstream patch?

We currently have the version of binutils-mingw-w64-x86-64 pinned to an
older version to avoid the issue.

Thank you very much!
Dennis

Bug#1035401: tmux as an alternative to screen

[Marc Haber]

Package: release-notes
Severity: minor

Hi,

the release notes in the "preparing a safe environment" chapter
recommend running in screen. Since tmux has reached some matureness in
the mean time, it might be a good idea to mention tmux along screen.

Greetings
Marc

Bug#1035398: [pre-approval] unblock: dwarves/1.24-4.1

[Aurelien Jarno]

Hi Release team and Salvatore,

On 2023-05-02 20:59, Salvatore Bonaccorso wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: dwar...@packages.debian.org, Aurelien Jarno 
> , k...@debian.org, vagr...@debian.org, Domenico Andreoli 
> , car...@debian.org
> Control: affects -1 + src:dwarves
> 
> Dear release team,
> 
> Please unblock package dwarves
> 
> [ Reason ]
> Back in #1033301, Aurelien reported that the arm64 kernel size did
> increase significantly due to issues with BTF deduplication. First
> suspected to be a Linux kernel upstream issue, Aurelien discussed this
> on with upstream and it was found that the issue is caused by a
> src:dwarves regression (applied in 1.24-4).
> 
> Details in https://bugs.debian.org/1033301#31
> 
> The (not yet uploaded) dwarves upload with attache debdiff
> cherry-picks the upstream commit.
> 
> (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.)
> 
> [ Impact ]
> Increased arm64 kernel size.
> 
> [ Tests ]
> Apart from the report from Aurelien[1], package passes its autopkgtest.
> 
>  [1]  https://lore.kernel.org/linux-arm-kernel/zezhajup21ln5...@aurel32.net/

Thanks a lot for preparing this pre-approval request and the
corresponding upload. I confirm that I tested the exact same change on
arm64, on both native and cross-compiled build and that it fixes the
issue I reported.

> [ Risks ]
> The upstream commit zero-initializes memory which previous was not
> initialized after allocation, and might have contained garbage values
> which were used. The fix is isolated as a oneliner.

I agree that the risk is quite low. The fix also likely improves
reproducibility by removing a dependence on build time random data which
is always good think.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net


signature.asc
Description: PGP signature

Bug#993985: wireguard should not depend on wireguard-dkms or wireguard-modules in Debian 11

[Kevin P. Fleming]

Package: wireguard-tools
Followup-For: Bug #993985

Dear Maintainer,

In Debian 11 (currently 'testing'), there are no packages which provide
'wireguard-dkms', and 'wireguard-modules' is provided by the standard 'linux-
image-' packages. As a result there is no apparent value in having
'wireguard-tools' recommend either of those.

In fact on a system which intentionally does *not* have the 'linux-
image-' package installed, installing 'wireguard-tools' will pull it in
unless the user tells it not to, and may pull it in in the future when the
'wireguard-tools' package is upgraded and 'apt upgrade' is run... unless the
user once again remember to tell 'apt' to not install recommended packages.


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

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

Versions of packages wireguard-tools depends on:
ii  libc6  2.36-9

Versions of packages wireguard-tools recommends:
ii  iptables   1.8.9-2
ii  linux-image-amd64 [wireguard-modules]  6.1.20-2
ii  nftables   1.0.6-2

Versions of packages wireguard-tools suggests:
pn  openresolv | resolvconf  

-- no debconf information

Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[John Scott]

> I do not indend to hijack/adopt gnupg2, so I am very reluctant to upload
> without some kind of go from Daniel or Eric. (Even to experimental.)
> 
> However I have updated the GIT branches to 2.4.1 today.

Thanks for your hard work Andreas! Those packages do indeed solve issues for me 
and bring desirable features, especially as a user of OpenPGP cards.


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1034336: unblock: openvpn/2.6.3-1 and openvpn-dco-dkms/0.0+git20230324-1 (pre-approval)

[Bernhard Schmidt]

Control: tags -1 - moreinfo

> > in order to reduce the deviation from an upstream tag I'd like to skip
> > 2.6.2 and go for 2.6.3. Updated debdiff attached.
> 
> Please go ahead and remove the moreinfo tag once the packages are
> available in unstable.

Uploaded, accepted and built on all architectures. piuparts is clean,
the autopkgtest of openvpn-dco-dkms also ran fine. The autopkgtest for
openvpn won't run in the Debian infrastructure due to the unsupported
isolation-machine restriction.

Please unblock (and - if possible - age) both packages.

unblock openvpn/2.6.3-1
unblock openvpn-dco-dkms/0.0+git20230324-1

Bernhard


signature.asc
Description: PGP signature

Bug#1035392: installation-reports: Installation Report: Bookworm RC2: Raspberry Pi 400 (netboot)

[James Addison]

Package: installation-reports
Followup-For: Bug #1035392

> The only customized dnsmasq setting required was:
>
>   pxe-service=0, "Raspberry Pi Boot"

Oops, I lied.  There was one other relevant dnsmasq setting:

  dhcp-boot=bootnetaa64.efi

(telling the device what EFI filename to retrieve and run from the TFTP server)

Bug#1035400: lucene8: reproducible builds: username embedded in .jar files

[Vagrant Cascadian]

Source: lucene8
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: username
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Various .jar files embed the username:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/lucene8.html

  /usr/share/java/lucene-analyzers-common-8.7.0.jar

  Implementation-Version:·8.8.1-4·unknown·-·pbuilder1·-·2022-11-25·13:00\xd
  vs.
  Implementation-Version:·8.8.1-4·unknown·-·pbuilder2·-·2022-11-25·13:00\xd

The attached patches fix this by removing the user.name from the
Implementation-Version fields in various template .xml files.

According to my local tests, with these patches applied lucene8 should
become reproducible on tests.reproducible-builds.org!

Thanks for maintaining lucene8!

live well,
  vagrant
From 42be160c88c6d81278c85c0dbd612b1c84b1e2bb Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 2 May 2023 12:20:34 -0700
Subject: [PATCH 1/4] common-build.xml: Remove user from
 Implementation-Version.

---
 common-build.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common-build.xml b/common-build.xml
index 96c5ba5..2bb79f7 100644
--- a/common-build.xml
+++ b/common-build.xml
@@ -793,7 +793,7 @@
 
 
 
+   value="${version} ${checkoutid} - ${DSTAMP} ${TSTAMP}"/>
 
 
-- 
2.39.2

From 8655f43ae17ad1fa707fd7e3d08af328b11479e8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 2 May 2023 12:22:17 -0700
Subject: [PATCH 2/4] debian/poms/lucene-solr-grandparent.pom.xml: Remove build
 user from Implementation-Version.

---
 debian/poms/lucene-solr-grandparent.pom.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/poms/lucene-solr-grandparent.pom.xml b/debian/poms/lucene-solr-grandparent.pom.xml
index b0df3c7..c34075c 100644
--- a/debian/poms/lucene-solr-grandparent.pom.xml
+++ b/debian/poms/lucene-solr-grandparent.pom.xml
@@ -11686,7 +11686,7 @@
 ${specification.version}
 The Apache Software Foundation
 
-${project.version} ${checkoutid} - ${user.name} - ${now.timestamp}
+${project.version} ${checkoutid} - ${now.timestamp}
 The Apache Software Foundation
 ${project.groupId}
 ${java.compat.version}
@@ -11812,7 +11812,7 @@
 ${specification.version}
 The Apache Software Foundation
 
-${project.version} ${checkoutid} - ${user.name} - ${now.timestamp}
+${project.version} ${checkoutid} - ${now.timestamp}
 The Apache Software Foundation
 ${project.groupId}
 ${java.compat.version}
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1035397: pm-utils is abandoned, should be removed from Debian

[Ian Jackson]

Control: retitle -1 Consider maintainership transfer to d-i-d team

Mario Limonciello writes ("Bug#1035397: pm-utils is abandoned, should be 
removed from Debian"):
> pm-utils hasn't had any changed in 13 years upstream.  It's been effectively 
> replaced by
> systemd-sleep in all practical ways.
> 
> It should be removed from the archive.

Since I don't use systemd, obviously I don't agree.  If necessary I
will consider myself upstream, but I think there are probably other
people worth collaborating with.  Anyway, I'm not changing this
package for bookworm at this stage unless to fix a very serious bug.

For the next release, I agree that this package could do with some
love.  It might be worth transferring maintainership to the Debian
Init Diversity Team, and in any case the patches ought to be reviewed
and applied.

For the avoidance of doubt: I would of course welcome constructive
NMUs.  Members of the Debian Init Diversity Team are welcome to do
0-day NMUs.  But, not during the freeze.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1032994: unblock: node-webpack/5.76.1+dfsg1+~cs17.16.16-1

[Paul Gevers]

Hi Yadd,

On 02-05-2023 10:15, Yadd wrote:

extracting only CVE patch means:
  * keep some (unimportant) bugs in Bullseye
  * publish such version number:
    5.76.1+dfsg1+~cs17.16.16+really~5.75.0+dfsg+~cs17.16.14-1


Indeed, both are totally acceptable. Can we have a debdiff please?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035399: grub2: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: grub2 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of grub2 debconf
messages. A draft has been posted to the debian-l10n-dutch mailing list
allowing for review. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1035380: [3dprinter-general] Bug#1035380: prusa-slicer: segfaults at start if window is too small

[Félix Sipma]

"too small" is a width around 600px.

The output of `coredumpctl info` follows, is it enough?

   PID: 378245 (slic3r_main)
   UID: 1000 (gueux)
   GID: 1000 (gueux)
Signal: 11 (SEGV)
 Timestamp: Tue 2023-05-02 20:59:03 CEST (5min ago)
  Command Line: prusa-slicer
Executable: /usr/bin/prusa-slicer
 Control Group: /user.slice/user-1000.slice/session-2.scope
  Unit: session-2.scope
 Slice: user-1000.slice
   Session: 2
 Owner UID: 1000 (gueux)
   Boot ID: 93f374270995410e90a0a604288f7249
Machine ID: bd1078e9de2113789ff1dde150518661
  Hostname: capeo
   Storage: 
/var/lib/systemd/coredump/core.slic3r_main.1000.93f374270995410e90a0a604288f7249.378245.168305394300.zst
 (present)
  Size on Disk: 21.0M
   Message: Process 378245 (slic3r_main) of user 1000 dumped core.

Module libudev.so.1 from deb systemd-252.6-1.amd64

Module libnss_myhostname.so.2 from deb systemd-252.6-1.amd64
Module libsystemd.so.0 from deb systemd-252.6-1.amd64
Stack trace of thread 378245:
#0  0x55c9e8291208 n/a (prusa-slicer + 0xe6a208)
#1  0x55c9e822a5eb n/a (prusa-slicer + 0xe035eb)
#2  0x55c9e822a8b6 n/a (prusa-slicer + 0xe038b6)
#3  0x55c9e81d8a94 n/a (prusa-slicer + 0xdb1a94)
#4  0x55c9e81e1570 n/a (prusa-slicer + 0xdba570)
#5  0x55c9e81f64f4 n/a (prusa-slicer + 0xdcf4f4)
#6  0x55c9e81f6b9e n/a (prusa-slicer + 0xdcfb9e)
#7  0x55c9e81f6d07 n/a (prusa-slicer + 0xdcfd07)
#8  0x7f54530086d2 
_ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent
 (libwx_baseu-3.2.so.0 + 0x2086d2)
#9  0x7f5453008b2e 
_ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent (libwx_baseu-3.2.so.0 + 
0x208b2e)
#10 0x7f5453008e80 _ZN12wxEvtHandler11TryHereOnlyER7wxEvent 
(libwx_baseu-3.2.so.0 + 0x208e80)
#11 0x7f5453008f2a 
_ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent (libwx_baseu-3.2.so.0 + 
0x208f2a)
#12 0x7f5453009031 
_ZN12wxEvtHandler12ProcessEventER7wxEvent (libwx_baseu-3.2.so.0 + 0x209031)
#13 0x7f545300a7c7 
_ZN12wxEvtHandler18SafelyProcessEventER7wxEvent (libwx_baseu-3.2.so.0 + 
0x20a7c7)
#14 0x7f54529714b0 
_ZN12wxWindowBase14SendIdleEventsER11wxIdleEvent (libwx_gtk3u_core-3.2.so.0 + 
0x5714b0)
#15 0x7f5452971488 
_ZN12wxWindowBase14SendIdleEventsER11wxIdleEvent (libwx_gtk3u_core-3.2.so.0 + 
0x571488)
#16 0x7f5452971488 
_ZN12wxWindowBase14SendIdleEventsER11wxIdleEvent (libwx_gtk3u_core-3.2.so.0 + 
0x571488)
#17 0x7f5452971488 
_ZN12wxWindowBase14SendIdleEventsER11wxIdleEvent (libwx_gtk3u_core-3.2.so.0 + 
0x571488)
#18 0x7f5452971488 
_ZN12wxWindowBase14SendIdleEventsER11wxIdleEvent (libwx_gtk3u_core-3.2.so.0 + 
0x571488)
#19 0x7f54527e6525 
_ZN7wxFrame14SendIdleEventsER11wxIdleEvent (libwx_gtk3u_core-3.2.so.0 + 
0x3e6525)
#20 0x7f545284718d _ZN9wxAppBase11ProcessIdleEv 
(libwx_gtk3u_core-3.2.so.0 + 0x44718d)
#21 0x7f54527514e9 _ZN5wxApp6DoIdleEv 
(libwx_gtk3u_core-3.2.so.0 + 0x3514e9)
#22 0x7f5452751623 n/a (libwx_gtk3u_core-3.2.so.0 + 
0x351623)
#23 0x7f545231c67f g_main_context_dispatch 
(libglib-2.0.so.0 + 0x5467f)
#24 0x7f545231ca38 n/a (libglib-2.0.so.0 + 0x54a38)
#25 0x7f545231ccef g_main_loop_run (libglib-2.0.so.0 + 
0x54cef)
#26 0x7f5451c08435 gtk_main (libgtk-3.so.0 + 0x208435)
#27 0x7f545276df85 _ZN14wxGUIEventLoop5DoRunEv 
(libwx_gtk3u_core-3.2.so.0 + 0x36df85)
#28 0x7f5452ed7fad _ZN15wxEventLoopBase3RunEv 
(libwx_baseu-3.2.so.0 + 0xd7fad)
#29 0x7f5452ea2a9b _ZN16wxAppConsoleBase8MainLoopEv 
(libwx_baseu-3.2.so.0 + 0xa2a9b)
#30 0x7f5452f1fec7 _Z7wxEntryRiPPw (libwx_baseu-3.2.so.0 + 
0x11fec7)
#31 0x55c9e7e292e9 n/a (prusa-slicer + 0xa022e9)
#32 0x55c9e7748ace n/a (prusa-slicer + 0x321ace)
#33 0x55c9e771e274 n/a (prusa-slicer + 0x2f7274)
#34 0x7f545184618a n/a (libc.so.6 + 0x2718a)
#35 0x7f5451846245 __libc_start_main (libc.so.6 + 0x27245)
#36 0x55c9e7741281 n/a (prusa-slicer + 0x31a281)

Stack trace of thread 378247:

#0  0x7f54518a4d36 n/a (libc.so.6 + 0x85d36)
#1  0x7f54518a73f8 pthread_cond_wait (libc.so.6 + 0x883f8)
#2  0x7f54522878dd 
_ZZN8progschj10ThreadPool12start_workerEmRKSt11unique_lockISt5mutexEENKUlvE_clEv
 

Bug#1035096: installation-report Bookworm RC2 GRUB not installed

[Pascal Hambourg]

On 02/05/2023 at 15:21, Peter Ehlert wrote:


DI asks on which drive to install GRUB
User says disk X
DI attempts to install on Drive Y
result ... GRUB does not get installed at all


This is completely different from what I understood.

The statement "GRUB does not get installed at all" is refuted by 
/var/log/syslog which indicates clearly that GRUB was successfully 
installed on /dev/sdb:



Apr 28 23:55:51 grub-installer: info: Running chroot /target grub-install  --force 
"/dev/sdb"
(...)
Apr 28 23:56:01 grub-installer: Installation finished. No error reported.


Can you described what happened exactly ?
Were you prompted to "Install the GRUB boot loader to your primary 
drive?" ? If yes, did you answer "yes" or "no" ?
Where you then prompted to select the "Device for boot loader 
installation" ? If yes, what option did you select exactly ?


setting up BIOS to boot from a drive that does not have a bios_grub 
flagged partition results in:


"GPT-formatted disk.

Legacy boot not supported. Press any key to reboot."


If this is a message from the BIOS, then it is flawed. A compliant BIOS 
should not care about the partition table, even less the presence of any 
kind of partition. All a BIOS should care about is the presence of the 
"boot signature" 0x55, 0xAA at the end of the boot sector.

Bug#1035398: [pre-approval] unblock: dwarves/1.24-4.1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: dwar...@packages.debian.org, Aurelien Jarno , 
k...@debian.org, vagr...@debian.org, Domenico Andreoli , 
car...@debian.org
Control: affects -1 + src:dwarves

Dear release team,

Please unblock package dwarves

[ Reason ]
Back in #1033301, Aurelien reported that the arm64 kernel size did
increase significantly due to issues with BTF deduplication. First
suspected to be a Linux kernel upstream issue, Aurelien discussed this
on with upstream and it was found that the issue is caused by a
src:dwarves regression (applied in 1.24-4).

Details in https://bugs.debian.org/1033301#31

The (not yet uploaded) dwarves upload with attache debdiff
cherry-picks the upstream commit.

(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.)

[ Impact ]
Increased arm64 kernel size.

[ Tests ]
Apart from the report from Aurelien[1], package passes its autopkgtest.

 [1]  https://lore.kernel.org/linux-arm-kernel/zezhajup21ln5...@aurel32.net/
[ Risks ]
The upstream commit zero-initializes memory which previous was not
initialized after allocation, and might have contained garbage values
which were used. The fix is isolated as a oneliner.

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

[ Other info ]
Ideally this enters the archive before a next upload for src:linux is
built (and which would be aimed for bookworm).

unblock dwarves/1.24-4.1

Regards,
Salvatore
diff -Nru dwarves-1.24/debian/changelog dwarves-1.24/debian/changelog
--- dwarves-1.24/debian/changelog   2022-12-10 10:11:28.0 +0100
+++ dwarves-1.24/debian/changelog   2023-05-02 20:37:16.0 +0200
@@ -1,3 +1,13 @@
+dwarves (1.24-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * dwarves: Zero-initialize struct cu in cu__new() to prevent incorrect BTF
+types.
+Fixes BTF deduplication issues causing arm64 kernel size increase.
+Thanks to Aurelien Jarno (Closes: #1033301)
+
+ -- Salvatore Bonaccorso   Tue, 02 May 2023 20:37:16 +0200
+
 dwarves (1.24-4) unstable; urgency=medium
 
   * Backport upstream patches to support newer toolchains.
diff -Nru 
dwarves-1.24/debian/patches/03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch
 
dwarves-1.24/debian/patches/03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch
--- 
dwarves-1.24/debian/patches/03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch
   1970-01-01 01:00:00.0 +0100
+++ 
dwarves-1.24/debian/patches/03-dwarves-Zero-initialize-struct-cu-in-cu__new-to-prev.patch
   2023-05-02 20:37:16.0 +0200
@@ -0,0 +1,94 @@
+From: Alan Maguire 
+Date: Fri, 21 Oct 2022 16:02:03 +0100
+Subject: dwarves: Zero-initialize struct cu in cu__new() to prevent incorrect
+ BTF types
+Origin: 
https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit?id=b72f5188856df0abf45e1a707856bb4e4e86153c
+Bug-Debian: https://bugs.debian.org/1033301
+
+BTF deduplication was throwing some strange results, where core kernel
+data types were failing to deduplicate due to the return values
+of function type members being void (0) instead of the actual type
+(unsigned int).  An example of this can be seen below, where
+"struct dst_ops" was failing to deduplicate between kernel and
+module:
+
+struct dst_ops {
+short unsigned int family;
+unsigned int gc_thresh;
+int (*gc)(struct dst_ops *);
+struct dst_entry * (*check)(struct dst_entry *, __u32);
+unsigned int (*default_advmss)(const struct dst_entry *);
+unsigned int (*mtu)(const struct dst_entry *);
+...
+
+struct dst_ops___2 {
+short unsigned int family;
+unsigned int gc_thresh;
+int (*gc)(struct dst_ops___2 *);
+struct dst_entry___2 * (*check)(struct dst_entry___2 *, __u32);
+void (*default_advmss)(const struct dst_entry___2 *);
+void (*mtu)(const struct dst_entry___2 *);
+...
+
+This was seen with
+
+bcc648a10cbc ("btf_encoder: Encode DW_TAG_unspecified_type returning routines 
as void")
+
+...which rewrites the return value as 0 (void) when it is marked
+as matching DW_TAG_unspecified_type:
+
+static int32_t btf_encoder__tag_type(struct btf_encoder *encoder, uint32_t 
type_id_off, uint32_t tag_type)
+{
+   if (tag_type == 0)
+   return 0;
+
+   if (encoder->cu->unspecified_type.tag && tag_type == 
encoder->cu->unspecified_type.type) {
+   // No provision for encoding this, turn it into void.
+   return 0;
+   }
+
+   return type_id_off + tag_type;
+}
+
+However the odd thing was that on further examination, the unspecified type
+was not being set, so why was this logic being tripped?  Futher debugging
+showed that the 

Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[James Addison]

On Mon, 1 May 2023 at 20:03, Cyril Brulebois  wrote:
> James Addison  (2023-05-01):
> > Also, the brcmfmac kernel module code mentions[3] that it can load
> > board-specific firmware file paths.  I'm not yet sure whether that's
> > relevant (either now, or in future).
>
> Yeah, both the function you pointed to and the one handling actual
> firmware requests seem to know about some alt_fw semantics, with a
> fallback. But I'm not diving into that rabbit hole. :)

That's a sensible strategy :)

Could either of you (Cyril, Diederik) recommend where I should ask
(and/or clone this bug) to follow up on the firmware filename issue,
given that the filename(s) seem to be generated from the kernel
module?

(as a recap: the brcmfmac module attempts to load a file of the format
"brcmfmac43455-sdio.Raspberry Pi Foundation-Raspberry Pi 4 Model
B.txt" instead of "brcmfmac43455-sdio.txt" -- I saw the same thing
during my install, with string adjustments for brcmfmac43456 and Pi
400)

I think that that's likely to be the cause of the firmware-not-loaded
problems in installation-reports #989593 and #1035392 (that second
report is from me, earlier today).  Even with the 'Contents-firmware'
file-to-package mapping, we won't find the relevant firmware file if
the name is wrong.

> Regarding “plans for the future”, it's worth mentioning #1033921, now
> cloned as #1035356. While the former is about license acceptance for
> some firmware packages specifically (and about to be fixed for bookworm)
> the latter is for longer term, with a proposed patch changing the logic
> around iterating over firmware filenames. I'm not saying it's going to
> solve spaces-in-filenames as it is, I just thought it'd make sense to
> mention it as that touches one relevant part of the hw-detect code.

Thank you; yep, I've followed _most_ of that (and arrived back here
again).  I will admit that most of what I've cognitively loaded from
it is "this script could use refactoring post-bookworm", and have not
processed the complete details.

Regards,
James

Bug#1035397: pm-utils is abandoned, should be removed from Debian

[Limonciello, Mario]

[Public]

There was a comment on #852167 that there are no non-systemd tools, but that's 
simply not true.

All you need for a suspend is

echo mem | sudo tee /sys/power/state

BTW - there's a reason that systemd refuses to include a lot of hooks and 
quirks.
The scripts/quirks/etc that pm-utils does are presumptuous and generally not 
correct.

Bug#1035397: pm-utils is abandoned, should be removed from Debian

[Mario Limonciello]

Package: pm-utils
Severity: important
X-Debbugs-Cc: mario.limoncie...@amd.com

Dear Maintainer,

pm-utils hasn't had any changed in 13 years upstream.  It's been effectively 
replaced by
systemd-sleep in all practical ways.

It should be removed from the archive.


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

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

Versions of packages pm-utils depends on:
ii  powermgmt-base  1.36

Versions of packages pm-utils recommends:
pn  ethtool  
ii  hdparm   9.60+ds-1build3
pn  vbetool  

Versions of packages pm-utils suggests:
pn  cpufrequtils
pn  radeontool  

Bug#1017887: grub-efi-amd64-signed: SecureBoot Grub-Install with Custom Bootloader ID Drops Grub into Grub Shell

[Pascal Hambourg]

(Not replying to the submitter because gmail rejects all my mails)

On Mon, 22 Aug 2022 10:58:06 +0800 Chew Kean Ho 
 wrote:


When performing a manual grub-install in a debootstrap Debian OS setup,
installing SecureBoot Grub with --bootloader-id value other than 'debian' causes
the Grub to drop into Grub Shell (failed to locate /boot/grub/grub.cfg) despite
having the UUID and root prefix values correct at /boot/EFI//grub.cfg
level.


This bug should be partially fixed since version 2.06-3~deb11u5 as a 
lucky side effect of embedding a grub.cfg into memdisk.



Exact cause is unknown (still not sure what causes the drop). The only
workaround is NOT to mess with the --bootloader-id or set --bootloader-id to
strictly 'debian' as value.


The cause is well known, see #925309. (maybe merge the two bugs ?)


An effective workaround was to copy /boot/EFI//grub.cfg into 
/boot/EFI/debian/ where GRUB expected to find it.



The same thing happens when SecureBoot is turned off at BIOS.


If secure boot is disabled, another workaround was to install GRUB 
without secure boot support, either by removing shim-signed or by 
running grub-install --no-uefi-secure-boot.

Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

[Ian Jackson]

Control: clone -1 -2
Control: retitle -2 ancient chown syntax
Control: severity -2 serious

Andreas Beckmann writes ("Re: Bug#1035361: sauce: Potentially dangerous mode on 
/etc/logrotate.d/sauce: 0755"):
> Setting up sauce (0.9.1) ...
> Checking for SAUCE databases in /var/lib/sauce ...
>   cdb.site-annoy (no existing data)  donechown: warning: '.' should be 
> ':': 'mail.mail'
> chown: warning: '.' should be ':': 'mail.mail'
> chown: warning: '.' should be ':': 'mail.mail'
> chown: warning: '.' should be ':': 'mail.mail'

etc.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

[Ian Jackson]

Andreas Beckmann writes ("Re: Bug#1035361: sauce: Potentially dangerous mode on 
/etc/logrotate.d/sauce: 0755"):
> [trying] it manually by installing logrotate and sauce in a chroot 
> (without removing sauce again):

Ah!

Thanks for investigating.  I think that I ought to fix the
permissions of the logrotate.d and the chown syntax.

I will do some more tests to check about whether that's sufficient or
whether "missingok" is needed too.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1035375: mtools: interprets SOURCE_DATE_EPOCH in system timezone instead of UTC

[Chris Lamb]

tags 1035375 + patch
forwarded 1035375 
https://lists.gnu.org/archive/html/info-mtools/2023-05/msg0.html
thanks

Hi Alper,

> I came across timestamp differences in FAT filesystem images while
> trying to build debian-installer with debrepro (among many other
> things), and tracked it down to mmd/mcopy calls. Here's a short reproducer:

Ah, interesting! And your reproducer is extremely helpful, and
I've managed to put together a proof-of-concept patch:

--- a/directory.c
+++ b/directory.c
@@ -104,7 +104,7 @@ struct directory *mk_entry(const dos_name_t *dn, 
unsigned char attr,
  uint8_t hour, min_hi, min_low, sec;
  uint8_t year, month_hi, month_low, day;
 
-   now = localtime();
+   now = gmtime();
  dosnameToDirentry(dn, ndir);
  ndir->attr = attr;
  ndir->ctime_ms = 0;
-- 
2.40.1

I've gone ahead and forwarded this to the mtools mailing list here:

  https://lists.gnu.org/archive/html/info-mtools/2023-05/msg0.html


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Domenico Andreoli]

On 29 April 2023 11:56:19 CEST, Salvatore Bonaccorso  wrote:
>Hi Aurelien,
>
>On Sat, Apr 29, 2023 at 09:50:57AM +0200, Aurelien Jarno wrote:
>> control: reassign -1 pahole/1.24-4
>> control: retitle -1 pahole: BTF deduplication issues causing arm64 kernel 
>> size increase
>> control: tag -1 + fixed-upstream
>> control: tag -1 + patch
>> control: affects -1 u-boot-rpi src:linux
>> 
>> Hi,
>> 
>> On 2023-03-21 23:11, Aurelien Jarno wrote:
>> > Source: linux
>> > Version: 6.1.15-1
>> > Severity: important
>> > Tags: upstream
>> > X-Debbugs-Cc: vagr...@debian.org
>> > Control: affects -1 + u-boot-rpi
>> > 
>> > Hi,
>> > 
>> > Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
>> > Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
>> > to boot with:
>> > 
>> > | 40175552 bytes read in 1695 ms (23 MiB/s)
>> > | 43794863 bytes read in 1817 ms (23 MiB/s)
>> > | Moving Image from 0x8 to 0x20, end=299
>> > | ERROR: RD image overlaps OS image (OS=0x20..0x299)
>> > 
>> > I tracked the issue to a significant increase of the kernel size between
>> > version 6.1.12-1 and 6.15-1:
>> > 
>> > | 31492   /boot/vmlinuz-6.1.0-5-arm64
>> > | 39236   /boot/vmlinuz-6.1.0-6-arm64
>> > 
>> > This is more than the 36MB that is allowed by u-boot with the default
>> > load addresses. A workaround is to shift the load addresses at the
>> > u-boot level as in the attached patch.
>> > 
>> > I have tracked issue on the upstream kernel side to the following commit
>> > on the stable tree:
>> > 
>> > | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
>> > | Author: Masahiro Yamada 
>> > | Date:   Thu Oct 13 08:35:00 2022 +0900
>> > | 
>> > | arm64: remove special treatment for the link order of head.o
>> > | 
>> > | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
>> > | 
>> > | In the previous discussion (see the Link tag), Ard pointed out that
>> > | arm/arm64/kernel/head.o does not need any special treatment - the 
>> > only
>> > | piece that must appear right at the start of the binary image is the
>> > | image header which is emitted into .head.text.
>> > | 
>> > | The linker script does the right thing to do. The build system does
>> > | not need to manipulate the link order of head.o.
>> > | 
>> > | Link: 
>> > https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
>> > | Suggested-by: Ard Biesheuvel 
>> > | Signed-off-by: Masahiro Yamada 
>> > | Reviewed-by: Nicolas Schier 
>> > | Link: 
>> > https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
>> > | Signed-off-by: Will Deacon 
>> > | Signed-off-by: Tom Saeger 
>> > | Signed-off-by: Greg Kroah-Hartman 
>> > 
>> > The problem is still reproducible on Linus' master.
>> > 
>> > I am reporting the bug to the linux package as I believed there is no
>> > real reason for such an increase in the kernel size. In case I missed
>> > something and this is actually wanted, the bug can be reassigned to the
>> > u-boot package.
>> 
>> This has been discussed upstream, and it appears that the issue is not
>> reproducible with pahole 1.25. Looking at the part that needs to be
>> backported to the Debian package, I have found that the issue is caused
>> by the following patch backported in version 1.24-4:
>> 
>> 02-encode-DW_TAG_unspecified_type-returning-routines-as-void.patch
>> 
>> This patch has an issue, and memory is not initialized after allocation,
>> so garbage values are used instead. A one-liner fix has been committed
>> upstream not so long after the initial patch:
>> 
>> https://git.kernel.org/pub/scm/devel/pahole/pahole.git/commit/?id=b72f5188856df0abf45e1a707856bb4e4e86153c
>> 
>> I am therefore reassigning the bug to pahole where the bug should be
>> fixed. Even if Bookworm is now fully frozen, I personally believe this
>> bug should still be fixed before the release. That said, this has to be
>> discussed with the release team, and as pahole is a key package you need
>> a pre-approval *before* the upload to sid. 
>
>Thanks for tracking this down!
>
>Domenico, I would say, it would eben be good to have this in in the
>archive for bookworm before the next (last?) linux upload for bookworm
>ideally. This is not yet planned but, the last one should probably be
>latest in the week of 15th May.
>
>Regards,
>Salvatore

Hi,

  Apologies for not having sent a VAC message but I'm unable to handle this in 
a timely manner.

Please proceed with a NMU.

Thanks,
Dom

Bug#1032902: Numba issues for genx for other architectures than amd64 and ppc64el (Was: genx won't start: TypeError: Pen(): arguments did not match any overloaded call)

[Nilesh Patra]

On Sat, Apr 29, 2023 at 07:44:24PM +0530, Nilesh Patra wrote:
> On Tue, Apr 18, 2023 at 03:54:23PM +0200, Andreas Tille wrote:
> >2. Remove the package from testing for the moment.  The only
> >   rdepends is currently pan-grazing-incidence which will be
> >   lowered to suggests once we re-render debian-pan metapackages.
> 
> It is a possible option but it maybe a useful package in itself.
> This numba situation has arised due to uploading a new upstream update
> of genx during hard freeze (I wonder why this happened).

I guess I understand the reason for this:

> I think we do have a third alternative:
> 
> > What do you think?
> 
> 3. Cherry-pick the commit[6] for fixing this bug and upload to t-p-u by
> asking release team first, or go ahead with a +really scheme whichever
> seems better, but it needs to be done quickly.

I guess I ended up under-estimating the fix. Even after applying heaps
of patches, genx is rendering broken for me, in the sense that the GUI is up but
I am observing some concerning warnings/errors in the logs, which means that I 
need to pick more and more commits to the point that the delta becomes huge for 
existing package.

It probably _genuinely_ needs a new version that Roland uploaded, which had 
major rework and has fixes for
many bugs.

I think it is better out of bookworm at the moment.

My 2 cents.

> > [1] 
> > 

Bug#1035380: [3dprinter-general] Bug#1035380: prusa-slicer: segfaults at start if window is too small

[Gregor Riepl]

I use a tiling window manager (sway). If I start prusa-slicer and the
resulting window is too small, the program segfaults:

 $ prusa-slicer
 [2023-05-02 15:49:42.874172] [0x7f8b39d49d80] [trace]
 Initializing StaticPrintConfigs
 15:49:45: Debug: window wxTreeCtrl@0x558be9c7d190 ("treeCtrl") lost
 focus even though it didn't have it
 15:49:45: Debug: window wxTreeCtrl@0x558be9c7d190 ("treeCtrl") lost
 focus even though it didn't have it
 Segmentation fault (core dumped)


Could you add a stack trace as well?
It will be easier to debug the issue or report it upstream that way.
coredumpctl will help, and possibly some debug symbol packages.

Also, can you explain what "too small" means exactly, to help reproduce 
the problem?

Bug#1035395: wide-dhcpv6-client does not recover if the network layer becomes unready.

[Phil Leinster]

Package: wide-dhcpv6-client
Version: 20080615-23
Severity: important
Tags: ipv6
X-Debbugs-Cc: philleins...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   If the network layer becomes unready, or the service starts before
   the network interface is ready, the service fails to operate on that
   interface. The following message is logged "client6_send: transmit
   failed: Network is unreachable"
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Normal network activity. PPP interfaces are particularly affected
 due to their non-permanent status.
   * What was the outcome of this action?
 IPv6 address was not requested and the lease lapsed after the
 timeout.
   * What outcome did you expect instead?
 Standard IPv6 connectivity without interruption.
 This issue can be worked around with a restart of the service.

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


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

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

Versions of packages wide-dhcpv6-client depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  libc6  2.31-13+deb11u6
ii  libfl2 2.6.4-8
ii  lsb-base   11.1.0
ii  sharutils  1:4.15.2-5

wide-dhcpv6-client recommends no packages.

wide-dhcpv6-client suggests no packages.

-- Configuration Files:
/etc/wide-dhcpv6/dhcp6c.conf changed:
profile default
{
  information-only;
  request domain-name-servers;
  request domain-name;
  script "/etc/wide-dhcpv6/dhcp6c-script";
};
interface ppp0 {
#prefix ::/56 3600;
# Request Prefix Delegation on ppp0, and give the received prefix id 2
send ia-pd 2;
#send ia-na 1;
};
id-assoc pd 2 {
prefix-interface ppp0 {
sla-len 8; # <- IMPORTANT: 8 because our small net is 64 and our 
big is 56 and that is the difference
sla-id 0;  # This is the subnet assigned within the SLA
ifid 1;# This is the host portion of the address
};
prefix-interface enp1s0 {
# Assign subnet 1 to enp1s0
sla-len 8; # <- IMPORTANT: 8 because our small net is 64 and our 
big is 56 and that is the difference
sla-id 1;
ifid 1;
};
prefix-interface enp1s0.16 {
# Assign subnet 1 to enp1s0
sla-len 8; # <- IMPORTANT: 8 because our small net is 64 and our 
big is 56 and that is the difference
sla-id 2;
ifid 1;
};
};


-- debconf information:
* wide-dhcpv6-client/interfaces: enp3s0

Bug#1002393: mdp: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[textshell]

Bump to avoid auto removal while the fixed version ages in unstable.

I'm not sure if this needs some additional prodding because tracker
only shows one of the bugs as fixed by migration and 2 bugs triggering
auto removal.

Bug#1035394: lcov: reproducible-builds: timezone-dependent timestamps on /usr/bin/*

[Vagrant Cascadian]

Source: lcov
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps timezone
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in various /usr/bin/* files is timezone
dependent:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/lcov.html

  lcov_1.16-1_all.deb

  
-rwxr-xr-x···0·root·(0)·root·(0)·4568·2022-06-06·08:19:45.00·./usr/bin/gendesc
  vs.
  
-rwxr-xr-x···0·root·(0)·root·(0)·4568·2022-06-05·18:19:45.00·./usr/bin/gendesc


The attached patch fixes this by removing a call to touch from the
updateversion.pl script.


According to my local tests, with this patch applied lcov should build
reproducibly on tests.reproducible-builds.org!


Thanks for maintaining lcov!


live well,
  vagrant
From f5e0643c16b6980a32602dbef893f5017418d936 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 2 May 2023 10:09:42 -0700
Subject: [PATCH] bin/updateversion.pl: Avoid setting the timestamp built
 files.

The reference file may have a timezone-dependent timestamp.

https://reproducible-builds.org/docs/timezones/
---
 bin/updateversion.pl | 1 -
 1 file changed, 1 deletion(-)

diff --git a/bin/updateversion.pl b/bin/updateversion.pl
index 04b038d..29427b9 100755
--- a/bin/updateversion.pl
+++ b/bin/updateversion.pl
@@ -141,7 +141,6 @@ sub update_bin_tool($)
 	close(IN);
 	chmod(oct($date[2]), "$filename.new");
 	system("mv", "-f", "$filename.new", "$filename");
-	system("touch", "$filename", "-t", $date[1]);
 }
 
 sub update_txt_file($)
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1033953: unblock: gimp-help/2.10.34-1

[Jordi Mallach]

Hi again,

El dl. 01 de 05 de 2023 a les 20:40 +0200, en/na Jordi Mallach va
escriure:
> Attached is the debdiff of what I uploaded to experimental (new
> translations need to go through NEW, if this ends up being
> acceptable,
> I'll try to get ftp-master to review it asap).

ftp-master already processed this package and is now accepted to
experimental.

-- 
Jordi Mallach 
Debian Project

Bug#1035044: autorandr: recommend libinput-tools missing

[Frank Scherrer]

Hi

On Fri, Apr 28, 2023 at 04:33:50PM -0700, Don Armstrong wrote:
> We currently aren't distributing (or installing) autorandr-lid-listener
> in the Debian package.

My bad. You are right, I was not talking about the package included in
debian. Did not realize/remember that I had the package built myself
from some instructions on github.

Thanks for looking into it!


signature.asc
Description: PGP signature

Bug#1035393: unblock: rust-env-logger-0.7/0.7.1-4

[plugwash]

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

Please unblock package rust-env-logger-0.7

A bug was raised regarding missing breaks/replaces in rust-env-logger-0.7,
analysis revealed that debcargo was setting breaks+replaces against a virtual
package, the breaks against the virtual package are considered by dpkg but the
replaces are not leading to the potential for unpack failures during upgrade
from bullseye to bookworm.

This upload manually changes the breaks+replaces to point at the physical
package instead. How this should be handled automatically in debcargo is
under consideration, but a repack with the latest debcargo would probablly not
be appropriate at this point in the release cycle anyway.

unblock rust-env-logger-0.7/0.7.1-4

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

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru rust-env-logger-0.7-0.7.1/debian/changelog 
rust-env-logger-0.7-0.7.1/debian/changelog
--- rust-env-logger-0.7-0.7.1/debian/changelog  2021-10-23 19:30:54.0 
+
+++ rust-env-logger-0.7-0.7.1/debian/changelog  2023-05-02 07:01:45.0 
+
@@ -1,3 +1,11 @@
+rust-env-logger-0.7 (0.7.1-4) unstable; urgency=medium
+
+  * Team upload.
+  * Declare breaks+replaces against physical package, rather than virtual one
+(Closes: #1034949)
+
+ -- Peter Michael Green   Tue, 02 May 2023 07:01:45 +
+
 rust-env-logger-0.7 (0.7.1-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru rust-env-logger-0.7-0.7.1/debian/control 
rust-env-logger-0.7-0.7.1/debian/control
--- rust-env-logger-0.7-0.7.1/debian/control2021-10-23 19:30:54.0 
+
+++ rust-env-logger-0.7-0.7.1/debian/control2023-05-02 07:01:07.0 
+
@@ -39,8 +39,8 @@
  librust-env-logger-dev (= ${binary:Version}),
  librust-env-logger-0-dev (= ${binary:Version}),
  librust-env-logger-0.7.1-dev (= ${binary:Version})
-Replaces: librust-env-logger-0.7.1-dev
-Breaks: librust-env-logger-0.7.1-dev
+Replaces: librust-env-logger-dev (<< 0.7.2)
+Breaks: librust-env-logger-dev (<< 0.7.2)
 Description: Logging implementation for `log` which is configured via an 
environment variable - Rust source code
  This package contains the source for the Rust env_logger crate, packaged by
  debcargo for use with cargo and dh-cargo.

Bug#1035392: installation-reports: Installation Report: Bookworm RC2: Raspberry Pi 400 (netboot)

[James Addison]

Package: installation-reports
Severity: normal
Tags: d-i

Boot method: network
Image version: [2023-04-28] Bookworm Release Candidate 2 Installer
Date: 2023-05-02

Machine: Raspberry Pi 400
Partitions:

Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   1871816   0   1871816   0% /dev
tmpfs  tmpfs   386544 704385840   1% /run
/dev/mmcblk1p2 ext4  14689724 4192988   9728736  31% /
tmpfs  tmpfs  1932704   0   1932704   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
/dev/mmcblk1p1 vfat524008  119424404584  23% /boot/efi
tmpfs  tmpfs   386540  44386496   1% /run/user/1000


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

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

Comments:

Although the list of problems in this report might seem lengthy and
arcane, I enjoyed the installation process and think that with a few
small fixes, the rough edges can be removed.  I am writing this report
from an LXDE environment on the installed system.


This was largely an experiment to determine how feasible it is to bring
up a Raspberry Pi 400 over the network and to install Debian Bookworm
from there using the standard Debian Installer process.

The TFTP server was dnsmasq with a fairly minimal configuration based on
Debian's PXE-boot wiki page[1].  In addition to Debian Bookworm's
netboot.tar.gz[2] file (for RC2 at the time of download), the EDK2 UEFI
firmware[3] v1.34 was extracted to the /srv/tftp directory.

The only customized dnsmasq setting required was:

  pxe-service=0, "Raspberry Pi Boot"


Additional firmware for use during the install session was provided by
unpacking a firmware.tar.gz[3] file onto a FAT32-formatted USB drive.


Problems:

  * Firmware for the brcmfmac kernel module was not found on the USB
drive (but is present).  This may be related to #1029843

* Workaround: extracted the .deb contents on another system, placed
  them onto the USB drive, and then used one of the available virtual
  consoles (ctrl-alt-F1 or ctrl-alt-F2) on the install host to mount
  the USB drive and copy the firmware files to /lib/firmware/brcm
  before rmmod'ing and modprobe'ing the kernel module.

  * [minor] The hw-detect/load_firmware dialog box included an
extraneous newline within the displayed filename(s) for which
loading failed.
 
  * The microSD card intended as the installation disk did not appear
under /dev/mmc* when the install began.

* Workaround: rmmod'd and modprobe'd the sdhci* kernel modules;
  after doing that, the disk was detected and available under /dev

  * After completing the installation and rebooting, the first boot from
the install disk failed.  The Raspberry Pi's diagnostics console
showed a 'Firmware not found' message.

* Fix: this seemed to be due to a lack of Pi-compatible firmware on
  the ESP (EFI System Partition) of the install disk.  To resolve
  the problem, the same EDK2 UEFI firmware used on the dnsmasq
  ntboot server was unpacked into the ESP partition from another
  system (by removing the SD card from the Pi and placing it into
  the other machine).

  * After successfully reaching the EDK2 UEFI boot manager, the system
appeared to pause without reaching the expected next-stage GRUB
bootloader.

* Fix: this appears to be due to the default unpacked EDK2 UEFI
  bootmanager being unaware of the GRUB install on the same ESP
  partition.  That's understandable, because GRUB was installed
  before the EDK2 UEFI.

  The problem was solved by using the built-in boot menu management
  in the EDK2 UEFI to add an entry to boot into Debian.  In
  particular, this involved creating a file-boot entry that runs
  'shimaa64.efi'.

That concludes the installer-related issues; with those problems
worked-around / resolved, the system booted correctly.

There was one more problem that may not be installer-related:

  * The 'raspi-firmware' package failed to configure correctly during
'apt install', with an exit code 1 and asking whether the
/boot/firmware path had been mounted.


[1] - 
https://wiki.debian.org/PXEBootInstall?action=show=DebianInstaller%2FNetbootPXE#Another_Way_-_use_Dnsmasq

[2] - 
https://deb.debian.org/debian/dists/testing/main/installer-arm64/current/images/netboot/netboot.tar.gz

[2] - https://github.com/pftf/RPi4/releases/tag/v1.34

[3] - 
https://cdimage.debian.org/cdimage/firmware/bookworm/20230424/firmware.tar.gz


-- Package-specific 

Bug#1035390: mirror submission for mirrors.qontinuum.space

[Marco d'Itri]

On May 02, Qontinuum  wrote:

> Country: MC Monaco
> Location: Monaco
> Sponsor: Q Continuum https://qontinuum.space
> Comment: This site replaces debian.qontinuum.space that no longer exist
Can you clarify which data center is hosting this server and how much 
bandwidth is available to it?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1035391: dovecot-fts-xapian: stable version is very slow

[Alban Browaeys]

Package: dovecot-fts-xapian
Version: 1.4.9a-1+deb11u1
Severity: normal

Dear Maintainer,

The stable package version is very slow, likely due to missing fix
https://github.com/grosjo/fts-xapian/commit/6c1518ae8bf3cfc5993d1e653c53c5b9a206cb88
first introduced in 1.4.11.

See https://github.com/grosjo/fts-xapian/issues/89 "
grosjo commented on Jul 4, 2021

Yes, it seems the detection of the free memory was buggy, and the plugin
kept flushing on disk, which destroyed the performance
"

The stable backports 1.5.5-1~bpo11+1 version fixes this issue.

This bug report is there to point to a bug and tell the workaround
(install bullseye-backports version).
As this is not a security issue I doubt this commit would be added to
the bullseye version of the package.

stable version was indexing my 56G Maildir for more than a month with
1.4.9a-1+deb11u1 without even having half of it indexed.

Cheers,
Alban

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

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

Bug#1035390: mirror submission for mirrors.qontinuum.space

[Qontinuum]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.qontinuum.space
Type: leaf
Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc 
ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Qontinuum 
Country: MC Monaco
Location: Monaco
Sponsor: Q Continuum https://qontinuum.space
Comment: This site replaces debian.qontinuum.space that no longer exist




Trace Url: http://mirrors.qontinuum.space/debian/project/trace/
Trace Url: 
http://mirrors.qontinuum.space/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirrors.qontinuum.space/debian/project/trace/mirrors.qontinuum.space

Bug#1035389: ruby-aws-sdk-core: The VERSION file is not packaged

[vincent]

Package: ruby-aws-sdk-core
Version: 3.104.3-3+deb11u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Our build pipeline uses Debian Bullseye, which received a point release (11.7) 
including an update to your package.
This update now renders this package unusable.
After installing the package ("apt install ruby-aws-sdk-core"), when one tries 
to require aws-sdk-core or run the file directly on debian by running:
"ruby /usr/lib/ruby/vendor_ruby/aws-sdk-core.rb", you get the error:

Traceback (most recent call last):
2: from /usr/lib/ruby/vendor_ruby/aws-sdk-core.rb:93:in `'
1: from /usr/lib/ruby/vendor_ruby/aws-sdk-core.rb:95:in `'
/usr/lib/ruby/vendor_ruby/aws-sdk-core.rb:95:in `read': No such file or 
directory @ rb_sysopen - /usr/lib/ruby/VERSION (Errno::ENOENT)

This was most likely caused by dropping the fix-version.patch file, now the 
following line is executed and generates the aforementioned error:
"CORE_GEM_VERSION = File.read(File.expand_path('../../VERSION', 
__FILE__)).strip"

I expect the gem to not throw an error when requiring it.
This can be achieved by correctly packaging the VERSION file that exists in the 
repository.

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

Kernel: Linux 5.10.0-20-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)

Versions of packages ruby-aws-sdk-core depends on:
ii  ruby  1:2.7+2
ii  ruby-aws-eventstream  1.1.0-1
ii  ruby-aws-partitions   1.354.0-2
ii  ruby-aws-sigv41.1.0-3
ii  ruby-jmespath 1.4.0-2

ruby-aws-sdk-core recommends no packages.

ruby-aws-sdk-core suggests no packages.

-- no debconf information

Bug#974703: Still a problem...

[Evan Goers]

On my Panasonic Toughbook CF-M34, with a SiliconMotion LynxEM(SM710) video
chip, this is still a problem on Debian 11. I get the same issue "Not
enough video memory for the configured screen size (800x600) and color
depth."

It seems no amount of xorg.conf experimentation will make this error go
away. Even setting the VideoRam manually doesn't help. 800x600x16 should
fit within 4MB(it works just fine in Windows 98SE).

Bug#1035388: coreutils: pr: form feed behaves erratically, deviates from SVr4

[наб]

Package: coreutils
Version: 8.32-4+b1
Version: 9.1-1
Severity: normal

Dear Maintainer,

As an extension, coreutils supports having the form feed character
act as "end of page in input file", and, like many pr extensions,
this is for compatibility with SysVr4.

Under SysVr4, FF in an input line splits it in twain:
the bit before the FF is a line on the current page,
the bit after  the FF is a line on the next page.
This is obvious and expected behaviour.

Indeed, they agree (sans #1034858):
-- >8 --
% { seq 56; printf 'a\fb\n'; } | pr | cat -sA
$
2023-05-02 17:46  Page 1$
$
1$
2$
3$
4$
5$
6$
7$
8$
9$
10$
11$
12$
13$
14$
15$
16$
17$
18$
19$
20$
21$
22$
23$
24$
25$
26$
27$
28$
29$
30$
31$
32$
33$
34$
35$
36$
37$
38$
39$
40$
41$
42$
43$
44$
45$
46$
47$
48$
49$
50$
51$
52$
53$
54$
55$
56$
$
2023-05-02 17:46  Page 2$
$
a$
$
2023-05-02 17:46  Page 3$
$
b$
$

% { seq 55; printf 'a\fb\n'; } | pr | cat -sA
$
2023-05-02 17:52  Page 1$
$
1$
2$
3$
4$
5$
6$
7$
8$
9$
10$
11$
12$
13$
14$
15$
16$
17$
18$
19$
20$
21$
22$
23$
24$
25$
26$
27$
28$
29$
30$
31$
32$
33$
34$
35$
36$
37$
38$
39$
40$
41$
42$
43$
44$
45$
46$
47$
48$
49$
50$
51$
52$
53$
54$
55$
a$
$
2023-05-02 17:52  Page 2$
$
b$
$
-- >8 --

But not always. Here, coreutils pr eats the first line:
-- >8 --
% { seq 56; printf '\fb\n'; } | pr | cat -sA | tail
52$
53$
54$
55$
56$
$
2023-05-02 17:53  Page 2$
$
b$
$
% { seq 56; printf '\fb\n'; } | ./a.out | cat -sA | tail
54$
55$
56$
$
May  2 17:53 2023   Page 2$
$
May  2 17:53 2023   Page 3$
$
b$
$
-- >8 --

And here the second:
-- >8 --
% { seq 56; printf 'a\f\n'; } | pr | cat -sA | tail
52$
53$
54$
55$
56$
$
2023-05-02 17:54  Page 2$
$
a$
$
% { seq 56; printf 'a\f\n'; } | ./a.out | cat -sA | tail
54$
55$
56$
$
May  2 17:54 2023   Page 2$
$
a$
$
May  2 17:54 2023   Page 3$
$

% { seq 55; printf 'a\f\n'; } | pr | cat -sA | tail
48$
49$
50$
51$
52$
53$
54$
55$
a$
$
% { seq 55; printf 'a\f\n'; } | ./a.out | cat -sA | tail
50$
51$
52$
53$
54$
55$
a$
$
May  2 17:55 2023   Page 2$
$
-- >8 --

And here both:
-- >8 --
% { seq 56; printf '\f\n'; } | pr | cat -sA | tail
48$
49$
50$
51$
52$
53$
54$
55$
56$
$
% { seq 56; printf '\f\n'; } | ./a.out | cat -sA | tail
52$
53$
54$
55$
56$
$
May  2 17:55 2023   Page 2$
$
May  2 17:55 2023   Page 3$
$

% { seq 55; printf '\f\n'; } | pr | cat -sA | tail
47$
48$
49$
50$
51$
52$
53$
54$
55$
$
% { seq 55; printf '\f\n'; } | ./a.out | cat -sA | tail
49$
50$
51$
52$
53$
54$
55$
$
May  2 17:56 2023   Page 2$
$
-- >8 --

It's unclear to me why you'd want this, especially with a trivial-to-use
well-defined interface to copy.

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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b5

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1035387: csound: Regression from Bullseye: K opcodes not initialized at init time

[Sam Hartman]

Package: csound
Version: 1:6.18.1+dfsg-1
Tags: fixed-upstream, upstream

See https://github.com/csound/csound/issues/1707

I'd like to NMU a fix once things settle down on the upstream side and
I'd like to file an unblock request (or a stable update request if
this misses the bookworm release).

I'm not a member of the multimedia team, but I am familiar with the csound 
packaging.
Are you okay with me doing an NMU and  submitting a merge request on salsa once 
we settle on a fix on the upstream github issue?

You can declare an opcode something like

opcode inittest,K,0

According o the docs, the output parameter is copied both at k-time
and at i-time.  It turns out in csound 6.14 (bullseye) it's always
copied at i-time even if declared as 'k' not 'K'.  But that in 6.18
it's only copied as k-time.  If you are using the opcode as a state
machine, triggering reinits, etc, that can totally break your
orchestra.

Bug#1035386: gnome-package-updater: does not find package upgrades, until after running 'apt update'

[Amr Ibrahim]

Package: gnome-package-updater
Version: 43.0-1
Severity: normal

Dear Maintainer,

gnome-package-updater cannot find package upgrades, until after running 'apt
update'.

Steps:
0. Make sure that there are packages to upgrade without running 'apt update'
because that breaks the steps
1. Run gnome-package-updater
2. It does not find any package upgrades
3. Close gnome-package-updater
4. Run in a terminal 'sudo apt update'
5. apt will show the number of packages to upgrade
6. Run gnome-package-updater
7. It will show the package upgrades

What should happen:
gnome-package-updater finds package upgrades, when they are available, without
having to run 'apt update'.

Best,
Amr


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

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

Versions of packages gnome-package-updater depends on:
ii  gnome-packagekit-common  43.0-1
ii  libc62.36-9
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libpackagekit-glib2-18   1.2.6-3
ii  libpolkit-gobject-1-0122-3
ii  packagekit   1.2.6-3

Versions of packages gnome-package-updater recommends:
pn  software-properties-gtk  

gnome-package-updater suggests no packages.

-- no debconf information

Bug#1034568: binascii.Error: Odd-length string when asking the status

[Jamie Strandboge]

On Tue, 02 May 2023, Marek Küthe wrote:

> Hello,
> 
> thank you for the answer.
> 
> I must admit that I was a bit hasty in reporting this error. This error
> occurred when I tried to automate my ufw firewall rules with ansible.
> In doing so, I had unfortunately run several scripts which inserted
> rules - maybe this is the reason? In the meantime I don't have the
> problem anymore and unfortunately I don't know the problematic rule.
> But I also noticed that the same error occurred when I inserted
> firewall rules and watched ufw status "watch -n 0.5 'ufw status
> numbered | wc -l'".

Ok, no worries. I'm glad you aren't seeing the issue anymore. I plan to
upload the mitigation fix to bookworm which will close out this issue.
If you happen to come across this error again, perhaps consider
responding with the additional info.

Thanks again for the report.

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#1019387: News and questions

[Sébastien Le Roux]

Dear Debian  community,
I last updated this bug on October 17th, after that I underwent wrist 
surgery

and I was away for quite a long time.
Since then I worked on the Debian package for atomes, I invite you to 
check this

on the link above.

Also atomes is now officially packaged by Fedora and I hope this proves 
that I really

am involved in the process of packaging and maintaining my software.
However I also learned from this first experience that I would need help 
and

guidance to do things properly with Debian as I did with Fedora.

Above in the bug messages I was offered to contact packaging teams I 
missed at first,
In particular Debichem, and I did at the time but did not get any 
answers from this list.

I would really appreciate to have a feedback from the Debian community.

Best regards.

Sébastien Le Roux

--
===
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail: sebastien.ler...@ipcms.unistra.fr
Webpage: https://www.ipcms.fr/sebastien-le-roux/
ATOMES project: https://atomes.ipcms.fr/
RINGS project: http://rings-code.sourceforge.net/
ISAACS project: http://isaacs.sourceforge.net/
Fax:   +33 3 88 10 72 46
Phone: +33 3 88 10 71 58
===

Bug#1035385: grub-pc: /etc/default/grub GRUB_DISABLE_RECOVERY should be without quotes for consistency

[Martin-Éric Racine]

Package: grub-pc
Version: 2.06-12
Severity: minor

In /etc/default/grub, all default values are unquoted, except for 
GRUB_DISABLE_RECOVERY. The quotes should be removed for consistency with the 
other defaults.

Martin-Éric

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

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

Versions of packages grub-pc depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  grub-common2.06-12
ii  grub-pc-bin2.06-12
ii  grub2-common   2.06-12
ii  ucf3.0043+nmu1

grub-pc recommends no packages.

grub-pc suggests no packages.

-- debconf information excluded

Bug#1034000: Experiencing the same issue

[Melvin Vermeeren]

Hi,

Experiencing the same issue since about a week. For example yesterday's job
(May first) reported a very high number of 503 Backend fetch failed.

http://snapshot.debian.org/archive/debian/20230430T000334Z/pool/main/b/base-passwd/base-passwd_3.5.46_amd64.deb:
2023-05-01 00:14:38 ERROR 503: Backend fetch failed.
http://snapshot.debian.org/archive/debian/20230430T000334Z/pool/main/b/bash/bash_5.0-4_amd64.deb:
2023-05-01 00:15:38 ERROR 503: Backend fetch failed.
http://snapshot.debian.org/archive/debian/20230430T000334Z/pool/main/b/bzip2/libbz2-1.0_1.0.6-9.2~deb10u1_amd64.deb:
2023-05-01 00:16:38 ERROR 503: Backend fetch failed.
...

Appears very random, sometimes only a few packages return 503, sometimes lot.
If luck is high I might get none at all and get an image built successfully.

Anyone knows some details about this issue?

Thanks,

-- 
Melvin Vermeeren
Systems engineer

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

Bug#1034568: binascii.Error: Odd-length string when asking the status

[Jamie Strandboge]

On Mon, 01 May 2023, Jamie Strandboge wrote:

> Thank you for the report. If you update hex_decode() in
> /usr/lib/python3/dist-packages/ufw/util.py to use this:
> 
> return binascii.unhexlify('%2s' % h).decode("utf-8")
> 
> instead of:
> 
> return binascii.unhexlify(h).decode("utf-8")
> 
> Does it resolve the issue for you?

Don't worry about the above, I have a better mitigation to avoid tracing
back:
https://git.launchpad.net/ufw/commit/?id=a14ab9777cde6308724164f5c42d368d2a823b3a

This will be in the next upload and will allow 'ufw status' to still
work in the face of an odd length hex string which will mitigate the
issue, but not address the underlying cause.

I'd like to better understand how you ended up with an odd length string
in the first place. You gave a reproducer, but can we simplify it a bit?
Can you:

1. backup your firewall with:
  $ sudo ufw disable
  $ sudo /lib/ufw/ufw-init flush-all
  $ sudo cp -a /etc/ufw /etc/ufw.backup
2. reproduce the issue with:
  $ sudo ufw reset(resets to installation defaults)
  $ sudo ufw enable
  $ sudo ufw route ...(I need a single rule that causes the issue)
  $ sudo ufw status   (demonstrates the problem)
  $ sudo cat /etc/ufw/user.rules  (I need this with the problematic rule)
  $ env|grep LC_  (I need this to see if related)
3. restore from backup with:
  $ sudo ufw disable
  $ sudo /lib/ufw/ufw-init flush-all
  $ sudo mv /etc/ufw /etc/ufw.1034568
  $ sudo cp -a /etc/ufw.backup /etc/ufw
  $ sudo ufw enable

When responding, please include the problematic ufw rule,
/etc/ufw/user.rules and the output of 'env|grep LC_'.

Thanks!

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#1034568: binascii.Error: Odd-length string when asking the status

[Jamie Strandboge]

On Tue, 02 May 2023, Jamie Strandboge wrote:

> Don't worry about the above, I have a better mitigation to avoid tracing
> back:
> https://git.launchpad.net/ufw/commit/?id=a14ab9777cde6308724164f5c42d368d2a823b3a

Sorry, this is the correct commit:
https://git.launchpad.net/ufw/commit/?id=aa26a79dd34ff2c727d7a00132bcaa365da8cd9f

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#1035384: openscap-daemon: hardcoded dependency on no longer available libopenscap8

[Andreas Beckmann]

Package: openscap-daemon
Version: 0.1.10-3.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   openscap-daemon : Depends: libopenscap8 but it is not installable


libopenscap8 is long gone, but even rebuilding openscap-daemon does not pick
up a dependency on a newer version, threrfore that seems to be hardcoded
somewhere.


Cheers,

Andreas

Bug#993314: User-level systemd unit for autorandr

[Antoine Beaupré]

On 2023-04-28 16:31:50, Don Armstrong wrote:
> Control: tag -1 moreinfo
>
>
> You should be able to enable the system-wide unit for a user by using
> something like the following:
>
>systemctl --user enable /lib/systemd/system/autorandr.service
>
> That said, the system-wide one is supposed to work.
>
> Can you give some details on why autorandr --batch might not be working
> for your setup? [It works for mine, though I am using xdm with .xsession
> instead of startx or whatever you're doing.]
Hi!

Sorry, I switched to sway/wayland and don't have much more information
to provide than what I already reported...

a.

-- 
Time is a created thing. To say, "I don't have time" is like saying,
"I don't want to."
- Lao Tzu

Bug#1035383: unblock (pre-approval): brial/1.2.11-2.1

[plugwash]

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

It was discovered about a month ago by Bastian Germann that python3-brial needs
python3-sage, and he added a dependency.

Unfortunately this left the package uninstallable on about half of release
architectures. Normally this would block migration to testing, but elbrus
forced the package in.

I filed a bug 1034443 with grave severity for this based on the following
understanding.

* An uninstallable package is unusable
* The "is this package unusable" criteria is applied to each binary package
  individually and for packages that are built seperately for multiple
  architectures is applied on each arhictecture individually. Or to put it
  another way my understanding the criteria is applied to each "deb"
  individually.

I don't think these are explicitly stated anywhere, but they are consistent
with my experiance of how things are typically done in Debian. They are
consistent with the state of testing (other than python3-brial there are no
uninstallable arch-specific binary packages in testing) and they are consistent
with the rules britney normally enforces for testing migration.

Elbrus replied to my bug report, challangeing why I had filed it as rc, I
explained my position and he seemed somewhat but not totally convinced.

I would like to ask for a release team ruling on this bug. If the release agree
it is rc and should be fixed, I am happy to make an upload doing so. On the
other hand if the release team decide that it is not rc and should not be fixed
at this stage in the release process I'm happy to abide by that descision.

The debdiff for my proposed upload can be found at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1034443;filename=brial.debdiff;msg=40

unblock brial/1.2.11-2.1

Bug#1035382: Bookworm amd64 live install ISO RC1 and RC2 install pointless raspi-firmware package

[Paul Seelig]

Package: debian-live
Severity: normal
Tags: d-i
X-Debbugs-Cc: think...@rumbero.org

Installation of Bookworm RC1+2 using amd64 live install ISO[1] includes package 
'raspi-firmware', which in this context is a useless waste of space. It's 
presence results in the creation of a /boot/firmware/ directory of more than 
100MB and which serves no purpose for a amd64 system. Manually purging the 
package leaves the pointless /boot/firmware/ directory in place.

For debugging purposes, please refer to the installer logs available via [2].

Please ensure the 'raspi-firmware' package is only included with live ISO 
variants where it actually makes sense.

Thanks,
P.Seelig

[1] 
https://cdimage.debian.org/cdimage/bookworm_di_rc2-live/amd64/iso-hybrid/debian-live-bkworm-DI-rc2-amd64-xfce.iso

[2] 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1035360;filename=installer-logs.tar.xz;msg=10

Bug#1035381: virt-manager: does not autodetect OS of Debian Installer RC ISOs

[Emanuele Rocca]

Package: virt-manager
Version: 1:4.1.0-2
X-Debbugs-CC: debian-b...@lists.debian.org

Hi,

Step 2 of the "Create a new virtual machine" wizard fails to
automatically detect the operating system when using an RC version of
d-i such as [0]. See attached screenshot.

Stable images like [1] are correctly identified as "Debian 11".

Given that "debiantesting" is in the list of known operating systems, it
would be great if d-i RC ISOs could be identified as such.

Thanks,
  ema

[0] 
https://cdimage.debian.org/cdimage/bookworm_di_rc2/amd64/iso-cd/debian-bookworm-DI-rc2-amd64-netinst.iso
[1] 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.7.0-amd64-netinst.iso

Bug#1035380: prusa-slicer: segfaults at start if window is too small

[Félix Sipma]

Package: prusa-slicer
Version: 2.5.2+dfsg-1
Severity: normal

I use a tiling window manager (sway). If I start prusa-slicer and the 
resulting window is too small, the program segfaults:

$ prusa-slicer
[2023-05-02 15:49:42.874172] [0x7f8b39d49d80] [trace]   
Initializing StaticPrintConfigs
15:49:45: Debug: window wxTreeCtrl@0x558be9c7d190 ("treeCtrl") lost 
focus even though it didn't have it
15:49:45: Debug: window wxTreeCtrl@0x558be9c7d190 ("treeCtrl") lost 
focus even though it didn't have it
Segmentation fault (core dumped)


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

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

Versions of packages prusa-slicer depends on:
ii  fonts-noto-hinted  20201225-1
ii  libboost-chrono1.74.0  1.74.0+ds1-20
ii  libboost-filesystem1.74.0  1.74.0+ds1-20
ii  libboost-iostreams1.74.0   1.74.0+ds1-20
ii  libboost-locale1.74.0  1.74.0+ds1-20
ii  libboost-log1.74.0 1.74.0+ds1-20
ii  libboost-regex1.74.0 [libboost-regex1.74.0-icu72]  1.74.0+ds1-20
ii  libboost-thread1.74.0  1.74.0+ds1-20
ii  libc6  2.36-9
ii  libcurl3-gnutls7.88.1-9
ii  libdbus-1-31.14.6-1
ii  libexpat1  2.5.0-1
ii  libgcc-s1  12.2.0-14
ii  libgl1 1.6.0-1
ii  libglew2.2 2.2.0-4+b1
ii  libglib2.0-0   2.74.6-2
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libgtk-3-0 3.24.37-2
ii  libimath-3-1-293.1.6-1
ii  libjpeg62-turbo1:2.1.5-2
ii  libmpfr6   4.2.0-1
ii  libnlopt0  2.7.1-4+b4
ii  libocct-data-exchange-7.6  7.6.3+dfsg1-5
ii  libocct-foundation-7.6 7.6.3+dfsg1-5
ii  libocct-modeling-algorithms-7.67.6.3+dfsg1-5
ii  libocct-modeling-data-7.6  7.6.3+dfsg1-5
ii  libocct-ocaf-7.6   7.6.3+dfsg1-5
ii  libopenvdb10.0 10.0.1-1+b1
ii  libpng16-161.6.39-2
ii  libstdc++6 12.2.0-14
ii  libtbb12   2021.8.0-1
ii  libwxbase3.2-1 3.2.2+dfsg-2
ii  libwxgtk-gl3.2-1   3.2.2+dfsg-2
ii  libwxgtk3.2-1  3.2.2+dfsg-2

prusa-slicer recommends no packages.

prusa-slicer suggests no packages.

-- no debconf information

-- 
Félix


signature.asc
Description: PGP signature

Bug#1035379: lios: Lios cannot find installed tesseract language files

[Lukas Svoboda]

Package: lios
Version: 2.7.2-5
Severity: normal
X-Debbugs-Cc: svobod...@gmail.com

Dear Maintainer,

lios 2.7.2-5 (bookworm) reports "Dictionary not found!" during start even
though packages tesseract-ocr-[eng,deu,ces,...] and spellcheck dictionaries
(aspell-*, hunspell-*) are installed. Lios mistakenly expects tesseract
language packs to be installed in /usr/share/tesseract-ocr/tessdata, but in
fact they are located in /usr/share/tesseract-ocr/5/tessdata. As a result of
this bug user cannot choose specific language in Recognition Preferences menu.
As a workaround user can create a softlink /usr/share/tesseract-ocr/tessdata ->
/usr/share/tesseract-ocr/5/tessdata. After creating this softlink, lios detects
installed language packs as expected.

This issue was reported upstream a few years ago, see
https://github.com/zendalona/lios/issues/6.

Best regards,
Lukáš Svoboda


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

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

Versions of packages lios depends on:
ii  aspell-en2020.12.07-0-1
ii  espeak   1.48.15+dfsg-3
ii  gir1.2-gst-plugins-base-1.0  1.22.0-3
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.37-2
ii  gir1.2-vte-2.91  0.70.3-1
ii  imagemagick  8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.6
ii  poppler-utils22.12.0-2+b1
ii  python3  3.11.2-1+b1
ii  python3-enchant  3.2.2-1
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1
ii  python3-sane 2.9.1-2+b4
ii  python3-speechd  0.11.4-2
ii  tesseract-ocr5.3.0-2

Versions of packages lios recommends:
ii  gnome-icon-theme  3.12.0-5

Versions of packages lios suggests:
ii  cuneiform  1.1.0+dfsg-9

-- no debconf information

Bug#1034409: Boot from removable media path fails after changing secure boot validation because MOK Manager is not found

[Steve McIntyre]

Control: severity -1 serious

Raising the severity here, seen another report of this.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall

Bug#1031719: libpipewire-0.3-modules: pipewire module zeroconf discover filters out sources

[Alban Browaeys]

Likely an upstream issue.

I see the headset mic has an IPv6 address:
   address = [2a01:e0a:8db:8861:dead:beef:0:f0f8]
while advertised as IPv4.

pipewire now filter IPv6 zeroconf advertisment in its zeroconf-discover
module to avoid showing duplicate entries (one for IPv4 the other for
IPv6) in the client UI this might be related.
The fact that no IPv4 service is advertised (well it is but with an
IPv6 address) might explain why the pipewire zeroconf discover module
hide your headless mic.
You could try older pipewire debs (snapshot.debian.org) as this IPv6
hide was introduced recently or simply open a bug in the upstream bug
tracker. This was introduced due to
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2031

The change was made on the publishing side ie the server is the one
were you should downgrade pipewire. The version that introduced this
behaviour is 0.6.32 so downgtrading to 0.6.31 will do. see
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2861

The fact that an IPv6 address is published in an IPv4 entry might be
another upstream pipewire bug namely inhte zeroconf-publish module.
Though before reporting to upstream you should try at least pipewire
0.3.70 from debian experimental (and maybe even upstream code).

Mind that for me 0.3.70 module-zeroconf-discover module might crash on
startup but this is another issue that I am investigating. Might not
crash for you (the crash depends on the server box adverstising which
will be different for your setup). upstream git code is also affected.
This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035280 not
yet reported upstream (as I have a hard time to reproduce properly with
my git master build).


Cheers,
Alban


On Tue, 21 Feb 2023 14:45:03 +0100 Landry MINOZA
 wrote:
> Package: libpipewire-0.3-modules
> Version: 0.3.65-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Trying to use remote devices with pipewire, I don't see some devices
> (specificaly a headset mic in my case).
> Reproduce on 2 sid clients.
> 
> I load zeroconf module:
> 
> pactl load-module module-zeroconf-discover
> 
> When listing available devices:
> Audio
>  ├─ Devices:
>  │  42. Audio interne   [alsa]
>  │
>  ├─ Sinks:
>  │  *   45. Audio interne Stéréo analogique   [vol: 0.40]
>  │  62. Starship/Matisse HD Audio Controller Stéréo analogique on
landry@demetra [vol: 1.00]
>  │  64. [G533 Wireless Headset Dongle]  [vol: 1.00]
>  │
>  ├─ Sink endpoints:
>  │
>  ├─ Sources:
>  │  *   46. Audio interne Stéréo analogique   [vol: 1.00 MUTED]
>  │  60. Starship/Matisse HD Audio Controller Stéréo analogique on
landry@demetra [vol: 1.00]
>  │
>  ├─ Source endpoints:
>  │
>  └─ Streams:
> 
> The headset mic (source [G333 Wireless Headset Dongle] is exposed by
> avahi:
> 
> ❯ avahi-browse --resolve _pulse-source._tcp -t
> +  wlan0 IPv4 landry@demetra: [G533 Wireless Headset Dongle] Mono
PulseAudio Sound Source local
> +  wlan0 IPv4 landry@demetra: Starship/Matisse HD Audio Controller
St__r__o a PulseAudio Sound Source local
> =  wlan0 IPv4 landry@demetra: [G533 Wireless Headset Dongle] Mono
PulseAudio Sound Source local
>    hostname = [demetra.local]
>    address = [2a01:e0a:8db:8861:dead:beef:0:f0f8]
>    port = [4713]
>    txt = ["description=[G533 Wireless Headset Dongle] Mono"
"subtype=hardware" "channel_map=mono" "format=s16le" "channels=1"
"rate=48000" "device=alsa_input.usb-Logitech_G533_Gaming_Headset-
00.mono-fallback" "cookie=0x4a6f9a3a" "fqdn=demetra" "uname=Linux
x86_64 6.1.0-5-amd64" "user-name=landry" "server-version=PipeWire
0.3.65"]
> =  wlan0 IPv4 landry@demetra: Starship/Matisse HD Audio Controller
St__r__o a PulseAudio Sound Source local
>    hostname = [demetra.local]
>    address = [10.0.0.144]
>    port = [4713]
>    txt = ["description=Starship/Matisse HD Audio Controller
St\195\169r\195\169o analogique" "subtype=hardware" "channel_map=front-
left,front-right" "format=s32le" "channels=2" "rate=48000"
"device=alsa_input.pci-_0a_00.4.analog-stereo" "cookie=0x4a6f9a3a"
"fqdn=demetra" "uname=Linux x86_64 6.1.0-5-amd64" "user-name=landry"
"server-version=PipeWire 0.3.65"]
> 
> On the remote host, this source is visible and usable:
> Audio
>  ├─ Devices:
>  │  44. GM204 High Definition Audio Controller [alsa]
>  │  46. [G533 Wireless Headset Dongle]  [alsa]
>  │  47. Starship/Matisse HD Audio Controller [alsa]
>  │ 122. Fairphone 4 5G  [bluez5]
>  │
>  ├─ Sinks:

Bug#1034443: python3-brial: uninstallable on arcitectures where sagemath is unavailable

[plugwash]

Hell All, I have just made singular independent from brial

Thanks for dealing with that part of the issue.

Otherwise it must be keep in mind that Sage is mostly umbrella software.
That means that the dependency of brian on sage material is odd.

odd as it may be, it seems the dependency of python3-brial
on sagemath is real.

I've prepared a NMU, and intend to open a pre-approval
request with the release team. If you have any objections
to the NMU please tell me ASAP (I do not intend to upload
it until I receive a response from the release team, if you
would preffer to make the upload yourself that is fine too).
diff -Nru brial-1.2.11/debian/changelog brial-1.2.11/debian/changelog
--- brial-1.2.11/debian/changelog   2023-04-03 12:13:10.0 +
+++ brial-1.2.11/debian/changelog   2023-05-02 10:39:34.0 +
@@ -1,3 +1,11 @@
+brial (1.2.11-2.1) bookworm-staging; urgency=medium
+
+  * Non-Maintainer upload.
+  * Limit architectures for python3-brial package  to architectures where
+sagemath is available (Closes: #1034443).
+
+ -- Peter Michael Green   Tue, 02 May 2023 10:39:34 
+
+
 brial (1.2.11-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru brial-1.2.11/debian/control brial-1.2.11/debian/control
--- brial-1.2.11/debian/control 2023-04-03 12:11:20.0 +
+++ brial-1.2.11/debian/control 2023-04-08 15:18:38.0 +
@@ -22,7 +22,7 @@
 Homepage: https://github.com/BRiAl
 
 Package: python3-brial
-Architecture: any
+Architecture: amd64 arm64 i386 riscv64
 Section: python
 Depends: python3-sage,
  ${misc:Depends},

Bug#1035096: installation-report Bookworm RC2 GRUB not installed

[Peter Ehlert]

On 4/30/23 01:17, Pascal Hambourg wrote:

On 30/04/2023 at 01:47, Peter Ehlert wrote:


On 4/29/23 15:41, Pascal Hambourg wrote:

On 29/04/2023 at 16:02, Peter Ehlert wrote:


reboot gave me the Old GRUB menu, not including my new system.


What do you mean by "old GRUB menu" ? The GRUB which was previously 
installed on /dev/sdb ? 


the GRUB that was on the only disk with a bios_grub flagged partition.


Thank you for the clarification. If I understand correctly,
- the machine usually boots with some GRUB on disk X,
- you installed a new Debian system with GRUB on disk Y,
- then the machine rebooted on disk X as usual.



Correct:

to reiterate the problem...
DI asks on which drive to install GRUB
User says disk X
DI attempts to install on Drive Y
result ... GRUB does not get installed at all



The Debian installer will not add the newly installed system to 
another existing OS GRUB menu; it will only add other existing OS's to 
the new installed system GRUB menu, which will be displayed only if 
the machine boots from the disk containing the new GRUB. So what you 
describe is normal behaviour.



"normal"?
except I am not asking for the existing GRUB menu on drive X to be 
appended.


the request is Install GRUB on drive X

If you want to add the newly installed system to another OS GRUB menu, 
you need to run update-grub from that other OS. If you want to boot 
with the new installed GRUB, you need to set up the BIOS to boot from 
the disk which contains it.


setting up BIOS to boot from a drive that does not have a bios_grub 
flagged partition results in:


"GPT-formatted disk.

Legacy boot not supported. Press any key to reboot."

Bug#1034969: [Pkg-javascript-devel] Bug#1034969: Fwd: Bug#1034969: terser: missing Breaks+Replaces for uglifyjs.terser when upgrading from bullseye

[Jonas Smedegaard]

Quoting Yadd (2023-05-02 08:58:06)
> For the record, unblock issue is #1035368

Looks excellent - thanks for your work on this, Yadd!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

[Andreas Beckmann]

On 02/05/2023 11.37, Ian Jackson wrote:

Andreas Beckmann writes ("Bug#1035361: sauce: Potentially dangerous mode on 
/etc/logrotate.d/sauce: 0755"):

Package: sauce
Version: 0.9.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

...

during a test with piuparts I noticed your package's logrotate
configuration causes logrotate to exit with an error after the package
has been removed (*) or when logrote is run but no logfile exists.


Thanks for the report.  I will fix this ASAP.


Usually the solution is to specify 'missingok' in the logrotate
configuration.


I will do some tests but that sounds like a possible approach.


That doesn't look like a solution in this case.


Setting severity to serious since this does not seem limited to being
emitted after package removal but always. The current logrotate version
in sid seems to be more strict.


I looked through the changelog and didn't find anything about missing
logfiles since at least 2015.  Are you sure ?


>From the attached log (scroll to the bottom...):

0m17.0s DEBUG: Starting command: ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp6h9n6ntx', '/usr/sbin/logrotate', 
'/etc/logrotate.d/sauce']
0m17.0s DUMP:
   warning: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755
0m17.0s DEBUG: Command ok: ['chroot', 
'/srv/piuparts.debian.org/tmp/tmp6h9n6ntx', '/usr/sbin/logrotate', 
'/etc/logrotate.d/sauce']
0m17.0s ERROR: FAIL: Logrotate file /etc/logrotate.d/sauce exits with error or 
has output with package removed


I have one question.  The message here is complaining about the file
permission.  I think that mode is probably wrong, but I don't think it
is *dangerous*.

I don't think I ought to change the mode for bookworm.


That code is from logrotate

https://sources.debian.org/src/logrotate/3.21.0-1/config.c/?hl=1057#L1057

but it was already present at least in bullseye (didn't check earlier 
releases).


Tryinit it manually by installing logrotate and sauce in a chroot 
(without removing sauce again):


bullseye# ls -la /etc/logrotate.d/sauce
-rwxr-xr-x 1 root root 506 Jan 27  2021 /etc/logrotate.d/sauce
bullseye# logrotate /etc/logrotate.d/sauce
bullseye# echo $?
0

installing sauce in bookworm is very noisy:

Setting up sauce (0.9.1) ...
Checking for SAUCE databases in /var/lib/sauce ...
 cdb.site-annoy (no existing data)  donechown: warning: '.' should be 
':': 'mail.mail'

chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
.
 cdb.site-seen (no existing data)  donechown: warning: '.' should be 
':': 'mail.mail'

chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
.
 cdb.site-list (no existing data)  donechown: warning: '.' should be 
':': 'mail.mail'

chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
.
 cdb.addr-seen (no existing data)  donechown: warning: '.' should be 
':': 'mail.mail'

chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
.
 cdb.addr-list (no existing data)  donechown: warning: '.' should be 
':': 'mail.mail'

chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
chown: warning: '.' should be ':': 'mail.mail'
.


bookworm# ls -la /etc/logrotate.d/sauce
-rwxr-xr-x 1 root root 506 Jan 27  2021 /etc/logrotate.d/sauce
bookworm# logrotate /etc/logrotate.d/sauce
warning: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755
bookworm# echo $?
0

If I understand it correctly, logrotate complains about the executable 
permission. (0644 and 0600 should be both ok)
And it will do that every time logrotate runs while the package is 
installed, producing some cron email or other notification.


IMO both bugs (logrotate permission and ancient chown syntax) warrant an 
update of the package to be included in bookworm.


Andreas

Bug#1021601: vlc: VAAPI hardware acceleration no more available

[Fabien Motta]

On Sun, 05 Mar 2023 15:31:01 + bob_smith_1337 
 wrote:
> This is also the case for me with VLC 3.0.18-2 (current debian 
bookworm version)

> Is there any workaround ?

> Thanks a lot

I recovered VAAPI acceleration by downloading ffmpeg 4.4 on the ffmpeg 
website, and then compiling and installing it in /usr/local. Then I 
compiled VLC and it worked.


Loss of VAAPI hw acceleration with ffmpeg 5.x has been reported to VLC 
devs, and it will _not_ be corrected in the 3.x branch.


Cf. https://code.videolan.org/videolan/vlc/-/issues/26772

Have a good day.

FM

Bug#1035014: installation-reports: Graphical installer has Xorg "no screens found" error

[Timo Aaltonen]

Cyril Brulebois kirjoitti 1.5.2023 klo 18.50:

Control: reassign -1 xserver-xorg-core-udeb 2:21.1.1-1
Control: affects -1 debian-installer

Hello debian-x,

Cyril Brulebois  (2023-04-27):

Tracked down to 9c81b8f5b5 upstream:
   https://cgit.freedesktop.org/xorg/xserver/commit/?id=9c81b8f5b5

Flipping the switch and wrapping it up in a netboot mini.iso
debian-installer build led to a successful test (with amd64) by Keith.
We'll try and confirm the same happens with arm64.

If you're happy with that approach, feel free to reassign to the udeb,
and check the udeb-modesetting branch in xorg-server:
   
https://salsa.debian.org/xorg-team/xserver/xorg-server/-/commits/udeb-modesetting


Any objections to my merging/uploading this?


Hi, fine by me!

--
t

Bug#1035068: linux-image-6.1.0-7-amd64: occasionally no trackpad/trackpoint on resume from hibernate

[Rusty Grove]

Package: src:linux
Version: 6.1.25-1
Followup-For: Bug #1035068
X-Debbugs-Cc: rgr...@rsu20.org

Dear Maintainer,
I have a couple of L13s I'm testing on. This one has the kernel from unstable.
On resume from suspend (didn't reach hibernate), I have no trackpad/trackpoint
this morning (systemd script still enabled). This report was done with neither
trackpad/trackpoint working. I'll ditch the systemd script on both laptops and
see how it goes.
Thanks


-- Package-specific info:
** Version:
Linux version 6.1.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.25-1 (2023-04-22)

** Command line:
root=LABEL=root rw quiet splash loglevel=1 rootfstype=btrfs add_efi_memmap 
workqueue.power_efficient=true initrd=\EFI\Debian\initrd.img

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[63563.260556] PM: suspend entry (s2idle)
[63563.277311] Filesystems sync: 0.016 seconds
[63563.278079] Freezing user space processes
[63563.279850] Freezing user space processes completed (elapsed 0.001 seconds)
[63563.279854] OOM killer disabled.
[63563.279856] Freezing remaining freezable tasks
[63563.281092] Freezing remaining freezable tasks completed (elapsed 0.001 
seconds)
[63563.281096] printk: Suspending console(s) (use no_console_suspend to debug)
[63563.342135] e1000e: EEE TX LPI TIMER: 0011
[63563.527367] ACPI: EC: interrupt blocked
[67161.893202] ACPI: EC: interrupt unblocked
[67162.417240] nvme nvme0: Shutdown timeout set to 8 seconds
[67162.427479] nvme nvme0: 8/0/0 default/read/poll queues
[67162.913674] OOM killer enabled.
[67162.913679] Restarting tasks ... 
[67162.913678] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: 
bound :00:02.0 (ops i915_hdcp_component_ops [i915])
[67162.919662] done.
[67162.919715] random: crng reseeded on system resumption
[67162.929518] PM: suspend exit
[67163.536574] psmouse serio1: elantech: assuming hardware version 4 (with 
firmware version 0x5f3001)
[67163.549626] psmouse serio1: elantech: Synaptics capabilities query result 
0x90, 0x18, 0x0d.
[67163.563027] psmouse serio1: elantech: Elan sample query result 00, 0d, a7
[67163.576056] psmouse serio1: elantech: Elan ic body: 0x11, current fw 
version: 0x4
[67163.656316] psmouse serio1: elantech: Trying to set up SMBus access
[67163.663757] elan_i2c 14-0015: supply vcc not found, using dummy regulator
[67163.673141] elan_i2c 14-0015: Elan Touchpad: Module ID: 0x000d, Firmware: 
0x0001, Sample: 0x, IAP: 0x
[67163.673442] input: Elan Touchpad as 
/devices/pci:00/:00:1f.4/i2c-14/14-0015/input/input248
[67163.673824] input: Elan TrackPoint as 
/devices/pci:00/:00:1f.4/i2c-14/14-0015/input/input249
[67164.070142] [ cut here ]
[67164.070147] kernfs: can not remove '14-0015', no directory
[67164.070157] WARNING: CPU: 7 PID: 22175 at fs/kernfs/dir.c:1625 
kernfs_remove_by_name_ns+0xba/0xc0
[67164.070168] Modules linked in: elan_i2c psmouse(-) ctr ccm rfcomm cmac 
algif_hash algif_skcipher af_alg snd_seq_dummy snd_hrtimer snd_seq 
snd_seq_device bnep btusb btrtl btbcm btintel btmtk bluetooth uvcvideo 
jitterentropy_rng wacom videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 drbg 
videobuf2_common ansi_cprng usbhid videodev ecdh_generic ecc crc16 mc qrtr 
binfmt_misc hid_sensor_accel_3d hid_sensor_trigger hid_sensor_iio_common 
nls_ascii industrialio_triggered_buffer kfifo_buf nls_cp437 squashfs 
industrialio vfat fat hid_sensor_custom hid_sensor_hub hid_generic 
intel_ishtp_hid hid x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel 
snd_sof_pci_intel_tgl snd_hda_codec_hdmi iwlmvm snd_sof_intel_hda_common kvm 
soundwire_intel soundwire_generic_allocation soundwire_cadence 
snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp irqbypass crc32_pclmul 
mac80211 snd_sof snd_ctl_led snd_sof_utils ghash_clmulni_intel snd_soc_hdac_hda 
snd_hda_codec_realtek snd_hda_ext_core
[67164.070255]  snd_soc_acpi_intel_match sha512_ssse3 snd_soc_acpi 
sha512_generic snd_hda_codec_generic snd_soc_core snd_compress soundwire_bus 
libarc4 snd_hda_intel iwlwifi snd_intel_dspcfg aesni_intel snd_intel_sdw_acpi 
snd_hda_codec crypto_simd cryptd thinkpad_acpi snd_hda_core mei_hdcp 
rtsx_pci_sdmmc iTCO_wdt intel_pmc_bxt xhci_pci snd_hwdep rapl nvram 
iTCO_vendor_support mmc_core watchdog xhci_hcd mei_me snd_pcm intel_ish_ipc 
e1000e platform_profile i2c_i801 intel_cstate 
processor_thermal_device_pci_legacy cfg80211 intel_rapl_msr usbcore snd_timer 
pcspkr processor_thermal_device ledtrig_audio thunderbolt think_lmi ptp mei 
i2c_smbus snd processor_thermal_rfim firmware_attributes_class wmi_bmof 
rtsx_pci processor_thermal_mbox pps_core ucsi_acpi processor_thermal_rapl 
typec_ucsi roles intel_rapl_common intel_ishtp intel_uncore usb_common 
intel_soc_dts_iosf typec igen6_edac soundcore rfkill battery int3403_thermal 
int340x_thermal_zone ac soc_button_array intel_pmc_core int3400_thermal

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Marc Haber]

On Tue, May 02, 2023 at 12:49:13PM +0100, Dark wrote:
> Yep this is a systemd system

Then your issue is completely independent from this bug report. I am
happy to hear from you in a new bug report.

Greetings
Marc

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

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Marc Haber]

I apologize for letting this hang for too long. Sadly, any more changes
are not going to be in bookworm.

On Wed, Mar 15, 2023 at 04:14:25AM +0100, Guillem Jover wrote:
> On Thu, 2023-03-09 at 14:39:37 +0100, Marc Haber wrote:
> > On Sun, Mar 05, 2023 at 06:45:59PM +0100, Guillem Jover wrote:
> > >  # added updating to 0.18-1
> > >  rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
> > >  
> > > -if dpkg --compare-versions "$2" lt 0.17.5-1; then
> > > +if dpkg --compare-versions "$2" lt "0.18-2"; then
> > 
> > I am wondering why your postinst didn't trigger there. And I think if
> > there is one person in Debian who knows how dpkg --compare-versions
> > works then I am right now talking to him.
> 
> > Current stable has 0.17.3-4+deb11u1, and we had  number of 0.17.4
> > versions in testing during the bullseye cycle, so even the first version
> > comparing with 0.17.5-1 should have always triggered the chown
> > mechanisms, right?
> 
> I think I tried to cover this in the commit message, but perhaps it
> was not very clear. This should have triggered, and the chown/chmod
> calls executed, but because the user _aide had not been created then
> the chown calls failed silently and their error codes got ignored.

So we should check for _aide to be present, or is the current package
using dh_installsysusers robust enough so that we can assume _aide to be
there?

> > if dpkg --compare-versions "$2" lt 0.18-3; then
> > # we're updating from a version earlier than 0.18-3, chown aideinit logs
> > chown --quiet _aide:adm /var/log/aide/aideinit.log 
> > /var/log/aide/aideinit.errors|| true
> > fi
> 
> See above. Also, I'd assume the supported users are root or _aide? Or
> do you consider running under any arbitrary user configured by the
> admin something to support? If the former, then if the admin has
> decided to run the tools as root, then I'd assume the tools should have
> enough permissions to write into the files even if they are owned by
> _aide (but didn't try that in case they drop privs or similar).

I'd like to be cooperative and help local admins to use other users as
well, but not to an extents that I would write tens of lines of codes to
"support" this. I'd just rather not slam a door unnecessarily, if that
makes sense.

> > >  Depends: aide (>= 0.17),
> > >   liblockfile1,
> > >   ucf (>= 2.0020),
> > > + adduser | systemd-sysusers,
> > >   ${misc:Depends}
> > 
> > This is hopefully handled by dh_installsysusers
> 
> (I assume that will imply having to install systemd-sysusers on a
> system where adduser is already available if no adduser support is
> added, which seems unfortunate, but better than not having the user
> created. :)

Yes, that will imply that. systemd-sysusers is provided by systemd
proper, and I do not plan on using adduser in aide.

> > >  Recommends: cron,
> > > + libcap2-bin,
> > >   bsd-mailx | mailx | s-nail
> > 
> > I'd rather not have this but document it in README.Debian to not pull in
> > libcap2-bin on systemd systems which don't need that dependency. I have
> > added a half-sentence mentioning libcap2-bin to README.Debian. The
> > scripts should run fine without libcap2-bin installed and fall back to
> > running as root instead.
> 
> If you find Recommends too strong, then it can always be added as a
> Suggests, which is metadata available to the package managers and
> frontends (perhaps even with a brief note in the Description?).

Too late for bookworm, but noted for the next cycle. It will be a
suggests.

Greetings
Marc

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Dark]

Yep this is a systemd system

The only relevant customisation I can think of is adduser.conf set to 
'DIR_MODE=0750' (which I reverted to the new 0700 default as part of the 
upgrade, but not sure if that happened before or after aide was 
upgraded), and proc mounted with 'hidepid=2' (which I know systemd 
sometimes isn't happy with)


Will get a separate bug written up soon


On 02/05/2023 12:41, Marc Haber wrote:

Hi Dark,

please file a new bug report, that gives more information about your
system.

Are you using systemd?

Greetings
Marc

Bug#1032381: aide: Broken aideinit due to _aide user handling

[Marc Haber]

Hi Dark,

please file a new bug report, that gives more information about your
system.

Are you using systemd?

Greetings
Marc

Bug#1035378: linux - Backport of jumbo support in Microsoft Azure Network Adapter

[Bastian Blank]

Source: linux
Version: 6.1.25-1
Severity: important

Microsoft asked to backport the jumbo frame support in the Microsoft
Azure Network Adapter from current master.  The changes are not suitable
for stable@ and contained to this one driver.

Commit ids are something like

80f6215b450eb8e92d8b1f117abf5ecf867f963e
2fbbd712baf1c60996554326728bbdbef5616e12
a2917b23497e4205db32271e4e06e142a9f8a6aa
ce518bc3e9ca342309995c9270c3ec4892963695
df18f2da302f169e1a29098c6ca3b474f1b0269e
5c74064f43c291d9add2b436a2d70205b71a7cc7

And for good measure:

bd7fc6e1957c2102866f9e464c1f2302e891b7e9

Bastian

Bug#958218: update-grub fails to process more than one argument to initrd

[Steve McIntyre]

Hi Krzmbrzl,

On Mon, May 01, 2023 at 02:42:41PM +0200, Krzmbrzl wrote:
>Hi everyone,
>
>In this report, there seems to be an indication that this issue was fixed
>with grub2/2.04-5. At least that's how I interpret the auto-generated line
>"No longer marked as found in versions grub2/2.04-5" that was somehow
>triggered by Colin Watson (though when checking the respective mail, it seems
>like that is only about reassignment and not about a resolution).
>
>In either case, I want to report that this issue still exists when having
>grub2-common/2.06 installed (on Ubuntu 22.04), which comes with
>os-prober/1.79.

If you're seeing this in Ubuntu, then you'll need to talk to the
Ubuntu developers. There are two parts to this, one in os-prober
itself and one in GRUB. The os-prober part was fixed in version 1.80
in Debian. The fix in GRUB will be included shortly in Debian - see

  
https://salsa.debian.org/grub-team/grub/-/commit/358e8faa1329e9ed3467f6f9cacaa781fc34a7b8
 

I'd suggest you ask the Ubuntu folks to pick that up.

>Furthermore, I can explain exactly where this issue occurs. I have written up
>a question on the Unix StackExchange about this, that contains the
>explanation: https://unix.stackexchange.com/q/744624/203826

ACK.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty

Bug#1035376: unblock: nfs-ganesha/4.3-2

[Christoph Martin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: mar...@uni-mainz.de

Please unblock package nfs-ganesha

4.3-2 contains a fix for a RC bug which prevents smooth upgrade of
nfs-ganesha-ceph :#1034925.

[ Reason ]
Fixes RC bug #1034925.

[ Impact ]
includes breaks: and replaces: to make upgrade succeed.

[ Tests ]
Installation was successful

[ Risks ]
I don't see any risks.

[ 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 nfs-ganesha/4.3-2
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in second .changes but not in first
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/47/075fa73da0e4bfba1008cb4a432c16795d1646.debug

Files in first .changes but not in second
-
-rw-r--r--  root/root   
/usr/lib/debug/.build-id/c0/969f5415c2e585fa41915d3e0f593b0bd1677d.debug

Control files of package nfs-ganesha: lines which differ (wdiff format)
---
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-ceph: lines which differ (wdiff format)

{+Breaks: nfs-ganesha (<< 4.0-1)+}
Depends: libacl1 (>= 2.2.23), libc6 (>= 2.34), libcephfs2 (>= 16.2.6+ds), 
librados2 (>= [-16.2.10+ds),-] {+16.2.11+ds),+} liburcu8 (>= 0.13.0), 
nfs-ganesha (= [-4.3-1)-] {+4.3-2)+}
{+Replaces: nfs-ganesha (<< 4.0-1)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-ceph-dbgsym: lines which differ (wdiff 
format)
---
Build-Ids: {+47075fa73da0e4bfba1008cb4a432c16795d1646+} 
9e0845a088c12df1b6e7bc74c10af58102f949ac 
[-c0969f5415c2e585fa41915d3e0f593b0bd1677d-] 
ceae296fe799f3feca7b7afd36e68cd64484192b
Depends: nfs-ganesha-ceph (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-dbgsym: lines which differ (wdiff format)
--
Depends: nfs-ganesha (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-doc: lines which differ (wdiff format)
---
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-gluster: lines which differ (wdiff format)
---
Depends: libacl1 (>= 2.2.23), libc6 (>= 2.34), libgfapi0 (>= 10.3), liburcu8 
(>= 0.13.0), nfs-ganesha (= [-4.3-1),-] {+4.3-2),+} libglusterfs0 (>= 6.0)
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-gluster-dbgsym: lines which differ (wdiff 
format)
--
Depends: nfs-ganesha-gluster (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-gpfs: lines which differ (wdiff format)

Depends: libc6 (>= 2.34), libdbus-1-3 (>= 1.9.14), liburcu8 (>= 0.13.0), 
nfs-ganesha (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-gpfs-dbgsym: lines which differ (wdiff 
format)
---
Depends: nfs-ganesha-gpfs (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-mem: lines which differ (wdiff format)
---
Depends: libc6 (>= 2.34), nfs-ganesha (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-mem-dbgsym: lines which differ (wdiff 
format)
--
Depends: nfs-ganesha-mem (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-mount-9p: lines which differ (wdiff format)

Depends: nfs-ganesha (>= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-nullfs: lines which differ (wdiff format)
--
Depends: libc6 (>= 2.4), nfs-ganesha (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package nfs-ganesha-nullfs-dbgsym: lines which differ (wdiff 
format)
-
Depends: nfs-ganesha-nullfs (= [-4.3-1)-] {+4.3-2)+}
Version: [-4.3-1-] {+4.3-2+}

Control files of package 

Bug#1035377: unblock: libapache2-mod-auth-openidc/2.4.12.3-2

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libapache2-mod-auth-open...@packages.debian.org
Control: affects -1 + src:libapache2-mod-auth-openidc

Please unblock package libapache2-mod-auth-openidc

Fixes CVE-2023-28625 "segfault DoS when OIDCStripCookies is set".

[ Reason ]
Fixes #1033916 by fixing CVE-2023-28625.

[ Impact ]
The CVE with  Base Score:  7.5 HIGH
Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
would persist in the new stable release.

[ Tests ]
The patch has been verified by upstream and I have successfully
tested the new package version in our infrastructure.

[ Risks ]
The newly added patch changes just two lines by adding a
null pointer check. I don't see anything getting worse by
that.

[ 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 libapache2-mod-auth-openidc/2.4.12.3-2

Bug#1033916: libapache2-mod-auth-openidc: CVE-2023-28625: segfault DoS when OIDCStripCookies is set

[Moritz Schlarb]

Dear Security Team,

regarding fixing this in Bullseye 
(https://salsa.debian.org/debian/libapache2-mod-auth-openidc/-/compare/769c3920203e7c64f6ff9456ee6858ac0cb034f0...a8e821213ac28ca0909ca4f1bf512de5e35f90fa):


Shall I upload this to security or proposed-updates?

Best regards,
Moritz

On 03.04.23 22:38, Salvatore Bonaccorso wrote:

Source: libapache2-mod-auth-openidc
Version: 2.4.12.3-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libapache2-mod-auth-openidc.

CVE-2023-28625[0]:
| mod_auth_openidc is an authentication and authorization module for the
| Apache 2.x HTTP server that implements the OpenID Connect Relying
| Party functionality. In versions 2.0.0 through 2.4.13.1, when
| `OIDCStripCookies` is set and a crafted cookie supplied, a NULL
| pointer dereference would occur, resulting in a segmentation fault.
| This could be used in a Denial-of-Service attack and thus presents an
| availability risk. Version 2.4.13.2 contains a patch for this issue.
| As a workaround, avoid using `OIDCStripCookies`.


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-28625
 https://www.cve.org/CVERecord?id=CVE-2023-28625
[1] 
https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-f5xw-rvfr-24qr

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore


--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035375: mtools: interprets SOURCE_DATE_EPOCH in system timezone instead of UTC

[Alper Nebi Yasak]

Package: mtools
Version: 4.0.33-1+really4.0.32-1
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org


Hi,

I came across timestamp differences in FAT filesystem images while
trying to build debian-installer with debrepro (among many other
things), and tracked it down to mmd/mcopy calls. Here's a short reproducer:

  export SOURCE_DATE_EPOCH="$(date "+%s")"

  imgprep() {
[ -f "$1" ] && rm "$1"
mkfs.msdos --invariant -v -i deb1 -C "$1" 512
mmd -i "$1" ::foo
mcopy -i "$1" "$2" ::bar
  }

  dd if=/dev/random of=rand.img bs=512 count=200

  TZ=UTC   imgprep first.img rand.img
  TZ=UTC-3 imgprep second.img rand.img

  diffoscope first.img second.img

which shows an exact 3-hour difference in timestamps for me. AFAICT,
SOURCE_DATE_EPOCH is meant to be in UTC, so embedded timestamps and the
two files should be the same regardless of TZ or system timezone.