Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Dirk Hünniger]

Hi Paul, Georges,

This site

https://qa.debian.org/excuses.php?package=mediawiki2latex

says:

Issues preventing migration:

 * mediawiki2latex/armel has unsatisfiable dependency
 * mediawiki2latex/mips64el has unsatisfiable dependency
 * mediawiki2latex/s390x has unsatisfiable dependency

So I think its a problem in the packages I depend on and thus cannot fix 
myself.


What is even more strange is that this site

https://buildd.debian.org/status/package.php?p=mediawiki2latex

says that is it installed on armel misp64el and s390x.

Happy to hear about you explanations.

Yours Dirk

On 13.02.24 20:08, Paul Gevers wrote:

Source: mediawiki2latex
Version: 8.0-1
Severity: serious
Control: close -1 8.7-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between 
testing and unstable for more than 30 days as having a Release 
Critical bug in testing [1]. Your package src:mediawiki2latex has been 
trying to migrate for 31 days [2]. Hence, I am filing this bug. The 
version can't be installed on armel, mips64el and s390x while the 
package builds on those architectures.


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


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


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


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


Paul

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

Bug#1063601: tailspin: FTBFS: error[E0407]: method `backtrace` is not a member of trait `Error`

[Jonas Smedegaard]

Quoting Peter Green (2024-02-14 00:51:12)
>  >> [eyre 0.6.8] error[E0407]: method `backtrace` is not a member of trait 
> `Error`
>  >> [eyre 0.6.8]   --> 
> /<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:19:9
> > The above seems like a failure not in tailspin but in librust-eyre-dev.
> 
> I don't think the errors Sebastian quoted are the cause of the build failure
> at all. I think they are just noise from a test compilation performed to
> determine what the compiler supports. Those same errors are present
> in the successful build log for tailspin 2.0.0
> 
> The actual error seems to be.
> 
> > error: environment variable `CARGO_CHANNEL` not defined at compile time
> >   --> tests/utils.rs:11:48
> >|
> > 11 | PathBuf::from(format!("./target/{}/tspin", env!("CARGO_CHANNEL")))
> >|^
> >|
> >= help: Cargo sets build script variables at run time. Use 
> > `std::env::var("CARGO_CHANNEL")` instead
> >= note: this error originates in the macro `env` (in Nightly builds, run 
> > with -Z macro-backtrace for more info)

Ohhh, of course.  Sorry to have bothered you instead of checking beyond
the bugreport itself.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them

[Andrius Merkys]

Hi,

On 2024-02-14 00:21, Peter Hyman wrote:

Description : tmpwatch is a utility searches for files not accessed in a
specific time and deletes them


I fail to parse the short description as a sentence. Maybe:

s/utility searches/utility which searches/

Best,
Andrius

Bug#1063882: gcc: Internal error from ternary cond as inline asm parameter

[Matthias Klose]

Control: tags -1 + moreinfo

On 14.02.24 02:10, VictorBW wrote:

Package: gcc
Version: 4:12.2.0-3
Severity: normal
X-Debbugs-Cc: knodewaeee+debb...@gmail.com

Dear Maintainer,

I wanted to dynamically select registers for use in an inline assembly 
statement, so I tried the questionmark conditional operator, as in this minimal 
example:

namespace gpr {
volatile register int64_t r12 asm("r12");
volatile register int64_t r13 asm("r13");
...
asm volatile ("mov %0, blah" : "+r"((reg) ? gpr::r13 : gpr::r12));



please post the complete code example.

please also recheck with newer GCC versions (GCC 13, GCC 14) in newer 
Debian development versions.



This generates an internal error:
$ g++ bug.cpp
during RTL pass: expand
bug.cpp: In function ‘void move(uint8_t, int64_t)’:
bug.cpp:11:47: internal compiler error: in expand_expr_addr_expr_1, at 
expr.cc:8435
   11 | asm volatile ("mov %0, blah" : "+r"((reg) ? gpr::r13 : 
gpr::r12));
  | 
~~^

g++ -freport-bug did not deem the bug reproducible, but godbolt.org produces 
the following backtrace
0x264bdbc internal_error(char const*, ...)
???:0
0xa523e3 fancy_abort(char const*, int, char const*)
???:0
0xf62e6e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
???:0
0xf703ae store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0

I expected:
Realistically, a proper compiler error
Optimistically, generation of appropriate branches

I will apply an alternative solution in the meantime, but the latter behaviour 
would be very nice to have.

Perhaps other builtins also generate improper errors when used with a 
conditional operator? (I have not tried)

First time Debian/GCC bugreport, please forgive any relevant blunders :)

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

Bug#1024830: ERROR: Unable to connect to servers to test latency.

[Christian Marillat]

On 14 févr. 2024 14:44, Paul Wise  wrote:

> On Fri, 26 Jan 2024 11:46:15 +0100 Yves-Alexis Perez wrote:
>> On Sat, 26 Nov 2022 08:35:40 +0100 cuboid_06_wavers wrote:
>> >   running speedtest
>> > 
>> >    * What was the outcome of this action?
>> > 
>> >   ERROR: Unable to connect to servers to test latency.
>> 
>> Same thing happens here. As far as I can tell that makes the package pretty
>> unusable so I guess the severity could be raised.
>
> I'm not able to reproduce this, speedtest-cli works fine for me,
> so lets let it back into testing until it is confirmed really broken.
>
> Could you all paste the output of your speedtests? Mine are below.
>
> Also probably a good idea to try the --secure or --single options.

Still doesn't work for me even with --secure or --single options
also tested on 3 machines

speedtest-cli is also unable to list remote server

,
| $ speedtest-cli --list
| Retrieving speedtest.net configuration...
`

Christian

Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them

[Michael Biebl]

Am 13.02.2024 um 23:21 schrieb Peter Hyman:

- how do you plan to maintain it?
tmpwatch has not had any activity for over 5 years. Originally written by
Erik Troan , Preston Brown , Mike A. 
Harris

, Miloslav Trmač ,
development has been discontinued, as systemd-tmpfiles already 
implements this kind of functionality.


We also already have tmpreaper in the archive which basically does the 
same thing as tmpwatch.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063890: libzydiscore-dev: Static library is missing

[Tim Rühsen]

Package: libzydiscore-dev
Severity: normal
X-Debbugs-Cc: tim.rueh...@gmx.de

Dear Maintainer,

for software development, I need to build static binaries.
Currently, I have to build my own static library.
But it would be way easier to communicate the build steps in Zydis didn't need
an extra recipe on how to build and install the static library.

Please add the static library to the package (libzydis-dev is also affected).

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

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

Bug#1063889: Parse package version string using ‘python3-debian’ class ‘debian.debian_support.Version’

[Ben Finney]

On 14-Feb-2024, Ben Finney wrote:

> The ‘dput.source_check’ function currently uses a custom regex pattern for
> parsing a package version string. This pattern differs in some ways from
> the official Debian Policy definition of a version string.

Thanks to Christoph Berg (‘myon’) for the motivation to report this bug.

-- 
 \   “We jealously reserve the right to be mistaken in our view of |
  `\  what exists, given that theories often change under pressure |
_o__)  from further investigation.” —Thomas W. Clark, 2009 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1024830: ERROR: Unable to connect to servers to test latency.

[Paul Wise]

Control: severity -1 important 

On Fri, 26 Jan 2024 11:46:15 +0100 Yves-Alexis Perez wrote:
> On Sat, 26 Nov 2022 08:35:40 +0100 cuboid_06_wavers wrote:
> >   running speedtest
> > 
> >    * What was the outcome of this action?
> > 
> >   ERROR: Unable to connect to servers to test latency.
> 
> Same thing happens here. As far as I can tell that makes the package pretty
> unusable so I guess the severity could be raised.

I'm not able to reproduce this, speedtest-cli works fine for me,
so lets let it back into testing until it is confirmed really broken.

Could you all paste the output of your speedtests? Mine are below.

Also probably a good idea to try the --secure or --single options.

   $ speedtest-cli
   Retrieving speedtest.net configuration...
   Testing from Optus (49.194.242.10)...
   Retrieving speedtest.net server list...
   Selecting best server based on ping...
   Hosted by Aussie Broadband (Adelaide) [1162.27 km]: 411.184 ms
   Testing download 
speed
   Download: 50.96 Mbit/s
   Testing upload 
speed..
   Upload: 18.01 Mbit/s
   
   $ speedtest-cli
   Retrieving speedtest.net configuration...
   Testing from Optus (49.194.242.10)...
   Retrieving speedtest.net server list...
   Selecting best server based on ping...
   Hosted by Optus (Rockingham) [3294.66 km]: 31.062 ms
   Testing download 
speed
   Download: 50.11 Mbit/s
   Testing upload 
speed..
   Upload: 19.37 Mbit/s
   
   $ speedtest-cli --list
   Retrieving speedtest.net configuration...
   12495) Telstra (Adelaide, Australia) [1162.25 km]
   15135) Aussie Broadband (Adelaide, Australia) [1162.27 km]
   10613) Optus (Rockingham, Australia) [3294.66 km]
   48851) PT. Superspace Teknologi Indonesia (Kupang, Indonesia) [3851.65 km]
   36160) Arsenet Global Solusi (Kupang, Indonesia) [3851.65 km]
   57225) MTM Bali (Mataram, Indonesia) [4556.24 km]
   58325) GMEDIA (Mataram, Indonesia) [4556.24 km]
   59213) ALUSNet (Denpasar, Indonesia) [4623.59 km]
   58275) IPN (Denpasar, Indonesia) [4623.59 km]
   62212) Spicelink Broadband (Denpasar, Indonesia) [4623.59 km]

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1063889: Parse package version string using ‘python3-debian’ class ‘debian.debian_support.Version’

[Ben Finney]

Package: dput
Version: dput
Severity: minor

The ‘dput.source_check’ function currently uses a custom regex pattern for
parsing a package version string. This pattern differs in some ways from
the official Debian Policy definition of a version string.

Instead of custom parsing, re-write the check to use the functionality
provided by the ‘python3-debian’ package. In ‘debian.debian_support’ is a
‘Version’ class whose constructor parses a package version string into the
defined structure of a Debian package version.

This will introduce a “Depends: python3-debian” relationship to this
package.

-- 
 \  “He that would make his own liberty secure must guard even his |
  `\ enemy from oppression.” —Thomas Paine |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1063887: wvstreams: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: wvstreams
Version: 4.6.1-17
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

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

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for wvstreams
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

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.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru wvstreams-4.6.1/debian/changelog wvstreams-4.6.1/debian/changelog
--- wvstreams-4.6.1/debian/changelog2024-02-03 22:43:16.0 +
+++ wvstreams-4.6.1/debian/changelog2024-02-14 05:51:04.0 +
@@ -1,3 +1,13 @@
+wvstreams (4.6.1-17.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+  * Use dh_lintian instead of bespoke debian/rules code to install files;
+their contents are superseedd by the t64 lintian overrides and also
+didn't use the debhelper-standard names for these files
+
+ -- Steve Langasek   Wed, 14 Feb 2024 05:51:04 +
+
 wvstreams (4.6.1-17) unstable; urgency=medium
 
   * QA upload.
diff -Nru wvstreams-4.6.1/debian/control wvstreams-4.6.1/debian/control
--- wvstreams-4.6.1/debian/control  2024-02-03 22:42:59.0 +
+++ wvstreams-4.6.1/debian/control  2024-02-14 05:51:04.0 +
@@ -17,7 +17,11 @@
 Standards-Version: 3.9.8
 Homepage: https://github.com/apenwarr/wvstreams/
 
-Package: libwvstreams4.6-base
+Package: libwvstreams4.6t64-base
+Provides: ${t64:Provides}
+X-Time64-Compat: libwvstreams4.6-base
+Replaces: libwvstreams4.6-base
+Breaks: libwvstreams4.6-base (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends}
@@ -32,7 +36,11 @@
   * WvLog: a log files handler 
   * UniIniGen: a tiny version of UniConf for simple configuration systems
 
-Package: libwvstreams4.6-extras
+Package: libwvstreams4.6t64-extras
+Provides: ${t64:Provides}
+X-Time64-Compat: libwvstreams4.6-extras
+Replaces: libwvstreams4.6-extras
+Breaks: libwvstreams4.6-extras (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends}
@@ -46,7 +54,10 @@
  WvDial, TunnelVision, FastForward, KWvDial, retchmail, and many more yet 
  to come.  ;) 
 
-Package: libuniconf4.6
+Package: libuniconf4.6t64
+Provides: ${t64:Provides}
+Replaces: libuniconf4.6
+Breaks: libuniconf4.6 (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends}
@@ -75,9 +86,9 @@
 Package: libwvstreams-dev
 Architecture: any
 Section: libdevel
-Depends: libwvstreams4.6-base (= ${binary:Version}),
- libwvstreams4.6-extras (= ${binary:Version}),
- libuniconf4.6 (= ${binary:Version}),
+Depends: libwvstreams4.6t64-base (= ${binary:Version}),
+ libwvstreams4.6t64-extras (= ${binary:Version}),
+ libuniconf4.6t64 (= ${binary:Version}),
  libxplc0.3.13-dev,
  ${misc:Depends}
 Suggests: tk8.5 | wish
diff -Nru wvstreams-4.6.1/debian/libuniconf4.6.install 
wvstreams-4.6.1/debian/libuniconf4.6.install
--- wvstreams-4.6.1/debian/libuniconf4.6.install2011-05-19 
22:00:22.0 +
+++ wvstreams-4.6.1/debian/libuniconf4.6.install   

Bug#1063886: bluetooth: does not start w/error: kernel: Bluetooth: hci0: Opcode 0x0402 failed: -22

[JP]

Package: bluetooth
Version: 5.71-1
Severity: important
X-Debbugs-Cc: the_paco...@yahoo.com

Dear Maintainer,

This is on
Bus 002 Device 005: ID 413c:8156 Dell Computer Corp. Wireless 370 Bluetooth
Mini-card
Bus 002 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of
BCM2046 Bluetooth)

HW PROBE info at
https://linux-hardware.org/?probe=6c33cbfd96

Unable to scan bluetooth devices with gui or bluetooth in cli. No errors are
provided except in journal.

Enabled experimental interfaces in /etc/bluetooth/main.conf
no change to kernel error

I'm inexperienced at troubleshooting debian issues/submitting bug reports. Your
guidance and feedback is invaluable and appreciated.


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

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

Versions of packages bluetooth depends on:
ii  bluez  5.66-1+deb12u1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
pn  bluez-cups   
pn  bluez-meshd  
ii  bluez-obexd  5.66-1+deb12u1

-- no debconf information

Bug#1055342: RFA: kas -- Setup tool for bitbake based projects

[MOESSBAUER, Felix]

Hi,

I would be willing to continue the maintenance of this package,
together with the debian python team. I'm quite familiar with this
component, as I contributed a lot to the upstream project.

Currently I have to maintain this via a sponsor, but once I get
advocated to a DM, I can also maintain it directly.

Best regards,
Felix Moessbauer

-- 
Siemens AG, Technology
Linux Expert Center

Bug#1063885: chromium: videos never play in chromium

[Brent]

Package: chromium
Version: 121.0.6167.160-1
Severity: normal
X-Debbugs-Cc: webe...@aim.com

Videos no longer play in chromium.  If I try to play videos on youtube all that
I ever get is the spinning wheel.

I get the following errors when running chromium from the command line.

30609:30609:0213/213301.099512:ERROR:atom_cache.cc(224)] Add _ICC_PROFILE_1 to
kAtomsToCache
[30609:30609:0213/213301.744573:ERROR:policy_logger.cc(156)]
:components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc(161)
Cloud management controller initialization aborted as CBCM is not enabled.
Please use the `--enable-chrome-browser-cloud-management` command line flag to
enable it if you are not using the official Google Chrome build.
[30609:30609:0213/213306.901998:ERROR:object_proxy.cc(576)] Failed to call
method: org.freedesktop.ScreenSaver.GetActive: object_path=
/org/freedesktop/ScreenSaver: org.freedesktop.DBus.Error.NotSupported: This
method is not part of the idle inhibition specification:
https://specifications.freedesktop.org/idle-inhibit-spec/latest/
[30609:30653:0213/213307.056265:ERROR:nss_util.cc(357)] After loading Root
Certs, loaded==false: NSS error code: -8018
[30609:30609:0213/213307.844466:ERROR:interface_endpoint_client.cc(702)]
Message 0 rejected by interface blink.mojom.WidgetHost
[30609:30609:0213/213521.134376:ERROR:atom_cache.cc(224)] Add WM_CHANGE_STATE
to kAtomsToCache



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

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

Versions of packages chromium depends on:
ii  chromium-common  121.0.6167.160-1
ii  libasound2   1.2.10-3
ii  libatk-bridge2.0-0   2.50.0-1+b1
ii  libatk1.0-0  2.50.0-1+b1
ii  libatomic1   14-20240201-3
ii  libatspi2.0-02.50.0-1+b1
ii  libc62.37-15~deb13u1
ii  libcairo21.18.0-1+b1
ii  libcups2 2.4.7-1+b1
ii  libdbus-1-3  1.14.10-4
ii  libdouble-conversion33.3.0-1+b1
ii  libdrm2  2.4.120-2
ii  libevent-2.1-7   2.1.12-stable-8
ii  libexpat12.5.0-2+b2
ii  libflac121.4.3+ds-2+b1
ii  libfontconfig1   2.14.2-6+b1
ii  libfreetype6 2.13.2+dfsg-1+b1
ii  libgbm1  23.3.5-1
ii  libgcc-s114-20240201-3
ii  libglib2.0-0 2.78.3-2
ii  libgtk-3-0   3.24.41-1
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  libjsoncpp25 1.9.5-6+b2
ii  liblcms2-2   2.14-2+b1
ii  libminizip1  1:1.3.dfsg-3+b1
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.96.1-1
ii  libopenh264-71:2.4.1-dmo1
ii  libopenjp2-7 2.5.0-2+b2
ii  libopus0 1.4-1
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpng16-16  1.6.42-1
ii  libpulse016.1+dfsg1-3
ii  libsnappy1v5 1.1.10-1+b1
ii  libstdc++6   14-20240201-3
ii  libwebp7 1.3.2-0.3
ii  libwebpdemux21.3.2-0.3
ii  libwebpmux3  1.3.2-0.3
ii  libwoff1 1.0.2-2+b1
ii  libx11-6 2:1.8.7-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3 

Bug#1063884: RFS: python-autodocsumm/0.2.12-1 [ITP] -- API that automatically extends sphinx (common documentation)

[marcosrcarvalho42]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-autodocsumm":

 * Package name : python-autodocsumm
   Version  : 0.2.12-1
   Upstream contact : Philipp S. Sommer 
 * URL  : https://github.com/Chilipp/autodocsumm
 * License  : Apache-2.0
 * Vcs  : 
https://salsa.debian.org/python-team/packages/python-autodocsum
   Section  : python

The source builds the following binary packages:

  python3-autodocsumm - API that automatically extends sphinx
  python-autodocsumm-doc - API that automatically extends sphinx (common 
documentation)

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

  https://mentors.debian.net/package/python-autodocsumm/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-autodocsumm/python-autodocsumm_0.2.12-1.dsc

Changes for the initial release:

 python-autodocsumm (0.2.12-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1063633)

Regards,

  Marcos Rodrigues de Carvalho (aka oday)

Bug#1063883: rust-regalloc2 - upcoming rust-hashbrown update.

[Peter Green]

Package: rust-regalloc2

Now that rust-ahash 0.8 is in trixie and noble I hope to update
rust-hashbrown and rust-indexmap soon to versions 0.14
and version 2 respectively.

The release of regalloc2 currently in Debian, depends on
hashbrown 0.13 as does the latest upstream release. Upstream
git has upgraded to 0.14, when they did so they decided to make
some changes to the feature settings, setting
"default_features=false" and manually enabling the "ahash"
feature.

https://github.com/bytecodealliance/regalloc2/commit/5d79e12d0a93b10fc181f4da409b4671dd365228

The default features for hashbrown are currently
"ahash", "inline-more" and "allocator-api2" so this amounts
to not enabling the "inline-more" and "allocator-api2"
features.

I have tested that simply relaxing the dependency is enough
to make rust-regalloc2 build with the new hashbrown. The
debdiff I used for testing is attached.diff -Nru rust-regalloc2-0.9.2/debian/changelog 
rust-regalloc2-0.9.2/debian/changelog
--- rust-regalloc2-0.9.2/debian/changelog   2023-09-21 17:38:27.0 
+
+++ rust-regalloc2-0.9.2/debian/changelog   2024-02-14 02:21:52.0 
+
@@ -1,3 +1,10 @@
+rust-regalloc2 (0.9.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump hashbrown to 0.14
+
+ -- Peter Michael Green   Wed, 14 Feb 2024 02:21:52 +
+
 rust-regalloc2 (0.9.2-2) unstable; urgency=medium
 
   * generate documentation during build;
diff -Nru rust-regalloc2-0.9.2/debian/control 
rust-regalloc2-0.9.2/debian/control
--- rust-regalloc2-0.9.2/debian/control 2023-09-21 07:02:26.0 +
+++ rust-regalloc2-0.9.2/debian/control 2024-02-14 02:21:52.0 +
@@ -9,7 +9,7 @@
  librust-bincode-1+default-dev,
  librust-clap-4+default-dev,
  librust-clap-4+derive-dev,
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-log-0.4-dev,
  librust-pretty-env-logger-0.5+default-dev,
  librust-rustc-hash-1-dev,
@@ -30,7 +30,7 @@
 Architecture: all
 Multi-Arch: foreign
 Depends:
- librust-hashbrown-0.12+default-dev,
+ librust-hashbrown-0.14+default-dev,
  librust-log-0.4-dev,
  librust-rustc-hash-1-dev,
  librust-serde-1+alloc-dev,
diff -Nru rust-regalloc2-0.9.2/debian/patches/2002_hashbrown.patch 
rust-regalloc2-0.9.2/debian/patches/2002_hashbrown.patch
--- rust-regalloc2-0.9.2/debian/patches/2002_hashbrown.patch2023-09-19 
17:10:38.0 +
+++ rust-regalloc2-0.9.2/debian/patches/2002_hashbrown.patch2024-02-14 
02:21:23.0 +
@@ -12,7 +12,7 @@
  rustc-hash = { version = "1.1.0", default-features = false }
  slice-group-by = { version = "0.3.0", default-features = false }
 -hashbrown = "0.13.2"
-+hashbrown = ">= 0.12, < 0.14"
++hashbrown = ">= 0.12, < 0.15"
  
  # Optional serde support, enabled by feature below.
  serde = { version = "1.0.136", features = [

Bug#1063321: libwxgtk3.2-1t64 has an undeclared file conflict

[Steve Langasek]

On Fri, Feb 09, 2024 at 11:23:06AM -0500, Scott Talbert wrote:
> On Fri, 9 Feb 2024, Scott Talbert wrote:

> > On Tue, 6 Feb 2024, Helmut Grohne wrote:

> > > Package: libwxgtk3.2-1t64
> > > Version: 3.2.4+dfsg-3.1~exp1
> > > Severity: serious
> > > User: debian...@lists.debian.org
> > > Usertags: fileconflict
> > > Control: affects -1 + libwxgtk-gl3.2-1 libwxgtk-gl3.2-1t64
> > > libwxgtk-media3.2-1 libwxgtk-media3.2-1t64 libwxgtk-webview3.2-1
> > > libwxgtk-webview3.2-1t64
> > > X-Debbugs-Cc: vor...@debian.org

> > > libwxgtk3.2-1t64 has an undeclared file conflict. This may result in an
> > > unpack error from dpkg.

> > Hello Steve,

> > Are you planning on fixing this, or would you like me to?  If the
> > latter, how would you like the fix submitted before this is uploaded to
> > unstable?

This is in my queue to fix up.  It will be uploaded to experimental, and a
comprehensive patch attached to the original bug.

> Sending to your vor...@dodds.net as your mail server rejected the mail sent
> through debian.org with some sort of SPF error.  Probably something the
> debian server is doing?

Apologies, this was a misconfiguration on the side of my mailserver for
trying to enforce SPF on messages from a known relay.  I hadn't been doing
enough email before now, since enabling SPF, to have noticed it was a
problem.

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


signature.asc
Description: PGP signature

Bug#1062700: smplayer: Cannot resume playback from pause with mpv 0.37.0

[Gregor Riepl]

Hi,


After upgrading mpv to 0.37.0, resuming the paused video by clicking the UI
"play" button nor pressing the space key works -> nothing happens. With mpv <=
0.36.0, resuming works normally.

The workaround is to move video forward/backward 10 seconds (left/right key)
first. After that, resuming works again.


This is most likely upstream bug 
https://github.com/smplayer-dev/smplayer/issues/837


It should be fixed in smplayer 23.6.0.10190, or by adding the patch 
https://github.com/smplayer-dev/smplayer/commit/74690b30a816aa4644be4f83ffca096441713645


Regards,
oni

Bug#1057093: php-imagick's autopkg tests fail

[Sunil Mohan Adapa]

autopkg test on sid has succeed for me. Latest ci.debian.org test 
results show that the tests all pass.


Looks like this bug should be closed to allow the package to transition 
to testing.


--
Sunil


OpenPGP_0x36C361440C9BC971.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053665: libavif mismatch?

[Shmerl]

I see that during the build the package is installed, but it's somehow not
compatible?
Does KDE expect an older version or it's cmake not doing it right?

Does it need an upstream bug report or may be Plasma 6 is handling this
better?

See:
https://buildd.debian.org/status/fetch.php?pkg=kimageformats=amd64=5.107.0-3.1=1698015010=0

Regards,
Shmerl.

CMake Warning at CMakeLists.txt:54 (find_package):
  Could not find a configuration file for package "libavif" that is
  compatible with requested version "0.8.2".

  The following configuration files were considered but not accepted:

/usr/lib/x86_64-linux-gnu/cmake/libavif/libavif-config.cmake, version: 1.0.1
/lib/x86_64-linux-gnu/cmake/libavif/libavif-config.cmake, version: 1.0.1

Bug#1063601: tailspin: FTBFS: error[E0407]: method `backtrace` is not a member of trait `Error`

[Peter Green]

reassign 1063601 tailspin 3.0.0+dfsg-1
retitle 1063601 tailspin FTBFS error: environment variable `CARGO_CHANNEL` not 
defined at compile time
thanks

>> [eyre 0.6.8] error[E0407]: method `backtrace` is not a member of trait 
`Error`
>> [eyre 0.6.8]   --> 
/<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:19:9

The above seems like a failure not in tailspin but in librust-eyre-dev.


I don't think the errors Sebastian quoted are the cause of the build failure
at all. I think they are just noise from a test compilation performed to
determine what the compiler supports. Those same errors are present
in the successful build log for tailspin 2.0.0

The actual error seems to be.


error: environment variable `CARGO_CHANNEL` not defined at compile time
  --> tests/utils.rs:11:48
   |
11 | PathBuf::from(format!("./target/{}/tspin", env!("CARGO_CHANNEL")))
   |^
   |
   = help: Cargo sets build script variables at run time. Use 
`std::env::var("CARGO_CHANNEL")` instead
   = note: this error originates in the macro `env` (in Nightly builds, run 
with -Z macro-backtrace for more info)


I also notice the following earlier in the build log.


"debian cargo wrapper: WARNING: falling back to simply calling upstream cargo, 
because CARGO_HOME does not end with debian/cargo_home:"


This message appears in the failed logs for 3.0.0 but not in the succesful logs
for 2.0.0.

After serching for CARGO_CHANNEL I think may be the actual cause of the failure.
All the results on codesearch.debian.net for CARGO_CHANNEL seem to relate to 
dh_cargo
or your fork thereof. So I think these are probablly related.

Bug#1063881: nvidia-graphics-drivers: provide dependency package to catch all packages of given version

[Drew Parsons]

Source: nvidia-graphics-drivers
Version: 525.147.05-6
Severity: normal

>From time to time the version of nvidia-driver in experimental is far
ahead of the current version in unstable.  It's often desirable to
install it to see if the new version fixes particular problems.

The problem is that there are many different packages generated for
nvidia-graphics-drivers.  Ideally the same version would want to be
installed for all of them, including the cuda or opencl components.
This means to upgrade to the new version in experimental, one has to
individually select every single nvidia component.  There's more than
20 of them, it's a bit of effort.

Conversely, if the experimental version becomes stale, it does not get
automatically updated.  One might need to step back to the nvidia
version in unstable if the experimental version no longer confirms to
package standards, or to get automatic updating going forward.  Or
there might be a new version in experimental, which is not
automatically updated.  Either way, one again has to select every
single component package and mark it explicitly for downgrade or
upgrade.

It would be much easier to switch between versions in unstable and
experimental, or upgrade from experimental, if there were a dummy
dependency package that depends on all the manifold nvidia component
packages for the given version.  It could be called nvidia-driver-all,
for instance.  Then only the one package needs to be marked for
upgrade (or downgrade) and will bring in all the others.

Can it be done?

Bug#1063771: Please update to version 42, needed for new dnspython

[Scott Kitterman]

On Tue, 13 Feb 2024 10:16:23 +0100 Jérémy Lal  wrote:
> Will do, but right now there are a bunch of rust dependencies that need to
> be upgraded.

Thanks,

Scott K

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

Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them

[Peter Hyman]

They appear to be very similar. The code base is completely different.

I'll review the tmpreaper program closely and close this ITP if there is 
functional duplication.


Thank you for pointing this out.

On 2/13/24 16:39, gregor herrmann wrote:

On Tue, 13 Feb 2024 16:21:46 -0600, Peter Hyman wrote:


* Package name : tmpwatch
Description : tmpwatch is a utility searches for files not accessed in a
specific time and deletes them

The tmpwatch utility recursively searches through specified directories and
removes files which have not been accessed in a specified period of time.
tmpwatch is normally used to clean up directories which are used for
temporarily holding files (for example, /tmp).

This sounds very much like tmpreaper:

Description-en: cleans up files in directories based on their age
  This package provides a program that can be used to clean out temporary-file
  directories.  It recursively searches the directory, refusing to chdir()
  across symlinks, and removes files that haven't been accessed in a
  user-specified amount of time.  You can specify a set of files to protect
  from deletion with a shell pattern.  It will not remove files owned by the
  process EUID that have the `w' bit clear, unless you ask it to, much like
  `rm -f'.  `tmpreaper' will not remove symlinks, sockets, fifos, or special
  files unless given a command line option enabling it to.
  .
  WARNING:  Please do not run `tmpreaper' on `/'.  There are no protections
  against this written into the program, as that would prevent it from
  functioning the way you'd expect it to in a `chroot(8)' environment.
  .
  The daily tmpreaper run can be configured through /etc/tmpreaper.conf .


Could you maybe say a bit about the differences?
  


Cheers,
gregor


--
Peter Hyman

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

[Francesco Poli]

Control: notfixed 1061636 sbuild/0.85.5


On Mon, 12 Feb 2024 23:19:40 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Francesco Poli (2024-02-12 22:46:29)
[...]
> > 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.

Yes, he has just done so, but he apparently closed the original bug
report (which was against mmdebstrap and was already closed), rather
than the cloned bug report.

The above control commands should rectify the situation for the
original bug report, if I am not mistaken...

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


pgpsS9xwNplsC.pgp
Description: PGP signature

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Sam Hartman]

> "Ansgar" == Ansgar   writes:


Ansgar> As far as I understand this approach will break any consumer
Ansgar> on a library whose ABI changes to to the ABI changes
Ansgar> introduced here unless the consumer is built with the flags
Ansgar> from `dpkg-buildflags` (which would now define the ABI).

Ansgar> Do we want this?

I'm fairly sure we do not.  Elsewhere in the thread, I saw one of the
toolchain maintainers talking about what is involved in getting gcc to
support the new flags.  My suspicion is that handling things with
dpkg-flags is more about moving quickly with the transition than a
desired end state.

Personally I'd consider it a release blocker if we don't get the
compilers updated prior to the release.

I think it would be reasonable to open a bug on the toolchain packages
now talking about this.
I think logistically it would not be desirable for those bugs to be RC
at this time.
Yes, if not fixed they will eventually need to be, but for example I
don't think it would be desirable to block toolchain testing migrations
on this issue at this time.  And obviously we're not going to remove the
toolchain from the release.

--Sam
Speaking with my armchair I have no hat in this non-hat on.

Bug#1039607: libjansi-java: causes maven to always output escape character

[tony mancill]

On Sat, Jan 13, 2024 at 05:46:58PM -0800, tony mancill wrote:
> > > Feedback welcome.  We can coordinate here before any migrations from
> > > experimental to unstable.
> > 
> > Thank you for the fix. To test we created a chroot environment with the
> > following upgrades:
> > 
> > apt install libjansi-java/experimental
> > apt install maven/experimental libmaven3-core-java/experimental 
> > libcommons-cli-java/unstable libcommons-lang3-java/unstable
> > 
> > The issue reported in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059147 as well as our
> > original issue are resolved.
> 
> Thank you for your testing.
> 
> Are there any concerns before I upload maven and jansi to unstable?  We
> can always revisit the changes if we discover any issues.

I have uploaded maven_3.8.7-2 to unstable.  Once it is in the archive
and made it out to the mirrors, I will upload jansi.



signature.asc
Description: PGP signature

Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them

[gregor herrmann]

On Tue, 13 Feb 2024 16:21:46 -0600, Peter Hyman wrote:

> * Package name : tmpwatch

> Description : tmpwatch is a utility searches for files not accessed in a
> specific time and deletes them
> 
> The tmpwatch utility recursively searches through specified directories and
> removes files which have not been accessed in a specified period of time.
> tmpwatch is normally used to clean up directories which are used for
> temporarily holding files (for example, /tmp).

This sounds very much like tmpreaper:

Description-en: cleans up files in directories based on their age
 This package provides a program that can be used to clean out temporary-file
 directories.  It recursively searches the directory, refusing to chdir()
 across symlinks, and removes files that haven't been accessed in a
 user-specified amount of time.  You can specify a set of files to protect
 from deletion with a shell pattern.  It will not remove files owned by the
 process EUID that have the `w' bit clear, unless you ask it to, much like
 `rm -f'.  `tmpreaper' will not remove symlinks, sockets, fifos, or special
 files unless given a command line option enabling it to.
 .
 WARNING:  Please do not run `tmpreaper' on `/'.  There are no protections
 against this written into the program, as that would prevent it from
 functioning the way you'd expect it to in a `chroot(8)' environment.
 .
 The daily tmpreaper run can be configured through /etc/tmpreaper.conf .


Could you maybe say a bit about the differences?
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1063752: custodian: Inappriate maintainer address

[Nicholas Breen]

Might this have been a one-time glitch?  The list receives mail from
the ftpmaster role address routinely, before and after the bug report:
https://alioth-lists.debian.net/pipermail/debichem-devel/2024-February/author.html#16139

If there are no other reported incidents, I'd suggest closing the bug.



-- 
Nicholas Breen
nbr...@debian.org

Bug#987124: console-setup not work properly with plymouth

[Vladimir K]

A bit more refined variant without ps:

--- a/lib/console-setup/console-setup.sh   2024-02-09 17:45:38.0 +0300  

+++ b/lib/console-setup/console-setup.sh 2024-02-14 01:15:24.413177808 +0300
  
@@ -16,6 +16,16 @@
   -nt /etc/default/keyboard ] || do_configure=yes
 [ /etc/console-setup/cached_setup_terminal.sh \
   -nt /etc/default/console-setup ] || do_configure=yes
+
+# if plymouth-exit.service was launched, this means
+# plymouth released tty1 for us to fix
+if [ -r /proc/1/comm ] &&
+  [ "$(read -r INIT < /proc/1/comm ; echo "$INIT")" = "systemd" ] 
&&
+  command -v systemctl >/dev/null &&
+  systemctl is-active -q plymouth-quit.service
+then
+  do_configure=yes
+fi
 ;;
 esac

Bug#683774: First time font packager questions

[Soren Stoutner]

On Tuesday, February 13, 2024 3:17:00 PM MST Boyuan Yang wrote:
> Welcome down to the rabbit hole. I believe the AFDKO issue is likely the
> most important one. As far as I can tell it is blocked by
> https://lists.debian.org/debian-fonts/2021/07/msg9.html , after which
> no progress was made. If you could help, that would be really helpful and
> unblock the packaging of a vast amount of different fonts.

Boyuan,

That is indeed a rabbit hole.

Yao Wei,

I would be interested in co-maintaining the AFDKO package with you if you would 
like.  
Specifically, I would like to address the two bug reports at:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=afdko[1]

As well as looking into the problem you described at:

https://lists.debian.org/debian-fonts/2021/07/msg9.html

If you are amenable to that I can prepare MRs on Salsa and submit them to you.

-- 
Soren Stoutner
so...@debian.org


[1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=afdko


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

Bug#1063880: ITP: tmpwatch -- tmpwatch is a utility searches for files not accessed in a specific time and deletes them

[Peter Hyman]

Package: wnpp
Severity: wishlist
Owner: Peter Hyman 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name : tmpwatch
Version : 2.12
* Upstream Contact: Peter Hyman 
URL : https://github.com/pete4abw/tmpwatch
* License : GPL
Programming Lang: C
Description : tmpwatch is a utility searches for files not accessed in a
specific time and deletes them

The tmpwatch utility recursively searches through specified directories and
removes files which have not been accessed in a specified period of time.
tmpwatch is normally used to clean up directories which are used for
temporarily holding files (for example, /tmp).

- While Debian removes files in the /tmp directory, other files may have
temporary files that needs to be cleaned periodically. tmpwatch is 
ideally used

as a cron-job.
- how do you plan to maintain it?
tmpwatch has not had any activity for over 5 years. Originally written by
Erik Troan , Preston Brown , Mike A. 
Harris
, Miloslav Trmač , I have forked 
off and

added some enhancements.

However, packaging for Debian has been challenging since the autogen I wrote
fetches a submodule which creates lots of files not in the source package. I
would need a mentor to help me get this off the ground.

Original project URL is at the Fedora project page: 
https://pagure.io/tmpwatch


--
Peter Hyman

Bug#1063879: linux-image-6.1.0-18-amd64: nvidia-drivers 525.147.05 do not compile against linux-image 6.1.0-18

[Peter Hyman]

Package: src:linux
Version: 6.1.76-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)


Dear Maintainer,

Upgrading from linux-image 6.1.0-17 to 6.1.0-18 fails to complete due to 
nvidia

compile error.

ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'__rcu_read_lock'
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol
'__rcu_read_unlock'

* What led up to the situation?
routine kernel upgrade using meta package linux-image-amd64
* What exactly did you do (or not do) that was effective (or
ineffective)?
used synaptic. Also attempted on commandline
$ apt install linux-image-amd64
* What was the outcome of this action?
Cleaning build area...
env NV_VERBOSE=1 make -j8 modules
KERNEL_UNAME=6.1.0-18-amd64..(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.1.0-18-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more
information.
Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
...
dpkg: error processing package linux-image-amd64 (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-image-6.1.0-18-amd64
linux-headers-6.1.0-18-amd64
linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
* What outcome did you expect instead?
kernel upgraded


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

** Model information
sys_vendor: HP
product_name: HP Pavilion Laptop 15-cs3xxx
product_version: Type1ProductConfigId
chassis_vendor: HP
chassis_version: Chassis Version
bios_vendor: Insyde
bios_version: F.21
board_vendor: HP
board_name: 86E2
board_version: 95.36

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Ice Lake-LP Processor Host 
Bridge/DRAM Registers [8086:8a12] (rev 03)
Subsystem: Hewlett-Packard Company Ice Lake-LP Processor Host 
Bridge/DRAM Registers [103c:86e2]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0
IOMMU group: 1
Capabilities: 
Kernel driver in use: icl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Plus 
Graphics G7 [8086:8a52] (rev 07) (prog-if 00 [VGA controller])

Subsystem: Hewlett-Packard Company Iris Plus Graphics G7 [103c:86e2]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 139
IOMMU group: 0
Region 0: Memory at 601600 (64-bit, non-prefetchable) [size=16M]
Region 2: Memory at 40 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 8000 [size=64]
Expansion ROM at 000c [virtual] [disabled] [size=128K]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Processor 
Power and Thermal Controller [8086:8a03] (rev 03)
Subsystem: Hewlett-Packard Company Processor Power and Thermal 
Controller [103c:86e2]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0
Interrupt: pin A routed to IRQ 16
IOMMU group: 2
Region 0: Memory at 601710 (64-bit, non-prefetchable) [size=64K]
Capabilities: 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy

00:14.0 USB controller [0c03]: Intel Corporation Ice Lake-LP USB 3.1 
xHCI Host Controller [8086:34ed] (rev 30) (prog-if 30 [XHCI])
Subsystem: Hewlett-Packard Company Ice Lake-LP USB 3.1 xHCI Host 
Controller [103c:86e2]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 0
Interrupt: pin A routed to IRQ 127
IOMMU group: 3
Region 0: Memory at 5600 (64-bit, non-prefetchable) [size=64K]
Capabilities: 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:14.2 RAM memory [0500]: Intel Corporation Ice Lake-LP DRAM Controller 
[8086:34ef] (rev 30)

Subsystem: Hewlett-Packard Company Ice Lake-LP DRAM Controller [103c:86e2]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Latency: 0, Cache Line Size: 64 bytes
IOMMU group: 3
Region 0: Memory at 6017118000 (64-bit, non-prefetchable) [size=8K]
Region 2: Memory at 601712 (64-bit, non-prefetchable) [size=4K]
Capabilities: 

00:14.3 Network controller [0280]: Intel Corporation Ice Lake-LP PCH 
CNVi WiFi [8086:34f0] (rev 30)

DeviceName: Intel Wireless-WiFi 6 AX201 Dual Band 2x2 WiFi + BT 5
Subsystem: Intel 

Bug#683774: RFP: fonts-source-sans -- set of OpenType fonts designed for user interfaces

[Soren Stoutner]

Control: retitle -1 ITP: fonts-adobe-sourcesans3 -- set of OpenType fonts that 
have been designed to work well in user interface (UI) environments
Control: owner -1 !
Control: tags -1 + ITP

I would like to package these fonts as one of them is used by the Electrum 
package, which I maintain.  My intention is to join to fonts group and maintain 
this package going forward.

It should be noted that in 2020 the upstream author renamed the font from 
Source Sans Pro to Source Sans 3.

https://github.com/adobe-fonts/source-sans/issues/192[1]

Based on that, candidate names for the source package are:

fonts-adobe-sourcesans3
fonts-adobe-source-sans3
fonts-adobe-source-sans-3

Does anyone have a strong preference as to which is used?

-- 
Soren Stoutner
so...@debian.org


[1] https://github.com/adobe-fonts/source-sans/issues/192


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

Bug#1060256: Please enable the Rust parts

[Steinar H. Gunderson]

On Tue, Feb 06, 2024 at 11:55:55AM +0200, Faidon Liambotis wrote:
>> Still required.
> I uploaded that last week, currently sitting in NEW.

Now that this is through NEW, I uploaded an NMU to DELAYED/7-day.
I see that this package is in LowThresholdNmu, but given that it
adds an epoch, I'm giving everyone a week to speak up if they feel
this is wrong :-)

The package can be found at

  https://storage.sesse.net/bcachefs-tools/

and the git repository I built from at

  https://git.sesse.net/?p=bcachefs-tools-debian

I used (with upstream being github.com/koverstreet/bcachefs-tools)

  gbp buildpackage --git-upstream-tree=upstream/master

and then built with pbuilder. I've tested that this works fine with bcachefs
as root device on my workstation (which also has some patches for multi-device
root; see #1060256).

Thanks to Faidon for paving the way here :-)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

[Helmut Grohne]

Package: di-utils
Version: 1.148
User: helm...@debian.org
Usertags: dep17p3
Control: affects -1 + dpkg
Tags: patch
Forwarded: 
https://salsa.debian.org/installer-team/debian-installer-utils/-/merge_requests/11
X-Debbugs-Cc: b...@debian.org, f...@debian.org

Hi,

Raphael kindly pointed me at this Kali Linux bug report:
https://bugs.kali.org/view.php?id=8628
In there, we can see (among other things):

| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename
| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename
| Feb 8 22:06:02 main-menu[1596]: (process:31692): dpkg-divert: warning: 
diverting file '/sbin/start-stop-daemon' from an Essential package with rename 
is dangerous, use --no-rename

Due to this harmless warning, we learn that /sbin/start-stop-daemon is
being diverted, but dpkg now installs it as /usr/sbin/start-stop-daemon.
We are effectively faced with what DEP17 P3 calls an ineffective
diversion. We later see:

| Feb 8 22:07:08 grub-installer: dpkg: warning: 'start-stop-daemon' not found 
in PATH or not executable
| Feb 8 22:07:08 grub-installer: dpkg: error: 1 expected program not found in 
PATH or not executable
| Feb 8 22:07:08 grub-installer: Note: root's PATH should usually contain 
/usr/local/sbin, /u
| Feb 8 22:07:08 grub-installer: sr/sbin and /sbin

Raphael kindly pointed at chroot-setup.sh from di-utils. There
/sbin/start-stop-daemon is diverted with --rename. Since it is installed
as /usr/sbin/start-stop-daemon, this diversion (and its rename) does not
take any effect. When it is undiverted, the /sbin/start-stop-daemon (and
since the chroot is /usr-merged also /usr/sbin/start-stop-daemon) is
deleted and then undiverted with --rename, but there is no
/sbin/start-stop-daemon.REAL, because that diversion ended up being
ineffective. Therefore, nothing is moved back and we lost
/sbin/start-stop-daemon (and /usr/sbin-start-stop-daemon).

I've prepared a patch that duplicates diversions as needed and filed it
in the linked merge request on salsa. I've attempted testing this, but
debian-installer still FTBFS in unstable. Holger told me that Fil and
openqa.debian.net would be somehow able to test MRs on salsa. Fil, can
you help here?

I also see that https://openqa.debian.net/ has recent successes. dpkg
migrated to trixie about two weeks ago. I would have expected that this
breaks an d-i. Do you have an explanation for why jobs still pass?

Raphael, can you link this bug to the Kali bug?

Helmut

Bug#1063877: squid FTCBFS: fails detecting kerberos due to AC_RUN_IFELSE

[Helmut Grohne]

Source: squid
Version: 6.1-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

squid fails to cross build from source, because it pessimistically uses
AC_RUN_IFELSE, therefore concludes that kerberos is unavailable and then
causes a compiler error due to an untested code path. I've reviewed the
uses of AC_RUN_IFELSE and a number of them do not actually benefit from
running code (while others do). I'm attaching a patch that converts some
of the AC_RUN_IFELSE to AC_LINK_IFELSE and these happen to be enough to
make squid cross buildable (though the cross build still turns of some
features compared to a native build unless one provides more cache
variables externally). What do you think about the attached conversion?

Helmut
--- squid-6.6.orig/acinclude/krb5.m4
+++ squid-6.6/acinclude/krb5.m4
@@ -33,7 +33,7 @@
   AC_CACHE_CHECK([for broken Heimdal krb5.h],squid_cv_broken_heimdal_krb5_h, [
 SQUID_STATE_SAVE(squid_krb5_heimdal_test)
 CPPFLAGS="-I${srcdir:-.} $CPPFLAGS"
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #include 
 int
 main(void)
@@ -45,7 +45,7 @@
 return 0;
 }
 ]])], [ squid_cv_broken_heimdal_krb5_h=no ], [
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #define HAVE_BROKEN_HEIMDAL_KRB5_H  1
 #include "compat/krb5.h"
 int
@@ -130,7 +130,7 @@
 dnl checks that gssapi is ok, and sets squid_cv_working_gssapi accordingly
 AC_DEFUN([SQUID_CHECK_WORKING_GSSAPI], [
   AC_CACHE_CHECK([for working gssapi], squid_cv_working_gssapi, [
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #if USE_HEIMDAL_KRB5
 #if HAVE_GSSAPI_GSSAPI_H
 #include 
@@ -231,7 +231,7 @@
   AC_CACHE_CHECK([for working krb5], squid_cv_working_krb5, [
 SQUID_STATE_SAVE(squid_krb5_test)
 CPPFLAGS="-I${srcdir:-.} $CPPFLAGS"
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_LINK_IFELSE([AC_LANG_SOURCE([[
 #include "compat/krb5.h"
 int
 main(void)

Bug#1063876: xfsdump: move files from / to /usr (DEP17)

[Helmut Grohne]

Package: xfsdump
Version: 3.1.11-0.1
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to move aliased files from / to /usr to finalize the /usr-merge
transition via DEP17. After moving, we get rid of negative effects of
aliasing. xfsdump is involved, because it installs two utils to aliased
locations. I am sending a patch, because xfsdump cannot be automatically
converted using dh-sequence-movetousr. Note that this patch must not be
uploaded to bookworm-backports or earlier as it would violate the file
move moratorium there.

Helmut
diff --minimal -Nru xfsdump-3.1.11/debian/changelog 
xfsdump-3.1.11/debian/changelog
--- xfsdump-3.1.11/debian/changelog 2022-10-16 21:44:56.0 +0200
+++ xfsdump-3.1.11/debian/changelog 2024-02-13 14:12:03.0 +0100
@@ -1,3 +1,10 @@
+xfsdump (3.1.11-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move aliased xfs tools to /usr (DEP17). (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 13 Feb 2024 14:12:03 +0100
+
 xfsdump (3.1.11-0.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff --minimal -Nru xfsdump-3.1.11/debian/rules xfsdump-3.1.11/debian/rules
--- xfsdump-3.1.11/debian/rules 2022-10-16 21:44:56.0 +0200
+++ xfsdump-3.1.11/debian/rules 2024-02-13 14:12:03.0 +0100
@@ -27,7 +27,7 @@
@echo "== dpkg-buildpackage: configure" 1>&2
$(checkdir)
dh_autotools-dev_updateconfig
-   $(options) $(MAKE) include/config.h
+   $(options) $(MAKE) include/config.h 
LOCAL_CONFIGURE_OPTIONS='--exec-prefix=/nondefault --sbindir=/usr/sbin'
touch .census
 
 clean:

Bug#1062057: updated analysis results (ABI is unaffected)

[Adrien Nader]

Hi,

I just ran the analysis again: the ABI was dumped without requiring
any quirk. After diff, the result is that the ABI is not affected by
either time_t or LFS. :) 

I don't publish results after every update as that would be overwhelming
but I should do so by friday evening.

-- 
Adrien

Bug#1063875: mkdocs-material: Missing library dependency "paginate"

[Boyuan Yang]

Package: mkdocs-material
Version: 9.4.0-1
Severity: important

Dear Debian mkdocs-material maintainer,

Package "paginate" exists in requirements.txt and source code,
however current Debian package does not depends on this package.
It is not packaged in Debian yet.

Thanks,
Boyuan Yang


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

Bug#1063874: m2crypto: Testsuite fails with OpenSSL 3.2

[Sebastian Andrzej Siewior]

Package: m2crypto
Version: 0.40.1-1
Severity: important
Tags: sid patch
control: affects -1 src:openssl
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-3.2

OpenSSL had an optimisation for PKCS7_verify() where it kept the memory
BIO around. This optimisation is gone in OpenSSL 3.2 and so the test for
verify fails because the memory BIO "ended".

The attached patch fixes the issue.

Sebastian
>From 08308043d7ce8bb645996c8cb29655a23ead43a4 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Tue, 13 Feb 2024 17:47:22 +0100
Subject: [PATCH] test/smime: Rewind BIO before repeadetly invoking verify.

OpenSSL had an optimisation for PKCS7_verify() where it kept the memory
BIO around. This optimisation is gone in OpenSSL 3.2 and so the test for
verify fails because the memory BIO "ended".

Rewind the BIO before invoking verify again on the same data.

Signed-off-by: Sebastian Andrzej Siewior 
---
 tests/test_smime.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/test_smime.py b/tests/test_smime.py
index 6014315353824..1fe7e954fcb89 100644
--- a/tests/test_smime.py
+++ b/tests/test_smime.py
@@ -162,10 +162,12 @@ from tests import unittest
 with self.assertRaises(SMIME.PKCS7_Error):
 s.verify(p7, data)
 
+data.seek(0)
 st.set_verify_cb(verify_cb_dummy_function)
 v = s.verify(p7, data)
 self.assertEqual(v, self.cleartext)
 
+data.seek(0)
 st.set_verify_cb()
 v = s.verify(p7, data)
 self.assertEqual(v, self.cleartext)
-- 
2.43.0

Bug#1061009: winff: FTBFS: make[1]: *** [debian/rules:16: override_dh_auto_build-arch] Error 2

[Abou Al Montacir]

Control: found -1 3.0+dfsg1-5
Control: notfound -1 3.0+dfsg1-4

-- 
Cheers,
Abou Al Montacir


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

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

[Abou Al Montacir]

Control: found -1 3.0+dfsg1-5
Control: notfound -1 3.0+dfsg1-4

-- 
Cheers,
Abou Al Montacir


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

Bug#1063873: Building a reverse dependency of the guava-testlib artifact fails

[Pierre Gruet]

Source: guava-libraries
Version: 32.0.1-1
Severity: important

Dear Maintainer,

When one tries to use the com.google.guava:guava-testlib:debian artifact in a
Maven pom.xml file, during the build one gets the error

[ERROR] Failed to execute goal on project myProject: Could not resolve 
dependencies for project myGroup:myProject:jar:myVersion: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
com.google.guava:guava:bundle:debian has not been downloaded from it before. -> 
[Help 1]

because the pom of guava-testlib looks for com.google.guava:guava with the
"bundle" type. I trust we should ship com.google.guava:guava with the "jar"
packaging type instead of "bundle", this is more accurate and compliant with
Debian-Java practices.

For instance I believe the enclosed patch allows one to package guava-libraries
with "jar" artifacts instead of "bundle". Yet I did not try to build the rdeps.

Best,

-- 
Pierre
--- a/guava-testlib/pom.xml
+++ b/guava-testlib/pom.xml
@@ -34,7 +34,6 @@
   ${project.groupId}
   guava
   ${project.version}
-  bundle
 
 
   junit
--- a/guava/pom.xml
+++ b/guava/pom.xml
@@ -8,7 +8,7 @@
 32.0.1-jre
   
   guava
-  bundle
+  jar
   Guava: Google Core Libraries for Java
   https://github.com/google/guava
   

Bug#1052129: acpica-unix: Failed to migrate to Testing; missing s390x build not properly handled

[Boyuan Yang]

notfound 1052129 20230628-1
tags 1052129 - sid
close 1052129
thanks

Obviously the Testing migration is fixed. Now closing this bug accordingly.

Thanks,
Boyuan Yang


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

Bug#1063872: RM: prayer -- RoQA; Dead Upstream; Unmaintained; Incompatible with Tidy 5.8

[Boyuan Yang]

Package: ftp.debian.org
Control: affects -1 + src:prayer
X-Debbugs-Cc: pra...@packages.debian.org holmg...@debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
Severity: normal

Dear Debian FTP Masters,

Please remove package prayer ( https://tracker.debian.org/pkg/prayer )
from Debian archive.

As discussed in https://bugs.debian.org/1010066 , its upstream has been dead
since 201x, and it is incompatible with the upcoming tidy-html5 5.8.x. In 2022,
the Debian package maintainer (in CC list) states that it is not used anymore
and unmaintained since then. It missed the last Debian stable release. Package
prayer also has a low popcon value (< 10).

Thanks,
Boyuan Yang


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

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Ansgar]

On Sat, 6 Jan 2024 19:38:42 -0800 Steve Langasek wrote:
> - dpkg will be uploaded to experimental with 64-bit time_t in the
default
>   flags

As far as I understand this approach will break any consumer on a
library whose ABI changes to to the ABI changes introduced here unless
the consumer is built with the flags from `dpkg-buildflags` (which
would now define the ABI).

In particular users could no longer just invoke `gcc` alone, but would
have to also rely on `dpkg-buildflags` for any software they built on
their own using runtime libraries shipped by Debian. It would work in
some cases (multi-ABI libraries like libc6 or libraries not affected by
the ABI change), but it is not reliable.

Do we want this? It must at least be documented, probably in Debian
Policy and GCC.

This was asked on debian-devel@ multiple times, but there was no answer
so far.

Ansgar

Bug#1063871: ITP: r-cran-areal -- GNU R areal weighted interpolation

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-areal -- GNU R areal weighted interpolation
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-areal
  Version : 0.1.8
  Upstream Author : Christopher Prener,
* URL : https://cran.r-project.org/package=areal
* License : GPL-3
  Programming Lang: GNU R
  Description : GNU R areal weighted interpolation
 A pipeable, transparent implementation of areal weighted interpolation
 with support for interpolating multiple variables in a single function call.
 These tools provide a full-featured workflow for validation and estimation
 that fits into both modern data management (e.g. tidyverse) and spatial
 data (e.g. sf) frameworks.

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

Bug#1063870: fail2ban: upgrade warning: SyntaxWarning: invalid escape sequence

[Paul Gevers]

Package: fail2ban
Version: 1.0.2-3
Severity: important

During an upgrade of fail2ban I noticed this in the apt output:

Setting up fail2ban (1.0.2-3) ...
Installing new version of config file 
/etc/fail2ban/jail.d/defaults-debian.conf ...
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:224: 
SyntaxWarning: invalid escape sequence '\s'  "1490349000 test 
failed.dns.ch", "^\s*test \S+"
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:435: 
SyntaxWarning: invalid escape sequence '\S'   '^'+prefix+'User 
\S+ not allowed\n'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:443: 
SyntaxWarning: invalid escape sequence '\S'   '^'+prefix+'User 
\S+ not allowed\n'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:444: 
SyntaxWarning: invalid escape sequence '\d'   '^'+prefix+'Received 
disconnect from  port \d+'
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:451: 
SyntaxWarning: invalid escape sequence '\s'   _test_variants('common', 
prefix="\s*\S+ sshd\[\d+\]:\s+")
/usr/lib/python3/dist-packages/fail2ban/tests/fail2banregextestcase.py:537: 
SyntaxWarning: invalid escape sequence '\[' 
'common[prefregex="^svc\[\d+\] connect 
.+$"'
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1375: 
SyntaxWarning: invalid escape sequence '\s'   "`{ nft -a list chain inet 
f2b-table f2b-chain | grep -oP 
'@addr-set-j-w-nft-mp\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; 
do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1378: 
SyntaxWarning: invalid escape sequence '\s'
   "`{ nft -a list chain inet f2b-table f2b-chain | grep -oP 
'@addr6-set-j-w-nft-mp\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; 
do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1421: 
SyntaxWarning: invalid escape sequence '\s'
   "`{ nft -a list chain inet f2b-table f2b-chain | grep -oP 
'@addr-set-j-w-nft-ap\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; 
do`",
/usr/lib/python3/dist-packages/fail2ban/tests/servertestcase.py:1424: 
SyntaxWarning: invalid escape sequence '\s'   "`{ nft -a list chain inet 
f2b-table f2b-chain | grep -oP 
'@addr6-set-j-w-nft-ap\s+.*\s+\Khandle\s+(\d+)$'; } | while read -r hdl; 
do`",


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1026381: python-django-health-check: please make the build reproducible

[James Addison]

Followup-For: Bug #1026381
X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org
Control: block -1 1057432
Control: close -1

Based on recent reproducible build testing history[1] of this package, and for
Debian versions after the fix for #1057432 became available (excludes both
bookworm, and builds prior to 2023-12-04 or so), I'm confident that the package
is building reproducibly, so I think we can close this.

Adding a bug-blocker relationship for historical tracking purposes and closing
this bug.

[1] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django-health-check.html

Bug#1063869: pytest-cookies: Please package new upstream release 0.7.0

[Boyuan Yang]

Source: pytest-cookies
Version: 0.4.0-2
Tags: sid trixie
Control: block -1 by 1040040
Severity: normal
X-Debbugs-CC: ber...@debian.org

Please package new version of pytest-cookies (v0.7.0). Thanks!

The packaging of new version requires packaging the new version of
python-cookiecutter ( https://bugs.debian.org/1040040 ).

Regards,
Boyuan Yang


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

Bug#1010279: python-iso8601: please make the build reproducible

[James Addison]

Followup-For: Bug #1010279
X-Debbugs-Cc: la...@debian.org, reproducible-b...@lists.alioth.debian.org
Control: block -1 1056291
Control: close -1

Based on recent reproducible build testing history[1] of this package, and for
Debian versions after the fix for #1056291 became available (excludes both
bookworm, and builds prior to 2023-12-04 or so), I'm confident that the package
is building reproducibly, so I think we can close this.

(note: the failures that _have_ occurred recently when build-testing on
bookworm illustrate the same dot-dir pollution that we saw previously:
unexpected packaging of .hypothesis and .pytest_cache directories)

Adding a bug-blocker relationship for historical tracking purposes and closing
this bug.

[1] - 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-iso8601.html

Bug#1063868: O: xsecurelock -- X11 screen lock utility with the primary goal of security

[Markus Teich]

Package: wnpp
Severity: normal

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

[Christian Kastner]

Hi Petter,

On 2024-02-13 08:36, Petter Reinholdtsen wrote:
> 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.

yeah, that was my conclusion from my first experiments as well.

This is a problem though, since one key point of llama.cpp is to make
best use of the current hardware. If we'd target some 15-year-old amd64
lowest common denominator, we'd go against that.

In my first experiments, I've also had problems with ROCm builds on
hosts without a GPU.

I have yet to investigate if/how capabilities can be generally enabled,
and use determined at runtime.

Another issue that stable is clearly the wrong distribution for this.
This is a project that is continuously gaining new features, so we'd
need to stable-updates.

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

I'll push a first draft soon, though it will definitely not be
upload-ready for the above reasons.

Best,
Christian

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

[Diederik de Haas]

On Tuesday, 13 February 2024 17:59:55 CET Mario Limonciello wrote:
> > 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)
> You don't currently split up the AMD APU integrated graphics and dGPU,
> and I doing this is a bad idea as it's possible to reuse IP versions on
> APU and dGPU hardware.  If they are the same then they would use the
> same firmware binaries.

I have/had no plan to make a split for iGPU and dGPU, both would need to 
install the `firmware-amd-graphics` package.

For the 3 scenario's above:
- `intel-microcode` + `firmware-amd-graphics`
- `amd64-microcode` + `firmware-nvidia`*
- `amd64-microcode` + `firmware-amd-graphics`

AMD APU's would fall into scenario 3.

*) If my MR gets accepted, otherwise `firmware-misc-nonfree`

> For reference on the size:
> 
> $ du -sh amdgpu
> 60M amdgpu
> 
> $ du -sh du -sh amdtee/
> 20K amdtee/
> 
> $ du -sh amd-ucode/
> 112Kamd-ucode/
> 
> $ du -sh amd
> 268Kamd

What I want(ed) to prevent is that for scenario 2, the user should NOT have to 
install the `firmware-amd-graphics` package to get the amdtee firmware.

> These aren't yet upstream, but so you can see the size:
> 
> $ du -sh amdnpu/
> 3.3Mamdnpu/

And that seems like a future candidate too for amd64-microcode package.

> I think your suggestion to combine all the non graphics related binaries
> to a single package and all graphics related binaries to another is fine.

Excellent, then I think we're all in agreement :)

I'll add the `amdtee` dir to `Files-Excluded` in firmware-nonfree and Henrique 
can add those files to the amd64-microcode package.

Cheers,
  Diederik

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

Bug#1063601: tailspin: FTBFS: error[E0407]: method `backtrace` is not a member of trait `Error`

[Jonas Smedegaard]

Control: reassign -1 librust-eyre-dev
Control: retitle -1 librust-eyre-dev: fails to builds its source
Control: affects -1 tailspin

Quoting Sebastian Ramacher (2024-02-09 21:04:28)
> https://buildd.debian.org/status/fetch.php?pkg=tailspin=amd64=3.0.0%2Bdfsg-1=1706195420=0
> 
>  Running 
> `/<>/target/release/build/eyre-15058028a1ebd405/build-script-build`
> [eyre 0.6.8] error[E0407]: method `backtrace` is not a member of trait `Error`
> [eyre 0.6.8]   --> 
> /<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:19:9
> [eyre 0.6.8]|
> [eyre 0.6.8] 19 | / fn backtrace() -> Option<> {
> [eyre 0.6.8] 20 | | let backtrace = Backtrace::capture();
> [eyre 0.6.8] 21 | | match backtrace.status() {
> [eyre 0.6.8] 22 | | BacktraceStatus::Captured | 
> BacktraceStatus::Disabled | _ => {}
> [eyre 0.6.8] 23 | | }
> [eyre 0.6.8] 24 | | unimplemented!()
> [eyre 0.6.8] 25 | | }
> [eyre 0.6.8]| |_^ not a member of trait `Error`
> [eyre 0.6.8] 
> [eyre 0.6.8] error[E0554]: `#![feature]` may not be used on the stable 
> release channel
> [eyre 0.6.8]  --> 
> /<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:2:16
> [eyre 0.6.8]   |
> [eyre 0.6.8] 2 | #![feature(backtrace)]
> [eyre 0.6.8]   |^
> [eyre 0.6.8] 
> [eyre 0.6.8] warning: the feature `backtrace` has been stable since 1.65.0 
> and no longer requires an attribute to enable
> [eyre 0.6.8]  --> 
> /<>/target/x86_64-unknown-linux-gnu/release/build/eyre-eb1eb971e427fb49/out/probe.rs:2:16
> [eyre 0.6.8]   |
> [eyre 0.6.8] 2 | #![feature(backtrace)]
> [eyre 0.6.8]   |^
> [eyre 0.6.8]   |
> [eyre 0.6.8]   = note: `#[warn(stable_features)]` on by default
> [eyre 0.6.8] 
> [eyre 0.6.8] error: aborting due to 2 previous errors; 1 warning emitted
> [eyre 0.6.8] 
> [eyre 0.6.8] Some errors have detailed explanations: E0407, E0554.
> [eyre 0.6.8] For more information about an error, try `rustc --explain E0407`.
> [eyre 0.6.8] cargo:rustc-cfg=track_caller

The above seems like a failure not in tailspin but in librust-eyre-dev.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1063867: engrampa: Depends on non-free package

[cacin]

Source: engrampa
Version: 1.26.2-2
Severity: serious
Tags: patch
Justification: Policy 2.2.1

Dear Maintainer,

the commit fixing #1063564 introduced a direct Depends on 7zip-rar,
which is in the non-free area.

It should have been Depends: on 7zip and then Suggests: for 7zip-rar

Patch attached.
---
 debian/control | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 0dba580..4641fda 100644
--- a/debian/control
+++ b/debian/control
@@ -30,7 +30,6 @@ Depends: bzip2 (>= 1.0.1),
  engrampa-common (= ${source:Version}),
  gzip (>= 1.3.2),
  7zip,
- 7zip-rar,
  tar (>= 1.13.25),
  ${misc:Depends},
  ${shlibs:Depends},
@@ -52,7 +51,7 @@ Suggests: arj,
   sharutils,
   unace,
   unalz,
-  unar | unrar | p7zip-rar,
+  unar | unrar | 7zip-rar,
   zoo,
 Breaks: engrampa-common (<< 1.8.0),
 Description: archive manager for MATE
-- 

Bug#1063866: ddcci-dkms: failed to compile DKMS module for linux 6.5.0

[Jeff Becker (probably not evil)]

Package: ddcci-dkms
Version: 0.4.2-4
Severity: important

Dear Maintainer,

after trying to install package via apt it reports that the DKMS module could
not be compilled, giving the following output:

root@desu:~# apt install ddcci-dkms
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
ddcci-dkms
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/21.7 kB of archives.
After this operation, 95.2 kB of additional disk space will be used.
Selecting previously unselected package ddcci-dkms.
(Reading database ... 1401185 files and directories currently installed.)
Preparing to unpack .../ddcci-dkms_0.4.2-4_all.deb ...
Unpacking ddcci-dkms (0.4.2-4) ...
Setting up ddcci-dkms (0.4.2-4) ...
Loading new ddcci-0.4.2 DKMS files...
Building for 6.5.0-0.deb12.4-amd64
Building initial module for 6.5.0-0.deb12.4-amd64
Error! Bad return status for module build on kernel: 6.5.0-0.deb12.4-amd64
(x86_64)
Consult /var/lib/dkms/ddcci/0.4.2/build/make.log for more information.
dpkg: error processing package ddcci-dkms (--configure):
installed ddcci-dkms package post-installation script subprocess returned error
exit status 10
Errors were encountered while processing:
ddcci-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)


contents of make.log is include as an attached file.


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

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

Versions of packages ddcci-dkms depends on:
ii  dkms  3.0.10-8+deb12u1

ddcci-dkms recommends no packages.

ddcci-dkms suggests no packages.

-- no debconf information
DKMS make.log for ddcci-0.4.2 for kernel 6.5.0-0.deb12.4-amd64 (x86_64)
Tue Feb 13 14:32:20 EST 2024
make: Entering directory '/var/lib/dkms/ddcci/0.4.2/build'
make -C "ddcci"
make[1]: Entering directory '/var/lib/dkms/ddcci/0.4.2/build/ddcci'
make -C "/lib/modules/6.5.0-0.deb12.4-amd64/build" 
M="/var/lib/dkms/ddcci/0.4.2/build/ddcci" modules
make[2]: Entering directory '/usr/src/linux-headers-6.5.0-0.deb12.4-amd64'
  CC [M]  /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.o
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:42:34: error: macro 
"DEFINE_SEMAPHORE" requires 2 arguments, but only 1 given
   42 | static DEFINE_SEMAPHORE(core_lock);
  |  ^
In file included from 
/usr/src/linux-headers-6.5.0-0.deb12.4-common/include/linux/fs.h:25,
 from /var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:19:
/usr/src/linux-headers-6.5.0-0.deb12.4-common/include/linux/semaphore.h:34: 
note: macro "DEFINE_SEMAPHORE" defined here
   34 | #define DEFINE_SEMAPHORE(_name, _n) \
  | 
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:42:8: error: type defaults to 
‘int’ in declaration of ‘DEFINE_SEMAPHORE’ [-Werror=implicit-int]
   42 | static DEFINE_SEMAPHORE(core_lock);
  |^~~~
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c: In function 
‘ddcci_device_release’:
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1002:23: error: ‘core_lock’ 
undeclared (first use in this function); did you mean ‘file_lock’?
 1002 | down(_lock);
  |   ^
  |   file_lock
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1002:23: note: each undeclared 
identifier is reported only once for each function it appears in
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c: At top level:
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1053:27: error: initialization of 
‘int (*)(const struct device *, struct kobj_uevent_env *)’ from incompatible 
pointer type ‘int (*)(struct device *, struct kobj_uevent_env *)’ 
[-Werror=incompatible-pointer-types]
 1053 | .uevent = ddcci_device_uevent,
  |   ^~~
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1053:27: note: (near 
initialization for ‘ddcci_device_type.uevent’)
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1056:27: error: initialization of 
‘char * (*)(const struct device *, umode_t *, kuid_t *, kgid_t *)’ {aka ‘char * 
(*)(const struct device *, short unsigned int *, kuid_t *, kgid_t *)’} from 
incompatible pointer type ‘char * (*)(struct device *, umode_t *, kuid_t *, 
kgid_t *)’ {aka ‘char * (*)(struct device *, short unsigned int *, kuid_t *, 
kgid_t *)’} [-Werror=incompatible-pointer-types]
 1056 | .devnode= ddcci_devnode
  |   ^
/var/lib/dkms/ddcci/0.4.2/build/ddcci/ddcci.c:1056:27: note: (near 
initialization for ‘ddcci_device_type.devnode’)

Bug#1063865: src:tailspin: unsatisfied build dependency in testing: librust-terminal-size-0.2+default-dev

[Paul Gevers]

Source: tailspin
Version: 2.0.0+dfsg-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Paul Gevers]

Source: mediawiki2latex
Version: 8.0-1
Severity: serious
Control: close -1 8.7-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:mediawiki2latex has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version can't be 
installed on armel, mips64el and s390x while the package builds on those 
architectures.


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


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


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


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


Paul

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063530: node-undici: FTBFS with nodejs 18.19.0+dfsg-6~deb12u1

[Jérémy Lal]

Le ven. 9 févr. 2024 à 14:33, Dylan Aïssi  a écrit :

> Source: node-undici
> Version:  5.15.0+dfsg1+~cs20.10.9.3-1+deb12u3
> Severity: serious
> Tags: bookworm
> Usertags: apertis-ftbfs
> Justification: FTBFS
>
> Hello,
>
> While doing a rebuild of some node packages in Bookworm, it appears several
> packages (at least ~ 50 pkgs) no longer build with nodejs
> 18.19.0+dfsg-6~deb12u1
> (from bookworm-security repo) while they still successfully build with
> nodejs
> 18.13.0+dfsg1-1 (from the main bookworm repo). They all fail with the
> same error:
> error TS2307: Cannot find module 'undici-types' or its corresponding
> type declarations.
>
> Since, I am not sure which package need to be fixed (nodejs, node-undici or
> all of them), I fill this bug against the package referred by the error
> message,
> please reassign to the relevent package.


The latest nodejs (security | branch) update needs node-undici to export
its own "undici-types".
It seems that it doesn't, and that's probably my mistake.

Once that is fixed, three other packages need their test suites to be fixed
and uploaded to stable-proposed-updates.

> > > node-zx is a regression in the test suite only, fixed there:
> > https://salsa.debian.org/js-team/node
-zx/-/commit/a7d2861413480261890db147ea367a252192c9f2

> > > node-v8-compile-cache is a regression in the test suite only, fixed
> > there:
> > https://salsa.debian.org/js-team/node
-v8-compile-cache/-/commit/df42bdbfe84811e4da11d8c3d8ef3148d8a77bcc

> > > node-babel7 is a regression in the test suite, fixed there:
> > https://salsa.debian.org/js-team/node
-babel/-/commit/e5c88f4d765e4d64b60c9cf333dedb89abba39c5

Bug#1063863: tracker-miner-fs: lot of 'Could not get file handle for' log messages

[Patrice Duroux]

Package: tracker-miner-fs
Version: 3.4.6-3
Severity: minor

Dear Maintainer,

Looking at journalctl, I have a lot of messages like the following:

tracker-miner-f[11954]: Could not get file handle for '/home/patrice/Musique':
Opération non supportée
tracker-miner-f[11954]: Could not get file handle for '/home/patrice/Images':
Opération non supportée
tracker-miner-f[11954]: Could not get file handle for '/home/patrice/Vidéos':
Opération non supportée
tracker-miner-f[11954]: Could not get file handle for
'/home/patrice/.local/share/applications': Opération non supportée
tracker-miner-f[11954]: Could not get file handle for
'/home/patrice/.local/share/applications/wine': Opération non supportée
tracker-miner-f[11954]: Could not get file handle for
'/home/patrice/.local/share/applications/anbox': Opération non supportée

(sorry for the French)

Each message seems to be related to a directory file.
Is that expected?

Regards,
Patrice


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'oldstable-security'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 tracker-miner-fs depends on:
ii  init-system-helpers  1.66
ii  libc62.37-15
ii  libglib2.0-0 2.78.3-2
ii  libgstreamer1.0-01.22.9-1+b1
ii  libtracker-sparql-3.0-0  3.4.2-3
ii  libupower-glib3  1.90.2-8
ii  procps   2:4.0.4-4
ii  tracker  3.4.2-3
ii  tracker-extract  3.4.6-3

tracker-miner-fs recommends no packages.

tracker-miner-fs suggests no packages.

-- no debconf information

Bug#1053757: Info received (migration from sqlite to postgresql 15 failed)

[Harald Dunkel]

PS: I have replaced all "char(10)" and "char(13)" in the sqlite dump file
by "'.'". Finally I could import the database dump in postgresql (15) and
use it in xca.

There is no visible advantage, though. xca is as slow as for using sqlite.
I had hoped for a speed improvement.


Regards

Harri

Bug#1063775: initramfs-tools, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

[Wesley Schwengle]

Small update on the previous message.

It's the same as Debian #1055694, which is upstream bug

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62572


Cheers,
Wesley

--
Wesley Schwengle
E: wes...@schwengle.net

Bug#1063862: npm2deb fails when self.json['bin'] is not a list -- [patch provided]

[Georges Khaznadar]

Package: npm2deb
Version: 0.3.0-12
Severity: normal
Tags: patch

Dear Maintainer,

When I try to run:
   npm2deb create @babel/parser
the command fails:
   ...
   File "/usr/lib/python3/dist-packages/npm2deb/__init__.py", line 260, in
create_links
orig = _os.path.normpath(self.json['bin'][script])
 
  TypeError: string indices must be integers, not 'str'

The reason of this error is that:
   self.json['bin'] == './bin/babel-parser.js'
in this particular case.

Here is a patch which restores the expected behavior:

-8<-
diff --git a/npm2deb/__init__.py b/npm2deb/__init__.py
index ee3f29a..e2974da 100644
--- a/npm2deb/__init__.py
+++ b/npm2deb/__init__.py
@@ -255,9 +255,16 @@ and may not include tests.\n""")
 links = []
 dest = self.debian_dest
 if 'bin' in self.json:
-for script in self.json['bin']:
-orig = _os.path.normpath(self.json['bin'][script])
-links.append("%s/%s usr/bin/%s" % (dest, orig, script))
+if isinstance(self.json['bin'], list):
+for script in self.json['bin']:
+orig = _os.path.normpath(self.json['bin'][script])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
+else:
+script = self.json['bin']
+orig = _os.path.normpath(self.json['bin'])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
 if len(links) > 0:
 content = '\n'.join(links)
 utils.create_debian_file('links', content)
-8<-

Best regards,  Georges.


-- System Information:
Debian Release: trixie/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-25-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 npm2deb depends on:
ii  devscripts2.23.7
ii  node-github-url-from-git  1.5.0+~1.5.1-1
ii  npm   9.2.0~ds1-2
ii  python3   3.11.6-1
ii  python3-apt   2.7.5
ii  python3-dateutil  2.8.2-3

npm2deb recommends no packages.

npm2deb suggests no packages.

-- no debconf information
diff --git a/debian/changelog b/debian/changelog
index 75564f7..da54cd4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+npm2deb (0.3.0-12.1) unstable; urgency=medium
+
+  * NMU: fix an issue when self.json['bin'] is not a list.
+
+ -- Georges Khaznadar   Tue, 13 Feb 2024 18:57:29 +0100
+
 npm2deb (0.3.0-12) unstable; urgency=medium
 
   * Update standards version to 4.6.1, no changes needed.
diff --git a/npm2deb/__init__.py b/npm2deb/__init__.py
index ee3f29a..e2974da 100644
--- a/npm2deb/__init__.py
+++ b/npm2deb/__init__.py
@@ -255,9 +255,16 @@ and may not include tests.\n""")
 links = []
 dest = self.debian_dest
 if 'bin' in self.json:
-for script in self.json['bin']:
-orig = _os.path.normpath(self.json['bin'][script])
-links.append("%s/%s usr/bin/%s" % (dest, orig, script))
+if isinstance(self.json['bin'], list):
+for script in self.json['bin']:
+orig = _os.path.normpath(self.json['bin'][script])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
+else:
+script = self.json['bin']
+orig = _os.path.normpath(self.json['bin'])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
 if len(links) > 0:
 content = '\n'.join(links)
 utils.create_debian_file('links', content)

Bug#1053757: migration from sqlite to postgresql 15 failed

[Harald Dunkel]

Hi Thomas,

sorry for the late response. Somehow this went out of focus.

I have backported your 2.5.0 package too bookworm. After running
the new xca the sqlite db was updated, next I exported it using
sqlite3, but on importing it psql complained about the first line
in the dump file again:

ERROR:  syntax error at or near "PRAGMA"
LINE 1: PRAGMA foreign_keys=OFF;
^
BEGIN
CREATE TABLE
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
:


Finally (after about 400 lines) it failed with a syntax error:

:
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
INSERT 0 1
ERROR:  syntax error at or near ")"
LINE 1: ...0190307103908Z',replace('obsolete\n','\n',char(10)),2507,1);
 ^
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
ERROR:  current transaction is aborted, commands ignored until end of 
transaction block
:

I am not sure if xca is to blame here. The complete line looks like this:


INSERT INTO items 
VALUES(399,'old_strongSwan_IPsec_client',5,5,'20190307103908Z',replace('obsolete\n','\n',char(10)),2507,1);

There are tons of lines with

replace('sometext\n','\n',char(10))

I wonder how these newlines came into the database at all?


Regards

Harri

Bug#1063861: RFS: astro/0.25.1-1 [ITP] -- Gemini web browser using shell script

[Akash Doppalapudi]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name       : astro
   Version                : 0.25.1-1
   Upstream contact : Brian Mayer 
* URL                          : https://github.com/blmayer/astro
* License                : Expat
* Vcs                            : 
https://salsa.debian.org/akashdoppalapudi/astro

   Section                     : net

The source builds the following binary packages:

astro - Gemini web browser using shell script

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/a/astro/astro_0.25.1-1.dsc


Changes for the initial release:

astro (0.25.1-1) unstable; urgency=medium
.
* Initial release. (Closes: #1036734)

Regards,

Akash Doppalapudi



OpenPGP_0xBCBCAE31ECE05007.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063860: minissdpd: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: minissdpd
Version: 1.6.0-2
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for minissdpd
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# German translation of Debconf template for minissdpd
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the minissdpd package.
# Helge Kreutzmann , 2018, 2019, 2024.
#
msgid ""
msgstr ""
"Project-Id-Version: minissdpd 1.6.0-2\n"
"Report-Msgid-Bugs-To: miniss...@packages.debian.org\n"
"POT-Creation-Date: 2024-02-08 14:45+0800\n"
"PO-Revision-Date: 2024-02-13 18:59+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: german \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid "MiniSSDP daemon configuration"
msgstr "Konfiguration des MiniSSDP-Daemons"

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"The MiniSSDP daemon is being installed (perhaps as a dependency for UPnP "
"support) but will not function correctly until it is configured."
msgstr ""
"Der MiniSSDP-Daemon wird installiert (vielleicht als eine Abhängigkeit zur "
"UPnP-Unterstützung), wird aber nicht korrekt funktionieren, bis er "
"konfiguriert wurde."

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"MiniSSDP is a daemon used by MiniUPnPc to speed up device discovery. For "
"security reasons, no out-of-box default configuration can be provided, so it "
"requires manual configuration."
msgstr ""
"MiniSSDP ist ein von MiniUPnPc verwandter Daemon, um die Geräteerkennung zu "
"beschleunigen. Aus Sicherheitsgründen kann keine Standardkonfiguration "
"bereitgestellt werden, daher wird eine manuelle Konfiguration benötigt."

#. Type: note
#. Description
#: ../minissdpd.templates:2001
msgid ""
"Alternatively you can simply override the recommendation and remove "
"MiniSSDP, or leave it unconfigured - it won't work, but MiniUPnPc (and UPnP "
"applications) will still function properly despite some performance loss."
msgstr ""
"Alternativ können Sie auch einfach die Empfehlung außer Kraft setzen und "
"MiniSSDP entfernen oder es unkonfiguriert lassen. Es wird nicht "
"funktionieren, aber MiniUPnPc (und UPnP-Anwendungen) werden weiterhin, wenn "
"auch mit Leistungsverlusten, korrekt funktionieren."

#. Type: boolean
#. Description
#: ../minissdpd.templates:3001
msgid "Start the MiniSSDP daemon automatically?"
msgstr "Den MiniSSDP-Daemon automatisch starten?"

#. Type: boolean
#. Description
#: ../minissdpd.templates:3001
msgid ""
"Choose this option if the MiniSSDP daemon should start automatically, now "
"and at boot time."
msgstr ""
"Wählen Sie diese Option, falls der Daemon MiniSSDP jetzt und zum "
"Systemstartzeitpunkt automatisch starten soll."

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid "Interfaces to listen on for UPnP queries:"
msgstr "Schnittstellen, an denen auf UPnP-Anfragen gewartet werden soll:"

#. Type: string
#. Description
#: ../minissdpd.templates:4001
msgid ""
"The MiniSSDP daemon will listen for requests on those interfaces, and drop "
"all queries that do not come from the local network. Please enter the LAN "
"interfaces that it should listen on, separated by space."
msgstr ""
"Der MiniSSDP-Daemon wird auf diesen Schnittstellen auf Anfragen warten und "
"alle Anfragen verwerfen, die nicht vom lokalen Netzwerk stammen. Bitte geben "
"Sie die LAN-Schnittstellen ein, an denen auf Anfragen gewartet werden soll. "
"Trennen Sie die Einträge durch Leerzeichen."

#. Type: boolean
#. Description
#: ../minissdpd.templates:5001
msgid "Enable IPv6 listening?"
msgstr "Auf IPv6-Anfragen warten?"

#. Type: boolean
#. Description
#: ../minissdpd.templates:5001
msgid ""
"Please specify whether the MiniSSDP daemon should listen for IPv6 queries."
msgstr ""
"Bitte geben Sie an, ob der MiniSSDP-Daemon auf IPv6-Anfragen warten soll."

#~ msgid ""
#~ "Interface names are highly preferred, and required if you plan to enable "
#~ "IPv6 port forwarding."
#~ msgstr ""
#~ "Schnittstellennamen werden nachdrücklich bevorzugt. Falls Sie vorhaben, "
#~ "eine IPv6-Portweiterleitung zu aktivieren, sind dieser erforderlich."

#~ msgid ""
#~ "If you see this message but never manually install MiniSSDP, then most "
#~ "probably this package is automatically pulled as a recommendation for "
#~ "libminiupnpc, which is the UPnP support library for many applications."
#~ msgstr ""
#~ "Falls Sie diese Nachricht sehen aber MiniSSDP niemals manuell installiert "
#~ "haben, dann wird das Paket höchstwahrscheinlich als Empfehlung für "
#~ "libminiupnpc automatisch 

Bug#1063775: initramfs-tools, and cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead

[Jeffrey Walton]

This issue is likely Debian Bug #62572. Also see
.

(Thanks Wesley).

Bug#1063857: github-backup: commit messages don't end with newline

[Jakub Wilk]

* Jakub Wilk , 2024-02-13 18:00:

Commit messages created by github-backup don't end with newline


... which breaks git-log a bit:
#1063859 "git: commit msg without trailing \n breaks 'git log --grep'ing 
for notes"


--
Jakub Wilk

Bug#1063859: git: commit msg without trailing \n breaks "git log --grep"ing for notes

[Jakub Wilk]

Package: git
Version: 1:2.39.2-1.1

Let's create a commit with a message that doesn't end with newline¹, and 
attach a note to it:


   $ commit=$(printf 'foo' | git commit-tree 
4b825dc642cb6eb9a060e54bf8d69288fbee4904)
   $ git notes add -m bar $commit
   $ git log $commit --grep bar
   commit e0e2391bad1644f1dd580c0d5d6c5b58addf2870
   Author: Jakub Wilk 
   Date:   2024-02-13 18:00:51 +0100

   foo

   Notes:
   bar

So far so good, but if you anchor the regex, the commit can no longer be 
found:


   $ git log $commit --grep ^bar
   [nothing]

Apparently that's because git concatenates the commit message and the 
note without inserting newline between them:


   $ git log $commit --grep ^foobar
   commit e0e2391bad1644f1dd580c0d5d6c5b58addf2870
   Author: Jakub Wilk 
   Date:   2024-02-13 18:00:51 +0100

   foo

   Notes:
   bar



¹ See also bug #1063857 "github-backup: commit messages don't end with 
newline".



-- System Information:
Architecture: i386

Versions of packages git depends on:
ii  libc62.36-9+deb12u4
ii  libcurl3-gnutls  7.88.1-10+deb12u5
ii  libexpat12.5.0-1
ii  libpcre2-8-0 10.42-1
ii  zlib1g   1:1.2.13.dfsg-1
ii  perl 5.36.0-7+deb12u1
ii  liberror-perl0.17029-2
ii  git-man  1:2.39.2-1.1

--
Jakub Wilk

Bug#1063719: More analysis and improved patch

[George Robbert]

Hey,

Just like with the previous bug (#1026927), it looks like there's more
to this one.  Trying the patch on several more systems I run into the
same symptoms on some.  Again, these have the same symptoms but
differing causes (full patch included).  What I found was:


On an intel system, where uCode/AMD.pm was run before uCode/Intel.pm

intel_sys1# needrestart -b 
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-18-amd64
NEEDRESTART-KEXP: 6.1.0-18-amd64
NEEDRESTART-KSTA: 1
NEEDRESTART-UCSTA: 1
Use of uninitialized value $ucode_vars{"CURRENT"} in concatenation (.) or 
string at /usr/sbin/needrestart line 940.
NEEDRESTART-UCCUR: 
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
string at /usr/sbin/needrestart line 941.
NEEDRESTART-UCEXP: 

But we don't get the 'Use of uninitialized value' when run as
`needrestart -b -v`.  The issue here is that nr_ucode_check keeps
going after the "eval ...  ${pkg}::nr_ucode_check_real..." fails
unless $debug is set.  Thus, without $debug, thi saves off the
unintialized values from AMD.pm as "the good ones", so we get the
error.

On a VM running with an AMD processor but without package
amd64-microcode, and also directly on an AMD system with a processor new enough
that it does not have a microcode version lin amd64-microcode, I get
the following identical results.

amd_vm1# needrestart -b
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-18-amd64
NEEDRESTART-KEXP: 6.1.0-18-amd64
NEEDRESTART-KSTA: 1
NEEDRESTART-UCSTA: 1
NEEDRESTART-UCCUR: 0xa0011d1
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
string at /usr/sbin/needrestart line 941.
NEEDRESTART-UCEXP:


amd_sys3# needrestart -b
NEEDRESTART-VER: 3.6
NEEDRESTART-KCUR: 6.1.0-18-amd64
NEEDRESTART-KEXP: 6.1.0-18-amd64
NEEDRESTART-KSTA: 1
NEEDRESTART-UCSTA: 1
NEEDRESTART-UCCUR: 0x6006705
Use of uninitialized value $ucode_vars{"AVAIL"} in concatenation (.) or 
string at /usr/sbin/needrestart line 941.
NEEDRESTART-UCEXP: 

This comes from AMD.pm not setting $ucode_vars{"AVAIL"} if it doesn't
find any matching available versions.  compare_ucode_versions()
handles, this as expected, but leaves $ucode_vars{"AVAIL"} unset to
cause problems later when run with -b.


The attached patch fixes includes the previous patch and also fixes
these 2 issues.

Hope this helps,
George

--- /tmp/uCode.pm.dist  2024-02-13 09:20:29.236867717 -0700
+++ /usr/share/perl5/NeedRestart/uCode.pm   2024-02-13 09:33:23.099742955 
-0700
@@ -152,10 +152,15 @@
 
 # call ucode modules
 foreach my $pkg (@PKGS) {
+   eval "${pkg}::nr_ucode_init();";
+   if ( $@ ) {
+   print STDERR $@ if ($debug);
+   next;
+   }
 my @nvars;
 eval "\@nvars = ${pkg}::nr_ucode_check_real(\$debug, \$ui, 
\$processors{\$pid});";
-if ( $@ && $debug ) {
-print STDERR $@;
+if ( $@ ) {
+   print STDERR $@ if ($debug);
 $ui->progress_step;
 next;
 }
@@ -174,6 +179,10 @@
 
 $ui->progress_fin;
 
+if ( $state == NRM_CURRENT && ! grep ( ( $_ eq "AVAIL"), @vars ) ) {
+   push(@vars, "AVAIL", "unavailable");
+}
+
 return ( $state, @vars );
 }
 

Bug#1061802: Did Python 3.12 developers honestly broke special regexp sequences? (Was: hatop fails its autopkg tests with Python 3.12)

[Andreas Tille]

Hi,

I was constantly shaking my had above bug #1061802 featuring
Syntaxwarnings like

SyntaxWarning: invalid escape sequence '\.'
573s   CLI_INPUT_RE = re.compile('[a-zA-Z0-9_:\.\-\+; /#%]')
573s /tmp/autopkgtest.G4v4eK/autopkgtest_tmp/hatop.py:215: 
SyntaxWarning: invalid escape sequence '\s'
573s   'software_name':re.compile('^Name:\s*(?P\S+)'),

which is even in contrast with Regular expression operations
documentation for Python3.12[1] where

\s
For Unicode (str) patterns:
Matches Unicode whitespace characters (which includes [ \t\n\r\f\v], and also 
many other characters, for example the non-breaking spaces mandated by 
typography rules in many languages).

Matches [ \t\n\r\f\v] if the ASCII flag is used.

For 8-bit (bytes) patterns:
Matches characters considered whitespace in the ASCII character set; this is 
equivalent to [ \t\n\r\f\v].


remains what I know \s is meaning in regular expressions.  (I admit '\.'
is unusual inside [] and I think just '.' is appropriate here.)  I tried
simple things like


$ python3.12
Python 3.12.2 (main, Feb  7 2024, 20:47:03) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> software_name = re.compile('^Name:\s*(?P\S+)')
:1: SyntaxWarning: invalid escape sequence '\s'
>>> software_name = re.compile('^Name:[\s\t\n]*(?P\S+)')
:1: SyntaxWarning: invalid escape sequence '\s'


which makes me scratching my head what else we should write
for "any kind of space" now in Python3.12.

Kind regards
   Andreas.

[1] https://docs.python.org/3/library/re.html

-- 
http://fam-tille.de

Bug#1063856: hdf5: new upstream release

[Drew Parsons]

Source: hdf5
Followup-For: Bug #1063856

For further context, HDF upstream no longer supports hdf5 1.10, nor
hdf5 1.12 (i.e. no more releases will be made in these series)

see
https://github.com/HDFGroup/hdf5#release-schedule
https://github.com/h5py/h5py/issues/2312
https://forum.hdfgroup.org/t/release-of-hdf5-1-12-3-library-and-tools-newsletter-200/11924

hdf5 1.14 supports the REST VOL API, which may improve cloud computing
performance.
see https://github.com/HDFGroup/vol-rest
https://github.com/h5py/h5py/issues/2316

Bug#1063857: github-backup: commit messages don't end with newline

[Jakub Wilk]

Package: github-backup
Version: 1.20200721-2+b1

Commit messages created by github-backup don't end with newline:

   $ git clone -q https://github.com/jwilk/cowproxy

   $ cd cowproxy

   $ github-backup --no-forks
   Gathering metadata for https://github.com/jwilk/cowproxy.git ...

   $ git cat-file commit github && echo '<-- no newline here'
   tree e4fe2ef1f08a9145c7234e0fab086a9c12781eab
   parent 9d6d276c144804c026ac35195b6adddb764c4a35
   author Jakub Wilk  1707842905 +0100
   committer Jakub Wilk  1707842905 +0100

   github-backup<-- no newline here

This is unlike commit messages created by "git commit":

   $ git cat-file commit HEAD && echo '^-- yay'
   tree 91b21d2098618e30ec4c87eef0e3ed505f281f53
   parent 6eae506db2f48cb85ffd959e2cb2385a0a87e948
   author Jakub Wilk  1706350373 +0100
   committer Jakub Wilk  1706350373 +0100

   CI: upgrade actions/cache to v4.
   ^-- yay


-- System Information:
Architecture: i386

Versions of packages github-backup depends on:
ii  libc6  2.36-9+deb12u4
ii  libdouble-conversion3  3.2.1-1
ii  libffi83.4.4-1
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libstdc++6 12.2.0-14
ii  zlib1g 1:1.2.13.dfsg-1
ii  git1:2.39.2-1.1

--
Jakub Wilk

Bug#1063858: False disk set size in README.(html|txt), and a few minor corrections

[Kevin Price]

Package: debian-cd
X-Debbugs-Cc: J.A. Bezemer , Steve
McIntyre 
Version: 3.2.1
Severity: minor

Dear maintainers, dear Steve[1]:

In the official current stable (12.5) images, the /README.(html|txt)
files (see att.) seem to miscount the total number of disks in each set.
For instance, in debian-12.5.0-amd64-DLBD-2.iso, section "About This
Disc" says: "[...]this disc is number 2 of a set of 1 discs"

1. This is obviously false, not only in the DLBD images.

While we're at it, could we tidy up the generating script in a few more
minor details, without separate bug reports maybe?

2. Aforementioned sentence's full stop is awkwardly misplaced in the
html (line-break in-between), and it's missing in the txt.

3. I was not quite certain about the version number to file this bug
against, so I took a look at the XHTML header for sth. like 'meta
name="generator"'. Wouldn't that be helpful to include?

4. The html claims to be "XHTML 1.0 Strict", but fails to validate
against https://validator.w3.org/ . AFAICT, that's only due to errors in
the section "Last-Minute Notes":

4.a. The "" beginning with "This is an official release" lacks a
closing "".

4.b. Where it says "https://bugs.debian.org/;>bugs.debian.org" it should
respectively say "a", "href", and "/a" instead.

5. The html header defines the language to be "English". Maybe "en"
would be more preferable?

Please let me know how I could be of any further assistance in resolving
these issues.

[1] FWIW, See also
https://lists.debian.org/debian-user/2024/01/msg00796.html , and please
accept my apology for being slow to file this bug.

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

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

Versions of packages debian-cd depends on:
ii  apt2.6.1
ii  bc 1.07.1-3+b1
ii  bzip2  1.0.8-5+b1
ii  cpp4:12.2.0-3
ii  curl   7.88.1-10+deb12u5
ii  dctrl-tools [grep-dctrl]   2.24-3+b1
ii  dpkg-dev   1.21.22
ii  genisoimage9:1.1.11-3.4
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.21.22
ii  libfile-slurp-perl .32-2
ii  libyaml-libyaml-perl   0.86+ds-1
ii  lynx   2.9.0dev.12-1
ii  make   4.3-4.1
ii  perl [libdigest-sha-perl]  5.36.0-7+deb12u1
ii  pigz   2.6-1
ii  tofrodos   1.7.13+ds-6
ii  uuid-runtime   2.38.1-5+b1
ii  wget   1.21.3-1+b2
ii  xorriso1.5.4-4

Versions of packages debian-cd recommends:
ii  dosfstools   4.2-1
ii  hfsutils 3.2.6-15
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3
ii  mtools   4.0.33-1+really4.0.32-1
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

debian-cd suggests no packages.

-- no debconf information

HTH, cheers
-- 
Kevin Price   Debian GNU/Linux 12.5.0 "Bookworm" - Official amd64 DLBD Binary-2 with
   firmware 20240210-11:28

 (HTML version in README.html)

  Welcome to the exciting world of
  Debian GNU/Linux

   This is one disc in a set containing the Debian GNU/Linux distribution.
   Debian is a very extensive collection of software. But it is more. It
   is a complete Operating System (OS) for your computer. And it is free
   (as in "freedom").

   CONTENTS:
 * Introduction
 * About This Disc
 * Installing
 * Last-Minute Notes
 * Installing software using Apt
 * CD/DVD Manufacturers
 * More Information
 * Browse This Disc

Introduction


   An operating system is the set of basic programs and utilities that
   make your computer run. At the core of an operating system is the
   kernel. The kernel is the most fundamental program on the computer,
   which does all the basic housekeeping and lets you start other
   programs. Debian is kernel independent. It currently uses either the
   Linux or FreeBSD kernel. Most of the basic operating system tools come
   from the GNU project; hence the name GNU/Linux.

   Debian is available for various kinds of computers ("architectures").
   Check the ports page for more information.

   Read more at:

 https://www.debian.org/intro/about

About This Disc
===

   This disc is labeled

   Debian GNU/Linux 12.5.0 "Bookworm" - Official amd64 DLBD Binary-2 with
   firmware 20240210-11:28

  

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

[Mario Limonciello]

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


You don't currently split up the AMD APU integrated graphics and dGPU, 
and I doing this is a bad idea as it's possible to reuse IP versions on 
APU and dGPU hardware.  If they are the same then they would use the 
same firmware binaries.


For reference on the size:

$ du -sh amdgpu
60M amdgpu

$ du -sh du -sh amdtee/
20K amdtee/

$ du -sh amd-ucode/
112Kamd-ucode/

$ du -sh amd
268Kamd

These aren't yet upstream, but so you can see the size:

$ du -sh amdnpu/
3.3Mamdnpu/




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.


I think your suggestion to combine all the non graphics related binaries 
to a single package and all graphics related binaries to another is fine.

Bug#1061794: crmsh fails its autopkg tests with Python 3.12

[Florent 'Skia' Jacquet]

Hi,

Those two patches should fix autopkgtest.

The importlib one shouldn't be a problem.

The looseversion one, otoh, requires a bit more attention. LooseVersion 
was part of distutils, and got removed with Python 3.12, but there 
doesn't seem to be any replacement anywhere in the standard library.

There are basically two solutions here for now:
  * use that patch since setuptools is already packaged and provide a 
working implementation of LooseVersion. It's still in a `._distutils` 
module, which doesn't make it appear as being officially part of the 
API, meaning it could break eventually if it gets removed from here too.
  * make another patch that would make use of the `looseversion` 
package [1], that is currently not packaged in Debian, but should 
probably be the safer way forward, since the only purpose of that 
package is to provide that API. I haven't yet started the work of 
packaging that `looseversion` module, and don't know if that's the right 
path forward.


Obviously, this also depends on what solution upstream will take to 
support Python 3.12. I've already opened an issue here: 
https://github.com/ClusterLabs/crmsh/issues/1324


I also have that branch that passes autopkgtests locally: 
https://git.launchpad.net/~hyask/ubuntu/+source/crmsh/log/


[1]: https://github.com/effigies/looseversion



Skiadiff --git a/test/unittests/test_utils.py b/test/unittests/test_utils.py
index 77fd14b0b67d..900e8528143a 100644
--- a/test/unittests/test_utils.py
+++ b/test/unittests/test_utils.py
@@ -7,7 +7,7 @@ from __future__ import unicode_literals
 import os
 import socket
 import re
-import imp
+import importlib
 import subprocess
 import unittest
 import pytest
@@ -24,7 +24,7 @@ def setup_function():
 utils._ip_for_cloud = None
 # Mock memoize method and reload the module under test later with imp
 mock.patch('crmsh.utils.memoize', lambda x: x).start()
-imp.reload(utils)
+importlib.reload(utils)
 
 
 @mock.patch("crmsh.utils.get_stdout_stderr")
diff --git a/crmsh/ra.py b/crmsh/ra.py
index 6060ec7a3fd5..fcadc860aa5f 100644
--- a/crmsh/ra.py
+++ b/crmsh/ra.py
@@ -49,15 +49,15 @@ def crm_resource(opts):
 
 @utils.memoize
 def can_use_lrmadmin():
-from distutils import version
+from setuptools._distutils.version import LooseVersion
 # after this glue release all users can get meta-data and
 # similar from lrmd
 minimum_glue = "1.0.10"
 _rc, glue_ver = get_stdout("%s -v" % lrmadmin_prog, stderr_on=False)
 if not glue_ver:  # lrmadmin probably not found
 return False
-v_min = version.LooseVersion(minimum_glue)
-v_this = version.LooseVersion(glue_ver)
+v_min = LooseVersion(minimum_glue)
+v_this = LooseVersion(glue_ver)
 if v_this < v_min:
 return False
 if userdir.getuser() not in ("root", config.path.crm_daemon_user):
diff --git a/crmsh/utils.py b/crmsh/utils.py
index 51ff5b326d56..40c74a9019b5 100644
--- a/crmsh/utils.py
+++ b/crmsh/utils.py
@@ -34,7 +34,7 @@ from . import userdir
 from . import constants
 from . import options
 from . import term
-from distutils.version import LooseVersion
+from setuptools._distutils.version import LooseVersion
 from .constants import SSH_OPTION
 from . import log
 
diff --git a/debian/control b/debian/control
index 8fe560e13935..ea924b952335 100644
--- a/debian/control
+++ b/debian/control
@@ -40,6 +40,7 @@ Depends:
  python3-lxml,
  python3-packaging,
  python3-parallax,
+ python3-setuptools,
  python3-yaml
 Recommends: pacemaker (>= 1.1.12)
 Replaces: pacemaker (<< 1.1.12)

Bug#1063856: hdf5: new upstream release

[Drew Parsons]

Source: hdf5
Version: 1.10.10+repack-3
Severity: normal
X-Debbugs-Cc: debian-scie...@lists.debian.org

What our situation with our hdf5 package version?

We're currently using hdf5 1.10.10,
but 1.12.2 has been available in experimental for some time,
and upsteam has released 1.14.3.

Should we be upgrading now to hdft 1.14 (or 1.12)?

There's no current urgency, but I'm worried some bitrot might set in
as upstream developers focus on using the more recent HDF5 releases.

Drew

Bug#1063855: RM: jsdoc-toolkit -- ROM; jsdoc-toolkit is obsolete, superseded by node-jsdoc2

[Georges Khaznadar]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: jsdoc-tool...@packages.debian.org
Control: affects -1 + src:jsdoc-toolkit

Please remove jsdoc-toolkit from unstable and testing.

I used to maintain jsdoc-toolkit, as a build-dependency of the package
jsxgraph, which I will keep maintaining. jsdoc-toolkit was a javascript source
interpreted by a java-based engine. Now, it is superseded by the package node-
jsdoc2
which I uploaded to Debian, which is quite the same javascript source,
interpreted
by nodeJs.

So, jsdoc-toolkit is no longer useful for current developers.

Best regards,   Georges.

Bug#1063558: pgpainless 1.6.6 is available

[Daniel Kahn Gillmor]

On Mon 2024-02-12 11:18:59 -0500, Jérôme Charaoui wrote:
> On Fri, 09 Feb 2024 10:19:59 -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.
>
> According to my reading of the changes since 1.6.5, it's basically a 
> no-op for the Debian package:
>
> https://github.com/pgpainless/pgpainless/compare/1.6.5...1.6.6
>
> Is there a compelling reason to upgrade it nonetheless?

ah, i think you're right that this might not be worth the effort.

Sorry for the noise, i'm closing the bug report :)

--dkg


signature.asc
Description: PGP signature

Bug#1063854: RM: senlin -- ROM; unmaintained

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: sen...@packages.debian.org
Control: affects -1 + src:senlin


Hi,

As per this document:
https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html

Senlin is unmaintained and inactive. Let's remove it from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#1063853: RM: wims-moodle -- ROM; this package works only wil moodle version 2

[Georges Khaznadar]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: wims-moo...@packages.debian.org
Control: affects -1 + src:wims-moodle

Hello, please remove the package wims-moodle, which works only with Moodle
version 2.
So, it may have some interest for people using oldstable or oldoldstable, but
it is
definetely useless for people using stable, testing or unstable.

Moodle 2.9 was released in year 2015, and does not support PHP7.0
Moodle 3.1 (LTS) was released in year 2016.

Now, the features of wims-moodle can be provided by the current package wims-
lti which I maintain.

Best regards,   Georges.

Bug#1058890: new try

[Dr . André Desgualdo Pereira]

Adding "intel_iommu=off" to kernel boot does NOT change anything. 

Bug#1063852: pdns-recursor: crafted DNSSEC records in a zone can lead to a denial of service in Recursor (CVE-2023-50387 CVE-2023-50868)

[Salvatore Bonaccorso]

Source: pdns-recursor
Version: 4.9.2-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for pdns-recursor.

CVE-2023-50387[0] and CVE-2023-50868[1].

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-2023-50387
https://www.cve.org/CVERecord?id=CVE-2023-50387
[1] https://security-tracker.debian.org/tracker/CVE-2023-50868
https://www.cve.org/CVERecord?id=CVE-2023-50868
[2] 
https://blog.powerdns.com/2024/02/13/powerdns-recursor-4-8-6-4-9-3-5-0-2-released

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1063851: libxml++2.6: Newer version exists in the 2.x branch

[Guillermo Frontera]

Package: libxml++2.6-2v5
Version: 2.40.1-3build3
Severity: wishlist
File: libxml++2.6
X-Debbugs-Cc: gfrontera@gmail.com

Dear Maintainer,

The libxml++ project moved to GitHub (as announced here: 
https://mail.gnome.org/archives/libxmlplusplus-list/2020-January/msg0.html).
 However, the tracker (https://tracker.debian.org/pkg/libxml++2.6) is still 
monitoring the old repository.

Since then, several new versions have been released in the 2.x branch, the 
latest being 2.42.3 (whereas the latest tracked version is 2.40.1). The latest 
version is available at 
https://github.com/libxmlplusplus/libxmlplusplus/releases/tag/2.42.3.

Please, update the Debian Package Tracker with the latest homepage and Git repo 
and provide a packaged version with the latest version of the library in the 
2.x branch.

Homepage: https://libxmlplusplus.github.io/libxmlplusplus/
Git repo: https://github.com/libxmlplusplus/libxmlplusplus

-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-17-generic (SMP w/18 CPU threads; PREEMPT)
Locale: LANG=Default.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
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 libxml++2.6-2v5:amd64 depends on:
ii  libc6  2.35-0ubuntu3.6
ii  libgcc-s1  12.3.0-1ubuntu1~22.04
ii  libglibmm-2.4-1v5  2.66.2-2
ii  libstdc++6 12.3.0-1ubuntu1~22.04
ii  libxml22.9.13+dfsg-1ubuntu0.3

libxml++2.6-2v5:amd64 recommends no packages.

libxml++2.6-2v5:amd64 suggests no packages.

-- debconf information excluded

Bug#1063701: Fixed it

[kritomas]

After installing libstdc++-14-dev, it fixed itself, on both clang++, and
clang++ built from upstream.

Bug#1059223: Workaround for rustc toolchain bug

[Mate Kukri]

Unfortunately this patch was rather optimistic, there are 7 or so more
tests failing similarly, so more is needed to workaround this.

On Tue, Feb 13, 2024 at 2:33 PM Mate Kukri  wrote:
>
> Hello,
>
> We have a similar issue in Ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2049904
>
> To me this seems like a rust linking issue, the same C library
> compiled with cc, then linked against a C stub program links just fine
> for me.
>
> In comparison rustc tries to be annoyingly clever and calls `cc` to
> link with `-nodefaultlibs` and tries to manually provide all the
> required libraries, which makes it fail.
>
> The direct cause of the error is a library ordering issue, `-lc`
> should always come after all C static libs and object files in a link
> command, but it does not.
>
> It seems that meson doesn't pass `-Clink-arg=-lc` to `rustc` at all by
> default (which it probably shouldn't need to), and it's rustc itself
> that emits `-lc` at the wrong location.
>
> A workaround is as follows:
> ```
> dep_libc = declare_dependency(link_args : '-lc')
>
> l = static_library(
>   'c_accessing_zlib',
>   'c_accessing_zlib.c',
>   dependencies: [dep_zlib, dep_libc],
> )
> ```
>
> It is rather unweildly to read, but here's an example of an offending
> link invocation by rustc:
> ```
> LC_ALL="C" 
> PATH="/usr/lib/rustlib/aarch64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
> VSLANG="1033" "cc" "/tmp/rustcqxuAcC/symbols.o"
> "prog.p/prog.prog.3a9e8efe5d7989d1-cgu.0.rcgu.o"
> "prog.p/prog.2valzr4aprd78wdd.rcgu.o" "-Wl,--as-needed" "-L" "." "-L"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-3f505df5bf7b6973.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-f7bbfb2a4f0106ba.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-799d4aa6228550fd.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-817c1781430e6007.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-ad8936af23d8ece8.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-fa9ccab1157705c6.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-0f0344f8af442a24.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-f1d03073262366fd.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-d2b728fe429f73fd.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-78f4eeade0e7b3f3.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-386abc7d4431b549.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-f2fbe97df215d47a.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-1b9c021e2652ca95.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-a31e7b8703ef1917.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-67315dfc1c311b62.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-6f13ad92e9ef28f1.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-4647df6db5bfc191.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-7ca28360f44e13c1.rlib"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-bda26fded9d4fbc7.rlib"
> "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl"
> "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L"
> "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "prog"
> "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
> "libc_accessing_zlib.a" "-lz"
> ```
>
> Which was produced by the following rustc invocation:
> ```
> rustc -C linker=cc --color=always -C debug-assertions=yes -C
> overflow-checks=no --crate-type bin -g --crate-name prog --emit
> dep-info=prog.d --emit link=prog --out-dir prog.p -C metadata=prog@exe
> -Clink-arg=libc_accessing_zlib.a -Clink-arg=-lz -L. ../prog.rs
> ```
>
> As a note, same issue repros on the latest nightly rustc also.
>
> Fixing rustc instead of meson is the real solution, but I don't think
> this should be holding up meson migrating, as such I am attaching a
> workaround patch similar to the one I have proposed for Ubuntu.
>
> Mate Kukri

Bug#1063848: RM: sahara -- ROM; unmaintained upstream

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: sah...@packages.debian.org
Control: affects -1 + src:sahara

Hi,

As per this document:
https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html

Sahara is inactive and unmaintained. Let's remove it from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#1063850: RM: freezer -- ROM; unmaintained

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: free...@packages.debian.org
Control: affects -1 + src:freezer


As per this document:
https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html

Freezer is inactive and unmaintained. Please remove it from Debian.

That's 2 source packages:
- freezer
- freezer-api

Cheers,

Thomas Goirand (zigo)

Bug#1063849: RM: monasca-api\ -- ROM; unmaintained

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove


Hi,

As per this document:
https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html

Monasca is unmaintained and inactive. Let's remove it from Debian.

That's 2 source packages:
- monasca-api
- monasca-common

Cheers,

Thomas Goirand (zigo)

Bug#770331: graphite-web: aliasByNode() gets upset by 'odd' characters in data paths

[Alexandre Rossi]

Version: 1.0.2+debian-1

Hi,

This seems to have been fixed in upstream commit:


https://github.com/graphite-project/graphite-web/commit/b71f0e01b7b8b90f8124fabcc591c1f77e04ffc3

And released in 1.0.0 (from what I can see in the changelog).

Feel free to reopen if I'm mistaken.

Thanks,

Alex

Bug#1063704: RFS: tiny-initramfs/0.1-5.1 [NMU] [RC] -- Minimalistic initramfs implementation (automation)

[Tobias Frost]

Hi Victor,

uploaded to DELAYED/5 and sent the nmudiff to the package.

Thanks for your contributions to Debian!

Cheers,
-- 
tobi

On Sun, Feb 11, 2024 at 12:10:48PM +0100, Victor Westerhuis wrote:
> Package: sponsorship-requests
> Severity: important
> X-Debbugs-Cc: christ...@iwakd.de
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear mentors,
> 
> I am looking for a sponsor for "tiny-initramfs". The current version of
> the package is unusable with kernel packages with version 6.6.3-1~exp1
> or greater, because it does not support compressed modules. This NMU
> contains a targeted fix to enable support for XZ compressed modules.
> 
> I opened bug #1063142 6 days ago, so far without response from Christian
> Seiler, the maintainer. According to
> https://contributors.debian.org/contributor/chris_se/ Christian has not
> been active in Debian since 2021. That's why I decided to propose this
> NMU.
> 
> The below VCS URL is no longer active. The packaging was already
> imported in Salsa at https://salsa.debian.org/debian/tiny-initramfs and
> I'm testing some bigger packaging changes in my fork at
> https://salsa.debian.org/viccie30/tiny-initramfs.
> 
>  * Package name : tiny-initramfs
>Version  : 0.1-5.1
>Upstream contact : Christian Seiler 
>  * URL  : https://github.com/chris-se/tiny-initramfs/
>  * License  : GPL-2+, GPL-3+
>  * Vcs  : 
> https://anonscm.debian.org/cgit/collab-maint/tiny-initramfs.git
>Section  : utils
> 
> The source builds the following binary packages:
> 
>   tiny-initramfs - Minimalistic initramfs implementation (automation)
>   tiny-initramfs-core - Minimalistic initramfs implementation (core tools)
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/tiny-initramfs/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/t/tiny-initramfs/tiny-initramfs_0.1-5.1.dsc
> 
> Changes since the last upload:
> 
>  tiny-initramfs (0.1-5.1) unstable; urgency=high
>  .
>* Non-maintainer upload.
>* Decompress kernel modules included in initramfs. (Closes: #1063142)
> 
> - --
> Vriendelijke groet, Kind regards,
> 
> Victor Westerhuis
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmXIqzgTHHZpY3RvckB3
> ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+3QGD/90vFeAtsjTVWxw/W88+KV9WWp5HS4S
> t380m73WMciSqK8tA94xiem+6kwVkgTr5VeKvNPKBiRhlhkXVAJiqoVmg9xTY7oh
> bmOb9vghXCQ81+KINiE9gkBzYHdeTF+OLalN0Vjwn1R1yvQFNgi7uB/bArfR4qv8
> ytFzoqwFYURfuyVV5H+l5xhOl0q1BsNeShGQQGIhtH6rDvNhBdHIN6CAXMHkwIV8
> E1SAxVTvK2oSW7tU6wCYlwG2pXmPsFxRwjDE1l4gL3mjm0yRbfjMP8h9e7AfKVSf
> 9GD88xrNGPxsKGFgEfCkm4ndzoF3JqypIjpI8Xw8Zm/OHnrVobxAI84zvJB1tCeX
> fOYmO3HHOPzNDecJ6idWGddjXdjuQDGepbT/ZJ3qzxIPaCCPBMkGLrkmfM+sb1eg
> voRhYA36Fen1sM75rBbEx6b+tWhnb8b/lVmVHI553FhQoo+Off0/vaQGzVKf+AEw
> O5hU6e8BpPaAB8XyLYpehm1+fhO4MMf6jDhK+a7kFeHugPNL92GbnKKcbR5yVcoU
> TqlXYyU1rULqALU8fozYIm/pfZm9iPrCxe23Cj3ziJ0cRBteOe8L9FV+pzr8F5Q2
> 72JIYsJ3Q24tLVuLVyFzYVyR2Yp778+bz6bcj+b0C1mY9HmbnkaVrc0/q/R/KVMb
> 01fIJEX7ZkkTAg==
> =cfoH
> -END PGP SIGNATURE-
> 

Bug#1063142: tiny-initramfs: diff for NMU version 0.1-5.1

[Tobias Frost]

Control: tags 1063142 + pending


Dear maintainer,

I've sponsore an NMU, prepared by Victor Westerhuis, for tiny-initramfs
(versioned as 0.1-5.1) and uploaded it to DELAYED/5. Please feel free to
tell me if I should delay it longer.

Regards.

diff -Nru tiny-initramfs-0.1/debian/changelog tiny-initramfs-0.1/debian/changelog
--- tiny-initramfs-0.1/debian/changelog	2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/changelog	2024-02-11 11:48:39.0 +0100
@@ -1,3 +1,10 @@
+tiny-initramfs (0.1-5.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Decompress kernel modules included in initramfs. (Closes: #1063142)
+
+ -- Victor Westerhuis   Sun, 11 Feb 2024 11:48:39 +0100
+
 tiny-initramfs (0.1-5) unstable; urgency=medium
 
   [ Free Ekanayaka ]
diff -Nru tiny-initramfs-0.1/debian/control tiny-initramfs-0.1/debian/control
--- tiny-initramfs-0.1/debian/control	2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/control	2024-02-05 11:33:39.0 +0100
@@ -24,7 +24,7 @@
 Package: tiny-initramfs-core
 Architecture: linux-any
 Multi-Arch: foreign
-Depends: cpio, ${shlibs:Depends}, ${misc:Depends}
+Depends: cpio, xz-utils, ${shlibs:Depends}, ${misc:Depends}
 Built-Using: ${Built-Using}
 Description: Minimalistic initramfs implementation (core tools)
  A very minimalistic initramfs implementation for booting Linux
diff -Nru tiny-initramfs-0.1/debian/extra/functions tiny-initramfs-0.1/debian/extra/functions
--- tiny-initramfs-0.1/debian/extra/functions	2017-09-12 17:49:40.0 +0200
+++ tiny-initramfs-0.1/debian/extra/functions	2024-02-05 11:33:39.0 +0100
@@ -208,9 +208,18 @@
   fi
   /sbin/modprobe --all --ignore-install --set-version="${VERSION}" --quiet --show-depends "$@" | \
 awk '$1 == "insmod" { print; }' | while read dummy_type mod_file mod_options ; do
-mod_name=${mod_file##*/}
+mod_name=$(basename "$mod_file" | sed -E 's/(.*\.ko)(\..*)?/\1/')
+mod_compression=$(basename "$mod_file" | sed -E 's/(.*\.ko)(\..*)?/\2/')
 if ! grep -q ^/"${mod_name}" "${initramfs_dir}/modules" ; then
-  cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+  if [ "$mod_compression" = .xz ] ; then
+xzcat "${mod_file}" > "${initramfs_dir}/${mod_name}"
+  elif [ -z "$mod_compression" ] ; then
+cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+  else
+echo "$0: WARNING: unable to determine compression for modules while adding modules" >&2
+echo "YOUR SYSTEM MIGHT NOT BOOT WITH THIS INITRAMFS." >&2
+cp "${mod_file}" "${initramfs_dir}/${mod_name}"
+  fi
   printf "%s\n" "/${mod_name}${mod_options:+ $mod_options}" >> "${initramfs_dir}/modules"
 fi
   done


signature.asc
Description: PGP signature

Bug#1063847: minissdpd: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: minissdpd
Version: 1.6.0-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for minissdpd's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


minissdpd_1.6.0-2_pt.po.gz
Description: application/gzip

Bug#1063846: kwartz-client: [INTL:pt] Portuguese translation - debconf messages

[Américo Monteiro]

Package: kwartz-client
Version: 3.0-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for kwartz-client's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


kwartz-client_3.0-2_pt.po.gz
Description: application/gzip

Bug#1060995: FTBFS: make[1]: *** [debian/rules:10: override_dh_auto_build] Error 2)

[Abou Al Montacir]

Control: found -1 3.0+dfsg1-5
Control: notfound -1 3.0+dfsg1-4

-- 
Cheers,
Abou Al Montacir

Bug#1063845: unbound: Package 1.19.1 to fix CVE-2023-50387 and CVE-2023-50868

[Diederik de Haas]

Source: unbound
Version: 1.18.0-2
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Today 2 remote exploitable High Severity CVE's were published and
unbound has released version 1.19.1 to fix those.

Relevant links:
https://fosstodon.org/@nlnetlabs/111924266007688683
https://nlnetlabs.nl/news/2024/Feb/13/unbound-1.19.1-released/
https://kb.isc.org/docs/cve-2023-50387
https://kb.isc.org/docs/cve-2023-50868

I think a Release Critical Severity is more appropriate, but none of
the (by reportbug) presented options were applicable. It seems reportbug
then changed it to 'normal', which I manually changed to 'important'.

Fixing this bug would also fix bug #1051817, #1051818 and #1056631.

Link: https://bugs.debian.org/1051817
Link: https://bugs.debian.org/1051818
Link: https://bugs.debian.org/1056631

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZcuATAAKCRDXblvOeH7b
buedAP0QEqqGjjN4ZP8nu+WdKqrUWupLtsaN6FqEyNOd5OSp3QD/Wfh/sE5azFqf
99HKnBGhNVhrnxlNYIPlEjIns5pVDQs=
=thcd
-END PGP SIGNATURE-

Bug#1063844: iptables-persistent: In the flush_rules() function for IPv4 and IPv6, write a message when user-defined chains are found.

[Gabor Zsoldos]

Package: iptables-persistent
Version: 1.0.20
Severity: normal

Dear Maintainer,

When using user-defined chains in iptables, the netfilter-persistent flush 
command will write a message for each matching chain name like this:
iptables: Bad built-in chain name.

I suggest changing this regular expression in the flush_rules function of the 
15-ip4tables and 25-ip6tables scripts:
s/^:([A-Z]+).*/\1/p

to this:
s/^:([A-Z]+) [A-Z]+ .*/\1/p

This regular expression only captures the embedded chains, excluding 
user-defined chains, in the iptables-save output text.

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

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

Versions of packages iptables-persistent depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  iptables   1.8.9-2
ii  netfilter-persistent   1.0.20

iptables-persistent recommends no packages.

iptables-persistent suggests no packages.

-- debconf information excluded

Bug#1063843: python3-electrum: Upgrade to Electrum 4.5.2 from 4.4.6 causes installation of texlive packages

[Hernán Cabañas]

Package: python3-electrum
Version: 4.5.2+dfsg-1
Severity: normal
X-Debbugs-Cc: hcaban...@gmail.com

The new version of python3-electrum (4.5.2) recommends texlive-fonts-extra, 
which 
depends on texlive-base. All in all, installing (or upgrading) Electrum 
normally 
would install 2.3GB of packages that are not needed.

I deferred the upgrade, the following information is for python3-electrum 4.4.6.

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

Kernel: Linux 6.6.13-amd64 (SMP w/8 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 python3-electrum depends on:
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui 1.13.2+dfsg-1
ii  libjs-jquery-ui-theme-ui-lightness  1.12.1+dfsg-1.1
ii  libsecp256k1-1  0.2.0-2
ii  node-qrcode-generator   1.4.4+dfsg-3
ii  python3 3.11.6-1
ii  python3-aiohttp 3.9.1-1
ii  python3-aiohttp-socks   0.8.4-1
ii  python3-aiorpcx 0.22.1-2
ii  python3-attr23.2.0-1
ii  python3-bitstring   4.1.4-1
ii  python3-certifi 2023.11.17-1
ii  python3-cryptography41.0.7-3
ii  python3-dnspython   2.5.0-1
ii  python3-protobuf3.21.12-8+b1
ii  python3-qrcode  7.4.2-4

Versions of packages python3-electrum recommends:
ii  fonts-dejavu-core  2.37-8

Versions of packages python3-electrum suggests:
pn  python3-btchip  
pn  python3-trezor  

-- no debconf information