Bug#1040601: python3-typedload-doc: broken symlink: /usr/share/doc/python3-typedload/docs/README.md -> ../README.md

[Salvo Tomaselli]

Thank you for your report.

The fix will be included in the next version.

Il giorno ven 7 lug 2023 alle ore 21:23 Andreas Beckmann
 ha scritto:
>
> Package: python3-typedload-doc
> Version: 2.24-1
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink:
>
> 0m32.5s ERROR: FAIL: Broken symlinks:
>   /usr/share/doc/python3-typedload/docs/README.md -> ../README.md 
> (python3-typedload-doc)
>
>
> cheers,
>
> Andreas



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#1036971: pwsafe: empty window after internal timeout or screen blank

[Bill Wohler]

Just confirmed that it is version 1.16 that I'm running at work. It was
built from source on a Red Hat 8 system.

Bill Wohler  wrote:

> Hi Bill,
> 
> I can confirm this regression as I experienced it when I upgraded from
> bullseye (perhaps with a more recent version than 1.12 from backports)
> to bookworm (with PasswordSafe 1.16) yesterday.
> 
> Normally, when the database is locked after some time of inactivity, the
> password dialog appears. This dialog is no longer appearing. That's the
> bug.
> 
> Giuseppe, there is a workaround to get the password dialog that takes
> four more button presses than we'd like: press the Close button followed
> by the Open button and double-click on your database file.
> 
> Bill, I *think* I have a compiled PasswordSafe 1.16 from upstream at
> work that works as expected. I'll double-check the version tomorrow and
> let you know.
> 
> I wonder if this is a GNOME 43 incompatibility...
> 
> -- 
> Bill Wohler  aka 
> http://www.newt.com/wohler/, GnuPG ID:610BD9AD

-- 
Bill Wohler  aka 
http://www.newt.com/wohler/, GnuPG ID:610BD9AD

Bug#1040630: gavodachs autopkg tests fail with pillow 10.0.0

[Matthias Klose]

reported upstream: https://github.com/python-pillow/Pillow/issues/7275

Bug#1040790: installation-reports: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation

[yogg]

Package: installation-reports
Severity: serious
Tags: d-i
Justification: https://wiki.debian.org/MachineId

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: CD/network
Image version: http://ftp.debian.org/debian/dists/bookworm/main/installer-amd64/
Date: 2023-07-10

Machine: Virtual-Maschine
Partitions:
Disk /dev/vda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcf0c07c3

Device Boot   Start  End  Sectors  Size Id Type
/dev/vda1  2048  2000895  1998848  976M 82 Linux swap / Solaris
/dev/vda2  *2000896 20969471 189685769G 83 Linux



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

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

Comments/Problems:

After installation was finished and the system has been restarted the files 
"/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked in any way (no 
soft or hardlink) and the ID inside the files differ from each other.

Expected:
"cat /etc/machine-id /var/lib/dbus/machine-id" should return the same ID two 
times

Workaround:
rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen 
--ensure=/etc/machine-id && dbus-uuidgen --ensure


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230607"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux debian-test 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.27-1 (2023-05-08) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC 
[Natoma] [8086:1237] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA 
[Natoma/Triton II] [8086:7000]
lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE 
[Natoma/Triton II] [8086:7010]
lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
lspci -knn: Kernel driver in use: ata_piix
lspci -knn: Kernel modules: ata_piix, ata_generic
lspci -knn: 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI 
[8086:7113] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Cirrus Logic GD 5446 
[1013:00b8]
lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
lspci -knn: Kernel driver in use: cirrus
lspci -knn: Kernel modules: cirrus
lspci -knn: 00:03.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network 
device [1af4:1000]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0001]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:04.0 Communication controller [0780]: Red Hat, Inc. Virtio 
console [1af4:1003]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0003]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:05.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio block 
device [1af4:1001]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0002]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:06.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory 
balloon [1af4:1002]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0005]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lspci -knn: 00:07.0 Unclassified device [00ff]: Red Hat, Inc. Virtio RNG 
[1af4:1005]
lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0004]
lspci -knn: Kernel driver in use: virtio-pci
lspci -knn: Kernel modules: virtio_pci
lsmod: Module  Size  Used by
lsmod: fuse  176128  0
lsmod: battery28672  0
lsmod: dm_mod184320  0
lsmod: md_mod192512  0
lsmod: xfs  1945600  0
lsmod: jfs   221184  0
lsmod: btrfs1777664  0
lsmod: xor24576  1 btrfs
lsmod: 

Bug#1040630: gavodachs autopkg tests fail with pillow 10.0.0

[Markus Demleitner]

On Sat, Jul 08, 2023 at 09:23:21AM +0200, Matthias Klose wrote:
> 110s From it/q:
> 110s  ERROR SCS has a valid response
> 110s  ERROR TAP query with pgsphere yields plausible result

Interesting -- this fails because the server that's being tested
does not come up because:

  module 'PIL.Image' has no attribute 'ANTIALIAS'

And indeed, it does not:

  >>> from PIL import Image
  >>> Image.ANTIALIAS
  Traceback (most recent call last):
File "", line 1, in 
  AttributeError: module 'PIL.Image' has no attribute 'ANTIALIAS'

Now... this seems to be a fairly breaking change (or at least I
suspect there's a lot of code with Image.ANTIALIAS out there).
However, when looking for resize or ANTIALIAS in the upstream
changelog, I don't see it mentioned:
https://github.com/python-pillow/Pillow/blob/main/CHANGES.rst

That made me curious; ANTIALIAS as an alias of LANCZOS was dropped in
upstream commit f8e4e9c2dd94c6f4789639dd891b8a6d5fb16e14 with the
terse commit message "Added enums", where there's this:

  ...
  -LANCZOS = ANTIALIAS = 1

  -_filters_support = {BOX: 0.5, BILINEAR: 1.0, HAMMING: 1.0, BICUBIC: 2.0, 
LANCZOS: 3.0}
  +# resampling filters (also defined in Imaging.h)
  +class Resampling(IntEnum):
  +NEAREST = 0
  +BOX = 4
  +BILINEAR = 2
  +HAMMING = 5
  +BICUBIC = 3
  +LANCZOS = 1

Whether dropping the widely-documented ANTIALIAS alias was done
deliberately or not I can't say.  And hence I'll not decide whether or
not that's worth an upstream bug.  Instead, I'lljust move to LANCZOS
in DaCHS.

DaCHS users: if you urgently need the package on unstable, please use
our beta repo (https://soft.g-vo.org/repo) for the time being.
Release 2.8 wasn't our best one anyway.  Release 2.9 ought to come
around October-ish anyhow, at which time I'll close this bug (or
should be reminded to close it).

Bug#1040521: tpm2-tss: FTBFS (test failures)

[Ying-Chun Liu (PaulLiu)]

Hi Bastian,

Thanks for adding more information here.

I've looked into the problem. The s390x should be the endian problem.
While the rest (i386, armel, armhf) is due to it is 32-bits.

According to the build log:
https://buildd.debian.org/status/fetch.php?pkg=tpm2-tss=armhf=4.0.1-1=1688685120=0

The test failed at Test: tcti_libtpms_remap_state_posix_fallocate_fail_test

We can look into the code.
First.
At test/unit/tcti-libtpms.c:1097, expect_value(TPMLIB_Process, cmd, cmd);
And cmd is an array.
unsigned char cmd[] = {0x80, 0x01, 0x00, 0x00, 0x00, 0x0c, 0x00, 0x00, 0x01
, 0x44, 0x00, 0x00};

At test/unit/tcti-libtpms.c:136, check_expected_ptr(cmd);

So the problem is actually at test/unit/tcti-libtpms.c:1097.
Because it tries to convert a pointer to integer.
The expect_value() of CMocka is expect_value(#func, #para, LargestIntegralType 
val)
So that cmd is converted to Integral Type.
I think we might want to use expect_memory() instead?
expect_memory(#func, #para, void* mem, size_t size)
So that cmd is pointer rather than converted to int.

Yours,
Paul



OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040675: ca-certificates-java: incorrect "Breaks:" versions about ubuntu

[Matthias Klose]

Control: severity -1 important

openjdk-18 has been removed from testing in November 2022, and I now filed a bug 
report to remove it from unstable (#1040789). It is unmaintained upstream, and 
superseded by newer OpenJDK releases.


The versions used in these breaks work both for Debian and Ubuntu. If there are 
mistakes made, please tell them. Shouting "this is Debian" doesn't help.


I'll close this issue once openjdk-18 is also removed from unstable.

Bug#1039562: package install error is "fine"

[olivier sallou]

Installation shows an "error" because it tries to connect to database with
configuration defaults (will fail at first install if default user/password
does not exists in database, and this is fine).

In case of "failure" using found configuration
(/usr/share/gmod/chado/conf/gmod-chado.conf)  , it explains the expected
setup steps to user and exists with code 0.

So "error" is not a real error , but just an install setup test to check if
user need to configure database access, and exit as expected with error
code 0 (and package is installed as expected).

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

Bug#1040789: RM: please remove openjdk-18 from unstable

[Matthias Klose]

Package: ftp.debian.org

please remove openjdk-18 from unstable, superseded by new openjdk releases.

Bug#1040788: RFS: gcc-sh-elf/7 -- GNU C compiler for embedded SuperH devices

[John Scott]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-electronics-de...@alioth-lists.debian.net
Control: block 1026335 by -1

Dear mentors,

I am looking for a sponsor for my package "gcc-sh-elf":

 * Package name : gcc-sh-elf
   Version  : 7
 * License  : various
 * Vcs  : 
https://salsa.debian.org/electronics-team/toolchains/gcc-sh-elf
   Section  : devel

The source builds the following binary packages:

  gcc-sh-elf - GNU C compiler for embedded SuperH devices
  libnewlib-sh-elf-dev - small ISO C standard library for embedded SuperH 
devices

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

  https://mentors.debian.net/package/gcc-sh-elf/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gcc-sh-elf/gcc-sh-elf_7.dsc

Changes since the last upload:

 gcc-sh-elf (7) unstable; urgency=medium
 .
   * Include the full used Newlib source package version number in
 the libnewlib-sh-elf-dev binary package version number.
 This is necessary so we can tell what source package version was used.

This is a one-line change in debian/rules that is necessary for us to set the 
correct Built-Using field for carl9170fw; see that RFS to see the details 
spelled out. By the time you're reading this, if the moreinfo tag is removed 
from carl9170fw, then that's ready to go too and would also appreciate your 
careful review.

I will push changes to Git once this is uploaded.


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#858337: apt-show-versions: wrong output when version of an installed package is missing from the Packages files

[Christoph Martin]

Control: tags -1 + moreinfo

Hi Vincent,

Am 05.07.23 um 12:13 schrieb Vincent Lefevre:

Control: retitle -1 apt-show-versions gives unreliable information
Control: severity -1 grave



I still can not reproduce your problem.

Please try to find out, which value is missing in a Packages file, which 
triggers this error, so that I can reproduce the problem.


Regards
Christoph


OpenPGP_signature
Description: OpenPGP digital signature

Bug#806989: game-data-packager: add support for "Caesar III" playable with CaesarIA engine

[Alexandre Detiste]

control: retitle -1 "game-data-packager: add support for "Caesar III"
playable with julius/augustus engines"

a GDP-generated package could definitively support _both_ engine,
like the Doom data packages can be used by several different engines.

It's then better to install the data in an engine agnostic path
like /usr/share/games/caesar3 or something
instead of /usr/share/games/{augustus|julius}

Ideally we should also support both v1.0.0.0 & v1.0.1.0 of the original CD/DVD
with the patches made available here:
   https://github.com/bvschaik/julius/wiki/Patches

Greetings,

Bug#1040787: dh-elpa: Lots of missing eln files

[Nikolaus Rath]

Package: dh-elpa
Severity: normal

After upgrading to bookworm, I'm getting many warnings when starting
emacs:

Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc Disable showing Disable 
logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/transient-0.2.0.30/transient.elc Disable 
showing Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async-bytecomp.elc Disable showing 
Disable logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc Disable showing Disable 
logging
Warning (comp): Cannot look-up eln file as no source file was found for 
/usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc Disable 
showing Disable logging

Looking at one randomly there seems to be a broken symlink for the .el
file:

nikratio@vostro /u/s/e/s/elpa> dir  
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async.*
lrwxrwxrwx 1 root  57 Feb 24 10:49 
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async.el -> 
/usr/share/emacs/site-lisp/elpa-src/async-1.9.3//async.el
-rw-r--r-- 1 root 12K Feb 24 10:49 
/usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc


I am not sure which package ought to ship
/usr/share/emacs/site-lisp/elpa-src/.

I suspect this is the same problem for all elpa-* packages, so I'm not
filing this against elpa-async but (my best guess) dh-elpa.



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

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

Versions of packages dh-elpa depends on:
ii  debhelper 13.11.4
ii  emacs 1:28.2+1-15
ii  emacs-gtk [emacs] 1:28.2+1-15
pn  libarray-utils-perl   
pn  libconfig-tiny-perl   
pn  libdebian-source-perl | dh-make-perl  
ii  libdpkg-perl  1.21.22
ii  libfile-find-rule-perl0.34-3
ii  libtext-glob-perl 0.11-3
ii  perl  5.36.0-7

dh-elpa recommends no packages.

dh-elpa suggests no packages.

Bug#1017587: ITP: fheroes2

[Alexandre Detiste]

For the record:

The package that Anatoliy once published to Mentors
has been recoverd and imported here:

   https://salsa.debian.org/games-team/fheroes2/-/commits/master

and then further improved and updated to version 1.0.5

Greetings,

Bug#1040786: RFP: wl-screenrec -- High performance wlroots screen recording, featuring hardware encoding

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: wl-screenrec
  Version : no release published
  Upstream Contact: Russell Greene 
* URL : https://github.com/russelltg/wl-screenrec
* License : Apache-2.0
  Programming Lang: Rust
  Description : High performance wlroots screen recording, featuring 
hardware encoding

High performance screen recorder for wlroots Wayland.

Uses dma-buf transfers to get surface, and uses the GPU to do both the
pixel format conversion and the encoding, meaning the raw video data
never touches the CPU, leaving it free to run your applications.

System Requirements:
* Wayland compositor supporting the following protocols:
  * wlr-output-management-unstable-v1 (missing in hikari, cage, gamescope, 
kwinft)
  * wlr-screencopy-unstable-v1 (missing in gamescope and kwinft)
  Known working examples: sway, hyprland, wayfire, labwc.
* VA-API encoding:
  * Intel iGPUs: libva-intel-media-driver or libva-intel-driver
  * AMD/ATI GPUs: mesa-gallium-va


There's wf-recorder already packaged in Debian, and probably
desktop-specific ones as well, but, according to this project's
README, wl-screenrec beats wf-recorder by something like an order of
magnitude, at least, in performance.

Bug#1026335: carl9170 needs to wait on a new gcc-sh-elf upload

[John Scott]

Control: tags -1 moreinfo

I've discovered an issue with how the Built-Using fields are generated.

Specifically, because gcc-sh-elf does not set a Built-Using field for Newlib, 
and because of the way the libnewlib-sh-elf-dev binary package is currently 
versioned, there is no way to precisely tell what version of the Newlib source 
package was used to generate libnewlib-sh-elf-dev and hence which gets baked 
into the carl9170 binaries. That means we can't set the Built-Using field right.

Fortunately this does not have to be fixed in Newlib: it can be fixed 
completely in gcc-sh-elf, so I will simply prepare a new upload that changes 
the format of the version numbers so we can tell what version of the Newlib 
source package was used. When ready, I will send an RFS for that package and 
mark it as blocking this one.


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1040785: reportbug: ID in /etc/machine-id and /var/lib/dbus/machine-id mismatch on fresh debian 12 installation

[yogg]

Package: reportbug
Version: 12.0.0
Severity: serious
Tags: d-i
Justification: https://wiki.debian.org/MachineId

Dear Maintainer,

   * What led up to the situation?
 - Installing debian 12 via the installer

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 - Normal install (also preseed install)

   * What was the outcome of this action?
 - After installation was finished and the system has been restarted the 
files "/etc/machine-id" and "/var/lib/dbus/machine-id" are not linked in any 
way (no soft or hardlink) and the ID inside the files differ from each other.

   * What outcome did you expect instead?
 - "cat /etc/machine-id /var/lib/dbus/machine-id" should return the same ID 
two times

   * Workaround
 - rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen 
--ensure=/etc/machine-id && dbus-uuidgen --ensure


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

** /root/.reportbugrc:
reportbug_version "12.0.0"
mode standard
ui text
realname "yogg"
email "deb...@x-net.at"
no-check-uid
smtphost "x-zimbra03.x"

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

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

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

reportbug recommends no packages.

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

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

python3-reportbug suggests no packages.

-- no debconf information

Bug#1040784: mariadb-server: Upgrade from Debian Bullseye to Debian Bookworm may crash if innodb_log_file_buffering=OFF and physical block size is 4096 bytes

[Leonardo Martinho]

Package: mariadb-server
Version: 1:10.11.3-1
Severity: important

Dear Maintainer,

* Upgrading from Debian 11 to Debian 12 renders mariadb-server to be
unusable
* I opened a bug report on the Mariadb Jira in order to analyse and fix
the issue. In this case it seems to have to do something with the
physical block size of the hard drive the innodb is on
* The bug was fixed in a recent commit 
(https://github.com/MariaDB/server/commit/c358e216d989a57f4188e766799fc83a4675c5d1)
* As this is a rather major issue which prevents upgrades and crashes
mariadb hard on such device configurations, this should be included
promptly in the next version of the package

-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable')
Architecture: s390x

Kernel: Linux 5.10.0-23-s390x (SMP w/1 CPU thread)
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 mariadb-server depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  galera-4   26.4.13-1
ii  gawk   1:5.2.1-2
ii  iproute2   6.1.0-3
ii  libc6  2.36-9
ii  libdbi-perl1.643-4
ii  libpam0g   1.5.2-6
ii  libssl33.0.9-1
ii  libstdc++6 12.2.0-14
ii  lsof   4.95.0-1
ii  mariadb-client 1:10.11.3-1
ii  mariadb-common 1:10.11.3-1
ii  mariadb-server-core1:10.11.3-1
ii  passwd 1:4.13+dfsg1-1+b1
ii  perl   5.36.0-7
ii  procps 2:4.0.2-3
ii  psmisc 23.6-1
ii  rsync  3.2.7-1
ii  socat  1.7.4.4-2
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages mariadb-server recommends:
pn  libhtml-template-perl   
pn  mariadb-plugin-provider-bzip2   
pn  mariadb-plugin-provider-lz4 
pn  mariadb-plugin-provider-lzma
pn  mariadb-plugin-provider-lzo 
pn  mariadb-plugin-provider-snappy  
pn  pv  

Versions of packages mariadb-server suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
pn  mariadb-test   
ii  netcat-openbsd 1.219-1

-- Configuration Files:
/etc/logcheck/ignore.d.paranoid/mariadb-server [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.paranoid/mariadb-server'
/etc/logcheck/ignore.d.server/mariadb-server [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.server/mariadb-server'
/etc/logcheck/ignore.d.workstation/mariadb-server [Errno 13] Permission denied: 
'/etc/logcheck/ignore.d.workstation/mariadb-server'
/etc/mysql/mariadb.conf.d/50-server.cnf changed [not included]

-- debconf information excluded

Bug#1040780: [Pkg-nagios-devel] Bug#1040780: icingaweb2 incompatible with php8.2

[Sebastiaan Couwenberg]

forcemerge 1040780 1037925
thanks

On 7/10/23 15:36, David Kunz wrote:

It would be nice if you could update this package for using with php8.2.


It has been:


https://salsa.debian.org/nagios-team/icingaweb2/-/blob/master/debian/patches/php8.2.patch

This issue is a duplicate of #1037925.

The deprecation notices should not prevent icingaweb2 from working.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1036637: Having compilation instructions would make things a lot easier.

[shirish शिरीष]

At bottom :-

On 10/07/2023, shirish शिरीष  wrote:
> Dear Oliver,
>
> I tried to locally compile the software using the build instructions
> shared at -
>
> https://codeberg.org/klartext/plio/src/branch/main/doc/buildinstall.md
>
> I just wanted to try make without using any special fonts or anything so did
> -
>
>  ~/games/plio/src$ make
> gcc -c -Wall -W  main.c
> In file included from dircontents.h:23,
>  from collection.h:23,
>  from main.c:23:
> image.h:18:10: fatal error: FreeImage.h: No such file or directory
>18 | #include 
>   |  ^
> compilation terminated.
> make: *** [Makefile.objects:140: main.o] Error 1
>
> Git log shows me the following -
>
> commit 4ac01b38108f206f29d4f570edc7d1fedb43f91b
> Author: Oliver Bandel 
> Date:   Mon Jun 19 02:14:55 2023 +0200
>
> commands.c: more doxy-documentation added
>
> Looking forward to help.
>
> --
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> https://creativecommons.org/licenses/by-nc/3.0/
> https://flossexperiences.wordpress.com
>
> E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
>

Was able to fix the issues by installing libfreeimage-dev and was able
to fix the font issue by writing #define FONT_NAME
"/usr/share/fonts/truetype/oxygen/OxygenMono-Regular.ttf"

Maybe you can add that one as a commit. I haven't found
roboto-mono.ttf at least in Debian :(

While there are quite a few mono spaced fonts. I have shared a few
that have been installed on my system (not the whole bunch)  -

https://paste.debian.net/1285488/

One issue that I found out is maximizing the Window is an issue. I use
mate as my window-manager. I do not have the key that you shared for
maximizing window. If possible, would like the minimize, maximize and
close that we have in MATE window manager. Sharing a screenshot of the
same.

Looking forward to updates.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
https://creativecommons.org/licenses/by-nc/3.0/
https://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#1040783: libvirt-daemon: libvirt firewalld zone is missing

[Niccolò Belli]

Package: libvirt-daemon
Version: 9.0.0-4
Severity: normal
X-Debbugs-Cc: darkba...@linuxsystems.it

Hi,
I've installed firewalld (with the default nftables backend) and libvirt-daemon 
(kvm backend) in Debian 12 Bookworm.
I've connected remotely via virt-manager (through ssh) and tried to create a 
routed network, but I get the following error:

Error creating virtual network: internal error: firewalld is set to use the 
nftables backend, but the required firewalld 'libvirt' zone is missing. Either 
set the firewalld backend to 'iptables', or ensure that firewalld has a 
'libvirt' zone by upgrading firewalld to a version supporting rule priorities 
(0.7.0+) and/or rebuilding libvirt with --with-firewalld-zone

which is weird considering libvirt seems to be built with -Dfirewalld=enabled.

What's missing? Why doesn't firewalld create the libvirt zone?
I want to use the nftables backend.

Niccolo'

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.3.1-3
ii  libblkid1   2.38.1-5+b1
ii  libc6   2.36-9
ii  libdevmapper1.02.1  2:1.02.185-2
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libparted2  3.5-3
ii  libpcap0.8  1.10.3-1
ii  libpciaccess0   0.17-2
ii  libselinux1 3.4-1+b6
ii  libtirpc3   1.3.3+ds-1
ii  libudev1252.6-1
ii  libvirt-daemon-driver-qemu  9.0.0-4
ii  libvirt09.0.0-4
ii  libxml2 2.9.14+dfsg-1.2

Versions of packages libvirt-daemon recommends:
pn  libvirt-daemon-driver-lxc   
pn  libvirt-daemon-driver-vbox  
pn  libvirt-daemon-driver-xen   
ii  libxml2-utils   2.9.14+dfsg-1.2
ii  lvm22.03.16-2
ii  mount   2.38.1-5+b1
pn  netcat-openbsd  
ii  qemu-system 1:7.2+dfsg-7
ii  qemu-system-x86 [qemu-kvm]  1:7.2+dfsg-7

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster   
pn  libvirt-daemon-driver-storage-iscsi-direct  
pn  libvirt-daemon-driver-storage-rbd   
pn  libvirt-daemon-driver-storage-zfs   
ii  libvirt-daemon-system   9.0.0-4
ii  numad   0.5+20150602-8+b1

-- no debconf information

Bug#1040782: gimp: Using wacom tablet to chose menu crashes gimp

[Graeme Vetterlein]

Package: gimp
Version: 2.10.34-1
Severity: important
X-Debbugs-Cc: none, Graeme Vetterlein 

Dear Maintainer,


Open GIMP (wilber-big.jpg) using mouse select pencil, draw a line,
change size (in menu) draw line.
Repeat using wacom bamboo tablet . as soon as you try to change size, Gimp
crashes (many other actions cause this abort, this is just a specific
example (this is immediately after ugrading SID from bookwork to trixie)



>From gimp crash report:




```
GNU Image Manipulation Program version 2.10.34
git-describe: GIMP_2_10_34
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs 
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-12 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin 
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release 
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch 
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
 --enable-offload-defaulted --without-cuda-driver --enable-checking=release 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14) 

# Libraries #
using babl version 0.1.106 (compiled against version 0.1.98)
using GEGL version 0.4.46 (compiled against version 0.4.42)
using GLib version 2.74.6 (compiled against version 2.74.5)
using GdkPixbuf version 2.42.10 (compiled against version 2.42.10)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.14 (compiled against version 1.50.12)
using Fontconfig version 2.14.1 (compiled against version 2.14.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Aborted

Stack trace:
```

# Stack traces obtained from PID 24950 - Thread 24950 #

[New LWP 24951]
[New LWP 24952]
[New LWP 24953]
[New LWP 24954]
[New LWP 24955]
[New LWP 24956]
[New LWP 24957]
[New LWP 24958]
[New LWP 24959]
[New LWP 24961]
[New LWP 25047]
[New LWP 25073]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___libc_read (nbytes=256, buf=0x7ffdb114eb30, fd=17) at 
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame 
* 1Thread 0x7f1fdfb84300 (LWP 24950) "gimp-2.10"   __GI___libc_read 
(nbytes=256, buf=0x7ffdb114eb30, fd=17) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7f1fdf2856c0 (LWP 24951) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7f1fdea846c0 (LWP 24952) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7f1fd7fff6c0 (LWP 24953) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7f1fde2836c0 (LWP 24954) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7f1fdda826c0 (LWP 24955) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  7Thread 0x7f1fdd2816c0 (LWP 24956) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7f1fdca806c0 (LWP 24957) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7f1fd6d516c0 (LWP 24958) "gmain"   0x7f1fe08709ef in 
__GI___poll (fds=0x5566263db0f0, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  10   Thread 0x7f1fd65506c0 (LWP 24959) "gdbus"   0x7f1fe08709ef in 
__GI___poll (fds=0x5566263ee460, nfds=3, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  11   Thread 0x7f1fad5ff6c0 (LWP 24961) "async"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  12   Thread 0x7f1fa30146c0 (LWP 25047) "swap writer" syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  13   Thread 0x7f1fa38156c0 (LWP 25073) "paint"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

Thread 13 (Thread 0x7f1fa38156c0 (LWP 25073) 

Bug#1040781: Package: waagent - Azure Agent doesn't create config files

[Alexander Kaufman]

Package: waagent
Version: 2.7.3.0-4.1

Hi dear Debian dev team,

I've just installed a new Debian 12 VM and uploaded it to Microsoft Azure. It 
is a minimal installation, even no standard packages. And I'm having a problem 
with waagent, which I've never seen before on Debian 11.

After installing of waagent it doesn't start properly:


  *   The directory /var/lib/waagent stays empty.
  *   The Azure website shows that the agent is not installed (see the 
screenshot in attachment).
  *   On the console of the VM I'm repeatedly getting the following:
 *   2023-07-10T10:37:45.473554Z INFO Daemon Daemon cloud-init is enabled: 
False
 *   2023-07-10T10:37:45.478989Z WARNING Daemon Daemon cloud-init does not 
appear to be enabled
 *   2023-07-10T10:43:05.552742Z INFO Daemon Daemon Waiting for cloud-init 
to copy ovf-env.xml to /var/lib/waagent/ovf-env.xml [1160 retries remaining, 
sleeping 1s between retries]
 *   2023-07-10T10:43:05.572947Z INFO Daemon Daemon Unable to get 
cloud-init enabled status from systemctl: Command '['systemctl', 'is-enabled', 
'cloud-init-local.service']' returned non-zero exit status 1.
 *   2023-07-10T10:43:05.597817Z INFO Daemon Daemon Unable to get 
cloud-init enabled status from service: Command '['service', 'cloud-init', 
'status']' returned non-zero exit status 4.

The VM image was created "at home" on a Hyper-V host by installing from the 
network ISO image of Debian 12, downloaded yesterday. No packages were 
selected, also standard system utilities were not selected. Then the virtual 
hard disk was transferred to Azure and mounted to the Azure VM with installing 
of the waagent afterwards, by running:


  *   apt update && apt full-upgrade && apt autoremove
  *   apt install waagent

Appreciate any help!

Thanks and kind regards,
Alexander K.

Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

[soh08a+cbo9nqx75gwzw]

Package: base-files
Version: 12.4
Followup-For: Bug #885414

Dear Maintainer,

I agree that spaces in filenames are a bad idea, and a policy should be made 
against that, however scripts should still handle spaces in filenames 
gracefully (in this case by quoting variables properly) instead of causing 
undefined behavior.

Bug#1040780: icingaweb2 incompatible with php8.2

[David Kunz]

Package: icingaweb2
Version:  2.11.4-2
Severity: normal

Hallo

Thank you, for maintaining icingaweb2.

We wanted to install icingaweb2 on bookworm with php8.2. When
configuring via the web interface the ldap connection, we kept
getting the following error message:

Deprecated: Creation of dynamic property Icinga\Web\Form\Validator
\InArray::$zfBreakChainOnFailure is deprecated in
/usr/share/icingaweb2/library/vendor/Zend/Form/Element.php on line 2176

It would be nice if you could update this package for using with php8.2.

Greetings,
David

Bug#1039967: [PATCH] autofs: Fix hang on kerberos authenticated ldap

[Christopher Huhn]

> Could you please fix this in a point release for bookworm
> (and bullseye)?

I have prepare an autofs update targetting Debian bullseye, is it  
possible for you to test this?


I cherry-picked another patch into this proposed update, here is the  
list of changes:

https://salsa.debian.org/debian/autofs/-/commits/bullseye

Here is my personal package repo where I uploaded an amd64 build of  
the autofs 5.1.7+deb11u1 proposed update:

https://packages.sunweavers.net/debian/pool/main/a/autofs/

Let me know if this works for you.

Works for us, nice!

Grüße aus Darmstadt

Christopher


--
Christopher Huhn
Linux & web group
IT department

GSI Helmholtzzentrum fuer Schwerionenforschung GmbH
Planckstr. 1, 64291 Darmstadt, https://www.gsi.de/

Sitz der Gesellschaft / Registered Office:Darmstadt
Handelsregister   / Commercial Register:
Amtsgericht Darmstadt, HRB 1528

Geschaeftsfuehrung/ Managing Directors:
 Professor Dr. Paolo Giubellino, Joerg Blaurock

Vorsitzender des GSI-Aufsichtsrates /
  Chairman of the GSI Supervisory Board:
  Ministerialdirigent Dr. Volkmar Dietz

Bug#1040779: reportbug: option -V / --package-version does not put the version in the bug report

[Vincent Lefevre]

Package: reportbug
Version: 12.0.0
Severity: normal

The reportbug(1) man page says:

-V VERSION, --package-version=VERSION
Specify the version of the package the problem was found in.
This is probably most useful if you are reporting a bug in a
package  that is not installable or installed on a different
system.

and "reportbug --help" outputs

  -V PKGVERSION, --package-version=PKGVERSION
specify the version number for the package

But when I use this option, e.g.

  reportbug -V 20230707 ca-certificates-java
  reportbug -V 13 reportbug
  reportbug --package-version=13 reportbug

the version is not put in the bug report.

Note that I get the question

"Please enter the version of the package this report applies to (blank OK)"

which I leave blank as I have already provided the version via
the -V / --package-version option. BTW, asking this question is
useless for this reason.

-- Package-specific info:
** Environment settings:
EDITOR="/home/vinc17/bin/eclient"
PAGER="less -Lis"
VISUAL="/home/vinc17/bin/eclient"
EMAIL="vinc...@vinc17.net"
INTERFACE="text"

** /home/vinc17/.reportbugrc:
reportbug_version "2.10"
mode advanced
ui text
realname "Vincent Lefevre"
email "vinc...@vinc17.net"
mua mutt
cc
timeout 20

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

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

Versions of packages reportbug depends on:
ii  apt2.6.1
ii  python33.11.4-5
ii  python3-reportbug  12.0.0
ii  sensible-utils 0.0.20

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf 1.5.82
ii  debsums 3.0.2.1
ii  dlocate 1.12
ii  emacs-bin-common1:28.2+1-15
ii  file1:5.44-3
ii  gnupg   2.2.40-1.1
ii  postfix [mail-transport-agent]  3.8.1-2
ii  python3-urwid   2.1.2-4+b1
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.6.1
ii  file   1:5.44-3
ii  python33.11.4-5
ii  python3-apt2.6.0
ii  python3-debian 0.1.49
ii  python3-debianbts  4.0.1
ii  python3-requests   2.28.1+dfsg-1
ii  sensible-utils 0.0.20

python3-reportbug suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1038134: g++-12: Conditional compilation error in optimized mode

[Matthias Klose]

Control: tags -1 + moreinfo

please recheck with the gcc-12 and gcc-13 packages from unstable.  Also please 
try to check with a standalone test case.

Bug#1040521: tpm2-tss: FTBFS (test failures)

[Bastian Germann]

Control: forwarded -1 https://github.com/tpm2-software/tpm2-tss/issues/2531

The big endian problem on s390 is already reported upstream.
This is new code in v4.

Bug#1036637: Having compilation instructions would make things a lot easier.

[shirish शिरीष]

Dear Oliver,

I tried to locally compile the software using the build instructions
shared at -

https://codeberg.org/klartext/plio/src/branch/main/doc/buildinstall.md

I just wanted to try make without using any special fonts or anything so did -

 ~/games/plio/src$ make
gcc -c -Wall -W  main.c
In file included from dircontents.h:23,
 from collection.h:23,
 from main.c:23:
image.h:18:10: fatal error: FreeImage.h: No such file or directory
   18 | #include 
  |  ^
compilation terminated.
make: *** [Makefile.objects:140: main.o] Error 1

Git log shows me the following -

commit 4ac01b38108f206f29d4f570edc7d1fedb43f91b
Author: Oliver Bandel 
Date:   Mon Jun 19 02:14:55 2023 +0200

commands.c: more doxy-documentation added

Looking forward to help.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
https://creativecommons.org/licenses/by-nc/3.0/
https://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#1040778: Add env vars to apply MALLOC optimizations to cinder-backup and cinder-volume

[Christian Rohmann]

Package: cinder
Version: 2:22.0.0-4

According to upstream bughttps://bugs.launchpad.net/cinder/+bug/1908805
cinder-backup and cinder-volume should be started with

 MALLOC_ARENA_MAX: 1
 MALLOC_MMAP_THRESHOLD_: 131072
 MALLOC_TRIM_THRESHOLD_: 262144

to greatly reduce their memory footprint.
There are already patches for

 * Devstack:https://review.opendev.org/c/openstack/devstack/+/845805
 * Tripe-O:https://review.opendev.org/c/openstack/tripleo-common/+/845807
 * 
OpenStack-Ansible:https://review.opendev.org/c/openstack/openstack-ansible-os_cinder/+/888027

applying this.

During a Cinder team weekly the issue was also discussed and explained, see
https://meetings.opendev.org/meetings/cinder/2023/cinder.2023-04-05-14.00.log.html#l-64

Bug#1040521: tpm2-tss: FTBFS (test failures)

[Bastian Germann]

I have just noticed that the build dependency libtpms-dev was added in 4.0.1-1.
When I install it on bookworm, the build fails as well.

So to work around just revert
https://salsa.debian.org/debian/tpm2-tss/-/commit/4c88e0a46685632751e7501a91d9ba66a042e3e2

Bug#1040777: libcrypt-xxhash-perl: Baseline violation on x86 and FTBFS everywhere else

[Adrian Bunk]

Source: libcrypt-xxhash-perl
Version: 0.06-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=libcrypt-xxhash-perl=0.06-1

...
   dh_auto_build -a
/usr/bin/perl Build
Building Crypt-xxHash
c++ -I. -Isrc -Iext/xxHash -I. -Isrc 
-I/usr/lib/powerpc64le-linux-gnu/perl/5.36/CORE -fPIC -D_REENTRANT 
-D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -msse2 -msse4.2 -DCPP=1 
-std=c++17 -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing 
-pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -o ./ext/xxHash/xxh_x86dispatch.o 
./ext/xxHash/xxh_x86dispatch.c
c++: error: unrecognized command-line option ‘-msse2’
c++: error: unrecognized command-line option ‘-msse4.2’
error building ./ext/xxHash/xxh_x86dispatch.o from 
'./ext/xxHash/xxh_x86dispatch.c' at 
/usr/share/perl/5.36/ExtUtils/CBuilder/Base.pm line 185.
dh_auto_build: error: /usr/bin/perl Build returned exit code 2
make: *** [debian/rules:6: binary-arch] Error 25


Please remove the -msse parameters from Build.PL.

Bug#1040776: python-biopython: autopkgtest regression

[Adrian Bunk]

Source: python-biopython
Version: 1.80+dfsg-5
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-biopython/35614880/log.gz

...
580s ==
580s ERROR: test_diagram_via_methods_pdf 
(test_GenomeDiagram.DiagramTest.test_diagram_via_methods_pdf)
580s Construct and draw PDF using method approach.
580s --
580s Traceback (most recent call last):
580s   File 
"/tmp/autopkgtest-lxc.aeaunhwi/downtmp/autopkgtest_tmp/Tests/test_GenomeDiagram.py",
 line 1001, in test_diagram_via_methods_pdf
580s gdd.write(output_filename, "PDF")
580s   File 
"/usr/lib/python3/dist-packages/Bio/Graphics/GenomeDiagram/_Diagram.py", line 
244, in write
580s return _write(self.drawing, filename, output, dpi=dpi)
580s^^^
580s   File "/usr/lib/python3/dist-packages/Bio/Graphics/__init__.py", line 46, 
in _write
580s from reportlab.graphics import renderPS, renderPDF, renderSVG
580s   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderSVG.py", 
line 22, in 
580s from .renderPM import _getImage
580s   File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py", 
line 20, in 
580s from .utils import setFont as _setFont, RenderPMError
580s   File "/usr/lib/python3/dist-packages/reportlab/graphics/utils.py", line 
9, in 
580s from . _renderPM import makeT1Font
580s ModuleNotFoundError: No module named 'reportlab.graphics._renderPM'
...
582s autopkgtest [22:48:48]: test full_suite:  - - - - - - - - - - results - - 
- - - - - - - -
582s autopkgtest [22:48:48]:  summary
582s dependencies FAIL non-zero exit status 1
582s full_suite   FAIL non-zero exit status 1

Bug#1040775: package description mention wrong package name

[Bill Allombert]

Source: audit
Version: 1:3.0.9-1
Severity: normal

Hello Laurent,

The package descriptions do not match the package names:

For example libaudit-dev:
' The audit-libs-devel package contains the static libraries and header'
when there is no debian package audit-libs-devel.

But actually there is no need to spell out the package name in the package own
description.  I suggest you write a generic header like
"audit is a framework for monitoring systems for security related events."
and then adds

"This package contains ..."

for each package as needed.

Package: auditd
Description: User space tools for security auditing
 The audit package contains the user space utilities for
 storing and searching the audit records generated by
 the audit subsystem in the Linux 2.6 kernel.
 .
 Also contains the audit dispatcher "audisp".

Do not mention 2.6, this is quite outdated now.

This package contains the user space utilities for
 storing and searching the audit records generated by
 the audit subsystem in the Linux kernel

Package: libauparse0
Description: Dynamic library for parsing security auditing
 The libauparse package contains the dynamic libraries needed for
 applications to use the audit framework. It is used to monitor systems for
 security related events.
 .
 This package contains the libauparse0 library.

Package: libauparse-dev
Description: Header files and static library for the libauparse0 library
 The audit-libs parse package contains the dynamic libraries needed for
 applications to use the audit framework. It is used to monitor systems for
 security related events.

Should be 'This package contains...' 

Package: libaudit1
Description: Dynamic library for security auditing
 The audit-libs package contains the dynamic libraries needed for
 applications to use the audit framework. It is used to monitor systems for
 security related events.

Should be 'This package contains...' 

Package: libaudit-common
Description: Dynamic library for security auditing - common files
 The audit-libs package contains the dynamic libraries needed for
 applications to use the audit framework. It is used to monitor systems for
 security related events.
 .
 This package contains the libaudit.conf configuration file and the associated
 manpage.

"audit is a framework used to monitor systems for
 security related events.

 This package contains the libaudit.conf configuration file and the associated
 manpage.
"

Package: libaudit-dev
Description: Header files and static library for security auditing
 The audit-libs-devel package contains the static libraries and header
 files needed for developing applications that need to use the audit
 framework libraries.

Should be 'This package contains...' 

Package: python3-audit
Description: Python3 bindings for security auditing
 The package contains the Python3 bindings for libaudit and libauparse, which
 are used to monitor systems for security related events. Python can be used to
 parse and process the security event messages.

Should be 'This package'

Package: golang-redhat-audit-dev
Description: Go client bindings for the libaudit library
 The package contains the Go bindings to libaudit that only allows for logging
 audit events.
 .
 This package contains the source.

Should be 'This package'
"This package contains the source." is unclear.

Package: audispd-plugins
Description: Plugins for the audit event dispatcher
 The audispd-plugins package provides plugins for the real-time
 interface to the audit system, audispd. These plugins can do things
 like relay events to remote machines or analyze events for suspicious
 behavior.

OK.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1040774: msolve FTBFS on 32bit: test failure and hang

[Adrian Bunk]

Source: msolve
Version: 0.5.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=msolve=0.5.0-1

...
make  check-TESTS
make[3]: Entering directory '/<>'
make[4]: Entering directory '/<>'
PASS: fglm_build_matrixn_radical_shape-31
PASS: neogb_io
PASS: fglm_build_matrixn_nonradical_shape-31
PASS: fglm_build_matrixn_nonradical_radicalshape-31
FAIL: test/diff/diff_elim-qq.sh
PASS: test/diff/diff_elim-31.sh
PASS: test/diff/diff_F4SAT-31.sh
FAIL: test/diff/diff_kat6-31.sh
FAIL: test/diff/diff_eco11-31.sh
E: Build killed with signal TERM after 150 minutes of inactivity

Bug#1040521: tpm2-tss: FTBFS (test failures)

[Bastian Germann]

It is obviously a signedness issue on 32 bit systems.

3.2.1-3 has the same issue on sid. So this has to be caused by a post-bookworm update of a different 
component.

Bug#1040773: indi-pentax needs new binaries uploaded for the libraw transition

[Adrian Bunk]

Source: indi-pentax
Version: 1.0+20221221102411-1
Severity: serious
Tags: ftbfs trixie sid

https://buildd.debian.org/status/package.php?p=indi-pentax

One option would be a new source upload (with binaries).

Bug#1040748: ftbfs in pycairo with meson 1.2.0 rc2

[Eli Schwartz]

On 7/10/23 5:09 AM, Simon McVittie wrote:
> Is there a way for debhelper to set this option without breaking the
> build of packages that contain no Python?


It should be fine to always pass this option on meson 1.2.0+, since the
option will exist even if it is never read.

-- 
Eli Schwartz

Bug#1040772: RM: golang-gitaly-proto -- ROM; rc-buggy, no longer needed for gitlab-shell

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-gitaly-pr...@packages.debian.org
Control: affects -1 + src:golang-gitaly-proto
Control: affects -1 + src:golang-gitaly-proto
Control: block 1033705 by -1

Affected by rc bug #1033705 and leaf package. This was originally 
packaged for gitlab-shell but no longer needed.


OpenPGP_0x8F53E0193B294B75.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040771: openjdk-22 should not be in stable releases

[Adrian Bunk]

Source: openjdk-22
Version: 22~3ea-1
Severity: serious

openjdk-22 should not be in stable releases,
this bug should keep it out of testing.

Bug#1040770: bookworm-pu: package nvidia-settings/525.125.06-1~deb12u1

[Andreas Beckmann]

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

[ Reason ]
In prepararion to upgrading nvidia-graphics-drivers(-tesla) to the 535
series (a new LTSB branch announced last week and supported until
June 2026, i.e. sufficient for bookworm) I'd like to split
src:nvidia-settings (building binary packages in main and contrib) into
src:libxnvctrl (in main) and src:nvidia-settings (in contrib).
src:libxnvctrl will most likely see no further updates over the lifetime
of bookworm, while src:nvidia-settings will need new upstream releases
going into stable as the driver packages get updated.
As a side effect of this decoupling, bin:nvidia-settings will no longer
be a key package, removing a lot of contrib and non-free packages from
the key package set.
At the same time I'd like to update nvidia-settings to a new upstream
release fixing a crash.

[ Impact ]
Maintaining the new (split style) in sid/trixie and the old (merged
style) in bookworm while updating src:nvidia-settings in bookworm for
updated src:nvidia-drivers(-tesla) versions will be much more difficult
and less tested than doing the package split in stable, too, and just
rebuilding the packages from sid later on.
(This does not affect bullseye which cannot be updated beyond the 470
driver series, so no more nvidia-settings updates are expected there.)

[ Tests ]
diffoscope showed binary identical (excluding metadata) nvidia-settings
packages built using old- and new-style packaging (and the same upstream
version).

[ Risks ]
Low, with these changes updating nvidia-settings no longer touches main.

[ 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
  the NEW package is is ready in experimental, and I'll upload it to
  both sid and bookworm if this request (and the corresoding one for
  src:libxnvcrl) is granted.

[ Changes ]
The packaging changes are mostly for removing the libxnvctrl packages
and bringing the src:nvidia-settings packaging in sync with
src:nvidia-settings-tesla(-*) (now src:nvidia-settings and
src:nvidia-settings-tesla are identical packaging-wise).
nvml.h (the biggest part of the upstream diff) is only used internally.
(libnvidia-ml-dev from src:nvidia-cuda-toolkit ships nvml.h)

[ Other info ]
This package may require stable-NEW processing. (src from main to
contrib)

Andreas


nvidia-settings.525.125.06-1~deb12u1.diff.xz
Description: application/xz

Bug#951200: base-files: unable to upgrade, conffile error

[Santiago Vila]

reassign 951200 dpkg
thanks

Hello Guillem et al.

I'm reassigning this bug to dpkg because it is a lot more likely
to be a bug in dpkg than a bug in base-files.

Thanks.

El 12/2/20 a las 12:31, Luca Koroll escribió:

Package: base-files
Version: 9.9+deb9u11
Severity: important

Dear Maintainer,

after rebooting my system and trying to update my packages an error with the 
base-files package occured which brought me into the situation that I am unable 
to install any new packages.
There must be a problem with the conffile that is temporarily created when 
installing base-files.

apt-clean, dpkg-reconfigure base-files didn't help. The checksum of the 
packages are correct.

The error line states "new info file "/var/lib/dpkg/tmp.ci/conffiles" can't be 
installed: incorrect message
There is no further error code or information.

Thanks for helping.
[...]

Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

[Santiago Vila]

El 9/7/23 a las 0:54, so54p1+4s6g31jabjix4@cs.email escribió:

Package: base-files
Version: 12.4
Followup-For: Bug #885414

Dear Maintainer,

is there any progress on this issue? It causes issues when files with
spaces are placed in /etc/profile.d/


Hello. There is no "progress" because I'm not convinced it is a good idea.

It seems like an invitation for using spaces in filenames, which I think we
should avoid in either case.

Maybe I end up modifying profile as suggested, for compatibility with Ubuntu,
and only for user-provided scripts, but I would still like some policy 
discouraging
spaces in filenames for Debian packages.

Thanks.

Bug#1040694: Segfault in CbcModel::initialSolve

[Julien Schueller | Phimeca]

The problem goes away if I rebuild bonmin, it's needed since some defines are 
changing the class size.
j

De : Pierre Gruet 
Envoyé : dimanche 9 juillet 2023 15:47
À : Debian Bug Tracking System 
Objet : Bug#1040694: Segfault in CbcModel::initialSolve

Source: coinor-cbc
Version: 2.10.10+ds1-1
Severity: important
X-Debbugs-Cc: schuel...@phimeca.com

Dear Maintainer,

Starting from version 2.10.10+ds1-1 (2.10.8+ds1-1 was OK), one of the
build-time tests of openturns started to fail: t_Bonmin_std. Running it with
gdb I get:

--->8

(gdb) run
Starting program: 
/build/openturns-eQ5lBV/openturns-1.20/builddir/lib/test/t_Bonmin_std
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
class=Bonmin
algorithm=B-BB
options=
mu_oracle=loqo


Program received signal SIGSEGV, Segmentation fault.
0x71ce1347 in CbcModel::initialSolve() () from 
/usr/lib/x86_64-linux-gnu/libCbc.so.3
(gdb) bt
#0  0x71ce1347 in CbcModel::initialSolve() () from 
/usr/lib/x86_64-linux-gnu/libCbc.so.3
#1  0x748a2705 in Bonmin::Bab::branchAndBound(Bonmin::BabSetupBase&) () 
from /usr/lib/x86_64-linux-gnu/libbonmin.so.4
#2  0x7755b48e in OT::Bonmin::run (this=this@entry=0x7fffe440) at 
./lib/src/Base/Optim/Bonmin.cxx:174
#3  0xf285 in main () at ./lib/test/t_Bonmin_std.cxx:131

--->8

which indicates a problem in coinor-cbc.
The above backtrace is somewhat reminiscent of the one of the issue
https://github.com/coin-or/Cbc/issues/591
which has been fixed in upstream version 2.10.10. I suspect a close issue is
showing up here.

Thanks a lot for your help,

--
Pierre

Bug#1040769: linux-base: Errors on /proc/vmallocinfo

[Corcodel Marian]

Package: linux-base
Version: 4.6
Severity: normal
X-Debbugs-Cc: corcodel.mar...@gmail.com

Hi try to read /proc/vmallocinfo but i not figure what is happen there.
Lets see first line:

0x82422d6c-0x13420391   20480
irq_init_percpu_irqstack+0xcf/0x100 vmap

Substract 0x82422d6c-0x13420391
result not fit with 20480 , suppose this is aligned value, but memory
allocation is normal without alignment.

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

Kernel: Linux 5.10.0-23-amd64 (SMP w/2 CPU threads)
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 linux-base depends on:
ii  debconf [debconf-2.0]  1.5.77

linux-base recommends no packages.

linux-base suggests no packages.

Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.

[Max Nikulin]

On 06/07/2023 06:02, Nicholas D Steeves wrote:

"H.-Dirk Schmitt" writes:

A „clean solution“ should avoid duplicated distribution of the same
functionality – especially if one „shadows“ the other.


Can upstream be convinced of this „clean solution“?


If I remember correctly, Richard Stallman considers Org mode as an 
important part of Emacs. On the other hand there are users who prefer to 
have Org newer than built-in version, fortunately it is developed in a 
separate repository.


I am unsure that it is reasonable to split Emacs Debian package into a 
squad of smaller ones if an elpa-* counterpart is available. Perhaps it 
is easier to review elpa-* packages after packaging of new Emacs 
versions. I do not see much sense in painstakingly avoiding load shadowing.



For example a script that parses our Emacs' built-in
version, and that files release critical bugs against an elpa-foo
package when it's older than the Emacs built-in version.


package.el is created for interactive usage (`list-packages'), so the 
script will have to rely on internal variable and functions. When the 
package source file is known, `lm-header' may be used to obtain specific 
fields. It is doable, but unlikely straightforward.


P.S. Thanks for packaging of Org-9.6. I did not notice the experimental 
package.

Bug#1040689: Workaround without init and site file

[David Bremner]

Balbir Thomas  writes:

> Thanks to bremner on IRC it was found that
> launching emacs disabling the init and site lisp file
> ("emacs -Q") seems to fix the issue i.e. org-export-dispatch
> does work and and exported file is generated.

I was thinking about this a bit more, and I wonder if the two bugs you
filed are related. In particular I wonder if the problems you are having
with org-mode are related to your having .elc files from an old version
of org-mode still in your file system. Perhaps try removing the
directory /usr/share/emacs/site-lisp/elpa/org-9.4 (or moving it to some
location outside emacs search path, like /tmp).

Bug#1040056: spirv-tools breaks spirv-llvm-translator-15 autopkgtest: exactly one input file must be specified.

[Sebastien Bacher]

Hey Michel,

Sorry you are right there, unsure how I went to that conclusion but 
indeed what I wrote before was wrong


Cheers,
Sébastien

Le 10/07/2023 à 12:21, Michel Dänzer a écrit :

On 7/10/23 10:36, Sebastien Bacher wrote:

The issue needs to be fixed in piglit and there is a patch upstream, I've 
reported that as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039592

The spirv-llvm-translator build doesn't use piglit though, does it?



https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/821

However, 'spirv-as -h' still says:

'If no file is specified, [...] then the assembly text is read from standard 
input.'

So this does seem like a spirv-tools bug, and my piglit change is a workaround.

Bug#1030557: golang-github-theupdateframework-go-tuf is still stuck in NEW

[Reinhard Tartler]

Dear ftp-master,

On 6/26/23 1:30 PM, Reinhard Tartler wrote:

Dear ftp-masters,

I notice that
https://ftp-master.debian.org/new/golang-github-theupdateframework-go-tuf_0.5.2-1.html
is being reviewed since 5 months. I wonder whether there are any issues or
questions with the upload I might be able to help resolving?

The thing is, I'd really would like to continue working on packaging cosign
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030557), a package for
signing container images, and this this package is a code dependency.



I'm really eager to continue packaging newer versions of podman, which make it
harder and harder to package without cosign, for which I need this package in 
Debian.

Any chance you could give me a hand with golang-github-theupdateframework-go-tuf
which is still stuck in NEW?

Thank you for your help!
 

Bug#1040768: bullseye-pu: package libxnvctrl/525.85.05-3~deb12u1

[Andreas Beckmann]

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

[ Reason ]
In prepararion to upgrading nvidia-graphics-drivers(-tesla) to the 535
series (a new LTSB branch announced last week and supported until
June 2026, i.e. sufficient for bookworm) I'd like to split
src:nvidia-settings (building binary packages in main and contrib) into
src:libxnvctrl (in main) and src:nvidia-settings (in contrib).
src:libxnvctrl will most likely see no further updates over the lifetime
of bookworm, while src:nvidia-settings.
As a side effect of this decoupling, bin:nvidia-settings will no longer
be a key package, removing a lot of contrib and non-free packages from
the key package set.

[ Impact ]
Maintaining the new (split style) in sid/trixie and the old (merged
style) in bookworm while updating src:nvidia-settings in bookworm for
updated src:nvidia-drivers(-tesla) versions will be much more difficult
and less tested than doing the package split in stable, too, and just
rebuilding the packages from sid later on.
(This does not affect bullseye which cannot be updated beyond the 470
driver series, so no more nvidia-settings updates are expected there.)

[ Tests ]
diffoscope showed binary identical (excluding metadata) packages built
from src:nvidia-settings (old style) and src:libxnvctrl.

[ Risks ]
Low, the libxnvctrl0, libxnvctrl-dev packages only have metadata
changes.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [ ] the issue is verified as fixed in unstable
  the NEW package is is ready in experimental, and I'll upload it to
  both sid and bookworm if this request is granted.

[ Changes ]
Most of the diff is just deletion of the packaging bits needed for the
nvidia-settings binary package.

[ Other info ]
This package may require stable-NEW processing.

Andreas
diff --git a/debian/changelog b/debian/changelog
index 884310e..2705350 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+libxnvctrl (525.85.05-3~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Mon, 10 Jul 2023 12:02:00 +0200
+
+libxnvctrl (525.85.05-3) unstable; urgency=medium
+
+  * Upload to unstable.
+
+ -- Andreas Beckmann   Mon, 10 Jul 2023 12:01:56 +0200
+
+libxnvctrl (525.85.05-2) experimental; urgency=medium
+
+  * Fork as separate source package building only libxnvctrl0, libxnvctrl-dev
+in main.
+  * Upload to experimental.
+
+ -- Andreas Beckmann   Tue, 18 Apr 2023 14:14:26 +0200
+
 nvidia-settings (525.85.05-1) unstable; urgency=medium
 
   * New upstream release 525.85.05.
diff --git a/debian/control b/debian/control
index d9a6b3b..7bf03dc 100644
--- a/debian/control
+++ b/debian/control
@@ -1,58 +1,19 @@
-Source: nvidia-settings
-Section: x11
+Source: libxnvctrl
+Section: libs
 Priority: optional
 Maintainer: Debian NVIDIA Maintainers 

 Uploaders:
  Andreas Beckmann ,
- Luca Boccassi ,
 Build-Depends:
  debhelper-compat (= 13),
- m4,
- libgl-dev,
- libgtk-3-dev,
- libjansson-dev,
- libwayland-dev,
- libvdpau-dev,
- libxv-dev,
- libxxf86vm-dev,
- pkg-config,
- xserver-xorg-dev,
-Build-Conflicts:
- libxnvctrl-dev,
+ libxext-dev,
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
 Homepage: https://download.nvidia.com/XFree86/nvidia-settings/
 Vcs-Browser: https://salsa.debian.org/nvidia-team/nvidia-settings
-Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-settings.git
-
-Package: nvidia-settings
-Section: contrib/x11
-Architecture: amd64 arm64
-Pre-Depends:
- nvidia-installer-cleanup,
-Depends:
- , ${nvidia}-alternative
- , libxnvctrl0 (= ${binary:Version})
- , ${shlibs:Depends}, ${misc:Depends}
-Recommends:
- , libgl1-${nvidia}-glvnd-glx
- , ${nvidia}-vdpau-driver
- , lib${nvidia}-ml1
-Provides:
- nvidia-settings-gtk-${nvidia:Version},
-Conflicts:
- nvidia-settings-gtk-${nvidia:Version},
-Description: tool for configuring the NVIDIA graphics 
driver${nvidia:VariantDesc}
- The nvidia-settings utility is a tool for configuring the NVIDIA
- Linux graphics driver.  It operates by communicating with the NVIDIA
- X driver, querying and updating state as appropriate.  This
- communication is done with the NV-CONTROL X extension.
- .
- Values such as brightness and gamma, XVideo attributes, temperature,
- and OpenGL settings can be queried and configured via nvidia-settings.
+Vcs-Git: https://salsa.debian.org/nvidia-team/nvidia-settings.git -b 
libxnvctrl/main
 
 Package: libxnvctrl0
-Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
diff --git a/debian/gbp.conf b/debian/gbp.conf
index d3b0fe0..1924bb8 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,8 +1,8 @@
 [DEFAULT]
 upstream-vcs-tag = %(version)s
 upstream-branch = upstream
-debian-branch = main
-debian-tag = debian/%(version)s
+debian-branch = libxnvctrl/main
+debian-tag = 

Bug#1040056: spirv-tools breaks spirv-llvm-translator-15 autopkgtest: exactly one input file must be specified.

[Michel Dänzer]

On 7/10/23 10:36, Sebastien Bacher wrote:
> The issue needs to be fixed in piglit and there is a patch upstream, I've 
> reported that as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039592

The spirv-llvm-translator build doesn't use piglit though, does it?


> https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/821

However, 'spirv-as -h' still says:

'If no file is specified, [...] then the assembly text is read from standard 
input.'

So this does seem like a spirv-tools bug, and my piglit change is a workaround.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Bug#1029095: libselinux: claim /run/setrans directory

[Laurent Bigonville]

On Tue, 17 Jan 2023 17:44:13 +0100 =?UTF-8?Q?Christian_G=C3=B6ttsche?= 
 wrote:


Hello Christian,

> Libselinux by default, since Debian does not specify DISABLE_SETRANS
> at compile time, tries to translate security contexts within non-raw
> interfaces, e.g. getfilecon(3). The purpose is to translate MCS/MLS
> labels into human readable via mcstransd(8). The translation happens
> via communication over the public accessible UNIX socket
> /var/run/setrans/.setrans-unix, created by mcstransd(8). mcstransd(8)
> however is not installed by default, not a dependency of another
> package, nor recommended or suggested by one. Thus mcstransd(8) is
> probably not running on many (most?) SELinux enabled systems and
> thereby the directory /var/run/setrans is not created. This leaves
> the opportunity for (compromised) programs to create it and the UNIX
> socket to take control of the security context translation. It might
> not be prevented by the SELinux policy since most daemons are allowed
> to create entries in /var/run and UNIX socket communication between
> daemons is common. As a solution the directory /var/run/setrans
> should be created at boot by a trusted party with the default context
> according to the loaded policy (e.g. setrans_runtime_t), which no
> other daemon than mcstransd(8) should have the permission to create
> sockets inside. For example Fedora uses the tmpfiles.d(5) snippet:
>
> d /run/setrans 0755 root root

I'm wondering if that couldn't be done directly by the systemd package 
instead of the libselinux1, that might avoid us the need to introduce a 
new libselinux-common package or headache in the (unlikely?) case there 
a soname change to the libselinux library.


Note that we might need to remove the RuntimeDirectory=setrans option in 
the mcstrans.service to avoid conflict (but that might be for the next 
debian release)


If that's OK for you I'll coordinate with the debian systemd maintainer

Kind regards,

Laurent

Bug#1040710: please consider packaging util-linux 2.39 for logger fix

[Marc Haber]

On Mon, Jul 10, 2023 at 11:56:01AM +0200, Chris Hofstaedtler wrote:
> * Marc Haber  [230709 20:30]:
> > logger in util-linux 2.38 has a bug that leads to sending uninitialized
> > data to a socket, see https://github.com/util-linux/util-linux/issues/2336
> > 
> > This might be the root cause for adduser's autopkgtests failing on s390x
> > keeping adduser out of testing. In addition, a program should never send
> > uninitialized data.
> 
> By accident I reproduced the same problem on riscv64, so its clearly
> not specific to s390x. Thanks for finding the upstream bug.

Thank you very much for the quick reaction. Praise where praise belongs
to, the upstream bug was discovered by Enrik Berkan on Usenet.

Greetings
Marc

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

Bug#806989: game-data-packager: add support for "Caesar III" playable with CaesarIA engine

[Vincent Pelletier]

I cannot seem to find a repository of the caesaria engine which has
activity more recent than 2016.

On the other hand, I found a pair of active projects which implement
the caesar3 engine and thought I should update this bug report. Those
two projects are related to one another (augustus is a fork of
julius):
- https://github.com/bvschaik/julius focussing on bug-for-bug compatibility
- https://github.com/Keriew/augustus which makes a lot more changes to
the gameplay

Neither seem packaged in debian, and the "augustus" name is taken.
-- 
Vincent Pelletier

Bug#1040710: please consider packaging util-linux 2.39 for logger fix

[Chris Hofstaedtler]

Hi Marc,

* Marc Haber  [230709 20:30]:
> logger in util-linux 2.38 has a bug that leads to sending uninitialized
> data to a socket, see https://github.com/util-linux/util-linux/issues/2336
> 
> This might be the root cause for adduser's autopkgtests failing on s390x
> keeping adduser out of testing. In addition, a program should never send
> uninitialized data.

By accident I reproduced the same problem on riscv64, so its clearly
not specific to s390x. Thanks for finding the upstream bug.

> The issue in logger is fixed in util-linux 2.39.

I've uploaded 2.38.1-6 with the patch from upstream applied.

Getting 2.39.1 in is a lot more work, so I hope this is an
acceptable stop gap.

Best,
Chris

Bug#1040689: List of emacs related packages installed

[David Bremner]

Balbir Thomas  writes:

> As requested I am listing below all Emacs related
> packages installed. These list was generated using
> "dpkg --get-selections" and grepping for "emacs" and
> "elpa".

On IRC you later mentioned you duplicated the problem with a smaller set
of packages installed. It would be helpful to know what precisely the
packages are. Note that emacs-goodies-el is just a dependency package
that brings in a bunch of "elpa-*" packages, so it doesn't really make
sense that (as I thought I understood you say), only the "emacs-*"
packages from the list were installed.

d

Bug#1040056: [Pkg-opencl-devel] Bug#1040056: spirv-tools breaks spirv-llvm-translator-15 autopkgtest: exactly one input file must be specified.

[Andreas Beckmann]

Does this issue affect spirv-llvm-translator-16, too?
I tried to trigger the corresponding tests (which succeeded), but I'm 
not sure if it really tested the correct setup.


Andreas

Bug#1039900: pixfrogger: Indirectly depends on SDL 1.2

[Simon McVittie]

Control: reassign -1 src:pixfrogger

Sorry, this bug was reported against the wrong source package. Reassigning
to the right one, full text of the bug report quoted below.

On Thu, 29 Jun 2023 at 11:28:42 +0100, Simon McVittie wrote:
> This package depends on fenix, which is a game development environment
> based on SDL 1.2. SDL 1.2 has been superseded by SDL 2 and is unmaintained
> upstream.
> 
> If possible, please port this package to SDL 2. (This would presumably
> require porting fenix to SDL 2 - #1038340.)
> 
> If it is not possible to port to SDL 2, please test the package with
> libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
> this bug open to track the package as still using SDL 1.2 APIs.
> 
> libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
> API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
> library in some other distributions like Fedora and Arch, and my intention
> is to do the same in Debian during the trixie release cycle.
> 
> The interesting scenarios to test with libsdl1.2-compat-shim are:
> 
> 1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
>such as "GNOME on Xorg" or XFCE.
>($XDG_RUNTIME_DIR/wayland-* should not exist)
> 2. Install libsdl1.2-compat-shim and run the program in a Wayland
>environment such as GNOME's default mode, using Xwayland.
>($XDG_RUNTIME_DIR/wayland-* should exist)
> 3. Install libsdl1.2-compat-shim and run the program in a Wayland
>environment, but this time with environment variable
>SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
>(this is not currently the default for SDL 2).
> 4. Install libsdl1.2-compat-dev and recompile the package.
> 
> If any of those fail, please report it as a bug in the
> libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
> with "affects" pointing to the program that is affected.
> 
> Thanks,
> smcv
> 
> -- 
> This bug report is part of a mass-bug-filing:
> 

Bug#1040767: facter: inconsistent detection of Xen dom0

[Sergio Gelato]

Package: facter
Version: 4.3.0-2

On recent amd64 hardware (I haven't tested on ARM), and if the "virt-what" 
package is installed, "facter virtual is_virtual" in a Xen dom0 returns 
"virtual => xenhvm" and "is_virtual => true". On some older hardware it returns 
"virtual => xen0" and "is_virtual => false". If I uninstall the "virt-what" 
package it returns "virtual => xen0" and "is_virtual => false" on both old and 
new hardware.

Is this a bug in facter or in virt-what? Formally, a Xen dom0 is indeed a 
virtual machine, albeit a rather special one, and virt-what only reports 
(faithfully, as far as I could see) what it gets from the cpuid instruction; so 
the problem, in my view, is rather how facter makes use of the information from 
virt-what.

In practice, I prefer for the dom0 to have is_virtual => false since I use 
is_virtual to decide on such things as whether to install intel-microcode 
(which doesn't really make sense in a guest domain). I could live with "virtual 
=> xen0, is_virtual => true" since that also lets me single out the dom0. 
"virtual => xenhvm" for the dom0, on the other hand, doesn't give me enough 
information.

There are also differences in behavior with and without virt-what in a PVH 
domU. With virt-what I get "virtual => xen" instead of "virtual => xenu". (The 
underlying hardware doesn't seem to play a role here.)

Bug#1040748: ftbfs in pycairo with meson 1.2.0 rc2

[Simon McVittie]

On Sun, 09 Jul 2023 at 23:00:01 -0400, Eli Schwartz wrote:
> The underlying cause is an additional feature
> of meson:
> 
> https://mesonbuild.com/Release-notes-for-1-2-0.html#python-module-can-now-compile-bytecode
> 
> If this file is not desired in the debian package, please specify your
> preferred value for this meson setting. For example, to avoid compiling
> bytecode as part of `meson install`, you could setup the build system
> with the `-Dpython.bytecompile=-1` option.

I think we probably want debhelper's meson build system backend
(/usr/share/perl5/Debian/Debhelper/Buildsystem/meson.pm) to do this
globally for all Meson-built packages, the same way it already handles
cross-compilation, --prefix, --sysconfdir and so on, instead of having to
do it per-package.

Is there a way for debhelper to set this option without breaking the
build of packages that contain no Python?

smcv

Bug#1040766: RM: aeskulap -- ROM; Dead upstream, blocking removal of GTK+ 2 libraries

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: aesku...@packages.debian.org, 1038...@bugs.debian.org
Control: affects -1 + src:aeskulap

Hi,

as in bug #1038453 reported this package is not maintained upstream any
more and is blocking the removal of GTK+ 2 libraries.  There was no
response to my query whether someone remains interested in this package.

Thus its probably time to remove this package from Debian.

Kind regards
Andreas.

Bug#1040765: bookworm-pu: package nvidia-modprobe/535.54.03-1~deb12u1

[Andreas Beckmann]

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

[ Reason ]
In prepararion to upgrading nvidia-graphics-drivers(-tesla) to the 535
series (a new LTSB branch announced last week and supported until
June 2026, i.e. sufficient for bookworm) I'd like to update
nvidia-modprobe to a new upstream release.

[ Impact ]
The 525 series currently in sid/bookworm is only supported until the end
of this year.

[ Tests ]
n/a

[ Risks ]
Low. No functional changes.

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

[ Changes ]
Except for the version bump there are no code changes. The backported
patch is now part of the upstream release. This is a rebuild of the
package from sid with no further changes.

[ Other info ]
nvidia-graphics-drivers has a versioned dependency on nvidia-modprobe
(>= $MAJOR_VERSION) to ensure we don't miss (again) the rare cases where
nvidia-modprobe actually had code changes. That version works with all
driver series, so we can start with uploading nvidia-modprobe even if
the driver packages are not yet ready.


Andreas
diff --git a/debian/changelog b/debian/changelog
index 0ad05af..9ce25ce 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+nvidia-modprobe (535.54.03-1~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Mon, 10 Jul 2023 00:10:07 +0200
+
+nvidia-modprobe (535.54.03-1) unstable; urgency=medium
+
+  * New upstream release.
+
+ -- Andreas Beckmann   Sun, 02 Jul 2023 20:36:35 +0200
+
 nvidia-modprobe (530.30.02-2) unstable; urgency=medium
 
   * Updated nvidia-modprobe to create symbolic links in /dev/char when
@@ -73,6 +85,18 @@ nvidia-modprobe (495.44-1) experimental; urgency=medium
 
  -- Andreas Beckmann   Sun, 07 Nov 2021 09:19:56 +0100
 
+nvidia-modprobe (470.182.03-1) bullseye; urgency=medium
+
+  * New upstream release.
+- Updated nvidia-modprobe to create symbolic links in /dev/char when
+  creating the /dev/nvidia* device nodes. This resolves an issue that
+  prevented the device nodes from working with newer versions of runc:
+  https://github.com/opencontainers/runc/issues/3708
+  * Update Lintian overrides.
+  * Upload to bullseye.
+
+ -- Andreas Beckmann   Sun, 16 Apr 2023 21:40:37 +0200
+
 nvidia-modprobe (470.103.01-1~deb11u1) bullseye; urgency=medium
 
   * Rebuild for bullseye.
diff --git a/debian/copyright b/debian/copyright
index 415c397..26ebb3f 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -9,7 +9,8 @@ Disclaimer:
  NVIDIA drivers in non-free.
 
 Files: *
-Copyright: Copyright (C) 2004-2021 NVIDIA Corporation
+Copyright:
+ Copyright (C) 2004-2023 NVIDIA Corporation
 License: Expat
 
 Files: modprobe-utils/pci-enum.h
diff --git a/debian/patches/dev-char-symlink.patch 
b/debian/patches/dev-char-symlink.patch
deleted file mode 100644
index b7e7994..000
--- a/debian/patches/dev-char-symlink.patch
+++ /dev/null
@@ -1,151 +0,0 @@
-commit ec487af278c3603f785e6829023dc1675c66a236
-Author: Aaron Plattner 
-Date:   Thu Mar 30 11:10:10 2023 -0700
-
-525.105.17
-
-diff --git a/modprobe-utils/nvidia-modprobe-utils.c 
b/modprobe-utils/nvidia-modprobe-utils.c
-index 7437751..1a2144f 100644
 a/modprobe-utils/nvidia-modprobe-utils.c
-+++ b/modprobe-utils/nvidia-modprobe-utils.c
-@@ -1,5 +1,5 @@
- /*
-- * Copyright (c) 2013, NVIDIA CORPORATION.
-+ * Copyright (c) 2013-2023, NVIDIA CORPORATION.
-  *
-  * Permission is hereby granted, free of charge, to any person
-  * obtaining a copy of this software and associated documentation
-@@ -42,6 +42,7 @@
- #include "nvidia-modprobe-utils.h"
- #include "pci-enum.h"
- 
-+#define NV_DEV_PATH "/dev/"
- #define NV_PROC_MODPROBE_PATH "/proc/sys/kernel/modprobe"
- #define NV_PROC_MODULES_PATH "/proc/modules"
- #define NV_PROC_DEVICES_PATH "/proc/devices"
-@@ -502,6 +503,75 @@ int nvidia_get_file_state(int minor)
- return state;
- }
- 
-+/*
-+ * Symbolically link the /dev/char/ file to the given
-+ * device node.
-+ */
-+static int symlink_char_dev(int major, int minor, const char *dev_path)
-+{
-+char symlink_path[NV_MAX_CHARACTER_DEVICE_FILE_STRLEN];
-+char dev_rel_path[NV_MAX_CHARACTER_DEVICE_FILE_STRLEN];
-+struct stat link_status;
-+struct stat dev_status;
-+int ret;
-+
-+ret = snprintf(symlink_path, NV_MAX_CHARACTER_DEVICE_FILE_STRLEN,
-+   NV_CHAR_DEVICE_NAME, major, minor);
-+
-+if (ret < 0 || ret >= NV_MAX_CHARACTER_DEVICE_FILE_STRLEN)
-+{
-+return 0;
-+}
-+
-+/* Verify that the target device node exists and is a character device. */
-+if (stat(dev_path, _status) != 0 || !S_ISCHR(dev_status.st_mode))
-+{
-+return 0;
-+}
-+
-+/* Verify the device path prefix is as expected. */
-+if (strncmp(dev_path, NV_DEV_PATH, 

Bug#1040056: spirv-tools breaks spirv-llvm-translator-15 autopkgtest: exactly one input file must be specified.

[Sebastien Bacher]

The issue needs to be fixed in piglit and there is a patch upstream, 
I've reported that as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039592


https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/821

Bug#1040525: Lighttpd disregards ssl.dh-file setting

[Alain Knaff]

Hi,

On 08/07/2023 00:51, gs-bugs.debian@gluelogic.com wrote:
> ⚠ Expéditeur externe au réseau de l'Etat. Voir les consignes de sécurité sur 
> ctie.etat.lu.
> 
>   
> 
> On Fri, Jul 07, 2023 at 09:28:24AM +, Alain Knaff wrote:
>> Package: lighttpd
>> Version: 1.4.69-1
>>
>> Since our upgrade to Debian 12, lighttpd now uses insecure
>> Diffie-Hellman parameters
>> c90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63
>> b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5
>> 1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f
>> a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39
>> a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6
>> 70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b
>> 2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2
>> 261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8
>> 50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94
>> e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18
>> 177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce
>> 0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186
>> af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb
>> ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2
>> d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0
>> 8f4df435c934063199
> 
> What are you sharing?  What command did you use to obtain this info?

Thanks for your reply.

The full Diffie-Hellman parameter was listed in our monthly "Nexpose" 
Report. Then I confirmed using openssl  s_client -connect 
mcp.aev.etat.lu:443 -tls1_2 -cipher DHE-RSA-AES256-GCM-SHA384 -msg | 
grep -A2 "  0c 00" that this was indeed the parameters used.

(responds with a handshake failure now, as I disabled the 2 ciphers that 
use Diffie-Hellman)


> 
> Please clarify why you think this is insecure.

I trust Nexpose on this one. The theory goes that any "standard" 
parameter is insecure, as a would be attacker would only need to "crack" 
it once, and then be able to use it against a huge number of sites.

> 
> This does not look like lighttpd mod_openssl default DH parameters
> used since lighttpd 1.4.56.

Not sure where this is coming from, but for sure not from our local 
configuration (which is basically being ignored...)

> 
> Since lighttpd 1.4.56, lighttpd mod_openssl configures default
> DH parameters to use RFC 7919 FFDHE2048 2048-bit group
> https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/10c65e88f773d361db48e0135e1f4be3a932bf83
> RFC 7919:
> https://datatracker.ietf.org/doc/html/rfc7919#appendix-A.1
> 
> Nowadays, FFDHE3072 is preferred, and a future version of lighttpd may
> change lighttpd mod_openssl to use FFDHE3072 by default in the future.
> 
> Please note: if using GnuTLS (with lighttpd mod_gnutls) or using
> mbedTLS (with lighttpd mod_mbedtls), the Diffie-Hellman group is
> chosen to be secure according to RFC7919 DH parameter negotiation,
> and there is no default set by lighttpd.
> 
>> And this despite having pointed ssl.dh-file to a self generated dh param
>> file, as described in https://weakdh.org/sysadmin.html
> 
> That page is out-dated, at least for lighttpd.
> 
> Since lighttpd 1.4.68, if you are using ssl.cipher-list specified in
> https://weakdh.org/sysadmin.html, then you are WEAKENING the cipher list
> now used by default since lighttpd 1.4.68.
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68

We did use a "locally" constructed cipher list, to which we kept 
blacklisting ciphers as soon as Nexpose considered them insecure.

I now removed that cipher list (falling back to the default), and this 
disabled the 2 remaining ciphers (DHE-RSA-AES256-GCM-SHA384 and 
DHE-RSA-AES128-GCM-SHA256) that used Diffie Hellman :-)

> 
>> In Debian 11, an identical configuration was using our locally generated
>> secure dh parameters.
> 
> Since lighttpd 1.4.65 (released Jun 2022), lighttpd has been announcing
> the future scheduled removal of ssl.dh-file.
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_65
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_66
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_67

It would have been good if this change, potentially endangering 
security, would have been listed in apt_listchanges.


> 
> The removal of ssl.dh-file occurred in lighttpd 1.4.68 (Jan 2023)
> https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68
> 
> As linked in the lighttpd release notes:
>See https://wiki.lighttpd.net/Docs_SSL for replacements with
>`ssl.openssl.ssl-conf-cmd`, but prefer lighttpd defaults instead.
> 
> Since lighttpd 1.4.68, use ssl.openssl.ssl-conf-cmd "DHParameters"
> to specify your own DH parameters file, as ssl.dh-file has been removed.

I tried adding the following to our config (with the 2 ciphers re-enabled):

Bug#1040751: ITP: nanosvg -- simple svg parsing library

[Mathieu Malaterre]

On Mon, Jul 10, 2023 at 10:08 AM Chow Loong Jin  wrote:
>
> On Mon, Jul 10, 2023 at 07:50:21AM +0200, Mathieu Malaterre wrote:
> > On Mon, Jul 10, 2023 at 6:03 AM Chow Loong Jin  wrote:
> > > * Package name: nanosvg
> > >   Version : 0~git20221204.1.9da543e
> > >   Upstream Contact: https://github.com/memononen/nanosvg/issues
> > > * URL : https://github.com/memonenen/nanosvg
> >
> > https://github.com/memononen/nanosvg
>
> Whoops, nice catch thanks.
>
> > > * License : zlib
> > >   Programming Lang: C
> > >   Description : simple svg parsing library
> > >
> > > NanoSVG is a simple stupid single-header-file SVG parse. The output of
> > > the parser is a list of cubic bezier shapes.
> > [...]
> > > I will be packaging this library under the Debian 3-D Printing Packages
> > > team as a build-dependency of slic3r-prusa.
> >
> > 4 years ago the project was declared as not actively maintained:
> >
> > * 
> > https://github.com/memononen/nanosvg/commit/25241c5a8f8451d41ab1b02ab2d865b01600d949
>
> Yep I realize that, but unfortunately, while there is a network of
> forks, there doesn't seem to be a clear de-facto "upstream" apart from
> this one as far as I can tell. fltk's fork[1] appears to be the only one
> with versioned git tags, but it has no issue tracker or way to contact
> upstream short of creating a pull request. memononen's repo seems to be
> the original and the only one in the network with issues enabled.
>
> My intention here is to package the latest git snapshot of
> memononen/nanosvg, with the patch for this commit[2] from fltk/nanosvg
> applied for the use of slic3r-prusa 2.6.0.
>
> If this isn't acceptable, the only alternative I can see is to bundle
> the nanosvg headers somewhere in `debian/` or as a separate component
> tarball in slic3r-prusa, and patch slic3r-prusa's build system to use
> that, now that slic3r-prusa upstream's unbundled their copy.
>
> I had also considered asking slic3r-prusa's upstream to just bundle the
> copy of nanosvg that they need, but I think Debian generally leans
> towards unbundling libraries, not bundling new ones.
>
> I'm open to ideas -- I'm not sure what the best course of action is
> here.

Fair enough, at least you are aware of the issue from day one.

Good luck :)  Thanks for packaging nanosvg !

Bug#1040500: routine-update: Don't create d/salsa-ci.yml file

[Andreas Tille]

Hi Jochen,

Am Fri, Jul 07, 2023 at 12:04:29PM +0200 schrieb Jochen Sprickerhof:
> 
> echo "SALSA_TOKEN=" >> ~/.devscripts
> echo 'SALSA_CI_CONFIG_PATH="recipes/debian.yml@salsa-ci-team/pipeline"' >> 
> ~/.devscripts
> sudo apt install devscripts
> salsa update_safe --group science-team --all

Thanks for this code.  The only problem is that the salsa command does
not work for everybody - specifically not for me, despite I'm using the
token which works for any other task on salsa (including creating new
repositories, pushing etc.)  I simply get

$ salsa update_safe --group science-team --all
Error GETing 
https://salsa.debian.org/api/v4/groups/science-team?with_custom_attributes=0_projects=0
 (HTTP 401): Unauthorized {"error":"invalid_token","error_description":"Toke... 
at /usr/share/perl5/Devscripts/Salsa.pm line 396.

I would love to get this working for me but previous attempts to sort
this out failed.  I know it works for a couple of other DDs.

The other thing is the setting this for all might be slightly dangerous
since we have a couple of configured debian/salsa-ci.yml files in Debian
Med and Pkg R teams.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1035587: linux: broken AHCI controller on MIPS Loongson 3 (regression from 5.10.162-1)

[Jiaxun Yang]

Hi all,

I don't have much idea on firmware, so I don't know if firmware update 
is possible

for that system.

@Huacai, is it acceptable to revert MRRS/MPS workaround patch all MIPS based
Loongson system? Or leave a cmdline option to configure workaround type?

Thanks
- Jiaxun

在 2023/7/8 18:11, Aurelien Jarno 写道:

Hi,

On 2023-06-24 11:46, Aurelien Jarno wrote:

Hi,

On 2023-06-19 09:37, Huacai Chen wrote:

On Sun, Jun 18, 2023 at 5:24 PM Aurelien Jarno  wrote:

Hi,

On 2023-05-07 19:22, Jiaxun Yang wrote:



2023年5月6日 01:58，YunQiang Su  写道：

Aurelien Jarno  于2023年5月6日周六 04:30写道：

Source: linux
Version: 5.10.178-3
Severity: important
X-Debbugs-Cc: d...@debian.org, debian-m...@lists.debian.org, s...@debian.org

Following the point release, the buildd mipsel-osuosl-03.d.o does not
boot anymore, with errors in the AHCI controller:

[   35.912147] ata4.00: exception Emask 0x0 SAct 0x2000 SErr 0x0 action 0x6 
frozen
[   35.919769] ata4.00: failed command: WRITE FPDMA QUEUED
[   35.924968] ata4.00: cmd 61/20:e8:00:f0:e1/00:00:00:00:00/40 tag 29 ncq dma 
16384 out
[   35.924968]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 
(timeout)
[   35.940097] ata4.00: status: { DRDY }
[   35.943743] ata4: hard resetting link

While that initially looks like a hardware issue, it appears that
reverting the kernel to 5.10.162-1 (from 5.10.178-3) fixes the issue.
Strangely mipsel.osuosl-05.d.o, which seems to be similar hardware (CPU,
motherboard and SATA drive), does not exhibit the same issue.


Maybe the different firmwares are used for them...
CCed Huacai and Jiaxun.

I’m unable to reproduce on my side. Perhaps different hardware.
Is it possible to bisect Kernel on that machine to see of reverting that two 
commits do help?

I have bisected the issue and I confirm the intuition from Cyril. The
first bad commit is 654ae539254d10042869fdc77ad04c09e7eff1fd. Reverting
both commits (they are linked) indeed fixes the issue.

Seems a firmware bug, latest firmware should configure a suitable MRRS.

Ok, thanks for the feedback. Given it's not a kernel bug, I am closing
it.

That said, can someone please send us the procedure to upgrade the
firmware on this machine, so that we can continue using it as a buildd?

Any news about that? We need to be able to run the latest stable kernel
on the build daemon.

Thanks,
Aurelien

Bug#1040751: ITP: nanosvg -- simple svg parsing library

[Chow Loong Jin]

On Mon, Jul 10, 2023 at 07:50:21AM +0200, Mathieu Malaterre wrote:
> On Mon, Jul 10, 2023 at 6:03 AM Chow Loong Jin  wrote:
> > * Package name: nanosvg
> >   Version : 0~git20221204.1.9da543e
> >   Upstream Contact: https://github.com/memononen/nanosvg/issues
> > * URL : https://github.com/memonenen/nanosvg
> 
> https://github.com/memononen/nanosvg

Whoops, nice catch thanks.

> > * License : zlib
> >   Programming Lang: C
> >   Description : simple svg parsing library
> >
> > NanoSVG is a simple stupid single-header-file SVG parse. The output of
> > the parser is a list of cubic bezier shapes.
> [...]
> > I will be packaging this library under the Debian 3-D Printing Packages
> > team as a build-dependency of slic3r-prusa.
> 
> 4 years ago the project was declared as not actively maintained:
> 
> * 
> https://github.com/memononen/nanosvg/commit/25241c5a8f8451d41ab1b02ab2d865b01600d949

Yep I realize that, but unfortunately, while there is a network of
forks, there doesn't seem to be a clear de-facto "upstream" apart from
this one as far as I can tell. fltk's fork[1] appears to be the only one
with versioned git tags, but it has no issue tracker or way to contact
upstream short of creating a pull request. memononen's repo seems to be
the original and the only one in the network with issues enabled.

My intention here is to package the latest git snapshot of
memononen/nanosvg, with the patch for this commit[2] from fltk/nanosvg
applied for the use of slic3r-prusa 2.6.0.

If this isn't acceptable, the only alternative I can see is to bundle
the nanosvg headers somewhere in `debian/` or as a separate component
tarball in slic3r-prusa, and patch slic3r-prusa's build system to use
that, now that slic3r-prusa upstream's unbundled their copy.

I had also considered asking slic3r-prusa's upstream to just bundle the
copy of nanosvg that they need, but I think Debian generally leans
towards unbundling libraries, not bundling new ones.

I'm open to ideas -- I'm not sure what the best course of action is
here.

[1] https://github.com/fltk/nanosvg
[2] 
https://github.com/fltk/nanosvg/commit/abcd277ea45e9098bed752cf9c6875b533c0892f

-- 
Kind regards,
Loong Jin


signature.asc
Description: PGP signature

Bug#1040713: installation-guide 20230508+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1040713 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: installation-guide
Version: 20230508+deb12u1

Explanation: enable Indonesian translation

Bug#1040519: samba 4.17.9+dfsg-0+deb12u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1040519 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: samba
Version: 4.17.9+dfsg-0+deb12u2

Explanation: fix build issues on armel and mipsel

Bug#1040763: boswars: binary-any FTBFS

[Adrian Bunk]

Source: boswars
Version: 2.8-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=boswars=2.8-1

...
   dh_install -a
   debian/rules execute_after_dh_install-arch
make[1]: Entering directory '/<>'
# Copy (and rename) an icon to be used as desktop file
mkdir -p debian/boswars/usr/share/pixmaps/
cp units/tank/ico_tank.png debian/boswars/usr/share/pixmaps/boswars.png
rm -f debian/boswars/usr/share/doc/boswars/html/README-SDL.txt
rm -f debian/boswars/usr/share/doc/boswars/html/*copyright*
rm -f debian/boswars/usr/share/doc/boswars/html/gpl3.txt
iconv -f ISO-8859-1 -t UTF-8 units/corpses/unit-corpses.lua -o 
debian/boswars-data/usr/share/games/boswars/units/corpses/unit-corpses.lua
iconv: cannot open output file: No such file or directory
make[1]: *** [debian/rules:26: execute_after_dh_install-arch] Error 1

Bug#999421: #999421: still happens in 8.0.2+dfsg-3

[Michael Tokarev]

Control: found -1 1:8.0.2+dfsg-3

This bug is still present in 8.0.2 qemu version, confirmed it
with llvm-16 too.

FWIW.

/mjt

Bug#1040762: netpbm-free: Netpbm "make check" modifications

[Andreas Tille]

Source: netpbm-free
Version: 2:11.01.00-2
Severity: normal
X-Debbugs-Cc: Akira Urushibata 


Upstream Akira Urushibat wrote in private mail due to problems
posting to Debian BTS:

-

I see that you have authored a patch file for modifying the tests
reflecting the absence of certain executable files in Debian's
Netpbm package.

I have suggestions on how this should be done next time:

(1) all-in-place.test

If you modify all-in-place.test, you must also modify all-in-place.ok
(in the same test directory.)

All tests in the test framework produce output which is captured in a
file in directory /tmp/nestpbm-test and suffixed ".out" . The ".out"
file and ".ok" file are compared and if they match, the test is
declared a success.

A very simple way to deal with omitted programs is to take the file
/tmp/netpbm-test/all-in-place.out, rename it to all-in-place.ok and
use it as a replacement of the file in the test directory.  It will
have some lines saying things like "manweb: NO SUCH FILE" but that
is proper for the Debian package.  Once a patch is created it should
be valid for a good time.  (As some new programs are added to the
list, offsets will be reported when applying the patch.)

One advantage of this approach is that if in the future, someone
erroneously makes a change that results in one of the omitted programs
(say manweb) being created, the issue will be reported.


(2) Test-Order

Instead of deleting lines for tests to be skipped, I suggest commenting
them out.


Thank you for the work.  If you have any questions, please feel free to
ask me (Akira Urushibata ).

---


I'm just recording these perfectly valid and helpful statements in BTS
to make sure it does not become lost in my private mailbox.

Kind regards
 Andreas.


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

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

Bug#1040761: ITP: astropy-iers-data -- Earth Rotation and Leap Second tables for astropy

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org
Affects: src:astropy

* Package name: astropy-iers-data
  Upstream Author : Astropy Developers
* URL : https://github.com/astropy/astropy-iers-data
* License : BSD-3-Clause
  Programming Lang: Python 3
  Description : Earth Rotation and Leap Second tables for the astropy core 
package

This package provides access to the tables provided by the International
Earth Rotation and Reference Systems (IERS) service, in particular the
Earth Orientation data allowing interpolation of published UT1-UTC and
polar motion values for given times. This package is not currently meant
to be used directly by users, and only meant to be used from the core
astropy package.

It was cut-off from the astropy core package and will be a new
dependency of astropy.

I will maintain the package within the Debian Astro team in Salsa:

https://salsa.debian.org/debian-astro-team/astropy-iers-data

Best regards

Ole

Bug#1040760: bookworm-pu: package marco/1.26.1-3+deb12u1

[Mike Gabriel]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ma...@packages.debian.org
Control: affects -1 + src:marco

[ Reason ]
In cases where users run KDE apps such as kwrite or kcalc in a MATE
desktop session as superuser it happens that window titles in
mate-panel/tasklist (libwnck) show only " (as superuser)". When trying
nedit, nedit-ng, and gedit, etc. those don't seem to trigger this.

[ Impact ]
UI/UX improvement for MATE users using KDE apps.

[ Tests ]
Code review. Local test on bookworm system (launch kwrite as root in
MATE desktop session). Issue reported in #1040752 could be reproduced.
Updating to marco 1.26.1-3+deb12u1 resolves the issue.

[ Risks ]
Minimal. MATE's window manager might show regressions in handling window
titles.

[ 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 ]

+  * debian/patches:
++ Add 0004_show-correct-window-title-when-owned-by-superuser.patch. Fix
+  window titles sometimes shown incorrectly when owned as root. This
+  affects mostly KDE apps if they are run on MATE. (Closes: #1040752).

[ Other info ]
None.
diff -Nru marco-1.26.1/debian/changelog marco-1.26.1/debian/changelog
--- marco-1.26.1/debian/changelog   2023-04-26 07:46:12.0 +0200
+++ marco-1.26.1/debian/changelog   2023-07-10 06:47:02.0 +0200
@@ -1,3 +1,12 @@
+marco (1.26.1-3+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add 0004_show-correct-window-title-when-owned-by-superuser.patch. Fix
+  window titles sometimes shown incorrectly when owned as root. This
+  affects mostly KDE apps if they are run on MATE. (Closes: #1040752).
+
+ -- Mike Gabriel   Mon, 10 Jul 2023 06:47:02 
+0200
+
 marco (1.26.1-3) unstable; urgency=medium
 
   * Revert "debian/control: Drop B-D: libxpresent-dev." introduced with
diff -Nru 
marco-1.26.1/debian/patches/0004_show-correct-window-title-when-owned-by-superuser.patch
 
marco-1.26.1/debian/patches/0004_show-correct-window-title-when-owned-by-superuser.patch
--- 
marco-1.26.1/debian/patches/0004_show-correct-window-title-when-owned-by-superuser.patch
1970-01-01 01:00:00.0 +0100
+++ 
marco-1.26.1/debian/patches/0004_show-correct-window-title-when-owned-by-superuser.patch
2023-07-10 06:44:37.0 +0200
@@ -0,0 +1,22 @@
+From 730ed9dc454e97f569df8a92ac065a1afcc05baa Mon Sep 17 00:00:00 2001
+From: insaner 
+Date: Wed, 25 Jan 2023 21:35:07 -0500
+Subject: [PATCH] Show correct window title when owned by superuser. Issue #749
+
+---
+ src/core/window-props.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/core/window-props.c b/src/core/window-props.c
+index 71c9d203c..3a01f6f6f 100644
+--- a/src/core/window-props.c
 b/src/core/window-props.c
+@@ -489,7 +489,7 @@ set_title_text (MetaWindow  *window,
+ 
+   g_free (*target);
+ 
+-  if (!title)
++  if (!title || g_utf8_strlen (title, 2) < 1)
+ *target = g_strdup ("");
+   else if (g_utf8_strlen (title, MAX_TITLE_LENGTH + 1) > MAX_TITLE_LENGTH)
+ {
diff -Nru marco-1.26.1/debian/patches/series marco-1.26.1/debian/patches/series
--- marco-1.26.1/debian/patches/series  2023-04-25 15:34:49.0 +0200
+++ marco-1.26.1/debian/patches/series  2023-07-10 06:45:35.0 +0200
@@ -1,6 +1,6 @@
-
 _shadows.patch
 1001_marco-Add-cmdline-option-no-keybindings-for-disablin.patch
 0001_test-retval-from-XResQueryClientIds.patch
 0002_test-xres-1.2-is-present.patch
 0003_test-if-XResQueryClientIds-is-available.patch
+0004_show-correct-window-title-when-owned-by-superuser.patch

Bug#1040759: installation-reports: "out of memory" message at boot, then unable to update processor microcode, and kernel panic

[Ari Fryxell]

Package: installation-reports
Severity: important
Tags: d-i
X-Debbugs-Cc: ari.fryx...@proton.me

Boot method: USB
Image version: Debian 12.0.0-amd64-netist downloaded from July 3rd (i.e. a week 
old build)
Date: July 9, 2023

Machine: System76 serw10 laptop with an Intel Core i7-7700K CPU (CPU family 6, 
model 158, stepping 9)
Partitions: 
Filesystem  Type 1K-blocksUsed Available Use% Mounted on
udevdevtmpfs  32815780   0  32815780   0% /dev
tmpfs   tmpfs  65670041732   6565272   1% /run
/dev/nvme1n1p3  ext4  28660644   10988  27168440   1% /
/dev/nvme1n1p4  ext4 114760836 6898996 101986080   7% /usr
tmpfs   tmpfs 32835012   0  32835012   0% /dev/shm
tmpfs   tmpfs 5120  12  5108   1% /run/lock
/dev/nvme1n1p2  ext4989032  117276804172  13% /boot
/dev/nvme1n1p8  ext4  23854928  24  22617812   1% /opt
/dev/nvme1n1p12 ext4   9510080 220   9005184   1% /tmp
/dev/nvme1n1p13 ext4  28660644 120  27179308   1% /usr/local
/dev/nvme1n1p14 ext4  47745772  24  45287944   1% /usr/src
/dev/nvme1n1p5  ext4 256921924   27736 243770604   1% /home
/dev/nvme1n1p7  ext4  81121736  433584  76521396   1% /var
/dev/nvme1n1p1  vfat   10219846112   1015872   1% /boot/efi
tmpfs   tmpfs  6567000 144   6566856   1% /run/user/1000

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

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

Comments/Problems:

During the first boot, the system displays an "out of memory" message (this
seems to be during the initramfs stage).  Nevertheless after pressing a key
it presents two successive screens of a failure to load microcode message.
After the second message, the boot stops and the power button has to be
pressed.  The OS doesn't reach login.

For some reason, I've have been able to reach login and to successfully login
on the second boot after my initial install and my re-install today.
(This current successful boot is running the 6.1.0-9-amd64 kernel but the
6.1.0-10-amd64 didn't boot minutes before.)

Here is the output from
# dmesg | grep microcode 



[0.046049] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please 
update microcode to version: 0x52 (or later)
[0.113466] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[0.113467] TAA: Vulnerable: Clear CPU buffers attempted, no microcode
[0.113467] MMIO Stale Data: Vulnerable: Clear CPU buffers attempted, no 
microcode
[0.113468] SRBDS: Vulnerable: No microcode
[1.023465] microcode: sig=0x906e9, pf=0x2, revision=0x48
[1.023543] microcode: Microcode Update Driver: v2.2.

~

If I do
# cat /var/log/installer/syslog | grep microcode

then the block of lines above is followed by:

~

Jul 10 02:40:59 install-firmware: queuing intel-microcode installation 
(GenuineIntel)
Jul 10 03:12:25 hw-detect: installing intel-microcode
Jul 10 03:12:26 in-target:   intel-microcode iucode-tool
Jul 10 03:12:26 in-target: Get:2 cdrom://[Debian GNU/Linux 12.0.0 _Bookworm_ - 
Official amd64 NETINST with firmware 20230610-10:21] bookworm/non-free-firmware 
amd64 intel-microcode amd64 3.20230512.1 [6,124 kB]
Jul 10 03:12:26 in-target: Selecting previously unselected package 
intel-microcode.^M
Jul 10 03:12:26 in-target: Preparing to unpack 
.../intel-microcode_3.20230512.1_amd64.deb ...^M
Jul 10 03:12:26 in-target: Unpacking intel-microcode (3.20230512.1) ...^M
Jul 10 03:12:27 in-target: Setting up intel-microcode (3.20230512.1) ...^M
Jul 10 03:12:27 in-target: intel-microcode: microcode will be updated at next 
boot

~

However, on the (more-frequent) occasions when the kernel panics at boot and
the OS doesn't load the final output to my display has been:

~

[0.047755] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please 
update microcode to version: 0x52 (or later)
[0.117586] RETBleed: WARNING: Spectre v2 mitigation leaves CPU vulnerable to
 RETBleed attacks, data leaks possible!
[1.140611] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
[1.140697] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.0-10-amd64 #1  
Debian 6.1.37-1
[1.140777] Hardware name: System76  
Serval WS   /Serval WS
[1.140902] Call Trace:
[1.140929]  
[1.140952]  dump_stack_lvl+0x44/0x5c
[1.140995]  panic+0x118/0x2ed
[1.141031]  mount_block_root+0x1d3/0x1e6
[

Bug#999785: Bogus Lintian warning built-using-field-on-arch-all-package affects prospective package firmware-carl9170

[John Scott]

Lintian asserts that having Built-Using on an Arch: all package is always 
incorrect. Debian Policy permits and often requires having Built-Using on an 
Arch: all package. This is the situation with carl9170fw, a 
GPL-2.0-only-licensed binary that bakes in several static libraries that need 
to have their sources kept around. This is a firmware package, however, so it's 
Arch: all despite being written in C and producing a bare-metal binary.

I am concerned that this Lintian warning may cause false alarm by my sponsors 
or even cause rejection in the NEW queue. Please remove it from Lintian.

Furthermore, the far more likely problem with Built-Using is that a package 
forgets to use it when it should. So when a package *does* remember to set the 
Built-Using field, it's typically the result of long consideration and the 
maintainer should be given the benefit of the doubt.


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


smime.p7s
Description: S/MIME cryptographic signature