Bug#1063737: nvidia-graphics-drivers-tesla-470 470.223.02-4~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1063737 = 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: nvidia-graphics-drivers-tesla-470
Version: 470.223.02-4~deb12u1

Explanation: restore compatibility with newer Linux kernel builds; stop 
building nvidia-cuda-mps

Bug#1062932: Confirm, Bookworm still broken

[Kate Korsaro]

Hi guys,
tried an update this morning and it still broken for Bookworm.

Bug#1062057: chipmunk: NMU diff for 64-bit time_t transition

[Stephen Kitt]

Hi,

On Wed, 31 Jan 2024 08:50:37 +, Steve Langasek  wrote:
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> chipmunk as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).

[…]

> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if
> information becomes available that your package should not be included in
> the transition, there is time for us to amend the planned uploads.

I’ve fixed the header problems preventing analysis in 7.0.3-6 (just uploaded
to unstable), would it be possible to re-run the ABI analysis?

Regards,

Stephen


pgpqEUBqjjZQk.pgp
Description: OpenPGP digital signature

Bug#1063673: ITP: llama.cpp -- Inference of Meta's LLaMA model (and others) in pure C/C++

[Petter Reinholdtsen]

I tried building the CPU edition on one machine and run it on another,
and experienced illegal instruction exceptions.  I suspect this mean one
need to be careful when selecting build profile to ensure it work on all
supported Debian platforms.

I would be happy to help getting this up and running.  Please let me
know when you have published a git repo with the packaging rules.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1063829: ITP: tftp-proxy -- proxy to redirect TFTP requests to HTTP

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian.a...@manchmal.in-ulm.de

* Package name: tftp-proxy
  Version : 1.0.0
  Upstream Contact: Arnoud Vermeer 
* URL : https://github.com/openfibernet/tftp-proxy
* License : Apache-2.0
  Programming Lang: Go
  Description : A TFTP server that proxies request to an HTTP
backend if a file is not found.

 This program is basically a minimalistic TFTP server. As an extra
 however, it will forward request that cannot be served to a
 configurable HTTP backend.
 .
 This is useful in a network where the actual TFTP server is relatively
 far away: Due to the simple design of TFTP, already 40ms of latency
 result in a very poor performance, tftp-proxy can shortcut that to
 network speed.
 .
 Additionally, the requests may be directed to a caching HTTP server.



signature.asc
Description: PGP signature

Bug#1063800: Should we restrict libtread-pool to 64bit only

[Andreas Tille]

Am Mon, Feb 12, 2024 at 10:09:43PM -0500 schrieb Aaron M. Ucko:
> Andreas Tille  writes:
> 
> >Build-Depends libthread-pool 4.0.0 which does not build
> >for 32bit architectures[1]
> 
> I see a fix in experimental:
> 
> https://buildd.debian.org/status/package.php?p=libthread-pool=experimental
> 
> Why not just reupload it to unstable?

Done.  Thanks a lot for the reminder
Andreas. 

-- 
http://fam-tille.de

Bug#1063191: libcifpp-data: Incorrect URL in update-libcifpp-data script

[Andreas Tille]

Hi Maarten,

since last September there is a new upstream version in Git which was
not uploaded.  I see less instances of ftp.wwpdb.org in this code but
there are some remainings.  It would be great if you could upload your
preparation after checking that the bug below is fixed.

Kind regards
   Andreas.

Am Mon, Feb 05, 2024 at 11:27:36AM -0500 schrieb Rick Bernard:
> Package: libcifpp-data
> Version: 5.0.7.1-3
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>Installing libcifpp-data via "apt install".  The incorrect URL causes apt 
> to
> hang for a long period of time before returrning to a prompt.  As a result, 
> the
> file supposed to be loaced in /var/cache/libcifpp/components.cif fails to
> download.  The Stable version of this package was showing timeout errors when
> attempting to connect to https://ftp.wwpdb.org.  The correct URL that is
> published by wwpdb.org is https://files.wwpdb.org for downloading via HTTP.
> This will happen durring install via apt when you are prompted Package
> configuration about setting up weekly downloads of these data files from
> wwpdb.org.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Editing the file /etc/cron.weekly/update-libcifpp-data and changing the 
> URL
> for the components.cif download from https://ftp.wwpdb.org to
> https://files.wwpdb.org leaving all subpaths the same resolves the issue.  
> This
> also helps with the stable version of this package and fixes dpkg and apt when
> running "dpkg --configure -a"
> 
>* What was the outcome of this action?
>  Resolves the package install and fixes apt/dpkg package management 
> system.
> 
>* What outcome did you expect instead?
> The expected outcome is that "apt install" will successfully install the
> package and be able to run the download scripts successfully.
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: 12.4
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-17-amd64 (SMP w/12 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libcifpp-data depends on:
> ii  debconf [debconf-2.0]  1.5.82
> 
> libcifpp-data recommends no packages.
> 
> libcifpp-data suggests no packages.
> 
> -- debconf information:
> * libcifpp/update: true

> --- update-libcifpp-data.orig 2024-02-05 11:13:15.964579981 -0500
> +++ update-libcifpp-data  2024-02-05 11:24:35.219320601 -0500
> @@ -60,7 +60,7 @@
>  
>  # Update the dictionaries
>  
> -update_dictionary "/var/cache/libcifpp/components.cif" 
> "https://ftp.wwpdb.org/pub/pdb/data/monomers/components.cif.gz;
> +update_dictionary "/var/cache/libcifpp/components.cif" 
> "https://files.wwpdb.org/pub/pdb/data/monomers/components.cif.gz;
>  update_dictionary "/var/cache/libcifpp/mmcif_pdbx.dic" 
> "https://mmcif.wwpdb.org/dictionaries/ascii/mmcif_pdbx_v50.dic.gz;
>  update_dictionary "/var/cache/libcifpp/mmcif_ma.dic" 
> "https://github.com/ihmwg/ModelCIF/raw/master/dist/mmcif_ma.dic;
>  

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#979332: New upstream version

[David Prévot]

Control: severity -1 serious

Le Mon, Feb 12, 2024 at 06:15:27PM -0700, skizz...@skizzerz.net a écrit :
> Seems the current version is causing errors due to using syntax removed in
> PHP 8. I'm seeing the following error message:
> TypeError: implode(): Argument #2 ($array) must be of type ?array, string
> given /usr/share/php/simplepie/library/SimplePie/Parse/Date.php(544)
> 
> This was fixed upstream a while ago, so I'm bumping this bug in hopes that
> the package can be updated. The dokuwiki package depends on this one and
> is broken on the pages that make use of the library, causing some wiki pages
> to become inaccessible after an upgrade to bookworm.

Increasing the severity accordingly (it affects stable too I assume…).

Regards

David


signature.asc
Description: PGP signature

Bug#1063819: dh-sysuser: uses deprecated given/when

[Niko Tyni]

On Tue, Feb 13, 2024 at 01:07:59AM +0100, Lorenzo Puliti wrote:
> Package: dh-sysuser
> Version: 1.3.10+really1.4.4
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: Niko Tyni , plore...@disroot.org
> 
> Building runit package I have

>dh_sysuser -O--sourcedirectory=runit-2.1.2/src
> given is deprecated at /usr/bin/dh_sysuser line 37.
> when is deprecated at /usr/bin/dh_sysuser line 38.
> when is deprecated at /usr/bin/dh_sysuser line 39.
> when is deprecated at /usr/bin/dh_sysuser line 46.
>dh_install -O--sourcedirectory=runit-2.1.2/src
>dh_installdocs -O--sourcedirectory=runit-2.1.2/src
>dh_buildinfo -O--sourcedirectory=runit-2.1.2/src
> 
> so I guess it needs an update like in dh-runit's  #1060709
> What I'm not sure is if this need to be fixed in unstable as
> possible or it can wait longer. The autopkgtest covers only
> sysuser-helper, so the package does not fail to build.
> Patch at the bottom.
> 
> Dear Niko, please bump the severity if this is urgent.

No particular urgency from my side, but thanks for asking.

The similar ones I filed at severity:serious for the Perl 5.38
transition were precisely because they were causing build or autopkgtest
failures. Those were technical blockers for getting the new perl into
testing. By your description this one is "just" cosmetic.

Of course it would be nice to fix it but it can wait :)

Thanks for your work on Debian,
-- 
Niko

Bug#1063828: clang-17: HIP detection for /usr

[Cordell Bloor]

Package: clang-17
Version: 1:17.0.6-5
Severity: wishlist
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

LLVM upstream added support for HIP in /usr, but it incorrectly reports
HIP as being installed in /usr/local [1]. I have not verified whether
this bug affects Debian or not, so it's possible that the Debian package has
additional patches that mitigate the issue. However, you may still want to
consider backporting the upstream fix [2].

Filing as severity wishlist until I verify that this bug affects the Debian
package. For now, it might just be nice to backport to match the upstream
search behaviour.

Sincerely,
Cory Bloor

[1]: https://github.com/llvm/llvm-project/issues/78344
[2]: 
https://github.com/llvm/llvm-project/commit/fcd3752342ebd193d4eef39b9c0730599eca4486

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

Kernel: Linux 6.6.9-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages clang-17 depends on:
ii  binutils2.42-2
ii  libc6   2.37-15
ii  libc6-dev   2.37-15
ii  libclang-common-17-dev  1:17.0.6-5
ii  libclang-cpp17  1:17.0.6-5
ii  libclang1-171:17.0.6-5
ii  libgcc-13-dev   13.2.0-13
ii  libgcc-s1   14-20240201-3
ii  libllvm17   1:17.0.6-5
ii  libobjc-13-dev  13.2.0-13
ii  libstdc++-13-dev13.2.0-13
ii  libstdc++6  14-20240201-3
ii  llvm-17-linker-tools1:17.0.6-5

Versions of packages clang-17 recommends:
ii  llvm-17-dev  1:17.0.6-5
ii  python3  3.11.6-1

Versions of packages clang-17 suggests:
pn  clang-17-doc  
pn  wasi-libc 

-- no debconf information

Bug#1063692: uruk: move files to /usr (DEP17)

[Joost van Baal-Ilić]

tags 1063692 +pending
thanks

Hi Helmut,

On Sun, Feb 11, 2024 at 02:17:47PM +0100, Helmut Grohne wrote:
> On Sun, Feb 11, 2024 at 10:19:50AM +0100, Joost van Baal-Ilić wrote:
> > Thanks a lot for this beautiful patch.  Do you intend to take care of 
> > uploading
> > it to unstable too?  If not, I'm happy to do that of course.
> 
> Thanks for the quick reply. I prefer you uploading it as you know your
> git workflow best. Let me know if you want me to NMU it. Realistically,
> we need this done by September 2024 to finish the transition in time.

Cool; just committed your patch; I'll take care of the upload.

Bye,

Joost

Bug#1063827: tahoe-lafs: new package tahoe-lafs depends on python3-future which is pending removal

[Alexandre Detiste]

Source: tahoe-lafs
Version: 1.17.0-1
Severity: important

Hi,

I noticed that the new package tahoe-lafs is bringing
a new dependency on python3-future which is RC broken
and pending removal (#1063264).

Version 1.19 doesn't get much better.

I can provide a patch upstream for a big cleanup,
but it would be easier if upstream is cooperative:
i.e. willing to drop Python2.7 compatibility
to get Python3.12 compatibility.

Greetings

---

tahoe-lafs $ grep future debian/ -r
debian/control: python3-future ,

tchet@brix /tmp/tahoe-lafs $ grep -e ' future' -e ' past' -r | wc -l
774


/tmp/tahoe-lafs-1.19.0 $ grep -e ' future' -e ' past' -r | wc -l
608


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

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

Bug#1063656: linux-image-6.1.0-18-amd64: Building nvidia modules (from Debian package) fails. Resulting kernel panics.

[Teemu Likonen]

* 2024-02-10 16:42:58+0100, Christoph Groth wrote:

> Package: src:linux
> Version: 6.1.76-1

This is probably the same bug as #1062932
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062932


signature.asc
Description: PGP signature

Bug#1061095: linux-image-6.6.11-amd64: 2.5gbit USB device with r8152 chipset only does 100baset

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 2024-01-18 at 13:42 +1100, Russell Coker wrote:
> Package: src:linux
> Version: 6.6.11-1
> Severity: normal
> Tags: upstream
> 
> [51076.208113] r8152-cfgselector 2-1: reset SuperSpeed USB device number 6 
> using xhci_hcd
> [51076.236596] r8152 2-1:1.0: firmware: direct-loading firmware 
> rtl_nic/rtl8156b-2.fw
> [51076.258622] r8152 2-1:1.0: ram code speedup mode fail
> [51076.258647] r8152 2-1:1.0: load rtl8156b-2 v2 04/27/23 successfully
> [51076.301913] r8152 2-1:1.0 eth0: v1.12.13
> [51076.697896] r8152 2-1:1.0 usb2.5g: renamed from eth0
> [51079.489807] r8152 2-1:1.0 usb2.5g: carrier on
> [51079.745192] r8152 2-1:1.0 usb2.5g: carrier off
> [51082.561105] r8152 2-1:1.0 usb2.5g: carrier on
> [51152.705733] r8152 2-1:1.0 usb2.5g: carrier off
> [51156.353013] r8152-cfgselector 2-1: USB disconnect, device number 6
> [51156.353455] xhci_hcd :00:14.0: WARN Set TR Deq Ptr cmd failed due to 
> incorrect slot or ep state.
> [51156.353492] r8152 2-1:1.0 usb2.5g: Stop submitting intr, status -108
> 
> Above is the relevant kernel message logs.
> 
> # mii-tool usb2.5g
> usb2.5g: 100 Mbit, half duplex, link ok

You should not use mii-tool for this; it only works speeds up to
1 Gbit (and even then only with some PHYs).  Please provide information
from ethtool.

> Above is the output of mii-tool, also the lights on the switch indicate
> 100mbit speed.   It gets 100mbit on a 1000baset switch too, so it's not a
> switch issue.
> 
> [66653.451043] cdc_ncm 2-1.2:2.0 enx00e04c680225: renamed from eth0
> [66656.811499] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66657.067647] IPv6: ADDRCONF(NETDEV_CHANGE): enx00e04c680225: link becomes 
> ready
> [66657.323360] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66657.835395] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66658.347355] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66658.859227] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66659.371242] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> [66659.883190] cdc_ncm 2-1.2:2.0 enx00e04c680225: 2500 mbit/s downlink 2500 
> mbit/s uplink
> 
> Above is the dmesg output from a LicheePi4A running the
> 5.10.113-g387b6863253c-dirty kernel it ships with, when it does this the
> switch LEDs indicate that it's 2500 speed.  This indicates that it's not
> a problem with the hardware in the USB device but a problem with the kernel.
> 
> # ethtool usb2.5g
> Settings for usb2.5g:
>   Supported ports: [  ]
>   Supported link modes:   Not reported

!!

>   Supported pause frame use: No
>   Supports auto-negotiation: No
>   Supported FEC modes: Not reported
>   Advertised link modes:  Not reported
>   Advertised pause frame use: No
>   Advertised auto-negotiation: No
>   Advertised FEC modes: Not reported
>   Speed: 1000Mb/s
>   Duplex: Half
>   Auto-negotiation: off

!!

>   Port: Twisted Pair
>   PHYAD: 0
>   Transceiver: internal
>   MDI-X: Unknown
> Current message level: 0x0007 (7)
>drv probe link
>   Link detected: yes
> 
> Above is the output of running ethtool on a Debian/Stable system running
> kernel 6.1.0-13-amd64.

Is this using the cdc-ncm or r8152 driver?

> Half duplex is a problem, but less of a problem than
> 100baseT.  This is a regression from Debian/Stable.

The above also looks very broken, so I would hesitate to say that this
has regressed as opposed to showing different symptoms.

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program
than vice versa.



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

Bug#1063826: python3-binwalk: core/magic.py:431: SyntaxWarning: invalid escape sequence '\.'

[Paul Wise]

Package: python3-binwalk
Version: 2.3.4+dfsg1-3
Severity: minor
Usertags: warnings
User: debian-pyt...@lists.debian.org
Usertags: python3.12

I got a Python SyntaxWarning when upgrading python3-binwalk:

   Selecting previously unselected package python3-zombie-imp.
   Preparing to unpack .../python3-zombie-imp_0.0.2-2_all.deb ...
   Unpacking python3-zombie-imp (0.0.2-2) ...
   Preparing to unpack .../python3-binwalk_2.3.4+dfsg1-3_all.deb ...
   Unpacking python3-binwalk (2.3.4+dfsg1-3) over (2.3.4+dfsg1-1) ...
   Preparing to unpack .../binwalk_2.3.4+dfsg1-3_all.deb ...
   Unpacking binwalk (2.3.4+dfsg1-3) over (2.3.4+dfsg1-1) ...
   Setting up python3-zombie-imp (0.0.2-2) ...
   Setting up python3-binwalk (2.3.4+dfsg1-3) ...
   /usr/lib/python3/dist-packages/binwalk/core/magic.py:431: SyntaxWarning: 
invalid escape sequence '\.'
 self.period = re.compile("\.")
   Setting up binwalk (2.3.4+dfsg1-3) ...
   Processing triggers for man-db (2.12.0-3) ...

Probably this was caused by the Python 3.12 transitions.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python3-binwalk depends on:
ii  libmagic1   1:5.45-2+b1
ii  python3 3.11.6-1
ii  python3-zombie-imp  0.0.2-2

Versions of packages python3-binwalk recommends:
ii  7zip [p7zip-full]  23.01+dfsg-8
pn  arj
ii  bzip2  1.0.8-5+b2
pn  cramfsswap 
pn  mtd-utils  
pn  ncompress  
pn  p7zip  
pn  python3-pyqtgraph  
ii  sleuthkit  4.12.1+dfsg-1
ii  squashfs-tools 1:4.6.1-1

python3-binwalk suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1063825: ognibuild: crashes when building hexchat due to parsing meson stderr as JSON

[Paul Wise]

Package: ognibuild
Version: 0.0.18+git20230208.1.9b890a2-1
Severity: normal
Usertags: crash

With hexchat, `ogni build` crashes because meson prints a warning
to stderr and that gets parsed as JSON by ognibuild/buildsystem.py.

https://github.com/hexchat/hexchat/

Probably the right fix would be to not parse meson stderror as JSON
and instead direct stderr to the terminal ogni is running on.

   hexchat (master =) $ ogni build
   Preparing directory .
   Using requirement resolver: [cpan, ctan, pypi, npm, go, hackage, cran, 
bioconductor, octave-forge]
   Detected buildsystems: meson
   Checking that declared requirements are present
   Running ['meson', 'introspect', '--scan-dependencies', './meson.build']
   Trying to enter misc which has already been visited --> Skipping
   [{"name": "gio-2.0", "required": true, "version": [">= 2.36.0"], 
"has_fallback": false, "conditional": false}, {"name": "gmodule-2.0", 
"required": true, "version": [], "has_fallback": false, "conditional": false}, 
{"name": "libcanberra", "required": true, "version": [">= 0.22"], 
"has_fallback": false, "conditional": false}, {"name": "dbus-glib-1", 
"required": true, "version": [], "has_fallback": false, "conditional": false}, 
{"name": "openssl", "required": true, "version": [">= 0.9.8"], "has_fallback": 
false, "conditional": true}, {"name": "gtk+-2.0", "required": true, "version": 
[">= 2.24.0"], "has_fallback": false, "conditional": false}, {"name": "x11", 
"required": true, "version": [], "has_fallback": false, "conditional": true}, 
{"name": "iso-codes", "required": false, "version": [], "has_fallback": false, 
"conditional": false}, {"name": "-embed", "required": false, "version": [">= 
3.3"], "has_fallback": false, "conditional": true}, {"name": "libpci", 
"required": false, "version": [], "has_fallback": false, "conditional": true}]
   Traceback (most recent call last):
 File "/usr/bin/ogni", line 33, in 
   sys.exit(load_entry_point('ognibuild==0.0.18', 'console_scripts', 
'ogni')())

 File "/usr/bin/ogni", line 25, in importlib_load_entry_point
   return next(matches).load()
  
 File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in 
load
   module = import_module(match.group('module'))

 File "/usr/lib/python3.11/importlib/__init__.py", line 126, in 
import_module
   return _bootstrap._gcd_import(name[level:], package, level)
  
 File "", line 1204, in _gcd_import
 File "", line 1176, in _find_and_load
 File "", line 1147, in _find_and_load_unlocked
 File "", line 690, in _load_unlocked
 File "", line 940, in exec_module
 File "", line 241, in 
_call_with_frames_removed
 File "/usr/lib/python3/dist-packages/ognibuild/__main__.py", line 329, in 

   sys.exit(main())
^^
 File "/usr/lib/python3/dist-packages/ognibuild/__main__.py", line 233, in 
main
   install_necessary_declared_requirements(
 File "/usr/lib/python3/dist-packages/ognibuild/__main__.py", line 65, in 
install_necessary_declared_requirements
   buildsystem.install_declared_requirements(
 File "/usr/lib/python3/dist-packages/ognibuild/buildsystem.py", line 98, 
in install_declared_requirements
   relevant = get_necessary_declared_requirements(
  
 File "/usr/lib/python3/dist-packages/ognibuild/buildsystem.py", line 76, 
in get_necessary_declared_requirements
   for stage, req in requirements:
 File "/usr/lib/python3/dist-packages/ognibuild/buildsystem.py", line 943, 
in get_declared_dependencies
   resp = self._introspect(session, fixers, ["--scan-dependencies"])
  ^^
 File "/usr/lib/python3/dist-packages/ognibuild/buildsystem.py", line 940, 
in _introspect
   return json.loads(''.join(ret))
  
 File "/usr/lib/python3.11/json/__init__.py", line 346, in loads
   return _default_decoder.decode(s)
  ^^
 File "/usr/lib/python3.11/json/decoder.py", line 337, in decode
   obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  ^^
 File "/usr/lib/python3.11/json/decoder.py", line 355, in raw_decode
   raise JSONDecodeError("Expecting value", s, err.value) from None
   json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
   
   hexchat (master =) $ meson introspect --scan-dependencies ./meson.build > 
/dev/null 
   Trying to enter misc which has already been visited --> Skipping
   
   hexchat (master =) $ meson introspect --scan-dependencies ./meson.build 2> 
/dev/null 
   [{"name": "gio-2.0", "required": true, 

Bug#1063824: zenmap should depends on python3-gi-cairo

[Yadd]

Package: zenmap
Version: 7.94+git20230807.3be01efb1+dfsg-3
Severity: important
X-Debbugs-Cc: y...@debian.org

Hi,

when using zenmap, the "port" tab is broken unless python3-gi-cairo is
installed:

  TypeError: Couldn't find foreign struct converter for 'cairo.Context'

Cheers,
Yadd

Bug#1063800: Should we restrict libtread-pool to 64bit only

[Aaron M. Ucko]

Andreas Tille  writes:

>Build-Depends libthread-pool 4.0.0 which does not build
>for 32bit architectures[1]

I see a fix in experimental:

https://buildd.debian.org/status/package.php?p=libthread-pool=experimental

Why not just reupload it to unstable?

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#1032869: works but strange

[Stefan Kropp]

Feedback from upstream. The first and second call is because of
resolver routines. The 3. connection is the "libstrophe"
connection.

When I understood well, the reason of the bugs was a wrong IPv6
configuration. After failed IPv6 connection, libstrophe didn't
try IPv4 as fallback. Am I right?

TIL: There are some information in RFC 6724 - Default Address
Selection for Internet Protocol Version 6 (IPv6).

-- 
Stefan

Bug#1063823: bullseye-pu: package nvidia-graphics-drivers/470.223.02-2

[Andreas Beckmann]

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

[ Reason ]
While preparing the update series for bookworm I realized that I had
missed in the last OPU some changes in
src:nvidia-graphics-drivers/bullseye that were added in
src:nvidia-graphics-drivers-tesa-470/bullseye.
To avoid confusion, these packages should stay in sync.
The relevant bug here is libnvidia-fbc1 not being built on arm64, even
though the library is available in the blob nowadays.

[ Impact ]
A package missing on arm64 (but no dependency problem).

[ Tests ]
Would require nvidia hardware and driver usage.

[ Risks ]
Low. All changes are already present in src:nvidia-graphics-drivers-tesa-470

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

[ Changes ]
nvidia-graphics-drivers (470.223.02-2) bullseye; urgency=medium

  * Build libnvidia-fbc1 for arm64, too.  (Closes: #1057078)
  * bug-control: Report information about more driver components.
  * nvidia-detect: Drop support for Tesla 450 drivers (EoL).
  * *-common: Drop alternative Suggests on EoL Tesla 450 packages that have
been turned into transitional packages.

 -- Andreas Beckmann   Tue, 13 Feb 2024 03:32:54 +0100

 debian/bug-control.mk  |  4 +++-
 debian/changelog   | 19 +++
 debian/control |  7 ++-
 debian/control.in  |  7 ++-
 debian/control.md5sum  |  8 
 debian/copyright   |  2 +-
 debian/detect/nvidia-detect.in | 18 +-
 debian/nvidia.NEWS |  9 +
 debian/rules   |  2 +-
 debian/rules.defs  |  1 -
 10 files changed, 42 insertions(+), 35 deletions(-)

The other changes are cleanup after
src:nvidia-graphics-drivers-tesla-450 has been turned into transitional
packages.

[ Other info ]
This can wait for the next point release, it does not need to go
through oldstable-updates.

Andreas
diff --git a/debian/bug-control.mk b/debian/bug-control.mk
index 899a92e1..75d3e710 100644
--- a/debian/bug-control.mk
+++ b/debian/bug-control.mk
@@ -41,11 +41,13 @@ define PACKAGE_STATUS
libcuda1-any
libcuda.so.1
libnvidia-ml.so.1
-   nvidia-settings
+   nvidia-cuda-mps
+   nvidia-settings$(-variant)
nvidia-xconfig
nvidia-support
nvidia-kernel-common
nvidia-modprobe
+   nvidia-persistenced
xserver-xorg
xserver-xorg-core
xserver-xorg-legacy
diff --git a/debian/changelog b/debian/changelog
index 0687cbcb..87b5a0da 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+nvidia-graphics-drivers (470.223.02-2) bullseye; urgency=medium
+
+  * Build libnvidia-fbc1 for arm64, too.  (Closes: #1057078)
+  * bug-control: Report information about more driver components.
+  * nvidia-detect: Drop support for Tesla 450 drivers (EoL).
+  * *-common: Drop alternative Suggests on EoL Tesla 450 packages that have
+been turned into transitional packages.
+
+ -- Andreas Beckmann   Tue, 13 Feb 2024 03:32:54 +0100
+
 nvidia-graphics-drivers (470.223.02-1) bullseye; urgency=medium
 
   * New upstream long term support branch release 470.223.02 (2023-10-31).
@@ -1064,6 +1074,15 @@ nvidia-graphics-drivers (455.23.04-1) experimental; 
urgency=medium
 
  -- Andreas Beckmann   Thu, 24 Sep 2020 21:52:54 +0200
 
+nvidia-graphics-drivers (450.248.02-4) UNRELEASED; urgency=medium
+
+  * The Tesla 450 driver series has been declared as End-of-Life by
+NVIDIA. No further updates fixing security issues, critical bugs, or
+adding support for new Xorg or Linux releases will be issued.
+https://docs.nvidia.com/datacenter/tesla/drivers/
+
+ -- Andreas Beckmann   Wed, 22 Nov 2023 14:13:01 +0100
+
 nvidia-graphics-drivers (450.248.02-3) UNRELEASED; urgency=medium
 
   * Revert backport of pin_user_pages changes.
diff --git a/debian/control b/debian/control
index eb5c5396..1ac158b5 100644
--- a/debian/control
+++ b/debian/control
@@ -476,7 +476,6 @@ Depends:
 Suggests:
  libegl-${nvidia-}0 [i386 amd64 ${arch:arm64} ${arch:ppc64el}]
  | libegl-nvidia-tesla-470-0 [i386 amd64 arm64 ppc64el]
- | libegl-nvidia-tesla-450-0 [i386 amd64 arm64 ppc64el]
  | libegl-nvidia-tesla-418-0 [i386 amd64 ppc64el]
  | libegl-nvidia-legacy-390xx0 [i386 amd64 armhf],
 Description: NVIDIA binary EGL driver - common files
@@ -546,7 +545,6 @@ Depends:
 Suggests:
  ${nvidia}-vulkan-icd [i386 amd64 ${arch:arm64} ${arch:ppc64el}]
  | nvidia-tesla-470-vulkan-icd [i386 amd64 arm64 ppc64el]
- | nvidia-tesla-450-vulkan-icd [i386 amd64 arm64 ppc64el]
  | nvidia-tesla-418-vulkan-icd [i386 amd64 ppc64el]
  | nvidia-legacy-390xx-vulkan-icd [i386 amd64],
 Conflicts:
@@ -877,7 +875,7 @@ Description: NVIDIA OpenGL-based Inband Frame Readback 
runtime 

Bug#1063822: ITP: lxc-ci -- Official image definitions for distrobuilder

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-lxc-de...@lists.alioth.debian.org

* Package name: lxc-ci
  Version : 0.0~git20240210.e5f93e4-1
  Upstream Author : Linux Containers Project
* URL : https://github.com/lxc/lxc-ci
* License : Apache-2.0
  Programming Lang: yaml
  Description : Official image definitions for distrobuilder

 This package contains the official yaml definitions used by the Linux
 Containers Project to generate the pre-built images offered at
 https://images.linuxcontainers.org/.

  This will be kind of a weird package -- the source is lxc-ci, which
contains all the bits and pieces to run the Linux Containers Project's
Jenkins server. However, Debian will only be interested in the image
yaml files for use with the distrobuilder package, so the produced
binary package is distrobuilder-images. It will be team-maintained with
the pkg-lxc team.


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

Bug#979332: New upstream version

[skizzerz]

Seems the current version is causing errors due to using syntax removed in
PHP 8. I'm seeing the following error message:
TypeError: implode(): Argument #2 ($array) must be of type ?array, string
given /usr/share/php/simplepie/library/SimplePie/Parse/Date.php(544)

This was fixed upstream a while ago, so I'm bumping this bug in hopes that
the package can be updated. The dokuwiki package depends on this one and
is broken on the pages that make use of the library, causing some wiki pages
to become inaccessible after an upgrade to bookworm.

Is it possible to get this package updated to something compatible with
PHP 8? Latest upstream is now 1.8.0, released January 2023.

Bug#1063820: faketime does not fake timestamps in stat(1) or ls(1)

[Dalton Durst]

Package: faketime
X-Debbugs-Cc: deb...@daltondur.st
Version: 0.9.10-2.1+b1
Severity: normal

Dear Maintainer,

faketime and libfaketime in and after Debian 11 (bullseye) do not fake
timestamps to common commands which use the statx syscall, such as
stat(1) or ls(1). Instead, the on-disk timestamps are returned:

  # LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 
FAKETIME='1970-01-01 00:00:01' stat /
File: /
Size: 4096 Blocks: 8 IO Block: 4096 directory
  Device: 72h/114d Inode: 14475976 Links: 1
  Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
  Access: 2024-02-13 00:08:45.027068497 +
  Modify: 2024-02-13 00:08:45.027068497 +
  Change: 2024-02-13 00:09:55.450105641 +
  Birth: 2024-02-13 00:08:45.027068497 +

In Debian 10 (buster) and earlier, or in sid with faketime built from
the current git master branch, the correct result is returned (all
timestamps are returned as 1970-01-01 00:00:01.0). This seems to be
related to upstream bug https://github.com/wolfcw/libfaketime/issues/417
which was fixed by PR https://github.com/wolfcw/libfaketime/pull/434

Unfortunately, faketime hasn't had a release since that fix for statx
was merged.

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

Versions of packages faketime depends on:
ii  libc62.37-14
ii  libfaketime  0.9.10-2.1+b1

faketime recommends no packages.

faketime suggests no packages.

-- no debconf information

Bug#1063821: bullseye-pu: package python-dnslib/0.9.14-1

[Scott Kitterman]

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


[ Reason ]
Address no-dsa CVE.  CVE-2022-22846

[ Impact ]
Continued vulnerability to minor issue.

[ Tests ]
Package has tests which are run via autopkgtest and during the build.
Both pass locally with the added patch.

[ Risks ]
Risk is minimal.  Patch is from upstream and has been around for awhile
without known issues.  Change is trivial.

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

[ Changes ]
Add verify that the ID value in a DNS reply matches an ID value in a query.

[ Other info ]
I've only ever used this for running local tests to mock DNS responses,
which is not a case that's at risk for this issue, but it did occur to
me others may use it differently, so probably better to fix it.

Scott K
diff -Nru python-dnslib-0.9.14/debian/changelog 
python-dnslib-0.9.14/debian/changelog
--- python-dnslib-0.9.14/debian/changelog   2020-06-10 00:51:44.0 
-0400
+++ python-dnslib-0.9.14/debian/changelog   2024-02-12 19:43:55.0 
-0500
@@ -1,3 +1,9 @@
+python-dnslib (0.9.14-1+deb11u1) bullseye; urgency=medium
+
+  * Add d/p/0002-Validate-TXID-in-client.py.patch to address CVE-2022-22846
+
+ -- Scott Kitterman   Mon, 12 Feb 2024 19:43:55 -0500
+
 python-dnslib (0.9.14-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru 
python-dnslib-0.9.14/debian/patches/0002-Validate-TXID-in-client.py.patch 
python-dnslib-0.9.14/debian/patches/0002-Validate-TXID-in-client.py.patch
--- python-dnslib-0.9.14/debian/patches/0002-Validate-TXID-in-client.py.patch   
1969-12-31 19:00:00.0 -0500
+++ python-dnslib-0.9.14/debian/patches/0002-Validate-TXID-in-client.py.patch   
2024-02-12 19:42:50.0 -0500
@@ -0,0 +1,24 @@
+From: Scott Kitterman 
+Date: Sat, 12 Feb 2024 19:41:26 -0500
+Subject: Validate TXID in client.py
+Fixes CVE-2022-22846
+Origin: backport, 
https://github.com/paulc/dnslib/commit/76e8677699ed098387d502c57980f58da642aeba
+
+---
+ dnslib/client.py | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/dnslib/client.py b/dnslib/client.py
+index 628ea81..09572b6 100644
+--- a/dnslib/client.py
 b/dnslib/client.py
+@@ -76,6 +76,9 @@ if __name__ == '__main__':
+ a_pkt = q.send(address,port,tcp=args.tcp)
+ a = DNSRecord.parse(a_pkt)
+ 
++if q.header.id != a.header.id:
++raise DNSError('Response transaction id does not match query 
transaction id')
++
+ if a.header.tc and args.noretry == False:
+ # Truncated - retry in TCP mode
+ a_pkt = q.send(address,port,tcp=True)
diff -Nru python-dnslib-0.9.14/debian/patches/series 
python-dnslib-0.9.14/debian/patches/series
--- python-dnslib-0.9.14/debian/patches/series  2020-06-10 00:50:31.0 
-0400
+++ python-dnslib-0.9.14/debian/patches/series  2024-02-12 19:43:55.0 
-0500
@@ -1 +1,2 @@
 0001-Only-run-tests-for-python3.patch
+0002-Validate-TXID-in-client.py.patch

Bug#1063558: pgpainless 1.6.6 is available

[tony mancill]

On Fri, Feb 09, 2024 at 10:19:59AM -0500, Daniel Kahn Gillmor wrote:
> Package: src:pgpainless
> Version: 1.6.5-1
> Severity: wishlist
> 
> pgpainless 1.6.6 is available upstream.  it would be great to have it in
> debian.

Hi,

I pulled the new version and prepared the update, but I'm not seeing
anything that would affect Debian users of this package (because we
only have logback 1.2.x anyway):


diff -Nru pgpainless-1.6.5/CHANGELOG.md pgpainless-1.6.6/CHANGELOG.md
--- pgpainless-1.6.5/CHANGELOG.md   2023-12-15 08:35:50.0 -0800
+++ pgpainless-1.6.6/CHANGELOG.md   2024-02-02 13:06:11.0 -0800
@@ -5,6 +5,9 @@
 
 # PGPainless Changelog
 
+## 1.6.6
+- Downgrade `logback-core` and `logback-classic` to `1.2.13` to fix #426
+
 ## 1.6.5
 - Add `SecretKeyRingEditor.setExpirationDateOfSubkey()`
 

However, since the packaging update is done, I will go ahead and upload
soonish.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Diederik de Haas]

On Monday, 12 February 2024 21:25:35 CET Mario Limonciello wrote:
> > My logic was that this is about AMD TEE (Trusted Execution Environment),
> > which I *assumed* is part of/tied to the CPU. This thought is based on
> > that on ARM platforms, you also have a TEE and that is part of the CPU
> > (and implemented in TF-A IIUC). I can be wrong here ofc.
> 
> To me using the nomenclature of "CPU" is confusing.  We should be
> calling these SoCs.

While SoC may be technically more accurate, I'm not in favor of using it in 
this context as it doesn't give any hint on what it does.

I'd use CPU for general processing and GPU for graphics processing.

> Notably AMD APUs have X86 cores, IPU/NPU cores, GPU cores, ASP (formerly
> called PSP) and various others.

I would describe an APU as a CPU with integrated GPU.
My guess is most people/end-users aren't even aware of the ASP/PSP.

I would classify the various ASICs (like IPU/NPU) as part of the CPU, but it 
is (by definition?) an arbitrary qualification/separation.

> > There's no need to pick an existing binary package. I could add it to amd-
> > graphics, but I consider that a poor choice. I could create a new binary
> > package `amdtee` in firmware-nonfree (source package).
> > That would be fine afaic.
> > 
> > So I have no strong feelings about it, just trying to find the best place
> > for the `amdtee` dir.
> 
> My general feeling is that having separated binary packages for all the
> AMD 'things' makes things "generally" confusing for end users and is
> needless extra work for you to maintain.

I mostly agree. It isn't (much) extra work for 'me' though.

> 'amdtee' is the one thing right now, but soon (TM) the IPU/NPU binaries
> will go to linux-firmware.git and then where do those go?

My (current) thinking is to have 2 categories:
- AMD CPU related
- AMD GPU/graphics related

> Current products only put the IPU/NPU in APU chips, but who is to stay;
> those might end up in SoCs without graphics in the future too.

I think it's important to facilitate people having f.e. the following combos:
- Intel CPU with AMD GPU
- AMD CPU with Nvidia GPU
- AMD CPU with AMD GPU (discrete or integrated)

Preferably without having to install 100s of MB of firmware files of which 95% 
the user doesn't actually need. (See f.e. https://bugs.debian.org/1057786)

> How would you feel about making a master "amd" metapackage that pulls
> them all?  You can split as you see fit then and people who want the
> 'easy button' can just install that package.

I'm not much of a fan of such metapackages. I think it mostly indicates that 
the purpose of the various packages isn't clear, so let's install all of them.
Clarifying the purpose better is a better solution imo.
I'm aware others feel different: https://bugs.debian.org/522415

I prefer to keep that discussion out of this bug though, feel free to open a 
new bug for that if you do want it.

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

Bug#1063457: [Pkg-zfsonlinux-devel] Bug#1063457: nordugrid-arc and arcstat

[Petter Reinholdtsen]

[Helmut Grohne]
> While you may move arcstat back to sbin, doing so does not address or
> fix this bug. The arcstat command is still being provided (albeit in a
> different place) and hence policy is still being violated.

Am I understanding you correctly that you mean it violate the "Two
different packages must not install programs with different
functionality but with the same filenames" statement of policy 10.1?  It
is not obvious to me that this applies to two packages, one with
/usr/bin/arcstat and another with /usr/sbin/arcstat.  What make you sure
it violate policy?

In any case, I guess one way to avoid two binaries in $PATH with the
same name is to move one of them out of $PATH, for example by moving the
zfs binary to /usr/lib/zfs/arcstat.  Another way would be to rename it
to /usr/bin/zfs-arcstat.  Both approaches would make the Debian location
incompatible with ZFS on other platforms.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1063819: dh-sysuser: uses deprecated given/when

[Lorenzo Puliti]

Package: dh-sysuser
Version: 1.3.10+really1.4.4
Severity: normal
Tags: patch
X-Debbugs-Cc: Niko Tyni , plore...@disroot.org

Building runit package I have

   create-stamp debian/debhelper-build-stamp
   dh_testroot -O--sourcedirectory=runit-2.1.2/src
   dh_prep -O--sourcedirectory=runit-2.1.2/src
   dh_installdirs -O--sourcedirectory=runit-2.1.2/src
   dh_auto_install -O--sourcedirectory=runit-2.1.2/src
   dh_sysuser -O--sourcedirectory=runit-2.1.2/src
given is deprecated at /usr/bin/dh_sysuser line 37.
when is deprecated at /usr/bin/dh_sysuser line 38.
when is deprecated at /usr/bin/dh_sysuser line 39.
when is deprecated at /usr/bin/dh_sysuser line 46.
   dh_install -O--sourcedirectory=runit-2.1.2/src
   dh_installdocs -O--sourcedirectory=runit-2.1.2/src
   dh_buildinfo -O--sourcedirectory=runit-2.1.2/src

so I guess it needs an update like in dh-runit's  #1060709
What I'm not sure is if this need to be fixed in unstable as
possible or it can wait longer. The autopkgtest covers only
sysuser-helper, so the package does not fail to build.
Patch at the bottom.

Dear Niko, please bump the severity if this is urgent.

Regards,
Lorenzo


diff --git a/dh_sysuser b/dh_sysuser
index 74195f9..fbe9c30 100755
--- a/dh_sysuser
+++ b/dh_sysuser
@@ -34,17 +34,17 @@ init();
 
 sub parse_options($conf, $options, $user) {
 foreach my $opt (split(/,/, $options)) {
-given ($opt) {
-when (/^home=(.*)$/)  { $conf->{home} = $1; }
-when (/^home$/)   {
+for ($opt) {
+if (/^home=(.*)$/)  { $conf->{home} = $1; }
+elsif (/^home$/)   {
 my $normal = $user;
 $normal =~ s/^_+//; # strip leading
 $normal =~ s/_+$//; # and trailing underscore
 $normal =~ s/^[Dd]ebian-//; # and discouraged debian- prefix
 $conf->{home} = "/var/lib/$normal";
 }
-when (/^defaults$/)   { "do nothing"; }
-default   { error("unknown option `$opt'"); }
+elsif (/^defaults$/)   { "do nothing"; }
+else   { error("unknown option `$opt'"); }
 }
 }
 }



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

Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages dh-sysuser depends on:
ii  perl  5.38.2-3

dh-sysuser recommends no packages.

dh-sysuser suggests no packages.

-- no debconf information

Bug#1063675: nvidia-graphics-drivers 525.147.05-6~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

On Mon, Feb 12, 2024 at 08:07:36PM +0100, Patrick ZAJDA wrote:
> 
> 
> Le 12/02/2024 à 18:56, Jonathan Wiltshire a écrit :
> > package release.debian.org
> > tags 1063675 = 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: nvidia-graphics-drivers
> > Version: 525.147.05-6~deb12u1
> > 
> > Explanation: restore compatibility with newer Linux kernel builds; take 
> > over packages from nvidia-graphics-drivers-tesla; add new 
> > nvidia-suspend-common package
> > 
> So the update won't be available in bookworm-update and we must add
> proposed-update to our sources to be able to update to latest kernel?
> Or do I miss something?

It will be released in bookworm at the next point release, and all being
well earlier than that via bookworm-updates.

Testing of the packages through proposed-updates before then is
appreciated, as always.

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

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

Bug#1063818: marisa: autopkg tests are run from the source package, not the installed package

[Boyuan Yang]

Source: marisa
Version: 0.2.6-14
Severity: important

Originally reported by Matthias Klose at https://bugs.debian.org/1061809#10 :

> At least the python3 autopkg test is run from the source package, not 
> from the installed package, not using the regenerated bindings by swig.
> The two before/after autoconf targets are not run for the autopkg tests, 
> the package is only unpacked, and the old marisa.py is used.
> Patch for the python3 autopkg test at
> http://launchpadlibrarian.net/713482090/marisa_0.2.6-14build3_0.2.6-14ubuntu1.diff.gz
> however the very same should probably be done with the tests for the 
> other bindings.

Thanks,
Boyuan Yang


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

Bug#1063817: debconf-copydb pipe writes to GLOB file instead of stdout

[Dan Bungert]

Package: debconf
Version: 1.5.85
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

While debugging a FTBFS in Ubiquity, I observed that the usage of
debconf-copydb regressed when using version 1.5.85 of debconf. The
previous-in-Ubuntu version 1.5.82 of debconf was OK.

That invocation looks roughly like:
debconf-copydb templatedb pipe --config=Name:pipe --config=Driver:Pipe
--config=InFd:none ...

Bisecting debconf from there found commit
5db857ade00953496bfdb7edb884296bebc41885:
"Avoid two-argument open"

Further tracing found the following change to Debconf/DbDriver/Pipe.pm
around line 120:
- open ($fh, '>-');
+ open ($fh, '>', \*STDOUT);

An additional symptom of this problem is GLOB files are created in CWD
with names that look like:
GLOB(0x0123456789ab)

Pointing the above to above to configdb on a fairly stock Debian Sid
installation produces an equivalent result - GLOB file creation
instead of the output.

Is the 3-argument form this?
open ($fh, '>&', \*STDOUT);

Originally filed as LP: #2052982.

-Dan

Bug#1063816: python-easydev: Please package new release 0.13.0 (and migrate away from appdirs)

[Boyuan Yang]

Source: python-easydev
Version: 0.12.1+dfsg-1
Severity: important
Control: block 1060427 by -1
X-Debbugs-CC: osal...@debian.org

Dear Debian python-easydev maintainer,

Your package (build-)depends on python3-appdirs, which is dead upstream
and will not be released with Debian Trixie. The new upstream release has
migrated away from appdirs and thus should be packaged.

Thanks,
Boyuan Yang


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

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Martin Steigerwald]

Hi!

This breaks compiling my own kernel with:

time eatmydata make -j16 bindeb-pkg LOCALVERSION=-t14

Likely going to downgrade and pin kmod to a working version as I am 
seriously fed up with usr-merge related bugs. (Yeah, it is called unstable 
for a reason and if I use it unstable is what I may get. But I really 
don't see how any possible benefit justifies that immense and error-prone 
effort. Anyway it is not me doing that work.)

Best,
-- 
Martin

Bug#1063815: ITP: vapid -- Simple VAPID header generation library

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

Package Name: vapid / python3-py-vapid
Version: 1.8.2
Upstream Author: JR Conlin 
License: MPL2
Programming Lang: Python 3
Homepage: https://github.com/web-push-libs/vapid

Description: Simple VAPID header generation library
 This minimal library contains the minimal set of functions you need to
 generate a VAPID key set and get the headers you'll need to sign a
 WebPush subscription update.

Bug#1063814: ITP: encrypted-content-encoding -- Encrypted Content-Encoding for HTTP

[Martin]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

Package Name: encrypted-content-encoding / python3-http-ece
Version: v1.2.0
Upstream Author: Martin Thomson 
License: MIT
Programming Lang: Python 3
Homepage: https://github.com/web-push-libs/encrypted-content-encoding

Description: Encrypted Content-Encoding for HTTP
 This library implements HTTP ECE in accordance with RFC 8188.
 It is needed e.g. for WebPush.

Bug#1063813: ITP: pywebpush -- Webpush Data publication library

[From]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

Package Name: pywebpush 
Version: 1.14.0
Upstream Author: JR Conlin 
License: MPL2
Programming Lang: Python 3
Homepage: https://github.com/web-push-libs/pywebpush

Description: WebPush Data publication library
 This library implements WebPush in Python.

Depends on python3-http-ece and python3-py-vapid.

Bug#1063812: btrfsd: Do not scrub all mount points that belong to the same file system

[Vincent Blut]

Package: btrfsd
Version: 0.2.1-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

btrfsd runs 'btrfs scrub' on all mount points even if those are part of
a unique filesystem. This is suboptimal since that will not just scrub
those mount points but the entire filesystem where they reside.

So, let's say I have three subvolumes mounted on a single filesystem, scrub will
thus pass over the filesystem three times in a row. While not dramatic, it's
certainly a waste of ressources.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZcqe8QAKCRAQn1qAt/bg
AXY+AP4n0+y1Rxrtva1yEOc7EK1ER56zKzkK0O+y3KSf7t4QMQD+JWIKf3pESV6s
rwpqHOqK+07PqojDMkaMgX7ZSPRJrAQ=
=hB6t
-END PGP SIGNATURE-

Bug#1063811: android-framework-23: transition from p7zip to 7zip

[cacin]

Source: android-framework-23
Version: 6.0.1+r72-6
Severity: normal

Dear Maintainer,

your package Build-Depends/Depends/Recommends/Suggests or has some other 
relation to the p7zip/p7zip-full/p7zip-rar packages, which have become 
transitional packages in debian trixie and will eventually be removed from 
debian. They have been replaced by 7zip and 7zip-rar packages.

If necessary, please modify your package to use the executables from the 7zip 
package instead. If everything everything behaves as expected, then remove 
p7zip/p7zip-full/p7zip-rar from the control file and replace it with 7zip 
and/or 7zip-rar.

This bug is currently filed with normal priority but the priority will be 
increased as the release date of debian trixie gets closer.

Thank you for maintaining software in debian.

Bug#1061816: Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + pending

Hi Francesco


Quoting Francesco Poli (2024-02-12 22:46:29)
> On Mon, 29 Jan 2024 21:07:52 +0100 Francesco Poli wrote:
> > Yes, I think it makes sense to have a separate bug report, so that I
> > can be easily notified, once it becomes pending and once it gets closed.
> > 
> > Thanks!
> I see that [MR 54] has been merged.
> 
> [MR 54]: 

yes, thanks to the work of Christian (in CC).

> Is there anything else that needs to be fixed/enhanced in sbuild-qemu,
> in order for sbuild-qemu-update to be able to update
> mmdebstrap-autopkgtest-build-qemu VM images?

Theoretically not. If you want to make sure, feel free to clone the git and try
it out.

> If not, I think this bug report (#1061816) should be marked as pending.

Done.

> And probably mentioned in some debian/changelog entry. Or in some
> commit message, if you generate debian/changelog from commit messages...

Christian is probably going to do this on the next upload.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1063810: libio-compress-lzma-perl: transition from p7zip to 7zip

[cacin]

Source: libio-compress-lzma-perl
Version: 2.206-1
Severity: normal

Dear Maintainer,

your package Build-Depends/Depends/Recommends/Suggests or has some other 
relation to the p7zip/p7zip-full/p7zip-rar packages, which have become 
transitional packages in debian trixie and will eventually be removed from 
debian. They have been replaced by 7zip and 7zip-rar packages.

If necessary, please modify your package to use the executables from the 7zip 
package instead. If everything everything behaves as expected, then remove 
p7zip/p7zip-full/p7zip-rar from the control file and replace it with 7zip 
and/or 7zip-rar.

This bug is currently filed with normal priority but the priority will be 
increased as the release date of debian trixie gets closer.

Thank you for maintaining software in debian.

Bug#1063809: nexuiz-data: transition from p7zip to 7zip

[cacin]

Source: nexuiz-data
Version: 2.5.2-12
Severity: normal

Dear Maintainer,

your package Build-Depends/Depends/Recommends/Suggests or has some other 
relation to the p7zip/p7zip-full/p7zip-rar packages, which have become 
transitional packages in debian trixie and will eventually be removed from 
debian. They have been replaced by 7zip and 7zip-rar packages.

If necessary, please modify your package to use the executables from the 7zip 
package instead. If everything everything behaves as expected, then remove 
p7zip/p7zip-full/p7zip-rar from the control file and replace it with 7zip 
and/or 7zip-rar.

This bug is currently filed with normal priority but the priority will be 
increased as the release date of debian trixie gets closer.

Thank you for maintaining software in debian.

Bug#877016: Time to drop cpufrequtils?

[Pkreuzt]

Cpupower (linux-cpupower package) is the natural replacement for cpufrequtils 
and it seems capable of autoloading governors alone. I think all we need is a 
systemd service and a sample config file for it, as provided by cpufrequtils.

See my own wish report on it:

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

Also see the way Arch does this:

https://gitlab.archlinux.org/archlinux/packaging/packages/linux-tools

Bug#1063808: simple-scan: Unable to load items from the cursor theme adwaita-icon-theme

[Jean-Marc]

Package: simple-scan
Version: 44.0-1
Severity: normal
X-Debbugs-Cc: jean-m...@6jf.be

Dear Maintainer,

Since adwaita-icon-theme upgraded to 46~beta-1, I get issues when cropping a 
scanned document.

The mouse cursor does not change when trying to grap the crop-region-selector 
to resize it.


Logs from simple-scan:
$ LANG=C simple-scan
Gdk-Message: 17:42:28.355: Unable to load bottom_side from the cursor theme
Gdk-Message: 17:42:28.370: Unable to load hand1 from the cursor theme
Gdk-Message: 17:42:28.969: Unable to load bottom_side from the cursor theme
Gdk-Message: 17:42:29.021: Unable to load arrow from the cursor theme
Gdk-Message: 17:42:29.224: Unable to load bottom_left_corner from the cursor 
theme
Gdk-Message: 17:42:29.593: Unable to load left_side from the cursor theme
Gdk-Message: 17:42:29.719: Unable to load bottom_left_corner from the cursor 
theme
Gdk-Message: 17:42:30.253: Unable to load bottom_side from the cursor theme
Gdk-Message: 17:42:30.271: Unable to load hand1 from the cursor theme
Gdk-Message: 17:42:35.285: Unable to load bottom_side from the cursor theme
Gdk-Message: 17:42:35.398: Unable to load arrow from the cursor theme
Gdk-Message: 17:42:36.161: Unable to load bottom_side from the cursor theme
Gdk-Message: 17:42:36.507: Unable to load bottom_right_corner from the cursor 
theme
Gdk-Message: 17:42:42.130: Unable to load arrow from the cursor theme
Gdk-Message: 17:43:51.187: Unable to load hand1 from the cursor theme
Gdk-Message: 17:43:51.283: Unable to load top_side from the cursor theme
Gdk-Message: 17:43:51.312: Unable to load arrow from the cursor theme

Regards,

Jean-Marc


-- Package-specific info:

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

Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT)
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)
LSM: AppArmor: enabled

Versions of packages simple-scan depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-4
ii  dbus-x11 [dbus-session-bus]   1.14.10-4
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4+b1
ii  libc6 2.37-15
ii  libcairo2 1.18.0-1+b1
ii  libcolord21.4.6-5
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3+b1
ii  libglib2.0-0  2.78.3-2
ii  libgtk-3-03.24.41-1
ii  libgusb2  0.4.8-1
ii  libhandy-1-0  1.8.3-1
ii  libpackagekit-glib2-181.2.8-1+b1
ii  libsane1  1.2.1-7+b1
ii  libwebp7  1.3.2-0.3
ii  libwebpmux3   1.3.2-0.3
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.3.dfsg-3+b1

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Bastian Blank]

Control: reassign -1 kmod

On Mon, Feb 12, 2024 at 10:37:46PM +0100, Marco d'Itri wrote:
> On Feb 12, Salvatore Bonaccorso  wrote:
> > --with-module-directory=/usr/lib/modules
> I can revert it if it causes too much trouble, but maybe this is just 
> the right time to switch the kernel packages to /usr/lib/modules/ as well?

We can't change this on our own.  The usage of $BASE/lib/modules is
baked in pretty deep into the kernel build.

| MODLIB  = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
and
| depmod -b "$INSTALL_MOD_PATH"

depmod need to learn to work with MODLIB to even be able to change this
value.

The main linux build does not break, because we skip depmod during
build.  But any other, including manual linux builds, will break.

Bastian

-- 
Only a fool fights in a burning house.
-- Kank the Klingon, "Day of the Dove", stardate unknown

Bug#1063807: rpm: transition from p7zip to 7zip

[cacin]

Source: rpm
Version: 4.18.2+dfsg-1
Severity: normal

Dear Maintainer,

your package Build-Depends/Depends/Recommends/Suggests or has some other 
relation to the p7zip/p7zip-full/p7zip-rar packages, which have become 
transitional packages in debian trixie and will eventually be removed from 
debian. They have been replaced by 7zip and 7zip-rar packages.

If necessary, please modify your package to use the executables from the 7zip 
package instead. If everything everything behaves as expected, then remove 
p7zip/p7zip-full/p7zip-rar from the control file and replace it with 7zip 
and/or 7zip-rar.

This bug is currently filed with normal priority but the priority will be 
increased as the release date of debian trixie gets closer.

Thank you for maintaining software in debian.

Bug#1063457: nordugrid-arc and arcstat

[Helmut Grohne]

On Mon, Feb 12, 2024 at 04:08:40PM +, 陈 晟祺 wrote:
> As a (tentative) solution, we discussed and decided to move arcstat back to
> sbin on the zfs-linux side. That would leave the current situation untouched
> until maintainers from both sides form a consensus on how to handle this.

While you may move arcstat back to sbin, doing so does not address or
fix this bug. The arcstat command is still being provided (albeit in a
different place) and hence policy is still being violated.

If you want to migrate a zfs-linux upload to testing, you may adjust the
found version to clarify that it already affects trixie and also
periodically update this bug to prevent the autoremover from taking
action.

> We will keep working on this and try to ask for more advice from both users
> and developers.

Yes, please.

Helmut

Bug#1063692: uruk: move files to /usr (DEP17)

[Helmut Grohne]

Hi Joost,

On Sun, Feb 11, 2024 at 10:19:50AM +0100, Joost van Baal-Ilić wrote:
> Thanks a lot for this beautiful patch.  Do you intend to take care of 
> uploading
> it to unstable too?  If not, I'm happy to do that of course.

Thanks for the quick reply. I prefer you uploading it as you know your
git workflow best. Let me know if you want me to NMU it. Realistically,
we need this done by September 2024 to finish the transition in time.

Helmut

Bug#1063457: nordugrid-arc and arcstat

[Helmut Grohne]

On Mon, Feb 12, 2024 at 09:13:50AM +0100, Mattias Ellert wrote:
> NorduGrid ARC has used the name arcstat since release 1.0. It has been
> in Debian since January 2010 (source package nordugrid-arc-nox, later
> renamed nordugrid-arc in May 2011).
> 
> The command is part of a set of commands, all using the arc prefix:
> arccat arcget arckillarcproxy   arcresume  arcsync
> arcclean   arcls  arcrename  arcrm  arctest
> arccp  arched arcmkdir   arcrenew   arcstat
> arcctl arcinfoarcplugin  arcresub   arcsub 

Thank you for providing background. Given that zfs-linux was first
uploaded to Debian in 2016, it seems quite clear to me that the command
reasonably belongs to nordugrid. Do we all agree to reassign the bug
back to zfs-linux and have it release the name? If not, please discuss
with debian-de...@lists.debian.org.

Given that this issue is quite old and that forky is still quite in
progress, I don't see any reason to rush any action right now. Having a
civilized discussion and consensus on a long-term solution should be
focus from my point of view.

Helmut

Bug#1062932: Stable 12.5 still broken

[Roberto Fasciolo]

Hello,

Thanks for fixing the issue. However the fixed version is currently 
available only in sid and the version from sid doesn't install on 
bookworm due to requirement on dkms (>= 3.0.11 while bookworm 
3.0.10-8+deb12u1).


Are there any plans to port the fixed version to bookworm? In years of 
using Debian I've never seen the stable distribution be broken like this 
and it would be a shame if it wouldn't be fixed very quickly.


Br,
-Roberto

Bug#1063806: clutter-imcontext FTCBFS: fails running gtk-doc scanner

[Helmut Grohne]

Source: clutter-imcontext
Version: 0.1.4-3.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

clutter-imcontext fails to cross build from source, because it fails
running the gtk-doc scanner with an Exec format error. It already has
its documentation split out to an Arch:all package, so running the
scanner does not bring any benefit in an arch-only build. Hence, I
propose fixing this cross build failure by disabling gtk-doc in
arch-only builds. I'm attaching a patch for your convenience. I verified
that the arch-only and indep-only .debs match those produced by a full
build that enables gtk-doc via reproducible builds.

Helmut
diff --minimal -Nru clutter-imcontext-0.1.4/debian/changelog 
clutter-imcontext-0.1.4/debian/changelog
--- clutter-imcontext-0.1.4/debian/changelog2020-12-25 18:19:08.0 
+0100
+++ clutter-imcontext-0.1.4/debian/changelog2024-02-11 14:11:48.0 
+0100
@@ -1,3 +1,10 @@
+clutter-imcontext (0.1.4-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Disable gtk-doc in arch-only builds. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 11 Feb 2024 14:11:48 +0100
+
 clutter-imcontext (0.1.4-3.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff --minimal -Nru clutter-imcontext-0.1.4/debian/rules 
clutter-imcontext-0.1.4/debian/rules
--- clutter-imcontext-0.1.4/debian/rules2012-06-27 17:47:50.0 
+0200
+++ clutter-imcontext-0.1.4/debian/rules2024-02-11 14:11:48.0 
+0100
@@ -4,7 +4,12 @@
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/utils.mk
 
-DEB_CONFIGURE_EXTRA_FLAGS := --enable-gtk-doc 
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
+build-arch binary-arch: DEB_BUILD_TYPE+=arch
+build-indep binary-indep: DEB_BUILD_TYPE+=indep
+build binary: DEB_BUILD_TYPE+=both
+
+DEB_CONFIGURE_EXTRA_FLAGS = --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
+   --$(if $(filter indep both,$(DEB_BUILD_TYPE)),en,dis)able-gtk-doc
 DEB_CONFIGURE_SCRIPT := ./autogen.sh
 
 clutter-scan-immodules.1: debian/clutter-scan-immodules.sgml

Bug#1063805: spring: transition from p7zip to 7zip

[cacin]

Source: spring
Version: 106.0+dfsg-3
Severity: normal

Dear Maintainer,

your package Build-Depends/Depends/Recommends/Suggests or has some other 
relation to the p7zip/p7zip-full/p7zip-rar packages, which have become 
transitional packages in debian trixie and will eventually be removed from 
debian. They have been replaced by 7zip and 7zip-rar packages.

If necessary, please modify your package to use the executables from the 7zip 
package instead. If everything everything behaves as expected, then remove 
p7zip/p7zip-full/p7zip-rar from the control file and replace it with 7zip 
and/or 7zip-rar.

This bug is currently filed with normal priority but the priority will be 
increased as the release date of debian trixie gets closer.

Thank you for maintaining software in debian.

Bug#1061816: Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli]

On Mon, 29 Jan 2024 21:07:52 +0100 Francesco Poli wrote:

[...]
> Yes, I think it makes sense to have a separate bug report, so that I
> can be easily notified, once it becomes pending and once it gets closed.
> 
> Thanks!

Hello!
I see that [MR 54] has been merged.

[MR 54]: 

Is there anything else that needs to be fixed/enhanced in sbuild-qemu,
in order for sbuild-qemu-update to be able to update
mmdebstrap-autopkgtest-build-qemu VM images?

If not, I think this bug report (#1061816) should be marked as pending.
And probably mentioned in some debian/changelog entry. Or in some
commit message, if you generate debian/changelog from commit messages...

Please let me know, thanks for your time!


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


pgpzCEW0fkUtn.pgp
Description: PGP signature

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Bastian Blank]

On Mon, Feb 12, 2024 at 10:26:07PM +0100, Salvatore Bonaccorso wrote:
> On Mon, Feb 12, 2024 at 10:16:21PM +0100, Bastian Blank wrote:
> > On Mon, Feb 12, 2024 at 10:09:41PM +0100, Salvatore Bonaccorso wrote:
> > > kernel-wedge copy-modules 6.6.15 amd64 6.6.15-amd64
> > > depmod: ERROR: could not open directory 
> > > /<>/debian/linux-image-6.6.15-amd64/usr/lib/modules/6.6.15-amd64:
> > >  No such file or directory
> > I would say depmod changed the API from /lib/modules to
> > /usr/lib/modules.  Re-assign?
> A right, the last upload of kmod changed to use:
> --with-module-directory=/usr/lib/modules

The problem is, this now ties linux, kernel-wedge and kmod together.
And with backports and the implicit nature of dh_movetousr, this is not
a good idea right now.

So we need to
- make /usr usage explicit (in linux-signed-* it is still completely
  disabled, because of this implicit usage)
- teach kernel-wedge to not assume

Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Marco d'Itri]

On Feb 12, Salvatore Bonaccorso  wrote:

> --with-module-directory=/usr/lib/modules
> 
> Looping in Marco for comments.
I can revert it if it causes too much trouble, but maybe this is just 
the right time to switch the kernel packages to /usr/lib/modules/ as well?
Please let me know if I am missing anything...

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1063770: transition: mupdf

[Victor Westerhuis]

On 12/02/2024 15:30, Kan-Ru Chen (陳侃如) wrote:

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: mu...@packages.debian.org, pymu...@packages.debian.org, 
sio...@packages.debian.org, ippsam...@packages.debian.org
Control: affects -1 + src:mupdf
User: release.debian@packages.debian.org
Usertags: transition

Hi Release Team,

This is a somewhat unusual transition request. The libmupdf-dev package
used to only ship static library archives due to upstream preference.
Recently upstream started to provide makefiles for building shared library
so I think it's time to ship shared library in Debian.
I'm glad upstream has started providing support for shared libraries, 
especially with the library size of libmupdf.


I've uploaded the new version to experimental (binary package libmupdf23.10)
and tried to build the affected reverse build-deps (Cc'ed).

ippsample - doesn't seem to use mupdf at all
pymupdf - requires some changes. Likely also needs to update to new upstream 
version.
sioyek - requires some changes to drop extra linker flags.
I have prepared an updated version of sioyek at 
https://salsa.debian.org/viccie30/sioyek/-/tree/debian/experimental that 
builds and runs with the version of mupdf in experimental. Once the 
transition starts and the updated libmupdf-dev is uploaded to unstable, 
I will double-check the version of the mupdf dependency and upload the 
new version of sioyek.


Ben file:

title = "mupdf";
is_affected = .build-depends ~ "libmupdf-dev";
is_good = .depends ~ "libmupdf23.10";
is_bad = ! .depends ~ "libmupdf23.10";



--
Vriendelijke groet, Kind regards,

Victor Westerhuis

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Salvatore Bonaccorso]

Hi Bastian,

On Mon, Feb 12, 2024 at 10:16:21PM +0100, Bastian Blank wrote:
> On Mon, Feb 12, 2024 at 10:09:41PM +0100, Salvatore Bonaccorso wrote:
> > kernel-wedge copy-modules 6.6.15 amd64 6.6.15-amd64
> > depmod: ERROR: could not open directory 
> > /<>/debian/linux-image-6.6.15-amd64/usr/lib/modules/6.6.15-amd64:
> >  No such file or directory
> 
> I would say depmod changed the API from /lib/modules to
> /usr/lib/modules.  Re-assign?

A right, the last upload of kmod changed to use:

--with-module-directory=/usr/lib/modules

Looping in Marco for comments.

Regards,
Salvatore

Bug#1060932: (doublecmd: FTBFS: make[1]: *** [debian/rules:16: override_dh_install] Error 2)

[Abou Al Montacir]

Control: tag -1 - trixie
-- 
Cheers,
Abou Al Montacir


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

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Bastian Blank]

On Mon, Feb 12, 2024 at 10:09:41PM +0100, Salvatore Bonaccorso wrote:
> kernel-wedge copy-modules 6.6.15 amd64 6.6.15-amd64
> depmod: ERROR: could not open directory 
> /<>/debian/linux-image-6.6.15-amd64/usr/lib/modules/6.6.15-amd64:
>  No such file or directory

I would say depmod changed the API from /lib/modules to
/usr/lib/modules.  Re-assign?

Bastian

-- 
Every living thing wants to survive.
-- Spock, "The Ultimate Computer", stardate 4731.3

Bug#1063804: FTBFS: depmod: FATAL: could not search modules: No such file or directory

[Salvatore Bonaccorso]

Source: linux-signed-amd64
Version: 6.6.15+2
Severity: serious
Justification: FTBFS
X-Debbugs-Cc: car...@debian.org, wa...@debian.org, k...@debian.org

The linux-signed-amd64 (and arm64 one) currently FTBFS (only filling
one for amd64, as the same for arm64):

https://buildd.debian.org/status/fetch.php?pkg=linux-signed-amd64=amd64=6.6.15%2B2=1707701442=0

[...]
dh_builddeb -- -Zxz
dpkg-deb: building package 'linux-image-6.6.15-amd64' in 
'../linux-image-6.6.15-amd64_6.6.15-2_amd64.deb'.
make[2]: Leaving directory '/<>'
/usr/bin/make -f debian/rules.real binary_installer ABINAME='6.6.15' 
ARCH='amd64' COMPILER='gcc-13' DESTDIR='/<>/debian/tmp' 
DH_OPTIONS='-pacpi-modules-6.6.15-amd64-di -pata-modules-6.6.15-amd64-di 
-pbtrfs-modules-6.6.15-amd64-di -pcdrom-core-modules-6.6.15-amd64-di 
-pcrc-modules-6.6.15-amd64-di -pcrypto-dm-modules-6.6.15-amd64-di 
-pcrypto-modules-6.6.15-amd64-di -pefi-modules-6.6.15-amd64-di 
-pevent-modules-6.6.15-amd64-di -pext4-modules-6.6.15-amd64-di 
-pf2fs-modules-6.6.15-amd64-di -pfat-modules-6.6.15-amd64-di 
-pfb-modules-6.6.15-amd64-di -pfirewire-core-modules-6.6.15-amd64-di 
-pi2c-modules-6.6.15-amd64-di -pinput-modules-6.6.15-amd64-di 
-pisofs-modules-6.6.15-amd64-di -pjfs-modules-6.6.15-amd64-di 
-pkernel-image-6.6.15-amd64-di -ploop-modules-6.6.15-amd64-di 
-pmd-modules-6.6.15-amd64-di -pmmc-core-modules-6.6.15-amd64-di 
-pmmc-modules-6.6.15-amd64-di -pmouse-modules-6.6.15-amd64-di 
-pmtd-core-modules-6.6.15-amd64-di -pmultipath-modules-6.6.15-amd64-di 
-pnbd-modules-6.6.15-amd64-di -pnic-modules-6.6.15-amd64-di 
-pnic-pcmcia-modules-6.6.15-amd64-di -pnic-shared-modules-6.6.15-amd64-di 
-pnic-usb-modules-6.6.15-amd64-di -pnic-wireless-modules-6.6.15-amd64-di 
-ppata-modules-6.6.15-amd64-di -ppcmcia-modules-6.6.15-amd64-di 
-ppcmcia-storage-modules-6.6.15-amd64-di --modules-6.6.15-amd64-di 
-prfkill-modules-6.6.15-amd64-di -psata-modules-6.6.15-amd64-di 
-pscsi-core-modules-6.6.15-amd64-di -pscsi-modules-6.6.15-amd64-di 
-pscsi-nic-modules-6.6.15-amd64-di -pserial-modules-6.6.15-amd64-di 
-psound-modules-6.6.15-amd64-di -pspeakup-modules-6.6.15-amd64-di 
-psquashfs-modules-6.6.15-amd64-di -pudf-modules-6.6.15-amd64-di 
-puinput-modules-6.6.15-amd64-di -pusb-modules-6.6.15-amd64-di 
-pusb-serial-modules-6.6.15-amd64-di -pusb-storage-modules-6.6.15-amd64-di 
-pxfs-modules-6.6.15-amd64-di' FEATURESET='none' FLAVOUR='amd64' 
IMAGE_FILE='arch/x86/boot/bzImage' IMAGE_INSTALL_STEM='vmlinuz' 
IMAGE_PACKAGE_NAME='kernel-image-6.6.15-amd64-di' KCONFIG='debian/config/config 
debian/config/kernelarch-x86/config debian/config/amd64/config' 
KCONFIG_OPTIONS=' -o "BUILD_SALT=\"6.6.15-amd64\""' KERNEL_ARCH='x86' 
LOCALVERSION='-amd64' LOCALVERSION_HEADERS='' LOCALVERSION_IMAGE='-amd64' 
SOURCEVERSION='6.6.15-2' SOURCE_BASENAME='linux' SOURCE_SUFFIX='' 
UPSTREAMVERSION='6.6' VDSO='True' VERSION='6.6'
make[2]: Entering directory '/<>'
dh_testroot
dh_prep
dh_installdirs
DH_OPTIONS="-pkernel-image-6.6.15-amd64-di 
--sourcedir=debian/linux-image-6.6.15-amd64" dh_install 
boot/vmlinuz-6.6.15-amd64
DH_OPTIONS="-pkernel-image-6.6.15-amd64-di 
--sourcedir=debian/linux-image-6.6.15-amd64" dh_install 
lib/modules/6.6.15-amd64/modules.builtin
DH_OPTIONS="-pkernel-image-6.6.15-amd64-di 
--sourcedir=debian/linux-image-6.6.15-amd64" dh_install 
lib/modules/6.6.15-amd64/modules.order
kernel-wedge copy-modules 6.6.15 amd64 6.6.15-amd64
depmod: ERROR: could not open directory 
/<>/debian/linux-image-6.6.15-amd64/usr/lib/modules/6.6.15-amd64: 
No such file or directory
depmod: FATAL: could not search modules: No such file or directory
No module interdependencies found. This probably means your modules.dep is 
broken.
If this is intentional, touch /<>/debian/installer/no-modules
make[2]: *** [debian/rules.real:95: binary_installer] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules.gen:14: binary-arch_amd64_none_amd64_installer] 
Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:19: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Regards,
Salvatore

Bug#1063800: Should we restrict libtread-pool to 64bit only (Was: Bug#1063800: src:pinfish: fails to migrate to testing for too long: not installable on armel, armhf and i386)

[Andreas Tille]

Hi,

the chain of dependencies for pinfish which creates the problem is

   pinfish depends racon which in turn can't install its
   Build-Depends libthread-pool 4.0.0 which does not build
   for 32bit architectures[1]

My suggestion to solve the issue is to explicitly set

   Architecture: any-amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 
loong64 ppc64 sparc64 x32

and ask ftpmaster for removing 32bit architectures for libthread-pool,
racon and pinfish.  Does anybody think we should ask libthread-pool
upstream to support 32bit or do we just want to go on to remove 32bit
(which also solves time_t bug easily).

Kind regards
Andreas.

[1] https://buildd.debian.org/status/package.php?p=libthread-pool

Am Mon, Feb 12, 2024 at 09:35:34PM +0100 schrieb Paul Gevers:
> Source: pinfish
> Version: 0.1.0+ds-3
> Severity: serious
> Control: close -1 0.1.0+ds-4
> 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:pinfish has been trying to migrate for 31 days [2].
> Hence, I am filing this bug. It seem the version in unstable isn't
> installable on our 32 bit architectures. It seems like the version in
> testing doesn't have binaries on these architectures, while the buildd
> history shows they were built for the previous version, so you probably had
> them removed. You probably need to do this again, but I suggest to add a
> Build-Depends on racon to prevent accidental builds on architectures where
> racon isn't available (and thus the package becomes not installable).
> 
> 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=pinfish
> 




> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#1063799: src:snapd-glib: fails to migrate to testing for too long: FTBFS on mips64el, ppc64el and s390x

[Bastian Germann]

Control: found -1 1.63-5

This is not caused by the NMU. The three failing release architectures also 
FTBFS in testing.

Bug#1063803: grub-pc: Regression from Debian 11.8 to 11.9, boot disk must be first in bios boot sequence

[Karl O. Pinc]

Package: grub-pc
Version: 2.06-3~deb11u6
Severity: important

Hi,

Upgrading from Debian 11.8 to 11.9, the system froze at boot.  After
grub prints the "loading initramfs..." (or some such) line, the
screen cleared and an underscore appeared in the upper left.
After that the system did not respond to ctrl-alt-del.

What seemed to fix the problem was to put the boot disk first
in the bios boot sequence.

Other information:

I did plug in an unplugged drive.  And I also unplugged the
dvd drive and used it's sata cable to plug in the boot drive.
(The boot drive being the only drive used.  All other have
I'm not sure what on them.)  After doing this, the system
remained broken, the freeze behavior did not change.
I then changed the boot order in the bios setup, and was able
to boot.

So, changing the cable on the boot/root drive may have changed
the controller but this does not seem to matter.

The upgrade installed a new kernel.  After upgrade neither the
old nor the new kernel (5.10.0-27-686-pae and 5.10.0-28-686-pae)
would boot.  "Freeze behavior" was the same with both.
This is why I believe the problem is in grub, not the kernel.

After changing the boot order in bios and booting, I rebuilt
the 5.10.0-28-686-pae initramfs.  Rebooting with the new
initramfs worked.  This is why I believe the problem is
not with mkinitramfs.

UEFI boot disabled.  (Enabling did nothing).

Note that the hardware & arch are mis-matched, and the
hardware is strange.  There's at least one hardware raid
card (I think), none of which I use.  I had an old i686
box break and I just dropped the drive into new hardware;
the old drive is _slow_, and a spinning disk.  It's been
running fine for at least a year, through various point
releases, and has always worked in the past.  (I'm pretty
sure I'm using only a fraction of the box's ram.)

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/vg00-root / ext3 rw,relatime,errors=remount-ro 0 0
/dev/sdf2 /boot ext2 rw,relatime,stripe=4 0 0
/dev/mapper/vg00-apt--cacher /var/cache/apt-cacher ext3 rw,noatime 0 0
/dev/mapper/vg00-debian /srv/debian ext4 rw,noatime,stripe=32742 0 0
/dev/mapper/vg00-debian /home/ftp/debian ext4 ro,noatime,stripe=32742 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(fd0)   /dev/fd0
(hd0)   /dev/disk/by-id/ata-WDC_WD20EZRX-00D8PB0_WD-WMC4M0E0X336
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 
--hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 --hint='hd0,gpt2'  
015e8b4d-a62b-4017-91e0-90ad0cbad794
else
  search --no-floppy --fs-uuid --set=root 015e8b4d-a62b-4017-91e0-90ad0cbad794
fi
font="/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=C
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-76969129-3e22-4188-9907-3eb9a0c172ce' {
load_video
insmod gzio
   

Bug#1063802: Update to latest release (1.2.x)

[Jérôme Charaoui]

Package: src:ruby-concurrent
Version: 1.1.6+dfsg-5

Hello,

I'm currently working on upgrading the Puppet packages in Debian and one 
of the requirements is a newer version of ruby-concurrent, at least 1.2.2.


The reason is that memory leaks were identified in earlier versions.

Unless there's a reason to proceed in a more coordinated manner (if so, 
let me know), I'll upload an updated package myself some time soon.


Thanks,

-- Jérôme

Bug#1063783: libconfig-model-dpkg-perl: does not recognise Architecture field in debian/tests/control

[Victor Westerhuis]

Package: libconfig-model-dpkg-perl
Followup-For: Bug #1063783
Control: tags -1 patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've opened a MR[1] on Salsa with a fix. I've also included the patch
with this message.

- --
Vriendelijke groet, Kind regards,

Victor Westerhuis

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

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

Versions of packages libconfig-model-dpkg-perl depends on:
ii  debhelper  13.13
ii  libapt-pkg-perl0.1.40+b3
ii  libarray-intspan-perl  2.004-2
ii  libconfig-model-backend-yaml-perl  2.134-2
ii  libconfig-model-perl   2.153-3
ii  libexporter-lite-perl  0.09-2
ii  liblog-log4perl-perl   1.57-1
ii  libmouse-perl  2.5.10-1+b4
ii  libparse-debcontrol-perl   2.005-6
ii  libparse-recdescent-perl   1.967015+dfsg-4
ii  libsoftware-copyright-perl 0.012-2
ii  libsoftware-licensemoreutils-perl  1.009-1
ii  libsort-versions-perl  1.62-3
ii  libtext-autoformat-perl1.75-2
ii  libtext-levenshtein-damerau-perl   0.41-3
ii  libtoml-tiny-perl  0.16-1
ii  liburi-perl5.25-1
ii  libwww-perl6.76-1
ii  libyaml-pp-perl0.38.0-1
ii  licensecheck   3.3.9-1
ii  lintian2.116.3
ii  perl [libmodule-corelist-perl] 5.38.2-3

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.379-1

libconfig-model-dpkg-perl suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmXKerwTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+7X0D/9MJ/oQ6IrkQy3H9l4vdh6YvNmxp8Bv
ebTteB/Orhm8NAa3PMcgUKV1FQRBwncxjpc38r2qaFvVSMOCbZvCH94VtxixGCsK
/RvKyMOxDf5qZixLuTz1iaYp+Va+dbijiMG7YKAcwSOFx+FWJ85l/OAW9hFboj/c
Z8Ue7P/UMJqoKQOQoWV9hyKN5zbAma9gftSHxo/o6Jyad6hVWxznByC08DHdYW+K
EVvE0/mAQKsZkna8OSf0h+cIghXkEK6z8ueEShP7MaWsfQkuL0RnOf76Qh0Jxxom
lP79rf8TN6N9xJFntMqtIxp7RIqCGF7nIzQALqe32W7y+qeKtwilGmLTH/OmNOmd
zcC1N1/q1NIOuYxzIGBcIGvNf3fT7aS1Tmhc8nRzy+yqccUri1UUej/+cM87eqc1
4azmfm67J0JZgWmzUJ6638vYacHqz59kurzK7d/MWdXRqSpH8YiwhVpzpcvykxIM
fwmAj9h97KDNILKX4Wq1B0v8PUXn2r4hxS/ugq4sHDMJRcy8KuvLHUGjH8aXDkJF
m1+zqrq/n9BucehJTZRVB3cfAsqDvzfVks11XdbrPlHnABZmbeeaXIwkHGC56rYy
E3rXOon9yTpKsZ+bn75K+13kaMgZekVKRA0RfaSOmmwWWbZxX9OkCIxQcdQWJ1KV
BSmHdqBnbabfkQ==
=Fvjq
-END PGP SIGNATURE-
>From 9ccdbc88bf300e25a3dbcd043a4b492dba7cf9b7 Mon Sep 17 00:00:00 2001
From: Victor Westerhuis 
Date: Mon, 12 Feb 2024 20:49:15 +0100
Subject: Add Architecture as allowed field in debian/tests/control

---
 lib/Config/Model/models/Dpkg/Tests/Control.pl | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/Config/Model/models/Dpkg/Tests/Control.pl 
b/lib/Config/Model/models/Dpkg/Tests/Control.pl
index f0f0f13e..12b9d053 100644
--- a/lib/Config/Model/models/Dpkg/Tests/Control.pl
+++ b/lib/Config/Model/models/Dpkg/Tests/Control.pl
@@ -120,6 +120,12 @@ This field can specify a list of abstract class names such 
as "desktop" or "grap
 This is purely an informational field for autopkgtest itself and will be 
ignored.',
 'type' => 'leaf',
 'value_type' => 'uniline'
+  },
+  'Architecture',
+  {
+'description' => 'When package tests are only supported on a limited 
set of architectures, or are known to not work on a particular (set of) 
architecture(s), this field can be used to define the supported architectures. 
The autopkgtest will be skipped when the architecture of the testbed doesn\'t 
match the content of this field. The format is the same as in (Build-)Depends, 
with the understanding that C is not allowed, and C means that the 
test will be run on every architecture, which is the default when not 
specifying this field at all.',
+'type' => 'leaf',
+'value_type' => 'string'
   }
 ],
 'gist' => '{Tests:0}{Test-Command}',
-- 
2.43.0

Bug#1063801: freeglut: CVE-2024-24258 CVE-2024-24259

[Salvatore Bonaccorso]

Source: freeglut
Version: 3.4.0-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/freeglut/freeglut/pull/155
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for freeglut.
Those were previously associated with mupdf, but found that the issues
are in freeglut instread.

CVE-2024-24258[0]:
| freeglut 3.4.0 was discovered to contain a memory leak via the
| menuEntry variable in the glutAddSubMenu function.


CVE-2024-24259[1]:
| freeglut through 3.4.0 was discovered to contain a memory leak via
| the menuEntry variable in the glutAddMenuEntry function.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-24258
https://www.cve.org/CVERecord?id=CVE-2024-24258
[1] https://security-tracker.debian.org/tracker/CVE-2024-24259
https://www.cve.org/CVERecord?id=CVE-2024-24259
[2] https://github.com/freeglut/freeglut/pull/155
[3] 
https://github.com/freeglut/freeglut/commit/9ad320c1ad1a25558998ddfe47674511567fec57

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1063800: src:pinfish: fails to migrate to testing for too long: not installable on armel, armhf and i386

[Paul Gevers]

Source: pinfish
Version: 0.1.0+ds-3
Severity: serious
Control: close -1 0.1.0+ds-4
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:pinfish has been trying to migrate for 31 
days [2]. Hence, I am filing this bug. It seem the version in unstable 
isn't installable on our 32 bit architectures. It seems like the version 
in testing doesn't have binaries on these architectures, while the 
buildd history shows they were built for the previous version, so you 
probably had them removed. You probably need to do this again, but I 
suggest to add a Build-Depends on racon to prevent accidental builds on 
architectures where racon isn't available (and thus the package becomes 
not installable).


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=pinfish



OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[dann frazier]

On Sun, Feb 11, 2024 at 08:46:32PM +0100, Salvatore Bonaccorso wrote:
> Does this split look good to you?

Yes, thank you!

  -dann

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Mario Limonciello]

On 2/12/2024 14:11, Diederik de Haas wrote:

On Monday, 12 February 2024 19:38:12 CET Henrique de Moraes Holschuh wrote:

On Fri, Feb 2, 2024, at 13:50, Diederik de Haas wrote:

This is about "AMD Platform Management Framework TA", which seems to be
about AMD CPU features. The first (and only) commit message has this:

```
amd_pmf: Add initial PMF TA for Smart PC Solution Builder

AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
```

Firmware for AMD graphics belongs in firmware-nonfree, but the
``amdtee`` directory seems to fit better in amd64-microcode?


Could be, yes.  It isn't needed at early boot at all, but then neither is
AMD-SEV, and it is in amd64-microcode.

So yeah, I could carry it on amd64-microcode, but we need to coordinate it
re. linux-firmware packages, since it has to move from one package to the
other.  Unless it has never made it to any linux-firmware packages ?


It has never made it into any firmware-nonfree package, so nothing needs to
move.
I'm working on a 20230804 update where I have added AMD-SEV to the Files-
Excluded section. I then came across the 'amdtee' dir and was wondering what
(best) to do with that, hence this bug.


And I need to know what I should do about it on the backport branches and
security update branches.


I don't know/understand what you mean by this. Can you clarify?

On Wed, 7 Feb 2024 18:38:30 -0600 Mario Limonciello
 wrote:

The firmware is only used on mobile APUs (which contain graphics).  So
if needing to pick an existing binary package instead of a new one I can
see a stronger argument to bundle it with the graphics package.


My logic was that this is about AMD TEE (Trusted Execution Environment), which
I *assumed* is part of/tied to the CPU. This thought is based on that on ARM
platforms, you also have a TEE and that is part of the CPU (and implemented in
TF-A IIUC). I can be wrong here ofc.


To me using the nomenclature of "CPU" is confusing.  We should be 
calling these SoCs.


Notably AMD APUs have X86 cores, IPU/NPU cores, GPU cores, ASP (formerly 
called PSP) and various others.


The TEE environment is part of the ASP, which is present on all Zen and 
later SoCs.




That it *currently* is only used on mobile APUs is something I consider to be
an implementation detail. I can be wrong on this too.


This specific TEE firmware is only for mobile APUs, but you're right the 
TEE environment is on socketed client desktop SoCs too.




There's no need to pick an existing binary package. I could add it to amd-
graphics, but I consider that a poor choice. I could create a new binary
package `amdtee` in firmware-nonfree (source package).
That would be fine afaic.

But as I assumed AMD TEE is a CPU feature, adding it to a package which
already deals with AMD CPU features seems the most logical.
And if AMD TEE becomes available in the future in 'normal' desktop CPUs
(without graphics) it would be 'weird' to have to install firmware-amd-graphics
to make use of it (and then a move probably would be needed).

So I have no strong feelings about it, just trying to find the best place for
the `amdtee` dir.

Cheers,
   Diederik


My general feeling is that having separated binary packages for all the 
AMD 'things' makes things "generally" confusing for end users and is 
needless extra work for you to maintain.


'amdtee' is the one thing right now, but soon (TM) the IPU/NPU binaries 
will go to linux-firmware.git and then where do those go?


Current products only put the IPU/NPU in APU chips, but who is to stay; 
those might end up in SoCs without graphics in the future too.


How would you feel about making a master "amd" metapackage that pulls 
them all?  You can split as you see fit then and people who want the 
'easy button' can just install that package.

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

[Bastian Germann]

Am 11.02.24 um 16:40 schrieb Stefan Monnier:

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


I guess you expect the rest of the patch set at
https://github.com/ungoogled-software/ungoogled-chromium/tree/master/patches/core/ungoogled-chromium
to be applied. Please ask for that on the chromium package's bug tracker.


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

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


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


That is true, and it is probably not to the extend of ungoogled chromium.
I have just said that Debian's chromium is already patched
and the package maintainers would probably welcome integrating patches
that remove privacy violations.

Bug#1037346: cyrus-imapd: all emails disappeared after upgrading from bullseye to bookworm (similar to #1007965)

[Oliver Gerlich]

Hi,

I had the same problem (mails were not displayed in the mail client any
more after upgrading from Bullseye to Bookworm).

What worked in the end for me was this:

- restored /var/lib/cyrus/ and /var/spool/cyrus/ from backup, to the old
state from before the Debian upgrade.
- built Cyrus 3.4.6, and installed and started it temporarily. The mails
were now visible in the mail client again.
- upgraded to the normal Cyrus version from Bookworm. The mails were
still visible in the mail client.

And since I had already kept the server running for some hours with the
broken mail archive, I then also restored the getmail6 status files
(/var/lib/getmail) to the state from before the Debian upgrade. This
caused getmail to re-fetch the mails that were missing.

I don't know how to detect whether the mail archive was really migrated
successfully; but since Cyrus 3.6.1 is now running and Thunderbird can
connect and sees all mails, I suppose the migration was successful?


Regarding the build of Cyrus 3.4.6, in the end I built it using the
existing Debian packaging data, and using the "debocker" tool to build
inside a clean Docker container.

Unfortunately debocker will always run the "lintian" tool to check the
package, which failed for me with error "E: cyrus-common:
depends-on-obsolete-package Depends: lsb-base". I didn't know how to fix
this error or how to correctly disable the lintian step; so I edited the
debocker files to disable this check. Very ugly, but it worked.

So from my notes, these must have been the steps that I did for building
the Cyrus 3.4.6 Debian package:
- installed "debocker" and "devscripts" packages: `sudo apt install
debocker devscripts`
- downloaded the Debian cyrus-imapd packaging info: `debcheckout
cyrus-imapd`
- downloaded the original source package: `wget
https://github.com/cyrusimap/cyrus-imapd/releases/download/cyrus-imapd-3.4.6/cyrus-imapd-3.4.6.tar.gz`
- renamed the source package so it would be found in the next steps: `mv
cyrus-imapd-3.4.6.tar.gz cyrus-imapd_3.4.6.orig.tar.gz`
- `cd cyrus-imapd/`
- started new Git branch at the state of Cyrus 3.4.3-4: `git checkout -b
cyrus-3.4.6 debian/3.4.3-4`
- added changelog entry: `dch -v '3.4.6-1.1' "use new upstream version
3.4.6"`
- the warning about missing DEBEMAIL can be ignored
- committed change: `git commit debian/changelog -m 'update changelog'`

- modified the "debocker" template files to disable the lintian step:
`sudo nano /usr/share/debocker/bundle-files/steps/05-build` and then
commented out the line for "lintian --pedantic --display-info *.changes"

- created build bundle: `debocker bundle --image debian:bookworm -f "-b
-us -uc"`
- did the actual build: `sudo debocker build-bundle
../cyrus-imapd_3.4.6-1.1_bundle.tar`
- whether the "sudo" is necessary depends on your local Docker setup
- the build took a while (half an hour or more?); and then there was a
message like "LOG Build successful", and there were lots of Cyrus
packages in the current directory.

I then copied cyrus-clients_3.4.6-1.1_amd64.deb,
cyrus-common_3.4.6-1.1_amd64.deb and cyrus-imapd_3.4.6-1.1_amd64.deb to
the server and installed them.

Remember to undo the change to the debocker file
(/usr/share/debocker/bundle-files/steps/05-build) after the build.

Kind regards,
Oliver

Bug#1063799: src:snapd-glib: fails to migrate to testing for too long: FTBFS on mips64el, ppc64el and s390x

[Paul Gevers]

Source: snapd-glib
Version: 1.63-5
Severity: serious
Control: close -1 1.63-5.1
Tags: sid trixie ftbfs
X-Debbugs-CC: Bo YU , b...@debian.org
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:snapd-glib has been trying to migrate for 
32 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on mips64el, ppc64el and s390x


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=snapd-glib



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Diederik de Haas]

On Monday, 12 February 2024 19:38:12 CET Henrique de Moraes Holschuh wrote:
> On Fri, Feb 2, 2024, at 13:50, Diederik de Haas wrote:
> > This is about "AMD Platform Management Framework TA", which seems to be
> > about AMD CPU features. The first (and only) commit message has this:
> > 
> > ```
> > amd_pmf: Add initial PMF TA for Smart PC Solution Builder
> > 
> > AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
> > ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
> > ```
> > 
> > Firmware for AMD graphics belongs in firmware-nonfree, but the
> > ``amdtee`` directory seems to fit better in amd64-microcode?
> 
> Could be, yes.  It isn't needed at early boot at all, but then neither is
> AMD-SEV, and it is in amd64-microcode.
> 
> So yeah, I could carry it on amd64-microcode, but we need to coordinate it
> re. linux-firmware packages, since it has to move from one package to the
> other.  Unless it has never made it to any linux-firmware packages ?

It has never made it into any firmware-nonfree package, so nothing needs to 
move.
I'm working on a 20230804 update where I have added AMD-SEV to the Files-
Excluded section. I then came across the 'amdtee' dir and was wondering what 
(best) to do with that, hence this bug.

> And I need to know what I should do about it on the backport branches and
> security update branches.

I don't know/understand what you mean by this. Can you clarify?

On Wed, 7 Feb 2024 18:38:30 -0600 Mario Limonciello 
 wrote:
> The firmware is only used on mobile APUs (which contain graphics).  So 
> if needing to pick an existing binary package instead of a new one I can 
> see a stronger argument to bundle it with the graphics package.

My logic was that this is about AMD TEE (Trusted Execution Environment), which 
I *assumed* is part of/tied to the CPU. This thought is based on that on ARM 
platforms, you also have a TEE and that is part of the CPU (and implemented in 
TF-A IIUC). I can be wrong here ofc.

That it *currently* is only used on mobile APUs is something I consider to be 
an implementation detail. I can be wrong on this too.

There's no need to pick an existing binary package. I could add it to amd-
graphics, but I consider that a poor choice. I could create a new binary 
package `amdtee` in firmware-nonfree (source package).
That would be fine afaic.

But as I assumed AMD TEE is a CPU feature, adding it to a package which 
already deals with AMD CPU features seems the most logical.
And if AMD TEE becomes available in the future in 'normal' desktop CPUs 
(without graphics) it would be 'weird' to have to install firmware-amd-graphics 
to make use of it (and then a move probably would be needed).

So I have no strong feelings about it, just trying to find the best place for 
the `amdtee` dir.

Cheers,
  Diederik

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

Bug#1063798: src:spaln: fails to migrate to testing for too long: FTBFS on arm64, ppc64el and s390x

[Paul Gevers]

Source: spaln
Version: 2.4.13f+dfsg-1
Severity: serious
Control: close -1 3.0.2+dfsg-1
Tags: sid trixie ftbfs
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:spaln has been trying to migrate for 32 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on arm64, ppc64el and s390x.


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=spaln



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063797: src:mathgl: fails to migrate to testing for too long: FTBFS on amd64 and i386

[Paul Gevers]

Source: mathgl
Version: 8.0.1-4
Severity: serious
Control: close -1 8.0.1-5
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1063599

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:mathgl has been trying to migrate for 34 
days [2]. Hence, I am filing this bug. The version in unstable failed to 
build on amd64 and i386 (and arch:all), as reported in bug #1063599). 
Apparently now also a lot of other architectures have build problems 
(build depends not available)


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=mathgl



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063796: src:plplot: fails to migrate to testing for too long: patchelf not available on mips64el

[Paul Gevers]

Source: plplot
Version: 5.15.0+dfsg2-6
Severity: serious
Control: close -1 5.15.0+dfsg2-7+deb13u1
X-Debbugs-CC: debian-m...@lists.debian.org
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:plplot has been trying to migrate for 34 
days [2]. Hence, I am filing this bug. The package Build-Depends on 
patchelf, which has a build issue on mips64el (bug #1059752). 
Unfortunately patchelf is a key package, and saw a new version in the 
time that mips64el was allowed to be broken, so currently patchelf 
doesn't exist on mips64el in testing. This is impacting your package. I 
think that for the time being it's probably easiest to request removal 
of your package on mips64el. Alternatively you try to help fix the bug 
in patchelf (I've CC'd the mips porters to draw their attention to the 
problem too).


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=plplot



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063795: python-glance-store: CVE-2024-1141

[Moritz Mühlenhoff]

Source: python-glance-store
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for python-glance-store.

CVE-2024-1141[0]:
| A vulnerability was found in python-glance-store. The issue occurs
| when the package logs the access_key for the glance-store when the
| DEBUG log level is enabled.

https://bugzilla.redhat.com/show_bug.cgi?id=2258836
https://github.com/openstack/glance_store/commit/d6e531af4821c8466b1e9404f12f89f6216417f2
https://github.com/openstack/glance_store/commit/a5ba027922ba1230b4ae9abb810f36427be6354a


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-1141
https://www.cve.org/CVERecord?id=CVE-2024-1141

Please adjust the affected versions in the BTS as needed.

Bug#1059385: r-cran-ggally: autopkgtest regression

[Andreas Tille]

Control: block -1 by 1063785
Control: tags -1 pending

Hi,

as per upstream the test fails due to the missing Test-Depends
r-cran-intergraph.  This is uploaded to new (WNPP #1063785) and
will be uploaded as soon as it has cleared new.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1063794: ITP: chordpro -- lyrics and chords formatting program

[Roland Rosenfeld]

Package: wnpp
Owner: Roland Rosenfeld 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: chordpro
  Version : 6.050
  Upstream Author : Johan Vromans 
* URL : https://www.chordpro.org/
* License : Artistic or GPL-1+
  Programming Lang: FIXME
  Description : lyrics and chords formatting program

ChordPro will read one or more text files containing the lyrics of
one or many songs plus chord information. chordpro will then generate
a photo-ready, professional looking, impress-your-friends sheet-music
suitable for printing on your nearest printer.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1063793: ITP: libstring-interpolate-named-perl -- Interpolated named arguments in string

[Roland Rosenfeld]

Package: wnpp
Owner: Roland Rosenfeld 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libstring-interpolate-named-perl
  Version : 1.03
  Upstream Author : Johan Vromans 
* URL : https://metacpan.org/release/String-Interpolate-Named
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Interpolated named arguments in string

String::Interpolate::Named provides a function to interpolate named
arguments by target texts in a template string. The target texts are
provided to the function via a hash, where the keys correspond to the
named argument to be replaced, or a subroutine that performs the lookup.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1063792: ITP: libtext-layout-perl -- Pango style markup formatting

[Roland Rosenfeld]

Package: wnpp
Owner: Roland Rosenfeld 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtext-layout-perl
  Version : 0.032
  Upstream Author : Johan Vromans 
* URL : https://metacpan.org/release/Text-Layout
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Pango style markup formatting

Text::Layout provides methods for Pango style text formatting.  Where
possible the methods have identical names and (near) identical
behavior as their Pango counterparts.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1063791: ITP: libfile-loadlines-perl -- Load lines from files and network

[Roland Rosenfeld]

Package: wnpp
Owner: Roland Rosenfeld 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libfile-loadlines-perl
  Version : 1.045
  Upstream Author : Johan Vromans 
* URL : https://metacpan.org/release/File-LoadLines
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Load lines from files and network

File::LoadLines provides an easy way to load the contents of a text
file into an array of lines.  It is intended for small to moderate
size files like config files that are often produced by weird tools
(and users).

It will transparantly fetch data from the network if the provided
file name is a URL.

File::LoadLines automatically handles ASCII, Latin-1 and UTF-8
text.  When the file has a BOM, it handles UTF-8, UTF-16 LE and BE,
and UTF-32 LE and BE.

Recognized line terminators are NL (Unix, Linux), CRLF (DOS, Windows)
and CR (Mac)

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1063790: ITP: libjavascript-quickjs-perl -- Run JavaScript via QuickJS in Perl

[Roland Rosenfeld]

Package: wnpp
Owner: Roland Rosenfeld 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libjavascript-quickjs-perl
  Version : 0.19
  Upstream Author : Felipe Gasper (FELIPE)
* URL : https://metacpan.org/release/JavaScript-QuickJS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Run JavaScript via QuickJS in Perl

JavaScript::QuickJS embeds Fabrice Bellard’s  QuickJS engine into a
Perl XS module.  You can thus run JavaScript directly in your Perl
programs.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1032530:

[sj fordeb]

Reproduced by running same command twice. IOW, the second time the target
directory was not empty.

Bug#1063789: RFS: anew/0.2-1 -- Tool for adding new lines to files, skipping duplicates (program)

[Marcos Rodrigues de Carvalho (aka oday)]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : anew
   Version  : 0.2-1
   Upstream contact : m...@tomhudson.co.uk
 * URL  : https://github.com/tomnomnom/anew
 * License  : Expat
 * Vcs  : https://salsa.debian.org/marcos.rcarvalho/anew
   Section  : golang

The source builds the following binary packages:

  anew - Tool for adding new lines to files, skipping duplicates (program)

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/anew/anew_0.2-1.dsc

Changes for the initial release:

 anew (0.2-1) unstable; urgency=medium

   * New upstream release.

Regards,

  Marcos Rodrigues de Carvalho (aka oday)

Bug#1063736: snort removal from bullseye (Re: Bug#1063736: RM: snort -- RoQA; security issues, unmaintained)

[Moritz Muehlenhoff]

On Mon, Feb 12, 2024 at 06:16:48PM +, Jonathan Wiltshire wrote:
> On Mon, Feb 12, 2024 at 09:24:47AM +, Holger Levsen wrote:
> > hi,
> > 
> > On Sun, Feb 11, 2024 at 09:44:18PM +, Jonathan Wiltshire wrote:
> > > Requested by security team. Not in stable or testing.
> > 
> > once this has happened we should communicate this to our users via
> > debian-security-upload to bullseye.
> 
> Looping in security in case security support should be withdrawn earlier.
> (The removal won't happen until the next and final point release.)

That's fine, all current bugs are addressed in bullseye, except a
minor logrotate issue.

Cheers,
Moritz

Bug#1063675: nvidia-graphics-drivers 525.147.05-6~deb12u1 flagged for acceptance

[Patrick ZAJDA]

Le 12/02/2024 à 18:56, Jonathan Wiltshire a écrit :

package release.debian.org
tags 1063675 = 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: nvidia-graphics-drivers
Version: 525.147.05-6~deb12u1

Explanation: restore compatibility with newer Linux kernel builds; take over 
packages from nvidia-graphics-drivers-tesla; add new nvidia-suspend-common 
package

So the update won't be available in bookworm-update and we must add 
proposed-update to our sources to be able to update to latest kernel?

Or do I miss something?

Best regards,
--
Patrick ZAJDA


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063788: RM: rust-libadwaita-sys/experimental -- ROM; wrongful upload

[Matthias Geiger]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net, werdah...@riseup.net
Control: affects -1 + src:rust-libadwaita-sys

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear ftpmasters,

please remove rust-libadwaita-sys from experimental. I uploaded 0.6.1; 
which does not build against the newer gtk-rs stack staged in
experimental. 0.6.0 is the correct version; our tooling picked up the
wrong one. Since our tooling does not support +really versions atm
removal and re-upload it the best way to go here imo.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmXKazoVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1wxAP+gNWek10JGPmAs6Xlu8paZKKjcTO
/wggOKXk+G3IHUlBcpM1x2IYHUPEZ6INfm8oz7HICrz6VTzuYx5ceRU3UOjmegZE
xOzr7TWdr2tFses0nxcBKc68BogHN8gkmbYkZb8eE4JRFkWYtmSinl35tn1O04L+
oJA82kbhnlGzPfJ1uhXZ4yHu4zKnvwMv//9WffwnX9jxftMQkD5sB2owLQ6vsqaE
TmwazLeEASPcB5Wj38lift2x8KiAlxeOwd04JtbxXx9DJZM48+5QAh64CW3XEF5w
+wOwEtYJGHm2XGWBVrrtER8XTiXzX7O5m/FrCWSbXZOz3iSyQY/C+UcsRhjs+0rw
aqw4QPXwHyQ/ekLKyzaj0+za0gCgKZqlx5wESXdzlD8lbYUUuZQg/Tas174F/leV
3h1oXpXWVEZIxQum1T7N4wfE7DAyukPauhCg70tFfQqcNj46ovx4RrpPjiwRG9oc
thWUtyzIBEeTsoOc/84A1+ZsJtLuZk+EcIQgcRx1dGrenlvLWw+frho+NzcCgLGB
tXDDgafiTJQexuEO8Sq0OlrRJEaOr0cDyZMMc70V/sYNb2RZ/SeZZLKtJ8IJo7ed
uX5Oq/Iw6GcaeeknHjPKKtdPoRHhYkRkXAnYLr5fwysTh9c4BHExBeXuhdyJMTow
B431ImF/h93Nytjd
=cfLY
-END PGP SIGNATURE-

Bug#1063787: installation-reports: No ethernet on Cubieboard with netboot SD-card-image

[Ville Viinikka]

Package: installation-reports
Severity: important

Boot method: netboot/SD-card-images
Image version: 
https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/partition.img.gz
 2024-02-12 00:01
Date: 2024-02-12

Machine: Cubietech Cubieboard


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

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

Comments/Problems:

Can't continue network installation because the network card doesn't work:
[   50.262983] sun4i-emac 1c0b000.ethernet end0: could not find the PHY
[   50.263036] sun4i-emac 1c0b000.ethernet end0: cannot probe MDIO bus

Can be worked around by manually copying 
/lib/modules/6.6.13-armmp/kernel/drivers/net/mdio/mdio-sun4i.ko to initrd.

Should probably be fixed by adding mdio-sun4i to 
debian/installer/modules/armhf-armmp/nic-modules.

Bug#1063270: The "64bits time_t transition" in Debian/Xen

[Hans van Kranenburg]

Hi,

On 2/12/24 18:43, Andrew Cooper wrote:
> On 12/02/2024 5:27 pm, zithro wrote:
>> Hey all,
>>
>> the Debian project is focused on the "2038 time_t" switch.
>> So the maintainers of the Debian Xen package must ensure that all
>> imported Xen code conforms to the new Debian standards.
>>
>> I was asked by Andrew Cooper to post here about this, I'll quote him :
>> "So I had been idly wondering whether Xen would match up to Debian's new
>> policy, and it appears not
>> this topic really needs to be brought up on the xen-devel mailing list
>> do you have any more details as to what has gone wrong?
>> this is something we ought to arrange to happen in CI by default
>> but it sounds like there's some work needed first"
>>
>> (Not answering the question because I'm just a messenger).
> 
> xen.git/xen$ git grep -w time_t -- :/
> ../tools/console/client/main.c:106: time_t start, now;
> ../tools/console/daemon/io.c:272:   time_t now = time(NULL);
> ../tools/libs/light/libxl_qmp.c:116:    time_t timeout;
> ../tools/libs/light/libxl_qmp.c:585:   
> time_t ask_timeout)
> ../tools/libs/light/libxl_x86.c:516:    time_t t;
> ../tools/libs/toollog/xtl_logger_stdio.c:61:    time_t now = time(0);
> ../tools/tests/xenstore/test-xenstore.c:453:    time_t stop;
> ../tools/xenmon/xenbaked.c:98:time_t start_time;
> ../tools/xenstored/core.c:109:  time_t now;
> ../tools/xenstored/core.h:150:  time_t ta_start_time;
> ../tools/xenstored/domain.c:143:    time_t mem_last_msg;
> ../tools/xenstored/domain.c:188:static time_t wrl_log_last_warning; /*
> 0: no previous warning */
> ../tools/xenstored/domain.c:1584:   time_t now;
> ../tools/xenstored/lu.c:160:    time_t now = time(NULL);
> ../tools/xenstored/lu.c:185:    time_t now = time(NULL);
> ../tools/xenstored/lu.c:292:    time_t now = time(NULL);
> ../tools/xenstored/lu.h:32: time_t started_at;
> ../tools/xentop/xentop.c:947:   time_t curt;
> ../tools/xl/xl_info.c:742:static char *current_time_to_string(time_t now)
> ../tools/xl/xl_info.c:759:static void print_dom0_uptime(int short_mode,
> time_t now)
> ../tools/xl/xl_info.c:810:static void print_domU_uptime(uint32_t domuid,
> int short_mode, time_t now)
> ../tools/xl/xl_info.c:847:    time_t now;
> ../tools/xl/xl_vmcontrol.c:336:    time_t start;
> ../tools/xl/xl_vmcontrol.c:495:    time_t now;
> ../tools/xl/xl_vmcontrol.c:504:    if (now == ((time_t) -1)) {
> ../tools/xs-clients/xenstore_control.c:33:    time_t time_start;
> arch/x86/cpu/mcheck/mce.h:224:    uint64_t time; /* wall time_t when
> error was detected */
> arch/x86/time.c:1129: * machines were long is 32-bit! (However, as
> time_t is signed, we
> 
> 
> I don't see any ABI problems from using a 64bit time_t.  The only header
> file with a time_t is xenstored/lu.h which is a private header and not a
> public ABI.
> 
> I guess we fell into the "could not be analysed via
> abi-compliance-checker" case?

Thanks for also looking into this!

Maximilian mentioned in #debian-xen that doing a Debian package build
with DEB_BUILD_OPTIONS=abi=+lfs and _FILE_OFFSET_BITS=64 and
_TIME_BITS=64 resulted in the exact same binaries for shared libs.

What we also found is these reports:

1. Enabling lfs, which has no effect:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-06T16%3A48%3A00/compat_reports/libxen-dev/base_to_lfs/compat_report.html

2. Enabling the 64-bit time_t as well:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-06T16%3A48%3A00/compat_reports/libxen-dev/lfs_to_time_t/compat_report.html
In there, see "Problems with Data Types, Low Severity  2 " about
struct_timeval:

 >8 

  [+] struct timeval
Change -> Effect
1 Type of field tv_sec has been changed from __time_t to __time64_t.
-> Recompilation of a client program may be broken.
2 Type of field tv_usec has been changed from __suseconds_t to
__suseconds64_t. -> Recompilation of a client program may be broken.

  [+] affected symbols: 3 (0.2%)
* libxl_osevent_afterpoll ( libxl_ctx* ctx, int nfds, struct pollfd
const* fds, struct timeval now ) -> 4th parameter 'now' is of type
'struct timeval'.
* libxl_osevent_beforepoll ( libxl_ctx* ctx, int* nfds_io, struct
pollfd* fds, int* timeout_upd, struct timeval now ) -> 5th parameter
'now' is of type 'struct timeval'.
* libxl_osevent_register_hooks ( libxl_ctx* ctx, libxl_osevent_hooks
const* hooks, void* user ) -> Field 'hooks.timeout_modify.p2' in 2nd
parameter 'hooks' (pointer) has base type 'struct timeval'.

 >8 

So, the question is, is this correct and would it cause a problem.

If so, it also means that those functions are in a versioned lib,
libxenlight.so.4.17.0 (in binary package libxenmisc4.17).

Coincidentally, we are currently preparing the upload to switch from Xen
4.17 to Xen 4.18 in Debian unstable. So, if we just go ahead with doing
that, and make sure it's built in the new way already...

then...

tada.wav!

We just immediately have the correct 

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

[Sebastiaan Couwenberg]

Keeping an eye on the Release Calendar can help too:

 https://release.debian.org/release-calendar.ics

Kind Regards,

Bas

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

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Henrique de Moraes Holschuh]

On Fri, Feb 2, 2024, at 13:50, Diederik de Haas wrote:
> This is about "AMD Platform Management Framework TA", which seems to be
> about AMD CPU features. The first (and only) commit message has this:
>
> ```
> amd_pmf: Add initial PMF TA for Smart PC Solution Builder
>
> AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
> ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
> ```
>
> Firmware for AMD graphics belongs in firmware-nonfree, but the
> ``amdtee`` directory seems to fit better in amd64-microcode?

Could be, yes.  It isn't needed at early boot at all, but then neither is 
AMD-SEV, and it is in amd64-microcode.

So yeah, I could carry it on amd64-microcode, but we need to coordinate it re. 
linux-firmware packages, since it has to move from one package to the other.  
Unless it has never made it to any linux-firmware packages ?

And I need to know what I should do about it on the backport branches and 
security update branches.

-- 
  Henrique de Moraes Holschuh 

Bug#1063786: nss: Please package recent version 3.97 of NSS

[Carsten Schoenert]

Source: nss
Version: 2:3.96.1-1
Severity: wishlist

Hello Mike,

could you please package version 3.97 of the NSS package?
I'm trying to package Thunderbird 123.x for experimental but this is
depending on a newer libnss3-dev package.

Thanks and regards!
Carsten

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

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

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

[Andreas Sundstrom]

Ok, then I will stick with my workaround.

Although I don't think defaults like this really should change within a 
stable release, and certainly not without a notice about in in the 
changelog or NEWS file.


/Andreas

Bug#1063785: ITP: r-cran-intergraph -- GNU R coercion routines for network data objects

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-intergraph -- GNU R coercion routines for network data 
objects
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-intergraph
  Version : 2.0
  Upstream Author : Michał Bojanowski
* URL : https://cran.r-project.org/package=intergraph
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R coercion routines for network data objects
 Functions implemented in this package allow to coerce (i.e.
 convert) network data between classes provided by other R packages.
 Currently supported classes are those defined in packages: network and
 igraph.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-intergraph

Bug#1063742: nvidia-settings 525.147.05-1~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1063742 = 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: nvidia-settings
Version: 525.147.05-1~deb12u1

Explanation: also build for ppc64el

Bug#1055656: bookworm-pu: package ms-gsl/4.0.0-2+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Thu, Nov 09, 2023 at 09:00:09PM +0300, Nicholas Guriev wrote:
> [ Reason ]
> The libmsgsl-dev package in stable is currently incompatible with std::variant
> from GNU's libstdc++. To solve this issue, I propose a patch adding 
> conditional
> noexcept for the gsl::not_null template constructors.

Please go ahead.

Thanks,


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

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

Bug#1055036: bookworm-pu: package crmsh/4.4.1-1+deb12u1

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On Sun, Oct 29, 2023 at 10:16:25PM +0100, Valentin Vidic wrote:
> diff -Nru crmsh-4.4.1/debian/crmsh.postinst crmsh-4.4.1/debian/crmsh.postinst
> --- crmsh-4.4.1/debian/crmsh.postinst 1970-01-01 01:00:00.0 +0100
> +++ crmsh-4.4.1/debian/crmsh.postinst 2023-10-29 20:46:13.0 +0100
> @@ -0,0 +1,46 @@
> +#!/bin/sh
> +# postinst script for crmsh
> +#
> +# see: dh_installdeb(1)
> +
> +set -e
> +
> +# summary of how this script can be called:
> +#*  `configure' 
> +#*  `abort-upgrade' 
> +#*  `abort-remove' `in-favour' 
> +#  
> +#*  `abort-deconfigure' `in-favour'
> +#`removing'
> +#   
> +# for details, see http://www.debian.org/doc/debian-policy/ or
> +# the debian-policy package
> +#
> +
> +case "$1" in
> +configure)
> +mkdir -p /var/log/crmsh
> +chown hacluster:haclient /var/log/crmsh
> +chmod 0775 /var/log/crmsh
> +
> +touch /var/log/crmsh/crmsh.log
> +chown hacluster:haclient /var/log/crmsh/crmsh.log
> +chmod 0664 /var/log/crmsh/crmsh.log
> +;;

This will happen on every package update, no? What if the local
administrator has set other properties on the log file (e.g. to allow other
users to read it)?


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

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

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

[Adam D. Barratt]

On Mon, 2024-02-12 at 17:59 +, Jonathan Wiltshire wrote:
> The point release dates go to
> debian-stable-annou...@lists.debian.org which
> is very low traffic.

Actually, that's one place they *don't* go in advance. The first mail
to -stable-announce is at the point that processing of uploads is
already frozen.

(They do go to -project@ldo, amongst others, which is also generally
not too busy.)

Sending to d-d-a would require a second mail in each case, as the main
announcement is to debian-release@ BCCed to several other lists and
team aliases. From memory of previous discussions, dda was avoided both
for that reason and because it doesn't really capture the right
audience (not everyone who cares about point releases is a DD, and
"many" DDs don't particularly care about stable updates).

If it would help, we could easily add an additional address to the
notification list.

Regards,

Adam

Bug#1063736: snort removal from bullseye (Re: Bug#1063736: RM: snort -- RoQA; security issues, unmaintained)

[Jonathan Wiltshire]

On Mon, Feb 12, 2024 at 09:24:47AM +, Holger Levsen wrote:
> hi,
> 
> On Sun, Feb 11, 2024 at 09:44:18PM +, Jonathan Wiltshire wrote:
> > Requested by security team. Not in stable or testing.
> 
> once this has happened we should communicate this to our users via
> debian-security-upload to bullseye.

Looping in security in case security support should be withdrawn earlier.
(The removal won't happen until the next and final point release.)

Thanks,

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

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

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

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

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

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

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

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

Krb5 is very v6-happy.
So, you're suggesting that I fix this by build-depending on
libnss-myhostname [linux-any] assuming tests are enabled?
If so, that's easy.
(I don't remember the order of build profiles and architecture
specifications in a build depends but can go look that up.