Bug#1063640: adwaita-icon-theme: cursor theme not found

[Guy Rutenberg]

Package: mutter
Version: 44.8-3
Followup-For: Bug #1063640
X-Debbugs-Cc: guyrutenb...@gmail.com

Dear Maintainer,

I just experienced the same bug using mutter 44.8-3 and adwaita-icon-them
46~beta-1. Reverting back to adwaita-icon-theme 45.0-2 resolved the issue.

Guy

*** 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: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mutter depends on:
ii  adwaita-icon-theme45.0-2
ii  gnome-settings-daemon-common  45.1-1
ii  gsettings-desktop-schemas 45.0-2
ii  libc6 2.37-15
ii  libgles2  1.7.0-1
ii  libglib2.0-0  2.78.3-2
ii  libmutter-12-044.8-3
ii  libwayland-client01.22.0-2.1+b1
ii  mutter-common 44.8-3
ii  zenity4.0.1-1

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:46~alpha-2
ii  xdg-user-dirs 0.18-1

-- no debconf information

Bug#1063753: systemd: IFB network devices are no longer autocreated when ifb module is loaded

[Andreas Sundstrom]

Package: systemd
Version: 252.22-1~deb12u1
Severity: important
X-Debbugs-Cc: sunkan+debian.b...@zappa.cx

Dear Maintainer,

After upgrading systemd from 252.19-1~deb12u1 to 252.22-1~deb12u1
(Bookworm 12.4 to 12.5) the IFB network devices are no longer
automatically created when loading the `ifb` module. This is a
regression since previous releases as there is nothing mentioned about
this in the changelog.

It seems the root cause is that the following has been added to
/lib/modprobe.d/systemd.conf

[part of .../systemd.conf]
# Do the same for ifb0.

options ifb numifbs=0
[end]

How this will affect your system depends a lot on what you use the IFB
device(s) for. In my case it is used in combination with a QoS
scheduling/shaping setup.

For now I have worked around this change by adding the IFB device I
needed manually with the command `ip link add ifb0 numtxqueues 8 type
ifb`. And from what I can tell the kernel default setting is
`numifbs=2`.

Bug#1051470: RFP: esbuild-sass-plugin -- Plugin for esbuild to handle Sass & SCSS files

[Carsten Schoenert]

The list of deps isn't that long, but there are some other packages need
to be around before esbuild-sass-plugin can be packaged.

$ date
Mo 12. Feb 08:15:18 CET 2024
$ npm2deb depends -b -r esbuild-sass-plugin
Dependencies:
NPM   Debian
esbuild-sass-plugin (3.0.0)   None
├─ resolve (^1.22.6)  node-resolve 
(1.22.8+~cs5.34.15-2)
└─ sass-embedded (^1.70.0)None
   ├─ @bufbuild/protobuf (^1.0.0) None
   ├─ buffer-builder (^0.2.0) None
   ├─ immutable (^4.0.0)  node-immutable (4.3.4-1)
   ├─ rxjs (^7.4.0)   None
   │  └─ tslib (^2.1.0)   node-tslib (2.4.1-1)
   ├─ supports-color (^8.1.1) node-supports-color 
(8.1.1+~8.1.1-1)
   └─ varint (^6.0.0) None

Bug#1061028: flask-restful: FTBFS: intersphinx inventory 'six/objects.inv' not fetchable due to : [Errno 2] No such file or directory: '/<>/docs/six/objects.inv

[Alexandre Detiste]

flask 3.0 is there now.

https://tracker.debian.org/news/1502520/accepted-flask-302-1-source-into-unstable/

Le lun. 12 févr. 2024 à 04:47, Emmanuel Arias  a écrit :
>
> Hi,
>
> flask 3.0 will fix this two tests?
I don't know, I was just busy with other things
and it felt like wastign time to test with 2.x

> New upstream release of flask-restful
> + this two tests turned off can not be uploaded yet?
I guess this can be uploaded soonish.

Greetings

Bug#1063739: Bug#1006531: mariadb: FTBFS on hurd-i386: cmake/plugin.cmake: Plugin AUTH_SOCKET cannot be built

[Otto Kekäläinen]

Thanks Daniel!

Pushed to 
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/70
for additional testing/review

Bug#1063752: custodian: Inappriate maintainer address

[Scott Kitterman]

Source: custodian
Version: 2024.1.9-2
Severity: serious
Justification: Policy 3.3

Policy 3.3 says that maintainer addresses must accept mail from Debian
role accounts.  This one, apparently, does not:

From:   debichem-devel-ow...@alioth-lists.debian.net
To: ftpmas...@ftp-master.debian.org
Sender: Debichem-devel 

List-Id:Debichem development list 

Date:   2/11/24 10:10 PM
Spam Status:Spamassassin 
You are not allowed to post to this mailing list From: a domain which
publishes a DMARC policy of reject or quarantine, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
debichem-devel-ow...@alioth-lists.debian.net.

Scott K

Bug#1063462: pycurl: FTBFS during tests: GnuTLS recv error (-110): The TLS connection was non-properly terminated

[Scott Talbert]

Control: reassign -1 src:curl 8.6.0-1
Control: affects -1 src:pycurl

On Thu, 8 Feb 2024, Emanuele Rocca wrote:


Source: pycurl
Version: 7.45.2-7
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: sid trixie ftbfs

Dear Maintainer,

pycurl currently fails to build from source on amd64 and arm64 with the
following error:

=== FAILURES ===
__ CertinfoTest.test_request_without_certinfo __

self = 

   @util.min_libcurl(7, 19, 1)
   @util.only_ssl
   def test_request_without_certinfo(self):
   self.curl.setopt(pycurl.URL, 'https://localhost:8383/success')
   sio = util.BytesIO()
   self.curl.setopt(pycurl.WRITEFUNCTION, sio.write)
   # self signed certificate
   self.curl.setopt(pycurl.SSL_VERIFYPEER, 0)

  self.curl.perform()

E   pycurl.error: (56, 'GnuTLS recv error (-110): The TLS connection was 
non-properly terminated.')

tests/certinfo_test.py:34: error
=== warnings summary ===
../../../usr/lib/python3/dist-packages/bottle.py:38
 /usr/lib/python3/dist-packages/bottle.py:38: DeprecationWarning: 'cgi' is 
deprecated and slated for removal in Python 3.13
   import base64, cgi, email.utils, functools, hmac, itertools, mimetypes,\

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
===Flaky Test Report===
=== short test summary info 
FAILED tests/certinfo_test.py::CertinfoTest::test_request_without_certinfo - ...
= 1 failed, 404 passed, 19 skipped, 5 deselected, 1 warning in 15.80s ==


This is a regression in curl 8.6.0.  It has already been fixed/reverted 
upstream: 
https://github.com/curl/curl/commit/ed09a99af57200643d5ae001e815eeab9ffe3f84


Cherry-picking that commit should fix the issue.

Regards,
Scott

Bug#1061028: flask-restful: FTBFS: intersphinx inventory 'six/objects.inv' not fetchable due to : [Errno 2] No such file or directory: '/<>/docs/six/objects.inv

[Emmanuel Arias]

Hi,

flask 3.0 will fix this two tests? New upstream release of flask-restful
+ this two tests turned off can not be uploaded yet?

-- 
cheers,
Emmanuel Arias

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  eam...@debian.org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
 
 ⠈⠳⣄


signature.asc
Description: PGP signature

Bug#1062952: This package is not affected by time_t

[Dima Kogan]

Hi.

libmrcal-dev does not use time_t. I'm seeing the abi-compliance-checker
failure here:

  
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libmrcal-dev/base/log.txt

The cause is that the tool takes all the headers in /usr/include/mrcal
in an arbitrary order, and tries to #include them. That does not work
here. "mrcal-internal.h" should not be #included explicitly since it is
already #included by mrcal.h. Removing that header from the command in
the error log above makes the errors disappear.

Let me know what needs to happen to ingest that logic, to exclude mrcal
from this transition. This will make my life easier.

Thanks.

Bug#1063750: firmware-amd-graphics: System with AMD Ryzen 7 PRO 7840U laptop fails to suspend, error from amdgpu

[Benjamin Poirier]

Package: firmware-amd-graphics
Version: 20230625-2
Severity: normal
X-Debbugs-Cc: benjamin.poir...@gmail.com

Dear Maintainer,

My laptop, Lenovo ThinkPad P14s Gen 4 with AMD Ryzen 7 PRO 7840U w/
Radeon 780M Graphics SoC, fails to enter suspend.

When I try to suspend, in ~9/10 cases, the suspend "fails" and the
machine immediately resumes. I see the following logs at the end of the
suspend sequence:

Feb 11 20:29:52 f4 kernel: 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=14
Feb 11 20:29:52 f4 kernel: [drm:amdgpu_mes_reg_write_reg_wait [amdgpu]] *ERROR* 
failed to reg_write_reg_wait

At boot I see the errors:

eb 11 20:27:36 f4 kernel: amdgpu :64:00.0: firmware: failed to load 
amdgpu/gc_11_0_1_mes_2.bin (-2)
Feb 11 20:27:36 f4 kernel: firmware_class: See https://wiki.debian.org/Firmware 
for information about missing firmware
Feb 11 20:27:36 f4 kernel: amdgpu :64:00.0: firmware: failed to load 
amdgpu/gc_11_0_1_mes_2.bin (-2)
Feb 11 20:27:36 f4 kernel: amdgpu :64:00.0: Direct firmware load for 
amdgpu/gc_11_0_1_mes_2.bin failed with error -2

I installed all the firmware files from linux-firmware.git at commit
fbef4d38, regenerated the initramfs and rebooted. Suspend worked in 3/3
tries.

To narrow things down a bit, I tried to copy only the missing firmware
file (amdgpu/gc_11_0_1_mes_2.bin) from the tag of linux-firmware
matching the installed version of the firmware-amd-graphics package
(20230625). That got rid of the "failed to load" error message of course
but suspend still failed with the same error.

Then I copied only the firmware files which are loaded by the driver on
my machine according to the following logs:

Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/psp_13_0_4_toc.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/psp_13_0_4_ta.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/dcn_3_1_4_dmcub.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/gc_11_0_1_pfp.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/gc_11_0_1_me.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/gc_11_0_1_rlc.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/gc_11_0_1_mec.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/vcn_4_0_2.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/gc_11_0_1_mes_2.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/gc_11_0_1_mes1.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/gc_11_0_1_imu.bin
Feb 11 20:52:28 f4 kernel: amdgpu :64:00.0: firmware: direct-loading 
firmware amdgpu/sdma_6_0_1.bin

I copied the files from linux-firmware.git commit fbef4d38. Somewhat
surprisingly, the suspend problem still occurred. Is there another
related firmware file that gets loaded? I tested once more by installing
all the files from linux-firmware and confirmed that the suspend problem
does not occur.

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

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

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.142

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_mec.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_mec2.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_sjt_mec.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_sjt_mec2.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_smc.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_sos.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/aldebaran_ta.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/arcturus_ta.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/beige_goby_ce.bin (from 
firmware-amd-graphics package)
debsums: changed file /usr/lib/firmware/amdgpu/beige_goby_dmcub.bin (from 
firmware-amd-graphics package)
debsums: 

Bug#1063749: kmod: kernel build fails with 31+20240202-1

[Arthur Marsh]

Package: kmod
Version: 31+20240202-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

upgrading kmod to 31+20240202-1 from 31-1

Then building a kernel using:

MAKEFLAGS='HOSTCC=gcc-14 CC=gcc-14' make -j7 menuconfig bindeb-pkg

  DEPMOD  debian/linux-image-6.8.0-rc4/lib/modules/6.8.0-rc4
depmod: ERROR: could not open directory 
/usr/src/linux/debian/linux-image-6.8.0-rc4/usr/lib/modules/6.8.0-rc4: No such 
file or directory
depmod: FATAL: could not search modules: No such file or directory

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

Downgrading kmod to 31-1 fixed things.

   * 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: trixie/sid
  APT prefers experimental
  APT policy: (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.0-rc3+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages kmod depends on:
ii  libc6 2.38-6
ii  libkmod2  31-1
ii  liblzma5  5.4.5-0.3
ii  libssl3   3.1.5-1
ii  libzstd1  1.5.5+dfsg2-2

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

Bug#1061772: Missing dependencies

[Jelmer Vernooij]

There's a bunch of dependencies for JJ that probably need to be packaged first.

IIRC there is somebody working on gitoxide (gix-*) already in debcargo

  clap-markdown v0.1.3
  esl01-renderdag v0.3.0
  gix-config v0.32.1
  gix-diff v0.38.0
  gix-discover v0.27.0
  gix-hashtable v0.4.1
  gix-index v0.27.1
  gix-macros v0.1.3
  gix-object v0.39.0
  gix-odb v0.55.0
  gix-pack v0.45.0
  gix-refspec v0.20.0
  gix-ref v0.39.1
  gix-revision v0.24.0
  gix-revwalk v0.10.0
  gix-traverse v0.35.0
  gix v0.56.0
  pollster v0.3.0
  scm-record v0.2.0
  serde_bser v0.3.1
  tracing-chrome v0.7.1
  watchman_client v0.8.0

Bug#1063748: ITP: pythonprop -- graphical interface to the VOACAP HF propagation engine

[David da Silva Polverari]

Package: wnpp
Severity: wishlist
Owner: David da Silva Polverari 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: pythonprop
  Version : 0.30.1
  Upstream Contact: James Watson 
* URL : https://github.com/jawatson/pythonprop
* License : GPL-2+
  Programming Lang: Python3
  Description : graphical interface to the VOACAP HF propagation engine
   pythonprop is a collection of Python 3 scripts designed to create VOACAP
   input (.dat) files and plot the resulting predictions.
   .
   It can be used either in point-to-point (P2P) mode, to produce HF (High
   Frequency) propagation predictions between two fixed locations, or in area
   mode, to produce HF propagation plots over a user-defined area from a fixed
   transmit site.
   .
   This package provides the voacapgui, voaP2PPlot and voaAreaPlot scripts. It 
is
   useful for making HF (High Frequency) circuit prediction for amateur radio
   ("ham radio") operators.

This package provides a GUI for the voacapl package [1]. I plan to
maintain it by myself initially, later proposing to include it on the
Debian Hamradio Team. I don't need a sponsor.

[1] https://bugs.debian.org/1063747

-- 
⢀⣴⠾⠻⢶⣦⠀ David da Silva Polverari 
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Debian: The universal operating system
⠈⠳⣄

Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

[Simon McVittie]

On Sun, 11 Feb 2024 at 13:53:56 -0800, Benjamin Kaduk wrote:
> On Sat, Feb 10, 2024 at 01:33:15PM +0100, Johannes Schauer Marin Rodrigues 
> wrote:
> > there as a binNMU "Rebuild to sync binNMU versions" for krb5 and that
> > failed for arm64, armel and ppc64el:
> > 
> > https://buildd.debian.org/status/package.php?p=krb5
> > 
> > The error logs look very similar:
> > *** Output of last command:
> > Can't resolve hostname arm-conova-03
> 
> This is due more to the build environment than the test suite per se.
...
> In short, the test suite, as for the protocol itself, assumes that it can
> resolve the server's hostname to an IP address

It might be relevant that according to #972151, arm-conova-03 (and
perhaps other *-conova-* buildds?) is IPv6-only, with no IPv4 addresses
or routes other than loopback (not even via NAT).

I believe there is consensus that we consider "localhost resolves to
127.0.0.1" to be a reasonable thing to demand from all buildds as part
of the build-essential interface.

I am unsure whether there is consensus that "the result of gethostname()
resolves to some address of the local machine" is also a reasonable
thing to demand from all buildds as part of build-essential: /etc/hosts
typically makes this true, but is not *guaranteed* to do so. On Linux,
packages can ensure that it happens by build-depending on
libnss-myhostname [linux-any], if necessary.

However, even with both of those, if the krb5 test suite (or protocol)
is resolving the local hostname with AF_INET (IPv4-only), and with either
AI_ADDRCONFIG or NULL hints, then that will not yield any results on
an IPv6-only system for the reasons discussed in #952740 and related
bug reports.

A workaround is to resolve with AF_UNSPEC, which currently disregards
AI_ADDRCONFIG, but that is, itself, arguably a bug (#854301).

If I'm understanding the krb5 issue correctly, the version of this in krb5
is more troublesome than the related issues seen in the GLib test suite,
because the GLib test suite would be happy with localhost always being
resolvable to 127.0.0.1 (as requested in #801362), but the krb5 test suite
wants to be able to resolve the local host name as well (so
resolving #801362 would not be enough).

smcv

Bug#1063747: ITP: voacapl -- HF circuit prediction engine

[David da Silva Polverari]

Package: wnpp
Severity: wishlist
Owner: David da Silva Polverari 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: voacapl
  Version : 0.7.6
  Upstream Contact: James Watson 
* URL : https://github.com/jawatson/voacapl
* License : special (public domain), CC0-1.0 and GPL-3+ parts
  Programming Lang: Fortran
  Description : HF circuit prediction engine
   voacapl is an implementation of VOACAP, the NTIA/ITS professional HF (high
   frequency) propagation prediction program, originally developed for Voice of
   America (VOA). It reads input files in the standard VOACAP format and writes
   point-to-point or area prediction data to an output file (or files).
   .
   voacapl helps amateur radio operators ("hams") predict point-to-point path
   loss and coverage of a given transceiver if given as inputs the transmitting
   and receiving antennas, solar weather, and time/date.
   .
   The suggested pythonprop package provides a graphical interface for voacapl,
   accepting inputs as fields and plotting the results as graphics.

VOACAP (Voice of America Coverage Analysis Program) is a modified
version of IONCAP (Ionospheric Communication Analysis and Prediction
Program), developed for use by Voice Of America (VOA).

Originally, IONCAP was developed by the National Telecommunications and
Information Administration (NTIA), being a model that has been under
development by the U.S. Government since 1942. The strength of the model
is that it uses world maps of ionospheric parameters to construct the
ionospheric path and uses path-specific statistics to evaluate the
system performance factors.

IONCAP was selected by the VOA in 1985 because it provided the system
performance analysis capability they needed for design specifications
and it had a proven track record.

VOACAP's enhanced model is used worldwide to predict HF point-to-point
or area data. It is often used on Microsoft Windows, distributed inside
the HFWIN32 suite [1], where it is called VOACAPW.

There is a shortage of HF prediction packages on Debian. In the past, I
had to resort to using Windows machines to make HF predictions. Thus, I
intend to package voacapl, along with its companion GUI, pythonprop,
which depends on it.

Initially, I plan to package it by myself, and I will propose including
it in the Debian Hamradio Team. I don't need a sponsor. I have already
packaged them both, and just need to make some minor adjustments.

[1] http://www.greg-hand.com/hfwin32.html

-- 
⢀⣴⠾⠻⢶⣦⠀ David da Silva Polverari 
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Debian: The universal operating system
⠈⠳⣄

Bug#1063746: golang-github-katalix-go-l2tp: FTBFS: transport_test.go:388: test sender function reported an error: failed to send Hello message: transmit of avpMsgTypeHello failed after 3 retry attempt

[Mathias Gibbens]

Source: golang-github-katalix-go-l2tp
Version: 0.1.6-2
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs

  In a clean sid schroot, one of the tests is timing out:

> transport_test.go:388: test sender function reported an error: failed to 
> send Hello message: transmit of avpMsgTypeHello failed after 3 retry attempts
> panic: test timed out after 10m0s
> running tests:
>   TestBasicSendReceive (9m59s)
>   TestBasicSendReceive/5:_send/recv_[::1]:9000_[::1]:9001_L2TPv3_IP 
> (9m59s)
> 
> [snip goroutine tracebacks]

  This is also occurring in the debci runs:
https://ci.debian.net/packages/g/golang-github-katalix-go-l2tp/


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

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Andreas Beckmann]

On 11/02/2024 21.36, Salvatore Bonaccorso wrote:

If I can add a comment: I (but note I'm not wearing a
nvidia-graphics-drivers maintainer hat) would support that, as there
are enough people affected by this. This is quite unfortunate and I'm
open to hear ideas how we can try to avoid such fallouts.


I was aware of the bug (#1062932) but not of the fact a point release 
was upcoming. Even if I had been aware of the point release I'm not sure 
if I had realized the impact of this bug to make me yell ;-)
Perhaps once point release dates have been choosen, this could be 
announced to d-d-a@ as well.

I'm not following debian-release@ ... -ENOTIME


As you know we are strictly following upstream stable series (and
trying our best to keep an eye on as well regression reports upstream,
but OOT modules are not explicitly tested, so neither the nvidia ones)


Are autopkgtests being run for proposed-updates? That should have shown 
the issue.


It was unfortunate that this upstream backported change appeared in 
proposed-updates first and in sid only a few days later. And the 
metapackages from linux-signed-amd64 are still depending on the version 
before this change was introduced ... so I only could reproduce the 
issue (and verify fixes) manually. (The module build test done during 
the package build did not use the regressing headers.)


Then I had to spent quite some time verifying that the issue only 
happened on amd64 and since the 460 series (despite of ppc64el having 
even more calls to pfn_valid() dating back to the 418 series).


Andreas

PS: @Salvatore: Looking forward to see some linux 6.8 packages in 
experimental s.t. I can throw them in my module build chroot to see what 
breaks next :-) Or do you already have some early build available 
somewhere while experimental is still preparing 6.7?

Bug#1063742: bookworm-pu: package nvidia-settings/525.147.05-1~deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, Feb 11, 2024 at 11:52:14PM +0100, Andreas Beckmann wrote:
> [ Reason ]
> In order to enable building src:nvidia-graphics-drivers for ppc64el
> (part of the unification with src:nvidia-graphics-drivers-tesla), we
> also need to enable building src:nvidia-settings for ppc64el, otherwise
> we get some unsatisfiable dependency.
> (I'm not trying some magic to use nvidia-settings-tesla which is already
> built for ppc64el to satisfy that dependency.)

Agreed. Please go ahead.

Thanks,

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

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

Bug#1063739: Bug#1006531: mariadb: FTBFS on hurd-i386: cmake/plugin.cmake: Plugin AUTH_SOCKET cannot be built

[Daniel Black]

Opps, wrong one - this one https://github.com/MariaDB/server/pull/3039

On Mon, 12 Feb 2024 at 10:10, Daniel Black  wrote:
>
> Fixed by https://github.com/MariaDB/server/pull/3002 which didn't make
> the release unfortunately.
>
> On Mon, 12 Feb 2024 at 09:43, Otto Kekäläinen  wrote:
> >
> > Version: 1:10.11.7-1
> >
> > I confirm this was fixed in latest upload MariaDB 1:10.11.7-1, which
> > included 
> > https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/66
> >
> > Unfortunately there seems to be more failures now that build is
> > passing on this one, see
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063739.

Bug#1063739: Bug#1006531: mariadb: FTBFS on hurd-i386: cmake/plugin.cmake: Plugin AUTH_SOCKET cannot be built

[Daniel Black]

Fixed by https://github.com/MariaDB/server/pull/3002 which didn't make
the release unfortunately.

On Mon, 12 Feb 2024 at 09:43, Otto Kekäläinen  wrote:
>
> Version: 1:10.11.7-1
>
> I confirm this was fixed in latest upload MariaDB 1:10.11.7-1, which
> included 
> https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/66
>
> Unfortunately there seems to be more failures now that build is
> passing on this one, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063739.

Bug#1063737: bookworm-pu: package nvidia-graphics-drivers-tesla-470/470.223.02-4~deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, Feb 11, 2024 at 11:16:13PM +0100, Andreas Beckmann wrote:
> [ Reason ]
> 1) A backported (by upstream) change in Linux 6.1.76 (included in
> today's point release) broke compilation of the non-free nvidia kernel
> module. A patched version of the driver is available in sid.
> 
> 2) After merging src:nvidia-graphics-drivers-tesla into
> src:nvidia-graphics-drivers (PU request for src:nvidia-graphics-drivers
> is already approved), the nvidia-cuda-mps package will be built from
> src:nvidia-graphics-drivers, so stop building it here.

Please go ahead.

Thanks,



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

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

Bug#1063745: srt: FTBFS on i386: build-gnutls/test-srt failed in Transmission.FileUpload: srt_close(accepted_sock) -> SRT_ERROR

[Simon McVittie]

Source: srt
Version: 1.5.3-1
Severity: important
Tags: ftbfs unreproducible

The srt_1.5.3-1+b1 binNMU initially failed to build on the i386 buildd
with this test failure:

> 100: Test command: /<>/build-gnutls/test-srt 
> "--gtest_filter=Transmission.FileUpload"
> 100: Working Directory: /<>/build-gnutls
> 100: Test timeout computed to be: 1000
> 100: Note: Google Test filter = Transmission.FileUpload
> 100: [==] Running 1 test from 1 test suite.
> 100: [--] Global test environment set-up.
> 100: [--] 1 test from Transmission
> 100: [ RUN  ] Transmission.FileUpload
> 100: Running test on port 5000
> 100: WILL CREATE source file with size=84410368 (= 7 * 12058624[sndbuf])
> 100: Connection initialized
> 100: Finished sending, closing sockets:
> 100: Sockets closed, joining receiver thread
> 100: Received 0 bytes, breaking.
> 100: ./test/test_file_transmission.cpp:130: Failure
> 100: Expected: (srt_close(accepted_sock)) != (SRT_ERROR), actual: -1 vs -1
> 100:
> 100: Comparing files
> 100: [  FAILED  ] Transmission.FileUpload (9806 ms)

I gave back the build and it succeeded, so this is probably only an
intermittent failure, hence reported as non-RC; but it seemed like
something that maintainers should be aware of, to monitor whether it
happens again. Older build logs don't seem to show this test failing.

(I don't really know what this package is or does, I only noticed this
because the build failure temporarily made its amd64 and i386 instances
non-co-installable).

Thanks,
smcv

Bug#1063744: RFP: alexvsbus -- a platform runner game

[Alexandre Almeida]

Package: alexvsbus
Severity: wishlist

* Package name: alexvsbus
  Version : 2024.02.10.0
  Upstream Author : M374LX
* URL : https://github.com/M374LX/alexvsbus
* License : GPL
  Programming Lang: C
  Description : a platform runner game

It would be nice if the new FOSS game I have just
released could be included in Debian's repositories.

In case a compelling reason is needed, it is a complete
game, no longer WIP.

Bug#1063743: gloo-cuda: required rebuilds for libhiredis transition

[Sebastian Ramacher]

Source: gloo-cuda
Version: 0.0~git20230117.1090929-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sramac...@debian.org

gloo-cuda is involved in the libhiredis transition. But since the
package cannot be built on the buildds, uploads of builds against the
new libhiredis version are required.

Cheers
-- 
Sebastian Ramacher

Bug#1063742: bookworm-pu: package nvidia-settings/525.147.05-1~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 +1 src:nvidia-settings

[ Reason ]
In order to enable building src:nvidia-graphics-drivers for ppc64el
(part of the unification with src:nvidia-graphics-drivers-tesla), we
also need to enable building src:nvidia-settings for ppc64el, otherwise
we get some unsatisfiable dependency.
(I'm not trying some magic to use nvidia-settings-tesla which is already
built for ppc64el to satisfy that dependency.)

[ Impact ]
Uninstallable nvidia driver package on ppc64el.

[ Tests ]
Would require use of nvidia hardware and driver.

[ Risks ]
Low. No relevant changes besides enabling the package for another
architecture.

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

[ Changes ]
nvidia-settings (525.147.05-1~deb12u1) bookworm; urgency=medium

  * Rebuild for bookworm.

 -- Andreas Beckmann   Sun, 11 Feb 2024 23:27:34 +0100

nvidia-settings (525.147.05-1) unstable; urgency=medium

  * New upstream release 525.147.05.
  * Build for ppc64el.

 -- Andreas Beckmann   Fri, 26 Jan 2024 19:29:45 +0100

 debian/changelog  | 13 +
 debian/control|  2 +-
 debian/copyright  |  2 +-
 debian/salsa-ci.yml   |  3 +--
 doc/version.mk|  2 +-
 samples/version.mk|  2 +-
 src/libXNVCtrl/version.mk |  2 +-
 src/version.mk|  2 +-
 version.mk|  2 +-
 9 files changed, 21 insertions(+), 9 deletions(-)

This is a new upstream release but the only change is the version bump.
Since I had to upload the package anyway, I used the latest upstream to
be in sync again with the driver.

[ Other info ]
The is a rebuild of the package from sid with no further changes.


Andreas
diff --git a/debian/changelog b/debian/changelog
index 4c8ff6b..07ad2e7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+nvidia-settings (525.147.05-1~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Sun, 11 Feb 2024 23:27:34 +0100
+
+nvidia-settings (525.147.05-1) unstable; urgency=medium
+
+  * New upstream release 525.147.05.
+  * Build for ppc64el.
+
+ -- Andreas Beckmann   Fri, 26 Jan 2024 19:29:45 +0100
+
 nvidia-settings (525.125.06-1~deb12u1) bookworm; urgency=medium
 
   * Rebuild for bookworm.
diff --git a/debian/control b/debian/control
index 20fd7fa..3cd072a 100644
--- a/debian/control
+++ b/debian/control
@@ -26,7 +26,7 @@ Vcs-Browser: 
https://salsa.debian.org/nvidia-team/nvidia-settings
 Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-settings.git
 
 Package: nvidia-settings
-Architecture: amd64 arm64
+Architecture: amd64 arm64 ppc64el
 Pre-Depends:
  nvidia-installer-cleanup,
 Depends:
diff --git a/debian/copyright b/debian/copyright
index d41447d..a606761 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -102,7 +102,7 @@ License: Expat
 Files: debian/*
 Copyright: © 2004-2010 Randall Donald 
© 2009-2010 Fathi Boudra 
-   © 2011-2023 Andreas Beckmann 
+   © 2011-2024 Andreas Beckmann 
© 2017  Luca Boccassi 
 License: GPL-2
 
diff --git a/debian/salsa-ci.yml b/debian/salsa-ci.yml
index 14fa000..c3d1fdf 100644
--- a/debian/salsa-ci.yml
+++ b/debian/salsa-ci.yml
@@ -1,7 +1,6 @@
 ---
 include:
-  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
-  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
 
 variables:
   SALSA_CI_COMPONENTS: 'main contrib non-free'
diff --git a/doc/version.mk b/doc/version.mk
index 33fa123..dae35ac 100644
--- a/doc/version.mk
+++ b/doc/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 525.125.06
+NVIDIA_VERSION = 525.147.05
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/samples/version.mk b/samples/version.mk
index 33fa123..dae35ac 100644
--- a/samples/version.mk
+++ b/samples/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 525.125.06
+NVIDIA_VERSION = 525.147.05
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/src/libXNVCtrl/version.mk b/src/libXNVCtrl/version.mk
index 33fa123..dae35ac 100644
--- a/src/libXNVCtrl/version.mk
+++ b/src/libXNVCtrl/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 525.125.06
+NVIDIA_VERSION = 525.147.05
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/src/version.mk b/src/version.mk
index 33fa123..dae35ac 100644
--- a/src/version.mk
+++ b/src/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 525.125.06
+NVIDIA_VERSION = 525.147.05
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/version.mk b/version.mk
index 33fa123..dae35ac 100644
--- a/version.mk
+++ b/version.mk
@@ 

Bug#1063741: ITP: hipify -- CUDA to HIP source-to-source translation tools

[Cordell Bloor]

Package: wnpp
Severity: wishlist
Owner: Cordell Bloor 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org, 
c...@slerp.xyz

* Package name: hipify
  Version : 6.0.2
* URL : https://github.com/ROCm/HIPIFY
* License : Expat
  Programming Lang: C++, Perl
  Description : CUDA to HIP source-to-source translation tools

hipify is a set of tools to convert CUDA sources into HIP sources. It
provides hipify-clang, which uses a clang-based parser and can therefore
translate complex C++ constructs, but requires complete input sources,
including access to any CUDA headers used. For cases where this is not
possible, it provides hipify-perl, which uses a simple perl-based parser
that can translate syntactically invalid inputs and source file fragments,
but may not recognize complex C++ constructs.

Hipify is often used by developers porting existing CUDA-based libraries
to the ROCm platform. Additionally, the hipify-perl tool is sometimes
used at build-time by projects that were written in CUDA to convert to
HIP at the last minute when targeting AMD GPUs. For example, the rccl
library introduced a build dependency on hipify-perl in ROCm 5.5. A
hipify-perl package is needed to update the Debian rccl package to the
most recent upstream release.

This package is part of AMD's ROCm stack and will be maintained under the
Debian AI team umbrella.

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Aurelien Jarno]

Hi Helmut,

I finally got time to look at your patch and do very basic testing of
it. Overall it looks good, I have a few points or questions.

On 2024-02-04 21:20, Helmut Grohne wrote:
> So here is an updated patch with a few notes:
>  * This patch moves all the files including the runtime dynamic linker
>in the main multiarch library. Therefore, this patch needs to be
>synced with the corresponding base-files change to add the aliasing
>symlinks or debootstrap breaks. In other words: Don't upload this
>yet.

Ok.

>  * As mentioned earlier, only the multiarch packages install the runtime
>dynamic linker via data.tar. All the multilib packages install it via
>maintainer scripts now.
>  * When installing libc6-x32, /libx32 will be created because partial
>upgrades might otherwise be broken. Removing libc6-x32 will not
>remove /libx32 though. I suggest fixing this in base-files by
>installing a trigger interest in /usr/libx32 and having
>base-files.postinst create/remove /libx32 as needed. This way, we
>centralize the management of aliasing links into base-files. libx32
>only serves as an example here and it works the same way for any
>other non-essential multilib directory. Do you agree with the
>approach?

It sounds good yes. I never liked the fact the fact that the top level
symlinks like libx32 have to be handled by libc6. I explained that
clearly in #926699, and even suggested to do that in base-files, however
I didn't get the clever idea to use triggers. I got pressure from a
member of the TC to be constructive and given I didn't have a patch to
provide, I had to accept getting it managed by glibc...

>  * The multilib packages install a trigger interest on the runtime
>dynamic linker such that they notice when a multiarch package deletes
>it and can then recreate it as needed. Thus the multiarch packages do
>not have to pay attention to a possibly installed multilib package
>when they are removed.

Does it means we can just remove the Replaces: in the multiarch and
multilib libc? It should not be necessary anymore, even if without file
conflicts, they should not be an issue. However not sure what could
happen during the upgrade between the old and new packages.

>  * I've tried quite a few multiarch upgrades involving amd64 and i386
>using dpkg --auto-deconfigure --unpack with various packages and even
>cross grading libc6-x32 from :i386 to :amd64 during the upgrade.
>While dpkg --verify was occasionally unhappy during a partial upgrade
>(where half-unpacked packages were around), once no package was
>half-installed, dpkg --verify was also happy again in all attempts. I
>did not come up with a systematic enumeration of possible upgrade
>scenarios though.

Great.

>  * The patch works will deboostrap/cdebootstrap/mmdebstrap (in
>combination with more patches including base-files, bash, dash and
>util-linux).

Ok

>  * The change to install ldconfig to /usr/sbin can be uploaded right
>away. It's limited to debian/debhelper.in/libc-bin.install and
>debian/debhelper.in/libc-bin.lintian-overrides and doesn't contribute
>much diff, so doing it later is fine as well.

Ok noted. The idea was to get the 2.38 into testing, but the glibc
transition is currently blocked by the time_t transition, so the
development is currently stalled, and I am not sure when we'll do an
upload.

I also noticed that you clearly marked the code that can be removed only
after "released:forky", thanks for doing so. Do you really mean after
forky is released, so in the development cycle of forky+1? Or do you
mean for the release of forky, so in the development cycle of forky?

Cheers
Aurelien

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

Bug#1063740: lxqt-archiver: Can't create .zip archive. "Failed to execute command." and "Archive not found" errors

[Sudip Mukherjee]

Source: lxqt-archiver
Version: 0.7.0-3
Severity: important
Tags: upstream
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Dear Maintainer,

lxqt-archiver depends on p7zip-full which now is a transitional package and
installs 7zip. Creating zip files with lxqt-archiver is now using 7z and the
option '-l' is invalid with 7z. As a result it fails to create zip files.

Upstream issue: https://github.com/lxqt/lxqt-archiver/issues/379


-- 
Regards
Sudip

Bug#1063739: mariadb: FTBFS on hurd-i386: OS_DATA_FILE_NO_O_DIRECT was not declared in this scope

[otto]

Source: mariadb
Version: 1:10.11.7-1
Tags: confirmed, help, ftbfs
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

The builds of MariaDB currently fail with:

[ 51%] Building CXX object 
extra/mariabackup/CMakeFiles/mariadb-backup.dir/xtrabackup.cc.o
cd /<>/builddir/extra/mariabackup && /usr/bin/c++ -DBTR_CUR_ADAPT 
-DBTR_CUR_HASH_ADAPT -DHAVE_CONFIG_H -DHAVE_SYSTEM_REGEX -DPCRE_STATIC=1 
-D_FILE_OFFSET_BITS=64 -Dmariadb_backup_EXPORTS 
-I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 
-I/<>/builddir/include -I/<>/include/providers 
-I/<>/storage/innobase/include 
-I/<>/storage/innobase/handler 
-I/<>/libbinlogevents/include -I/<>/tpool 
-I/<>/include -I/<>/sql 
-I/<>/extra/mariabackup/quicklz 
-I/<>/extra/mariabackup -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time 
-D_FORTIFY_SOURCE=2 -pie -fPIC -fstack-protector --param=ssp-buffer-size=4 
-Wconversion -Wno-sign-conversion -O2 -g -static-libgcc -fno-omit-frame-pointer 
-fno-strict-aliasing -Wno-uninitialized -fno-omit-frame-
 pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wenum-compare -Wenum-conversion 
-Wextra -Wformat-security -Wmissing-braces -Wno-format-truncation 
-Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual 
-Wnon-virtual-dtor -Wvla -Wwrite-strings -std=gnu++11   -Wdate-time 
-D_FORTIFY_SOURCE=2 -DHAVE_OPENSSL -DOPENSSL_API_COMPAT=0x1010L 
-UMYSQL_SERVER -DHAVE_OPENSSL -DOPENSSL_API_COMPAT=0x1010L -MD -MT 
extra/mariabackup/CMakeFiles/mariadb-backup.dir/xtrabackup.cc.o -MF 
CMakeFiles/mariadb-backup.dir/xtrabackup.cc.o.d -o 
CMakeFiles/mariadb-backup.dir/xtrabackup.cc.o -c 
/<>/extra/mariabackup/xtrabackup.cc
/<>/extra/mariabackup/xtrabackup.cc: In function ‘bool 
innodb_init()’:
/<>/extra/mariabackup/xtrabackup.cc:2431:39: error: 
‘OS_DATA_FILE_NO_O_DIRECT’ was not declared in this scope
 2431 |   OS_DATA_FILE_NO_O_DIRECT, false, 
);
  |   ^~~~


See full log at 
https://buildd.debian.org/status/fetch.php?pkg=mariadb=hurd-i386=1%3A10.11.7-1=1707571681=0

Previously build was failing on Bug#1006531, but it was fixed in previous 
upload, so we have not gotten in the build this far ever before and thus 
discovered this for the first time.

Bug#1063738: mariadb: FTBFS on armel, armhf, powerpc, x32, hppa: size of array compile_time_assert is negative

[otto]

Source: mariadb
Version: 1:10.11.7-1
Forwarded: https://jira.mariadb.org/browse/MDEV-33429
Tags: confirmed, help, ftbfs
User: debian-...@lists.debian.org
Usertags: armel, armhf
X-Debbugs-CC: debian-...@lists.debian.org
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-CC: debian-powe...@lists.debian.org

After uploading latest MariaDB 10.11.7 to Debian it was noticed that the builds 
on armel, armhf, powerpc, x32, hppa fail on:

[ 31%] Building C object tests/CMakeFiles/bug25714.dir/bug25714.c.o
cd /<>/builddir/tests && /usr/bin/cc -DHAVE_CONFIG_H 
-DMYSQL_CLIENT -D_FILE_OFFSET_BITS=64 -I/<>/libmariadb/include 
-I/<>/builddir/libmariadb/include 
-I/<>/wsrep-lib/include -I/<>/wsrep-lib/wsrep-API/v26 
-I/<>/builddir/include -I/<>/include/providers 
-I/<>/include -I/<>/client -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -pie -fPIC 
-fstack-protector --param=ssp-buffer-size=4 -O2 -g -static-libgcc 
-fno-omit-frame-pointer -fno-strict-aliasing  -Wno-uninitialized 
-fno-omit-frame-pointer -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall 
-Wdeclaration-after-statement -Wenum-compare -Wenum-conversion -Wextra 
-Wformat-security -Wmissing-braces -Wno-format-truncation -Wno-init-self 
-Wno-nonnull-compare -Wno-unused-parameter -Wvla -Wwrite-strings 
 -std=gnu99   -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MT 
tests/CMakeFiles/bug25714.dir/bug25714.c.o -MF 
CMakeFiles/bug25714.dir/bug25714.c.o.d -o CMakeFiles/bug25714.dir/bug25714.c.o 
-c /<>/tests/bug25714.c
In file included from /<>/tests/mysql_client_fw.c:16,
 from /<>/tests/mysql_client_test.c:38:
/<>/tests/mysql_client_fw.c: In function ‘main’:
/<>/include/my_global.h:384:18: error:
  384 | typedef char compile_time_assert[(X) ? 1 : -1] 
__attribute__((unused)); \
  |  ^~~
/<>/tests/mysql_client_fw.c:1438:3: note: in expansion of macro 
‘compile_time_assert’
 1438 |   compile_time_assert(sizeof(MYSQL) == 77*sizeof(void*)+656);
  |   ^~~

See 
https://buildd.debian.org/status/fetch.php?pkg=mariadb=armel=1%3A10.11.7-1=1707544526=0
 and 
https://buildd.debian.org/status/fetch.php?pkg=mariadb=armhf=1%3A10.11.7-1=1707545871=0
 for full log. I was able to reproduce this on Launchpad.net armhf builder as 
well, both on Noble and Mantic, so it looks like a regression in MariaDB itself 
and not in any Debian dependency. These are all 32-bit systems, so it can be 
related to potential time_t changes in MariaDB.

This has been reported upstream in https://jira.mariadb.org/browse/MDEV-33429

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Andreas Beckmann]

On 11/02/2024 23.13, Jonathan Wiltshire wrote:

Yes, I've been watching the trickle of bugs being merged. As soon as
Andreas has chance to upload I'll get it out via stable-updates and an SUA
issued.


src:nvidia-graphics-drivers is already in stable-NEW due to 
nvidia-suspend-common.


We need to push 4 packages together to stable-updates:
nvidia-graphics-drivers
nvidia-settings
nvidia-graphics-drivers-tesla-470
nvidia-graphics-drivers-tesla


Andreas

Bug#1063733: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done

[Sven Joachim]

On 2024-02-11 22:10 +0100, Rene Engelhard wrote:

> Source: gpgme1.0
> Version: 1.18.0-4.1~exp1
> Severity: important
>
> [ let's no get into a discussion on  the sense of this transition. I
> actually believe this isn't needed and we can leave 32 bit die in 2038
> but anyways...
>
> The transition is ongoing now in experimental. So be it ]
>
>
> Hi,
>
>
> I just tried a rebuild of libreoffice with
> DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens.
>
> It failed in a certificate unit tests so I tried to rebuild the
> "certificate" related (build-)dependencies also with
> DEB_HOST_MAINT_OPTIONS="abi=+time64"

The correct variable is DEB_BUILD_MAINT_OPTIONS, as you have already
noticed.

> While doing so I noticed that gpgme1.0 doesn't define -D_TIME_BITS=64
> even when built for t64 (as in the experimental NMU renaming to t64)
> on the affected architectures (anything 32-bit except i386).
>
> This is probably because it doesn't honout dpkg-buildflags.

No, this is because debian/rules already sets DEB_BUILD_MAINT_OPTIONS,
overriding the value from the environment.  Either add abi=+time64 there
or set DEB_BUILD_OPTIONS rather than DEB_BUILD_MAINT_OPTIONS in the
environment.

I don't think there is a bug here.

Cheers,
   Sven

Bug#1063737: bookworm-pu: package nvidia-graphics-drivers-tesla-470/470.223.02-4~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
1) A backported (by upstream) change in Linux 6.1.76 (included in
today's point release) broke compilation of the non-free nvidia kernel
module. A patched version of the driver is available in sid.

2) After merging src:nvidia-graphics-drivers-tesla into
src:nvidia-graphics-drivers (PU request for src:nvidia-graphics-drivers
is already approved), the nvidia-cuda-mps package will be built from
src:nvidia-graphics-drivers, so stop building it here.

[ Impact ]
Users are unable to use Tesla 470 variant of the non-free nvidia module.

[ Tests ]
Only module building can be (and has been) tested. Everything else
requires use of nvidia hardware and the driver.

[ Risks ]
Rebuilding nvidia driver packages from sid for stable is an established
practice.

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

[ Changes ]
nvidia-graphics-drivers-tesla-470 (470.223.02-4~deb12u1) bookworm; 
urgency=medium

  * Rebuild for bookworm.

 -- Andreas Beckmann   Sun, 11 Feb 2024 22:11:51 +0100

nvidia-graphics-drivers-tesla-470 (470.223.02-4) unstable; urgency=medium

  * Apply pfn_valid patch from gentoo to fix kernel module build for
Linux 6.1.76, 6.6.15, 6.7.3, 6.8.  (Closes: #1063361)
  * Update lintian overrides.

 -- Andreas Beckmann   Thu, 08 Feb 2024 14:23:21 +0100

nvidia-graphics-drivers-tesla-470 (470.223.02-3) unstable; urgency=medium

  * nvidia-cuda-mps is again built from src:nvidia-graphics-drivers.

 -- Andreas Beckmann   Thu, 25 Jan 2024 19:48:07 +0100

nvidia-graphics-drivers-tesla-470 (470.223.02-2~deb11u1) bullseye; 
urgency=medium

  * Rebuild for bullseye.

 -- Andreas Beckmann   Sun, 03 Dec 2023 13:31:00 +0100

 debian/README.source   |  61 ++-
 debian/bug-control.mk  |   4 +-
 debian/changelog   |  59 ++-
 debian/control |  17 -
 debian/control.in  |   7 +-
 debian/control.md5sum  |   8 +-
 debian/copyright   |   7 +-
 debian/detect/nvidia-418.ids   | 304 --
 debian/detect/nvidia-470.ids   | 439 -
 debian/detect/nvidia-detect.in |  92 ++---
 debian/libnvidia-eglcore.lintian-overrides.in  |   1 +
 debian/libnvidia-glcore.lintian-overrides.in   |   1 +
 debian/module/debian/patches/0034-fix-typos.patch  |  48 +++
 ...35-fix-build-w-kernel-6.1.76-6.6.15-6.7.3.patch |  99 +
 debian/module/debian/patches/series.in |   2 +
 debian/not-installed.in|   5 +
 debian/nvidia-detect.install   |   4 +-
 debian/nvidia.NEWS |   9 +
 debian/po/ro.po|  81 
 debian/rules   |  11 +-
 debian/rules.defs  |   9 +-
 debian/tests/control   |   8 +
 debian/tests/control.in|   8 +
 debian/watch   |   4 +-
 debian/watch.in|   4 +-
 25 files changed, 387 insertions(+), 905 deletions(-)

- The nvidia-detect changes are irrelevant here since nvidia-detect is
  not built from this source package. They are present anyway since I'm
  keeping all the nvidia driver packaging branches in sync to minimize
  the difference between them.
- unifying src:nvidia-graphics-drivers and
  src:nvidia-graphics-drivers-tesla brought some changelog
  synchronization changes as well as packaging synchronization bits

[ Other info ]
This package too should be made available quickly since several users
are affected.
stable-updates might be a good idea (once all 4 packages are available
in stable-pu: nvidia-graphics-drivers, nvidia-settings,
nvidia-graphics-drivers-tesla, nvidia-graphics-drivers-tesla-470).


Andreas


ngd-tesla-470-470.223.02-4~deb12u1.diff.xz
Description: application/xz

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Jonathan Wiltshire]

On Sun, Feb 11, 2024 at 09:36:02PM +0100, Salvatore Bonaccorso wrote:
> If I can add a comment: I (but note I'm not wearing a
> nvidia-graphics-drivers maintainer hat) would support that, as there
> are enough people affected by this. This is quite unfortunate and I'm
> open to hear ideas how we can try to avoid such fallouts.

Yes, I've been watching the trickle of bugs being merged. As soon as
Andreas has chance to upload I'll get it out via stable-updates and an SUA
issued.

Thanks,

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

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

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Aurelien Jarno]

Hi Helmut,

On 2024-02-05 07:44, Helmut Grohne wrote:
> Hi Aurelien,
>
> So this confirms your initial suspicion on the actually affected case.
> Thank you.
> 
> c-t-b has repacking code with arch-specific mangling (of slibdir)
> already.
> https://sources.debian.org/src/cross-toolchain-base/68/debian/rules/#L563
> Adding to that wouldn't be the worst. A relatively easy measure would be
> running the libc-alt.postinst manually with DPKG_ROOT set to have it
> create the symlink that way. Do you think this is too much of a hack?

That's indeed an option, with the hope that we do not add more
incompatible things to that file at a later point.

However it's probably the best to ask Matthias as the maintainer of
c-t-b. If doing that way the uploads need to be synchronized to not
break c-t-b.

Cheers
Aurelien

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

Bug#1063733: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done

[Rene Engelhard]

Hi,

Am 11.02.24 um 22:10 schrieb Rene Engelhard:
I just tried a rebuild of libreoffice with 
DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens.


DEB_BUILD_MAINT_OPTIONS of course. I set the correct one (and 
libreoffice and xmlsec1 did pick it up) but just "thinkoed" it when 
reporting the bug.


Regards,

Rene

Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

[Benjamin Kaduk]

On Sat, Feb 10, 2024 at 01:33:15PM +0100, Johannes Schauer Marin Rodrigues 
wrote:
> 
> there as a binNMU "Rebuild to sync binNMU versions" for krb5 and that
> failed for arm64, armel and ppc64el:
> 
> https://buildd.debian.org/status/package.php?p=krb5
> 
> The error logs look very similar:
> *** Output of last command:
> Can't resolve hostname arm-conova-03

This is due more to the build environment than the test suite per se.  I am
pretty sure that there was a previous discussion of this but I could not
construct a search query to find it quickly (maybe Sam can do better than
me?).

In short, the test suite, as for the protocol itself, assumes that it can
resolve the server's hostname to an IP address; for the test suite the
server will be the local machine, and so this becomes an assumption that
what the "machine" (or container/etc.) thinks its hostname is will resolve
with the resolver on that machine.  In this case it looks like a bare name
(without domain) that is not localhost, and presumably a local resolver
with no search path set.

I do not remember whether the previous discussion reached a firm conclusion
about what can reasonably be expected from a build/test environment in this
regard.

-Ben

Bug#1063736: RM: snort -- RoQA; security issues, unmaintained

[Jonathan Wiltshire]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: rm

Requested by security team. Not in stable or testing.

Bug#1063735: python-maturin - upcoming rust-indexmap update.

[Peter Michael Green]

Package: python-maturin

Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14.x
and version 2.x.x respectively. The new versions are currently
available in experimental.

Currently the debian dependency on rust-indexmap
has no upper limit, but the cargo dependency does have
an upper limit.

python-maturin upstream did not make any code changes
when bumping the dependency to 2.x and after removing
the upper limit I was able to build python-maturin
successfully against the new indexmap.

A debdiff is attatched which removes the upper limit
diff -Nru python-maturin-1.3.2/debian/changelog 
python-maturin-1.3.2/debian/changelog
--- python-maturin-1.3.2/debian/changelog   2024-01-21 00:21:43.0 
+
+++ python-maturin-1.3.2/debian/changelog   2024-02-11 03:59:53.0 
+
@@ -1,3 +1,10 @@
+python-maturin (1.3.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax cargo dependency on indexmap.
+
+ -- Peter Michael Green   Sun, 11 Feb 2024 03:59:53 +
+
 python-maturin (1.3.2-1) unstable; urgency=medium
 
   [ Andreas Tille ]
diff -Nru python-maturin-1.3.2/debian/patches/relax-rust-indexmap 
python-maturin-1.3.2/debian/patches/relax-rust-indexmap
--- python-maturin-1.3.2/debian/patches/relax-rust-indexmap 1970-01-01 
00:00:00.0 +
+++ python-maturin-1.3.2/debian/patches/relax-rust-indexmap 2024-02-11 
03:59:33.0 +
@@ -0,0 +1,13 @@
+Index: python-maturin-1.3.2/Cargo.toml
+===
+--- python-maturin-1.3.2.orig/Cargo.toml
 python-maturin-1.3.2/Cargo.toml
+@@ -61,7 +61,7 @@ once_cell = "1.7.2"
+ rustc_version = "0.4.0"
+ semver = "1.0.13"
+ target-lexicon = "0.12.8"
+-indexmap = "1.9.3"
++indexmap = ">= 1.9.3"
+ pyproject-toml = "0.7.0"
+ python-pkginfo = "0.5.5"
+ textwrap = "0.16.0"
diff -Nru python-maturin-1.3.2/debian/patches/series 
python-maturin-1.3.2/debian/patches/series
--- python-maturin-1.3.2/debian/patches/series  2024-01-21 00:21:43.0 
+
+++ python-maturin-1.3.2/debian/patches/series  2024-02-11 03:59:15.0 
+
@@ -18,3 +18,4 @@
 relax-pyproject-toml
 relax-python-pkginfo
 relax-tracing-subscriber
+relax-rust-indexmap

Bug#1063685: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#1063685: fixed in precious 0.6.0-4)

[Peter Michael Green]

reopen 1063685
thanks

On 11/02/2024 18:27, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the precious package:

#1063685: precious - upcoming rust-indexmap update.

It has been closed by Debian FTP Masters  (reply to 
Jonas Smedegaard ).
building the new version of precious with the indexmap from experimental 
results in


error: failed to select a version for the requirement `indexmap = 
">=1.9.3, <=2.0.2"`

candidate versions found which didn't match: 2.2.2

Please change the upper limit on the cargo dependency to either < 3 or <= 2.
(personally I think the former is less confusing).

Bug#1063733: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done

[Rene Engelhard]

Source: gpgme1.0
Version: 1.18.0-4.1~exp1
Severity: important

[ let's no get into a discussion on  the sense of this transition. I 
actually believe this isn't needed and we can leave 32 bit die in 2038 
but anyways...


The transition is ongoing now in experimental. So be it ]


Hi,


I just tried a rebuild of libreoffice with 
DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens.


It failed in a certificate unit tests so I tried to rebuild the 
"certificate" related (build-)dependencies also with 
DEB_HOST_MAINT_OPTIONS="abi=+time64"



While doing so I noticed that gpgme1.0 doesn't define -D_TIME_BITS=64 
even when built for t64 (as in the experimental NMU renaming to t64) on 
the affected architectures (anything 32-bit except i386).


This is probably because it doesn't honout dpkg-buildflags.

But even if you don't like dpkg-buildflags that define has to be done.

Regards,

Rene

P.S::
Thankfully libreoffice is fine without a rebuilt gpgme1.0 somehow

Bug#1063734: no -D_TIME_BITS=64 on builds where t64 support is supposed to be done

[Rene Engelhard]

Source: gnutls28
Version: 3.8.3-1.1~exp1
Severity: important

[ let's no get into a discussion on  the sense of this transition. I 
actually believe this isn't needed and we can leave 32 bit die in 2038 
but anyways...


The transition is ongoing now in experimental. So be it ]

Hi,

I just tried a rebuild of libreoffice with 
DEB_HOST_MAINT_OPTIONS="abi=+time64" to actually see what happens.


It failed in a certificate unit tests so I tried to rebuild the 
"certificate" related (build-)dependencies also with 
DEB_HOST_MAINT_OPTIONS="abi=+time64"


While doing so I noticed that gnutls28 doesn't define -D_TIME_BITS=64 
even when built for t64 (as in the experimental NMU renaming to t64) on 
the affected architectures (anything 32-bit except i386).


This is probably because it doesn't honout dpkg-buildflags.

But even if you don't like dpkg-buildflags that define has to be done.

Regards,

Rene

P.S::
Thankfully libreoffice is fine with just xmlsec1 being rebuilt. But it 
uses the nss flabour, so stuff using gnutls might break, no idea

Bug#916795: [live-build] Can't skip keyboard selection of the installer

[otyugh]

Hey, 6 years past, on bullseye this time, and the same bug remain.

No way to preseed the keyboard selection, only way I found is to skip it 
using "keymap=fr". Doing so will also skip any keyboard selection. So I 
needed to set it manually after the installation was done using 
localectl. It didn't work. it didn't work because 
*/etc/X11/xorg.conf.d/00-keyboard.conf* was set and kept overwriting any 
change from localectl.


When I asked around me, nobody heard of it. Removing that file makes 
localectl efficient again.


Story (in french) about me being very slow at finding out here 
https://debian-facile.org/viewtopic.php?pid=410530

Bug#1063732: hurd-i386 twice in java_unsupported_architectures

[Rene Engelhard]

Package: java-common
Version: 0.75
Severity: minor

Hi,

$ grep java_unsupported_architectures /usr/share/java/java_defaults.mk
java_unsupported_architectures = hppa hurd-i386 kfreebsd-amd64 
kfreebsd-i386 hurd-i386 powerpcspe s390 sparc

[...]

hurd-i386 is here twice.

Regards,

Rene

Bug#1063716: Update fix

[Ceppo]

In the update I sent I forgot to fix a typo. Here's the fixed version.


--
Ceppo
# kwartz-client po-debconf italian translation.
# Copyright (C) 2022, 2024 kwartz-client's copyright holder
# This file is distributed under the same license as the kwartz-client package.
# Ceppo , 2022, 2024.
#
msgid ""
msgstr ""
"Project-Id-Version: kwartz-client\n"
"Report-Msgid-Bugs-To: kwartz-cli...@packages.debian.org\n"
"POT-Creation-Date: 2024-01-28 22:56+0100\n"
"PO-Revision-Date: 2024-02-04 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid "IP address of the proxy service:"
msgstr "Indirizzo IP del servizio proxy:"

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid ""
"Please enter the address of the proxy service. It is ususally the same as "
"the address of the Kwartz server. If unsure, keep the default value."
msgstr ""
"Inserire l'indirizzo IP del servizio proxy. Di solito è lo stesso indirizzo "
"del server Kwartz. In caso di incertezza, lasciare il valore predefinito."

#. Type: string
#. Description
#: ../kwartz-client.templates:2001
msgid "Port number of the proxy service:"
msgstr "Numero della porta del servizio proxy:"

#. Type: string
#. Description
#: ../kwartz-client.templates:2001
msgid ""
"Please enter the port number of the proxy service. The default value is "
"usually safe."
msgstr ""
"Inserire il numero della porta del servizio proxy. Di solito il valore "
"predefinito è adeguato."

#. Type: string
#. Description
#: ../kwartz-client.templates:3001
msgid "List of IP addresses not concerned by the proxy service:"
msgstr "Elenco degli indirizzi IP non interessati dal servizio proxy:"

#. Type: string
#. Description
#: ../kwartz-client.templates:3001
msgid ""
"Please enter the IP addresses and ranges which must be fetched without the "
"help of the proxy. If unsure, keep the default list."
msgstr ""
"Inserire gli indirizzi e intervalli IP che devono essere recuperati senza "
"l'aiuto del proxy. In caso di incertezza, lasciare l'elenco predefinito."

#. Type: string
#. Description
#: ../kwartz-client.templates:4001
msgid "Landing page URL for the browser:"
msgstr "URL della pagina iniziale per il browser:"

#. Type: string
#. Description
#: ../kwartz-client.templates:4001
msgid ""
"Please choose the URL of a landing page for the browser. This web page will "
"appear each time the browser is launched. If unsure, keep the default URL."
msgstr ""
"Scegliere l'URL della pagina iniziale per il browser. Questa pagina web "
"comparirà ogni volta che il browser viene lanciato. In caso di incertezza, "
"lasciare l'URL predefinito."

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "Halt the client computer every night:"
msgstr "Arrestare il computer client ogni notte:"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "- 0: no, the computer will not be halted automatically"
msgstr "- 0: no, il computer non verrà arrestato automaticamente"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "- 1: yes, the computer will be halted at 19:00"
msgstr "- 1: sì, il computer verrà arrestato alle 19:00"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "- 2: yes, the computer will be halted at 20:00"
msgstr "- 2: sì, il computer sarà arrestato alle 20:00"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "- 3: yes, the computer will be halted at 22:00"
msgstr "- 3: sì, il computer sarà arrestato alle 22:00"

#. Type: string
#. Description
#: ../kwartz-client.templates:6001
msgid "An unpriviledged user to access the web:"
msgstr "Un utente senza privilegi per accedere al web:"

#. Type: string
#. Description
#: ../kwartz-client.templates:6001
msgid ""
"When APT will run some automatic update for the package database, a user "
"name is needed to use the proxy service. This user must be unpriviledged."
msgstr ""
"Quando APT eseguirà alcuni aggiornamenti automatici al database dei "
"pacchetti, sarà necessario un nome utente per accedere al servizio proxy. "
"Questo utente non deve avere privilegi."

#. Type: password
#. Description
#: ../kwartz-client.templates:7001
msgid "Password to access the web:"
msgstr "Password per accedere al web:"

#. Type: password
#. Description
#: ../kwartz-client.templates:7001
msgid ""
"The unpriviledged user which will be used by APT to access the web needs a "
"password. It must be some strong password."
msgstr ""
"L'utente senza privilegi che sarà usato da APT per accedere al web necessita "
"di una password. Deve essere una password sicura."

#. Type: string
#. Description
#: ../kwartz-client.templates:8001
msgid "Network name of the Kwartz server:"
msgstr "Il nome di rete del server Kwartz:"

#. Type: string
#. Description
#: 

Bug#1063730: [Bug #1063730] Clarify that latest master branch code works

[Chad Phillips]

Note that I built a custom lua-sql-odbc Debian package by simply
substituting the latest src code on the master branch at
https://github.com/lunarmodules/luasql in place of the current src code at
https://salsa.debian.org/lua-team/lua-sql, and it does in fact resolve the
reported issue.

Bug#1063029: reopening

[Matthias Klose]

Control: reopen -1

python3-tzlocal was added as a suggestion, not a dependency.

Bug#1063542: python-parsl-doc: please make the build reproducible

[Étienne Mollier]

James Addison, on 2024-02-10:
> I'll also forward the same change to upstream, in the hope that we may
> be able to drop the patch from the packaging in future.

That would be useful.  Patch rebase tends to cause quite some
friction on the long run with newer upstream versions.  It
shouldn't hurt informing upstream of the availability of the
change, in case they are sensible to build reproducibility
issue.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-


signature.asc
Description: PGP signature

Bug#1063675: bookworm-pu: package nvidia-graphics-drivers/525.147.05-6~deb12u1

[Salvatore Bonaccorso]

Hi Jonathan,

On Sun, Feb 11, 2024 at 12:29:45AM +, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Sat, Feb 10, 2024 at 11:00:58PM +0100, Andreas Beckmann wrote:
> > [ Reason ]
> > 1) A backported (by upstream) change in Linux 6.1.76 (included in
> > today's point release) broke compilation of the non-free nvidia kernel
> > module. A patched version of the driver is available in sid.
> > 
> > 2) In order to simplify future maintenance of the many Nvidia driver
> > packages (also in stable and oldstable) I'm going to remove the
> > distinction between "normal" and "Tesla" drivers (they were at the
> > same version in stable anyway). The Tesla specific bits
> > (src:nvidia-graphics-drivers-tesla) will be merged into
> > src:nvidia-graphics-drivers (that mainly means addition of the ppc64el
> > architecture to these packages, and building some binary packages from
> > src:nvidia-graphics-drivers instead: nvidia-powerd, nvidia-cuda-mps).
> > nvidia-detect has been updated, too, as it no longer needs to
> > distinguish the Tesla variants.
> > There will be one further update to src:nvidia-graphics-drivers-tesla
> > in stable that turns these packages into transitional packages depending
> > on their counterparts from src:nvidia-graphics-drivers. (Separate PU
> > request upcoming.)
> > There will also be a PU request for nvidia-settings, as we need to
> > enable building that on ppc64el. (The src:nvidia-settings-tesla package
> > will then become obsolete.)
> > 
> > 3) In order to better integrate the nvidia driver with the system power
> > management, a new package nvidia-suspend-common is being introduced
> > which properly ships and enables some systemd units that were previously
> > only being shipped as examples. These power management changes are an
> > enhancement for the 525 series, but seem to be required in the 535
> > series. (We will have to switch to the 535 LTSB series in stable soon,
> > as 525 has reached EoL. 535 will be supported till mid 2026, so that will
> > be the last driver branch switch for bookworm.)
> > nvidia-suspend-common was already prepared in the previous pu update,
> > but not yet enabled on stable as it hadn't undergone enough testing. As
> > no new issues have popped up on sid, I'm confident to enable this in
> > stable now.
> 
> Please go ahead. Is this something we should release early through
> stable-updates, given the breakage is caused by a point release?

If I can add a comment: I (but note I'm not wearing a
nvidia-graphics-drivers maintainer hat) would support that, as there
are enough people affected by this. This is quite unfortunate and I'm
open to hear ideas how we can try to avoid such fallouts.

As you know we are strictly following upstream stable series (and
trying our best to keep an eye on as well regression reports upstream,
but OOT modules are not explicitly tested, so neither the nvidia ones)

Regards,
Salvatore

Bug#1063730: lua-sql-odbc Aborted on con:execute(sql) #135

[Chad Phillips]

Package: lua-sql-odbc
Version: 2.6.0-2

This bug is clearly described at
https://github.com/lunarmodules/luasql/issues/135

See this comment, where the maintainer reports the bug as fixed on the
master branch:
https://github.com/lunarmodules/luasql/issues/135#issuecomment-1397405029

However, the Debian package does not contain this fix.

This bug effectively makes the LuaSQL ODBC driver useless on Debian
Bookworm, as I encounter it when issuing any query that is not a SELECT.

I suspect part of the issue is that the last git tag, 2.6.0, was in Sept.
2020, and there have been quite a few commits to the project since then.

Bug#1063729: Kernel panic after update from Debian 12.4 to 12.5 in command line and reboot

[pham...@bluewin.ch]

Package: linux-image-6.1.0-18-amd64
Version: 6.1.76-1: amd64
Severity: critical

Bug Description:

Kernel panic after update from Debian 12.4 to 12.5 in command line and reboot.
Look "Kernel panic after update.txt" in attachment for details.
Look message booting display in attachment for more details.
Please correct this urgently !!!
Regards.

Philipperoot@station:~# apt update && apt dist-upgrade
Atteint :1 https://security.debian.org/debian-security bookworm-security 
InRelease
Atteint :2 http://ppa.launchpad.net/vincent-vandevyvre/vvv/ubuntu focal 
InRelease
Atteint :3 https://deb.debian.org/debian bookworm InRelease
Atteint :4 https://deb.debian.org/debian bookworm-updates InRelease
Atteint :5 https://deb.debian.org/debian-security bookworm-security InRelease
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait  
Tous les paquets sont à jour.
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait  
Calcul de la mise à jour... Fait
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
  linux-headers-6.1.0-16-common
Veuillez utiliser « apt autoremove » pour le supprimer.
Les paquets suivants seront ENLEVÉS :
  linux-headers-6.1.0-16-amd64 linux-image-6.1.0-16-amd64
0 mis à jour, 0 nouvellement installés, 2 à enlever et 0 non mis à jour.
4 partiellement installés ou enlevés.
Après cette opération, 412 Mo d'espace disque seront libérés.
Souhaitez-vous continuer ? [O/n] o
(Lecture de la base de données... 416726 fichiers et répertoires déjà installés.
)
Suppression de linux-headers-6.1.0-16-amd64 (6.1.67-1) ...
Suppression de linux-image-6.1.0-16-amd64 (6.1.67-1) ...
/etc/kernel/prerm.d/dkms:
dkms: removing: nvidia-current 525.147.05 (6.1.0-16-amd64) (x86_64)
Module nvidia-current-525.147.05 for kernel 6.1.0-16-amd64 (x86_64).
Before uninstall, this module version was ACTIVE on this kernel.

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

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

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

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

nvidia-current-peermem.ko:
 - Uninstallation
   - Deleting from: /lib/modules/6.1.0-16-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.
depmod...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.0-16-amd64
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.1.0-18-amd64
Found linux image: /boot/vmlinuz-6.1.0-17-amd64
Found initrd image: /boot/initrd.img-6.1.0-17-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot 
entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
Paramétrage de linux-image-6.1.0-18-amd64 (6.1.76-1) ...
I: /initrd.img is now a symlink to boot/initrd.img-6.1.0-18-amd64
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-18-amd64.
Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
env NV_VERBOSE=1 make -j32 modules KERNEL_UNAME=6.1.0-18-amd64(bad exit 
status: 2)
Error! Bad return status for module build on kernel: 6.1.0-18-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more informat
ion.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
dkms: autoinstall for kernel: 6.1.0-18-amd64 failed!
run-parts: /etc/kernel/postinst.d/dkms exited with return code 11
dpkg: erreur de traitement du paquet 

Bug#1063660: the amdgpu module is missing from the kernel

[Николай Сабельников]

so, I'm ready to test something, especially since I have btrfs snapshots 
configured.

11 февраля 2024 г. 22:21:23 GMT+03:00, Diederik de Haas  
пишет:
>Control: reassign -1 firmware-amd-graphics 20230210-5
>Control: retitle -1 firmware-amd-graphics: Please backport newer firmware to 
>Bookworm
>Control: tag -1 -moreinfo
>Control: severity -1 wishlist
>
>On Sunday, 11 February 2024 20:11:19 CET saber716rus wrote:
>> В Вс, 11/02/2024 в 19:48 +0100, Diederik de Haas пишет:
>> > Control: tag -1 moreinfo
>> > 
>> > On Saturday, 10 February 2024 17:41:43 CET Nikolay Sabelnikov wrote:
>> > > Package: linux-image-amd64
>> > > Version: 6.1.76-1
>> > > 
>> > > > update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64
>> > > > W: Possible missing firmware
>> > > > /lib/firmware/amdgpu/ip_discovery.bin for module amdgpu
>> > > > ...
>> > > > W: Possible missing firmware
>> > > > /lib/firmware/amdgpu/psp_13_0_11_ta.bin
>> > > > for module amdgpu
>> > 
>> > What I see in these messages that it's requesting new(er) *firmware*
>> > files, but the bug title implicates that there is a *kernel* module 
>> > missing.
>> > The latter would be very surprising and would make your/any graphics
>> > output on AMD GPUs not work.
>> > Can you confirm it's actually a firmware issue?
>> 
>> there are no errors in dmesg. and I don't see any graphical artifacts,
>> but the error about the lack of modules is very alarming to me.
>
>Apparently some new (AMD) kernel files have been backported to the 6.1 branch,
>which causes it to request firmware files which didn't exist when 6.1 was
>released. 
>I've reassigned and changed this bug report into a request for a backport of
>newer firmware files for Bookworm, although I'm not so sure that's a good idea.
>
>While it may look alarming, it's highly likely harmless. Just noisy.

Bug#1063728: keyboard-configuration: format of XKBOPTIONS not specified

[Michael Gold]

Package: keyboard-configuration
Version: 1.226
Severity: minor

Dear Maintainer,

/etc/default/keyboard refers to "the keyboard(5) manual page", which
says:
  XKBOPTIONS
Specifies the XKB keyboard option components. Options usually
relate to the behavior of the special keys (, ,
, , etc.) Default: not set.

This does not say how multiple options should be separated.  Luckily,
there are examples suggesting the value can be a comma-separated list
with no whitespace.

The actual expectations should be stated explicitly, and the same goes
for XKBVARIANT.

- Michael


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

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

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.85
ii  liblocale-gettext-perl  1.07-6+b1
ii  xkb-data2.41-1

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages console-setup depends on:
ii  console-setup-linux1.226
ii  debconf [debconf-2.0]  1.5.85
ii  xkb-data   2.41-1

Versions of packages console-setup suggests:
ii  locales2.37-15
ii  sysvinit-utils [lsb-base]  3.08-6

Versions of packages console-setup-linux depends on:
ii  init-system-helpers  1.66
ii  kbd  2.6.4-2

Versions of packages console-setup-linux suggests:
ii  console-setup  1.226

Versions of packages keyboard-configuration is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.6.4-2
ii  systemd   255.3-2

-- debconf information:
  keyboard-configuration/unsupported_options: true
  console-setup/fontsize-text47: 8x16
  console-setup/guess_font:
  console-setup/fontsize-fb47: 8x16
  console-setup/store_defaults_in_debconf_db: true
* keyboard-configuration/model: Generic 105-key PC
* keyboard-configuration/store_defaults_in_debconf_db: true
* keyboard-configuration/switch: No temporary switch
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/layout:
  console-setup/charmap47: UTF-8
* keyboard-configuration/compose: No compose key
  keyboard-configuration/unsupported_layout: true
  console-setup/use_system_font:
  console-setup/fontface47: Fixed
  console-setup/framebuffer_only:
* keyboard-configuration/layoutcode: us
* keyboard-configuration/toggle: No toggling
* keyboard-configuration/xkb-keymap: us(dvorak)
* keyboard-configuration/altgr: The default for the keyboard layout
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
  console-setup/codesetcode: Lat15
* keyboard-configuration/other:
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/variantcode: dvorak
* keyboard-configuration/modelcode: pc105
* keyboard-configuration/variant: English (US) - English (Dvorak)
  console-setup/fontsize: 8x16
  keyboard-configuration/ctrl_alt_bksp: false
* keyboard-configuration/optionscode: ctrl:swapcaps
  keyboard-configuration/unsupported_config_options: true


signature.asc
Description: PGP signature

Bug#1061256: edk2: CVE-2023-45229 CVE-2023-45230 CVE-2023-45231 CVE-2023-45232 CVE-2023-45233 CVE-2023-45234 CVE-2023-45235 CVE-2023-45236 CVE-2023-45237

[Salvatore Bonaccorso]

Control: clone 1061256 -1 -2
Control: retitle 1061256 edk2: CVE-2023-45229 CVE-2023-45230 CVE-2023-45231 
CVE-2023-45232 CVE-2023-45233 CVE-2023-45234 CVE-2023-45235
Conytol: retitle -1 edk2: CVE-2023-45236
Control: retitle -2 edk2: CVE-2023-45237
Control: fixed 1061256 2023.11-6

Hi Dann,

On Sat, Feb 10, 2024 at 01:11:47PM -0700, dann frazier wrote:
> Thanks Salvatore.
> 
> The first 7 are now fixed upstream, so I'm preparing an upload for
> those. Fixes for CVE-2023-45236 and CVE-2023-45237 are still in the
> works. Should we split those into separate bugs?

Yes, let's do this so we have proper tracking (doing two for each CVE
in case we run in same situation for those and they are not fixed with
same upload).

Does this split look good to you?

Regards,
Salvatore

Bug#1062437: python-debian: When Files: is a whitespace-separated list, files are matched too eagerly

[Lasse Collin]

One way to fix it is to change buf.write('|') to buf.write('\Z|') in
globs_to_re in copyright.py line 485[1]. The comment at the end of the
method sounds like that the thinking had been that in 'foo|bar\Z' the
\Z would affect matching of foo but in reality only affects bar.

Other possibility is modifying matches(). In copyright.py line 758,
pat.match(filename) could be changed to pat.fullmatch(filename). Then
globs_to_re wouldn't need to add \Z even at the end.

[1]
https://salsa.debian.org/python-debian-team/python-debian/-/blob/e7990d2ab83057a2aaf7851f4250f1072f6fee8c/lib/debian/copyright.py#L485

[2]
https://salsa.debian.org/python-debian-team/python-debian/-/blob/master/src/debian/copyright.py#L758

-- 
Lasse Collin

Bug#1063660: the amdgpu module is missing from the kernel

[Diederik de Haas]

Control: reassign -1 firmware-amd-graphics 20230210-5
Control: retitle -1 firmware-amd-graphics: Please backport newer firmware to 
Bookworm
Control: tag -1 -moreinfo
Control: severity -1 wishlist

On Sunday, 11 February 2024 20:11:19 CET saber716rus wrote:
> В Вс, 11/02/2024 в 19:48 +0100, Diederik de Haas пишет:
> > Control: tag -1 moreinfo
> > 
> > On Saturday, 10 February 2024 17:41:43 CET Nikolay Sabelnikov wrote:
> > > Package: linux-image-amd64
> > > Version: 6.1.76-1
> > > 
> > > > update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64
> > > > W: Possible missing firmware
> > > > /lib/firmware/amdgpu/ip_discovery.bin for module amdgpu
> > > > ...
> > > > W: Possible missing firmware
> > > > /lib/firmware/amdgpu/psp_13_0_11_ta.bin
> > > > for module amdgpu
> > 
> > What I see in these messages that it's requesting new(er) *firmware*
> > files, but the bug title implicates that there is a *kernel* module missing.
> > The latter would be very surprising and would make your/any graphics
> > output on AMD GPUs not work.
> > Can you confirm it's actually a firmware issue?
> 
> there are no errors in dmesg. and I don't see any graphical artifacts,
> but the error about the lack of modules is very alarming to me.

Apparently some new (AMD) kernel files have been backported to the 6.1 branch,
which causes it to request firmware files which didn't exist when 6.1 was
released. 
I've reassigned and changed this bug report into a request for a backport of
newer firmware files for Bookworm, although I'm not so sure that's a good idea.

While it may look alarming, it's highly likely harmless. Just noisy.

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

Bug#1063725: xkb-data: keymap alias 'dvorak' no longer available

[Michael Gold]

Package: xkb-data
Version: 2.41-1

Dear Maintainer,

I noticed a "setxkbmap dvorak" command, run by my X session scripts,
starting giving an error with the latest xkb-data:
Error loading new keyboard description

It started after upgrading the following 4 packages together:
console-setup:amd64 (1.223, 1.226)
console-setup-linux:amd64 (1.223, 1.226)
xkb-data:amd64 (2.38-2, 2.41-1),
keyboard-configuration:amd64 (1.223, 1.226)
(The xkb-data changes look the most substantial, which is why I've filed
against that package.)

My keyboard layout was still as expected, but downgrading those packages
to the versions from 'testing' eliminated the error.

Here's the output of "setxkbmap -verbose 10 -print dvorak" with 2.38-2:
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:  evdev
model:  pc105
layout: dvorak
options:ctrl:swapcaps,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+us(dvorak)+inet(evdev)+ctrl(swapcaps)+compose(menu)
geometry:   pc(pc105)
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+us(dvorak)+inet(evdev)+ctrl(swapcaps)+compose(menu)"};
xkb_geometry  { include "pc(pc105)" };
};

And with 2.41-1:
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:  evdev
model:  pc105
layout: dvorak
options:ctrl:swapcaps,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+dvorak+inet(evdev)+ctrl(swapcaps)+compose(menu)
geometry:   pc(pc105)
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)" };
xkb_types { include "complete"  };
xkb_compat{ include "complete"  };
xkb_symbols   { include 
"pc+dvorak+inet(evdev)+ctrl(swapcaps)+compose(menu)"};
xkb_geometry  { include "pc(pc105)" };
};

The contents of /etc/default/keyboard:
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT="dvorak"
XKBOPTIONS="ctrl:swapcaps"

BACKSPACE="guess"

My X session was configured to run this command at startup:
setxkbmap -option 'ctrl:swapcaps' -option 'compose:menu' dvorak

After looking at the above output, I changed "dvorak" to "us(dvorak)" in
the command, and it worked without error.

It's not clear whether support for just "dvorak" was dropped on purpose,
but I don't recall seeing any deprecation warnings about it, and don't
see any relevant Debian changelog or "NEWS" entry.

- Michael


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

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

-- no debconf information


signature.asc
Description: PGP signature

Bug#1063724: postgresql-16-postgis-3-scripts: please make the extension template scripts build reproducibly.

[James Addison]

Package: postgresql-16-postgis-3-scripts
Version: 3.4.1+dfsg-1
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps

Dear Maintainer,

I'm an occasional volunteer with the Reproducible Builds[1] project, and
noticed recently that the postgresql-16-postgis-3-scripts package failed to
build reproducibly from source.

The problem seems to occur in some extension template .sql scripts, such as
the 'postgis--TEMPLATED--TO--ANY.sql' file, where the build host's current time
is embedded into a comment at build-time.

There is an existing 'POSTGIS_BUILD_DATE' defined[2] in the configure scripts
that already reads from the recommended SOURCE_DATE_EPOCH[3] environment
variable, and may be reusable here for consistency.

Note: to replicate the problem and/or confirm a fix, it's possible to to
enable the 'reprotest' feature of Salsa CI for the package.

Regards,
James

[1] - https://reproducible-builds.org/

[2] - https://sources.debian.org/src/postgis/3.4.2%2Bdfsg-1/configure.ac/#L1273

[3] - 
https://wiki.debian.org/ReproducibleBuilds/Howto#Files_in_data.tar_contain_timestamps

Bug#1063723: bullseye-pu: package pypdf2/1.26.0-4

[Scott Kitterman]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Fixes two no-DSA CVE issues.

[ Impact ]
Continued low level security risk.

[ Tests ]
None that are run in the Debian package or autopkgtest.

[ Risks ]
Risk is low.  Code changes are relatively simple and were provided by
upstream.  These same two patches were previously released for LTS with
no known issues.

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

[ Changes ]
  * Forward-port CVE fixes by LTS team
- CVE-2023-36810: Quadratic runtime with malformed PDF missing xref marker.
- Fix CVE-2022-24859:
Sebastian Krause discovered that manipulated inline images can force
PyPDF2, a pure Python PDF library, into an infinite loop, if a
maliciously crafted PDF file is processed.

[ Other info ]
This may show up as an NMU (lintian things so), but I'm the maintainer
now for Testing/Unstable.  I chose not to update the maintainer fields
in this update to keep it minimal to address the issues.

Scott K
diff -Nru pypdf2-1.26.0/debian/changelog pypdf2-1.26.0/debian/changelog
--- pypdf2-1.26.0/debian/changelog  2020-01-19 03:08:58.0 -0500
+++ pypdf2-1.26.0/debian/changelog  2024-02-11 13:50:22.0 -0500
@@ -1,3 +1,14 @@
+pypdf2 (1.26.0-4+deb11u1) bullseye; urgency=medium
+
+  * Forward-port CVE fixes by LTS team
+- CVE-2023-36810: Quadratic runtime with malformed PDF missing xref marker.
+- Fix CVE-2022-24859:
+Sebastian Krause discovered that manipulated inline images can force
+PyPDF2, a pure Python PDF library, into an infinite loop, if a
+maliciously crafted PDF file is processed.
+
+ -- Scott Kitterman   Sun, 11 Feb 2024 13:50:22 -0500
+
 pypdf2 (1.26.0-4) unstable; urgency=medium
 
   * Remove Python 2 from build dependencies (closes: #937505).
diff -Nru 
pypdf2-1.26.0/debian/patches/0001-MAINT-Quadratic-runtime-while-parsing-reduced-to-lin.patch
 
pypdf2-1.26.0/debian/patches/0001-MAINT-Quadratic-runtime-while-parsing-reduced-to-lin.patch
--- 
pypdf2-1.26.0/debian/patches/0001-MAINT-Quadratic-runtime-while-parsing-reduced-to-lin.patch
1969-12-31 19:00:00.0 -0500
+++ 
pypdf2-1.26.0/debian/patches/0001-MAINT-Quadratic-runtime-while-parsing-reduced-to-lin.patch
2024-02-11 13:49:50.0 -0500
@@ -0,0 +1,50 @@
+From 82ee233ea82a40c626e95a191fe2d52c745db870 Mon Sep 17 00:00:00 2001
+From: dsk7 
+Date: Sat, 23 Apr 2022 19:12:13 +0200
+Subject: MAINT: Quadratic runtime while parsing reduced to linear  (#808)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When the PdfFileReader tries to find the xref marker, the readNextEndLine 
methods builds a so called line by reading byte-for-byte. Every time a new byte 
is read, it is concatenated with the currently read line. This leads to 
quadratic runtime O(n²) behavior as Python strings (also byte-strings) are 
immutable and have to be copied where n is the size of the file.
+For files where the xref marker can not be found at the end this takes a 
enormous amount of time:
+
+* 1mb of zeros at the end: 45.54 seconds
+* 2mb of zeros at the end: 357.04 seconds
+(measured on a laptop made in 2015)
+
+This pull request changes the relevant section of the code to become linear 
runtime O(n), leading to a run time of less then a second for both cases 
mentioned above. Furthermore this PR adds a regression test.
+---
+ PyPDF2/pdf.py | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/PyPDF2/pdf.py b/PyPDF2/pdf.py
+index 9979414..8b355e0 100644
+--- a/PyPDF2/pdf.py
 b/PyPDF2/pdf.py
+@@ -1930,7 +1930,7 @@ class PdfFileReader(object):
+ def readNextEndLine(self, stream):
+ debug = False
+ if debug: print(">>readNextEndLine")
+-line = b_("")
++line_parts = []
+ while True:
+ # Prevent infinite loops in malformed PDFs
+ if stream.tell() == 0:
+@@ -1957,10 +1957,10 @@ class PdfFileReader(object):
+ break
+ else:
+ if debug: print("  x is neither")
+-line = x + line
+-if debug: print(("  RNEL line:", line))
++line_parts.append(x)
+ if debug: print("leaving RNEL")
+-return line
++line_parts.reverse()
++return b"".join(line_parts)
+ 
+ def decrypt(self, password):
+ """
+-- 
+2.30.2
+
diff -Nru pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch 
pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch
--- pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch   1969-12-31 
19:00:00.0 -0500
+++ pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch   2024-02-11 
13:49:50.0 -0500
@@ -0,0 +1,63 @@
+From: 

Bug#1063660: the amdgpu module is missing from the kernel

[saber716rus]

В Вс, 11/02/2024 в 19:48 +0100, Diederik de Haas пишет:
> Control: tag -1 moreinfo
> 
> On Saturday, 10 February 2024 17:41:43 CET Nikolay Sabelnikov wrote:
> > Package: linux-image-amd64
> > Version: 6.1.76-1
> > 
> > > update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64
> > > W: Possible missing firmware
> > > /lib/firmware/amdgpu/ip_discovery.bin for
> > > module amdgpu
> > > W: Possible missing firmware /lib/firmware/amdgpu/vega10_cap.bin
> > > for
> > > module amdgpu
> > > W: Possible missing firmware
> > > /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module amdgpu
> > > W: Possible missing firmware /lib/firmware/amdgpu/navi12_cap.bin
> > > for
> > > module amdgpu
> > > W: Possible missing firmware
> > > /lib/firmware/amdgpu/psp_13_0_11_ta.bin
> > > for module amdgpu
> 
> What I see in these messages that it's requesting new(er) *firmware*
> files, but 
> the bug title implicates that there is a *kernel* module missing.
> The latter would be very surprising and would make your/any graphics
> output on 
> AMD GPUs not work.
> Can you confirm it's actually a firmware issue?

there are no errors in dmesg. and I don't see any graphical artifacts,
but the error about the lack of modules is very alarming to me.
[0.077291] Spectre V2 : Enabling Speculation Barrier for firmware calls
[2.244591] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_sdma.bin
[2.245272] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_asd.bin
[2.245294] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_ta.bin
[2.245551] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_dmcub.bin
[2.245552] [drm] Loading DMUB firmware via PSP: version=0x01010026
[2.245577] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_pfp.bin
[2.245590] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_me.bin
[2.245602] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_ce.bin
[2.245622] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_rlc.bin
[2.245711] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_mec.bin
[2.246585] amdgpu :03:00.0: firmware: direct-loading firmware amdgpu/renoir_vcn.bin
[2.246586] [drm] Found VCN firmware Version ENC: 1.19 DEC: 5 VEP: 0 Revision: 0
[2.246591] amdgpu :03:00.0: amdgpu: Will use PSP to load VCN firmware
[4.719801] platform regulatory.0: firmware: direct-loading firmware regulatory.db
[4.719830] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s
[4.841334] rtw_8822ce :01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_wow_fw.bin
[4.841501] rtw_8822ce :01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_fw.bin
[4.874130] bluetooth hci0: firmware: direct-loading firmware rtl_bt/rtl8822cu_fw.bin
[4.874162] bluetooth hci0: firmware: direct-loading firmware rtl_bt/rtl8822cu_config.bin

Bug#1063712: check-dfsg-status: integration of monthly cron job with systemd-cron

[Holger Levsen]

On Sun, Feb 11, 2024 at 07:39:41PM +0100, Alexandre Detiste wrote:
> > > PS: this need a not yet released systemd-cron to actually work.
> > any idea when it will be released?
> Now, we are both upstream & downstream, it's easy.

ok, please ping this bug once it's in trixie.


-- 
cheers,
Holger

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

I’ve said it once, and I’ll say it a thousand times: If the penalty for
breaking a law is a fine, then that law only exists for the poor.


signature.asc
Description: PGP signature

Bug#1063660: the amdgpu module is missing from the kernel

[Diederik de Haas]

Control: tag -1 moreinfo

On Saturday, 10 February 2024 17:41:43 CET Nikolay Sabelnikov wrote:
> Package: linux-image-amd64
> Version: 6.1.76-1
> 
> > update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64
> > W: Possible missing firmware /lib/firmware/amdgpu/ip_discovery.bin for
> > module amdgpu
> > W: Possible missing firmware /lib/firmware/amdgpu/vega10_cap.bin for
> > module amdgpu
> > W: Possible missing firmware
> > /lib/firmware/amdgpu/sienna_cichlid_cap.bin for module amdgpu
> > W: Possible missing firmware /lib/firmware/amdgpu/navi12_cap.bin for
> > module amdgpu
> > W: Possible missing firmware /lib/firmware/amdgpu/psp_13_0_11_ta.bin
> > for module amdgpu

What I see in these messages that it's requesting new(er) *firmware* files, but 
the bug title implicates that there is a *kernel* module missing.
The latter would be very surprising and would make your/any graphics output on 
AMD GPUs not work.
Can you confirm it's actually a firmware issue?

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

Bug#1063722: /usr/bin/autopkgtest-build-qemu: autopkgtest-build-qemu can create incorrect /etc/fstab

[Victor Westerhuis]

Package: autopkgtest
Version: 5.32
Severity: normal
File: /usr/bin/autopkgtest-build-qemu
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

autopkgtest-build-qemu assumes that the output
of $(ls -1 /dev/mapper/loop* | sort | tail -1) is the root device for the
created image. This can fail if there are other devices matching that glob.

vmdb2 supports creating /etc/fstab based on the created and mounted
partitions in the image. I've attached a patch to use vmdb2's fstab
support. I've also opened a MR[1] with the same changes.

[1]: https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/292

- --
Vriendelijke groet, Kind regards,

Victor Westerhuis

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US:en:nl_NL:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages autopkgtest depends on:
ii  apt-utils   2.7.10
ii  libdpkg-perl1.22.4
ii  mawk1.3.4.20240123-1
ii  procps  2:4.0.4-4
ii  python3 3.11.6-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.33-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
ii  genisoimage  9:1.1.11-3.4
pn  incus
pn  lxc  
pn  lxd  
ii  ovmf 2023.11-6
pn  ovmf-ia32
ii  podman   4.9.2+ds1-2
ii  python3-distro-info  1.7
ii  qemu-efi-aarch64 2023.11-6
ii  qemu-efi-arm 2023.11-6
pn  qemu-system  
ii  qemu-utils   1:8.2.1+ds-1
ii  schroot  1.6.13-3+b3
ii  util-linux   2.39.3-6
ii  vmdb20.28-1
ii  zerofree 1.1.1-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmXJFTkTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+9kLEACcPYoO6aVRGd+VVA62pzkb/uBPAkt4
fsfUfN18g+M/vjaObyKGLPiaDGVB4bxY2eF/fxrRIQEroEutG7gOuFLPEKICJqZT
vIZyWvyLwoYDmHwSRCOi4X45BgX+GRg+j4JBRZ4vDFWX/6L0jOuBLeMP8jjayfBH
qQwof2pXg+3FAYYJKE598LCd770NGevT+dK5Cmnf4CNyrz95ftH6fDHiy0lgQfOF
r0KzmoZNp6VpUR8RTR+DxTBy1qJ5zsyCUW/Ettq4W/16H4V/uPbGr2x7drGiE6tU
cOvMVDFxLSnqFmgBFe5QXHYB8GWrm5gejpSOq/YXwEEgdywhhXj1Krm7p70kbRsg
xQfoUWej+RTex58iQTgSjI1IxuL+nl8veztNpBcDJ4uWq7/91AqoXUHz4vJZ1OaF
qcGwXQjkk5emu46Wy/N2R9HZYUDwukcRqgZ7l26I4IU0dD0VcU+2Hvt6GPTaBHcl
EHVguoysXi4Ob1U/MVIZEK+kQsXCEkBFPEMgf07gj600JHWHc93OqZUFLNwn/U7b
h3WHW5g9vHhM5q3OBrPpQkWDdfblJ/j5aTzthj135vKD/ceFkBQ/8fIRvVIQcsVl
wPSXshC/m/gsiAd4Dptdtdlgf3aEHfNETprQ6s5S+kCiLcZNpumBvLM8UEqFbJqD
XrKtyaPsRcUYSw==
=Rqlg
-END PGP SIGNATURE-
>From 18a2f2e7c9e92b2ce386f4abb0581e1d1aa7529b Mon Sep 17 00:00:00 2001
From: Victor Westerhuis 
Date: Sun, 11 Feb 2024 19:17:14 +0100
Subject: Let vmdb2 write /etc/fstab in autopkgtest-build-qemu

The old code assumed the last device matching the glob
/dev/mapper/loop* was the root device, which is not
always true.
---
 tools/autopkgtest-build-qemu | 26 ++
 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/tools/autopkgtest-build-qemu b/tools/autopkgtest-build-qemu
index a7d135c..2d50d58 100755
--- a/tools/autopkgtest-build-qemu
+++ b/tools/autopkgtest-build-qemu
@@ -521,6 +521,11 @@ class BuildQemu:
 
 if boot == 'efi':
 steps.append(dict(mkfs='vfat', partition='efi'))
+steps.append({
+'mount': 'efi',
+'dirname': 'boot/efi',
+'mount-on': 'root',
+})
 steps.append(
 dict(
 grub='uefi',
@@ -560,26 +565,7 @@ class BuildQemu:
 ),
 )
 
-steps.append({
-'shell': '\n'.join([
-'rootdev=$(ls -1 /dev/mapper/loop* | sort | tail -1)',
-'uuid=$(blkid -c /dev/null -o value -s UUID "$rootdev")',
-('echo "UUID=$uuid / ext4 errors=remount-ro 0 1" '
- '> "$ROOT/etc/fstab"'),
-]),
-'root-fs': 'root',
-})
-
-if boot == 'efi':
-steps.append({
-'shell': '\n'.join([
-'efidev=$(ls -1 /dev/mapper/loop* | sort | head -1)',
-'uuid=$(blkid -c /dev/null -o value -s UUID "$efidev")',
-('echo "UUID=$uuid /boot/efi vfat defaults 0 2" '
- '>> "$ROOT/etc/fstab"'),
-]),
-'root-fs': 'root',
-})
+steps.append(dict(fstab='root'))
 
 for s in (script, user_script):
 if s:
-- 
2.43.0

Bug#1063712: check-dfsg-status: integration of monthly cron job with systemd-cron

[Alexandre Detiste]

Le dim. 11 févr. 2024 à 18:14, Holger Levsen  a écrit :
>
> On Sun, Feb 11, 2024 at 04:32:58PM +0100, Alexandre Detiste wrote:
> > Unless #1026287 "use systemd .timer unit instead of /etc/cron.monthly"
> > got implemented, would it be possible to ship a
> > tiny 2 lines "old-style-mail.conf"  drop-in systemd overide that
> > overides how systemd-cron will style the monthly report ?
> >
> > This drop-in would have no effect on Vixie cron or cronie.
>
> sounds reasonable & thanks for the (almost) patch!

It's more complicated to get an agreement than
to write tiny patches (see 915370).

> > PS: this need a not yet released systemd-cron to actually work.
>
> any idea when it will be released?

Now, we are both upstream & downstream, it's easy.

Greetings

Bug#1063721: spip: has stopped working, complains about PHP version being ‘too recent’

[Axel]

Package: spip
Version: 4.1.9+dfsg-1+deb12u4
Severity: important
X-Debbugs-Cc: a...@users.sourceforge.net

Dear Maintainer,

after the upgrade, I could not log in to my site anymore. After making a backup 
of my
files, I first tried reinstalling, then purging + installing. a2ensite and 
spip_add_site
do not complain but …/ecrire shows:

“This installation will probably fail, or damage your site. PHP version 8.2.7 
too recent (maximum = 8.1.99)”

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

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

Versions of packages spip depends on:
ii  fonts-dustin20030517-14
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-form   12-4
ii  libjs-jquery-jstree 3.3.12+dfsg1-2
ii  libjs-mediaelement  2.15.1+dfsg-3
ii  libjs-prefix-free   1.0.10+repack-5
ii  libjs-twitter-bootstrap-datepicker  1.3.1+dfsg1-4.1
ii  node-js-cookie  3.0.1+~3.0.0-3
ii  php-common  2:93
ii  php-getid3  1.9.22+dfsg-1
ii  php-mysql   2:8.2+93
ii  php-pgsql   2:8.2+93
ii  php-sqlite3 2:8.2+93
ii  php-xml 2:8.2+93
ii  php8.2-pgsql [php-pgsql]8.2.7-1~deb12u1
ii  php8.2-sqlite3 [php-sqlite3]8.2.7-1~deb12u1
ii  php8.2-xml [php-xml]8.2.7-1~deb12u1

Versions of packages spip recommends:
ii  apache2 [httpd]2.4.57-2
ii  default-mysql-server   1.1.0
ii  imagemagick8:6.9.11.60+dfsg-1.6
ii  imagemagick-6.q16 [imagemagick]8:6.9.11.60+dfsg-1.6
ii  mariadb-server [virtual-mysql-server]  1:10.11.6-0+deb12u1
ii  netpbm 2:11.01.00-2
ii  php-sqlite32:8.2+93
ii  php8.2-sqlite3 [php-sqlite3]   8.2.7-1~deb12u1
ii  postgresql 15+248

spip suggests no packages.

-- debconf information:
  spip/webserver: apache2

Bug#1027876: protobuf: package is missing CMake files

[Thomas Braun]

Am Sonntag, dem 14.01.2024 um 13:48 +0100 schrieb László Böszörményi
(GCS):

> It will take a while to make it to Sid, but please report back if you
> find any issues.

Works here, thanks for the update.

Bug#1063717: Please close this bug as it already exists

[matte . mb2006 . 9990]

The same bug is cited here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062932
You can close this bug.

Bug#1063720: rust-env-logger: please upgrade to v0.11

[Jonas Smedegaard]

Source: rust-env-logger
Version: 0.10.0-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, upstream branch v0.11.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXJEAUACgkQLHwxRsGg
ASHEiBAAnCwACMLb+fO0qrzKef24hNbGCon5KBVXRpZt97GST6NSv89jZbl6Gw/J
UPxJD4a8GBGXvtm9jSpOncmMSdSwIgRbgJs9m67WlKYhMNxb1RJSKr6XheryGupZ
Umg0EPFYSHiwXMrQamecyc2EPoAwzNXsJaMoUHmaWjN8QmzvJqpB1GiJ12HR6buW
0TB39qu67dEwI0gPaWnwnvJazfPrhqtX//H5NHnOxqszxmwNA/B5X9/bfCgu1xyS
RMFWW98HaFpEszRCxHgixk1aGOtCfhN8anxM/iVU3GyiVEN9n5SmNP9AEB4nWjeo
z9Z1mCLz3+RQUZ79s9v+57ZXRKkaVT93rphZfvg0oqdlSun1VZBhVA8kWZKVH9fg
Pwuxiync7utNLIJsN+f/AdhLUWYZ3CGal1We/gi5EDdroWox2R7qlbIyOSZ8YMja
BCTwLq25ikS16w006EudK9zRdnIJ60r/5RVe3bVaJ60A8UgRbd6Hzt4h1NspTP0n
z5z4f3LnPYIw265Q4aPGqAmyWA1lyicidZnEa6di5UgJQ1+hEyRSuXk9QOS67doR
xySLQfHcQHh4EwSgDtwUHZqmIRop3GELM8kDYt5mLGVX00xQxxERcny8ccaw4F4X
98j/6Gl3RDsHCole3yxnKYKUcRDze8AokJE5eIhmWzOrn2UXO9A=
=A3eG
-END PGP SIGNATURE-

Bug#1063719: needrestart -b complainst of initialized variables on some AMD and all ARM

[George Robbert]

Package: needrestart
Version: 3.6-4+deb12u1
Severity: normal
Tags: patch

Dear Maintainer,

When running 'needrestart -b' on some AMD systems I get the following
uninitialized variable warning.  It also does not report the expected
microcode version (NEEDRESTART-UCEXP).

Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or string 
at /usr/sbin/needrestart line 941.

On ARM systems, it gives the following 2 uninitialized variable warnings.

Use of uninitialized value $ucode_vars{"CURRENT"} in concatenation (.) or 
string at /usr/sbin/needrestart line 940.
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or string 
at /usr/sbin/needrestart line 941.

I first thought this was a regression of bug #1026927, but find this
is actually a different bug with similar behavior.

The problem stems from NeedRestart::uCode::Intel:::nr_ucode_check_real
running "successfully" on non-intel platforms.  The reason only some
AMD systems are affected is that nr_ucode_check_real() for AMD and
Intel may be run in either order, depending on the order they are
returned by findsubmod().  If AMD::nr_ucode_check_real() is run first,
the bug does not appear.

Here is sample output from 3 systems: a "failing" AMD, a "passing"
AMD, and an arm7l (banana pi).  I've trimmed (w/ grep) the stderr from
these to only the pertinent lines, please let me know if you want the
entire output.

amd_sys1# needrestart -b -v 2>/tmp/a
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-17-amd64
NEEDRESTART-KEXP: 6.1.0-18-amd64
NEEDRESTART-KSTA: 3
NEEDRESTART-UCSTA: 1
NEEDRESTART-UCCUR: 0x600063e
NEEDRESTART-UCEXP: 
amd_sys1# grep -e NeedRestart::uCode -e uninitialized /tmp/a 
[ucode] using NeedRestart::uCode::Intel
[ucode] using NeedRestart::uCode::AMD
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
string at /usr/sbin/needrestart line 941.

amd_sys2# needrestart -b -v 2>/tmp/a
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-17-amd64
NEEDRESTART-KEXP: 6.1.0-18-amd64
NEEDRESTART-KSTA: 3
NEEDRESTART-UCSTA: 1
NEEDRESTART-UCCUR: 0x06000852
NEEDRESTART-UCEXP: 0x06000852
amd_sys2# grep -e NeedRestart::uCode -e uninitialized /tmp/a   
[ucode] using NeedRestart::uCode::AMD
[ucode] using NeedRestart::uCode::Intel

arm7l_sys# needrestart -b -v 2>/tmp/a
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-17-armmp-lpae
NEEDRESTART-KEXP: 6.1.0-18-armmp-lpae
NEEDRESTART-KSTA: 3
NEEDRESTART-UCSTA: 0
NEEDRESTART-SVC: irqbalance
NEEDRESTART-SVC: lircd
NEEDRESTART-SVC: lircmd
NEEDRESTART-SVC: openbsd-inetd
NEEDRESTART-SVC: ssh
arm7l_sys# grep -e uninitial -e ucode /tmp/a   
[ucode] using NeedRestart::uCode::Intel
[ucode] using NeedRestart::uCode::AMD
[ucode] #0 did not get available microcode version
Use of uninitialized value $ucode_vars{"CURRENT"} in concatenation (.) or 
string at /usr/sbin/needrestart line 940.
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
string at /usr/sbin/needrestart line 941.


The problem comes from uCode::Intel::nr_ucode_check_real() still not
dying on non-Intel processors, and actually returning a "CURRENT"
microcode version on AMD processors.  This looks to be checked for in
uCode::Intel::nr_ucode_init(), but this function is never called.

The following patch adds a call to this so that nr_ucode_check_real()
is only called for architectures that successfully pass
nr_ucode_init().  An alternative would be to modify
uCode::Intel::nr_ucode_check_real() to do the equivalent checks like
uCode::AMD does.



--- /tmp/uCode.pm.dist  2024-02-11 09:28:27.051119002 -0700
+++ uCode.pm2024-02-11 10:14:26.905533440 -0700
@@ -152,6 +152,11 @@
 
 # call ucode modules
 foreach my $pkg (@PKGS) {
+   eval "${pkg}::nr_ucode_init();";
+   if ( $@ ) {
+   print STDERR $@ if ($debug);
+   next;
+   }
 my @nvars;
 eval "\@nvars = ${pkg}::nr_ucode_check_real(\$debug, \$ui, 
\$processors{\$pid});";
 if ( $@ && $debug ) {






-- Package-specific info:
needrestart output:
Your outdated processes:
emacs[9574, 6843, 10275, 3922, 6197]



-- System Information:
Debian Release: 12.0
Architecture: i386 (i686)

Kernel: Linux 6.1.0-17-686-pae (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages needrestart depends on:
ii  binutils   2.40-2
ii  dpkg   1.21.22
ii  gettext-base   0.21-12
ii  libintl-perl   1.33-1
ii  libmodule-find-perl0.16-2
ii  libmodule-scandeps-perl1.31-2
ii  libproc-processtable-perl  0.634-1+b2
ii  libsort-naturally-perl 1.03-4
ii  libterm-readkey-perl

Bug#1063660: (no subject)

[Nikolay Sabelnikov]

saber716rus@BOM-WXX9 ~> apt list -a firmware-amd-graphics
List output… Done
firmware-amd-graphics/stable,now 20230210-5 all [installed]
firmware-amd-graphics/unknown 20210818-1 all

saber716rus@BOM-WXX9 ~>

Bug#1063718: rust-byte-unit: please upgrade to v5

[Jonas Smedegaard]

Source: rust-byte-unit
Version: 4.0.13-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to, or separately provide, branch v5.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmXJDCgACgkQLHwxRsGg
ASGHcA/+NFJr84fhgvjCfoDU9uT2I+24WpKETpzzoM5thKjcfjrO770ahi1isVRu
wEFuxgkdGeZWV/VUfXTQS7En2lGjoPaqyjCXf2FjsgoYOe7vIQdP/KZ6+WdmkpxW
R2HHyWhndPLUkpz3+vRbR8hOOljqVHTco+rStIm5VSFzxlbfCvZemb5oNzyn5A3f
9g5G4cpqxxs2NSgjiu5BmSARPpaFPlHG0j3bRmLEBErZR1kuBbpzN1Yp9oFlR0Ip
pOHK9UwSjUPXHIQwanNJF7h5ZkEt3DPW1vWqQtMELEEZqcvuBOoMK1Mn0Z9Iiiot
psyCcWefPdJuN6UZQ7401IBFD5YKB1CV16d/l7fJscmu1FiruuRJS5PdHnmVgkUA
qQITBU+wn21Ep6i1IhwuGUwk94dvRXipL4cKR1gJKE/XpzWvDc67ba3bpnyTkpgu
ciLxYuuCdL8IperOa/Qscn+DNTGebEMGA6kywjYHCT1mmewVFxDzf6i9XmGzO9Ba
3XhMIgS3Zp4SfETYr7Izh9NAMhXfhhMCAvEMBqb9IPbFvX7QehZB8jxkUdFJdHIP
PT4B6v3hx61p2bBo0I1eS66ioVCtVIoWTJ5KB5moU2HHENmjjUW/HcRi7ntBZXIq
sP1FWxyAkyqw//1bx0On6HkKnm/ppFtw3SJcpFE5xIKMnFZtXd4=
=3agz
-END PGP SIGNATURE-

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Diederik de Haas]

Control: reassign -1 firmware-iwlwifi 20230625-2
Control: retitle -1 firmware-iwlwifi: Please update to version 20230919

On Sunday, 11 February 2024 16:34:16 CET Miguel Angel Rojas wrote:
> > While 'annoying', this is expected behavior. It tries to load the newest
> > (-83)
> Yes, this is the expected behavior from our Linux kernel. However, I agree
> with you and these messages are very annoying and should be removed.

IMO it's working as expected and as it should do.
It's aware of newer firmware so it tries to load that first, but then 'fall 
back' to older versions in case it can't find the newer firmware files.

> > It could be it wouldn't be shown if it had already found one of the
> > earlier logged firmware files.
> Interesting theory! When the new version of the firmware packages is
> uploaded, we can check again if the "'iwl-debug-yoyo.bin" message disappears

Great

> > Bit confused about that version number, but looks like success.
> Why are you confused with the numbers?
I thought it might have been some custom file, but that's an error on my part.
Apparently it detects the 'internal' firmware version and reports that. 

> And yes, wifi is working fine although I haven't properly done any
> performance test yet.

It could/might be there would be some improvement somewhere with newer 
firmware, but as long as things keep working that is fine.
Consequently, I've reassigned/renamed the bug to a request for a new upstream 
version (the one which has the -83 firmware file(s)).

Cheers,
  Diederik

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

Bug#1063710: lintian: apache2-deprecated-auth-config ignores mentioned workaround

[Russ Allbery]

Roland Rosenfeld  writes:

> I observe the following warning in xymon package:

> W: xymon: apache2-deprecated-auth-config Allow 
> [etc/apache2/conf-available/xymon.conf:23]
> N: 
> N:   The package is using some of the deprecated authentication configuration
> N:   directives Order, Satisfy, Allow, Deny,  or 
> N:   
> N:   These do not integrate well with the new authorization scheme of Apache
> N:   2.4 and, in the case of  and  have confusing
> N:   semantics. The configuration directives should be replaced with a 
> suitable
> N:   combination of , , Require all, Require local,
> N:   Require ip, and Require method.
> N:   
> N:   Alternatively, the offending lines can be wrapped between  N:   !mod_authz_core.c> ...  or  ... 
> N:   directives.
> N: 
> N:   Visibility: warning
> N:   Show-Always: no
> N:   Check: apache2

> But this xymon.conf already uses the mentioned
>   ... 
> wrapper:

This is definitely a bug in that the tag doesn't match the tag
description, but it may also be worth noting that Apache 2.4 was released
in February of 2012 and Apache 2.2 has been officially end of life and
entirely unsupported since July of 2017.  I think one can make a good
argument that both the Lintian tag description and xymon should just drop
all support for Apache versions prior to 2.4.  Hopefully no one is still
running it, since it almost certainly has significant unfixed security
vulnerabilities at this point.

-- 
Russ Allbery (r...@debian.org)  

Bug#1063717: cuda-drivers: Build of module nvidia.ko fails

[matte . mb2006 . 9990]

Package: cuda-drivers
Version: 545.23.08-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: matte.mb2006.9...@gmail.com

Dear Maintainer,
Compiling the cuda driver for kernel 6.1.0-18 fails with this error:
"
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'__rcu_read_lock'
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'__rcu_read_unlock'
"

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

Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 cuda-drivers depends on:
ii  cuda-drivers-545  545.23.08-1

cuda-drivers recommends no packages.

cuda-drivers suggests no packages.

-- no debconf information

Bug#1063716: [INTL:it] Italian po-debconf translation update

[Ceppo]

Package: kwartz-client
Severity: wishlist
Tags: l10n patch

Hello,
here's the updated Italian po-debconf translation.
Cheers,


--
Ceppo
# kwartz-client po-debconf italian translation.
# Copyright (C) 2022, 2024 kwartz-client's copyright holder
# This file is distributed under the same license as the kwartz-client package.
# Ceppo , 2022, 2024.
#
msgid ""
msgstr ""
"Project-Id-Version: kwartz-client\n"
"Report-Msgid-Bugs-To: kwartz-cli...@packages.debian.org\n"
"POT-Creation-Date: 2024-01-28 22:56+0100\n"
"PO-Revision-Date: 2024-02-04 00:00+\n"
"Last-Translator: Ceppo \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid "IP address of the proxy service:"
msgstr "Indirizzo IP del servizio proxy:"

#. Type: string
#. Description
#: ../kwartz-client.templates:1001
msgid ""
"Please enter the address of the proxy service. It is ususally the same as "
"the address of the Kwartz server. If unsure, keep the default value."
msgstr ""
"Inserire l'indirizzo IP del servizio proxy. Di solito è lo stesso indirizzo "
"del server Kwartz. In caso di incertezza, lasciare il valore predefinito."

#. Type: string
#. Description
#: ../kwartz-client.templates:2001
msgid "Port number of the proxy service:"
msgstr "Numero della porta del servizio proxy:"

#. Type: string
#. Description
#: ../kwartz-client.templates:2001
msgid ""
"Please enter the port number of the proxy service. The default value is "
"usually safe."
msgstr ""
"Inserire il numero della porta del servizio proxy. Di solito il valore "
"predefinito è adeguato."

#. Type: string
#. Description
#: ../kwartz-client.templates:3001
msgid "List of IP addresses not concerned by the proxy service:"
msgstr "Elenco degli indirizzi IP non interessati dal servizio proxy:"

#. Type: string
#. Description
#: ../kwartz-client.templates:3001
msgid ""
"Please enter the IP addresses and ranges which must be fetched without the "
"help of the proxy. If unsure, keep the default list."
msgstr ""
"Inserire gli indirizzi e intervalli IP che devono essere recuperati senza "
"l'aiuto del proxy. In caso di incertezza, lasciare l'elenco predefinito."

#. Type: string
#. Description
#: ../kwartz-client.templates:4001
msgid "Landing page URL for the browser:"
msgstr "URL della pagina iniziale per il browser:"

#. Type: string
#. Description
#: ../kwartz-client.templates:4001
msgid ""
"Please choose the URL of a landing page for the browser. This web page will "
"appear each time the browser is launched. If unsure, keep the default URL."
msgstr ""
"Scegliere l'URL della pagina iniziale per il browser. Questa pagina web"
"comparirà ogni volta che il browser viene lanciato. In caso di incertezza, "
"lasciare l'URL predefinito."

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "Halt the client computer every night:"
msgstr "Arrestare il computer client ogni notte:"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "- 0: no, the computer will not be halted automatically"
msgstr "- 0: no, il computer non verrà arrestato automaticamente"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "- 1: yes, the computer will be halted at 19:00"
msgstr "- 1: sì, il computer verrà arrestato alle 19:00"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "- 2: yes, the computer will be halted at 20:00"
msgstr "- 2: sì, il computer sarà arrestato alle 20:00"

#. Type: string
#. Description
#: ../kwartz-client.templates:5001
msgid "- 3: yes, the computer will be halted at 22:00"
msgstr "- 3: sì, il computer sarà arrestato alle 22:00"

#. Type: string
#. Description
#: ../kwartz-client.templates:6001
msgid "An unpriviledged user to access the web:"
msgstr "Un utente senza privilegi per accedere al web:"

#. Type: string
#. Description
#: ../kwartz-client.templates:6001
msgid ""
"When APT will run some automatic update for the package database, a user "
"name is needed to use the proxy service. This user must be unpriviledged."
msgstr ""
"Quando APT eseguirà alcuni aggiornamenti automatici al database dei "
"pacchetti, sarà necessario un nome utente per accedere al servizio proxy. "
"Questo utente non deve avere privilegi."

#. Type: password
#. Description
#: ../kwartz-client.templates:7001
msgid "Password to access the web:"
msgstr "Password per accedere al web:"

#. Type: password
#. Description
#: ../kwartz-client.templates:7001
msgid ""
"The unpriviledged user which will be used by APT to access the web needs a "
"password. It must be some strong password."
msgstr ""
"L'utente senza privilegi che sarà usato da APT per accedere al web necessita "
"di una password. Deve essere una password sicura."

#. Type: string
#. Description
#: ../kwartz-client.templates:8001
msgid "Network name of the Kwartz server:"
msgstr "Il nome di rete del server Kwartz:"

Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland

[Simon McVittie]

Control: affects -1 + xfce4 task-xfce-desktop

On Sun, 11 Feb 2024 at 17:51:43 +0100, Yves-Alexis Perez wrote:
> Control: reassign -1 ibus

Marking this as affecting xfce4 and task-xfce-desktop so that it'll show up
in the most likely places to report a bug in "the normal Xfce desktop", to
avoid duplicates.

> Ibus maintainers: on Debian (Xfce) live images for 12.5 it seems that at
> startup ibus outputs an error message which shouldn't be there (no idea if it
> should work or not, but at least there's no Wayland or Plasma involved).

Note that this is (at least for now) a bookworm-specific bug report for
a high-visibility message in live images. I haven't tested Xfce on older
or newer suites.

It's entirely possible that this is fixed in testing/unstable already:
codesearch seems to indicate that the warning message "Keymap changes
do not work (etc.)" has been removed from ibus at some point before
unstable, leaving only a commented-out version in the .po files.

smcv

Bug#1063715: monitoring-plugins-common: check_flexlm (monitoring-plugins-standard) fails because utils.pm has empty PATH_TO_LMSTAT

[Christian Ospelkaus]

Package: monitoring-plugins-common
Version: 2.3.3-5+deb12u2
Severity: normal
Tags: patch

Dear Maintainer,

The command check_flexlm from montoring-plugins-standard is useless
because it relies on the setting PATH_TO_LMSTAT from
monitoring-plugins-common, which is unfortunately empty. AFAIK, no Debian 
package provides lmstat. So I suggest setting PATH_TO_LMSTAT to 
/usr/local/bin/lmstat so that somebody who wants to use the plugin can 
provide a symbolic link under /usr/local/bin/lmstat or place the exectutable 
right there. Even if there were a debian package that provided lmstat, the 
mechanism would still allow to make things work... Thanks for considering my 
suggesion. Here is my patch:

--- /usr/lib/nagios/plugins/utils.pm2024-02-11 17:57:02.238612539 +0100
+++ /usr/lib/nagios/plugins/utils.pm.orig   2024-02-11 17:58:59.337727843 
+0100
@@ -19,7 +19,7 @@
 ## updated by autoconf
 $PATH_TO_SUDO= "/usr/bin/sudo";
 $PATH_TO_RPCINFO = "/usr/sbin/rpcinfo" ;
-$PATH_TO_LMSTAT  = "/usr/local/bin/lmstat" ;
+$PATH_TO_LMSTAT  = "" ;
 $PATH_TO_SMBCLIENT = "/usr/bin/smbclient" ;
 $PATH_TO_MAILQ   = "/usr/bin/mailq";
 $PATH_TO_QMAIL_QSTAT = "";

Best wishes,

Christian

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

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

Versions of packages monitoring-plugins-common depends on:
ii  libc6  2.36-9+deb12u4
ii  ucf3.0043+nmu1

monitoring-plugins-common recommends no packages.

Versions of packages monitoring-plugins-common suggests:
ii  icinga2  2.13.6-2

-- no debconf information

Bug#1063403: libeegdev-dev,libeegdev0t64: both ship /usr/share/doc/libeegdev0/changelog.gz

[Andreas Metzler]

Comtrol: tags -1 patch

On 2024-02-07 Andreas Beckmann  wrote:
> Package: libeegdev-dev,libeegdev0t64
[...]
> Something weird happened after the package rename:

>   /usr/share/doc/libeegdev0/changelog.Debian.gz
>   /usr/share/doc/libeegdev0/changelog.gz

> Are now shipped by libeegdev-dev and libeegdev0t64 while they should be
> in none of these packages.
[...]
> Control files: lines which differ (wdiff format)
> 
> Depends: {+libeegdev0t64 (= 0.2-8.1~exp1),+} libeegdev0 (= [-0.2-8)-] 
> {+0.2-8.1~exp1)+}
> Installed-Size: [-71-] {+87+}
> Version: [-0.2-8-] {+0.2-8.1~exp1+}

> Also the libeegdev0 dependency is still there ...

Hello,

This is another instance (well, the second one ;-) ) of not changing the
dh_installdocs --link-doc= argument in debian/rules. dh_installdocs also
generates the dependency.

-dh_installdocs --link-doc=libeegdev0
+dh_installdocs --link-doc=libeegdev0t64

cu Andreas

Bug#1063712: check-dfsg-status: integration of monthly cron job with systemd-cron

[Holger Levsen]

On Sun, Feb 11, 2024 at 04:32:58PM +0100, Alexandre Detiste wrote:
> Unless #1026287 "use systemd .timer unit instead of /etc/cron.monthly"
> got implemented, would it be possible to ship a
> tiny 2 lines "old-style-mail.conf"  drop-in systemd overide that
> overides how systemd-cron will style the monthly report ?
> 
> This drop-in would have no effect on Vixie cron or cronie.
 
sounds reasonable & thanks for the (almost) patch!

> PS: this need a not yet released systemd-cron to actually work.

any idea when it will be released?


-- 
cheers,
Holger

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

Change is coming whether you like it or not.


signature.asc
Description: PGP signature

Bug#1050693: sphinx: unreproducible output if the same function has two entries in the table of contents

[Dmitry Shachnev]

Hi Rebecca, and sorry for the late response!

On Mon, Aug 28, 2023 at 11:39:05AM +0100, Rebecca N. Palmer wrote:
> Package: python3-sphinx
> Version: 5.3.0-7
> Severity: wishlist
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: fileordering
> 
> When the same function has two entries in the table of contents, that
> function's documentation page may be generated with the table of contents
> open to either of those two entries.  (Probably based on filesystem order,
> i.e. which entry gets processed first, but I don't actually know that.)
> 
> For example, pandas DataFrame.to_* are listed in both reference/io.rst and
> reference/frame.rst:
> https://salsa.debian.org/science-team/pandas/-/jobs/4617327

In the log referenced by you there is indeed diff for
/usr/share/doc/python-pandas-doc/html/reference/api/pandas.DataFrame.to_*.html
files. However, I don't see any diff in the recent pandas reprotest logs, e.g.
in these ones:

- https://salsa.debian.org/science-team/pandas/-/jobs/5232189
- https://salsa.debian.org/science-team/pandas/-/jobs/5268239
- https://salsa.debian.org/science-team/pandas/-/jobs/5273611

There is no diff for /usr/share/doc/python-pandas-doc/html/reference/* at all.

Maybe this bug no longer happens in Sphinx 7.2 (which was uploaded to unstable
on 2023-11-05)? Or it just happens rarely and the CI can't always catch it?

If we manage to reproduce it, the next step would be identifying whether this
is a problem in autosummary extension, or can be reproduced without it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1061306:

[Peter B]

licenserecon's reporting GPL-3 vs GPL-3+ as a difference
is not a misleading false positive. They are different licenses.
The latter confers the right to use a later license, the former does not.

kitty's d/copyright file should have a separate file stanza for the 
GPL-3 (only) files.

See https://ftp-master.debian.org/licenses/good/gpl3/
In the box to the right it says;
  [Be careful to reflect the right restriction, ie. "version 3 only" or 
"version 3 or any later".]


Anyway, as you prefer not to see these GPL version differences,
I'm changing the bug to wishlist and retitling accordingly.
It would be a real bug if lrc ignored these differences.

I've updated the man page to make it explicit that
license version differences are intentionally reported.

Please note, you can suppress these differences by using
lrc | grep -v 'GPL-3+  | GPL-3'
This leaves just four lines of file differences for kitty.


FYI
I'm considering adding some options to lrc,
including a brief or terse option which would limit output of blocks
of files with identical license differences to the first file only.
In the case of kitty, the result would be very similar to that above,
so should meet your requirement. There would just be one line
of GPL-3+ | GPL-3' which would not down out the rest of the output.

I was originally intending to tag this a 'wontfix', but my current thinking
is to leave it for now, and to close it when a terse option is added.

Bug#1063701: Re: Bug#1063701: clang: When invoking "clang++", "clang" is invoked instead

[kritomas]

When I run "clang++", the output says "clang: error: no input files" 
instead of "clang++: error: no input files",


with all C++ functionality completely disabled (C++ hello world does 
"fatal error: 'iostream' file not found").


This issue only showed up today (so sometime within the past week), it 
definitely wasn't like this for "a very long time".

Bug#1063661: xfce4: "IBus Notification: Keymap changes do not work in Plasma Wayland" but this is not Plasma Wayland

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: reassign -1 ibus

On Sun, 2024-02-11 at 14:42 +, Simon McVittie wrote:
> > Yes indeed, that's really weird. I'll try a live 12.5 cd at some point but
> > if
> > you have one handy can you run a dpkg -l |grep '^ibus' or something?
> 
> No need for dpkg -l,
> https://cdimage.debian.org/images/release/current-live/amd64/iso-hybrid/debian-live-12.5.0-amd64-xfce.iso.packages
> says, among other things:
> 
> ibus  1.5.27-5
> ibus-data 1.5.27-5
> ibus-gtk:amd641.5.27-5
> ibus-gtk3:amd64   1.5.27-5
> ibus-gtk4:amd64   1.5.27-5
> ibus-hangul   1.5.4-2
> ibus-m17n 1.4.19-1

A good, indeed. I'm reassigning to ibus because the message is at least
misleading.

Ibus maintainers: on Debian (Xfce) live images for 12.5 it seems that at
startup ibus outputs an error message which shouldn't be there (no idea if it
should work or not, but at least there's no Wayland or Plasma involved).
> 
> At a guess, this is probably here because task-korean-desktop pulls in
> ibus-hangul? But that has been the case since at least Debian 11...

Maybe.
> 
> > I don't really know why it would suddenly get installed but maybe some
> > dependencies changed in 12.5.
> 
> I don't remember noticing this when I helped to test XFCE live images
> during the 12.0 release, but I also can't say for sure that 12.0 wasn't
> affected.

Ok.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmXI+x8ACgkQ3rYcyPpX
RFt6lgf+JTSF38jWL8y+Rd6qZVs9fIQ+dMQHGTFJwfN36oNNRxjJqlRIp31HOdkM
nEPQa7iisCK4vMjmCJ9OHIuaLr/peCR0HuJm6rbxi8CWlJQ0z2GHjJjtBU6mdYPR
E2BjmC/grMf6psIk6h4eoLqcuHQWTxHikaRXIiy4xBLZcSQaA2/KdIOHDnaqyhJ4
TY2P+qsHwoDKidfXI6QcKVkzd/T/A6OG2NuMYPsojb/LI/MUz/OTiIFQRi9N8Iq0
eHNJUPz29VxeegaQjUCIWjHXxH8Jyoc5tK1PjlfkoIgeeok6A6Ek9ywb1Flogp+E
lr1AthvYLeFws21deXJ2EgiWJuI6kQ==
=qQew
-END PGP SIGNATURE-

Bug#1058890: new try

[Dr . André Desgualdo Pereira]

Adding "init_on_alloc=0" to kernel boot does NOT change anything. 

Bug#1063660: (no subject)

[Nikolay Sabelnikov]

made inxi -Fazy
saber716rus@BOM-WXX9 ~> inxi -Fazy
System:
  Kernel: 6.1.0-18-amd64 arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-6.1.0-18-amd64
    root=UUID=32078b24-77ba-488f-81e3-c6d23b04f161 ro 
rootflags=subvol=@ quiet

    splash
  Desktop: Cinnamon v: 6.0.4 tk: GTK v: 3.24.38 wm: muffin vt: 7 dm: 
LightDM

    v: 1.26.0 Distro: LMDE 6 Faye base: Debian 12.1 bookworm
Machine:
  Type: Laptop System: HUAWEI product: BOM-WXX9 v: M1010
    serial: 
  Mobo: HUAWEI model: BOM-WXX9-PCB-B2 v: M1010 serial: 
    UEFI: HUAWEI v: 2.12 date: 03/16/2023
Battery:
  ID-1: BAT1 charge: 31.2 Wh (58.8%) condition: 53.1/54.9 Wh (96.6%) 
volts: 7.7

    min: 7.6 model: Desay HB4692Z9ECW-22T type: Li-ion serial: 
    status: discharging cycles: 44
CPU:
  Info: model: AMD Ryzen 7 5700U with Radeon Graphics bits: 64 type: MT MCP
    arch: Zen 2 gen: 3 level: v3 note: check built: 2020-22
    process: TSMC n7 (7nm) family: 0x17 (23) model-id: 0x68 (104) 
stepping: 1

    microcode: 0x8608103
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
    L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB 
L3: 8 MiB

    desc: 2x4 MiB
  Speed (MHz): avg: 1448 high: 1800 min/max: 1400/4370 boost: enabled
    scaling: driver: acpi-cpufreq governor: schedutil cores: 1: 1397 2: 
1400
    3: 1400 4: 1397 5: 1397 6: 1800 7: 1400 8: 1400 9: 1400 10: 1397 
11: 1400

    12: 1800 13: 1397 14: 1400 15: 1398 16: 1400 bogomips: 57491
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: retbleed mitigation: untrained return thunk; SMT enabled with STIBP
    protection
  Type: spec_rstack_overflow mitigation: safe RET
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
    prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
    sanitization
  Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, STIBP:
    always-on, RSB filling, PBRSB-eIBRS: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD Lucienne vendor: QUANTA driver: amdgpu v: kernel arch: 
GCN-5

    code: Vega process: GF 14nm built: 2017-20 pcie: gen: 3 speed: 8 GT/s
    lanes: 16 link-max: gen: 4 speed: 16 GT/s ports: active: eDP-1
    empty: HDMI-A-1 bus-ID: 03:00.0 chip-ID: 1002:164c class-ID: 0300
    temp: 40.0 C
  Device-2: Quanta ov9734_techfront_camera type: USB driver: uvcvideo
    bus-ID: 1-4:3 chip-ID: 0408:1040 class-ID: 0e02 serial: 
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 
driver: X:
    loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: 
amdgpu

    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
    s-diag: 582mm (22.93")
  Monitor-1: eDP-1 mapped: eDP model: BOE Display 0x0872 built: 2019
    res: 1920x1080 hz: 60 dpi: 142 gamma: 1.2 size: 344x194mm (13.54x7.64")
    diag: 395mm (15.5") ratio: 16:9 modes: max: 1920x1080 min: 640x480
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: AMD Radeon Graphics (renoir LLVM
    15.0.6 DRM 3.49 6.1.0-18-amd64) direct-render: Yes
Audio:
  Device-1: AMD Renoir Radeon High Definition Audio vendor: QUANTA
    driver: snd_hda_intel v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16
    link-max: gen: 4 speed: 16 GT/s bus-ID: 03:00.1 chip-ID: 1002:1637
    class-ID: 0403
  Device-2: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: QUANTA
    driver: snd_rn_pci_acp3x v: kernel alternate: snd_pci_acp3x, 
snd_pci_acp5x,

    snd_pci_acp6x pcie: gen: 3 speed: 8 GT/s lanes: 16 link-max: gen: 4
    speed: 16 GT/s bus-ID: 03:00.5 chip-ID: 1022:15e2 class-ID: 0480
  API: ALSA v: k6.1.0-18-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 0.3.65 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: 
plugin

    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter
    vendor: & Tele RSH driver: rtw_8822ce v: N/A modules: rtw88_8822ce 
pcie:

    gen: 1 speed: 2.5 GT/s lanes: 1 port: 2000 bus-ID: 01:00.0
    chip-ID: 10ec:c822 class-ID: 0280
  IF: wlp1s0 state: up mac: 
Bluetooth:
  Device-1: Realtek Bluetooth Radio type: USB driver: btusb v: 0.8
    bus-ID: 3-2:2 chip-ID: 1358:c123 class-ID: e001 serial: 
  Report: hciconfig ID: hci0 rfk-id: 1 state: up address:  
bt-v: 3.0

    lmp-v: 5.1 sub-v: abd3 hci-v: 5.1 rev: ffb8
  Info: acl-mtu: 1021:6 sco-mtu: 255:12 link-policy: rswitch hold sniff 
park
    link-mode: peripheral accept service-classes: rendering, capturing, 
object

    transfer, audio, telephony
Drives:
  Local Storage: total: 

Bug#1049378: (no subject)

[Nikolay Sabelnikov]

I recently got a bug, but a similar one was discovered six months ago.

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

Bug#1063660: (no subject)

[Nikolay Sabelnikov]

I found a bug similar to mine, but the problem is visible when you 
update the kernel. This bug was discovered six months ago, but has not 
yet been resolved.


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


saber716rus@BOM-WXX9 ~> apt list -a amd64-microcode
List output…
amd64-microcode/stable is ready,now 3.20230808.1.1~deb12u1 amd64 [installed]
amd64-microcode/stable-security 3.20230719.1~deb12u1 amd64
amd64-microcode/unknown 3.20191218.1 amd64

saber716rus@BOM-WXX9 ~>

Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu

[Patrice Duroux]

Package: src:linux
Version: 6.7.4-1~exp1
Followup-For: Bug #1061449

Dear Maintainer,
Just for info, the same error occurs also with 6.7.4-1~exp1.
Regards,
Patrice

[4.067807] [ cut here ]
[4.067808] WARNING: CPU: 7 PID: 246 at
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:387
construct_phy+0xb26/0xd60 [amdgpu]
[4.068223] Modules linked in: amdgpu(+) i915(+) drm_exec amdxcp sd_mod
gpu_sched drm_buddy nvme drm_suballoc_helper i2c_algo_bit drm_display_helper
nvme_core ahci hid_generic liba
hci crc32_pclmul crc32c_intel t10_pi cec libata rc_core crc64_rocksoft_generic
drm_ttm_helper ghash_clmulni_intel i2c_hid_acpi crc64_rocksoft sha512_ssse3 ttm
crc_t10dif i2c_hid rtsx_
pci_sdmmc sha512_generic xhci_pci crct10dif_generic drm_kms_helper xhci_hcd
mmc_core scsi_mod hid intel_lpss_pci crct10dif_pclmul i2c_i801 sha256_ssse3
intel_lpss crc64 thunderbolt dr
m e1000e usbcore sha1_ssse3 rtsx_pci video i2c_smbus crct10dif_common
usb_common scsi_common idma64 battery wmi button aesni_intel crypto_simd cryptd
[4.068253] CPU: 7 PID: 246 Comm: (udev-worker) Not tainted 6.7-amd64 #1
Debian 6.7.4-1~exp1
[4.068256] Hardware name: Dell Inc. Precision 7540/0T2FXT, BIOS 1.29.0
11/03/2023
[4.068257] RIP: 0010:construct_phy+0xb26/0xd60 [amdgpu]
[4.068593] Code: b9 01 00 00 00 83 fe 01 74 40 48 8b 82 f8 03 00 00 89 f2
48 c7 c6 70 57 a4 c1 48 8b 40 10 48 8b 00 48 8b 78 08 e8 fa b5 3e e9 <0f> 0b 49
8b 87 d0 01 00 00 b9 0f 0
0 00 00 48 8b 80 e8 04 00 00 48
[4.068595] RSP: 0018:b5d88083f318 EFLAGS: 00010246
[4.068596] RAX:  RBX: a0f433036000 RCX:
c000efff
[4.068598] RDX:  RSI: efff RDI:
0001
[4.068598] RBP: a0f4133c3600 R08:  R09:
b5d88083f0e0
[4.068599] R10: 0003 R11: abcd2428 R12:
b5d88083f384
[4.068600] R13: c1905120 R14: b5d88083f6e0 R15:
a0f433e11000
[4.068601] FS:  7f9eab8428c0() GS:a0f78c3c()
knlGS:
[4.068603] CS:  0010 DS:  ES:  CR0: 80050033
[4.068604] CR2: 7ffe7d8ebf88 CR3: 0001048aa002 CR4:
003706f0
[4.068605] DR0:  DR1:  DR2:

[4.068606] DR3:  DR6: fffe0ff0 DR7:
0400
[4.068607] Call Trace:
[4.068609]  
[4.068610]  ? construct_phy+0xb26/0xd60 [amdgpu]
[4.068947]  ? __warn+0x81/0x130
[4.068950]  ? construct_phy+0xb26/0xd60 [amdgpu]
[4.069285]  ? report_bug+0x171/0x1a0
[4.069288]  ? handle_bug+0x3c/0x80
[4.069290]  ? exc_invalid_op+0x17/0x70
[4.069291]  ? asm_exc_invalid_op+0x1a/0x20
[4.069294]  ? construct_phy+0xb26/0xd60 [amdgpu]
[4.069627]  ? construct_phy+0xb26/0xd60 [amdgpu]
[4.069965]  link_create+0x1b2/0x200 [amdgpu]
[4.070298]  create_links+0x135/0x420 [amdgpu]
[4.070614]  dc_create+0x321/0x640 [amdgpu]
[4.070931]  amdgpu_dm_init.isra.0+0x2a0/0x1df0 [amdgpu]
[4.071254]  ? sysvec_apic_timer_interrupt+0xe/0x90
[4.071257]  ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
[4.071259]  ? delay_tsc+0x1e/0xa0
[4.071262]  dm_hw_init+0x12/0x30 [amdgpu]
[4.071587]  amdgpu_device_init+0x1e42/0x24a0 [amdgpu]
[4.071838]  amdgpu_driver_load_kms+0x19/0x190 [amdgpu]
[4.072087]  amdgpu_pci_probe+0x165/0x4c0 [amdgpu]
[4.072335]  local_pci_probe+0x42/0xa0
[4.072338]  pci_device_probe+0xc7/0x240
[4.072340]  really_probe+0x19b/0x3e0
[4.072343]  ? __pfx___driver_attach+0x10/0x10
[4.072344]  __driver_probe_device+0x78/0x160
[4.072346]  driver_probe_device+0x1f/0x90
[4.072348]  __driver_attach+0xd2/0x1c0
[4.072349]  bus_for_each_dev+0x85/0xd0
[4.072352]  bus_add_driver+0x116/0x220
[4.072354]  driver_register+0x59/0x100
[4.072356]  ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]
[4.072601]  do_one_initcall+0x58/0x320
[4.072604]  do_init_module+0x60/0x240
[4.072606]  init_module_from_file+0x89/0xe0
[4.072608]  ? generic_update_time+0x4e/0x60
[4.072612]  idempotent_init_module+0x120/0x2b0
[4.072614]  __x64_sys_finit_module+0x5e/0xb0
[4.072616]  do_syscall_64+0x61/0x120
[4.072619]  ? exit_to_user_mode_prepare+0x40/0x1e0
[4.072621]  ? syscall_exit_to_user_mode+0x2b/0x40
[4.072622]  ? do_syscall_64+0x70/0x120
[4.072624]  ? syscall_exit_to_user_mode+0x2b/0x40
[4.072625]  ? do_syscall_64+0x70/0x120
[4.072627]  ? syscall_exit_to_user_mode+0x2b/0x40
[4.072628]  ? do_syscall_64+0x70/0x120
[4.072630]  ? exit_to_user_mode_prepare+0x40/0x1e0
[4.072631]  ? syscall_exit_to_user_mode+0x2b/0x40
[4.072633]  ? do_syscall_64+0x70/0x120
[4.072634]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[4.072636] RIP: 0033:0x7f9eac011059
[4.072638] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
f0 

Bug#1029939: libshaderc.so: Re: libshaderc1: underlinked shared library

[Witold Baryluk]

Package: libshaderc-dev
Version: 2023.2-1
Followup-For: Bug #1029939
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

I am seeing the same issue:

$ objdump -T  
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libshaderc.so | grep 
UND | grep Base
  D  *UND*    Base
_ZN7glslang8TProgram10getInfoLogEv
  D  *UND*    Base
_ZN7glslang7TShader17setNanMinMaxClampEb
  D  *UND*    Base
_ZN7glslang7TShader10setInvertYEb
  D  *UND*    Base
_ZN7glslang8TProgramD1Ev
  D  *UND*    Base
_ZN7glslang7TShader5parseEPK16TBuiltInResourcei8EProfilebb11EShMessagesRNS0_8IncluderE
  D  *UND*    Base
_ZN7glslang17InitializeProcessEv
  D  *UND*    Base
_ZN7glslang7TShader18setShiftUboBindingEj
  D  *UND*    Base
_ZN7glslang7TShader10preprocessEPK16TBuiltInResourcei8EProfilebb11EShMessagesPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERNS0_8IncluderE
  D  *UND*    Base
_ZTVN8spvtools5utils5TimerE
  D  *UND*    Base
_ZN7glslang7TShader22setShiftTextureBindingEj
  D  *UND*    Base
_ZN7glslang7TShader22setShiftSamplerBindingEj
  D  *UND*    Base
_ZN7glslang7TShader16setHlslIoMappingEb
  D  *UND*    Base
_ZN7glslang16GetKhronosToolIdEv
  D  *UND*    Base
_ZN7glslang8TProgram4linkE11EShMessages
  D  *UND*    Base
_ZN7glslang14TPoolAllocator4pushEv
  D  *UND*    Base
_ZN7glslang14TPoolAllocator8allocateEm
  D  *UND*    Base
_ZN7glslang22GetThreadPoolAllocatorEv
  D  *UND*    Base
_ZN7glslang8TProgramC1Ev
  D  *UND*    Base
_ZN7glslang7TShader18setShiftUavBindingEj
  D  *UND*    Base
_ZN7glslang7TShaderC1E11EShLanguage
  D  *UND*    Base
_ZN7glslang7TShader10getInfoLogEv
  D  *UND*    Base
_ZN7glslang13TIntermediate16improperStraddleERKNS_5TTypeEii
  D  *UND*    Base
_ZN8spvtools5utils9BitVector2OrERKS1_
  D  *UND*    Base
_ZN7glslang14TPoolAllocator3popEv
  D  *UND*    Base
_ZN7glslang7TShader30setTextureSamplerTransformModeE30EShTextureSamplerTransformMode
  D  *UND*    Base
_ZN7glslang7TShader19setShiftSsboBindingEj
  D  *UND*    Base
_ZN7glslang13TIntermediate18getMemberAlignmentERKNS_5TTypeERiS4_NS_14TLayoutPackingEb
  D  *UND*    Base
_ZNK7glslang13TIntermediate17findLinkerObjectsEv
  D  *UND*    Base
_ZN7glslang7TShader29setStringsWithLengthsAndNamesEPKPKcPKiS4_i
  D  *UND*    Base
_ZN7glslang13TIntermediate22getBaseAlignmentScalarERKNS_5TTypeERi
  D  *UND*    Base
_ZN7glslang7TShader21setResourceSetBindingERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE
  D  *UND*    Base
_ZN7glslang7TShader19setAutoMapLocationsEb
  D  *UND*    Base
_ZN7glslang7TShader13setEntryPointEPKc
  D  *UND*    Base
_ZN8spvtools5utils5Timer6ReportEPKc
  D  *UND*    Base
_ZN7glslang7TShader18setAutoMapBindingsEb
  w   D  *UND*    Base
_ITM_deregisterTMCloneTable
  D  *UND*    Base
_ZN7glslang15FinalizeProcessEv
  D  *UND*    Base
_ZN7glslang8TProgram5mapIOEPNS_14TIoMapResolverEPNS_9TIoMapperE
  D  *UND*    Base
_ZN7glslang7TShaderD1Ev
  w   D  *UND*    Base__gmon_start__
  D  *UND*    Base
_ZN7glslang7TShader20setShiftImageBindingEj
  w   D  *UND*    Base
_ITM_registerTMCloneTable
  D  *UND*    Base
_ZN8spvtools5utils21PrintTimerDescriptionEPSob
   

Bug#848972: Fixed in Ubuntu

[Ferenc Wágner]

On Sun, 11 Feb 2024 13:11:51 +0100 Holger Wansing  wrote:

> Ferenc Wágner  wrote (Mon, 26 Jun 2023 12:27:49 +0200):
>
>> This issue was fixed in 1.178ubuntu12, as detailed at
>> https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1824227
>> Please consider taking over the fix.
> 
> I have grabbed the changings from
> https://git.launchpad.net/ubuntu/+source/console-setup/commit/?h=applied/ubuntu/disco=dc3395232928c2a3f53c7e5e29ad25a2638ddcae
> Patch attached.  Any objections?

Hi Holger,

None from my part, FWIW (very little).  I'd thank the original
author in the changelog entry, though.
-- 
Thanks for you work,
Feri.

Bug#1063713: linux-image-6.1.0-18-amd64: apt fails to install the kernel version, reports problem with building modules

[User]

Package: src:linux
Version: 6.1.76-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: gnomedeu...@gmail.com


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

** Model information
sys_vendor: ASUSTeK COMPUTER INC.
product_name: VivoBook S13 X330FN_S330FN
product_version: 1.0   
chassis_vendor: ASUSTeK COMPUTER INC.
chassis_version: 1.0   
bios_vendor: American Megatrends Inc.
bios_version: X330FN.304
board_vendor: ASUSTeK COMPUTER INC.
board_name: X330FN
board_version: 1.0   

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Coffee Lake HOST and DRAM 
Controller [8086:3e34] (rev 0c)
Subsystem: ASUSTeK Computer Inc. Coffee Lake HOST and DRAM Controller 
[1043:1631]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation WhiskeyLake-U GT2 
[UHD Graphics 620] [8086:3ea0] (rev 02) (prog-if 00 [VGA controller])
DeviceName: VGA
Subsystem: ASUSTeK Computer Inc. WhiskeyLake-U GT2 [UHD Graphics 620] 
[1043:1d1e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 0c)
Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/E3-1500 v5/6th Gen 
Core Processor Thermal Subsystem [1043:1631]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy

00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / 
E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v5/v6 / E3-1500 v5 / 
6th/7th/8th Gen Core Processor Gaussian Mixture Model [1043:1631]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:12.0 Signal processing controller [1180]: Intel Corporation Cannon Point-LP 
Thermal Controller [8086:9df9] (rev 30)
Subsystem: ASUSTeK Computer Inc. Cannon Point-LP Thermal Controller 
[1043:1631]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal

00:14.0 USB controller [0c03]: Intel Corporation Cannon Point-LP USB 3.1 xHCI 
Controller [8086:9ded] (rev 30) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Cannon Point-LP USB 3.1 xHCI 
Controller [1043:201f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Cannon Point-LP Shared SRAM 
[8086:9def] (rev 30)
Subsystem: Intel Corporation Cannon Point-LP Shared SRAM [8086:7270]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:14.3 Network controller [0280]: Intel Corporation Cannon Point-LP CNVi 
[Wireless-AC] [8086:9df0] (rev 30)
DeviceName: WLAN
Subsystem: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] 
[8086:0034]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

00:15.0 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial 
IO I2C Controller #0 [8086:9de8] (rev 30)
Subsystem: ASUSTeK Computer Inc. Cannon Point-LP Serial IO I2C 
Controller [1043:1631]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci

00:15.1 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP Serial 
IO 

Bug#1063683: lxappearance: segfault when removing cursor theme

[наб]

gdb says this is a null theme in on_remove_theme_clicked():
-- >8 --
Reading symbols from lxappearance...
Reading symbols from 
/usr/lib/debug/.build-id/94/079b37c65443f89e318af943680a890f1ad940.debug...

warning: Can't open file /SYSV (deleted) during file-backed mapping 
note processing
[New LWP 6213]
[New LWP 6221]
[New LWP 6219]
[New LWP 6220]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `lxappearance'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xd7d77730 in on_remove_theme_clicked (btn=0xe2941690, 
user_data=) at ./src/icon-theme.c:174
174 gboolean both = theme->has_icon && theme->has_cursor;
[Current thread is 1 (Thread 0xb9f3c9c0 (LWP 6213))]
(gdb) p theme
$1 = (IconTheme *) 0x0
(gdb) bt
#0  0xd7d77730 in on_remove_theme_clicked (btn=0xe2941690, 
user_data=) at ./src/icon-theme.c:174
#1  0xb9e77dbc in _g_closure_invoke_va (closure=0xe291ce50, 
return_value=0x0, instance=0xe2941690, args=..., n_params=0, 
param_types=0x0) at ../../../gobject/gclosure.c:895
#2  0xb9e8e7ac in signal_emit_valist_unlocked (instance=0xe274ba00, 
instance@entry=0xe2941690, signal_id=signal_id@entry=178, 
detail=detail@entry=0, var_args=...) at ../../../gobject/gsignal.c:3516
#3  0xb9e940b4 in g_signal_emit_valist (instance=0xe2941690, 
signal_id=178, detail=0, var_args=...) at ../../../gobject/gsignal.c:3355
#4  0xb9e94174 in g_signal_emit (instance=, 
signal_id=, detail=) at 
../../../gobject/gsignal.c:3675
#5  0xba144ea4 in gtk_button_do_release (emit_clicked=1, 
button=0xe2941690) at ../../../gtk/gtkbutton.c:1845
#6  gtk_button_do_release (emit_clicked=1, button=0xe2941690) at 
../../../gtk/gtkbutton.c:1832
#7  gtk_real_button_released (button=0xe2941690) at 
../../../gtk/gtkbutton.c:1963
#8  0xb9e75f64 in g_type_class_meta_marshalv (closure=, 
return_value=, instance=, args=..., 
marshal_data=, n_params=, param_types=) at ../../../gobject/gclosure.c:1060
#9  0xb9e77dbc in _g_closure_invoke_va (closure=0xe278f400, 
return_value=0x0, instance=0xe2941690, args=..., n_params=0, 
param_types=0x0) at ../../../gobject/gclosure.c:895
#10 0xb9e8e7ac in signal_emit_valist_unlocked (instance=0xe274ba00, 
instance@entry=0xe2941690, signal_id=signal_id@entry=177, 
detail=detail@entry=0, var_args=...) at ../../../gobject/gsignal.c:3516
#11 0xb9e940b4 in g_signal_emit_valist (instance=0xe2941690, 
signal_id=177, detail=0, var_args=...) at ../../../gobject/gsignal.c:3355
#12 0xb9e94174 in g_signal_emit 
(instance=instance@entry=0xe2941690, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3675
#13 0xba142e24 in multipress_released_cb (gesture=0xe2941780, 
n_press=, x=, y=, 
widget=0xe2941690) at ../../../gtk/gtkbutton.c:666
#14 0xba0f9c34 in _gtk_marshal_VOID__INT_DOUBLE_DOUBLEv 
(closure=, return_value=, instance=, args=..., marshal_data=, n_params=, 
param_types=) at gtk/gtkmarshalers.c:4804
#15 0xb9e77dbc in _g_closure_invoke_va (closure=0xe2941a70, 
return_value=0x0, instance=0xe2941780, args=..., n_params=3, 
param_types=0xe2727730) at ../../../gobject/gclosure.c:895
#16 0xb9e8e7ac in signal_emit_valist_unlocked (instance=0xe27be5a0, 
instance@entry=0xe2941780, signal_id=signal_id@entry=188, 
detail=detail@entry=0, var_args=...) at ../../../gobject/gsignal.c:3516
#17 0xb9e940b4 in g_signal_emit_valist (instance=0xe2941780, 
signal_id=188, detail=0, var_args=...) at ../../../gobject/gsignal.c:3355
#18 0xb9e94174 in g_signal_emit 
(instance=instance@entry=0xe2941780, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3675
#19 0xba22f408 in gtk_gesture_multi_press_end (gesture=0xe2941780, 
sequence=sequence@entry=0x0) at ../../../gtk/gtkgesturemultipress.c:287
#20 0xb9e7b60c in g_cclosure_marshal_VOID__BOXEDv 
(closure=0xe27e43e0, return_value=, instance=0xe2941780, 
args=..., marshal_data=0xba22f340 , 
n_params=, param_types=0xe27e4410)
at ../../../gobject/gmarshal.c:1686
#21 0xb9e75f64 in g_type_class_meta_marshalv (closure=, 
return_value=, instance=, args=..., 
marshal_data=, n_params=, param_types=) at ../../../gobject/gclosure.c:1060
#22 0xb9e77dbc in _g_closure_invoke_va (closure=0xe27e43e0, 
return_value=0x0, instance=0xe2941780, args=..., n_params=1, 
param_types=0xe27e4410) at ../../../gobject/gclosure.c:895
#23 0xb9e8e7ac in signal_emit_valist_unlocked (instance=0xe27be5a0, 
instance@entry=0xe2941780, signal_id=signal_id@entry=183, 
detail=detail@entry=0, var_args=...) at ../../../gobject/gsignal.c:3516
#24 0xb9e940b4 in g_signal_emit_valist (instance=0xe2941780, 
signal_id=183, detail=0, var_args=...) at 

Bug#939406: ITP: ungoogled-chromium -- Web browser that aims to build a safer, faster, and more stable internet browsing experience

[Stefan Monnier]

> Please work on the already existing (and patched!) chromium in the archive
> instead of adding one additional chromium-based browser that then also lacks
> team power. If you need any additional patches on Debian's chromium that are
> in ungoogled chromium, make them available in Debian's chromium.

Does that mean that Debian's `chromium` is also "ungoogled"?
That would admittedly make a lot of sense.
I see a directory `ungoogled` in

https://sources.debian.org/src/chromium/121.0.6167.160-1/debian/patches/

but it contains a fairly trivial patch that doesn't do what I expect
"ungoogled" to mean.

If it is indeed, ungoogled, then the package's description should say
so, shouldn't it?  Currently it just says:

Description: web browser
 Web browser that aims to build a safer, faster, and more stable internet
 browsing experience. 
 
 This package contains the web browser component.

which doesn't hint at it being ungoogled at all.


Stefan

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Miguel Angel Rojas]

Hi Diederik,

> While 'annoying', this is expected behavior. It tries to load the newest
(-83)
Yes, this is the expected behavior from our Linux kernel. However, I agree
with you and these messages are very annoying and should be removed.

> It could be it wouldn't be shown if it had already found one of the
earlier logged firmware files.
Interesting theory! When the new version of the firmware packages is
uploaded, we can check again if the "'iwl-debug-yoyo.bin" message disappears

Why are you confused with the numbers?
>Bit confused about that version number, but looks like success.

And yes, wifi is working fine although I haven't properly done any
performance test yet.

Regards


On Sun, Feb 11, 2024 at 4:15 PM Diederik de Haas 
wrote:

> Hi Miguel,
>
> On Sunday, 11 February 2024 16:03:20 CET Miguel A. Rojas wrote:
> > I forgot to include you the dmesg as promised:
> >
> > [2.235947] iwlwifi :00:14.3: enabling device ( -> 0002)
> > [2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id
> > 0x80401 wfpm id 0x8030
> > [2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430,
> > rfid=0x10a100
> > [2.237845] iwlwifi :00:14.3: firmware: failed to load
> > iwlwifi-so-a0-hr-b0-83.ucode (-2)
> > [2.237867] iwlwifi :00:14.3: firmware: failed to load
> > iwlwifi-so-a0-hr-b0-83.ucode (-2)
> > ... more firmware load failures
> > [2.238098] iwlwifi :00:14.3: Direct firmware load for
> > iwlwifi-so-a0-hr-b0-73.ucode failed with error -2
> > [2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware
> > iwlwifi-so-a0-hr-b0-72.ucode
>
> While 'annoying', this is expected behavior. It tries to load the newest
> (-83)
> and when it can't find that, it tries an older one and ends up with '-72'.
>
> > [2.247819] iwlwifi :00:14.3: api flags index 2 larger than
> > supported by driver
> > [2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version:
> > 0.0.2.36
> > [2.248049] iwlwifi :00:14.3: firmware: failed to load
> > iwl-debug-yoyo.bin (-2)
> <-
> > [2.248067] iwlwifi :00:14.3: firmware: failed to load
> > iwl-debug-yoyo.bin (-2)
> <-
>
> This 'iwl-debug-yoyo.bin' is a familiar one, but this file is NOT
> available in
> the upstream linux-firmware repo.
> It could be it wouldn't be shown if it had already found one of the
> earlier
> logged firmware files.
> I might look into this particular issue at some later date.
>
> > [2.248078] iwlwifi :00:14.3: loaded firmware version
> > 72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm
>
> Bit confused about that version number, but looks like success ...
>
> > [2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201
> > 160MHz, REV=0x430
> > [2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> > [2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> > [2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> > [2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
> > [2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100
> > [2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee
> > [2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0
> > [6.570171] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> > [6.570263] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> > [6.570275] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> > [6.570307] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
> > [6.644756] iwlwifi :00:14.3: Registered PHC clock: iwlwifi-PTP,
> > with index: 0
> > [6.809353] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> > [6.809386] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> > [6.809397] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> > [6.809408] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
>
> ... and from this it seems the device appears to be working properly?
>
> If that's indeed the case then this bug would essentially be a request for
> a
> new upstream version.
>
> Cheers,
>   Diederik

Bug#1063712: check-dfsg-status: integration of monthly cron job with systemd-cron

[Alexandre Detiste]

Package: check-dfsg-status
Version: 1.33
Severity: minor
X-Debbugs-Cc: Holger Levsen , наб 


Hi,

Unless #1026287 "use systemd .timer unit instead of /etc/cron.monthly"
got implemented, would it be possible to ship a
tiny 2 lines "old-style-mail.conf"  drop-in systemd overide that
overides how systemd-cron will style the monthly report ?

This drop-in would have no effect on Vixie cron or cronie.

Greetings,

Alexandre

PS: this need a not yet released systemd-cron to actually work.


$ systemctl cat cron-monthly-check-dfsg-status.service
# /run/systemd/generator/cron-monthly-check-dfsg-status.service
[Unit]
Description=[Cron] /etc/cron.monthly/check-dfsg-status
Documentation=man:systemd-crontab-generator(8)
SourcePath=/etc/cron.monthly/check-dfsg-status
OnFailure=cron-mail@%n:Failure.service
OnSuccess=cron-mail@%n:Success:nonempty.service

[Service]
User=root
Type=oneshot
IgnoreSIGPIPE=false
SyslogFacility=cron
KillMode=process
ExecStart=/etc/cron.monthly/check-dfsg-status

# 
/usr/lib/systemd/system/cron-monthly-check-dfsg-status.service.d/old-style-mail.conf

[Service]
Environment=CRON_MAIL_FORMAT=nometadata



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.13-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Diederik de Haas]

Hi Miguel,

On Sunday, 11 February 2024 16:03:20 CET Miguel A. Rojas wrote:
> I forgot to include you the dmesg as promised:
> 
> [2.235947] iwlwifi :00:14.3: enabling device ( -> 0002)
> [2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id
> 0x80401 wfpm id 0x8030
> [2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430,
> rfid=0x10a100
> [2.237845] iwlwifi :00:14.3: firmware: failed to load
> iwlwifi-so-a0-hr-b0-83.ucode (-2)
> [2.237867] iwlwifi :00:14.3: firmware: failed to load
> iwlwifi-so-a0-hr-b0-83.ucode (-2)
> ... more firmware load failures
> [2.238098] iwlwifi :00:14.3: Direct firmware load for
> iwlwifi-so-a0-hr-b0-73.ucode failed with error -2
> [2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware
> iwlwifi-so-a0-hr-b0-72.ucode

While 'annoying', this is expected behavior. It tries to load the newest (-83) 
and when it can't find that, it tries an older one and ends up with '-72'.

> [2.247819] iwlwifi :00:14.3: api flags index 2 larger than
> supported by driver
> [2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version:
> 0.0.2.36
> [2.248049] iwlwifi :00:14.3: firmware: failed to load
> iwl-debug-yoyo.bin (-2) <-
> [2.248067] iwlwifi :00:14.3: firmware: failed to load
> iwl-debug-yoyo.bin (-2) <-

This 'iwl-debug-yoyo.bin' is a familiar one, but this file is NOT available in 
the upstream linux-firmware repo.
It could be it wouldn't be shown if it had already found one of the earlier 
logged firmware files.
I might look into this particular issue at some later date.

> [2.248078] iwlwifi :00:14.3: loaded firmware version
> 72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm

Bit confused about that version number, but looks like success ...

> [2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201
> 160MHz, REV=0x430
> [2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> [2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> [2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> [2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
> [2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100
> [2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee
> [2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0
> [6.570171] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> [6.570263] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> [6.570275] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> [6.570307] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
> [6.644756] iwlwifi :00:14.3: Registered PHC clock: iwlwifi-PTP,
> with index: 0
> [6.809353] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
> [6.809386] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
> [6.809397] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
> [6.809408] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10

... and from this it seems the device appears to be working properly?

If that's indeed the case then this bug would essentially be a request for a 
new upstream version.

Cheers,
  Diederik

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

Bug#1063709: lintian: should recommend gobject-introspection for dh --with=gir, not gobject-introspection-bin

[Simon McVittie]

Control: forwarded -1 
https://salsa.debian.org/lintian/lintian/-/merge_requests/492
Control: tags -1 + patch

On Sun, 11 Feb 2024 at 13:44:27 +, Simon McVittie wrote:
> `lintian -Ii ostree_2024.1-1.dsc` reports:
> 
> E: ostree source: missing-build-dependency-for-dh-addon gir (does not satisfy 
> gobject-introspection-bin:any) [debian/rules]
...
> Perhaps
> lib/Lintian/Data/Debhelper/Addons.pm could learn to have a hand-maintained
> list of special cases, "if you would generate a dependency on package x,
> use package y instead", and add
> gobject-introspection-bin => gobject-introspection to that list?

In fact that list already exists. Fix proposed in
https://salsa.debian.org/lintian/lintian/-/merge_requests/492

smcv

Bug#964290: lintian: FP missing-build-dependency-for-dh-addon gir => gobject-introspection

[Simon McVittie]

Control: tags -1 + patch

On Sat, 04 Jul 2020 at 23:35:17 -0700, Felix Lechner wrote:
> In my package liferea, I am getting this error:
> 
> missing-build-dependency-for-dh-addon gir => gobject-introspection
> 
> but I have in my control: gobject-introspection | dh-sequence-gir

Fix proposed in
https://salsa.debian.org/lintian/lintian/-/merge_requests/492

smcv

Bug#1062703: firmware-realtek: Direct firmware load for rtl_nic/rtl8125b-2.fw failed with error -2

[Miguel A. Rojas]

Hi Diederik,

I forgot to include you the dmesg as promised:

[    2.235947] iwlwifi :00:14.3: enabling device ( -> 0002)
[    2.237778] iwlwifi :00:14.3: Detected crf-id 0x1300504, cnv-id 
0x80401 wfpm id 0x8030
[    2.237805] iwlwifi :00:14.3: PCI dev 7a70/0074, rev=0x430, 
rfid=0x10a100
[    2.237845] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-83.ucode (-2)
[    2.237867] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-83.ucode (-2)
[    2.237874] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-83.ucode failed with error -2 
<-
[    2.237879] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-82.ucode (-2)
[    2.237890] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-82.ucode (-2)
[    2.237896] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-82.ucode failed with error -2
[    2.237900] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-81.ucode (-2)
[    2.237916] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-81.ucode (-2)
[    2.237927] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-81.ucode failed with error -2
[    2.237932] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-80.ucode (-2)
[    2.237945] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-80.ucode (-2)
[    2.237955] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-80.ucode failed with error -2
[    2.237958] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-79.ucode (-2)
[    2.237968] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-79.ucode (-2)
[    2.237975] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-79.ucode failed with error -2
[    2.237978] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-78.ucode (-2)
[    2.237988] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-78.ucode (-2)
[    2.237994] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-78.ucode failed with error -2
[    2.237998] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-77.ucode (-2)
[    2.238007] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-77.ucode (-2)
[    2.238014] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-77.ucode failed with error -2
[    2.238018] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-76.ucode (-2)
[    2.238027] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-76.ucode (-2)
[    2.238034] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-76.ucode failed with error -2
[    2.238038] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-75.ucode (-2)
[    2.238052] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-75.ucode (-2)
[    2.238059] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-75.ucode failed with error -2
[    2.238062] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-74.ucode (-2)
[    2.238072] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-74.ucode (-2)
[    2.238078] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-74.ucode failed with error -2
[    2.238082] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-73.ucode (-2)
[    2.238091] iwlwifi :00:14.3: firmware: failed to load 
iwlwifi-so-a0-hr-b0-73.ucode (-2)
[    2.238098] iwlwifi :00:14.3: Direct firmware load for 
iwlwifi-so-a0-hr-b0-73.ucode failed with error -2
[    2.241012] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-so-a0-hr-b0-72.ucode
[    2.247819] iwlwifi :00:14.3: api flags index 2 larger than 
supported by driver
[    2.247832] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 
0.0.2.36
[    2.248049] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2) <-
[    2.248067] iwlwifi :00:14.3: firmware: failed to load 
iwl-debug-yoyo.bin (-2) <-
[    2.248078] iwlwifi :00:14.3: loaded firmware version 
72.daa05125.0 so-a0-hr-b0-72.ucode op_mode iwlmvm
[    2.653952] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 
160MHz, REV=0x430

[    2.769070] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x3f
[    2.769102] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[    2.769110] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90
[    2.769118] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x10
[    2.769154] iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100
[    2.834751] iwlwifi :00:14.3: base HW address: bc:09:1b:d3:e2:ee
[    2.849492] iwlwifi :00:14.3 wlp0s20f3: renamed from wlan0
[    6.570171] iwlwifi :00:14.3: 

Bug#1063318:

[Boian Bonev]

Hi,

I have fixed the typo that prevented gpsd from building. Also did a couple of
other small fixes and uploaded 3.25-3~exp1 to experimental.

With best regards,
b.