Bug#1057312: linuxcnc-doc-es hardcodes description in Spanish language

[s3v]

Package: src:linuxcnc
Version: 2.9.0~pre1+git20230208.f1270d6ed7-1

Dear Maintainer,

Please fix hardcoded translation in Spanish for the description of the
linuxcnc-doc-es binary package.
Currently the package description states:

 Description: controlador de movimiento para máquinas CNC y robots (Español).
  LinuxCNC es EMC (controlador de máquina mejorado) que proporciona
  control de movimiento para máquinas herramientas CNC (fresado,
  torneado, ruteado, etc.) y aplicaciones de robótica.
  .
  Este paquete contiene la documentación en español.

Hardcoding translation makes translation effort harder (or impossible) for
translators on DDTP [1] which should be used to accomplish this task.

References to DDTSS (translation interface) in Spanish and related mailing
list are [2][3].

Thanks for considering.

Kind Regards


[1] ddtp.debian.org
[2] https://ddtp.debian.org/ddtss/index.cgi/es
[3] https://lists.debian.org/debian-i18n/

Bug#1057203: r-bioc-rhdf5filters: missing build-dependency on big-endian architectures

[Andreas Tille]

Hi Graham,

thanks for bringing this up.

I have a totally different question concerning the transition.  At

https://buildd.debian.org/status/package.php?p=r-bioc-ioniser

the build logs are lagging now nearly two days for all architectures.
Do you know whom to ask for the reason?

Kind regards
   Andreas.

Am Fri, Dec 01, 2023 at 02:45:33PM -0100 schrieb Graham Inggs:
> Source: r-bioc-rhdf5filters
> Version: 1.12.1+dfsg2-1
> Severity: serious
> Tags: ftbfs
> X-Debbugs-Cc: debian-s...@lists.debian.org
> 
> Hi Maintainer
> 
> A commit on 2023-08-01 [1] added a build-dependency on
> libvbz-hdf-plugin-dev, which is not available on big-endian
> architectures, and prevents r-bioc-rhdf5filters from building on s390x
> [2], where it built previously, thus blocking migration.
> 
> The package libvbz-hdf-plugin does not build on big-endian
> architectures [3] due to a missing build-dependency on
> libstreamvbyte-dev, and libstreamvbyte itself FTBFS on big-endian
> architectures [4].
> 
> According to:
> reverse-depends --release sid --recursive r-bioc-rhdf5filters
> 
> r-bioc-rhdf5filters has many reverse-dependencies on s390x, so rather
> than dealing with all of these, it may be simplest to fix
> libstreamvbyte.
> 
> Regards
> Graham
> 
> 
> [1] 
> https://salsa.debian.org/r-pkg-team/r-bioc-rhdf5filters/-/commit/78ced3f3c70fe29db3ba16bc2b57da5ab0e4fa6c
> [2] https://buildd.debian.org/status/package.php?p=r-bioc-rhdf5filters
> [3] https://buildd.debian.org/status/package.php?p=libvbz-hdf-plugin
> [4] https://buildd.debian.org/status/package.php?p=libstreamvbyte
> 
> ___
> R-pkg-team mailing list
> r-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team
> 

-- 
http://fam-tille.de

Bug#1057309: src:haskell-pandoc binary package names conflict with src:pandoc binary packages

[Hannes von Haugwitz]

Source: haskell-pandoc
Version: 3.0.1-2
Severity: serious
Control: affects -1 src:pandoc

Hi,

The binary packages provided by src:haskell-pandoc conflict with the
binary packages of src:pandoc; violationg Debian Policy 3.1 ("Every
package must have a name that’s unique within the Debian archive.").

This also makes the pandoc binary package from src:pandoc uninstallable
in unstable:


# apt policy pandoc pandoc-data
pandoc:
  Installed: (none)
  Candidate: 2.17.1.1-3
  Version table:
 2.17.1.1-3 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 
Packages
pandoc-data:
  Installed: (none)
  Candidate: 3.0.1-2
  Version table:
 3.0.1-2 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 
Packages
 2.17.1.1-3 500
500 mirror+file:/etc/apt/mirrors/debian.list unstable/main amd64 
Packages

# apt install pandoc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 pandoc : Depends: pandoc-data (< 2.17.1.1-3.~) but 3.0.1-2 is to be installed
E: Unable to correct problems, you have held broken packages.


As a workaround you can specify the matching version of pandoc-data:

# apt install pandoc pandoc-data=2.17.1.1-3

Best regards

Hannes

Bug#1057274: bookworm-pu: package gimp/2.10.34-1+deb12u2

[Salvatore Bonaccorso]

Hi Adrian,

On Sat, Dec 02, 2023 at 04:46:22PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bookworm
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: Salvatore Bonaccorso 
> 
>   * Add Conflicts+Replaces: gimp-dds to remove old versions of this
> plugin shipped by gimp itself since 2.10.10. (Closes: #1057149)
> 
> gimp-dds is an older version of a plugin already included
> in gimp in bookworm, it also has CVE-2023-1 (DSA-5564-1)
> unfixed.
> 
> Removal of gimp-dds from bookworm has already been requested
> in #1056710, this update additionally removes stale versions
> a user might still have installed.

Thanks for taking care of it.

Regards,
Salvatore

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Martin-Éric Racine]

On Sat, 2 Dec 2023 19:19:05 +0100 Francesco Poli
 wrote:
> On Mon, 27 Nov 2023 11:12:45 +0200 Martin-Éric Racine wrote:
>
> > On Sat, 25 Nov 2023 00:38:25 +0100 Francesco Poli
> >  wrote:
> > > On Thu, 23 Nov 2023 14:00:12 +0200 Martin-Éric Racine wrote:
> [...]
> > > > You might wanna check whether Rocky Linux has patched their DHCP
> > > > clients or altered their default dhcpcd.conf to make this succeed. If
> > > > that's the case, please point me to the relevant changes.
> > >
> > > AFAICT, the Rocky Linux machine has the ISC DHCP client
> > > and /etc/resolv.conf is written by a script /usr/sbin/dhclient-script,
> > > which obtains data from the ISC DHCP client.
> >
> > That's not what I asked.
>
> I am sorry, if I misunderstood your request.
> I thought you were asking to be pointed to changes relevant to dhcpcd.
> Since the DHCP client I tested on Rocky Linux is the ISC DHCP client, I
> considered any patches for that client as irrelevant to dhcpcd (which
> is not a fork of the ISC DHCP client, is it?).
>
> Anyway, I tried to search for the Rocky Linux ISC DHCP client source
> package.

This is the dhcpcd package. Looking for Rocky changes to ISC is irrelevant.

If you experience issue with dhclient, reassign this bug to isc-dhcp-client.

Martin-Éric

Bug#1057296: src:r-cran-data.table: fails to migrate to testing for too long: autopkgtest failure on 32 bits

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/Rdatatable/data.table/issues/5785
Control: reopen -1

Forwarded upstream
Reopening to stay visible in our sentinel

-- 
http://fam-tille.de

Bug#1025664: rednotebook: Paste ’ with ' highlighted inserts at incorrect position

[Phil Wyett]

Hi,

Are you still having this issue with the latest stable or release you are using?

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org



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

Bug#1057307: sioyek: FTBFS with mupdf 0.23

[Victor Westerhuis]

On Sun, 03 Dec 2023 02:56:20 +0100 Victor Westerhuis 
 wrote:

Package: sioyek
Version: 2.0.0+dfsg-3+b5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: mu...@packages.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

mupdf 0.23 drops the pdf_parse_link_uri symbol, causing sioyek to fail
to build from source. I am preparing a new upload to fix the issue.
Apologies, the symbol is not dropped, but the declaration is moved to an 
internal header in 
https://github.com/ArtifexSoftware/mupdf/commit/254f77c41049cf8229ecb878e6c641c7ccfdf9df. 
It's still an API change that was not tested before uploading.


@mupdf maintainers: Could you test if reverse dependencies still build
before pushing a new version in the future?

- --
Groet, Regards,

Victor Westerhuis

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

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

Versions of packages sioyek depends on:
ii  libc62.37-12
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-7
ii  libgl1   1.7.0-1
ii  libgumbo20.12.0+dfsg-2
ii  libharfbuzz0b8.0.1-1+~optimized
ii  libjbig2dec0 0.19-3
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjs-sphinxdoc  7.2.6-2
ii  libmujs3 1.3.3-3
ii  libopenjp2-7 2.5.0-2
ii  libqt5core5a 5.15.10+dfsg-5
ii  libqt5gui5   5.15.10+dfsg-5
ii  libqt5network5   5.15.10+dfsg-5
ii  libqt5widgets5   5.15.10+dfsg-5
ii  libsqlite3-0 3.44.2-1
ii  libstdc++6   13.2.0-7
ii  libsynctex2  2023.20230311.66589-8
ii  sphinx-rtd-theme-common  2.0.0~rc3+dfsg-2
ii  zlib1-ng [zlib1g]2.0.6-0+~local1+b1
ii  zlib1g   1:1.3.dfsg-3

sioyek recommends no packages.

sioyek suggests no packages.

- -- no debconf information


--
Victor Westerhuis 

Bug#1057308: RFS: sioyek/2.0.0+dfsg-4 [RC] -- PDF viewer with a focus on technical books and research papers

[Victor Westerhuis]

Package: sponsorship-requests
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name : sioyek
   Version  : 2.0.0+dfsg-4
   Upstream contact : https://github.com/ahrm/sioyek/issues
 * URL  : https://sioyek.info/
 * License  : GPL-3.0+, GFDL-NIV-1.2+ or CC-BY-SA-3.0 or CC-BY-SA-2.5 
and CC-BY-SA-2.0 and CC-BY-SA-1.0, BSL-1.0, forrest-smith-license
 * Vcs  : https://salsa.debian.org/viccie30/sioyek
   Section  : misc

The source builds the following binary packages:

  sioyek - PDF viewer with a focus on technical books and research papers

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sioyek/sioyek_2.0.0+dfsg-4.dsc

Changes since the last upload:

 sioyek (2.0.0+dfsg-4) unstable; urgency=medium
 .
   * Move libmupdf-dev to Static-Built-Using.
   * Fix build with mupdf 0.23. (Closes: 1057307)

- --
Groet, Regards,

Victor Westerhuis

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmVr6xMTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+xGCD/92gp07cy6KxdRFswnHDBBe/ZKjQ7sw
+NWuJGEK5ZdJpbChN9o6TbwjtOFOaN2+0jkDeH53Pv2Kh33cfPYJIQv+6KxDztDm
sCkH5b4593D4e5SWve0ey++yejMooaJoohDeJzdsLtvSzh4snVNBJvuqm7j1jQ2S
jdJNLkR3ggcn25y6Qgr+oC953ONJg1b6JOs6bXLNaR8WEXE+suctP/+UbCztzCc0
uNvOgrAUHwCaFBJ7GvWg6FeXvCIVuPW6ZtMF5WIFLLTCZWwPS4a4wq2PIAOfQjct
LJBeFKRhvzn4puQo4wAAN7MY1Yu1gw889pQrXENcBRmcGaGUTugHGGBt1xeYlbKj
+X8Ldo0qGzMtSM49BVHfqIfsz4frCGP5yn+xZc/tdH6mo73Nh8cPIcu0+VSM3gRA
8KaX8H1nb3EofDqEeV4mxPXHe6fgP1gi48Qckw7eH1yGVeryTM3eX+oRviIFKdOX
Dv3Qal0BHr2v1fl4skCv63BCtqCRiMwbGzsx69Mx5Hn2SlmVVv1hxv4Uf5gJel+b
/R7Q18Gp102o/OuUgDFjHhVxQY5b1xzTwdzsyTMkVCPvsTixSe4Y9E8zojIbdtmj
2lv1bXIdopDBPOKiycKPvwoWdWq1IqkA9+jF3r9TJq0aStBDDo9rwIZZCeTmNuyW
GnwWGtux1jUo3w==
=3qNT
-END PGP SIGNATURE-

Bug#1057307: sioyek: FTBFS with mupdf 0.23

[Victor Westerhuis]

Package: sioyek
Version: 2.0.0+dfsg-3+b5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: mu...@packages.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

mupdf 0.23 drops the pdf_parse_link_uri symbol, causing sioyek to fail
to build from source. I am preparing a new upload to fix the issue.

@mupdf maintainers: Could you test if reverse dependencies still build
before pushing a new version in the future?

- --
Groet, Regards,

Victor Westerhuis

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

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

Versions of packages sioyek depends on:
ii  libc62.37-12
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-7
ii  libgl1   1.7.0-1
ii  libgumbo20.12.0+dfsg-2
ii  libharfbuzz0b8.0.1-1+~optimized
ii  libjbig2dec0 0.19-3
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjs-sphinxdoc  7.2.6-2
ii  libmujs3 1.3.3-3
ii  libopenjp2-7 2.5.0-2
ii  libqt5core5a 5.15.10+dfsg-5
ii  libqt5gui5   5.15.10+dfsg-5
ii  libqt5network5   5.15.10+dfsg-5
ii  libqt5widgets5   5.15.10+dfsg-5
ii  libsqlite3-0 3.44.2-1
ii  libstdc++6   13.2.0-7
ii  libsynctex2  2023.20230311.66589-8
ii  sphinx-rtd-theme-common  2.0.0~rc3+dfsg-2
ii  zlib1-ng [zlib1g]2.0.6-0+~local1+b1
ii  zlib1g   1:1.3.dfsg-3

sioyek recommends no packages.

sioyek suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmVr4EQTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+xTaD/9MoSE02oPgj/bc6EWqumd/iTnk7aHe
VIR7IfeJkvjIvnxEXr518se9Fy8E7V8eLS2shOYM0YWT4e/7kKgnB2trCyD7cMnw
jJLrrBsRf0WEIpvg2J6EwbUoZpExBieD7hdXCWbezCPeNsQNDuhTvC1/0rpttt7v
ZPwUtj0T1wfZwpryLbTMkZxX4Avb5ZLgplu6Hkomf9sfrF0/xCEU8bG3X5Blxy6q
j+nDG49ALo8hKepdWwT5J/FAOY9wn9vLovWHv2S8LrHIkFbpvT71fGy/JnPpcoiD
/KaUsWSf7DQGJ/A7V/85OMSVahFiXvK13VEGFA9d6wLPeO4d4VeoGbsvl2d/0yA8
U4Z6zwwZfgQ1eqJPxhr98Znv5cNFzULuinVXcHgRGW/TWX9SBiy3LU54z3VsjTDw
96++mVz79n6dZt5yAe1mzcniVzSi0bZA3opDeOZbCwY0kq+QXntO39Dgko9D9Pwy
c9HMYBcXMZqf4buEUrnMrHsKA89VdW5YhEuaBVqR0PadljHkoHIadu6poADZUeCD
ckeweCZCP96J4ICGUzXunKZ0uOUQcFAcKJKNTZDG9eGMbx2XTJ5sVCIEDEnYOXww
cPgVVjMpW0XIRp76hgFV9FGBxO8GGNE0pLOCq6JZON0Wovo4ayntYSyB/5CfSUun
o356ZnKsr2hzGw==
=wLiO
-END PGP SIGNATURE-

Bug#1057306: RFS: kmscon/9.0.0-5 [RC] -- Simple terminal emulator based on Kernel Mode Setting

[Victor Westerhuis]

Package: sponsorship-requests
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name : kmscon
   Version  : 9.0.0-5
   Upstream contact : https://github.com/Aetf/kmscon/issues
 * URL  : https://github.com/Aetf/kmscon
 * License  : Expat and HPND, Expat, LGPL-2.1+, GPL-2 with Font 
exception, public-domain
 * Vcs  : https://salsa.debian.org/viccie30/kmscon
   Section  : utils

The source builds the following binary packages:

  kmscon - Simple terminal emulator based on Kernel Mode Setting

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/k/kmscon/kmscon_9.0.0-5.dsc

Changes since the last upload:

 kmscon (9.0.0-5) unstable; urgency=medium
 .
   * Stop using undocumented autoscripts in d/rules.
   * Move unifont from Built-Using to Static-Built-Using.
   * Fix FTBFS when systemd.pc changes systemdsystemunitdir.
 Thanks to Helmut Grohne. (Closes: 1052644)

Groet, Regards,
- --
  Victor Westerhuis

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmVr1lwTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+wD8EACxucvUZbmIf605yVCNZZgriZktEvlL
h28S5Qn2guNDkjO5Ds/97wWuhePMjq4ZnkDRpGZl0D5zEO8/CQKWek7Su4BBtwbh
iRvj38dMB4UGzlARbBufFXi6iRTGcdbTV/jts+2/qykIvMNQwFQMwhRfGoIRKaZr
FTkG0PmBAY8Z3pgkas1O8UAsn6+jPi+Y6wJqp3bTISIXUDgwzl1xGBuMbigBAzob
Kmt+RPDZAQlIYxs+bhkdELvFm2a6Njo5xGjK2k1XX8awNpqGhcAKhtH/dtryNA1e
/un1bxXB70OoOHFk4CosDBcP4vv+qbnfBGhjqNdwA7I/PCCAV7VZk5HVdE6FrPGB
shSBfPF26UngsTL0mrdvOP9R6fvW5lMHpXlaJQ4Es7R7hEZdu+h6xX+QoJoys2B/
6RNTOcgcgHGm9aQcijdytcUqpmXqbv/26NClPlH/qN3O2h0bCEb3IuperPPLT0L8
kH4AJU9KVeN2f9DynON9uoCaVzb3hDbKGxFORc1DGavQxaiINs2STbZlJCjr6oUW
rFERhgCSA3PoTAFT+PIXQnuS2uX+yAZyn0BfjgtuXsSuMJc5JOwc/sxj0Iek1z6k
WEcRA6vMtfyPD3IJRaOfZc6ci0a52KdQknrFlAL/DkXtVMMnPshRxO9DMQa/+HuC
woCNdIUNz1p+NA==
=DM/U
-END PGP SIGNATURE-

Bug#1056552: sop-java: 4.1.2 is available upstream

[Jérôme Charaoui]

Le 2023-12-02 à 14 h 24, Jérôme Charaoui a écrit :
However, sop-java upstream have ported their code to Kotlin, and I'm not 
sure whether its feasible to keep it in Debian anymore since Kotlin, 
although in Debian currently, is quite new and has two unfixed CVEs 
against it.


Never mind, the Kotlin port only landed in the 8.x branch of sop-java. 
We should be able to package 7.x with minimal issues.


-- Jérôme

Bug#1056193: is actually a bug, sorry

[David Bremner]

Control: reopen -1
"Debian Bug Tracking System"  writes:

> This is an automatic notification regarding your Bug report
> which was filed against the glusterfs-client package:
>
> Am 18.11.2023 um 17:37 schrieb Xan Charbonnet:

>> I recently upgraded the backup machine to bookworm.  Suddenly I was unable to
>> mount the cluster.  The key error in the logs was:
>>
>> E [socket.c:4405:ssl_setup_connection_params] 0-glusterfs: could not load our
>> cert at /usr/lib/ssl/glusterfs.pem
>>
[snip]

>
> But if you look in /usr/lib/ssl =>
>
> $ ls -l /usr/lib/ssl/ insgesamt 4 lrwxrwxrwx 1 root root 34 23. Okt 
> 19:52 cert.pem -> /etc/ssl/certs/ca-certificates.crt lrwxrwxrwx 1 root 
> root 14 13. Mär 2012 certs -> /etc/ssl/certs drwxr-xr-x 2 root root 4096 
> 25. Okt 06:25 misc lrwxrwxrwx 1 root root 20 23. Okt 19:52 openssl.cnf 
> -> /etc/ssl/openssl.cnf lrwxrwxrwx 1 root root 16 13. Mär 2012 private 
> -> /etc/ssl/private
>
> So if you use the subdirectories the paths are correct (in /etc)

That's all very well, but glusterd is not looking in a subdirectory of
/usr/lib/ssl it is looking for /usr/lib/ssl/glusterfs.pem, as pointed
out above.

FYI, upstreams docs [1] show gluster looking in /etc/ssl, not in a
subdirectory.

https://docs.gluster.org/en/latest/Administrator-Guide/SSL/

Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure

[gregor herrmann]

On Sun, 03 Dec 2023 10:46:50 +1100, Tony Cook wrote:

> >   https://github.com/tonycoz/imager/issues/522
> Fixed in 1.022, please let me know if you have any more problems.

Thank you!
1.022 builds fine in Debian unstable, so I've uploaded it.
 
> d54ea521f63ec1ed7d8c0fd11c23507600d51143 should be safe to cherry pick
> back to 1.020 if you don't want all of the 1.021 TIFF changes in
> the debian stable libimager-perl.

Hm, Debian stable (which has 1.019) is a good question. If libtiff is
updated there too [0] we might see the same issue there.

Same experimentation later: It looks like building libimager-perl
1.019+dfsg-1 from stable in a stable chroot with an additional source
stable-security which pulls in libtiff-dev 4.5.0-6+deb12u1 -- still
succeeds.

So I guess we don't have to do anything here, and if reality is
different than my tests, we can pull in
d54ea521f63ec1ed7d8c0fd11c23507600d51143 -- thanks for the pointer!

Cheers,
gregor

[0]
tiff   | 4.5.0-6   | stable | source
tiff   | 4.5.0-6+deb12u1   | proposed-updates   | source


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1057239: bookworm-pu: cups/2.4.2-3+deb12u5

[Thorsten Alteholz]

On Sat, 2 Dec 2023, Adam D. Barratt wrote:

Please go ahead.


Great, thanks ...

... and uploaded

  Thorsten

Bug#1056934: bookworm-pu: libde265/1.0.11-1+deb12u1

[Thorsten Alteholz]

On Sat, 2 Dec 2023, Adam D. Barratt wrote:

Please go ahead.


Great, thanks ...

... and uploaded

  Thorsten

Bug#1056737: bookworm-pu: minizip/1.1-8+deb12u1

[Thorsten Alteholz]

On Sat, 2 Dec 2023, Adam D. Barratt wrote:

Please go ahead.


Great, thanks ...

... and uploaded

  Thorsten

Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure

[Tony Cook]

On Sat, Dec 02, 2023 at 08:35:38PM +0200, Niko Tyni wrote:
> >From 
> >https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L302
> 
>   static toff_t sizeproc(thandle_t x) {
>   return 0;
>   }
> 
> which is used as the TIFFClientOpen() argument in i_readtiff_wiol():
> 
>   
> https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L710
> 
> So it looks like libimager-perl is always saying the file size is 0,
> and this hasn't hurt earlier but now does with the src:tiff CVE-2023-6277
> patch.
> 
> Not sure where this leaves us, but I've just reported it at
> 
>   https://github.com/tonycoz/imager/issues/522

Fixed in 1.022, please let me know if you have any more problems.

d54ea521f63ec1ed7d8c0fd11c23507600d51143 should be safe to cherry pick
back to 1.020 if you don't want all of the 1.021 TIFF changes in
the debian stable libimager-perl.

Thanks,
Tony

Bug#1056358: bookworm-pu: package needrestart/3.6-4+deb12u1

[Antoine Beaupré]

Control: tags -1 - moreinfo

On 2023-12-02 18:52:39, Adam D. Barratt wrote:
> There doesn't appear to be a debdiff attached.

What is wrong with me.

diff -Nru needrestart-3.6/debian/changelog needrestart-3.6/debian/changelog
--- needrestart-3.6/debian/changelog	2023-05-31 10:47:03.0 -0400
+++ needrestart-3.6/debian/changelog	2023-11-15 15:05:37.0 -0500
@@ -1,3 +1,9 @@
+needrestart (3.6-4+deb12u1) bookworm; urgency=medium
+
+  * fix microcode check regression on AMD CPUs (Closes: #1013285)
+
+ -- Antoine Beaupré   Wed, 15 Nov 2023 15:05:37 -0500
+
 needrestart (3.6-4) unstable; urgency=medium
 
   * Remove leftover conffile 30-pacman with 3.6-4.
diff -Nru needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch
--- needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/05-fix-AMD-ucode-checking-in-non-debug-mode.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,33 @@
+From b073fb6d9969597173daa8c511a85bae9b03ed37 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Wed, 15 Nov 2023 15:20:37 -0500
+Subject: [PATCH] fix AMD ucode checking in non-debug mode
+
+It looks like the assignment when the ucode exist was not
+done *unless* `debug` (`-v`) was set. Therefore, all AMD microcode
+checks were returning UNKNOWN, including in Nagios checks, unless the
+`-v` ("verbose", but actually `debug`) was passed.
+
+Closes: #249
+---
+ perl/lib/NeedRestart/uCode/AMD.pm | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/perl/lib/NeedRestart/uCode/AMD.pm b/perl/lib/NeedRestart/uCode/AMD.pm
+index 638e68d..6daad8f 100644
+--- a/perl/lib/NeedRestart/uCode/AMD.pm
 b/perl/lib/NeedRestart/uCode/AMD.pm
+@@ -185,8 +185,8 @@ sub nr_ucode_check_real {
+ if ( exists( $_ucodes->{cpuid}->{$cpuid} ) ) {
+ my $prid = $_ucodes->{cpuid}->{$cpuid};
+ if ( exists( $_ucodes->{prid}->{$prid} ) ) {
+-$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} ),
+-		print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
++$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} );
++print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
+ 	}
+ }
+ 
+-- 
+2.39.2
+
diff -Nru needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch
--- needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/06-uCode-fix-uninitialized-value-in-logging-of-processo.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,30 @@
+From e85bfe33b595b88cc8052a7815d13612ecc2a841 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
+Date: Sun, 28 May 2023 17:42:28 +0200
+Subject: [PATCH] [uCode] fix uninitialized value in logging of processor index
+
+This got broken in f8c2609f8d5a0e10bd988497b8ea9815a7bb2fa8.
+
+Before that it would have effectively logged
+`$processors{$pid}->{processor}`, but the `processor` entry
+is also the key in `%processors`, i.e. equals `$pid`.
+---
+ perl/lib/NeedRestart/uCode.pm | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/perl/lib/NeedRestart/uCode.pm b/perl/lib/NeedRestart/uCode.pm
+index 6251339..db81375 100644
+--- a/perl/lib/NeedRestart/uCode.pm
 b/perl/lib/NeedRestart/uCode.pm
+@@ -148,7 +148,7 @@ sub nr_ucode_check {
+ }
+ $ui->progress_step;
+ 
+-my $nstate = compare_ucode_versions( $debug, $processors{processor}, @nvars );
++my $nstate = compare_ucode_versions( $debug, $pid, @nvars );
+ if ( $nstate > $state ) {
+ ( $state, @vars ) = ( $nstate, @nvars );
+ }
+-- 
+2.39.2
+
diff -Nru needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch
--- needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch	1969-12-31 19:00:00.0 -0500
+++ needrestart-3.6/debian/patches/07-mark-unavailable-firmware-as-CURRENT.patch	2023-11-15 15:05:37.0 -0500
@@ -0,0 +1,61 @@
+From 0e1ffe8025416a918ddf169f2d858762733d7238 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
+Date: Tue, 21 Nov 2023 10:59:32 -0500
+Subject: [PATCH] mark unavailable firmware as CURRENT
+
+This changes the policy of reporting missing firmware updates as
+"UNKNOWN". Now, if there's no available firmware, we report
+"current". That fixes needrestart on platforms that do not have
+firmware support (#220) or platforms that *are* supported but for
+which a CPU is to new to have an updated 

Bug#1057305: RM: vulkan-memory-allocator/experimental -- ROM; NVIU

[Matthias Geiger]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


Dear ftpmasters,

please ROM vulkan-memory-allocator from experimental as the never
version is in unstable. It hasn't been decrufted automatically for some
reason.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmVrv5cVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1UowP/2XOdrs4KNJKWbIUhZU+6arc2MIn
2Bti6o/PmF1rNCjNk326KupkQRYLnL4EICeyqQUTmX+G6rQnKMPoQ5UhVWkvJM8Z
qb4oxl9zvl4KLSWCRzvquxnFfh4iW638h7iYenCWaE1/j9Mj40m3DCpeOkb+989C
Aw39ldghS3H0QEQb8030XrJfUldXNQUAa+mt9Xwijys1vfz4rQR4pFa0KnRVSXKt
dzKxb/Ty/vNkMNrEe7NnoYpgDo21LPmfnhr33g9/vM3xX5C1+rGx9PbFZX3BsOFh
1ugBPVPEWuR16i6rO4KE/hfHAvlpy2An97cfXro7crZWdtSlT6iCzU6qeKf+HC+w
Tb9qXOVnNsvc5qx8+tiPqACgtwNHAEFXeSsEz/y4Dv/l8dn4wy8B0nQGGF12+jlW
jJf9xUMfLJuUEgHAqqVgRv1TaxBOQE0cqWyDH3RxEGnomigrWxKCFXLOdcWfvtB7
BLPwJ+o4UtPk9IwsFT5MeM6ARG70cqPv+lkfxoNRtEa3q5t0flEFQ3i4/UUxR4/k
YxSjY6UUb+SMAP1XJDcXcidLfCiR5c/KOHQr1SCsucTxTlE0EwPLPIss1QnWOyYs
UtJuTOiUmGwnR/5AWLhyeaWBFPZHTuhKhGNSiJ7b9v5TsG21sFgMxFdBOyKsWBZr
RfA9UUs0RAMgWwQP
=/lEp
-END PGP SIGNATURE-

Bug#1057239: bookworm-pu: cups/2.4.2-3+deb12u5

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2023-12-01 at 23:38 +, Thorsten Alteholz wrote:
> The attached debdiff for cups fixes a nasty bug in Bookworm.
> If the PPD file for a printer has a ColorModel option and the only
> choice  for printing in color is not named RGB but CMYK instead, the
> printer cannot be made printing in color with intuitive methods,
> usually  by selecting the color choice in the print dialog.

Please go ahead.

Regards,

Adam

Bug#1057157: bookworm-pu: package spyder/5.4.2+ds-5+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-11-30 at 20:43 +, Julian Gilbey wrote:
> This is a patch for
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054475
> 
> This bug prevents auto-detection of the environment language (using
> the Python locale.getdefaultlocale() function) when Spyder is first
> run.  After that, Spyder saves the language and uses that saved value
> for future use; this setting can be changed in the Spyder
> preferences.
> The upstream patch fixes the error that caused this bug by updating
> the list of available translations.

Please go ahead.

Regards,

Adam

Bug#1055588: bookworm-pu: package jdupes/1.21.3-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-11-08 at 12:29 -0300, Joao Eriberto Mota Filho wrote:
> jdupes is a fork from fdupes. A bug was introduced by the initial
> fork some years ago. The current fdupes on Debian is already fixed. A
> warning about this bug was sent by the jdupes upstream (Jody Bruchon)
> for me via email message.
> 
> The help option for jdupes says:
>   -d --delete: prompt user for files to preserve and delete all
>    others; [...]
> 
> Using the command 'jdupes -d .', a prompt will appear:
> 
>   Set 1 of 1: keep which files? (1 - 5, [a]ll, [n]one, [l]ink all,
> [s]ymlink all):
> 
> It is a mistake to set 2-4 because the jdupes considers one file
> only. Setting '2-4', the file 2 will be kept and the files 3 and 4
> will be deleted. The sentence 'keep which files? (1 - 5' induces the
> users to use a range and it is not valid. Currently, jdupes is not
> denying this behaviour and it is generating a data loss.

Please go ahead.

Regards,

Adam

Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code

[Nicholas D Steeves]

Xiyue Deng  writes:

> Nicholas D Steeves  writes:
>> Xiyue Deng  writes:
>>> Nicholas D Steeves  writes:
>>>
>
> There are about 3 years of newer commits since 1.1.0, and one of the
> major changes is that it adds support of scala 3 syntax which is not yet
> in a tagged release and would be good to have.

Ok, you've convinced me :)  Convey this information in your changelog
(that's what it's for), because the human maintainer (and any interested
users) of this package deserves to know why you made this change.

> Also seeing the last commit is from the end of last year, I sense that
> upstream may becoming a bit dormant for the time being, which is why I
> prefer to package the latest snapshot instead of waiting for a stable
> release.

This can also mean that we run the risk of becoming defacto upstream if
they quit at this point, but that said, I agree it's a good cut point as
well as the right thing to do.

>> Also, do you use this package?
>>
>
> Not on a regular basis, but I do use it a bit once in a while as I try
> to learn a bit of new programming languages every few months.

Thanks for confirming!

[snip]

> And then I just realized: why not just host the scala-mode-pkg.el file
> and substitute the version so that we don't need to update it manually
> on each update?  This is now implemented at [1].

Substvars make sense ;)

Also, neat use of a makefile target called from within the dh sequence.

Are you sure dh_auto_clean is the right place for this override?  Skim
its man page, as well as the one for dh_clean before replying.  Also,
whenever one overrides something in rules, one needs to document this in
the changelog.

Please use "cp -a" so timestamps between builds will be reproducible.
What is the rationale for CURDIR?  From what I can tell it isn't needed
and should be dropped.

>> Do you see what will happen when the package is updated to
>> 1.1.1 or newer?  Also, why did you choose to set the version to "0.23"
>> rather than "1.1.0"?
>
> Well I didn't choose it (if I did I'd use 1.1.0 :) This is the version
> specified in scala-mode.el[2].

I like your choice, and so what if upstream has that!  Is it correct?

>> Did you verify that elpa package version is consistent with the
>> upstream version of the Debian package in bin:elpa-scala-mode that is
>> consumed by users (the binary package)?
>>
>
> I tried install it from stable.melpa.org and yeah it's being
> installed as scala-mode-0.23 even if it's registered as version 1.1.0
> there[3].  So it's consistent in a sense :P

Oh my!  Sorry for the convoluted sentence I wrote, and I'm impressed
that you were able to make sense of it.  Yes, stable.melpa.org publishes
a scala-mode version 1.1.0 elpa package, which contains a scala-mode.el
file with "Package-Version: 0.23", and it also contains a
scala-mode-pkg.el file that overrides the Package-Version to `1.1.0`.
It is because of this pkg.el file that elpa/scala-mode-1.1.0 subdir.

Meanwhile our elpa-scala-mode 1.1.0-* all declare 0.23, and install to a
scala-mode-0.23 subdir.  Thank you for your kind optimism, that's very
gracious.

Your work reveals that I missed this issue when reviewing 1.1.0-1,
which I appreciate having pointed out.  Lets fix it in the upload you've
proposed.

> Anyway, I have just made a pull request to update this upstream[4] so
> hopefully the versioning will be sane.

Thank you, and hopefully they'll agree.

>* Modernize d/watch using special substitute strings.

 Ok, but why?

>>>
>>> I believe this provides a more robust way of detecting tags and should
>>> be an encouraged practices.  From my own experience, when I find a
>>> d/watch file that doesn't work I may search for other packages to learn
>>> from existing practices, and some may not work well as different
>>> upstream may follow different conventions.  The substitute strings use a
>>> more robust and tested regexp that works most of the time, and promoting
>>> its use may save people's time instead of working on an ad-hoc regexp.
>>
>> Sounds good!  This is the kind of rationale that should be in the
>> changelog, so please add it there :) From now on, read your changelog
>> and patche desriptions, and imagine I'm asking you "ok, but why" for
>> each point.  Yes, rarely something is self-evident and/or an
>> implementation detail, but most of the time you should say a few words
>> explaining "why"--particularly when you want to find a sponsor quickly.
>> My expectation is that you get better at this with each review, and that
>> you will apply everything you learned to all pending sponsorship
>> requests in addition to future ones.
>>
>
> Ack, and good suggestion!  I have slightly extended the entry with the
> rationale[5].  PTAL.

Thanks.  LTGM.  P.S. If you wanted to "make a mark" on many packages, a
possible project could be to extend lintian to detect when
@ANY_VERSION@@ARCHIVE_EXT@ can be used, but isn't yet being used.

>* Use xz compression in d/gbp.conf.
[snip]

> I 

Bug#1057304: nmu: ros2-performance-test-fixture_0.2.0-1

[Timo Röhling]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: ros2-performance-test-fixt...@packages.debian.org, 
team+robot...@tracker.debian.org
Control: affects -1 + src:ros2-performance-test-fixture

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nmu ros2-performance-test-fixture_0.2.0-1 . ANY . unstable . -m "Rebuild 
against benchmark (Closes: #1054676)"

benchmark 1.8.3 apparently dropped an exported symbol, which causes an 
undefined reference to `benchmark::internal::Benchmark::Benchmark(char 
const*)' when linking against ros2-performance-test-fixture.

A binNMU seems to be the simplest fix for that.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVruXkACgkQ+C8H+466
LVn5WAv/WyQ9BfZxjG9e6vDx2lGKvkTUSE0WnZ/V2wvwZXn1qytJDdKlsRuMuGTZ
9BE5usD35IKv2yuPnPjYNxB8cRfKZX2O5iDTVNf3WZ9puRpe7X5f2ydQevfsW7j0
foq+VZ5/dkWyNHskrOUXCZHewI59XNkrILgpRIel6A3aa0Nb13d6pn00775df244
zSrgB9eGzLH9fbZNI4TE63/re/CJAWBjS316qO5og7aAimELHldhxK2/RP+mZ2Av
O0BGXl9d6j69L8CvpG0mSSH1iQ9ucbANM/4eUB5dKHMv24dLw+WV24Cy2J67scta
B2ZJCnlSnxQ2l+MNCLPtakPHURuqEdDhMsVld3vcSiR6OawfAtG9v5W5AdVwGFRs
abBLuUd+UaVS4zFBzQMKGoPXvvD5NVZWjj53Et5QziF37HkHuf9uw+V0MeVrNUfu
8ZiuOgk+BXZ2bF/oplASBqkr8aqtVWBMXkON15UXSrKLoUnL0Fmwk0HUL2B7fByH
mX/9FT/J
=g67D
-END PGP SIGNATURE-

Bug#1055226: bookworm-pu: package yuzu/0-1335-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-11-02 at 14:11 +0100, Bastian Germann wrote:
> The package FTBFS in stable: #1041491.

Please go ahead.

Regards,

Adam

Bug#1057303: ITP: just-gtfs-cpp -- single header to parse the General Transit Feed Specification (GTFS)

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: werdah...@riseup.net
Control: block 986232 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: just-gtfs-cpp
  Version : 1.0.0
  Upstream Contact: Olga Khlopkova
* URL : https://github.com/mesozoic-drones/just_gtfs
* License : MIT
  Programming Lang: C++
  Description : single header to parse the General Transit Feed 
Specification (GTFS)

just-gtfs is a single-header library needed to devendor organicmaps.
It parses data in the GTFS format.
I have some packaging ready and it to upload it soon.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmVruO0VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1F3EP/0yX5ecGPm4p1dX+i6h+s8LwxYKf
h6QcZCBbq6ZxLjsEMRwHjH6SUa3RrfY0vVNhXqTJJwCvte7q4+9nPuFWsbgZBJaL
sbbtbZKCWDOTuCsPmmi6mAQXuZUWsJ1rpAPx0RAQcX8pTPUnqRyDXB3OulcsYgjv
kqRuBPKLMXx0PBqYXza43B3XjLQF65RAunkeQyfFMZegt3Ubh2dQO53Ro3W/EVJi
5zF7hPOaH+0XQRueYpEszEdUZ+hk5YERLqaWDjGA+4kS9z6bZ/+Oizx7aMQlQ4bi
6Drp1DLVvMIdgRJMIFEH9g5JVJg1HZt/ezLfnUFdlGgeigRZ8cph2a2Q9uohlWVj
M3iudtFmdJulUSgA/2aJhMjCE3SkbpcvwQ59WfmrPwXPD7oNg+qbQZg3d6EI2uMy
lMNgq0YjaCY9u3himT+OiILYolKKjeV92UdkerCe0QD/0nFwpnp8Iq9rhqUIujSg
3i8gQmGVjLhbP3TsAtb4q8uWGDdCDbKMw+RGWDDVyPumM3g7qcnf0iW+jP+DwMXo
5mQP+G5NFX8rAAry/ibrQ0xU8zPbPr6rK9Lk4mDrSSkljEGYbs/cIFv4yVgsnBdN
PKjyXqXaP9bklLOieIkRQFxQp8iRKERaYRKRTNiu+3qObVR8B3NMPxzolp8Bl60W
LtIvFKWhp4kZbXX7
=cmv3
-END PGP SIGNATURE-

Bug#1057234: sbuild: Generates weird messages in /var/log/syslog

[Preuße]

Control: clone 1057234 -1
Control: reassign -1 schroot
Control: retitle -1 schroot: Generates weird messages in /var/log/syslog

On 02.12.2023 08:30, Johannes Schauer Marin Rodrigues wrote:

Quoting Hilmar Preusse (2023-12-01 23:10:36)


Hi,


I run sbuild as following:

sbuild --no-run-lintian --arch-all --dist=sid *.dsc -d unstable-amd64-sbuild

, where unstable-amd64-sbuild references a chroot. Updating the chroot is done:

sudo sbuild-update -udcar unstable-amd64-sbuild

Both commands generate weird messages in /var/log/syslog like this:

2023-12-01T09:36:52.230653+01:00 haka2 schroot[3182]: [unstable-
amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot] (root->root) Running
command: "perl -e #012use strict;#012
use warnings;#012use POSIX;#012

Sample file is attached. These #012 are page feed chars IIRC. Unfortunately
logcheck is not able to handle the situation and generates E-Mails, which
report the full command line by line. There is definitely a white list rule for
schroot in /etc/logcheck/ignore.d.server/schroot, but it is not able to handle
the lot of special characters. Consider to not print the full perl script into
the log file (if possible).

It may be an issue in logcheck, but rather prefer to avoid message instead of
trying to white list afterwards.


it may also be an issue with schroot, no? I do not think sbuild at any point
tells schroot to write anything to syslog.

What should sbuild do to fix this?



I wasn't sure b/c I use mostly sbuild. Cloning to schroot.

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057301: RFP: swayosd -- osd window for volume and brightness

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: anar...@debian.org, team+swa...@tracker.debian.org, 
debian-r...@lists.debian.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: swayosd
  Version : unreleased
  Upstream Contact: Erik Reider
* URL : https://github.com/ErikReider/SwayOSD
* License : GPL-3
  Programming Lang: Rust
  Description : osd window for volume and brightness

swayosd is an on-screen-display that can display volume and brightness
on wlroots compositors, like in GNOME shell. At the moment I do not have
time to pursue packaging it, thus filing as RFP. It's missing about ~5
new rust libraries so not too bad.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmVrtsgVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1R8YP/0qxdQ/AyNmy1RM/tokwEaSsbddh
oLuhlPCXscImVR+ddABdRiZD5qSZxQDU/nD2P/1mbXaWOBVUhBYrZWqXNUu2j5RI
okpFLL1voF7+K6oPmzmuyWiQjWGXxWsgSoQ8k4cFMrSwnQ34ttk4LyEAyMTsTBZI
gA4SlFfkQvFOmpBPNikwG8T+Pf8WWy84UNaOWDQNp6Ao9gGa6Q92ZxcXDc6dgSdK
B+EcHSd2WE2jtvjbn1nH61E15/oiWOwRZ0YyWcElRiz/Hn7yV2SQ+BiYZfKa4I/v
xzLMXt2qXOSB7eQtqAFgd+6Wu6akOT5/gWoUPoYTgzBwkaanpXa5L2NbEBHKpDRr
xPaBPtjH7pUkeWb9geiisvVW/riLF1xUgFHxV8YjFkjhzXtMZdZqAlWqFatAHGUK
LgVvQWjFX2gNyOYcuLR7As3qTCNHznogimiRkTHSp/q+LL2uK52trxlRxTVgJUi6
x6lxpcl9Q7w/0/BOIeAuiu5iMrbxb+YsHhKky6bapd/e9j86cq2jw3ZUxVelONVg
0jsKmIt5P+AL0vnlLlT8gyIJhLRMHbkOWYWc34Pa6WOkHcxlIkZ+4OSAQKa8ysMg
b71ptvxDtPt+4ofJeUp09mXhZa7UtUgQfNChveEnCKJQAC8BWflHMDLOqV12DTpR
sCmZa18SAPIgmYlK
=sTVM
-END PGP SIGNATURE-

Bug#999664: Package severely outdated (unmaintained?)

[Faidon Liambotis]

Control: retitle -1 Package needs an active maintainer

On Sun, Nov 14, 2021 at 02:46:41PM +0200, Faidon Liambotis wrote:
> Debian is currently shipping ipv6calc 1.0.0. Upstream has released 12
> new upstream releases since, and is currently at 4.0.0.

Upstream has been regularly making releases and is now at 4.1.0.

I discussed this a bit in #debian-qa, and after a bit of encouragement,
I decided to work a bit on this package, to bring it up to date.

I uploaded 4.1.0-0.1 to the archive moments ago. This is definitely an
unusual NMU for me, as I refactored the package almost entirely. I hope
that's OK. I basically ran across into a number of issues and it would
be much more difficult for me to debug them using so antiquated
packaging standards and tooling (e.g. it wasn't even using dh), than it
was to just bring it forward to 2023 and then work from there.

I tried to be considerate and went with as much of a standard packaging
as possible, and left a bunch of comments. I also filed a bunch of
upstream issues¹ to raise everything that is an upstream issue, and left
breadcrumbs across debian/ to point to these bugs.

I'll monitor the BTS for any issues in the short-term, but not the
long-term: I am not stepping up to (co)maintain this. This is also why I
did not follow the salvaging process.

Therefore, I'm leaving this bug open for either Luca or anyone else that
decides to step up. Hopefully the work I did today is going to make this
a much easier endeavour :)

Regards,
Faidon

1: https://github.com/pbiering/ipv6calc/issues/created_by/paravoid

Bug#1055573: dh_makeshlibs: time64 compatibility is wrong for some architectures

[Steve Langasek]

On Sat, Dec 02, 2023 at 02:58:00PM +0100, John Paul Adrian Glaubitz wrote:
> > Maybe instead of duplicating this, debhelper can access it?

> I agree with Helmut's suggestion.  debhelper should be able to deal with
> 32-bit architectures that already support 64-bit time_t.

> If we ignore these, we could run into issues with potential new 32-bit ports
> such as ARC.

debhelper handling of 64-bit time_t is limited to deciding whether or not to
emit Provides: for the library package name without the 't64' tag.

It is only of value for maintaining dependency compatibility with existing
runtime library packages built before the transition.

The impact for *NEW* architectures is therefore moot, regardless.

For similar reasons, I expect it to be low impact for the other
already-defined architectures here as well.  If any of these named
architectures have public stable archives at all, it is nevertheless
exceedingly unlikely that there are third-party packages built *against*
such an archive that anyone cares about maintaining binary compatibility
with.

So while this bug is 100% technically correct, I can't see that there is any
practical impact at all.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1057129: debian-edu-fai 2023.11.19.1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057129 = 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: debian-edu-fai
Version: 2023.11.19.1~deb12u1

Explanation: new upstream stable version

Bug#1057299: designer-qt6: is libqquickwidget.so part of the interface or an implementation detail?

[Helmut Grohne]

Package: designer-qt6
Version: 6.6.0-2
Severity: important
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:phonon

Hi,

I am wondering whether users of designer-qt6 are supposed to use
libqquickwidget.so. Do you consider this plugin/library to be part of
the interface provided by designer-qt6 or is that internal and must not
be used by other packages?

If it is part of the interface, then designer-qt6 is wrongly marked
Multi-Arch: foreign. A shared library cannot be Multi-Arch: foreign. The
marking must be removed.

If it is not part of the interface, src:phonon must not use it during
build. In effect, this means phonon is rc-buggy.

There also is a middle ground. Maybe designer-qt6 is really meant to be
Multi-Arch: foreign. It is also possible to move libqquickwidget.so to a
different package (that is not Multi-Arch: foreign) and have
designer-qt6 depend on that extra package. Then designer-qt6 continues
to work and Multi-Arch: foreign remains valid on it, but src:phonon must
then Build-Depends on that new package.

My impression is that the last of options is what really is meant here,
but it requires restructuring packages and going through NEW. What do
you think?

In any case, the way this is currently set up grossly violates multiarch
concepts and something needs to be done.

Helmut

Bug#1057298: nodejs: improve passing of --dest-* options for cross builds

[Helmut Grohne]

Source: nodejs
Version: 18.19.0+dfsg-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi,

I can see that quite some effort went into cross build support for
nodejs. Thank you. Unfortunately, it doesn't quite just work.

For one thing, doing a cross build without --dest-os or --dest-cpu is
doomed to fail in surprising ways. Hence, the build should fail when
they are missing (for cross builds only). Then the computation of their
values is subtly wrong:
 * There is no Debian architecture named aarch64.
 * Prefer matching of DEB_HOST_ARCH_CPU over DEB_HOST_ARCH to avoid
   repeating cases for different kernels.
 * Increase coverage for loong64, ppc64el and s390.
 * Simplify matching when DEB_HOST_ARCH_CPU is what --dest-cpu wants.

This moves quite some cases further, but in the end it does not make
nodejs cross buildable for any architecture I tried. The issues are
strange and I have no solutions at this time. While this bug is about
passing of --dest-os and --dest-cpu and I ask you to close it when
addressing that aspect, I'll also go into some detail on what goes wrong
next:

 * arm64: Somehow manages to pass arm64-specific compiler options to a
   build architecture compiler. Not sure how they escaped.
 * armel/armhf: Very strange failure about missing header
   "bits/libc-header-start.h".
 * s390x: deps/v8/src/execution/s390/simulator-s390.cc uses bare isnan
   and signbit. gcc suggests you may want to be using std::isnan and
   std::signbit here. Not sure why this works in native builds.

The s390x one looks fixable at least. In any case, I'm attaching a patch
for the debian/rules aspects that I understand well and hope you agree
with it.

Helmut
diff --minimal -Nru nodejs-18.19.0+dfsg/debian/changelog 
nodejs-18.19.0+dfsg/debian/changelog
--- nodejs-18.19.0+dfsg/debian/changelog2023-12-02 02:12:25.0 
+0100
+++ nodejs-18.19.0+dfsg/debian/changelog2023-12-02 19:10:51.0 
+0100
@@ -1,3 +1,10 @@
+nodejs (18.19.0+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve passing of --dest-* options. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 02 Dec 2023 19:10:51 +0100
+
 nodejs (18.19.0+dfsg-3) unstable; urgency=medium
 
   * patch: drop fixed openssl test patch
diff --minimal -Nru nodejs-18.19.0+dfsg/debian/rules 
nodejs-18.19.0+dfsg/debian/rules
--- nodejs-18.19.0+dfsg/debian/rules2023-11-30 16:59:46.0 +0100
+++ nodejs-18.19.0+dfsg/debian/rules2023-12-02 19:10:51.0 +0100
@@ -50,23 +50,13 @@
 # map HOST ARCH AND OS, and if unknown let upstream guess
 
 destCpu =
-destCpu := $(or $(destCpu),$(if $(filter i386,$(DEB_HOST_ARCH)),ia32))
-destCpu := $(or $(destCpu),$(if $(filter x32,$(DEB_HOST_ARCH)),x32))
-destCpu := $(or $(destCpu),$(if $(filter kfreebsd-i386,$(DEB_HOST_ARCH)),ia32))
-destCpu := $(or $(destCpu),$(if $(filter hurd-i386,$(DEB_HOST_ARCH)),ia32))
-destCpu := $(or $(destCpu),$(if $(filter amd64,$(DEB_HOST_ARCH)),x64))
-destCpu := $(or $(destCpu),$(if $(filter kfreebsd-amd64,$(DEB_HOST_ARCH)),x64))
-destCpu := $(or $(destCpu),$(if $(filter armel,$(DEB_HOST_ARCH)),arm))
-destCpu := $(or $(destCpu),$(if $(filter armhf,$(DEB_HOST_ARCH)),arm))
-destCpu := $(or $(destCpu),$(if $(filter aarch64,$(DEB_HOST_ARCH)),arm64))
-destCpu := $(or $(destCpu),$(if $(filter mipsel,$(DEB_HOST_ARCH)),mipsel))
-destCpu := $(or $(destCpu),$(if $(filter mips64el,$(DEB_HOST_ARCH)),mips64el))
-destCpu := $(or $(destCpu),$(if $(filter 
mips64r6el,$(DEB_HOST_ARCH)),mips64el))
-destCpu := $(or $(destCpu),$(if $(filter mips,$(DEB_HOST_ARCH)),mips))
-destCpu := $(or $(destCpu),$(if $(filter powerpc,$(DEB_HOST_ARCH)),ppc))
-destCpu := $(or $(destCpu),$(if $(filter ppc64,$(DEB_HOST_ARCH)),ppc64))
-destCpu := $(or $(destCpu),$(if $(filter riscv64,$(DEB_HOST_ARCH)),riscv64))
-destCpu := $(or $(destCpu),$(if $(filter s390x,$(DEB_HOST_ARCH)),s390x))
+destCpu := $(or $(destCpu),$(if $(filter i386,$(DEB_HOST_ARCH_CPU)),ia32))
+destCpu := $(or $(destCpu),$(if $(filter 
amd64_32,$(DEB_HOST_ARCH_CPU)_$(DEB_HOST_ARCH_BITS)),x32))
+destCpu := $(or $(destCpu),$(if $(filter amd64,$(DEB_HOST_ARCH_CPU)),x64))
+destCpu := $(or $(destCpu),$(if $(filter 
mips64r6el,$(DEB_HOST_ARCH_CPU)),mips64el))
+destCpu := $(or $(destCpu),$(if $(filter powerpc,$(DEB_HOST_ARCH_CPU)),ppc))
+destCpu := $(or $(destCpu),$(if $(filter ppc64el,$(DEB_HOST_ARCH_CPU)),ppc64))
+destCpu := $(or $(destCpu),$(filter arm arm64 loong64 mipsel mips64el mips 
ppc64 riscv64 s390 s390x,$(DEB_HOST_ARCH_CPU)))
 
 # solaris freebsd openbsd linux
 destOs =
@@ -75,12 +65,20 @@
 
 ifneq (, $(destOs))
 DEB_CONFIGURE_EXTRA_FLAGS += --dest-os=$(destOs)
+else
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+$(error "unknown --dest-os for cross compiling nodejs to $(DEB_HOST_ARCH)")
+endif
 endif
 ifeq (unsupported, $(destCpu))
 $(error "nodejs cannot run on $(DEB_HOST_ARCH), please consult maintainers")
 endif
 ifneq (, $(destCpu))
 DEB_CONFIGURE_EXTRA_FLAGS += --dest-cpu=$(destCpu)
+else
+ifneq 

Bug#1057297: knewstuff FTCBFS: skips building the designer plugin

[Helmut Grohne]

Source: knewstuff
Version: 5.107.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

knewstuff fails to cross build from source, because it skips building
the designer plugin, but the packaging expects the designer plugin to be
built. Consider applying the attached patch.

Helmut
diff --minimal -Nru knewstuff-5.107.0/debian/changelog 
knewstuff-5.107.0/debian/changelog
--- knewstuff-5.107.0/debian/changelog  2023-06-18 16:08:45.0 +0200
+++ knewstuff-5.107.0/debian/changelog  2023-12-02 12:46:35.0 +0100
@@ -1,3 +1,10 @@
+knewstuff (5.107.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCFBS: Always build the designer plugin. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 02 Dec 2023 12:46:35 +0100
+
 knewstuff (5.107.0-1) unstable; urgency=medium
 
   [ Aurélien COUDERC ]
diff --minimal -Nru knewstuff-5.107.0/debian/patches/cross.patch 
knewstuff-5.107.0/debian/patches/cross.patch
--- knewstuff-5.107.0/debian/patches/cross.patch1970-01-01 
01:00:00.0 +0100
+++ knewstuff-5.107.0/debian/patches/cross.patch2023-12-02 
12:46:35.0 +0100
@@ -0,0 +1,17 @@
+--- knewstuff-5.107.0.orig/CMakeLists.txt
 knewstuff-5.107.0/CMakeLists.txt
+@@ -69,8 +69,12 @@
+ 
+ option(BUILD_QCH "Build API documentation in QCH format (for e.g. Qt 
Assistant, Qt Creator & KDevelop)" OFF)
+ add_feature_info(QCH ${BUILD_QCH} "API documentation in QCH format (for e.g. 
Qt Assistant, Qt Creator & KDevelop)")
+-
+-cmake_dependent_option(BUILD_DESIGNERPLUGIN "Build plugin for Qt Designer" ON 
"NOT CMAKE_CROSSCOMPILING" OFF)
++if (CMAKE_CROSSCOMPILING)
++set(BUILD_DESIGNERPLUGIN_DEFAULT OFF)
++else()
++set(BUILD_DESIGNERPLUGIN_DEFAULT ON)
++endif()
++option(BUILD_DESIGNERPLUGIN "Build plugin for Qt Designer" 
${BUILD_DESIGNERPLUGIN_DEFAULT})
+ add_feature_info(DESIGNERPLUGIN ${BUILD_DESIGNERPLUGIN} "Build plugin for Qt 
Designer")
+ 
+ set(EXCLUDE_DEPRECATED_BEFORE_AND_AT 0 CACHE STRING "Control the range of 
deprecated API excluded from the build [default=0].")
diff --minimal -Nru knewstuff-5.107.0/debian/patches/series 
knewstuff-5.107.0/debian/patches/series
--- knewstuff-5.107.0/debian/patches/series 2023-03-16 22:42:02.0 
+0100
+++ knewstuff-5.107.0/debian/patches/series 2023-12-02 12:46:35.0 
+0100
@@ -1 +1,2 @@
 remove-executable-flag-from-desktop-files
+cross.patch
diff --minimal -Nru knewstuff-5.107.0/debian/rules 
knewstuff-5.107.0/debian/rules
--- knewstuff-5.107.0/debian/rules  2023-03-16 22:42:02.0 +0100
+++ knewstuff-5.107.0/debian/rules  2023-12-02 12:46:35.0 +0100
@@ -11,7 +11,7 @@
dh $@ --with pkgkde_symbolshelper
 
 override_dh_auto_configure:
-   dh_auto_configure -- -DBUILD_QCH=ON
+   dh_auto_configure -- -DBUILD_QCH=ON -DBUILD_DESIGNERPLUGIN=ON
 
 override_dh_auto_test:
xvfb-run -a dh_auto_test

Bug#1057042: [patch] Drop dependency on libjsr166y-java

[Miguel Landaeta]

tags 1057042 + patch
thanks

https://salsa.debian.org/clojure-team/clojure/-/merge_requests/3

diff --git a/debian/changelog b/debian/changelog
index bab9d0f0..138cc6b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+clojure (1.11.1-3) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Drop dependency on libjsr166y-java. (Closes: #1057042)
+
+ -- Miguel Landaeta   Sat, 02 Dec 2023 21:16:06 +
+
 clojure (1.11.1-2) unstable; urgency=medium
 
   * Change the symlinked maven artifact for libclojure-java from 1.11.x to
diff --git a/debian/control b/debian/control
index 0ccfb227..0d3523b4 100644
--- a/debian/control
+++ b/debian/control
@@ -50,7 +50,6 @@ Description: Lisp dialect for the JVM
 Package: libclojure-java
 Architecture: all
 Depends:
- libjsr166y-java,
  ${java:Depends},
  ${misc:Depends}
 Breaks: clojure (<< 1.9.0-3), clojure1.8 (<< 1.8.0-6), libclojure1.8-java (<< 
1.8.0-6)
diff --git a/debian/changelog b/debian/changelog
index bab9d0f0..138cc6b0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+clojure (1.11.1-3) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Drop dependency on libjsr166y-java. (Closes: #1057042)
+
+ -- Miguel Landaeta   Sat, 02 Dec 2023 21:16:06 +
+
 clojure (1.11.1-2) unstable; urgency=medium
 
   * Change the symlinked maven artifact for libclojure-java from 1.11.x to
diff --git a/debian/control b/debian/control
index 0ccfb227..0d3523b4 100644
--- a/debian/control
+++ b/debian/control
@@ -50,7 +50,6 @@ Description: Lisp dialect for the JVM
 Package: libclojure-java
 Architecture: all
 Depends:
- libjsr166y-java,
  ${java:Depends},
  ${misc:Depends}
 Breaks: clojure (<< 1.9.0-3), clojure1.8 (<< 1.8.0-6), libclojure1.8-java (<< 1.8.0-6)

Bug#1057116: bookworm-pu: package lxc/1:5.0.2-1+deb12u2

[Mathias Gibbens]

On Sat, 02 Dec 2023 19:17:28 + "Adam D. Barratt"
 wrote:
> Please go ahead.

  Uploaded, thanks!

Mathias


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

Bug#1057296: src:r-cran-data.table: fails to migrate to testing for too long: autopkgtest failure on 32 bits

[Paul Gevers]

Source: r-cran-data.table
Version: 1.14.8+dfsg-1
Severity: serious
Control: close -1 1.14.8+dfsg2-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:r-cran-data.table has been trying to 
migrate for 40 days [2]. Hence, I am filing this bug. The version in 
unstable fails its autopkgtest on 32 bit architectures.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=r-cran-data.table



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057295: bcachefs-tools: breaks "mount" if the package is installed

[Adam Borowski]

Package: bcachefs-tools
Version: 24+really1.3.4-1
Severity: important

If bcachefs-tools is installed, "mount" fails to mount any bcachefs
filesystems, saying:

.
Unknown command /dev/nvme0n1p2
bcachefs - tool for managing bcachefs filesystems
usage: bcachefs  []

Superblock commands:
  format   Format a new filesystem
  show-super   Dump superblock information to stdout
  set-option   Set a filesystem option
[... (eleventy lines of help snipped)]
`

Conversely, if the package is _not_ installed, everything goes fine.
Stracing "mount", I see that it tries to run /sbin/mount.bcachefs (which
is symlinked to "bcachefs") if it exists.

The culprit is:
.--[ bcachefs.c ]
#ifndef BCACHEFS_NO_RUST
if (strstr(full_cmd, "mount"))
return cmd_mount(argc, argv);
#endif

...

#ifndef BCACHEFS_NO_RUST
if (!strcmp(cmd, "mount"))
return cmd_mount(argc, argv);
if (strstr(cmd, "completions"))
return cmd_completions(argc, argv);
#endif
`

Ie, the "mount" subcommand (both invoked explicitly and via argv[0]) is not
compiled in our current package.  It's not actually needed for basic operation
(the default logic in /sbin/mount is good enough), but if the helper exists,
"mount" will abort if it the helper fails.

I found it puzzling that no one reported this, quite fatal, bug in two weeks
since your upload (I for one have been away from this machine for a while).
However, it turns out systemd does not use this helper but reinvents it
(expect incompatible ways of handling options, but I digress).  This means,
out of 21 popcon votes, most folks had boot-time mount succeed, while only
manual mount would fail.

In other words:
 ✓ boot-time via systemd
 ✗ boot-time via initscripts
 ✗ manual via "mount"

A simple workaround would be to just drop the /sbin/mount.bcachefs symlink
until rust pieces are back.  But alas, I see that the helper is needed for
handling UUID= stanzas.  A typical person would say /dev/nvme0n1p2 while
d-i prefers PARTUUID= thus that'd _usually_ work... but still not ideal.

On the other hand, at least UUID= has never worked for bcachefs on Debian,
thus at least that part is no regression.


Meow!
-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (666, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.0-rc5-mithlond-02787-gf0f2365d02d9 (SMP w/4 CPU threads; 
PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages bcachefs-tools depends on:
ii  libaio1   0.3.113-5
ii  libblkid1 2.39.2-6
ii  libc6 2.37-12
ii  libkeyutils1  1.6.3-2
ii  liblz4-1  1.9.4-1
ii  libsodium23   1.0.18-1
ii  liburcu8  0.14.0-2
ii  libuuid1  2.39.2-6
ii  libzstd1  1.5.5+dfsg2-2
ii  zlib1g1:1.2.13.dfsg-3

Versions of packages bcachefs-tools recommends:
ii  initramfs-tools [linux-initramfs-tool]  0.142

bcachefs-tools suggests no packages.

-- no debconf information

Bug#1057233: pipewire-bin: installs files into /lib/udev/rules.d

[Gioele Barabucci]

Upstream pipewire now (post 1.0) defaults to /usr/lib/udev/rules.d.

So if no backports are planned for oldstable (Debian 11, bullseye), just 
waiting for a new pipewire release will be enough and no changes to 
d/rules are needed to fix this bug.


Regards,

--
Gioele Barabucci

Bug#1054495: Removal notice: obsolete

[Ilias Tsitsimpis]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: haskell-repa -- ROM; obsolete
Control: severity -2 normal

On Tue, Oct 24, 2023 at 06:23PM, Ilias Tsitsimpis wrote:
> I intend to remove this package:
> 
>   * It has no rev dependencies
>   * The current version FTBFS
>   * It's not part of the latest Stackage LTS

Dear FTP masters, please remove haskell-repa from unstable.

-- 
Ilias

Bug#1054318: Removal notice: obsolete

[Ilias Tsitsimpis]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: haskell-syb-with-class -- ROM; obsolete
Control: severity -2 normal

On Sat, Oct 21, 2023 at 08:35PM, Ilias Tsitsimpis wrote:
> I intend to remove this package:
> 
>   * The current version FTBFS with GHC 9.4
>   * It's not part of the latest Stackage LTS

Dear FTP masters, please remove haskell-syb-with-class from unstable.

-- 
Ilias

Bug#1054355: Removal notice: obsolete

[Ilias Tsitsimpis]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: haskell-parallel-tree-search -- ROM; obsolete
Control: severity -2 normal

On Sun, Oct 22, 2023 at 04:26PM, Ilias Tsitsimpis wrote:
> I intend to remove this package:
> 
>   * It has no rev dependencies
>   * The current version FTBFS
>   * Seems unmaintained; Last upload more than 3 years ago
>   * It's not part of the latest Stackage LTS

Dear FTP masters, please remove haskell-parallel-tree-search from unstable.

-- 
Ilias

Bug#1054317: Removal notice: obsolete

[Ilias Tsitsimpis]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 RM: haskell-numtype -- ROM; obsolete
Control: severity -2 normal

On Sat, Oct 21, 2023 at 08:10PM, Ilias Tsitsimpis wrote:
> I intend to remove this package:
> 
>   * It has no rev dependencies
>   * The current version FTBFS with GHC 9.4
>   * Seems unmaintained; Last upload more than 5 years ago
>   * It's not part of the latest Stackage LTS

Dear FTP masters, please remove haskell-numtype from unstable.

-- 
Ilias

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

[Sudip Mukherjee]

Package: bpftool
Severity: wishlist
X-Debbugs-Cc: sudipm.mukher...@gmail.com, debian-ker...@lists.debian.org, 
debian-de...@lists.debian.org

The official home for bpftool is now the github repo [1] but keeps the kernel
as the authoritative source code of bpftool and is developed as part of the 
bpf-next Linux source tree.
The Maintainers have said "Please use this Github repository for building and 
packaging bpftool" at [2]
The announcement was at [3].

imho, packaging it from the github instead of the kernel source will fix three 
issues:
1. bpftool will use libbpf available in Debian, whereas now it is building a 
libbpf.a from the development codes of libbpf in the kernel source and using 
that.
2. The official releases of bpftool is done in the github repo when the bpf 
maintainers decides the code is ready for a release. But the Debian bpftool 
package is done from the kernel source and so follows the kernel releases. And 
as a result, when a new kernel is released which Debian kernel team will then 
pickup may not have a bpftool release worthy code. For example, bpftool v7.3 
was released on 23/11/2023,
3. bpftool package in Debian is from the kernel v6.5.13 and so looking at the 
source and git commits I can see the that the Debian package is missing 25 
commits which is in the bpftool v7.3 release.


Do we package bpftool from their github repo independent of the kernel
update? Then we will need to remove the bpftool building bits from the
Debian kernel source and create a separate package for bpftool.

And so, it will be great if kernel team will like to package and maintain
it, if not, then I will be happy to do it. Please reject this bug report
if you think bpftool should not be done separately and should live inside
kernel source package.

[1]. https://github.com/libbpf/bpftool
[2]. https://github.com/libbpf/bpftool/blob/main/README.md?plain=1#L18
[3]. 
https://lore.kernel.org/bpf/267a35a6-a045-c025-c2d9-78afbf6fc...@isovalent.com/

-- 
Regards
Sudip

Bug#1057274: gimp 2.10.34-1+deb12u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057274 = 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: gimp
Version: 2.10.34-1+deb12u2

Explanation: add Conflicts+Replaces: gimp-dds to remove old versions of this 
plugin shipped by gimp itself since 2.10.10

Bug#1057236: gosa-plugins-sudo 2.8~git20211022.7ff3ed2-2+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057236 = 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: gosa-plugins-sudo
Version: 2.8~git20211022.7ff3ed2-2+deb12u1

Explanation: fix uninitialised variable

Bug#1057159: gnome-characters 43.1-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057159 = 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: gnome-characters
Version: 43.1-1+deb12u1

Explanation: add support for Unicode 15.1

Bug#1057156: fonts-noto-color-emoji 2.042-0+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057156 = 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: fonts-noto-color-emoji
Version: 2.042-0+deb12u1

Explanation: add support for Unicode 15.1

Bug#1056164: libervia-backend 0.9.0~hg3993-4+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1056164 = 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: libervia-backend
Version: 0.9.0~hg3993-4+deb12u1

Explanation: fix start failure without pre-existing configuration; make exec 
path absolute in dbus service file; fix dependencies on 
python3-txdbus/python3-dbus

Bug#1057125: debian-edu-config 2.12.40~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1057125 = 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: debian-edu-config
Version: 2.12.40~deb12u1

Explanation: new upstream stable version

Bug#1055986: symfony 5.4.23+dfsg-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055986 = 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: symfony
Version: 5.4.23+dfsg-1+deb12u1

Explanation: fix session fixation issue [CVE-2023-46733]; add missing escaping 
[CVE-2023-46734]

Bug#1056307: lastpass-cli 1.3.7-1~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1056307 = 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: lastpass-cli
Version: 1.3.7-1~deb12u1

Explanation: new upstream stable release; update certificate hashes; add 
support for reading encrypted URLs

Bug#1055944: vips 8.14.1-3+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055944 = 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: vips
Version: 8.14.1-3+deb12u1

Explanation: fix null pointer dereference issue [CVE-2023-40032]

Bug#1055611: oscrypto 1.3.0-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055611 = 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: oscrypto
Version: 1.3.0-1+deb12u1

Explanation: fix OpenSSL version parsing; fix autopkgtest

Bug#1055539: opensc 0.23.0-0.3+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055539 = 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: opensc
Version: 0.23.0-0.3+deb12u1

Explanation: fix out-of-bounds read issue [CVE-2023-4535], potential PIN bypass 
[CVE-2023-40660], memory-handling issues [CVE-2023-40661]

Bug#1055419: pcs 0.11.5-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055419 = 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: pcs
Version: 0.11.5-1+deb12u1

Explanation: fix "resource move"

Bug#1054421: weborf 0.19-2.1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1054421 = 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: weborf
Version: 0.19-2.1+deb12u1

Explanation: fix denial of service issue

Bug#1055350: exfatprogs 1.2.0-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055350 = 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: exfatprogs
Version: 1.2.0-1+deb12u1

Explanation: fix out-of-bounds memory access issues [CVE-2023-45897]

Bug#1055229: redis 7.0.11-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1055229 = 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: redis
Version: 7.0.11-1+deb12u1

Explanation: drop ProcSubset=pid hardening flag from the systemd unit due to it 
causing crashes

Bug#1054442: hash-slinger 3.1-1.1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1054442 = 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: hash-slinger
Version: 3.1-1.1+deb12u1

Explanation: fix generation of TLSA records

Bug#1054287: devscripts 2.23.4+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1054287 = 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: devscripts
Version: 2.23.4+deb12u1

Explanation: debchange: Update to current Debian distributions

Bug#1054100: iotop-c 1.23-1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1054100 = 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: iotop-c
Version: 1.23-1+deb12u1

Explanation: fix the logic in 'only' option; fix busy loop when ESC is pressed; 
fix ASCII graph rendering

Bug#1053895: node-undici 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1053895 = 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: node-undici
Version: 5.15.0+dfsg1+~cs20.10.9.3-1+deb12u2

Explanation: delete cookie and host headers on cross-origin redirect 
[CVE-2023-45143]

Bug#1053908: calibre 6.13.0+repack-2+deb12u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1053908 = 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: calibre
Version: 6.13.0+repack-2+deb12u2

Explanation: fix crash in Get Books when regenerating UIC files

Bug#1051876: ruby-rugged: please prepare for libgit2 transition

[Timo Röhling]

Hi,

On Wed, 13 Sep 2023 22:25:30 +0200 =?utf-8?q?Timo_R=C3=B6hling?= 
 wrote:
I suggest you upload ruby-rugged 1.7.1 to experimental first, so 
we can check for potential regressions. I will start the 
transition once all language bindings are ready.


FYI: It took longer than anticipated, but the transition will start 
now.



Cheers
Timo


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1056552: sop-java: 4.1.2 is available upstream

[Jérôme Charaoui]

On Wed, 22 Nov 2023 17:24:06 -0500 Daniel Kahn Gillmor 
 wrote:

Package: src:sop-java
Version: 4.1.0
Control: affects -1 + pgpainless-cli

Hi folks--

sop-java 4.1.2 is available upstream, and should be a relatively
straightforward update in Debian.

As are several substantially newer versions, but the newer ones look
like they might be semver incompatible, so for the purposes of keeping
the 1.3.* series of pgpainless-cli in debian they are probably not
advisable to upgrade until the newer version of bouncycastle lands in
unstable, see #1049356.


The 1.3.* series of pgpainless doesn't build with bouncycastle-1.77, 
which has been uploaded in Debian recently, so I think we don't have 
much choice but to bring both sop-java and pgpainless to the latest 
versions.


However, sop-java upstream have ported their code to Kotlin, and I'm not 
sure whether its feasible to keep it in Debian anymore since Kotlin, 
although in Debian currently, is quite new and has two unfixed CVEs 
against it.


I also couldn't find any other Kotlin projects in Debian which 
build-depend on Kotlin (aside from Kotlin itself and some related plugins).


What do you think?

-- Jérôme

Bug#1057128: bookworm-pu: package gnutls28/3.7.9-2+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-11-30 at 09:30 +0100, Andreas Metzler wrote:
> I would like to fix CVE-2023-5981 / GNUTLS-SA-2023-10-23 for stable
> (no DSA forthcoming, to fixed by stable update.) The patch is
> cherrypicked from upstream 3.8.2 release.

Please go ahead.

Regards,

Adam

Bug#1057116: bookworm-pu: package lxc/1:5.0.2-1+deb12u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Thu, 2023-11-30 at 02:06 +, Mathias Gibbens wrote:
> The version of lxc in bookworm fails to create ephemeral copies of
> containers. This is affecting Debian users, as two different bugs
> have
> been reported in addition to an upstream bug report.
> 
> A fix was merged into the upstream repo earlier today, and I have
> cherry-picked it into the packaging for unstable which I have just
> uploaded. I would like to get this fix into bookworm, as it is a
> regression compared to lxc in bullseye.

Please go ahead.

Regards,

Adam

Bug#1057070: bookworm-pu: package adequate/0.15.9~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-11-29 at 07:47 +0100, Andreas Beckmann wrote:
> This is a rebuild of the package from sid to fix the autopkgtests on
> !amd64. The symbol-size-mismatch issue can only happen on amd64,
> therefore it cannot be reproduced elsewhere. Skip the specific test
> on
> !amd64 (in a generic way).

Please go ahead.

Regards,

Adam

Bug#1057071: bookworm-pu: package rust-sd/0.7.6-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-11-29 at 08:10 +0100, Andreas Beckmann wrote:
> version 0.74-1 which is higher than the 0.7.6-1 currently in bookworm
> from src:rust-sd, violating version ordering contraints.
> 0.80 is a made up version higher than any src:sd version ever in the
> archive and lower than src:rust-sd 1.0 in sid.

Please go ahead.

Regards,

Adam

Bug#1057069: bookworm-pu: package midge/0.2.41+dfsg-1~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Wed, 2023-11-29 at 07:27 +0100, Andreas Beckmann wrote:
> This is a rebuild of the package from sid to remove some likely not
> dfsg-free files.

Please go ahead.

Regards,

Adam

Bug#1057038: bookworm-pu: package php-phpseclib3/3.0.19-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2023-11-28 at 14:08 +0100, David Prévot wrote:
> Please allow to fix CVE-2023-49316 (#1057008) in the next point
> release.
> I assume from the bug report wording that it isn’t worth a DSA
> (security
> team X-Debbugs-Cced in case I misunderstood).
> 
> The changelog refers to a trivial change (gbp.conf and control) for
> the
> build process, and the three line upstream patch (+comments +test) to
> fix the issue.

Please go ahead.

Regards,

Adam

Bug#1057289: qtractor hangs on startup

[tcrass]

Package: qtractor
Version: 0.9.36-1
Severity: important
X-Debbugs-Cc: m...@tcrass.de

Dear Maintainer,

I have a Debian testing system with pipewire as jack replacement, which worked 
without any problem with all kinds of audio software  -- and,  for most part 
(ardour, stand-alone synths...), still does. After a recent upgrade, however, 
qtractor (0.9.36, i. e. the latest version from testing) started to behave 
strangely: the GUI window comes up, an I still can click menu items, toolbar 
buttons etc., but the mouse cursor stays in busy mode, and the applications 
seems to fail to connect to the audio system. For instance, qtractor's mixer 
doesn't show any audio buses, and qtractor won't show up in qpwgraph.

The cause of the problem is probably the recent introduction of pipewire 1.0.0 
into testing. In fact, qtractor's upstream commit log mentions one commit 
(d2d9fa9a), tagged with "Fixed an ancient hack on session init to wait to JACK 
service start up, which hang up while on pipewire-jack >= 1.0.0 
(EXPERIMENTAL)". I can confirm that qtractor built directly from upstream 
source seems to work flawlessly with testing's latest pipewire version.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages qtractor depends on:
ii  jackd 5+nmu1
ii  libasound21.2.10-1
ii  libaubio5 0.4.9-4.3+b2
ii  libc6 2.37-12
ii  libgcc-s1 13.2.0-7
ii  libjack0 [libjack-0.125]  1:0.126.0-2
ii  liblilv-0-0   0.24.22-1
ii  liblo70.31-1
ii  libmad0   0.15.1b-10.1+b1
ii  libogg0   1.3.5-3
ii  libqt6core6   6.4.2+dfsg-19
ii  libqt6gui66.4.2+dfsg-19
ii  libqt6widgets66.4.2+dfsg-19
ii  libqt6xml66.4.2+dfsg-19
ii  librubberband23.3.0+dfsg-2
ii  libsamplerate00.2.2-4
ii  libsndfile1   1.2.2-1
ii  libstdc++613.2.0-7
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  libxcb1   1.15-1
ii  zlib1g1:1.2.13.dfsg-3

qtractor recommends no packages.

qtractor suggests no packages.

-- no debconf information

Bug#1056987: bookworm-pu: package ca-certificates-java/20230710~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2023-11-27 at 16:32 +0100, Andreas Beckmann wrote:
> After openjdk was updated in bookworm, we can backport the proper
> fixes for
> the dependency and trigger loops and defer java certificate
> population
> to a trigger. That allows to remove the HACK needed to allow
> configuration with a not yet configured jre package.

Please go ahead.

Regards,

Adam

Bug#1057265: cron: Uncheck return values of set*id() family functions

[Christian Kastner]

Hi Jeffrey,

On 2023-12-02 11:39, Jeffrey Bencteux wrote:
> Hi,
> 
> Both setuid() and setgid() return values are not checked in cron's code used 
> to execute user-provided commands:

This issue was reported as CVD-2006-2607 and fixed a long time ago.

Here's the relevant patch:

https://sources.debian.org/src/cron/3.0pl1-162/debian/patches/fixes/Check-privilege-drop-results-CVE-2006-2607.patch/

Are you perhaps looking at the unpatched source?

Best,
Christian

Bug#1056934: bookworm-pu: libde265/1.0.11-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-11-26 at 22:45 +, Thorsten Alteholz wrote:
> The attached debdiff for libde265 fixes CVE-2023-27102, CVE-2023-
> 27103, 
> CVE-2023-43887 and CVE-2023-47471 in Bookworm.
> Except CVE-2023-43887 all others are marked as no-dsa by the security
> team 
> (CVE-2023-43887 appeared recently and was not evaluated yet).

Please go ahead.

Regards,

Adam

Bug#1056958: bookworm-pu: package nvidia-graphics-drivers-tesla/525.147.05-3~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2023-11-27 at 10:19 +0100, Andreas Beckmann wrote:
> In oder to fix CVE-2023-31022 we need to upgrade
> nvidia-graphics-drivers-tesla to a new upstream release.

Please go ahead.

Regards,

Adam

Bug#1056744: bookworm-pu: package nvidia-graphics-drivers/525.147.05-1~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-11-25 at 20:20 +0100, Andreas Beckmann wrote:
> In oder to fix CVE-2023-31022 we need to upgrade
> nvidia-graphics-drivers-tesla-470 to a new upstream release.

Please go ahead.

Regards,

Adam

Bug#1056741: bookworm-pu: package nvidia-open-gpu-kernel-modules/525.147.05-1~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-11-25 at 19:59 +0100, Andreas Beckmann wrote:
> In order to fix CVE-2023-31022 we need to upgrade
> nvidia-open-gpu-kernel-modules to a new upstream release.
> (This package must match the version of src:nvidia-graphics-drivers
> and/or src:nvidia-graphics-drivers-tesla to be useful, and these two
> packages in non-free need to be updated for CVE-2023-31022, too.)

Please go ahead.

Regards,

Adam

Bug#1056737: bookworm-pu: minizip/1.1-8+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-11-25 at 18:01 +, Thorsten Alteholz wrote:
> The attached debdiff for minizip fixes CVE-2023-45853 in Bookworm.
> This 
> CVE has been marked as no-dsa by the security team.

Please go ahead.

Regards,

Adam

Bug#1056715: bullseye-pu: package nvidia-graphics-drivers-tesla-470/470.223.02-1~deb11u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-11-25 at 11:11 +0100, Andreas Beckmann wrote:
> Control: usertags -2 pu
> Control: tags -2 = bookworm
> Control: retitle -2 bookworm-pu: package nvidia-graphics-drivers-
> tesla-470/470.223.02-1~deb12u1
> 
> [ Reason ]
> In oder to fix CVE-2023-31022 we need to upgrade
> nvidia-graphics-drivers-tesla-470 to a new upstream release.

Please go ahead (x2).

Regards,

Adam

Bug#1056358: bookworm-pu: package needrestart/3.6-4+deb12u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2023-11-21 at 11:35 -0500, Antoine Beaupre wrote:
> needrestart, starting with bookworm, supports more microcode checks
> than before. In particular, it now checks AMD CPUs.
> 
> The amd64-microcode package seem to ship *less* firmware files than
> its Intel counterpart, which leads to *many* machines (half a dozen)
> in our fleet to suddenly start warning us about "UNKNOWN" firmware
> status.
> 
[...]
> [ 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

There doesn't appear to be a debdiff attached.

Regards,

Adam

Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure

[Niko Tyni]

Control: forwarded -1 https://github.com/tonycoz/imager/issues/522

On Sat, Dec 02, 2023 at 07:24:39PM +0200, Niko Tyni wrote:
> On Sat, Dec 02, 2023 at 01:40:51PM +0100, gregor herrmann wrote:
> > On Sat, 02 Dec 2023 14:24:01 +0200, Niko Tyni wrote:

> It can be reproduced like this with the libimager-perl binaries
> currently in sid and every tiff file I tried with, for example
> test/images/palette-1c-8b.tiff in src:tiff.

Further simplifying, this fails in the exact same way:

  $ perl -MImager -e '$i=Imager->new; Imager::init_log(); $i->read(file => 
shift) or die $i->_error_as_msg()' tiff/test/images/palette-1c-8b.tiff

> I note it says "filesize 0". The patch determines the file size with
> 
>   uint64_t filesize = TIFFGetFileSize(tif);
> 
> and TIFFGetFileSize() is in src:tiff libtiff/tiffiop.h as follows:
> 
>   #define TIFFGetFileSize(tif) ((*(tif)->tif_sizeproc)((tif)->tif_clientdata))
 
>From http://www.simplesystems.org/libtiff/functions/TIFFOpen.html

  TIFFClientOpen() is like TIFFOpen() except that the caller supplies a
  collection of functions that the library will use to do UNIX-like I/O
  operations. The readproc and writeproc functions are called to read and
  write data at the current file position. seekproc is called to change
  the current file position à la lseek() (2). closeproc is invoked to
  release any resources associated with an open file. sizeproc is invoked
  to obtain the size in bytes of a file. mapproc and unmapproc are called
  to map and unmap a file's contents in memory; c.f. mmap() (2) and
  munmap() (2). The clientdata parameter is an opaque "handle" passed to
  the client-specified routines passed as parameters to TIFFClientOpen().

>From 
>https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L302

  static toff_t sizeproc(thandle_t x) {
return 0;
  }

which is used as the TIFFClientOpen() argument in i_readtiff_wiol():

  
https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L710

So it looks like libimager-perl is always saying the file size is 0,
and this hasn't hurt earlier but now does with the src:tiff CVE-2023-6277
patch.

Not sure where this leaves us, but I've just reported it at

  https://github.com/tonycoz/imager/issues/522

-- 
Niko

Bug#1056614: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi MigueL,

there are reverse dependencies that need to be taken care of:

Checking reverse dependencies...
# Broken Depends:
db2twitter: db2twitter
retweet: retweet
twitterwatch: twitterwatch

# Broken Build-Depends:
retweet: python3-tweepy


In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.

Please file an RM bug for each package that should be removed.

  Thorsten

Bug#1057161: reverse dependencies

[Thorsten Alteholz]

To: 1057...@bugs.debian.org
Subject: reverse dependencies


Control: tags -1 + moreinfo

Hi Sebastian,

there are reverse dependencies that need to be taken care of:

Checking reverse dependencies...
# Broken Depends:
debian-design: design-desktop-animation
ogre-1.9: blender-ogrexml-1.9

# Broken Build-Depends:
gfpoken: blender

In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1057046: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Matthias,

there are reverse dependencies that need to be taken care of:

Checking reverse dependencies...
# Broken Build-Depends:
gcc-9-cross: autoconf2.64
gcc-9-cross-mipsen: autoconf2.64
gcc-9-cross-ports: autoconf2.64

In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1057204: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Andreas,

there are reverse dependencies that need to be taken care of:

Checking reverse dependencies...
# Broken Depends:
r-bioc-hdf5array: r-bioc-hdf5array
r-bioc-rhdf5: r-bioc-rhdf5

# Broken Build-Depends:
r-bioc-hdf5array: r-bioc-rhdf5filters
r-bioc-rhdf5: r-bioc-rhdf5filters

In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1057288: www.debian.org: use of wml::debian::translation-check header breaks translation of "Galician"

[Holger Wansing]

Package: www.debian.org
X-Debbugs-CC: a...@debian.org

I just found (more or less by accident), that using the
wml::debian::translation-check header in wml files breaks the translation of
the word "Galician".
So this counts for all pages but English.
The result can be found on pages like

https://www.debian.org/releases/trixie/releasenotes.nl.html
https://www.debian.org/releases/trixie/releasenotes.zh-cn.html

or

https://www.debian.org/doc/user-manuals.fr.html#refcard
https://www.debian.org/doc/user-manuals.es.html#refcard

All those pages have a line with HTML | text | PDF links, where the
language entry at the beginning is blank.


Removing the translation-check header from the respective wml file will
make the "Galician" word appear.
(Interestingly, all other language names are correctly translated in either
way!)

My wild guess would be this being a wml issue (thus abe in CC), but I would be 
more comfortable, if I could get more debugging info, like the full wml 
commandline, or the like.
Don't know, how to get this though ...


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1056565: dhcpcd-base: fails to write multiple search domains to /etc/resolv.conf

[Francesco Poli]

On Mon, 27 Nov 2023 11:12:45 +0200 Martin-Éric Racine wrote:

> On Sat, 25 Nov 2023 00:38:25 +0100 Francesco Poli
>  wrote:
> > On Thu, 23 Nov 2023 14:00:12 +0200 Martin-Éric Racine wrote:
[...]
> > > You might wanna check whether Rocky Linux has patched their DHCP
> > > clients or altered their default dhcpcd.conf to make this succeed. If
> > > that's the case, please point me to the relevant changes.
> >
> > AFAICT, the Rocky Linux machine has the ISC DHCP client
> > and /etc/resolv.conf is written by a script /usr/sbin/dhclient-script,
> > which obtains data from the ISC DHCP client.
> 
> That's not what I asked.

I am sorry, if I misunderstood your request.
I thought you were asking to be pointed to changes relevant to dhcpcd.
Since the DHCP client I tested on Rocky Linux is the ISC DHCP client, I
considered any patches for that client as irrelevant to dhcpcd (which
is not a fork of the ISC DHCP client, is it?).

Anyway, I tried to search for the Rocky Linux ISC DHCP client source
package. I am no Rocky Linux (Red Hat Enterprise Linux) expert, but I
think it's

The distro-specific patches seem to be collected in


Maybe the following patch is relevant?

I am not sure.

What I am sure is that dhcpcd (but also isc-dhcp-client) in Debian
failed to get the two search domains provided by the DHCP server in the
domain search list (DHCP option 119), while a Rocky Linux ISC DHCP
client and a Windows client correctly got the two search domains.

As far as I understand, isc-dhcp-client is EOL and will be removed from
Debian in the near future. So I would like to see dhcpcd-base fixed and
able to correctly handle DHCP option 119...

Please forward my bug report upstream, if this is an upstream issue.
Thanks for your kind assistance!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpjVgLXqF3VG.pgp
Description: PGP signature

Bug#1057287: xtrkcad: please update Maintainer / Uploaders list

[Alexandre Detiste]

Source: xtrkcad
Version: 1:5.2.0Beta2.1-1
Severity: minor

Hi Jörg,

I think now you can make it official that you
are the maintainer of this package.

https://contributors.debian.org/contributor/dmarkle-guest@alioth/
https://qa.debian.org/developer.php?login=dmar...@ashtech.net

Greetings,


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

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

Bug#1057285: gsasl: autopkgtest fails sometimes on armhf

[Simon Josefsson]

Hi

I think this is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017638

If it happens in practice we could ignore this self check or add some loop 
around this error message.

/Simon

> 2 dec. 2023 kl. 18:45 skrev Andreas Metzler :
> 
> Source: gsasl
> Version: 2.2.0-2
> 
> Hello,
> 
> Since gsasl's autopkgtest currently blocks gnutls28's migration to
> testing I gave it a quick look on the porterbox (abel.debian.org). The
> autopkgtest seems to be flacky on both sid and trixie. - Running all
> tests in loop 40 times (without valgrind, to speed things up) yields at
> least one error (either gsasl-mailutils-gs2krb5-gssapi or
> gsasl-dovecot-gssapi). An example looks like this. (XXX-lines and EXIT
> CODE reporting are local additions):
> 
> OK Run:
> TEST debian/tests/gsasl-mailutils-gs2krb5-gssapi
> XXXx-XXX
> + command -v valgrind
> + GSASL= /usr/bin/gsasl IMAP4D= /usr/sbin/imap4d 
> tests/gsasl-mailutils-gs2krb5-gssapi.sh
> + : /usr/bin/gsasl
> + : /usr/sbin/imap4d
> + /usr/bin/gsasl --version
> + grep ^gsasl (GNU SASL
> gsasl (GNU SASL) 2.2.0
> + + grep  GSSAPI
> /usr/bin/gsasl --client-mechanisms
> ANONYMOUS EXTERNAL LOGIN PLAIN SECURID NTLM DIGEST-MD5 CRAM-MD5 SCRAM-SHA-1 
> SCRAM-SHA-1-PLUS SCRAM-SHA-256 SCRAM-SHA-256-PLUS SAML20 OPENID20 GSSAPI 
> GS2-KRB5
> + test no = yes
> + export 
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
> + command -v ss
> /usr/bin/ss
> + + grep ^imap4d (GNU Mailutils)
> /usr/sbin/imap4d --version
> imap4d (GNU Mailutils) 3.16
> + command -v id
> /usr/bin/id
> + command -v hostname
> /usr/bin/hostname
> + command -v kinit
> /usr/bin/kinit
> + command -v kdb5_util
> /sbin/kdb5_util
> + command -v kadmin.local
> /sbin/kadmin.local
> + command -v krb5kdc
> /sbin/krb5kdc
> + mktemp -d
> + WORKDIR=/tmp/tmp.u55HmY6NH2
> + trap set +e; test -f $WORKDIR/k/pid && kill `cat $WORKDIR/k/pid`; test -f 
> $WORKDIR/imap4d.pid && kill `cat $WORKDIR/imap4d.pid`; tail -v -n +0 
> $WORKDIR/out-* $WORKDIR/kdc.log; rm -r $WORKDIR/imap4d.pid 
> $WORKDIR/mailutils.conf $WORKDIR/k $WORKDIR/*.log $WORKDIR/cc $WORKDIR/kt 
> $WORKDIR/out-*; rmdir $WORKDIR 0 INT QUIT ABRT PIPE TERM
> + : ametzler
> + id -gn
> + : ametzler
> + mkdir /tmp/tmp.u55HmY6NH2/k /tmp/tmp.u55HmY6NH2/k/etc
> + cat
> + hostname -d
> + hostname -f
> + cat
> + export KRB5CCNAME=/tmp/tmp.u55HmY6NH2/cc
> + export KRB5_CONFIG=/tmp/tmp.u55HmY6NH2/k/krb5.conf
> + export KRB5_KDC_PROFILE=/tmp/tmp.u55HmY6NH2/k
> + export KRB5_KTNAME=/tmp/tmp.u55HmY6NH2/kt
> + kdb5_util -P foo create -s
> Initializing database '/tmp/tmp.u55HmY6NH2/k/principal' for realm 
> 'GSASL.EXAMPLE',
> master key name 'K/M@GSASL.EXAMPLE'
> + hostname -f
> + kadmin.local addprinc -randkey imap/abel.debian.org
> + kadmin.local addprinc -pw bar ametzler
> + hostname -f
> + kadmin.local ktadd -k /tmp/tmp.u55HmY6NH2/kt imap/abel.debian.org
> Entry for principal imap/abel.debian.org with kvno 2, encryption type 
> aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/tmp.u55HmY6NH2/kt.
> Entry for principal imap/abel.debian.org with kvno 2, encryption type 
> aes128-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/tmp.u55HmY6NH2/kt.
> + i=0
> + + ss -na
> krb5kdc+ + grep LISTEN
> grep 0.0.0.0:17643
> -n -P /tmp/tmp.u55HmY6NH2/k/pid
> krb5kdc: starting...
> tcp   LISTEN 0  0 
> 0.0.0.0:17643  0.0.0.0:*
> + cat
> + i=0
> + ss -na
> + + grep LISTEN
> grep 0.0.0.0:19835
> + /usr/sbin/imap4d --config-file=/tmp/tmp.u55HmY6NH2/mailutils.conf 
> --debug-level=4711 --daemon --foreground
> + expr 0 + 1
> + i=1
> + test 1 = 10
> + sleep 1
> + ss -na
> + grep 0.0.0.0:19835
> + grep LISTEN
> tcp   LISTEN 0  0 
> 0.0.0.0:19835  0.0.0.0:*
> + hostname -f
> + /usr/bin/gsasl -m GSSAPI -d --no-starttls --imap abel.debian.org 19835
> + grep -q gss_init_sec_context /tmp/tmp.u55HmY6NH2/out-err
> + echo bar
> + kinit ametzler
> Password for ametzler@GSASL.EXAMPLE:
> + hostname -f
> + /usr/bin/gsasl -m GS2-KRB5 -d --no-starttls --imap abel.debian.org 19835 -z 
> ametzler
> + grep -q ^. OK AUTHENTICATE /tmp/tmp.u55HmY6NH2/out-gs2krb5
> + hostname -f
> + /usr/bin/gsasl -m GSSAPI -d --no-starttls --imap abel.debian.org 19835 -z 
> ametzler
> + grep -q ^. OK AUTHENTICATE /tmp/tmp.u55HmY6NH2/out-gssapi
> + echo PASS: tests/gsasl-mailutils-gs2krb5-gssapi.sh
> PASS: tests/gsasl-mailutils-gs2krb5-gssapi.sh
> + exit 0
> + set +e
> + test -f /tmp/tmp.u55HmY6NH2/k/pid
> + cat /tmp/tmp.u55HmY6NH2/k/pid
> + kill 16318
> + test -f /tmp/tmp.u55HmY6NH2/imap4d.pid
> + cat /tmp/tmp.u55HmY6NH2/imap4d.pid
> + kill 16336
> + tail -v -n +0 /tmp/tmp.u55HmY6NH2/out-err /tmp/tmp.u55HmY6NH2/out-gs2krb5 
> /tmp/tmp.u55HmY6NH2/out-gssapi /tmp/tmp.u55HmY6NH2/out-imapd 
> /tmp/tmp.u55HmY6NH2/kdc.log
> ==> /tmp/tmp.u55HmY6NH2/out-err <==
> Trying 'abel.debian.org'...
> * OK IMAP4rev1
> . CAPABILITY
> * CAPABILITY 

Bug#1057286: xtrkcad: Please package current stable version 5.2.2aGA

[Johanna Jerzembeck]

Package: xtrkcad
Version: 1:5.2.0Beta2.1-1+b1
Severity: wishlist

Dear Maintainer,

according to the project homepage the current stable version of
XTrackCAD is 5.2.2aGA. The upstream CHANGELOG shows quite a lot of
improvements and bugfixes after version 5.2.0Beta2 of the current Debian
package.

Please consider packaging the current stable version from upstream for
Debian.

Kind regards,

Johanna Jerzembeck

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

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

Versions of packages xtrkcad depends on:
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk2.0-0  2.24.33-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libzip4  1.7.3-1+b1
ii  xtrkcad-common   1:5.2.0Beta2.1-1

xtrkcad recommends no packages.

xtrkcad suggests no packages.

-- no debconf information

-- 
"Was ist ein Name? Was uns Rose heißt,
  Wie es auch hieße, würde lieblich duften."

Bug#1057285: gsasl: autopkgtest fails sometimes on armhf

[Andreas Metzler]

Source: gsasl
Version: 2.2.0-2

Hello,

Since gsasl's autopkgtest currently blocks gnutls28's migration to
testing I gave it a quick look on the porterbox (abel.debian.org). The
autopkgtest seems to be flacky on both sid and trixie. - Running all
tests in loop 40 times (without valgrind, to speed things up) yields at
least one error (either gsasl-mailutils-gs2krb5-gssapi or
gsasl-dovecot-gssapi). An example looks like this. (XXX-lines and EXIT
CODE reporting are local additions):

OK Run:
TEST debian/tests/gsasl-mailutils-gs2krb5-gssapi
XXXx-XXX
+ command -v valgrind
+ GSASL= /usr/bin/gsasl IMAP4D= /usr/sbin/imap4d 
tests/gsasl-mailutils-gs2krb5-gssapi.sh
+ : /usr/bin/gsasl
+ : /usr/sbin/imap4d
+ /usr/bin/gsasl --version
+ grep ^gsasl (GNU SASL
gsasl (GNU SASL) 2.2.0
+ + grep  GSSAPI
/usr/bin/gsasl --client-mechanisms
ANONYMOUS EXTERNAL LOGIN PLAIN SECURID NTLM DIGEST-MD5 CRAM-MD5 SCRAM-SHA-1 
SCRAM-SHA-1-PLUS SCRAM-SHA-256 SCRAM-SHA-256-PLUS SAML20 OPENID20 GSSAPI 
GS2-KRB5
+ test no = yes
+ export 
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
+ command -v ss
/usr/bin/ss
+ + grep ^imap4d (GNU Mailutils)
/usr/sbin/imap4d --version
imap4d (GNU Mailutils) 3.16
+ command -v id
/usr/bin/id
+ command -v hostname
/usr/bin/hostname
+ command -v kinit
/usr/bin/kinit
+ command -v kdb5_util
/sbin/kdb5_util
+ command -v kadmin.local
/sbin/kadmin.local
+ command -v krb5kdc
/sbin/krb5kdc
+ mktemp -d
+ WORKDIR=/tmp/tmp.u55HmY6NH2
+ trap set +e; test -f $WORKDIR/k/pid && kill `cat $WORKDIR/k/pid`; test -f 
$WORKDIR/imap4d.pid && kill `cat $WORKDIR/imap4d.pid`; tail -v -n +0 
$WORKDIR/out-* $WORKDIR/kdc.log; rm -r $WORKDIR/imap4d.pid 
$WORKDIR/mailutils.conf $WORKDIR/k $WORKDIR/*.log $WORKDIR/cc $WORKDIR/kt 
$WORKDIR/out-*; rmdir $WORKDIR 0 INT QUIT ABRT PIPE TERM
+ : ametzler
+ id -gn
+ : ametzler
+ mkdir /tmp/tmp.u55HmY6NH2/k /tmp/tmp.u55HmY6NH2/k/etc
+ cat
+ hostname -d
+ hostname -f
+ cat
+ export KRB5CCNAME=/tmp/tmp.u55HmY6NH2/cc
+ export KRB5_CONFIG=/tmp/tmp.u55HmY6NH2/k/krb5.conf
+ export KRB5_KDC_PROFILE=/tmp/tmp.u55HmY6NH2/k
+ export KRB5_KTNAME=/tmp/tmp.u55HmY6NH2/kt
+ kdb5_util -P foo create -s
Initializing database '/tmp/tmp.u55HmY6NH2/k/principal' for realm 
'GSASL.EXAMPLE',
master key name 'K/M@GSASL.EXAMPLE'
+ hostname -f
+ kadmin.local addprinc -randkey imap/abel.debian.org
+ kadmin.local addprinc -pw bar ametzler
+ hostname -f
+ kadmin.local ktadd -k /tmp/tmp.u55HmY6NH2/kt imap/abel.debian.org
Entry for principal imap/abel.debian.org with kvno 2, encryption type 
aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/tmp.u55HmY6NH2/kt.
Entry for principal imap/abel.debian.org with kvno 2, encryption type 
aes128-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/tmp.u55HmY6NH2/kt.
+ i=0
+ + ss -na
krb5kdc+ + grep LISTEN
grep 0.0.0.0:17643
 -n -P /tmp/tmp.u55HmY6NH2/k/pid
krb5kdc: starting...
tcp   LISTEN 0  0 
0.0.0.0:17643  0.0.0.0:*
+ cat
+ i=0
+ ss -na
+ + grep LISTEN
grep 0.0.0.0:19835
+ /usr/sbin/imap4d --config-file=/tmp/tmp.u55HmY6NH2/mailutils.conf 
--debug-level=4711 --daemon --foreground
+ expr 0 + 1
+ i=1
+ test 1 = 10
+ sleep 1
+ ss -na
+ grep 0.0.0.0:19835
+ grep LISTEN
tcp   LISTEN 0  0 
0.0.0.0:19835  0.0.0.0:*
+ hostname -f
+ /usr/bin/gsasl -m GSSAPI -d --no-starttls --imap abel.debian.org 19835
+ grep -q gss_init_sec_context /tmp/tmp.u55HmY6NH2/out-err
+ echo bar
+ kinit ametzler
Password for ametzler@GSASL.EXAMPLE:
+ hostname -f
+ /usr/bin/gsasl -m GS2-KRB5 -d --no-starttls --imap abel.debian.org 19835 -z 
ametzler
+ grep -q ^. OK AUTHENTICATE /tmp/tmp.u55HmY6NH2/out-gs2krb5
+ hostname -f
+ /usr/bin/gsasl -m GSSAPI -d --no-starttls --imap abel.debian.org 19835 -z 
ametzler
+ grep -q ^. OK AUTHENTICATE /tmp/tmp.u55HmY6NH2/out-gssapi
+ echo PASS: tests/gsasl-mailutils-gs2krb5-gssapi.sh
PASS: tests/gsasl-mailutils-gs2krb5-gssapi.sh
+ exit 0
+ set +e
+ test -f /tmp/tmp.u55HmY6NH2/k/pid
+ cat /tmp/tmp.u55HmY6NH2/k/pid
+ kill 16318
+ test -f /tmp/tmp.u55HmY6NH2/imap4d.pid
+ cat /tmp/tmp.u55HmY6NH2/imap4d.pid
+ kill 16336
+ tail -v -n +0 /tmp/tmp.u55HmY6NH2/out-err /tmp/tmp.u55HmY6NH2/out-gs2krb5 
/tmp/tmp.u55HmY6NH2/out-gssapi /tmp/tmp.u55HmY6NH2/out-imapd 
/tmp/tmp.u55HmY6NH2/kdc.log
==> /tmp/tmp.u55HmY6NH2/out-err <==
Trying 'abel.debian.org'...
* OK IMAP4rev1
. CAPABILITY
* CAPABILITY IMAP4rev1 NAMESPACE ID IDLE LITERAL+ UNSELECT AUTH=GSSAPI 
AUTH=ANONYMOUS AUTH=EXTERNAL AUTH=LOGIN AUTH=PLAIN AUTH=SECURID AUTH=DIGEST-MD5 
AUTH=CRAM-MD5 AUTH=SCRAM-SHA-1 AUTH=SCRAM-SHA-1-PLUS AUTH=SCRAM-SHA-256 
AUTH=SCRAM-SHA-256-PLUS AUTH=SAML20 AUTH=OPENID20 AUTH=GSSAPI AUTH=GS2-KRB5
. OK CAPABILITY Completed
. AUTHENTICATE GSSAPI
+
/usr/bin/gsasl: mechanism error: GSSAPI error in client while negotiating 
security context in gss_init_sec_context() in SASL library.  This is most 
likely due insufficient 

Bug#1037098: RFS: serious-engine

[Alexandre Detiste]

Is this in a good shape ?

Bug#1055957: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Chris,

there are reverse dependencies that need to be taken care of:

Checking reverse dependencies...
# Broken Depends:
netpipe: netpipe-pvm
slpvm: slang-pvm
tablix2: tablix2

# Broken Build-Depends:
netpipe: pvm-dev
slpvm: pvm-dev
tablix2: pvm-dev

In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1055867: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Stéphane,

there are reverse dependencies that need to be taken care of:

Checking reverse dependencies...
# Broken Build-Depends:
ocaml-cstruct: libmigrate-parsetree-ocaml-dev
ocaml-odoc: libmigrate-parsetree-ocaml-dev
ppx-import: libmigrate-parsetree-ocaml-dev

In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1055839: reverse dependency

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Chris,

there is a reverse dependency that needs to be taken care of:

Checking reverse dependencies...
# Broken Depends:
dhis-mx-sendmail-engine: dhis-mx-sendmail-engine

In case they matter, this needs to be addressed first. Please remove the 
moreinfo tag once that is done.


  Thorsten

Bug#1057284: migrate get-www-stats to python3

[Thomas Lange]

Package: www.debian.org

The script get-www-stats is using python2. It does not work with
python3 because it uses counts.iteritems which must be migrated.

The script should also ignore log entries with produces 403 on the web
server. Currently this is half of them because of a lot of access to
the uncompressed oval...xml files.

We only have this python2 script in the webwml repo. Python scripts in
security/oval are already python3.

regards Thomas

Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure

[Niko Tyni]

(re-adding Cc: tiff@pdo)

On Sat, Dec 02, 2023 at 01:40:51PM +0100, gregor herrmann wrote:
> On Sat, 02 Dec 2023 14:24:01 +0200, Niko Tyni wrote:
> 
> > It regressed with tiff_4.5.1+git230720-2 which is currently blocked from
> > migrating to trixie because libimager-perl autopkgtests are failing too.
> > 
> > Changes:
> >  tiff (4.5.1+git230720-2) unstable; urgency=high
> >  .
> >* Backport security fix for CVE-2023-6277, passing a crafted tiff file to
> >  TIFFOpen() API may allow a remote attacker to cause a denial of service
> >  (closes: #1056751).
> > 
> > I see libimager-perl upstream has released 1.021 with some tiff related
> > changes. I haven't checked if those fix the issue, or whether libtiff
> > is actually broken. Feel free to reassign as needed.
> 
> I've imported 1.021 into our git repo yesterday, and there it fails
> the same way (I hadn't nticed that 1.020 in sid also fails …)
> 
> So -- is this a bug in Imager or in tiff?

Can't quite say, but sharing what I found:

The test creates TIFF/testout/t106.tiff with
Imager::File::TIFF::i_writetiff_wiol() and then tries to read it back with

  open(FH,"testout/t106.tiff") or die "cannot open testout/t106.tiff\n";
  binmode(FH);
  $IO = Imager::io_new_fd(fileno(FH));
  my $cmpimg = Imager::File::TIFF::i_readtiff_wiol($IO);

Adding an Imager->_error_as_msg() call after that gives

  Error opening file: Failed to read directory at offset 37014 at 
TIFF/t/t10tiff.t line 49.

Also there's t106tiff.log with plenty of diagnostics including

  [2023/12/02 16:29:42]   imtiff.c:237 1: tiff warning Requested memory 
size for TIFF directory of 168 is greather than filesize 0. Memory not 
allocated, TIFF directory not read

which matches the CVE-2023-6277 changes in libtiff, see

  
https://sources.debian.org/src/tiff/4.5.1%2Bgit230720-2/debian/patches/CVE-2023-6277.patch/

It can be reproduced like this with the libimager-perl binaries
currently in sid and every tiff file I tried with, for example
test/images/palette-1c-8b.tiff in src:tiff.

  
https://sources.debian.org/src/tiff/4.5.1%2Bgit230720-2/test/images/palette-1c-8b.tiff/

  $ perl -MImager::File::TIFF -E '$i = Imager::io_new_fd(*STDIN); 
Imager::init_log(); Imager::File::TIFF::i_readtiff_wiol($i) or die 
Imager->_error_as_msg' < tiff/test/images/palette-1c-8b.tiff
  [2023/12/02 17:16:03]  log.c:56  0: Imager - log started (level = 1)
  [2023/12/02 17:16:03]  Imager.xs:267 1: Imager 1.020 starting
  [2023/12/02 17:16:03]   imtiff.c:700 1: i_readtiff_wiol(ig 
0x55a6ece33890, allow_incomplete 0, page 0)
  [2023/12/02 17:16:03]   io.c:242 1: mymalloc(size 8192) -> 
0x55a6ed426e70
  [2023/12/02 17:16:03]   imtiff.c:237 1: tiff warning Requested memory 
size for TIFF directory of 180 is greather than filesize 0. Memory not 
allocated, TIFF directory not read
  [2023/12/02 17:16:03]   io.c:266 1: myrealloc(block (nil), size 124)
  [2023/12/02 17:16:03]   imtiff.c:201 1: tiff error fmt Failed to read 
directory at offset %lu
  [2023/12/02 17:16:03]   io.c:242 1: mymalloc(size 41) -> 
0x55a6ece1d480
  [2023/12/02 17:16:03]   imtiff.c:715 1: i_readtiff_wiol: Unable to open 
tif file
  [2023/12/02 17:16:03]   io.c:242 1: mymalloc(size 19) -> 
0x55a6ed36be90
  [2023/12/02 17:16:03]   io.c:253 1: myfree(p 0x55a6ed42e250)
  Error opening file: Failed to read directory at offset 23716 at -e line 1.
  [2023/12/02 17:16:03]  iolayer.c:424 1: io_glue_DESTROY(ig 0x55a6ece33890)
 
I note it says "filesize 0". The patch determines the file size with

  uint64_t filesize = TIFFGetFileSize(tif);

and TIFFGetFileSize() is in src:tiff libtiff/tiffiop.h as follows:

  #define TIFFGetFileSize(tif) ((*(tif)->tif_sizeproc)((tif)->tif_clientdata))

which is where I called it a day :)

So I suppose the way Imager reads the file here does not initialize the
data structure in a way that the patched libtiff expects?
-- 
Niko