Bug#1078108: soapysdr-module-hackrf: Add Appstream metainfo announcing HW support

[Petter Reinholdtsen]

Package: soapysdr-module-hackrf
Version: 0.3.3-5
Tags: patch
User: p...@hungry.com
Usertags: appstream-modalias

Here is a patch to add Appstream metainfo XML announcing the hardware
handled by this package.

Including this information in the package will ensure programs mapping
hardware to packages using Appstream information, like the isenkram
package, will know that this package is useful on machines where the
hardware is discovered.

The appstream metadata file can be checked using this command after
package build:

  appstreamcli validate-tree  --no-net --explain debian/soapysdr-module-hackrf

The appstream metainfo is only added to the non-versioned package as it
seem like a more useful generic package to suggest for installation when
the handled hardware is present.

diff --git a/debian/patches/1000-appstream-metainfo.patch 
b/debian/patches/1000-appstream-metainfo.patch
new file mode 100644
index 000..3acd5f3
--- /dev/null
+++ b/debian/patches/1000-appstream-metainfo.patch
@@ -0,0 +1,65 @@
+Description: Added AppStream metainfo XML with hardware provide info.
+ This allow isenkram to propose this package when the relevant hardware
+ is present.
+Author: Petter Reinholdtsen
+Forwarded: no
+Last-Update: 2024-08-07
+---
+Index: soapyhackrf-salsa/com.github.pothosware.SoapyHackRF.metainfo.xml
+===
+--- /dev/null  1970-01-01 00:00:00.0 +
 soapyhackrf-salsa/com.github.pothosware.SoapyHackRF.metainfo.xml   
2024-08-07 08:50:05.019064163 +0200
+@@ -0,0 +1,53 @@
++
++
++  com.github.pothosware.SoapyHackRF
++  MIT
++  xserver-xorg-input-wacom
++  HackRF device support for SoapySDR (default version)
++  
++The Soapy HackRF project provides a SoapySDR hardware support
++module.  Using this, any program using SoapySDR to interface to
++software defined radio hardware can make use of the open source
++HackRF device to transmit and receive.
++  
++  https://github.com/pothosware/SoapyHackRF/wiki
++  
++usb:v046Ap0005d*
++usb:v046Ap0010d*
++usb:v046Ap003Ed*
++usb:v04E6p5111d*
++usb:v04E6p5115d*
++usb:v04E6p5116d*
++usb:v04E6p5117d*
++usb:v04E6pE001d*
++usb:v04E6pE003d*
++usb:v058Fp9540d*
++usb:v076Bp3821d*
++usb:v076Bp6622d*
++usb:v08E6p3437d*
++usb:v08E6p3438d*
++usb:v08E6p3478d*
++usb:v08E6p34C2d*
++usb:v08E6p34ECd*
++usb:v0BF8p1006d*
++usb:v0C4Bp0500d*
++usb:v0D46p2012d*
++usb:v1050p0111d*
++usb:v1050p0112d*
++usb:v1050p0115d*
++usb:v1050p0116d*
++usb:v1050p0404d*
++usb:v1050p0405d*
++usb:v1050p0406d*
++usb:v1050p0407d*
++usb:v1209p2440d*
++usb:v1A44p0920d*
++usb:v1FC9p81E6d*
++usb:v20A0p4107d*
++usb:v20A0p4108d*
++usb:v20A0p4109d*
++usb:v20A0p4211d*
++usb:v234Bpd*
++usb:v316Dp4C4Bd*
++  
++
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..42e8b1a
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+1000-appstream-metainfo.patch
diff --git a/debian/soapysdr-module-hackrf.install 
b/debian/soapysdr-module-hackrf.install
new file mode 100644
index 000..a53a036
--- /dev/null
+++ b/debian/soapysdr-module-hackrf.install
@@ -0,0 +1 @@
+com.github.pothosware.SoapyHackRF.metainfo.xml usr/share/metainfo

-- 
Happy hacking
Petter Reinholdtsen

Bug#1064408: [PATCH] duplicate aliased diversions for DEP17

[Roland Clobus]

Hello Helmut,

On 02/08/2024 15:48, Helmut Grohne wrote:

Hi Roland,

On Fri, Aug 02, 2024 at 03:01:51PM +0200, Roland Clobus wrote:

I've prepared a MR which takes a different approach.
https://salsa.debian.org/live-team/live-build/-/merge_requests/359


Thank you for working on this matter.


Since the support of live-build starts from bullseye, and symlinks are
present since then, should using only '/usr/X' be sufficient?


The unfortunate answer is "no". dpkg-diversions apply to the path as
seen by the dpkg database only and are not affected by symlinks such as
/bin -> usr/bin. Even if the symlink moves /bin/hostname to
/usr/bin/hostname, as long as hostname is still named as /bin/hostname
in the hostname package, it can only be diverted via /bin/hostname. As
long as you want to support bullseye or bookworm, the diversions should
be duplicated.


I was able to generate functional ISO images for bullseye, bookworm, trixie
and sid.


Despite me claiming your MR to be buggy, this test result of yours is
plausible.


Since the live-build scripts do no need an upgrade (they are used for fixed
version) do I need the doubled diversion?


You convey a very crucial bit of information in this question. The
diversions (doubled or not) are only really needed for upgrading. If you
just create a chroot and then replace a few files normally owned some
package and you never intend to use the package manager again, the
benefit of using a diversion becomes questionable. It is not clear to me
whether you install or upgrade packages after setting up diversions. If
you do, you should keep and double diversions (as long as bookworm is
supported in live-build). If you do not, you may just overwrite the
files without doing any diversions.


There is another bit of information that I didn't share yet: these 
diversions are only temporary. The diversions are made during the 
construction of the live image (when other packages are installed and 
the packages that have diversions will not upgrade), and reverted before 
the image is finalised. They are not present inside the live images. 
They 'only' serve the purpose of saving time by performing a no-op 
during the construction of the live image.


Since during the construction the symlinks work properly and there are 
no upgrades in the mean time, do we need to patch anything at all?



Also: do I need to update all shebangs from `/bin/sh` to `/usr/bin/sh` as
well?


Please don't. You already changed more places than I recommend to
change. What really needs to change is the placement of files in the
data.tar inside Debian binary packages (to eliminate aliasing problems).
As a result of this move, the diversions need to be duplicated. However,
accessing files can use either path and I recommend leaving such
references as is. We will forever rely on the aliasing links. For
instance, the dynamic loader explicitly uses an aliased path. Hence
there is little benefit in referencing files via their /usr paths.


Ah, I (erroneously) thought that the whole purpose of moving the files 
to /usr was to (eventually) get rid of the symlinks (in forky+N).


With kind regards,
Roland Clobus


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

[Helmut Grohne]

Hi Thorsten and Russ,

thanks for dissecting the disagreement. Your reply helped me better
understand what Thorsten probably sees as a problem.

On Tue, Aug 06, 2024 at 05:23:35PM -0700, Russ Allbery wrote:
> Second, you believe the existing migration strategy will not work safely
> for mksh because of the potential /bin/sh symlink.  Helmut, do you
> disagree with this?  I'm not sure I'm clear on the precise point of
> disagreement: is the argument a factual disagreement about the behavior of
> the tools and the upgrade process, or an argument about acceptable risk?

I was looking at this too narrowly from a mksh-perspective only and I
still think that the addition of dh_movetousr to mksh does not worsen
the situation on the mksh side. What I didn't see as clearly earlier is
that the way people tend to use mksh is by adding a local diversion for
/bin/sh and such a diversion is subject to DEP17 problems and in
particular, it is rendered ineffective by dash/0.5.12-9, which moves
/bin/sh to /usr/bin/sh. Say I have a bookworm system with mksh and
/bin/sh locally diverted. Now I upgrade dash to trixie. In that process,
dpkg will honour the diversion during deletion and then see that no
diversion affects the new location /usr/bin/sh happily overwriting
/usr/bin/sh (and via aliasing /bin/sh) breaking the user's earlier
choice to link /bin/sh to lksh.

> Both bash and dash have already done this migration; how did they handle
> this problem?  Presumably they are at least as widely used as /bin/sh as
> mksh is, and I don't recall this breaking people's systems.  Perhaps I
> missed those problems?

bash and dash earlier had a mechanism based on package-issued diversions
and debconf. I managed to remove this mechanism before the release of
bookworm and now the only supported way of changing /bin/sh is local
diversions. Indeed, bash and dash did not handle this at all as we
deemed messing with local diversions to be too much risk of getting the
user's intention wrong. Rather, we will be extending the release-notes
and add a section on local diversions asking users to duplicate them
before upgrading.

Given that diverting /bin/sh is a more common use case, I think it is
fair to add a check to dash.preinst for /bin/sh being diverted and
/usr/bin/sh not and in that case abort the upgrade giving users the
chance to fix their system before moving forward. I will be filing a bug
with a patch for dash later (hopefully today).

So thanks to your interaction, I now see how there is a problem for
mksh, but it is not introduced nor worsened by using dh_movetousr in
mksh.

> I don't think this is really open for discussion at the Policy Editor
> level since my understanding is that the CTTE has decided that this is how
> we're going to do the transition.  In the case where this approach risks
> harm to the user's system, obviously that is something that needs to be
> analyzed and appropriately addressed, but in the typical case, no, the
> files in the packages should move so that we get to the more predictable
> and easier-to-reason-about end state that was the goal of the migration
> fix adopted by the CTTE.

I don't think the CTTE has actually issued a ruling on DEP17 or
/usr-move short of repealing the moratorium in order to enable moving
forward. The initial DEP17 as I proposed it suggested leaving all files
in place and enabling dpkg to understand the aliasing. However, that is
not the solution that consensus emerged around. I then adopted and
pursued the /usr-move path that I perceived as reaching most agreement.
There are two occasions where this could be seen as having been vetted.
One is elaborate discussions on d-devel with consensus summaries that
have not been objected to. The other is a transition bug that has been
acknowledged by the release team. In any case, I do not think we can use
the CTTE to back up my proposed policy change.

Helmut

Bug#1078030: lpfc: lost all san paths

[Salvatore Bonaccorso]

Control: severity -1 important
Control: tags -1 + moreinfo

Hi

You seem to run an old version 6.1.76-1, so please upgrade to the most
recent kernel provided in Debian bookworm (6.1.99-1).

On Tue, Aug 06, 2024 at 09:36:10AM +0200, Daniel Ufer wrote:
> Package: src:linux
> Version: 6.1.76-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation? -> normal usage, system is a postgresql 
> database host
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? -> reboot of the system fixed the problem
>* What was the outcome of this action? 
>* What outcome did you expect instead?

As we have only very little information here: Can you consistently
reproduce the issue under the specific workload with the current
6.1.99-1 in bookworm?

Regards,
Salvatore

Bug#1071970: pcre3 should not be part of trixie

[Matthew Vernon]

Hi,

On 07/08/2024 06:18, Paul Gevers wrote:

On 06-08-2024 23:33, Bastian Germann wrote:

I am including a patch to drop the libpcre3-udeb.
Please consider applying so that the package can be autoremoved.


Please don't do that until you have approval from d-i. I included them 
in the mail chain. If the udeb is used by d-i, that needs to be resolved 
first.


Noted, although I'm pretty sure d-i moved to pcre2 a while back now.

Regards,

Matthew

Bug#1078109: linux-image-6.10.3-amd64: No WiFi When Booting with linux-image-6.10.3-amd64

[Kurt Meyer]

Package: src:linux
Version: 6.10.3-1
Severity: normal
X-Debbugs-Cc: yahweh19...@hailmail.net

Dear Maintainer,

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

- What led up to the situation?

When booting my computer after the linux-image-6.10.3-amd64 upgrade, I had no 
WiFi access and WiFi was not even listed as an option from 
network-manager-gnome. WiFi has not worked on my computer with any kernel 
upgrades since the linux-image-6.6.15-amd64 kernel, so the issue may have 
started with that kernel.

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

WiFi works when I boot with the linux-image-6.6.13-amd64 kernel.

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

** Model information
sys_vendor: ASUSTeK Computer INC.
product_name: ET2321I
product_version: 0801
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: 0801
board_vendor: ASUSTeK COMPUTER INC.
board_name: ET2321I
board_version: Rev 1.xx

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback


** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller 
[8086:0a04] (rev 09)
Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: hsw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT 
Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA 
controller])
DeviceName:  Onboard IGD
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller 
[8086:0a0c] (rev 09)
Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:04.0 Signal processing controller [1180]: Intel Corporation Haswell-ULT 
Thermal Subsystem [8086:0a03] (rev 09)
Subsystem: Intel Corporation Device [8086:2010]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device_pci_legacy

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

00:16.0 Communication controller [0780]: Intel Corporation 8 Series HECI #0 
[8086:9c3a] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:1b.0 Audio device [0403]: Intel Corporation 8 Series HD Audio Controller 
[8086:9c20] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:85ac]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 1 
[8086:9c10] (rev e4) (prog-if 00 [Normal decode])
Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 3 
[8086:9c14] (rev e4) (prog-if 00 [Normal decode])
Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series PCI Express Root Port 4 
[8086:9c16] (rev e4) (prog-if 00 [Normal decode])
Subsystem: ASUSTeK Computer Inc. Device [1043:8534]
Control

Bug#1078030: AW: Bug#1078030: lpfc: lost all san paths

[Daniel.Ufer]

Hello Salvatore,

thanks for looking into this issue. This issue appeared on 2 different systems, 
who are running on the same hardware and the same software. After the issue 
occurred on the first system, we realized  a week later that the second server 
developed the same problem. We managed to reboot the second server before the 
postgresql service crashed. Unfortunately I have no further logs.
The problem occurred out of  the blue, there was no change involved. That's why 
we cannot reproduce the issue.
We are going to update the kernel package in the next few days.


Regards, Daniel


-Ursprüngliche Nachricht-
Von: Salvatore Bonaccorso  
Gesendet: Mittwoch, 7. August 2024 09:00
An: Daniel Ufer ; 1078...@bugs.debian.org
Betreff: Re: Bug#1078030: lpfc: lost all san paths

Control: severity -1 important
Control: tags -1 + moreinfo

Hi

You seem to run an old version 6.1.76-1, so please upgrade to the most recent 
kernel provided in Debian bookworm (6.1.99-1).

On Tue, Aug 06, 2024 at 09:36:10AM +0200, Daniel Ufer wrote:
> Package: src:linux
> Version: 6.1.76-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where 
> appropriate ***
> 
>* What led up to the situation? -> normal usage, system is a postgresql 
> database host
>* What exactly did you do (or not do) that was effective (or
>  ineffective)? -> reboot of the system fixed the problem
>* What was the outcome of this action? 
>* What outcome did you expect instead?

As we have only very little information here: Can you consistently reproduce 
the issue under the specific workload with the current
6.1.99-1 in bookworm?

Regards,
Salvatore

Bug#1078110: ITP: python-aionanoleaf -- async Python package for the Nanoleaf API

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-aionanoleaf
  Version : 0.2.1
  Upstream Contact: Milan Meulemans 
* URL : https://github.com/milanmeu/aionanoleaf
* License : LGPL3+
  Programming Lang: Python
  Description : async Python package for the Nanoleaf API

 async Python package for the Nanoleaf API.
 .
 This package is a dependency of Home Assistant.

I intend to maintain this package under the Home Assistant team.

Bug#1078109: linux-image-6.10.3-amd64: No WiFi When Booting with linux-image-6.10.3-amd64

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Kurt,

On Wed, Aug 07, 2024 at 03:17:26AM -0400, Kurt Meyer wrote:
> Package: src:linux
> Version: 6.10.3-1
> Severity: normal
> X-Debbugs-Cc: yahweh19...@hailmail.net
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
> - What led up to the situation?
> 
> When booting my computer after the linux-image-6.10.3-amd64 upgrade,
> I had no WiFi access and WiFi was not even listed as an option from
> network-manager-gnome. WiFi has not worked on my computer with any
> kernel upgrades since the linux-image-6.6.15-amd64 kernel, so the
> issue may have started with that kernel.
> 
> - What exactly did you do (or not do) that was effective (or ineffective)?
> 
> WiFi works when I boot with the linux-image-6.6.13-amd64 kernel.

Since you have two versions in same stable series, 6.6.13 (working)
and 6.6.15 (not working), would you be able to bisect these upstream
versions to see which commit(s) break it?

Regards,
Salvatore

Bug#953091: RFA: colorhug-client -- Tools for the Hughski Colorimeter

[Petter Reinholdtsen]

Any news on the orphaning?

I notice there is a git repository on
https://salsa.debian.org/debian/colorhug-client >.  As far as I
can tell, there is only the master branch, not any upstream or
pristine-tar branch.

I had a look to update the appstream metainfo of this package.  Will
send a patch based on the unstable edition instead of the git edition.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1077768: ui-utilcpp: patch for new recode version

[Gianfranco Costamagna]

Package: ui-utilcpp
Followup-For: Bug #1077768


Dear Maintainer,

I tested a patch based on the upstream removal of strategy struct parameter.

  * Drop strategy (Closes: #1077768)


Thanks for considering the patch.

diff -Nru ui-utilcpp-1.10.3/debian/patches/drop-strategy.patch 
ui-utilcpp-1.10.3/debian/patches/drop-strategy.patch
--- ui-utilcpp-1.10.3/debian/patches/drop-strategy.patch1970-01-01 
01:00:00.0 +0100
+++ ui-utilcpp-1.10.3/debian/patches/drop-strategy.patch2024-08-07 
08:46:33.0 +0200
@@ -0,0 +1,15 @@
+Description: strategy was removed in 
https://github.com/rrthomas/recode/commit/76d7efd2d6c9dfa81270401a346c27c52a9e7f11
+Author: Gianfranco Costamagna 
+Bug-Debian: https://bugs.debian.org/1077768
+Last-Update: 2024-08-07
+
+--- ui-utilcpp-1.10.3.orig/src/ui-utilcpp/Recoder.cpp
 ui-utilcpp-1.10.3/src/ui-utilcpp/Recoder.cpp
+@@ -154,7 +154,6 @@ Conversion const * LibRecodeConverter::m
+   :task_(::recode_new_task(request))
+   {
+   // Task config
+-  task_->strategy = RECODE_SEQUENCE_IN_MEMORY;
+   task_->fail_level = sloppy ? RECODE_INVALID_INPUT : 
RECODE_NOT_CANONICAL;
+
+   task_->input.buffer = buf;
diff -Nru ui-utilcpp-1.10.3/debian/patches/series 
ui-utilcpp-1.10.3/debian/patches/series
--- ui-utilcpp-1.10.3/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ ui-utilcpp-1.10.3/debian/patches/series 2024-08-07 08:45:44.0 
+0200
@@ -0,0 +1 @@
+drop-strategy.patch

However with this patch the testsuite now hangs, not sure if this is related or 
not.

G.

Bug#1070104: termshark: please add support for loong64

[wuruilong]

Source: termshark
Version: 2.4.0-1
Followup-For: Bug #1070104
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

The termshark software blocks many packages from continuing to compile, so 
maintainers can merge this patch?

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

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

Bug#1074303: Re: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian

[pham...@bluewin.ch]

Hello,
Listen, I followed your instructions 3x. And 3 times you tell me it's not 
right!?!?
If you are not able to give me correct instructions, you should seriously 
question yourself and consider stopping providing user support, because if you 
don't have the time or patience to take care of it properly, it harms everyone 
including you.
I have applied to the letter the commands you asked me to perform. I just have 
the feeling that you don't care... If you are not able to tell me exactly what 
to do, as is the case, I think it is not worth continuing to waste my time, and 
I sincerely suggest you pass the baton to someone else who is more 
pedagogical...
Greetings.
Message d'origine
De : bi...@debian.org
Date : 06/08/2024 - 18:28 (E)
À : pham...@bluewin.ch, 1074...@bugs.debian.org
Cc : m...@dorfdsl.de
Objet : Re: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when 
booting Debian
Am 06.08.24 um 10:15 schrieb pham...@bluewin.ch: > I hope that this time you 
have the necessary information to work on this > problem. Nope, this is (again) 
not a trace log, thus not possible to make anything useful out of it. For the 
third and last time: read the NetworkManager man page, section "DEBUGGING" and 
follow those instructions. 

Bug#1078111: azure-cli - does telemetry upload without asking the user

[Bastian Blank]

Package: azure-cli
Version: 2.63.0-1
Severity: serious
X-Debbugs-Cc: wa...@debian.org

Using an empty config, the debug output of "az" calls shows this:

| cli.azure.cli.__main__: Command ran in 0.598 seconds (init: 0.103, invoke: 
0.495)
| telemetry.main: Begin splitting cli events and extra events, total events: 1
| telemetry.client: Accumulated 0 events. Flush the clients.
| telemetry.main: Finish splitting cli events and extra events, cli events: 1
| telemetry.save: Save telemetry record of length 3823 in cache
| telemetry.main: Begin creating telemetry upload process.
| telemetry.process: Creating upload process: "/usr/bin/python3 
/usr/lib/python3/dist-packages/azure/cli/telemetry/__init__.py 
/home/bastian/.azure"
| telemetry.process: Return from creating process
| telemetry.main: Finish creating telemetry upload process.

As telemetry is not fundamental for the functioning of the program, it
needs to get user approval first.

Bastian

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

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

Versions of packages azure-cli depends on:
ii  python33.12.3-1
ii  python3-azure-cli  2.63.0-1

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

Bug#1078112: libio-digest-perl: warns on usage with Perl 5.40: Attempt to call undefined import method with arguments

[Niko Tyni]

Package: libio-digest-perl
Version: 0.11-4
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This module warns on usage with Perl 5.40 (currently in experimental).
This causes an autopkgtest regression.

  https://ci.debian.net/packages/libi/libio-digest-perl/unstable/amd64/50044480/

  $ perl -e 'use IO::Digest'
  Attempt to call undefined import method with arguments ("0.10") via package 
"PerlIO::via::dynamic" (Perhaps you forgot to load the package?) at 
/usr/share/perl5/IO/Digest.pm line 5.


Information on the new warning can be found at

  
https://metacpan.org/dist/perl/view/pod/perldelta.pod#Calling-the-import-method-of-an-unknown-package-produces-a-warning

-- 
Niko Tyni   nt...@debian.org

Bug#1078113: libhtml-stripscripts-perl: autopkgtest regression with Perl 5.40: syntax.t failure

[Niko Tyni]

Package: libhtml-stripscripts-perl
Version: 1.06-4
Severity: important
Tags: trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This package fails its autopkgtest checks with Perl 5.40 (currently
in experimental.)

  
https://ci.debian.net/packages/libh/libhtml-stripscripts-perl/unstable/amd64/50044348/

This is because of an intentional behaviour change in Perl 5.40:

  
https://metacpan.org/dist/perl/view/pod/perldelta.pod#Changes-to-Existing-Diagnostics

Name "%s::%s" used only once: possible typo

This warning now honors being marked as fatal. [GH #13814]

  See https://github.com/Perl/perl5/issues/13814 for more information.

Now, /usr/share/perl5/HTML/StripScripts.pm

  use warnings FATAL => 'all';

so the warning now correctly causes the check to exit with an error code.

A fix might be to add "no warnings 'once';" to the block where the
offending variable is used.

-- 
Niko Tyni   nt...@debian.org

Bug#1078077: jupyterlab: Fail to get yarn configuration. node:internal/modules/cjs/loader:1148

[PICCA Frederic-Emmanuel]

the packaging of the next version is done here

https://salsa.debian.org/js-team/node-jupyterlab

in the branch merge-python-and-node

to build it

git clone -b merge-python-and-node 
https://salsa.debian.org/js-team/node-jupyterlab

and

cd node-jupyterlab

gbp buildpackage --git-ignore-branch \
  --git-builder="sbuild -s --build-dep-resolver=aspcud \
  -j8 --no-apt-update -d unstable -c unstable-amd64-sbuild \
  --no-clean-source --no-run-lintian --source-only-changes " \
  --git-export=WC

and voila

Bug#1078114: libmasonx-interp-withcallbacks-perl: warns on usage with Perl 5.40: Attempt to call undefined import method with arguments

[Niko Tyni]

Package: libmasonx-interp-withcallbacks-perl
Version: 1.19-4
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This module warns on usage with Perl 5.40 (currently in experimental).
This causes an autopkgtest regression.

  
https://ci.debian.net/packages/libm/libmasonx-interp-withcallbacks-perl/unstable/amd64/50044773/

  $ perl -e 'use MasonX::Interp::WithCallbacks'
  Attempt to call undefined import method with arguments ("1.23") via package 
"HTML::Mason" (Perhaps you forgot to load the package?) at 
/usr/share/perl5/MasonX/Interp/WithCallbacks.pm line 4.

Information on the new warning can be found at

  
https://metacpan.org/dist/perl/view/pod/perldelta.pod#Calling-the-import-method-of-an-unknown-package-produces-a-warning

-- 
Niko Tyni   nt...@debian.org

Bug#1078030: AW: Bug#1078030: lpfc: lost all san paths

[Salvatore Bonaccorso]

Control: tags -1 - moreinfo

Hi Daniel,

On Wed, Aug 07, 2024 at 07:14:16AM +, daniel.u...@telekom.de wrote:
> Hello Salvatore,
> 
> thanks for looking into this issue. This issue appeared on 2
> different systems, who are running on the same hardware and the same
> software. After the issue occurred on the first system, we realized
> a week later that the second server developed the same problem. We
> managed to reboot the second server before the postgresql service
> crashed. Unfortunately I have no further logs.
> The problem occurred out of  the blue, there was no change involved.
> That's why we cannot reproduce the issue.
> We are going to update the kernel package in the next few days.

Thanks for quickly reporting back already.

So please du upgrade to the latest kernel, and then report back if you
still encountered the issue. If you are able to collect kernel logs
that would be helpful for the lpfc maintainers in case we have
something to be forwarded.

Regards,
Salvatore

Bug#1078115: azure-cli - fails to get access token: User 'X' does not exist in MSAL token cache

[Bastian Blank]

Package: azure-cli
Version: 2.63.0-1
Severity: important
X-Debbugs-Cc: wa...@debian.org

Some process of the cloud team rely to "az account get-access-token" to
get access to some parts of Azure, without re-implementing all the
oidc and other stuff.

With a brand new config and after using "az login" to login with exactly
the mentioned user, this now fails with:
| % az account get-access-token
| User 'wa...@spi-inc.org' does not exist in MSAL token cache. Run `az login`.
| % grep waldi@spi ~/.azure/msal_token_cache.json 
|"username": "wa...@spi-inc.org",

Bastian

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

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

Versions of packages azure-cli depends on:
ii  python33.12.3-1
ii  python3-azure-cli  2.63.0-1

azure-cli recommends no packages.

azure-cli suggests no packages.

-- no debconf information

Bug#1064408: [PATCH] duplicate aliased diversions for DEP17

[Helmut Grohne]

Hi Roland,

On Wed, Aug 07, 2024 at 09:00:47AM +0200, Roland Clobus wrote:
> There is another bit of information that I didn't share yet: these
> diversions are only temporary. The diversions are made during the
> construction of the live image (when other packages are installed and the
> packages that have diversions will not upgrade), and reverted before the
> image is finalised. They are not present inside the live images. They 'only'
> serve the purpose of saving time by performing a no-op during the
> construction of the live image.

As far as I understand the code, your construction applies to multiple
releases at the same time and for each release I would agree that you
only need one diversion. The need for duplicating the diversions arises
from different releases requiring different diversions. In principle,
you could also carry forward a variable say USR_MOVED that you set to ""
for bookworm and earlier and to "/usr" for trixie and later and then
prepend this to your diversions.

If you were to use the /usr-moved
diversions on a bookworm or earlier tree, they have the same effect as
doing nothing. In particular, you are expecting the relevant file to be
renamed (via --rename). So your diversion would apparently work, but it
would not actually move the diverted file out of place. Then you
overwrite the diverted file and when you remove the diversion you expect
to get back the original file, but instead you keep your temporary
changes.

I note that if live-build in forky also wants to support bookworm, the
"begin-remove-after: trixie" I used in my patch should be bumped to
"begin-remove-after: forky". The main benefit I see in my approach is
that it becomes simpler to eventually remove this compatibility code as
it is clearly identified when to remove what code in a machine-readable
way and the Debian janitor will be able to create merge requests
cleaning up this code. That said, you may prefer another implementation
and that's fine.

> Ah, I (erroneously) thought that the whole purpose of moving the files to
> /usr was to (eventually) get rid of the symlinks (in forky+N).

It is difficult to strike a good balance on how much detail we give. Too
much text and people stop reading. Too little and misunderstandings
happen. The fundamental reason for the moves is that we experienced bugs
(file loss) as a result of exercising undefined behaviour in dpkg and in
moving files from / to /usr (in data.tar of binary .debs), we operate
dpkg within its specification again reducing the risk of unexpected file
loss. As mentioned in my previous reply, the referencing of files
remains unaffected - except when the references apply to the dpkg
database as diversions do.

Hope this clarifies. Thanks for bearing with this transition.

Helmut

Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

[Helmut Grohne]

Hi Thorsten,

On Tue, Aug 06, 2024 at 09:58:44PM +, Thorsten Glaser wrote:
> I’m veto’ing this.

I see that Russ is kindly handling this. Thanks to him.

> >This relies on undefined behaviour in dpkg. Guillem is working on
> >improving metadata tracking and accurately tracking metadata will make
> >this break. It is not enough to rely on the implicit essential
> >dependency.
> 
> Then the tracking could be aware of this and DTRT.

Aliasing is unsupported in dpkg and has never been. We are currently
working in an undefined-behaviour area and the main goal of the
/usr-move transition is to get us into defined-behaviour waters. While I
appreciate that metadata tracking could eventually support aliasing use
cases, that is not planned for the initial implementation as aliasing
never has been supported.

> And that works how? By diverting the files away temporarily,
> leaving users with a dangling /bin/sh symlink during the pak‐
> kage upgrade which almost certainly will lead to a failing
> upgrade which will leave the user with a hosed system.

dh_movetousr does not manage any dpkg diversions. All that it does is
move the files inside the .deb's data.tar. Despite you having expressed
quite some words on the prospective failure case at hand, I am
difficulties turning this into a reproducer. Can you try to sketch a
possible interaction with dpkg and a hypothetically /usr-moved mksh
package that would lead into such a failure?

Note that I already understood the issue about a local dpkg diversion of
/bin/sh being rendered ineffective (DEP17 P3). This is a problem that
already affects mksh right now regardless of these bugs and that I
intend to handle separately regardless of these matters. It is not
something that would cause a failed upgrade though and therefore I am
expecting that you are referring to a different problem here.

> As an issue reporter, there comes a time when you are of the
> opinion that what you opened is a bug, but the maintainer dis‐
> agrees. This is such a case. This is not a bug in mksh, and
> even if it were, the fix would lead to broken users’ systems
> and therefore isn’t worth it. Alternative ways to fix this,
> #2 in dpkg and #1 is currently a nōn-issue (and if dpkg’s new
> metadata tracking is being written, it can be written to account
> for this, as I have the right of having been here first).

In case of disagreement of what constitutes a bug we have two
arbitration mechanisms. For one thing, the release team defines what is
considered a release-critical bug and they can override the decision of
a package maintainer. I expect the release team to back up my view that
this is a release-critical bug in mksh and pax given that the release
team agreed to my transition bug. The other route is escalating to the
CTTE. Given earlier rulings of the CTTE, I expect a likely outcome even
though I would abstain from voting if this were to come onto the CTTE. I
again ask you to reopen the bugs and suggest that we can skip involving
those teams that way.

As the discussion of the matter is ongoing and new insights are gained,
I do not expect you to fix the bugs soon. We should find a resolution
before the transition freeze though.  You may also express the ongoing
discussion by adding a moreinfo tag. The meaning of the bugs in this
case is expressing the need for change without having agreed on what
change that is.

Thanks for considering

Helmut

Bug#1073754: raising severity of /usr-move bugs (DEP17)

[Helmut Grohne]

Hi Tai,

On Wed, Aug 07, 2024 at 02:00:00AM +0200, Taihsiang Ho (tai271828) wrote:
> Thanks for the update. I am the maintainer of package rasdaemon and
> was working on the DEP-17 related issue for rasdaemon Bug#1073754
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073754 . We have
> uploaded our fix based on the suggested "manual move" solution to Sid
> with rasdaemon 0.8.1-2, and closed the corresponding bug. To my
> understanding, we don't have anything incompleted. I could be wrong.
> If I am wrong, would you mind telling me what else I, the maintainer
> of package rasdaemon, should still do? Thank you.

Thank you for asking. Even though I raised the severity of this bug,
that does not affect its closure state. You are correct that it is
marked as fixed in unstable. I selected all bugs that affected trixie or
unstable yesterday and at that time rasdaemon was not fixed in trixie as
it did not migrate yet. The bug still affected trixie and it very
briefly became rc-buggy in trixie until it migrated. There is nothing
more to do now.

Thank you

Helmut

Bug#1078116: libsignal-mask-perl: autopkgtest regression with Perl 5.40: syntax.t failure

[Niko Tyni]

Package: libsignal-mask-perl
Version: 0.008-3
Severity: important
Tags: trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This package fails its autopkgtest checks with Perl 5.40 (currently
in experimental.)

  
https://ci.debian.net/packages/libs/libsignal-mask-perl/unstable/amd64/50045830/

 72s # Subtest: all modules in libsignal-mask-perl pass the syntax check
 72s 1..2
 72s # Name "Signal::Mask" used only once: possible typo at 
/usr/share/perl5/Signal/Mask.pm line 22.
 72s not ok 1 - /usr/bin/perl -wc /usr/share/perl5/Signal/Mask.pm exited 
successfully
 72s # Name "Signal::Pending" used only once: possible typo at 
/usr/share/perl5/Signal/Pending.pm line 13.
 72s not ok 2 - /usr/bin/perl -wc /usr/share/perl5/Signal/Pending.pm exited 
successfully
 72s not ok 4 - all modules in libsignal-mask-perl pass the syntax check
 72s Dubious, test returned 1 (wstat 256, 0x100)
 72s Failed 1/4 subtests 

This is because of an intentional behaviour change in Perl 5.40:

  
https://metacpan.org/dist/perl/view/pod/perldelta.pod#Changes-to-Existing-Diagnostics

Name "%s::%s" used only once: possible typo

This warning now honors being marked as fatal. [GH #13814]

  See https://github.com/Perl/perl5/issues/13814 for more information.

Now, /usr/share/perl5/Signal/Mask.pm and /usr/share/perl5/Signal/Pending.pm have

  use warnings FATAL => 'all';

so the warning now correctly causes the check to exit with an error code.

A fix might be to add "no warnings 'once';" to the block where the
offending variable is used.

-- 
Niko Tyni   nt...@debian.org

Bug#1078083: transition: ace

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 06/08/2024 20:00, Sudip Mukherjee wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: sudipm.mukher...@gmail.com
Control: affects -1 + src:ace

Hi,

Small transition with only two affected packages: diagnostics, ivtools,

Confirmed with a testbuild that both reverse dependencies builds fine
with ace 8.0.1+dfsg-1 in experimental.

The autogenerated ben tracker looks good. Please consider 'ace' for
transition.


Go ahead.

Emilio

Bug#1078117: libtest-expander-perl: autopkgtest regression with Perl 5.40: syntax.t failure

[Niko Tyni]

Package: libtest-expander-perl
Version: 2.5.0-2
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This package fails its autopkgtest checks with Perl 5.40 (currently
in experimental.)

  
https://ci.debian.net/packages/libt/libtest-expander-perl/unstable/amd64/50046161/

 89s # Subtest: all modules in libtest-expander-perl pass the syntax check
 89s 1..2
 89s ok 1 - /usr/bin/perl -wc /usr/share/perl5/Test/Expander/Constants.pm 
exited successfully
 89s # Name "Test::Expander::BAIL_OUT" used only once: possible typo at 
/usr/share/perl5/Test/Expander.pm line 83.
 89s not ok 2 - /usr/bin/perl -wc /usr/share/perl5/Test/Expander.pm exited 
successfully
 89s not ok 4 - all modules in libtest-expander-perl pass the syntax check
 89s Dubious, test returned 1 (wstat 256, 0x100)
 89s Failed 1/4 subtests 

This is because of an intentional behaviour change in Perl 5.40:

  
https://metacpan.org/dist/perl/view/pod/perldelta.pod#Changes-to-Existing-Diagnostics

Name "%s::%s" used only once: possible typo

This warning now honors being marked as fatal. [GH #13814]

  See https://github.com/Perl/perl5/issues/13814 for more information.

Now, /usr/share/perl5/Test/Expander.pm does

  use warnings FATAL => 'all';

so the warning now correctly causes the check to exit with an error code.

A fix might be to add "no warnings 'once';" to the block where the
offending variable is used.

-- 
Niko Tyni   nt...@debian.org

Bug#1078118: libuniversal-exports-perl: warns on usage with Perl 5.40: Subroutine UNIVERSAL::import redefined

[Niko Tyni]

Package: libuniversal-exports-perl
Version: 0.05-4
Severity: important
Tags: trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This module warns on usage with Perl 5.40 (currently in experimental).
This causes an autopkgtest regression.

  
https://ci.debian.net/packages/libu/libuniversal-exports-perl/unstable/amd64/50046521/

  $ perl -e 'use UNIVERSAL::exports'
  Subroutine UNIVERSAL::import redefined at /usr/share/perl5/Exporter/Lite.pm 
line 56.

Apparently UNIVERSAL has started to define an 'import' method, as mentioned in

  
https://metacpan.org/dist/perl/view/pod/perldelta.pod#Calling-the-import-method-of-an-unknown-package-produces-a-warning

-- 
Niko Tyni   nt...@debian.org

Bug#1078119: libvm-ec2-perl: warns on usage with Perl 5.40: Attempt to call undefined import method with arguments

[Niko Tyni]

Package: libvm-ec2-perl
Version: 1.28-4
Severity: important
Tags: trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This module warns on usage with Perl 5.40 (currently in experimental).
This causes an autopkgtest regression.

  https://ci.debian.net/packages/libv/libvm-ec2-perl/unstable/amd64/50046581/
  
  $ perl -e 'use VM::EC2'
  Attempt to call undefined import method with arguments ("") via package 
"VM::EC2" (Perhaps you forgot to load the package?) at 
/usr/share/perl5/VM/EC2/ParmParser.pm line 4.
  Attempt to call undefined import method with arguments ("tag") via package 
"VM::EC2" (Perhaps you forgot to load the package?) at 
/usr/share/perl5/VM/EC2/Generic.pm line 58.

Information on the new warning can be found at

  
https://metacpan.org/dist/perl/view/pod/perldelta.pod#Calling-the-import-method-of-an-unknown-package-produces-a-warning

-- 
Niko Tyni   nt...@debian.org

Bug#1073289: Bug#1073983: transition: ocaml

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 25/07/2024 10:54, Emilio Pozuelo Monfort wrote:

On 17/07/2024 21:56, Adrian Bunk wrote:

On Wed, Jul 17, 2024 at 11:28:04AM +0200, Emilio Pozuelo Monfort wrote:

On 16/07/2024 13:16, Adrian Bunk wrote:

On Tue, Jul 16, 2024 at 10:25:43AM +0200, Stéphane Glondu wrote:

Hi,


Hi Stéphane,


Le 27/06/2024 à 11:38, Stéphane Glondu a écrit :

The remaining unknowns are llvm-toolchain-{14,15,16,17,18}... [...]


I've done a rebuild of the OCaml universe with yesterday's unstable
(mostly). The "missing" packages are the same, but the llvm-toolchain-16
build got far enough to FTBFS because of OCaml 5.2.0. This is likely to
affect llvm-toolchain-{14,15} as well, but might be fixed in newer versions.
I've reported bugs accordingly.


[...] Worst case scenario: the OCaml bindings can be disabled (they
don't have reverse dependencies in Debian).


I still think this is the best course of action.


looking at [1] this might be the only reasonable course of action for LLVM < 
17.


Disabling them sounds fine (specially for 14 which is no longer in testing
and 15 which we're trying to get rid of), but ideally it can be done ahead
of the start in order to prevent delays with the transition.

Other than that, I'm happy with the current state and we could go ahead. So
if you can get those bindings disabled, then I think we can go ahead.


I tried looking at that, but this "ideally" is in level 15 of the ocaml
transition.

The bindings are already enabled only on some architectures, uploads to
disable them everywhere are trivial while it's a pain to test any changes
without the first 14 levels of the transition.

It would really be much easier to have the binNMUs scheduled and then
fix LLVM.


If by fixing you mean disabling the ocaml bindings, then I'm not sure why it 
needs to happen after the binNMUs. If you mean actually fixing the bindings so 
they work with the new ocaml, then sure, that's fine.


I see that autopkgtests are being run and some issues are being spotted. I'm 
starting the gsl transition first, let's do this one after gsl (hopefully it 
will be straightforward).


That one is done. Let's go ahead with this one.

Cheers,
Emilio

Bug#1078120: bullseye-pu: package nvidia-graphics-drivers-tesla-418/418.226.00-6~deb11u2

[Andreas Beckmann]

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

[ Reason ]
Two commits from Linux 6.8 got backported to Linux 6.1, but only one
of them got backported to Linux 5.10, causing the use of GPL-only
symbols (on ppc64el only) from 5.10.210 onwards.
We already had fixed this in the previous point release in
  nvidia-graphics-drivers 470.256.02-2 and
  nvidia-graphics-drivers-tesla-470 470.256.02-1~deb11u2
but the Tesla 418/450/460 packages are affected as well.

[ Impact ]
dkms module failing to build on ppc64el

[ Tests ]
Manual module build test in bullseye ppc64el chroot.
The package has autopkgtest-pkg-dkms, but that is not run by
dkms/bullseye.

[ Risks ]
Low. The changes have already been tested in the 470 driver series.

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

[ Changes ]
+nvidia-graphics-drivers-tesla-418 (418.226.00-6~deb11u2) bullseye; 
urgency=medium
+
+  * Cherry-pick ppc64el changes from 418.226.00-16.
+  * Backport pfn_valid changes in nv-mmap.c from 470.239.06.
+  * ppc64el: Use pfn_valid() variant with rcu_read_{,un}lock_sched() for
+Linux 5.10 from 5.10.210 onwards to avoid using GPL symbols.
+
+ -- Andreas Beckmann   Sun, 04 Aug 2024 16:41:41 +0200

[ Other info ]
I'm not rebuilding the package from sid this time since that contains
some changes not suitable for bullseye as I had not expected to need
updating the package again in bullseye after it got EoLed upstream.

I'm going to upload this change right now.


Andreas
diff --git a/debian/changelog b/debian/changelog
index 45fd50b05..414961dc3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+nvidia-graphics-drivers-tesla-418 (418.226.00-6~deb11u2) bullseye; 
urgency=medium
+
+  * Cherry-pick ppc64el changes from 418.226.00-16.
+  * Backport pfn_valid changes in nv-mmap.c from 470.239.06.
+  * ppc64el: Use pfn_valid() variant with rcu_read_{,un}lock_sched() for
+Linux 5.10 from 5.10.210 onwards to avoid using GPL symbols.
+
+ -- Andreas Beckmann   Sun, 04 Aug 2024 16:41:41 +0200
+
 nvidia-graphics-drivers-tesla-418 (418.226.00-6~deb11u1) bullseye; 
urgency=medium
 
   * Rebuild for bullseye.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 415779ad1..31f6e0c17 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = tesla-418/master
+debian-branch = tesla-418/bullseye
 
 [buildpackage]
 overlay = True
diff --git 
a/debian/module/debian/patches/0036-backport-pfn_valid-changes-in-nv-mmap.c-from-470.239.patch
 
b/debian/module/debian/patches/0036-backport-pfn_valid-changes-in-nv-mmap.c-from-470.239.patch
new file mode 100644
index 0..330122f5c
--- /dev/null
+++ 
b/debian/module/debian/patches/0036-backport-pfn_valid-changes-in-nv-mmap.c-from-470.239.patch
@@ -0,0 +1,39 @@
+From 63d49836d41809282dce33126a0117d51d1d6834 Mon Sep 17 00:00:00 2001
+From: Andreas Beckmann 
+Date: Sun, 25 Feb 2024 09:38:15 +0100
+Subject: [PATCH] backport pfn_valid changes in nv-mmap.c from 470.239.06
+
+---
+ nvidia/nv-mmap.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/nvidia/nv-mmap.c b/nvidia/nv-mmap.c
+index 29ac828..af53116 100644
+--- a/nvidia/nv-mmap.c
 b/nvidia/nv-mmap.c
+@@ -13,6 +13,7 @@
+ 
+ #include "os-interface.h"
+ #include "nv-linux.h"
++#include "nv-ibmnpu.h"
+ #include "nv_speculation_barrier.h"
+ 
+ extern nv_cpu_type_t nv_cpu_type;
+@@ -461,11 +462,10 @@ int nvidia_mmap_helper(
+ // 
+ // This path is similar to the sysmem mapping code. 
+ // TODO: Refactor is needed as part of bug#2001704.
+-// Use pfn_valid to determine whether the physical address has
+-// backing struct page. This is used to isolate P8 from P9. 
+ //
+-if (!IS_REG_OFFSET(nv, access_start, access_len) && 
+-(pfn_valid(PFN_DOWN(mmap_start
++nv_linux_state_t *nvl = NV_GET_NVL_FROM_NV_STATE(nv);
++if ((nv_get_numa_status(nvl) == NV_NUMA_STATUS_ONLINE) &&
++!IS_REG_OFFSET(nv, access_start, access_len))
+ {
+ ret = nvidia_mmap_numa(vma, mmap_context);
+ if (ret)
+-- 
+2.20.1
+
diff --git 
a/debian/module/debian/patches/0044-use-pfn_valid-variant-with-rcu_read_-un-lock_sched.patch
 
b/debian/module/debian/patches/0044-use-pfn_valid-variant-with-rcu_read_-un-lock_sched.patch
new file mode 100644
index 0..e80d0ade7
--- /dev/null
+++ 
b/debian/module/debian/patches/0044-use-pfn_valid-variant-with-rcu_read_-un-lock_sched.patch
@@ -0,0 +1,80 @@
+From 2d0d2cad42331b75fcff6f0492d69cbc3a1d47ab Mon Sep 17 00:00:00 2001
+From: Andreas Beckmann 
+Date: Mon, 24 Jun 2024 02:31:03 +0200
+Subject: [PATCH] use pfn_valid() variant with rcu_read_{,un}lock_sched()
+
+---
+ common/inc/nv-linux.h | 45 +

Bug#1078115: azure-cli - fails to get access token: User 'X' does not exist in MSAL token cache

[Bastian Blank]

Control: severity -1 serious

On Wed, Aug 07, 2024 at 09:59:06AM +0200, Bastian Blank wrote:
> With a brand new config and after using "az login" to login with exactly
> the mentioned user, this now fails with:
> | % az account get-access-token
> | User 'wa...@spi-inc.org' does not exist in MSAL token cache. Run `az login`.
> | % grep waldi@spi ~/.azure/msal_token_cache.json 
> |"username": "wa...@spi-inc.org",

Okay, this problem is fixed in
https://github.com/AzureAD/microsoft-authentication-extensions-for-python/commit/6fd4920f20ab36263a55ad228c432265f8d2f2eb
and released with python-msal-extensions 1.2.0.  What a shitshow.

In a nut shell: the token cache changed function namens from find to
search.  msal_extensions 1.1.0 wraps "find" to actually read the token
cache, but azure-cli uses "search".

Bastian

-- 
... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, "The Omega Glory", stardate unknown

Bug#1049854: colorhug-client: Fails to build binary packages again after successful build

[Petter Reinholdtsen]

Control: tags -1 + patch

I suspect the following patch solve the issue:

diff --git a/Makefile.am b/Makefile.am
index 5ec4213..bd106ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -51,7 +51,6 @@ setup-win32:
 distclean-local:
if test $(srdcir) = .; then :; else \
rm -f ChangeLog; \
-   rm -f NEWS; \
fi
 
 ChangeLog:
@@ -69,6 +68,7 @@ ChangeLog:
fi
 
 NEWS: data/appdata/*.appdata.xml
+   rm -f NEWS; \
$(AM_V_GEN) \
if test -e $(APPSTREAM_UTIL); then \
$(APPSTREAM_UTIL) appdata-to-news $^ > $@; \

The issue is that NEWS is generated and removed in 'make distclean', but also
need to exist on the second invocation.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1074431: arm-trusted-firmware: CVE-2024-6287 CVE-2024-6285

[Moritz Mühlenhoff]

Am Mon, Jul 08, 2024 at 07:16:54PM -0700 schrieb Vagrant Cascadian:
> Control: notfound 1074431 2.4+dfsg-2
> Control: notfound 1074431 2.8.0+dfsg-1
> Control: found 1074431 2.9.0+dfsg-1
> 
> On 2024-06-28, Moritz Mühlenhoff wrote:
> > The following vulnerabilities were published for arm-trusted-firmware.
> >
> > CVE-2024-6287[0]:
> > | Incorrect Calculation vulnerability in Renesas arm-trusted-firmware
> > | allows Local Execution of Code.   When checking whether a new image
> ...
> > CVE-2024-6285[1]:
> > | Integer Underflow (Wrap or Wraparound) vulnerability in Renesas arm-
> > | trusted-firmware. An integer underflow in image range check
> 
> As packaged in Debian bookworm and bullseye, none of the affected
> targets are actually built, although the source code contains the issue.
> 
> The targets are built in later versions, starting with 2.9.0+dfsg-1 and
> 2.10.0+dfsg-1+b1 currently in trixie and sid.

Thanks, I've updated the Debian Security Tracker accordingly.

Cheers,
Moritz

Bug#1078121: colorhug-client: Obsolete appdata should be renamed to metainfo

[Petter Reinholdtsen]

Package: colorhug-client
Version: 0.2.8-3
User: p...@hungry.com
Usertags: appstream-modalias

The XML data in /usr/share/appdata/ should be moved to
/usr/share/appdata/ to be picked up by the Appstream parser.  The
appdata/ path is obsolete.  The XML files might need an update too.
This can be used to check the XML content:

  appstreamcli validate-tree  --no-net --explain debian/colorhug-client

I tried to create a patch for this, but could not get it to build,
thanks to cross references between the toplevel Makefile.am, the
obsolete path data/appdata/ and the content in po/POTFILES*.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1078122: login: sg does not work (does nothing)

[Vincas Dargis]

Package: login
Version: 1:4.16.0-2+really2.40.2-5
Severity: normal

Dear Maintainer,

I was using sg like this:

```
sg fw-torrent transmission-qt
sg fw-skype skypeforlinux
```
To launch specific gui applications with changed group, and later I can
handle IP traffic of these specific applications via firewall rules.

But now it does nothing.

`sg fw-torrent date` does not print anything, exit code is 0.

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

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

Versions of packages login depends on:
ii  libaudit1   1:3.1.2-4+b1
ii  libc6   2.39-6
ii  libcrypt1   1:4.4.36-4
ii  libpam-modules  1.5.3-7
ii  libpam-runtime  1.5.3-7
ii  libpam0g1.5.3-7
ii  login.defs  1:4.16.0-4

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1078123: scikit-learn: test_svm fails on i386 with scipy 1.13

[Drew Parsons]

Source: scikit-learn
Version: 1.4.2+dfsg-5
Severity: normal
Control: forwarded -1 https://github.com/scikit-learn/scikit-learn/issues/29633

scipy 1.13 is triggering test failure in
test_svc_ovr_tie_breaking[NuSVC] on i386 architecture.

The error can be seeing in debian CI tests, 
https://ci.debian.net/packages/s/scikit-learn/unstable/i386/
Full test log at 
https://ci.debian.net/packages/s/scikit-learn/unstable/i386/50043538/
or https://ci.debian.net/packages/s/scikit-learn/testing/i386/50043537/


1333s ___ test_svc_ovr_tie_breaking[NuSVC] 
___
1333s 
1333s SVCClass = 
1333s 
1333s @pytest.mark.parametrize("SVCClass", [svm.SVC, svm.NuSVC])
1333s def test_svc_ovr_tie_breaking(SVCClass):
1333s """Test if predict breaks ties in OVR mode.
1333s Related issue: 
https://github.com/scikit-learn/scikit-learn/issues/8277
1333s """
1333s X, y = make_blobs(random_state=0, n_samples=20, n_features=2)
1333s 
1333s xs = np.linspace(X[:, 0].min(), X[:, 0].max(), 100)
1333s ys = np.linspace(X[:, 1].min(), X[:, 1].max(), 100)
1333s xx, yy = np.meshgrid(xs, ys)
1333s 
1333s common_params = dict(
1333s kernel="rbf", gamma=1e6, random_state=42, 
decision_function_shape="ovr"
1333s )
1333s svm = SVCClass(
1333s break_ties=False,
1333s **common_params,
1333s ).fit(X, y)
1333s pred = svm.predict(np.c_[xx.ravel(), yy.ravel()])
1333s dv = svm.decision_function(np.c_[xx.ravel(), yy.ravel()])
1333s >   assert not np.all(pred == np.argmax(dv, axis=1))
1333s E   assert not True
1333s E+  where True = (array([1, 1, 1, 
..., 1, 1, 1]) == array([1, 1, ..., dtype=int32)
1333s E+where  = np.all
1333s E   
1333s E   Full diff:
1333s E   - array([1, 1, 1, ..., 1, 1, 1], dtype=int32)
1333s E   ?  -
1333s E   + array([1, 1, 1, ..., 1, 1, 1]))
1333s 
1333s /usr/lib/python3/dist-packages/sklearn/svm/tests/test_svm.py:1225: 
AssertionError


I'll add a patch to skip it in the meantime while upstream is
reworking the test.

Bug#1078125: nautilus-sendto: Obsolete appdata should be renamed to metainfo

[Petter Reinholdtsen]

Package: nautilus-sendto
Version: 3.8.6-3.1

The XML data in /usr/share/appdata/ should be moved to
/usr/share/appdata/ to be picked up by the Appstream parser.  The
appdata/ path is obsolete.  The XML files might need an update too.
This can be used to check the XML content:

  appstreamcli validate-tree  --no-net --explain debian/nautilus-sendto

-- 
Happy hacking
Petter Reinholdtsen

Bug#1078126: Unable to run «timedatectl» (missing d-bus dependency?)

[Camaleón]

Package: systemd-timesyncd
Version: 252.26-1~deb12u2
Severity: normal

Hello,

After installing «systemd-timesyncd», when I run timedatectl (either as root or 
plain user) I get an error and command is not run: 

root@noc11:~# timedatectl status
Failed to connect to bus: No such file or directory

This is a barebone/headless server (no X, no UI), maybe a missing 
dependency (d-bus?) that is not pulled to be installed but should be.

root@noc11:~# dpkg -l | grep -e dbus -e systemd
ii  libdbus-1-3:amd641.14.10-1~deb12u1   amd64  
  simple interprocess messaging system (library)
ii  libsystemd-shared:amd64  252.26-1~deb12u2amd64  
  systemd shared private library
ii  libsystemd0:amd64252.26-1~deb12u2amd64  
  systemd utility library
ii  systemd  252.26-1~deb12u2amd64  
  system and service manager
ii  systemd-sysv 252.26-1~deb12u2amd64  
  system and service manager - SysV compatibility symlinks
ii  systemd-timesyncd252.26-1~deb12u2amd64  
  minimalistic service to synchronize local time with NTP servers

Greetings,

-- 
Camaleón 

Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Guillem Jover]

Control: reassign -1 apt
Control: retitle -1 apt: daily systemd service handles dpkg frontend locking 
incorrectly?

Hi!

[ Please see the entire bug report for more details, otherwise I'm
  sure Vincent can fill in any missing pieces. ]

On Thu, 2024-07-25 at 11:03:50 +0200, Vincent Lefevre wrote:
> Control: reopen -1
> Control: severity -1 important
> 
> On 2024-07-11 00:49:20 +0200, Guillem Jover wrote:
> > libdpkg: Try to print the executable name of the lock contending process
> > 
> > Just printing the PID is not very useful to try to track down the
> > contending process as its presence might be momentary and might no
> > longer be present when the user tries to look for that specific PID.
> > 
> > Try to get the executable name to give a better hint to what might be
> > going wrong.
> > 
> > Closes: #1070027

I added this mostly as a debugging aid, even though I had already kind
of tracked the surrounding area for this, I guess I was expecting a
clone and reassign or a new bug report filed on apt, but probably I
should have done that myself, or not closed the report for the
improved debugging output (just adding a reference).

> Since the problem occurred again, this time on the dpkg upgrade itself:
> 
> Unpacking dpkg (1.22.9) over (1.22.7) ...
> Setting up dpkg (1.22.9) ...
> dpkg: error: dpkg frontend lock was locked by /usr/bin/apt-get process with 
> pid 326336
> 
> But this is rather useless information. Perhaps it should also
> write the full "ps -ef" output (something like that) to a file,
> though this may be too late.

Printing more stuff could certainly be helpful, but would be annoying.
I'd expect something like this bug not being common, so I'm not sure
(at least right now) it's worth it to implement further output, or
relying on ps or pstree or similar (which would seem rather meh).

> According to the journalctl output:
> 
> Jul 25 10:30:36 qaa systemd[1]: Reload requested from client PID 326242 
> ('systemctl') (unit session-2.scope)...
> Jul 25 10:30:36 qaa systemd[1]: Reloading...
> Jul 25 10:30:37 qaa systemd[1]: Reloading finished in 153 ms.
> Jul 25 10:30:37 qaa systemd[1]: Starting apt-daily.service - Daily apt 
> download activities...
> Jul 25 10:30:37 qaa systemd[1]: apt-daily.service: Deactivated successfully.
> Jul 25 10:30:37 qaa systemd[1]: Finished apt-daily.service - Daily apt 
> download activities.
> 
> but again, I did *not* do a systemctl. So either systemd is completely
> broken, or perhaps the systemctl was done by dpkg itself. Note that in
> this latter case (I would not be surprised, because when this happens,
> this is *always* during an upgrade), even if aptitude had some fix of
> frontend locking, there would still be a conflict between aptitude and
> dpkg, both leading to a request a lock.

A reload is the common operation expected when installing any systemd
service file, so if that would cause a dpkg lock issue, then that
would be a general problem. This is specific to the interaction of the
apt-daily.service and how it ends up locking things.

On Thu, 2024-07-25 at 13:27:52 +0200, Vincent Lefevre wrote:
> On 2024-07-25 11:49:42 +0200, Vincent Lefevre wrote:
> > The reload is triggered with just
> > 
> >   dpkg -i /var/cache/apt/archives/dpkg_1.22.9_amd64.deb
> > 
> > so aptitude and even apt aren't even involved in this bug:
> > 
> > Jul 25 11:47:56 qaa systemd[1]: Reload requested from client PID 333083 
> > ('systemctl') (unit session-2.scope)...
> > Jul 25 11:47:56 qaa systemd[1]: Reloading...
> > Jul 25 11:47:56 qaa systemd[1]: Reloading finished in 139 ms.
> 
> And if the timer time has been reached, the apt-daily service is run.
> 
> To try to reproduce the issue, I've copied
> 
>   /usr/lib/systemd/system/apt-daily.service
>   /usr/lib/systemd/system/apt-daily.timer
> 
> into /etc/systemd/system and edited them.
> 
> For /etc/systemd/system/apt-daily.service, I've changed the ExecStart
> script pathname and edited the copy of the apt.systemd.daily script to
> set VERBOSE=1 and ducplicate the following lines
> 
> # check if we can lock the cache and if the cache is clean
> if command -v apt-get >/dev/null && ! eval apt-get check $XAPTOPT $XSTDERR ; 
> then
> debug_echo "error encountered in cron job with \"apt-get check\"."
> exit 0
> fi
> 
> 6 times (as "apt-get check" attempts to lock the cache, thus
> giving more chance of failure).
> 
> For /etc/systemd/system/apt-daily.timer, I've changed the following
> lines to get
> 
> OnCalendar=*-*-* *:*:00
> RandomizedDelaySec=1m
> 
> thus reaching the timer time more often.
> 
> Now, whether I use
> 
>   aptitude reinstall dpkg dpkg-dev
> or
>   apt install --reinstall dpkg dpkg-dev
> or
>   dpkg -i /var/cache/apt/archives/dpkg_1.22.9_amd64.deb \
>   /var/cache/apt/archives/dpkg-dev_1.22.9_all.deb
> 
> I can get a failure in the apt.systemd.daily script:
> 
> Jul 25 12:59:17 qaa systemd[1]: Starting apt-daily.service - Daily apt 
> download activities...
> Jul 25 12:59:17 qaa apt.system

Bug#1067087: dpkg-buildflags: Enable frame pointers by default

[Guillem Jover]

Control: tags 1058664 moreinfo
Control: forcemerge 1058664 -1

Hi!

[ Merging with the other dupes. :) ]

On Sat, 2024-04-06 at 01:48:04 +0200, Guillem Jover wrote:
> Control: tags -1 moreinfo
> Control: retitle -1 dpkg-buildflags: Enable frame pointers by default
> 
> On Mon, 2024-03-18 at 09:56:38 +0100, Kurt Roeckx wrote:
> > Source: gcc-14
> > Severity: wishlist
> 
> > Please consider enabling frame pointers on 64 bit arches.
> > See: 
> > https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html
> 
> On Sat, 2024-03-30 at 11:59:24 +0100, Matthias Klose wrote:
> > Make sure, that you contact porters on which architectures that should be
> > enabled, and e.g. don't do that on 32bit architectures at all.
> 
> Please see this entry in the dpkg FAQ:
> 
>   
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F
> 
> and if you are interested in pursuing this, then start the process,
> while I don't see any issue with enabling this, I'm not going to drive
> this myself.

Thanks,
Guillem

Bug#1078127: libc6: mcheck(NULL) fails even at the beginning of a program

[Vincent Lefevre]

Package: libc6
Version: 2.39-6
Severity: normal

The following program

#include 
#include 

int main (void)
{
  int r;

  r = mcheck (NULL);
  printf ("%d\n", r);
  return 0;
}

outputs -1, which is incorrect. It should have been 0.

The glibc manual says

  It is too late to begin allocation checking once you have allocated
  anything with ‘malloc’.  So ‘mcheck’ does nothing in that case.
  The function returns ‘-1’ if you call it too late, and ‘0’
  otherwise (when it is successful).

Since there hasn't been any malloc yet, 0 should have been output.

Similarly, the example given in the mcheck(3) man page fails
unexpectedly.

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

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 libc6 depends on:
ii  libgcc-s1  14.2.0-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.7-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.87
ii  glibc-doc  2.39-6
ii  libc-l10n  2.39-6
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.39-6

-- debconf information:
  glibc/restart-failed:
* libraries/restart-without-asking: true
  glibc/disable-screensaver:
  glibc/upgrade: true
  glibc/restart-services:
  glibc/kernel-not-supported:
  glibc/kernel-too-old:

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

Bug#1077045: systemd 252.29-1~deb12u1 flagged for acceptance

[Luca Boccassi]

On Wed, 7 Aug 2024 at 06:24, Adam D Barratt  wrote:
>
> package release.debian.org
> tags 1077045 = bookworm pending
> thanks
>
> Hi,
>
> The upload referenced by this bug report has been flagged for acceptance into 
> the proposed-updates queue for Debian bookworm.
>
> Thanks for your contribution!
>
> Upload details
> ==
>
> Package: systemd
> Version: 252.29-1~deb12u1
>
> Explanation:

Thanks for processing these - for future cases, do you prefer a single
bug that gets renamed as a new version is uploaded, or the same with
one separate bug for each separate upload to p-u?

Bug#1078128: libc6: mtrace() + malloc() do not generate data

[Vincent Lefevre]

Package: libc6
Version: 2.39-6
Severity: normal

When testing the example given in the mtrace(3) man page,
no data are generated:

$ cat t_mtrace.c
#include 
#include 
#include 

int
main(void)
{
  mtrace();

  for (unsigned int j = 0; j < 2; j++)
malloc(100);/* Never freed--a memory leak */

  calloc(16, 16); /* Never freed--a memory leak */
  exit(EXIT_SUCCESS);
}

$ cc -g t_mtrace.c -o t_mtrace
t_mtrace.c: In function ‘main’:
t_mtrace.c:11:5: warning: ignoring return value of ‘malloc’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
   11 | malloc(100);/* Never freed--a memory leak */
  | ^~~
t_mtrace.c:13:3: warning: ignoring return value of ‘calloc’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
   13 |   calloc(16, 16); /* Never freed--a memory leak */
  |   ^~
$ export MALLOC_TRACE=/tmp/t
$ ./t_mtrace
$ mtrace ./t_mtrace $MALLOC_TRACE
Cannot open mtrace data file at /bin/mtrace line 152,  line 4.
$ ls $MALLOC_TRACE
ls: cannot access '/tmp/t': No such file or directory

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

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 libc6 depends on:
ii  libgcc-s1  14.2.0-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.7-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.87
ii  glibc-doc  2.39-6
ii  libc-l10n  2.39-6
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.39-6

-- debconf information:
  glibc/disable-screensaver:
  glibc/kernel-not-supported:
  glibc/restart-services:
  glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/restart-failed:
* libraries/restart-without-asking: true

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

Bug#1068901: re-open

[Konstantinos Poulios]

This is actually still present on a fully updated debian trixie/sid.

I can also confirm that applying
https://github.com/jupyter/notebook/pull/7051/files
fixes the issue

Maybe one should consider adding this commit as a debian patch until the
new upstream version has arrived.

Konstantinos

Bug#1076968: halide: FTBFS: 31 - mullapudi2016_reorder (Failed)

[Santiago Vila]

close 1076968 18.0.0-5
thanks

El 7/8/24 a las 1:06, Roman Lebedev escribió:

Yes. Could you please check if 18.0.0-5 (which was just uploaded to unstable)
makes that rebuild pass? If not, some more timings will need to be ignored...


The current version seems to fix the bug I reported, yes.
I'm therefore closing the bug using such version.

Thanks.

Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Vincent Lefevre]

On 2024-08-07 11:04:15 +0200, Guillem Jover wrote:
> On Thu, 2024-07-25 at 11:03:50 +0200, Vincent Lefevre wrote:
[...]
> > With VERBOSE=2, I could get more details about this failure:
> > 
> > Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily apt 
> > download activities...
> > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock 
> > /var/lib/dpkg/lock-frontend. It is held by process 378454 (apt)
> > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire the 
> > dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using 
> > it?
> > Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in cron 
> > job with "apt-get check".
> > Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated successfully.
> > Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily apt 
> > download activities.
> > 
> > Here, the failure occurs in the apt.systemd.daily, because the
> > process used for the upgrade got the lock first. But it could
> > be the other way round, as this could be seen with aptitude.
> 
> So, as mentioned above, and as we saw earlier in the bug report, it looks
> like the lock handling in the apt-daily.service is not working, and is
> interfering with the current run. This needs to be fixed there
> somehow. Reassigning.

OK. So, in short, apt keeps the lock for too long. The lock should
be released by apt for triggers since a lock may be needed by some
process run by a trigger.

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

Bug#1066835: universal-ctags: please add support for loong64

[wuruilong]

Source: universal-ctags
Version: 5.9.20210829.0-1
Followup-For: Bug #1066835
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Upstream has been merged into PR, please upgrade the software version or
merge the attached patch.

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

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

Bug#1070037: xwallpaper: please add support for loong64

[wuruilong]

Source: xwallpaper
Version: 0.7.3-1
Followup-For: Bug #1070037
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Can anyone merge the attached patches please?

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

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

Bug#1078129: git: permission denied on NFS filesystem while cloning repository

[Roberto Lumbreras]

Package: git
Version: 1:2.39.2-1.1
Severity: normal

Over NFS, git clone fails:

$ git clone URL directory
Cloning into 'directory'...
fatal: Unable to create temporary file
'.../.git/objects/pack/tmp_pack_XX': Permission denied
fatal: fetch-pack: invalid index-pack output

325727  0.30 openat(AT_FDCWD,
"/home/rover/intranet-src/.git/objects/pack/tmp_pack_jIbpEU",
O_RDWR|O_CREAT|O_EXC
L, 0444) = -1 EACCES (Permission denied)

The problem seems to be the O_RDWR + 0444, that fails on NFS, but not on
ext4 or tmpfs.

Confirmed with this code, it returns same error:

openat(AT_FDCWD, "testfile", O_RDWR|O_CREAT|O_EXCL, 0444) = -1 EACCES
(Permission denied)

#include 
#include 
#include 
#include 

int
main() {
int fd=open("testfile", O_RDWR|O_CREAT|O_EXCL, 0444);
printf("errno=%d\n", errno);
unlink("testfile");
close(fd);
}

-- 
Regards,
Roberto Lumbreras
Debian developer

Bug#1074312: yorick-ynfft: please add support for loong64

[wuruilong]

Source: yorick-ynfft
Version: 1.0.3-1
Followup-For: Bug #1074312
X-Debbugs-Cc: wuruil...@loongson.cn

Dear Maintainer,

Can anyone merge the attached patches please?

wuruilong

-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

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

Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Julian Andres Klode]

Control: reassign -1 aptitude
Control: retitle -1 aptitude: frontend lock support

On Wed, Aug 07, 2024 at 11:38:35AM GMT, Vincent Lefevre wrote:
> On 2024-08-07 11:04:15 +0200, Guillem Jover wrote:
> > On Thu, 2024-07-25 at 11:03:50 +0200, Vincent Lefevre wrote:
> [...]
> > > With VERBOSE=2, I could get more details about this failure:
> > > 
> > > Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily apt 
> > > download activities...
> > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock 
> > > /var/lib/dpkg/lock-frontend. It is held by process 378454 (apt)
> > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire the 
> > > dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process 
> > > using it?
> > > Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in cron 
> > > job with "apt-get check".
> > > Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated 
> > > successfully.
> > > Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily apt 
> > > download activities.
> > > 
> > > Here, the failure occurs in the apt.systemd.daily, because the
> > > process used for the upgrade got the lock first. But it could
> > > be the other way round, as this could be seen with aptitude.
> > 
> > So, as mentioned above, and as we saw earlier in the bug report, it looks
> > like the lock handling in the apt-daily.service is not working, and is
> > interfering with the current run. This needs to be fixed there
> > somehow. Reassigning.
> 
> OK. So, in short, apt keeps the lock for too long. The lock should
> be released by apt for triggers since a lock may be needed by some
> process run by a trigger.

No that's nonsense. The frontend lock is exactly supposed to be held
while running dpkg (which runs the lock). This is working as designed.

Now the original bug report is quite clearly about aptitude not
implementing frontend lock support, as in it still uses the old API
to release all locks to run dpkg and hence the service will steal
the frontend lock from it. That's expected and working as designed;
a frontend that does not implement frontend locking is vulnerable to
the same race as before.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1078130: dash: refuse upgrade if /bin/sh is ineffectively diverted (DEP17)

[Helmut Grohne]

Package: dash
Version: 0.5.12-9
Severity: serious
Justification: all dep17 bugs are have become rc since 2024-08-06
User: helm...@debian.org
Usertags: dep17p3
X-Debbugs-Cc: Thorsten Glaser 

Hi Andrew and Thorsten,

in my conversion of dash I slightly neglected the fact that /bin/sh is a
relatively common thing to divert. It was and still is planned to add a
note to the release-notes asking administrators to review their local
diversions before proceeding the upgrade, but diversions of /bin/sh are
quite delicate, so it is better to be safe here.

The upgrade of dash may render a diversion of /bin/sh by an
administrator ineffective and thus revert from a prior choice of e.g.
lksh from the mksh package back to dash. This is not resolvable on the
dash side, but dash may support here by aborting the upgrade and giving
the administrator guidance on how to resolve the situation.

I am attaching a patch that adds a dash.preinst checking for affected
upgrade scenarios and aborting those that require manual changes. I also
attach a script for testing various upgrade scenarios and ran it locally
to verify the correctness of the proposed change.

Note that the rc-severity merely indicates that this needs to be fixed
for trixie but does not otherwise imply urgency.

Helmut
diff --minimal -Nru dash-0.5.12/debian/changelog dash-0.5.12/debian/changelog
--- dash-0.5.12/debian/changelog2024-06-05 10:08:31.0 +0200
+++ dash-0.5.12/debian/changelog2024-08-07 11:13:50.0 +0200
@@ -1,3 +1,10 @@
+dash (0.5.12-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Notify users about ineffective diversions of /bin/sh (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 07 Aug 2024 11:13:50 +0200
+
 dash (0.5.12-9) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff --minimal -Nru dash-0.5.12/debian/dash.preinst 
dash-0.5.12/debian/dash.preinst
--- dash-0.5.12/debian/dash.preinst 1970-01-01 01:00:00.0 +0100
+++ dash-0.5.12/debian/dash.preinst 2024-08-07 11:13:50.0 +0200
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" = upgrade ] && dpkg --compare-versions "$2" lt 0.5.12-9~; then
+   # Upgrading from pre-/usr-move DEP17
+   truename=$(dpkg-divert --truename /bin/sh)
+   if [ "$truename" != /bin/sh ] &&
+   [ "$(dpkg-divert --listpackage /bin/sh)_$truename" != 
"dash_/bin/sh.distrib" ] &&
+   [ "$(dpkg-divert --truename /usr/bin/sh)" = "/usr/bin/sh" ]; 
then
+   # There is a diversion of /bin/sh and it is not our own
+   # diversion to /bin/sh.distrib that will be removed in
+   # postinst and there is no matching diversion of /usr/bin/sh.
+   cat <

test.sh
Description: Bourne shell script

Bug#1076849: No config found for iwlwifi

[Harald Dunkel]

Recently we have seen the "no config found" error for backports kernel
6.9.7 as well, ie the problem is not solved for newer kernels, either.

[Wed Aug  7 09:43:34 2024] Linux version 6.9.7+bpo-amd64 
(debian-ker...@lists.debian.org) (x86_64-linux-gnu-gcc-12 (Debian 12.2.0-14) 
12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 
6.9.7-1~bpo12+1 (2024-07-03)
:
:
[Wed Aug  7 09:45:01 2024] Intel(R) Wireless WiFi driver for Linux
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: enabling device ( -> 0002)
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: Detected crf-id 0x1300504, 
cnv-id 0x80400 wfpm id 0x30
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: Adding cdb to rf id
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: Adding jacket to rf id
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: Detected rf-type 0x504 step-id 
0x1 slave-id 0x0 from crf id 0x3010a100
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: Detected cdb-id 0x1 jacket-id 
0x1 from wfpm id 0x30
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: Detected jacket-id 0x1 from 
cnvi id 0x80400
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: PCI dev 51f1/, rev=0x370, 
rfid=0x3010a100
[Wed Aug  7 09:45:01 2024] iwlwifi: No config found for PCI dev 51f1/, 
rev=0x370, rfid=0x3010a100
[Wed Aug  7 09:45:01 2024] iwlwifi :00:14.3: probe with driver iwlwifi 
failed with error -22

When there is no problem, the vendor/device ID is "51f1/0074":

2024-08-05T10:39:04.760384+02:00 ppcl017 kernel: [  104.016404] iwlwifi 
:00:14.3: enabling device ( -> 0002)
2024-08-05T10:39:04.760385+02:00 ppcl017 kernel: [  104.023119] iwlwifi 
:00:14.3: Detected crf-id 0x1300504, cnv-id 0x80400 wfpm id 0x8030
2024-08-05T10:39:04.760385+02:00 ppcl017 kernel: [  104.023173] iwlwifi 
:00:14.3: PCI dev 51f1/0074, rev=0x370, rfid=0x10a100
2024-08-05T10:39:04.760389+02:00 ppcl017 kernel: [  104.031358] iwlwifi 
:00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.42
2024-08-05T10:39:04.760390+02:00 ppcl017 kernel: [  104.031780] iwlwifi 
:00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2)
2024-08-05T10:39:04.760390+02:00 ppcl017 kernel: [  104.031795] iwlwifi 
:00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2)
2024-08-05T10:39:04.760391+02:00 ppcl017 kernel: [  104.031797] iwlwifi 
:00:14.3: loaded firmware version 89.202a2f7b.0 so-a0-hr-b0-89.ucode 
op_mode iwlmvm
2024-08-05T10:39:05.011616+02:00 ppcl017 kernel: [  104.512731] iwlwifi 
:00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x370


Regards
Harri

Bug#1078124: linux-image-6.10.3-amd64: `apt upgrade` fails to build modules (nvidia)

[Julian Andres Klode]

Control: reassign -1 nvidia-kernel-dkms 

On Wed, Aug 07, 2024 at 10:42:01AM GMT, Moritz von der Heiden wrote:
> Package: apt
> Version: 2.9.7
> Severity: normal
> X-Debbugs-Cc: moritz.vonderhei...@visensys.de
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>   * running `apt update` followed by `apt upgrade`
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>   * Nothing in particular, except for trying to update my Debian Sid
>* What was the outcome of this action?
>   * apt failed to install linux-image-6.10.3-amd64 (see output below)
>* What outcome did you expect instead?
>   * apt installs linux-image-6.10.3-amd64 successfully
> 

Please don't blame APT for packages failing to install. And following
that, please don't blame the kernel package for dkms modules failing to
compile, that's nonsense.

> -- apt output (tried to update before, this is the second attempt):
> 
> $ sudo apt upgrade 
> The following packages were automatically installed and are no longer 
> required:
>   cpp-13-arm-linux-gnueabigcc-13-arm-linux-gnueabi libavdevice60  
> libksysguardformatter1linux-headers-6.9.8-amd64   
> linux-kbuild-6.9.8
>   cpp-13-arm-linux-gnueabihf  gcc-13-arm-linux-gnueabi-baselibavfilter9   
> libplacebo338 linux-headers-6.9.8-common  
> linux-kbuild-6.9.9
>   g++-13  gcc-13-arm-linux-gnueabihf   
> libdisplay-info1   libprocesscore9   
> linux-headers-6.9.9-amd64   ruby-ruby2-keywords
>   g++-13-arm-linux-gnueabigcc-13-arm-linux-gnueabihf-base  
> libgcc-13-dev-armel-cross  libprocessui9 
> linux-headers-6.9.9-common
>   g++-13-arm-linux-gnueabihf  gcc-13-cross-base
> libgcc-13-dev-armhf-cross  libstdc++-13-dev-armel-cross  
> linux-image-6.9.8-amd64
>   g++-13-x86-64-linux-gnu gcc-13-cross-base-ports  
> libkf5sysguard-datalibstdc++-13-dev-armhf-cross  
> linux-image-6.9.9-amd64
> Use 'sudo apt autoremove' to remove them.
> 
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
>   4 not fully installed or removed.
>   Space needed: 0 B / 1.305 GB available
> 
> Continue? [Y/n] 
> Setting up linux-image-6.10.3-amd64 (6.10.3-1) ...
> /etc/kernel/postinst.d/dkms:
> dkms: running auto installation service for kernel 6.10.3-amd64.
> Sign command: /lib/modules/6.10.3-amd64/build/scripts/sign-file
> Signing key: /var/lib/dkms/mok.key
> Public certificate (MOK): /var/lib/dkms/mok.pub
> 
> Building module:
> Cleaning build area...
> Building module(s).(bad exit status: 2)
> Failed command:
> env NV_VERBOSE=1 make -j16 modules KERNEL_UNAME=6.10.3-amd64
> Error! Bad return status for module build on kernel: 6.10.3-amd64 (x86_64)
> Consult /var/lib/dkms/nvidia-current/535.183.01/build/make.log for more 
> information.
> dkms autoinstall on 6.10.3-amd64/x86_64 failed for nvidia-current(10)
> Error! One or more modules failed to install during autoinstall.
> Refer to previous errors for more information.
> dkms: autoinstall for kernel: 6.10.3-amd64 failed!
> run-parts: /etc/kernel/postinst.d/dkms exited with return code 11


I am reassigning this to nvidia-kernel-dkms. I am not quite sure if you
are _actually_ using nvidia-kernel-dkms or made up your own mess, but
the nvidia driver maintainers should be able to figure that out and it
beats just closing it.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1078131: ripe-atlas-tools: ripe-atlas crash due to missing argument on yaml.load

[Sebastien Badia]

Package: ripe-atlas-tools
Version: 2.3.0-3
Severity: important
Tags: patch newcomer

Hello !

ripe-atlas fail with any commands due to a change in python yaml loader (patch
inclued).
we can maybe also update the Debian version to the latest ripe-atlas-tools
version (3.1.0), I can take care of it if needed.
let me know.

Thanks in advance !

Sebastien

% ripe-atlas --help
Traceback (most recent call last):
  File "/bin/ripe-atlas", line 8, in 
from ripe.atlas.tools.commands.measure import Factory as BaseFactory
  File "/usr/lib/python3/dist-
packages/ripe/atlas/tools/commands/measure/__init__.py", line 20, in 
from .ping import PingMeasureCommand
  File "/usr/lib/python3/dist-
packages/ripe/atlas/tools/commands/measure/ping.py", line 18, in 
from ...helpers.validators import ArgumentType
  File "/usr/lib/python3/dist-packages/ripe/atlas/tools/helpers/validators.py",
line 25, in 
from ..settings import aliases
  File "/usr/lib/python3/dist-packages/ripe/atlas/tools/settings/__init__.py",
line 287, in 
conf = Configuration().get()
   ^
  File "/usr/lib/python3/dist-packages/ripe/atlas/tools/settings/__init__.py",
line 34, in get
custom = yaml.load(y)
 
TypeError: load() missing 1 required positional argument: 'Loader'


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

Kernel: Linux 6.9.10-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 ripe-atlas-tools depends on:
ii  python3  3.12.4-1
ii  python3-dateutil 2.9.0-2
ii  python3-ipy  1:1.01-2
ii  python3-openssl  24.1.0-1
ii  python3-pkg-resources70.3.0-2
ii  python3-requests 2.31.0+dfsg-2
ii  python3-ripe-atlas-cousteau  2.0.0-1
ii  python3-ripe-atlas-sagan 1.3.1-1
ii  python3-tzlocal  5.2-1.1
ii  python3-yaml 6.0.1-2+b1

Versions of packages ripe-atlas-tools recommends:
ii  python3-ujson  5.10.0-1+b1

ripe-atlas-tools suggests no packages.

-- no debconf information

*** /home/sbadia/patch_ripe-atlas.patch
--- __init__.py 2024-08-07 11:53:46.629760865 +0200
+++ __init__.py 2024-08-07 11:57:48.887159939 +0200
@@ -13,7 +13,7 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .

-import collections
+from collections.abc import Mapping
 import copy
 import os
 import re
@@ -31,7 +31,7 @@
 r = copy.deepcopy(self.DEFAULT)
 if os.path.exists(self.USER_RC):
 with open(self.USER_RC) as y:
-custom = yaml.load(y)
+custom = yaml.load(y, Loader=yaml.FullLoader)
 if custom:
 r = self.deep_update(r, custom)
 return r
@@ -43,7 +43,7 @@
 Stolen from http://stackoverflow.com/questions/3232943/
 """
 for k, v in u.items():
-if isinstance(v, collections.Mapping):
+if isinstance(v, Mapping):
 r = cls.deep_update(d.get(k, {}), v)
 d[k] = r
 else:

Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Vincent Lefevre]

On 2024-08-07 11:56:56 +0200, Julian Andres Klode wrote:
> Control: reassign -1 aptitude
> Control: retitle -1 aptitude: frontend lock support
> 
> On Wed, Aug 07, 2024 at 11:38:35AM GMT, Vincent Lefevre wrote:
> > On 2024-08-07 11:04:15 +0200, Guillem Jover wrote:
> > > On Thu, 2024-07-25 at 11:03:50 +0200, Vincent Lefevre wrote:
> > [...]
> > > > With VERBOSE=2, I could get more details about this failure:
> > > > 
> > > > Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily apt 
> > > > download activities...
> > > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock 
> > > > /var/lib/dpkg/lock-frontend. It is held by process 378454 (apt)
> > > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire the 
> > > > dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process 
> > > > using it?
> > > > Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in 
> > > > cron job with "apt-get check".
> > > > Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated 
> > > > successfully.
> > > > Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily apt 
> > > > download activities.
> > > > 
> > > > Here, the failure occurs in the apt.systemd.daily, because the
> > > > process used for the upgrade got the lock first. But it could
> > > > be the other way round, as this could be seen with aptitude.
> > > 
> > > So, as mentioned above, and as we saw earlier in the bug report, it looks
> > > like the lock handling in the apt-daily.service is not working, and is
> > > interfering with the current run. This needs to be fixed there
> > > somehow. Reassigning.
> > 
> > OK. So, in short, apt keeps the lock for too long. The lock should
> > be released by apt for triggers since a lock may be needed by some
> > process run by a trigger.
> 
> No that's nonsense. The frontend lock is exactly supposed to be held
> while running dpkg (which runs the lock). This is working as designed.

WRONG! You can see above an error *without* using aptitude.
Even though there may be a bug in aptitude, there is also
a bug related to apt.

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

Bug#1071970: pcre3 should not be part of trixie

[Cyril Brulebois]

Matthew Vernon  (2024-08-07):
> On 07/08/2024 06:18, Paul Gevers wrote:
> > Please don't do that until you have approval from d-i. I included
> > them in the mail chain. If the udeb is used by d-i, that needs to be
> > resolved first.
> 
> Noted, although I'm pretty sure d-i moved to pcre2 a while back now.

I'm not seeing any reverse dependencies for the libpcre3-udeb package,
so we should be good.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1076022: Backport some security settings from upstream 3.2.5 release to mitigate BlastRADIUS

[Santiago Ruano Rincón]

Hi Bernhard,

El 14/07/24 a las 16:15, Salvatore Bonaccorso escribió:
> Hi Bernhard,
> 
> [
> On Sat, Jul 13, 2024 at 12:28:34AM +0200, Bernhard Schmidt wrote:
> > Am 12.07.24 um 13:34 schrieb Herwin Weststrate:
> > 
> > Dear Herwin,
> > 
> > > > > FreeRADIUS 3.2.5 has just been released, which includes some security
> > > > > fixes for BlastRADIUS: a vulnerability with a name and a website[0] 
> > > > > and
> > > > > a logo (hadn't seen one of those in a while).
> > 
> > [...]
> > 
> > > > 
> > > > Given that the freeradius codebase is really complicated I'm not 
> > > > entirely
> > > > sure whether we can do this (_I_ can't), or ask the security team for a
> > > > newer upstream version in stable.
> > > 
> > > I looked a bit deeper into it: there was a lot more needed than just
> > > these two commits. Pretty much every commit of July 8 was relevant.
> > 
> > Thanks a lot for checking this out.
> > 
> > > I have not yet tested the proxy settings, it takes a while to set that
> > > up and I would first like to know if there is a chance that this patch
> > > set will be accepted, if it gets rejected right away for whatever reason
> > > I'd rather save myself the trouble.
> > 
> > > All the commits have been cherry-picked in order from the upstream
> > > changes, so a code review can compare these commits side by side.
> > 
> > I'm open to it, but ultimatively it's up to the security team to decide. We
> > can either go for this 100k patch cherry-picked from upstream, or ask for
> > 3.2.5 in stable. Or ignore it, which is in my opinion still on the table (I
> > don't consider BlastRADIUS that bad, but it has a website and a logo so ...)
> > 
> > @Security Team: What do you think? Herwin did a spectacular job here already
> > and I can also offer to get it some life testing in a production
> > environment, but in the end we would have to jump into very cold waters.
> 
> I do not think this warrants a DSA, but I see one option, OTOH. How
> about trying to rebase freeradius to 3.2.5 in the next bookworm point
> release in august? Then while the issue will not warrant a DSA, we
> still get the implemented mitigations in a future point release of
> bookworm.
> 
> The same obviously could be done as well via a security update, I
> agree with you assessment that it's not that urgent and so such an
> update can be batched n the point release and additionally be exposed
> to the public via the proposed-upates queues.
> 
> Another story is bullseye, that one is affected as well but a backport
> there is even harder. For now I have marked it as well no-dsa in the
> security-tracker, but maybe it should be  with mentioning
> that backporting patches is too intrusive?

Regarding the version in bullseye: upstream has kindly shared with me a
set of patches. I've pushed them to:
https://salsa.debian.org/debian/freeradius/-/tree/wip/debian/blastradius/bullseye.

While they build, I haven't been able to test them (yet). The
autopkgtest job fails, but that is related to a bug in Salsa CI and
systemd when tmp.mount is masked.

Bernhard, are you able to test them? I do not have any experience with
FreeRADIUS, so I could test them, but I would take me some time. Just
let me know if help is needed here.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

[Thorsten Glaser]

Helmut Grohne dixit:

>that the way people tend to use mksh is by adding a local diversion for

Unfortunately not.

The way we have to do it since squeeze, when dash unilaterally broke
cross-package coordination, is:

dpkg-reconfigure dash ⇒ remove its owning of /bin/sh
 (so it reverts to bash)
ln -sf lksh /bin/sh

This cleanly persists across upgrades, bash was never problematic
wrt this.

>I don't think the CTTE has actually issued a ruling on DEP17 or
>/usr-move short of repealing the moratorium in order to enable moving
>forward.

That, and that UsrMove via symlinks /bin etc. is to be instated.

There is absolutely no reason to force files to move, given they
are now aliased already *anyway*.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

[Thorsten Glaser]

(Another data point is that there’s versions of mksh with
version numbers larger than what’s in sid around in my own
repo, for those wanting to follow CVS snapshots more closely,
backported to all versions up to sarge, so bookworm users
can very well have mksh packages with a version number that
is greater than what will be in trixie so anything that relies
on version numbers for transitioning will also not work.)

Bug#1078132: RFP: dotnet8 -- .NET 8.0 Runtime and Software Development Kit (SDK)

[Aptivi]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: c...@aptivi.anonaddy.com

* Package name: dotnet8
  Version : 8.0.107-8.0.7
  Upstream Contact: Ubuntu Developers 
* URL : https://dot.net/
* License : MIT
  Programming Lang: C, C++, C#
  Description : .NET 8.0 Runtime and Software Development Kit (SDK)

This package contains the full software development kit for .NET 8.0
applications. .NET is a fast, lightweight and modular platform for
creating cross platform applications that work on GNU/Linux, macOS and Windows.

It particularly focuses on creating console applications, web applications, and
micro-services.

.NET contains a runtime conforming to .NET Standards, a set of framework
libraries, an SDK containing compilers, and a 'dotnet' CLI application to drive
everything.

---

This package is useful because there are increasing numbers of
applications that use .NET 8.0 and manual installation of the .NET SDK
may not be as easy as it sounds. It's a dependency for future packages
that require .NET 8.0 to work, for example, I use .NET to make several
useful applications and libraries. There is Mono that is a runtime for
.NET Framework applications, but Mono can't build and/or run .NET 8.0
applications; only .NET Framework ones. Furthermore, Ubuntu has it
already packaged starting from Jammy Jellyfish with .NET 6.0 and uodated
it to .NET 8.0 on Noble Numbat.

I would love to maintain it, but can't due to lack of time and resources
to do it as I am having problems with electricity rolling blackouts and
internet speeds slowing down in the afternoon until the dawn, as well as
me being busy with important things and software development.

Bug#1077776: gcc-14 ftbfs on loong64 (illegal instruction)

[zhangdandan]

Hi doko,

On Fri, 2 Aug 2024 02:35:23 +0200 Matthias Klose wrote:

> Package: src:gcc-14
> Version: 14.2.0-1
> Severity: important
> Tags: sid trixie
> X-Debbugs-CC: debian-loonga...@lists.debian.org
>
> [...]
> checking for libphobos support... yes
> checking for loongarch64-linux-gnu-gcc... loongarch64-linux-gnu-gcc-14
> checking whether the C compiler works... no
> configure: error: in `/<>/build':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
>
> configure:4513: checking whether the C compiler works
> configure:4535: loongarch64-linux-gnu-gcc-14 conftest.c >&5
> ../src/configure: line 4537: 3830466 Illegal instruction $CC $CFLAGS
> $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS 1>&5
> configure:4539: $? = 132
> configure:4577: result: no
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | /* end confdefs.h. */
> |
> | int
> | main ()
> | {
> |
> | ;
> | return 0;
> | }
> configure:4582: error: in `/<>/build':
> configure:4584: error: C compiler cannot create executables
>
>
Thanks for your feedback.
This issue was related to the buildds and has been resolved.
The lastest build log (2024-08-07 09:28:19) can be found at 
https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=loong64&ver=14.2.0-1&stamp=1723022899&raw=0. 


The error log is as follows,
```
mkdir -p ada/gen_il
cd ada/gen_il; gnatmake -v -g -gnata -gnat2012 -gnatw.g -gnatyg -gnatU 
-I/<>/src/gcc/ada gen_il-main

mkdir -p ada/bldtools/snamest
touch ada/GNAT_DATE
cp -p -f ../../src/gcc/ada/libgnat/gnat.ads ada/gnat.ads
/bin/bash: line 1: gnatmake: command not found
make[5]: *** [../../src/gcc/ada/Make-generated.in:21: ada/stamp-gen_il] 
Error 127

make[5]: *** Waiting for unfinished jobs
rm -f ada/bldtools/snamest/snames.ads-tmpl 
ada/bldtools/snamest/snames.adb-tmpl ada/bldtools/snamest/snames.h-tmpl 
ada/bldtools/snamest/xsnamest.adb ada/bldtools/snamest/xutil.ads 
ada/bldtools/snamest/xutil.adb
cp -p ../../src/gcc/ada/snames.ads-tmpl 
../../src/gcc/ada/snames.adb-tmpl ../../src/gcc/ada/snames.h-tmpl 
../../src/gcc/ada/xsnamest.adb ../../src/gcc/ada/xutil.ads 
../../src/gcc/ada/xutil.adb ada/bldtools/snamest

cd ada/bldtools/snamest && gnatmake -v xsnamest && ./xsnamest
/bin/bash: line 1: gnatmake: command not found
make[5]: *** [../../src/gcc/ada/Make-generated.in:49: ada/stamp-snames] 
Error 127

make[5]: Leaving directory '/<>/build/gcc'
```

gcc-14 provides gnatmake-14, without gnatmake.
The command gnatmake is used in gcc-14 (14.2.0-1) 
src/gcc/ada/Make-generated.in.


Thanks,
Dandan Zhang

Bug#1078133: libyang3: missing Breaks+Replaces: libyang2 (<< 3), libyang2t64 (<< 3)

[Andreas Beckmann]

Package: libyang3
Version: 3.1.0+dfsg-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'bookworm'.
It installed fine in 'bookworm', then the upgrade to 'trixie' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libyang3_3.1.0+dfsg-4_amd64.deb ...
  Unpacking libyang3:amd64 (3.1.0+dfsg-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libyang3_3.1.0+dfsg-4_amd64.deb (--unpack):
   trying to overwrite 
'/usr/share/yang/modules/libyang/ietf-datasto...@2018-02-14.yang', which is 
also in package libyang2:amd64 2.1.30-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libyang3_3.1.0+dfsg-4_amd64.deb

The conflicting files are:

usr/share/yang/modules/libyang/ietf-datasto...@2018-02-14.yang
usr/share/yang/modules/libyang/ietf-inet-ty...@2013-07-15.yang
usr/share/yang/modules/libyang/ietf-yang-libr...@2019-01-04.yang
usr/share/yang/modules/libyang/ietf-yang-metad...@2016-08-05.yang
usr/share/yang/modules/libyang/ietf-yang-schema-mo...@2019-01-14.yang
usr/share/yang/modules/libyang/ietf-yang-structure-...@2020-06-17.yang
usr/share/yang/modules/libyang/ietf-yang-ty...@2013-07-15.yang
usr/share/yang/modules/libyang/y...@2022-06-16.yang


cheers,

Andreas


libyang2=2.1.30-2_libyang3=3.1.0+dfsg-4.log.gz
Description: application/gzip

Bug#1078134: lz4: new lz4Config.cmake file causes FTBFS due to bogus xxhash dependency

[Andrea Pappacoda]

Source: lz4
Version: 1.9.4-3
Severity: important
Tags: ftbfs
Control: affects -1 yuzu
Control: block 1077401 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, the newly introduced lz4Config.cmake file is currently causing yuzu (and
probably other packages as well) to failing to build from source, since the
file contains an INTERFACE (aka transitive) dependency on the "xxhash" library,
contained in libxxhash-dev. This is wrong, since xxhash is a hidden (i.e.
internal) dependency of liblz4, and users need not pass compiler or linker
directives mentioning xxhash when consuming liblz4. As you can see from the
files themselves:

$ dpkg --listfiles liblz4-dev | xargs grep -s xxhash
/usr/lib/x86_64-linux-gnu/cmake/lz4/lz4Targets.cmake:
INTERFACE_LINK_LIBRARIES "xxhash"
/usr/lib/x86_64-linux-gnu/cmake/lz4/lz4Targets.cmake:
INTERFACE_LINK_LIBRARIES "xxhash"
grep: /usr/lib/x86_64-linux-gnu/liblz4.so: binary file matches

xxhash isn't included in public headers, and the pkg-config file rightfully
doesn't mention xxhash at all. CMake is the only one wrong.

Given upstream's only supported build system are Makefiles, and the only
supported way of consuming the library as a dependency is via its pkg-config
file, you have two choices:

1. Go back to using the official Makefiles, and stop using the community
maintained CMake build scripts
2. Fix this issue upstream, and keep fixing CMake issues, adding maintenance
burden

Given using CMake instead of the officially supported build system has caused
issues to Arch Linux in the past[1] for the zstd package (which has the same
upstream developer and build system situation), I generally find it unwise to
use CMake at all for Debian. I know, people will keep asking for CMake config
files, but sometimes it's fine to just say no. In my opinion, this is a
decision that has to be taken upstream, not here; Debian should follow
upstream's recommendations.

If you have any question related to CMake or build systems in general, feel
free to ask!

Bye :)

[1]: https://www.phoronix.com/news/Arch-Linux-Bizarre-Zstd


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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZrNMwxQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3p9KMAQC6tGUvQD30GejfqLARrGRuGBL4E0S8
KCy0FaiuG6TIEwD+PacPP0ElqhY9EdQ88VmkAvdX7al6Nb1jSljNldNC3Qg=
=ladj
-END PGP SIGNATURE-

Bug#1078135: RFP: mesa-amber -- free implementation of the OpenGL API -- Amber GLX vendor library

[Aptivi]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: c...@aptivi.anonaddy.com

* Package name: mesa-amber
  Version : 21.3.9-1
  Upstream Contact: Debian X Strike Force 
* URL : https://mesa3d.org/
* License : MIT
  Programming Lang: C
  Description : free implementation of the OpenGL API -- Amber GLX vendor 
library

Mesa is a 3-D graphics library with an API which is very similar to
that of OpenGL.  To the extent that Mesa utilizes the OpenGL command
syntax or state machine, it is being used with authorization from
Silicon Graphics, Inc.  However, the authors make no claim that Mesa
is in any way a compatible replacement for OpenGL or associated with
Silicon Graphics, Inc.

This version of Mesa provides GLX and DRI capabilities: it is capable of
both direct and indirect rendering.  For direct rendering, it can use DRI
modules from the libgl1-amber-dri package to accelerate drawing.

---

Source code is on https://salsa.debian.org/xorg-team/lib/mesa-amber

This package is useful because there are still older computers whose
graphics cards are not supported by the current Mesa version shipped
with the latest versions of Debian, such as the Radeon 9200 series that
use the R200 microcode. This is because I have an older computer that
holds such a card, so I use it from time to time.

I plan to maintain it someday, inside the Debian X Strike Force team
https://wiki.debian.org/Teams/XStrikeForce, once I find time to do this.

Bug#1078136: arb: FTBFS with GCC 14: clustalv.c:130:1: error: return type defaults to 'int'

[Andreas Beckmann]

Source: arb
Version: 6.0.6-7
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

arb started to FTBFS when GCC 14 was made the default compiler:

[17:16.880788997]  Make CLUSTAL
make[7]: Entering directory '/build/arb-6.0.6/GDE/CLUSTAL'
cc -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/build/arb-6.0.6=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -O3 
-pipe -fmessage-length=0 -fshow-column -funit-at-a-time -fPIC -fno-com
mon -fstrict-aliasing -fno-diagnostics-show-caret -rdynamic -w -DNDEBUG 
-DDEVEL_RELEASE -DARB_64  -DLINUX   -DIN_ARB_GDE -DIN_ARB_CLUSTAL -c -o 
clustalv.o clustalv.c -I. -I/build/arb-6.0.6/INCLUDE -I/include 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gn
u/glib-2.0/include -I/usr/include/sysprof-6 -pthread
clustalv.c:130:1: error: return type defaults to 'int' [-Wimplicit-int]
make[7]: *** [Makefile:12: clustalv.o] Error 1
make[7]: Leaving directory '/build/arb-6.0.6/GDE/CLUSTAL'


Andreas

Bug#1078132:

[EoflaOE ViceCity]

This is a relevant upstream GitHub: https://github.com/dotnet/dotnet
This is a Launchpad entry: https://launchpad.net/ubuntu/+source/dotnet8

Bug#1077764: Ruling request on os-release specification implementation

[Luca Boccassi]

On Wed, 7 Aug 2024 at 07:54, Sean Whitton  wrote:
>
> Hello,
>
> On Tue 06 Aug 2024 at 11:45pm +01, Luca Boccassi wrote:
>
> > It's just a bunch of emails. I have no idea where that is coming from,
> > because it's certainly not the intention. Your guess about languages
> > is probably accurate.
>
> Your use of English suggests to me you have native or near-native
> fluency, and you said upthread that you live in an English-speaking
> country and see yourself as culturally fitting-in.
> Therefore, I would ask you to think carefully about whether the problem
> may be more subtle than just misunderstandings of English tone.

And I would ask you to understand that your statements about processes
have misled me into changing this proposal in a way that was against
my interest as petitioner. An unfortunate and unintentional
misunderstanding with no ill intent behind it I'm sure, but it still
happened. Naively, this would appear much more problematic to me than
some perceived misunderstandings about unspecified and nebulous
"English tone" (?) in a bunch of emails, but most likely being the
aggrieved party has something to do with it.

A brief summary:

Here you said that you could rule on general principles:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#368
Here I reply asking you to please do so if it is possible, changing
the proposal to be on general principles:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#388
Here you respond to my request by calling a vote to dismiss the
proposal because you don't rule on general principles:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077764#433

Bug#1078137: blimps: FTBFS with GCC 14: error: implicit declaration of function 'gets'

[Andreas Beckmann]

Source: blimps
Version: 3.9+ds-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source

gcc -Wall -O2 -c blksort.c
blksort.c: In function 'main':
blksort.c:242:13: error: implicit declaration of function 'gets'; did you mean 
'fgets'? [-Wimplicit-function-declaration]
  242 | gets(homfile);
  | ^~~~
  | fgets

gets() in declared in stdio.h which semms to be no longer transitively
included.


Andreas


blimps_3.9+ds-2.log.gz
Description: application/gzip

Bug#1078138: git-buildpackage: Please automatically accept 'main' instead of 'master'

[Julian Andres Klode]

Package: git-buildpackage
Version: 0.9.34
Severity: wishlist
X-Debbugs-Cc: j...@debian.org

For various reasons, main is displacing master as the preferred
terminology for git repositories, and it would be nice if
git-buildpackage were to accept both equally/auto-detect
the right name.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1072742: On Romanian translations in the iso-codes package

[Alex]

Dear Remus, thanks for looking into this. If it’s of any help, there already 
exists an open issue in the iso-codes project that I created almost two months 
ago: https://salsa.debian.org/iso-codes-team/iso-codes/-/issues/50



> On 5 Aug 2024, at 18:57, Remus-Gabriel Chelu  
> wrote:
> 
> Hello,
> 
> 
> 
> În 24.07.2024 22:18, Remus-Gabriel Chelu a scris:
> 
>> 
>> 
>> Hi,
>> 
>> I just published on the mailing list of the Romanian Debian team
>> , the corrected
>> "iso-3166-2-ro.po" file, with a request for review [RFR].
>> 
>> I hope that at the beginning of next month (probably Sunday, the 4th day
>> of the month), I will upload it to Weblate with the changes proposed by the 
>> team.
> 
> Last night, I tried to upload the corrected "iso-3166-2-ro.po" file into
> "iso-codes_Weblate", but ... I couldn't do it!
> 
> On the project page, in fact on the page of each component of the project,
> there is a warning message
> 
> "The translation is temporarily closed for contributions due to maintenance, 
> please come back later.
> The translation was automatically locked due to following alerts: Could not 
> push the repository.";
> clicking on the «Could not push the repository.» link will display the 
> message:
> 
> "Could not push the repository.
> 
> Weblate could not push changes to the upstream repository.
> 
> kex_exchange_identification: Connection closed by remote host
> Connection closed by 2607:f8f0:614:1::1274:44 port 22
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.
>  (128)
> 
> Weblate will retry the operation once it is needed again,
> so the alert might disappear for the temporary issues.
> Appeared 3 months ago, last seen 3 months ago"
> 
> 
> That's why I'm attaching the corrected file here, so as not to open another
> bug report on the "iso-codes" project.
> 
> --
> Greetings,
> Remus-Gabriel
> 

Bug#1076365: ITP: opam-0install-cudf -- Opam solver using 0install backend using the CUDF interface

[Kate Deplaix]

Hi,

opam-0install-cudf maintainer here,

Just as a side note on:
* Upstream Contact: Thomas Leonard
* URL: https://github.com/ocaml-opam/opam-0install-solver

The URL, while still correct until 0.4.3, has recently been split off into its 
own repository a few days ago. See:
https://github.com/ocaml-opam/opam-0install-solver/issues/54

The upstream contact should also be me anyway: Kate Deplaix, as Thomas only 
maintains the opam-0install part of the old repository and I'm the main 
maintainer of the new repository:
https://github.com/ocaml-opam/opam-0install-cudf

If there is anything I can do to help move this new package forward (as it is 
required to update the opam package), please let me know.

Cheers,
Kate

Bug#1078139: Please update golang version to >=1.22 or at least >=1.19.13 in the stable Bookworm release, due to CVEs

[Prusty, Badrikesh]

Package: golang-go
Version: 2:1.19~1
Severity: important

Hello Debian Team,

As golang-1.19-go version 1.19.8-2 is affected by various critical and high 
CVEs. List:

CVE List:

  *   https://security-tracker.debian.org/tracker/CVE-2023-29405: 9.8
  *   https://security-tracker.debian.org/tracker/CVE-2023-24540: 9.8
  *   https://security-tracker.debian.org/tracker/CVE-2023-29402: 9.8
  *   https://security-tracker.debian.org/tracker/CVE-2023-29404: 9.8
  *   https://security-tracker.debian.org/tracker/CVE-2023-29403: 7.8
The above listed CVEs got fixed in version 1.19.10 and above.



  *   https://security-tracker.debian.org/tracker/CVE-2023-39323: 8.1
  *   https://security-tracker.debian.org/tracker/CVE-2024-24784: 7.5
  *   https://security-tracker.debian.org/tracker/CVE-2024-24785: 7.5
  *   https://security-tracker.debian.org/tracker/CVE-2023-45289: 7.5
  *   https://security-tracker.debian.org/tracker/CVE-2023-45290: 7.5
  *   https://security-tracker.debian.org/tracker/CVE-2024-24783: 7.5
The above listed CVEs got fixed in version 1.21 and 1.22.1 and above.

Found that the updated version of package available in bookworm-backports.
golang-1.19-go  v1.19.13: 
https://packages.debian.org/bookworm-backports/golang-1.19-go
golang-1.22-go v1.22.1: 
https://packages.debian.org/bookworm-backports/golang-1.22-go

golang-go points 1.19.8 in Bookworm: 
https://packages.debian.org/bookworm/golang-go,
while 1.22.1 in Bookworm backports: 
https://packages.debian.org/bookworm-backports/golang-go

Kindly update golang version to >=1.22 or atleast >=1.19.13 in the stable 
Bookworm release for fixing the above listed vulnerabilities.

Let us know if any help is needed from my side for migrating the package from 
backports to stable Bookworm release.


Thanks & Regards,
Badrikesh

Bug#1078126: Unable to run «timedatectl» (missing d-bus dependency?)

[Camaleón]

El 2024-08-07 a las 11:13 +0200, Michael Prokop escribió:

> * Camaleón [Wed Aug 07, 2024 at 10:57:52AM +0200]:
> 
> > After installing «systemd-timesyncd», when I run timedatectl (either as 
> > root or 
> > plain user) I get an error and command is not run: 
> > 
> > root@noc11:~# timedatectl status
> > Failed to connect to bus: No such file or directory
> > 
> > This is a barebone/headless server (no X, no UI), maybe a missing 
> > dependency (d-bus?) that is not pulled to be installed but should be.
> > 
> > root@noc11:~# dpkg -l | grep -e dbus -e systemd
> > ii  libdbus-1-3:amd641.14.10-1~deb12u1   amd64  
> >   simple interprocess messaging system (library)
> > ii  libsystemd-shared:amd64  252.26-1~deb12u2amd64  
> >   systemd shared private library
> > ii  libsystemd0:amd64252.26-1~deb12u2amd64  
> >   systemd utility library
> > ii  systemd  252.26-1~deb12u2amd64  
> >   system and service manager
> > ii  systemd-sysv 252.26-1~deb12u2amd64  
> >   system and service manager - SysV compatibility symlinks
> > ii  systemd-timesyncd252.26-1~deb12u2amd64  
> >   minimalistic service to synchronize local time with NTP servers
> 
> systemd-timesyncd depends on systemd, which further has dbus in
> recommends via:
> 
>   Recommends: default-dbus-system-bus | dbus-system-bus, systemd-timesyncd | 
> time-daemon
> 
> So it looks like you have recommends disabled on your system.

Sure, it's a must for a clean system :-)

> If you're doing this you're leaving the defaults and need
> to handle this on your own, also see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

I would either consider:

1. Setting dbus or dbus-broker as (dep)endency for systemd; or
2. Setting dbus or dbus-broker as (rec)ommended for systemd-timesyncd.

> (Closing the bug report, as it's not a bug in systemd / systemd-timesyncd.)

Fair enough.

After installing dbus AND starting dbus daemon, the order is run as 
expected:

root@noc11:~# apt install dbus
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias... Hecho
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes adicionales:
  dbus-bin dbus-daemon dbus-session-bus-common dbus-system-bus-common
Paquetes sugeridos:
  default-dbus-session-bus | dbus-session-bus
Se instalarán los siguientes paquetes NUEVOS:
  dbus dbus-bin dbus-daemon dbus-session-bus-common 
dbus-system-bus-common
0 actualizados, 5 nuevos se instalarán, 0 para eliminar y 0 no 
actualizados.
Se necesita descargar 544 kB de archivos.
Se utilizarán 1.020 kB de espacio de disco adicional después de esta 
operación.
¿Desea continuar? [S/n] s

(...)

root@noc11:~# systemctl start dbus
root@noc11:~# timedatectl status
   Local time: mié 2024-08-07 13:00:18 CEST
   Universal time: mié 2024-08-07 11:00:18 UTC
 RTC time: mié 2024-08-07 11:00:18
Time zone: Europe/Madrid (CEST, +0200)
System clock synchronized: yes
  NTP service: active
  RTC in local TZ: no


Cheers,

-- 
Camaleón 

Bug#1074303: Re: [Pkg-utopia-maintainers] Bug#1074303: Re: Bug on Debian 12 Bookworm - RJ-45 wired network does not start when booting Debian

[pham...@bluewin.ch]

I opened a first bug, you asked me to make a diagnosis that was not the right 
one and you closed my bug.
I had to reopen it and 3 times in a row you started asking me to make commands 
to then come and tell me that it is not what you expected of me and then you 
close my bug again!?!
If you do not realize that we do not have the right to do this with people, 
have it explained to you by others than me, because this is too much for me!!
It is me who feels taken for an idiot by you and I tell you clearly, if this 
poses a problem for you it is your story, but you are not doing the job that is 
expected of you as a Debian user impacted by problems ;-(
You should seriously think about questioning yourself !!!
Greetings.
Message d'origine
De : bi...@debian.org
Date : 07/08/2024 - 12:45 (E)
À : pham...@bluewin.ch, 1074303-d...@bugs.debian.org
Objet : Re: [Pkg-utopia-maintainers] Bug#1074303: Re: Bug on Debian 12 Bookworm 
- RJ-45 wired network does not start when booting Debian
[snip rants and insults] such toxic behaviour is not welcome in Debian. I would 
kindly ask you to stop that. 

Bug#1075584: tree-puzzle: ftbfs with failure to link sprng symbols

[Étienne Mollier]

Control: tag -1 confirmed

Since the bug submission, it seems another issue cropped up.
From what I can parse of the new build output, something off
went of with the sprng symbols.  Relevant part of the build:

Use Debian packaged libsprng2.
gcc  -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection  
-Wl,-z,relro -Wl,-z,now sgamma.o sml1.o sml2.o smlparam.o smodel1.o smodel2.o 
spuzzle1.o spuzzle2.o spstep.o sutil.o sconsensus.o streesort.o streetest.o  
-lsprng -lm  -o puzzle
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_mod'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_cmp'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_powm'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_abs'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_init_set_str'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_set'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_get_ui'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpq_init'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_sub_ui'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_mul'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_pow_ui'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpq_set_den'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_mul_ui'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_set_str'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_add_ui'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpq_set_num'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_init_set_ui'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpq_get_den'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_fdiv_q_2exp'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_neg'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_sub'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_init'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_clear'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_fdiv_q'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `__mpn_add_n'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpq_get_num'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_cmp_ui'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `__mpn_sub_n'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_init_set'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-linux-gnu/14/../../../../lib/libsprng.so: undefined 
reference to `mpz_add'
collect2: error: ld returned 1 exit status

As far as I can tell, this seems to be a problem within sprng,
because tree-puzzle does not make direct use of the referenced
symbols.
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/0, please excuse my verbosity
   `-on air: Beardfish - Sleeping in Traffic


signature.asc
Description: PGP signature

Bug#1078099: licenserecon: GFDL-NIV-1.3+ is detected as GFDL-1.3+

[Peter B]

On 06/08/2024 22:28, Soren Stoutner wrote:


d/copyright | licensecheck

GFDL-NIV-1.3+   | GFDL-1.3+doc/index.docbook



Hi Soren,

Thanks for your report.

Its probably a bug in licensecheck.
I'll clone the bug there, and do a workaround in licenserecon.


Regards,
Peter

Bug#1078072: licenserecon: Make 'lrc' manual page more useful, add switches etc.

[Peter B]

On 06/08/2024 16:40, Phil Wyett wrote:

Package: licenserecon
Version: 1.14
Severity: normal

Dear Maintainer,

Please make the 'lrc' manual page more useful i.e. adding switches etc.

Regards

Phil


Hi Phil,

The brief man page tells users to run 'lrc -h'
to get help, including the options.

This should be easy enough.

Options are deliberately placed at the end of the help,
so they do not scroll off the top of the console.

I have used readme files, which are output is response to -h
as preference to detailed man pages, as it if far easier
to internationalise a plain text file, than a man page.
I have 5 locales already, and hope to add more.

However, I realise that currently, neither -h or -v
options work without a debian/copyright!

I intend to fix this problem first.


Regards,
Peter

Bug#1078140: plasma-desktoptheme: missing Breaks+Replaces: plasma-framework (<< 6)

[Andreas Beckmann]

Package: plasma-desktoptheme
Version: 6.1.3-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../plasma-desktoptheme_6.1.3-3_amd64.deb ...
  Unpacking plasma-desktoptheme (6.1.3-3) ...
  dpkg: error processing archive 
/var/cache/apt/archives/plasma-desktoptheme_6.1.3-3_amd64.deb (--unpack):
   trying to overwrite '/usr/share/plasma/desktoptheme/breeze-dark/colors', 
which is also in package plasma-framework 5.115.0-2
  Errors were encountered while processing:
   /var/cache/apt/archives/plasma-desktoptheme_6.1.3-3_amd64.deb

The conflicting files are

usr/share/plasma/desktoptheme/breeze-dark/colors
usr/share/plasma/desktoptheme/breeze-dark/metadata.json
usr/share/plasma/desktoptheme/breeze-dark/plasmarc
usr/share/plasma/desktoptheme/breeze-light/colors
usr/share/plasma/desktoptheme/breeze-light/metadata.json
usr/share/plasma/desktoptheme/breeze-light/plasmarc
usr/share/plasma/desktoptheme/default/dialogs/background.svgz
usr/share/plasma/desktoptheme/default/icons/akonadi.svgz
usr/share/plasma/desktoptheme/default/icons/akregator.svgz
usr/share/plasma/desktoptheme/default/icons/amarok.svgz
usr/share/plasma/desktoptheme/default/icons/applications.svgz
usr/share/plasma/desktoptheme/default/icons/apport.svgz
usr/share/plasma/desktoptheme/default/icons/audio.svgz
usr/share/plasma/desktoptheme/default/icons/battery.svgz
...
usr/share/plasma/desktoptheme/oxygen/widgets/scrollbar.svgz
usr/share/plasma/desktoptheme/oxygen/widgets/scrollwidget.svgz
usr/share/plasma/desktoptheme/oxygen/widgets/slider.svgz
usr/share/plasma/desktoptheme/oxygen/widgets/tabbar.svgz
usr/share/plasma/desktoptheme/oxygen/widgets/tasks.svgz
usr/share/plasma/desktoptheme/oxygen/widgets/timer.svgz
usr/share/plasma/desktoptheme/oxygen/widgets/tooltip.svgz
usr/share/plasma/desktoptheme/oxygen/widgets/translucentbackground.svgz
usr/share/plasma/desktoptheme/oxygen/widgets/viewitem.svgz


cheers,

Andreas


plasma-framework=5.115.0-2_plasma-desktoptheme=6.1.3-3.log.gz
Description: application/gzip

Bug#1078124: Proposed patch

[Gianluigi Tiesi]

this is the proposed patch, it was extracted and adapted from upstream
open source kernel module at
this commit:

https://github.com/NVIDIA/open-gpu-kernel-modules/commit/74ee05e16071354fa68b25461c5a62529dc1

tested with 6.10.3 using nvidia 535.183.01

perhaps follow_pte was already gpl only in 6.9.12 but still compiles
for some reason

the currently implementation of nv_follow_pfn() returns -1, but the
same is for new nvidia version
diff -ur nvidia-current-535.183.01.orig/conftest.sh nvidia-current-535.183.01/conftest.sh
--- nvidia-current-535.183.01.orig/conftest.sh	2024-06-14 11:20:01.0 +0200
+++ nvidia-current-535.183.01/conftest.sh	2024-08-07 12:50:57.923895110 +0200
@@ -5181,22 +5181,23 @@
 compile_check_conftest "$CODE" "NV_PCI_CLASS_MULTIMEDIA_HD_AUDIO_PRESENT" "" "generic"
 ;;
 
-unsafe_follow_pfn)
+follow_pfn)
 #
-# Determine if unsafe_follow_pfn() is present.
+# Determine if follow_pfn() is present.
 #
-# unsafe_follow_pfn() was added by commit 69bacee7f9ad
-# ("mm: Add unsafe_follow_pfn") in v5.13-rc1.
+# follow_pfn() was added by commit 3b6748e2dd69
+# ("mm: introduce follow_pfn()") in v2.6.31-rc1, and removed
+# by commit 233eb0bf3b94 ("mm: remove follow_pfn")
+# from linux-next 233eb0bf3b94.
 #
 CODE="
 #include 
-void conftest_unsafe_follow_pfn(void) {
-unsafe_follow_pfn();
+void conftest_follow_pfn(void) {
+follow_pfn();
 }"
 
-compile_check_conftest "$CODE" "NV_UNSAFE_FOLLOW_PFN_PRESENT" "" "functions"
+compile_check_conftest "$CODE" "NV_FOLLOW_PFN_PRESENT" "" "functions"
 ;;
-
 drm_plane_atomic_check_has_atomic_state_arg)
 #
 # Determine if drm_plane_helper_funcs::atomic_check takes 'state'
diff -ur nvidia-current-535.183.01.orig/nvidia/nvidia.Kbuild nvidia-current-535.183.01/nvidia/nvidia.Kbuild
--- nvidia-current-535.183.01.orig/nvidia/nvidia.Kbuild	2024-06-14 11:20:01.0 +0200
+++ nvidia-current-535.183.01/nvidia/nvidia.Kbuild	2024-08-07 12:58:41.718220280 +0200
@@ -161,7 +161,7 @@
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += vga_tryget
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += cc_platform_has
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += seq_read_iter
-NV_CONFTEST_FUNCTION_COMPILE_TESTS += unsafe_follow_pfn
+NV_CONFTEST_FUNCTION_COMPILE_TESTS += follow_pfn
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += drm_gem_object_get
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += drm_gem_object_put_unlocked
 NV_CONFTEST_FUNCTION_COMPILE_TESTS += add_memory_driver_managed
@@ -199,6 +199,7 @@
 
 NV_CONFTEST_SYMBOL_COMPILE_TESTS += is_export_symbol_gpl_of_node_to_nid
 NV_CONFTEST_SYMBOL_COMPILE_TESTS += is_export_symbol_gpl_sme_active
+NV_CONFTEST_SYMBOL_COMPILE_TESTS += is_export_symbol_gpl_follow_pte
 NV_CONFTEST_SYMBOL_COMPILE_TESTS += is_export_symbol_present_swiotlb_map_sg_attrs
 NV_CONFTEST_SYMBOL_COMPILE_TESTS += is_export_symbol_present_swiotlb_dma_ops
 NV_CONFTEST_SYMBOL_COMPILE_TESTS += is_export_symbol_present___close_fd
diff -ur nvidia-current-535.183.01.orig/nvidia/os-mlock.c nvidia-current-535.183.01/nvidia/os-mlock.c
--- nvidia-current-535.183.01.orig/nvidia/os-mlock.c	2024-05-12 22:26:49.0 +0200
+++ nvidia-current-535.183.01/nvidia/os-mlock.c	2024-08-07 13:18:21.734359573 +0200
@@ -36,10 +36,28 @@
 unsigned long address,
 unsigned long *pfn)
 {
-#if defined(NV_UNSAFE_FOLLOW_PFN_PRESENT)
-return unsafe_follow_pfn(vma, address, pfn);
-#else
+#if defined(NV_FOLLOW_PFN_PRESENT)
 return follow_pfn(vma, address, pfn);
+#else
+#if !NV_IS_EXPORT_SYMBOL_GPL_follow_pte
+int status = 0;
+spinlock_t *ptl;
+pte_t *ptep;
+
+if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
+return status;
+
+status = follow_pte(vma, address, &ptep, &ptl);
+if (status)
+return status;
+*pfn = pte_pfn(ptep_get(ptep));
+
+// The lock is acquired inside follow_pte()
+pte_unmap_unlock(ptep, ptl);
+return 0;
+#else // NV_IS_EXPORT_SYMBOL_GPL_follow_pte
+return -1;
+#endif // NV_IS_EXPORT_SYMBOL_GPL_follow_pte
 #endif
 }
 

Bug#1078100: licenserecon: Detects licenses mentioned in passing in the header as being the file license.

[Peter B]

Hi Soren,

On 06/08/2024 22:11, Soren Stoutner wrote:

This might not be a scenario that is possible to accurately handle in an 
automated fashion.


Agreed.


I'll consider implementing an override feature,
to handle problem files like this.

lrc already has a hardwired internal list of excluded files.
Just needs to be made more extendable (i.e. external file lists)


Regards,
Peter

Bug#1078141: cufflinks: FTBFS with GCC 14: locfit/c_plot.c:470:14: error: passing argument 1 of 'setvarname' from incompatible pointer type

[Andreas Beckmann]

Source: cufflinks
Version: 2.2.1+dfsg.1-9
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)

Hi,

cufflinks started to FTBFS when GCC 14 was made the default compiler:

gcc -DHAVE_CONFIG_H -I. -I..  -I../src  -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include  -Wall -Wno-strict-aliasing -g -gdwarf-2 -Wunused 
-Wuninitialized -ftemplate-depth-1024  -O3 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/build/cufflink
s-2.2.1+dfsg.1=. -fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -std=c++14 -DNDEBUG  -c -o c_plot.o 
`test -f 'locfit/c_plot.c' || echo './'`locfit/c_plot.c
cc1: warning: command-line option '-std=c++14' is valid for C++/ObjC++ but not 
for C
cc1: warning: command-line option '-ftemplate-depth=1024' is valid for 
C++/ObjC++ but not for C
locfit/c_plot.c: In function 'plotfit':
locfit/c_plot.c:228:13: warning: variable 'sd' set but not used 
[-Wunused-but-set-variable]
  228 |   double c, sd, xl[2*MXDIM], xll[2];
  | ^~
locfit/c_plot.c:226:36: warning: variable 'sef' set but not used 
[-Wunused-but-set-variable]
  226 | { INT add, d, dp, i = 0, j = 0, n, sef;
  |^~~
locfit/c_plot.c: In function 'setplot':
locfit/c_plot.c:470:14: error: passing argument 1 of 'setvarname' from 
incompatible pointer type [-Wincompatible-pointer-types]
  470 |   setvarname(curstr,tname);
  |  ^~
  |  |
  |  char *
In file included from locfit/lffuns.h:214,
 from locfit/local.h:106,
 from locfit/c_plot.c:6:
locfit/vari.hpp:16:27: note: expected 'vari *' but argument is of type 'char *'
   16 | void setvarname(vari* v, varname name);
  | ~~^
make[3]: *** [Makefile:1044: c_plot.o] Error 1


Andreas


cufflinks_2.2.1+dfsg.1-9.log.gz
Description: application/gzip

Bug#1078115: azure-cli - fails to get access token: User 'X' does not exist in MSAL token cache

[Luca Boccassi]

Control: severity -1 minor
Control: reassign -1 microsoft-authentication-extensions-for-python

On Wed, 7 Aug 2024 10:18:59 +0200 Bastian Blank 
wrote:
> Control: severity -1 serious
> 
> On Wed, Aug 07, 2024 at 09:59:06AM +0200, Bastian Blank wrote:
> > With a brand new config and after using "az login" to login with
exactly
> > the mentioned user, this now fails with:
> > | % az account get-access-token    
> > | User 'wa...@spi-inc.org' does not exist in MSAL token cache. Run
`az login`.
> > | % grep waldi@spi ~/.azure/msal_token_cache.json 
> > |    "username": "wa...@spi-inc.org",
> 
> Okay, this problem is fixed in
>
https://github.com/AzureAD/microsoft-authentication-extensions-for-python/commit/6fd4920f20ab36263a55ad228c432265f8d2f2eb
> and released with python-msal-extensions 1.2.0.  What a shitshow.
> 
> In a nut shell: the token cache changed function namens from find to
> search.  msal_extensions 1.1.0 wraps "find" to actually read the
token
> cache, but azure-cli uses "search".

Sigh they tag their betas as "1.2.0b1" so uscan on ddpo doesn't show
that 1.2.0 was actually released and it looked like it was still in
beta

-- 
Kind regards,
Luca Boccassi


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

Bug#1078142: libxml-grddl-perl: warns on usage with Perl 5.40: Attempt to call undefined import method with arguments

[Niko Tyni]

Package: libxml-grddl-perl
Version: 0.004-4
Severity: important
Tags: trixie sid
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This module warns on usage with Perl 5.40 (currently in experimental).
This causes an autopkgtest regression.

  https://ci.debian.net/packages/libx/libxml-grddl-perl/unstable/amd64/50046702/

  $ perl -e 'use XML::GRDDL'
  Attempt to call undefined import method with arguments ("1.097") via package 
"RDF::RDFa::Parser" (Perhaps you forgot to load the package?) at 
/usr/share/perl5/XML/GRDDL.pm line 10.

I expect s/'1.097'/1.097/ will fix this.

Information on the new warning can be found at

  
https://metacpan.org/dist/perl/view/pod/perldelta.pod#Calling-the-import-method-of-an-unknown-package-produces-a-warning

-- 
Niko Tyni   nt...@debian.org

Bug#1078143: Please update curl version to >=8.7 in the stable Bookworm release, due to CVE-2024-2398

[Prusty, Badrikesh]

Package: curl
Version: 7.88.1-10+deb12u6
Severity: important

Hello Debian Team,

As curl version 7.88.1-10+deb12u6 is affected by CVE:
https://security-tracker.debian.org/tracker/CVE-2024-2398: 8.6

The listed CVE got fixed in version >=8.7.
Found that the updated version 8.8.0-1~bpo12+1 of package available in 
bookworm-backports:
https://packages.debian.org/source/bookworm-backports/curl

Kindly update curl and its library packages to 8.8.0-1 to fix the above listed 
vulnerability.

Let us know if any help is needed from my side for migrating the package from 
backports to stable Bookworm release.


Thanks & Regards,
Badrikesh

Bug#1078144: gcc-14: FTBFS: /bin/bash: line 1: gnatmake: command not found

[zhangdandan]

Source: gcc-14
Version: 14.2.0-1
Severity: important
Tags: sid
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the gcc-14 (14.2.0-1) failed for loong64 in the Debian Package 
Auto-Building environment.

For loong64, build-depend on the gdc-14 and gnat-14 frontends.
The error log is as follows,
```
mkdir -p ada/gen_il
cd ada/gen_il; gnatmake -v -g -gnata -gnat2012 -gnatw.g -gnatyg -gnatU
-I/<>/src/gcc/ada gen_il-main
mkdir -p ada/bldtools/snamest
touch ada/GNAT_DATE
cp -p -f ../../src/gcc/ada/libgnat/gnat.ads ada/gnat.ads
/bin/bash: line 1: gnatmake: command not found
make[5]: *** [../../src/gcc/ada/Make-generated.in:21: ada/stamp-gen_il]
Error 127
make[5]: *** Waiting for unfinished jobs
rm -f ada/bldtools/snamest/snames.ads-tmpl
ada/bldtools/snamest/snames.adb-tmpl ada/bldtools/snamest/snames.h-tmpl
ada/bldtools/snamest/xsnamest.adb ada/bldtools/snamest/xutil.ads
ada/bldtools/snamest/xutil.adb
cp -p ../../src/gcc/ada/snames.ads-tmpl
../../src/gcc/ada/snames.adb-tmpl ../../src/gcc/ada/snames.h-tmpl
../../src/gcc/ada/xsnamest.adb ../../src/gcc/ada/xutil.ads
../../src/gcc/ada/xutil.adb ada/bldtools/snamest
cd ada/bldtools/snamest && gnatmake -v xsnamest && ./xsnamest
/bin/bash: line 1: gnatmake: command not found
make[5]: *** [../../src/gcc/ada/Make-generated.in:49: ada/stamp-snames]
Error 127
make[5]: Leaving directory '/<>/build/gcc'
```

The lastest build log (2024-08-07 09:28:19) can be found at 
https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=loong64&ver=14.2.0-1&stamp=1723022899&raw=0. 


gcc-14 provides gnatmake-14, without gnatmake.
The command gnatmake is used in gcc-14(14.2.0-1) 
src/gcc/ada/Make-generated.in.

Please pay attention to the above phenomenon.

Thanks,
Dandan Zhang

Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Julian Andres Klode]

On Wed, Aug 07, 2024 at 12:05:54PM GMT, Vincent Lefevre wrote:
> On 2024-08-07 11:56:56 +0200, Julian Andres Klode wrote:
> > Control: reassign -1 aptitude
> > Control: retitle -1 aptitude: frontend lock support
> > 
> > On Wed, Aug 07, 2024 at 11:38:35AM GMT, Vincent Lefevre wrote:
> > > On 2024-08-07 11:04:15 +0200, Guillem Jover wrote:
> > > > On Thu, 2024-07-25 at 11:03:50 +0200, Vincent Lefevre wrote:
> > > [...]
> > > > > With VERBOSE=2, I could get more details about this failure:
> > > > > 
> > > > > Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily 
> > > > > apt download activities...
> > > > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock 
> > > > > /var/lib/dpkg/lock-frontend. It is held by process 378454 (apt)
> > > > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire 
> > > > > the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another 
> > > > > process using it?
> > > > > Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in 
> > > > > cron job with "apt-get check".
> > > > > Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated 
> > > > > successfully.
> > > > > Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily 
> > > > > apt download activities.
> > > > > 
> > > > > Here, the failure occurs in the apt.systemd.daily, because the
> > > > > process used for the upgrade got the lock first. But it could
> > > > > be the other way round, as this could be seen with aptitude.
> > > > 
> > > > So, as mentioned above, and as we saw earlier in the bug report, it 
> > > > looks
> > > > like the lock handling in the apt-daily.service is not working, and is
> > > > interfering with the current run. This needs to be fixed there
> > > > somehow. Reassigning.
> > > 
> > > OK. So, in short, apt keeps the lock for too long. The lock should
> > > be released by apt for triggers since a lock may be needed by some
> > > process run by a trigger.
> > 
> > No that's nonsense. The frontend lock is exactly supposed to be held
> > while running dpkg (which runs the lock). This is working as designed.
> 
> WRONG! You can see above an error *without* using aptitude.
> Even though there may be a bug in aptitude, there is also
> a bug related to apt.

If you believe there is another bug then you are free to open another
one with a summary, but I am not going to read a wild goose chase thread
in this bug about another bug you discover while trying to figure out
what's going on with your aptitude.

The behavior you show here in this final email with your log is entirely
correct: apt-daily.service fails to run because you are holding the lock
in an apt execution. This is a feature, not a bug.

On upgrades, we do not restart or reload or otherwise interact with
either apt-daily service, and the services are ordered so they do not
run at the same time either; so you won't see races between the services
or races from the service being restarted and lose to a parent apt
process.

But either way, the service is designed to fail this way. There's a
reason it runs twice a day despite only needing to run once a day,
precisely to give it a chance to catch up if it missed a run due
to a lock.

Now you could make it wait for the frontend lock, but whether this
is advisable is another story, it certainly will make your original
bug report worse: apt is guaranteed to steal aptitude's lock if it
starts while aptitude is running, so it seems worthwhile to fix this
bug.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1078145: trn4: FTBFS with GCC 14: error: return type defaults to 'int'

[Andreas Beckmann]

Source: trn4
Version: 4.0-test77-17
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

trn4 started to FTBFS when GCC 14 was made the default compiler:

Checking your choice of C compiler and flags for coherency...
I've tried to compile and run the following simple program:


I used the command:

gcc -O -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-Werror=implicit-function-declaration 
-ffile-prefix-map=/build/trn4-4.0-test77=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wall 
-DINET6 -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -fpcc-struct-return -o try 
-Wl,-z,relro try.c -lresolv
./try

and I got the following output:

try.c:3:1: error: return type defaults to 'int' [-Wimplicit-int]
3 | main() { printf("Ok\n"); exit(0); }
  | ^~~~
I can't compile the test program.
You have a BIG problem.  Shall I abort Configure [y]
Ok.  Stopping Configure.


Andreas


trn4_4.0-test77-17.log.gz
Description: application/gzip

Bug#1078146: todo.txt-base: Problematic recommended packages

[Lucas Veltkamp]

Package: todo.txt-base
Version: 2.4
Severity: minor
X-Debbugs-Cc: lu...@henri.lv

Dear Maintainer,

This package, which seeks to provide a base for todo.txt includes libre-office 
as a recommended package. I would suggest that this be changed to 'suggested'. 
While some software is required to view todo.txt files, I do not understand why 
specifically libre-office would be recommended (if this is the purpose of this 
recommendation). This is particularly problematic because this base package is 
a dependency of topydo, a CLI for todo.txt that renders a text editor such as 
libre-office unnecessary for interacting with the todo.txt file. Hence, when I 
sought to install topydo on my computer which I operate exclusively through the 
framebuffer terminal,  apt attempted to install all the dependencies for 
libre-office, forcing me to manually resolve dependencies of the topydo 
package, which obviously was only a minor inconvenience.  
This is my first bug report, so if this is badly formatted or useless, I 
apologise profusely and thank you for your work.

Yours, 
Lucas Veltkamp


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

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

Versions of packages todo.txt-base depends on:
ii  python3 3.12.4-1
ii  python3-configargparse  1.7-1
ii  python3-relatorio   0.10.2-1

Versions of packages todo.txt-base recommends:
ii  libreoffice-writer  4:24.2.5-1

todo.txt-base suggests no packages.

-- no debconf information

Bug#1078147: libkdepim-dev: missing Breaks+Replaces: libkf5libkdepim-dev (<< 4:24)

[Andreas Beckmann]

Package: libkdepim-dev
Version: 4:24.05.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.
This error may also be triggered by having a predecessor package from
'sid' installed while installing the package from 'experimental'.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libkdepim-dev_4%3a24.05.2-1_amd64.deb ...
  Unpacking libkdepim-dev:amd64 (4:24.05.2-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libkdepim-dev_4%3a24.05.2-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/share/dbus-1/interfaces/org.kde.addressbook.service.xml', which is also 
in package libkf5libkdepim-dev:amd64 4:22.12.3-1+b1
  Errors were encountered while processing:
   /var/cache/apt/archives/libkdepim-dev_4%3a24.05.2-1_amd64.deb

The ocnflicting files are:

usr/share/dbus-1/interfaces/org.kde.addressbook.service.xml
usr/share/dbus-1/interfaces/org.kde.mailtransport.service.xml

and I'm not sure whether they really belong into a -dev package.


cheers,

Andreas


libkf5libkdepim-dev=4:22.12.3-1+b1_libkdepim-dev=4:24.05.2-1.log.gz
Description: application/gzip

Bug#1078148: bkchem: Not starting with Python 3.12: No module named 'imp'

[Vincent Meille]

Package: bkchem
Version: 0.14.0~pre4+git20211228-3
Severity: important
Tags: patch

Dear Maintainer,

after showing its logo, this application crashes under the Python 3.12 
environment with this trace:


'''
Traceback (most recent call last):
  File "/usr/share/bkchem/bkchem/bkchem.py", line 185, in 
myapp.initialize()
  File "/usr/share/bkchem/bkchem/main.py", line 116, in initialize
self.init_modes()
  File "/usr/share/bkchem/bkchem/main.py", line 490, in init_modes
import imp
ModuleNotFoundError: No module named 'imp'
'''

This is related to the imp module removal in Python 3.12 [1].

 1 : https://docs.python.org/3/whatsnew/3.12.html#imp

I produced the joined patch with the help of the link above.

Regards,
Vincent.

-- System Information:
Debian Release: trixie/sid
  APT prefers noble-updates
  APT policy: (500, 'noble-updates'), (500, 'noble-security'), (500, 
'noble')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.0-39-generic (SMP w/8 CPU threads; PREEMPT)
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)

Versions of packages bkchem depends on:
ii  python3  3.12.3-0ubuntu1
ii  python3-pil  10.2.0-1ubuntu1

bkchem recommends no packages.

Versions of packages bkchem suggests:
ii  python3-cairo  1.25.1-2build2

-- no debconf information--- a/main.py	2022-01-09 04:27:16.0 +0100
+++ b/main.py	2024-08-07 13:13:30.222462673 +0200
@@ -487,21 +487,32 @@
'plus', 'text', 'bracket', 'rotate', 'bondalign', 'vector', 'misc']#  'reaction', 'externaldata'] #, 'rapiddraw']
 
 # import plugin modes
-import imp
+import importlib.util
+import importlib.machinery
+
+def load_source(modname, filename):
+loader = importlib.machinery.SourceFileLoader(modname, filename)
+spec = importlib.util.spec_from_file_location(modname, filename, loader=loader)
+module = importlib.util.module_from_spec(spec)
+loader.exec_module(module)
+return module
+
 for plug_name in self.plug_man.get_names( type="mode"):
   plug = self.plug_man.get_plugin_handler( plug_name)
   module_name = plug.get_module_name()
   # no invalid characters in mode_name
   mode_name = ''.join(x in string.ascii_letters and x or "X" for x in module_name)
   try:
-module = imp.load_source( module_name, plug.filename)
+module = load_source( module_name, plug.filename)
   except ImportError:
 continue
   else:
 self.modes[ module_name.replace("_","")] = module.plugin_mode()
 self.modes_sort.append( module_name.replace("_",""))
 
-del imp
+del load_source
+del importlib.machinery
+del importlib.util
 
 
   def init_mode_buttons( self):

Bug#1074841: bglibs: diff for NMU version 2.04+dfsg-6.1

[Peter Pentchev]

Control: tags 1074841 + patch
Control: tags 1074841 + pending


Dear maintainer,

I've prepared an NMU for bglibs (versioned as 2.04+dfsg-6.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
-- 
Peter Pentchev  r...@ringlet.net r...@debian.org pe...@morpheusly.com
PGP key:https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
diff -Nru bglibs-2.04+dfsg/debian/changelog bglibs-2.04+dfsg/debian/changelog
--- bglibs-2.04+dfsg/debian/changelog	2023-12-14 01:42:35.0 +0200
+++ bglibs-2.04+dfsg/debian/changelog	2024-08-07 15:20:24.0 +0300
@@ -1,3 +1,11 @@
+bglibs (2.04+dfsg-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload to fix FTBFS.
+  * Add the declarations patch to define _GNU_SOURCE for sigpause(3).
+Closes: #1074841
+
+ -- Peter Pentchev   Wed, 07 Aug 2024 15:20:24 +0300
+
 bglibs (2.04+dfsg-6) unstable; urgency=medium
 
   * Replace 'd/symbols' with regenerated 'd/libbg2.symbols'.
diff -Nru bglibs-2.04+dfsg/debian/patches/declarations.patch bglibs-2.04+dfsg/debian/patches/declarations.patch
--- bglibs-2.04+dfsg/debian/patches/declarations.patch	1970-01-01 02:00:00.0 +0200
+++ bglibs-2.04+dfsg/debian/patches/declarations.patch	2024-08-07 15:15:41.0 +0300
@@ -0,0 +1,16 @@
+Description: Define _GNU_SOURCE for sigpause(3) visibility
+Bug-Debian: https://bugs.debian.org/1074841
+Forwarded: no
+Author: Peter Pentchev 
+Last-Update: 2024-08-07
+
+--- a/unix/sig_suspend.c
 b/unix/sig_suspend.c
+@@ -15,6 +15,7 @@
+  * License along with this library; if not, write to the Free Software
+  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+  */
++#define _GNU_SOURCE
+ #include 
+ #include "sig.h"
+ #include "sysdeps.h"
diff -Nru bglibs-2.04+dfsg/debian/patches/series bglibs-2.04+dfsg/debian/patches/series
--- bglibs-2.04+dfsg/debian/patches/series	2023-12-14 01:42:35.0 +0200
+++ bglibs-2.04+dfsg/debian/patches/series	2024-08-07 15:13:12.0 +0300
@@ -1 +1,2 @@
 001_ensure_use_of_usr_bin_perl.patch
+declarations.patch


signature.asc
Description: PGP signature

Bug#1078149: irpas: FTBFS on 32-bit architectures with 64-bit time_t

[Andreas Beckmann]

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

irpas FTBFS on armhf after the 64-bit time_t switch:

icmp_redirect.c:462:27: error: passing argument 1 of 'ctime' from incompatible 
pointer type [-Wincompatible-pointer-types]
  462 | ctime(&(fanchor->t)));
  |   ^
  |   |
  |   long unsigned int *
In file included from /usr/include/features.h:502,
 from 
/usr/include/arm-linux-gnueabihf/bits/libc-header-start.h:33,
 from /usr/include/stdio.h:28,
 from icmp_redirect.c:9:
/usr/include/time.h:187:14: note: expected 'const time_t *' {aka 'const long 
long int *'} but argument is of type 'long unsigned int *'
  187 | extern char *__REDIRECT_NTH (ctime, (const time_t *__timer), __ctime64);
  |  ^~
make[1]: *** [Makefile:99: icmp_redirect.o] Error 1


Andreas


irpas_0.10-9.log.gz
Description: application/gzip

Bug#1078150: rspamd: autopkgtest regression with Perl 5.40: FAIL stderr: Duplicate specification

[Niko Tyni]

Package: rspamd
Version: 3.8.1-1.1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This package fails its autopkgtest checks with Perl 5.40 (currently
in experimental.)

  https://ci.debian.net/packages/r/rspamd/unstable/amd64/50047150/

 58s + rspamd_stats --log /dev/null
 58s Duplicate specification "symbol-bidir|S=s@" for option "s"
 58s Duplicate specification "exclude-logs|x=i" for option "x"
 58s Duplicate specification "json|j" for option "j"
 58s 
 58s === Summary 

 58s Messages scanned: 0
 58s 
 58s 

 58s autopkgtest [03:10:50]: test rspamd-stats: ---]
 58s autopkgtest [03:10:50]: test rspamd-stats:  - - - - - - - - - - results - 
- - - - - - - - -
 58s rspamd-stats FAIL stderr: Duplicate specification 
"symbol-bidir|S=s@" for option "s"

This is probably fallout from a change in the Getopt::Long library:

  https://metacpan.org/dist/Getopt-Long/changes#L34

  * Fix long standing bug that duplicate options were not detected when
the options differ in case while ignore_case is in effect.
This will now yield a warning and become a fatal error in a future
release.

One way to silence the warning might be

use Getopt::Long qw( :config no_ignore_case );

-- 
Niko Tyni   nt...@debian.org

Bug#1060229: fuse,fuse3,ntfs-3g: migrate dpkg-statoverride for UsrMerge?

[Helmut Grohne]

Control: clone -1 -2
Control: reassign -1 ntfs-3g
Control: reassign -2 fuse
Control: tags -2 + patch

Hi,

On Sun, Jan 07, 2024 at 10:52:52PM +0100, Chris Hofstaedtler wrote:
> Package: fuse,fuse3,ntfs-3g
> X-Debbugs-CC: Laszlo Boszormenyi (GCS) , Helmut Grohne 
> 
> 
> Hello Laszlo!
> 
> fuse, fuse3, and ntfs-3g use dpkg-statoverride on aliased paths in
> /bin: /bin/fusermount, /bin/fusermount3.

I am further splitting this bug after having split off fuse3 earlier.

> They do so in their postinst scripts, only checking if a
> statoverride exists. If not, they run chmod on some programs.
> The postinst does not add a statoverride.
> 
> As you know, these paths need to become canonicalized to /usr/{...}.
> When this happens, the old dpkg-statoverride entries stop working.
> 
> Now my question: do you think it is worth migrating any such
> dpkg-statoverride automatically?
> 
> If not, how should users/admins who previously created an override
> be informed about this problem? Some suggestions might be:
> - NEWS.Debian entry
> - trixie Release Notes
> 
> What do you think?

My earlier patch for fuse3 has reached trixie. It duplicates the
dpkg-statoverride check (and is thus able to deal with both a
/bin/fusermount and /usr/bin/fusermount statoverride) and adds a NEWS
entry requesting the administrator to duplicate their statoverrides.

I am attaching a similar patch for fuse here and leave the original bug
for ntfs-3g only. The patch is independent of the library move #1060229
and both need to be applied to solve /usr-move matters for fuse.

Helmut
diff --minimal -Nru fuse-2.9.9/debian/changelog fuse-2.9.9/debian/changelog
--- fuse-2.9.9/debian/changelog 2024-02-29 23:24:20.0 +0100
+++ fuse-2.9.9/debian/changelog 2024-08-07 14:07:13.0 +0200
@@ -1,3 +1,10 @@
+fuse (2.9.9-8.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Handle both canonial and aliased statoverride. (DEP17 P5) (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 07 Aug 2024 14:07:13 +0200
+
 fuse (2.9.9-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru fuse-2.9.9/debian/fuse.NEWS fuse-2.9.9/debian/fuse.NEWS
--- fuse-2.9.9/debian/fuse.NEWS 1970-01-01 01:00:00.0 +0100
+++ fuse-2.9.9/debian/fuse.NEWS 2024-08-07 14:07:13.0 +0200
@@ -0,0 +1,9 @@
+fuse (2.9.9-8.2) unstable; urgency=medium
+
+  The fuse package honours a dpkg-statoverride of /bin/fusermount installed
+  by a system administrator (e.g. to remove the setuid binary installed by
+  default). The path to this file according to the package manager is
+  transitioned to /usr/bin/fusermount. If you installed a statoverride,
+  please move it to the new path and verify the permissions.
+
+ -- Helmut Grohne   Wed, 07 Aug 2024 14:07:13 +0200
diff --minimal -Nru fuse-2.9.9/debian/fuse.postinst 
fuse-2.9.9/debian/fuse.postinst
--- fuse-2.9.9/debian/fuse.postinst 2023-11-05 13:44:31.0 +0100
+++ fuse-2.9.9/debian/fuse.postinst 2024-08-07 14:07:12.0 +0200
@@ -18,7 +18,8 @@
then
chmod 0600 /dev/cuse > /dev/null 2>&1
fi
-   if ! dpkg-statoverride --list /bin/fusermount > /dev/null 2>&1
+   if ! dpkg-statoverride --list /bin/fusermount > /dev/null 2>&1 
&&
+   ! dpkg-statoverride --list /usr/bin/fusermount > 
/dev/null 2>&1
then
chmod 4755 /bin/fusermount
fi

Bug#1067817: libfuse2: move library to /usr (DEP17 P1)

[Helmut Grohne]

Control: tags -1 + patch

On Tue, Aug 06, 2024 at 07:19:10PM +0200, Chris Hofstaedtler wrote:
> Control: tags -1 - patch
> 
> On Wed, Mar 27, 2024 at 08:33:46AM +0100, Helmut Grohne wrote:
> > fuse2 is involved in the /usr-move (DEP17) in multiple ways. In this bug
> > report, I am staying away from binaries to avoid interference with the
> > statoverride matter #1060229. That still has to be dealt with
> > separately. Here, it is about moving the fuse library having become
> > non-trivial due to the time64 transition. Simply moving it would cause a
> > DEP17 P1 problem incurring file loss on upgrade. I'm attaching a patch
> > implementing the library move in a mitigated (P8 protective diversions)
> > way.
> 
> IIRC you said the patch needs some rework. Please correct me if this
> is wrong.

I believe this is a misunderstanding and that I meant to refer to the
statoverride part of fuse needing work. I looked at my own patch again
and do not see any issues with it now. It should be applied in
combination with a mitigation to statoverride.

Helmut

Bug#1073608: Bug#1074014: Bug#1073622: Bug#1073608: mksh, pax: no move to /usr going to happen, because:

[Helmut Grohne]

Hi Thorsten,

On Wed, Aug 07, 2024 at 09:59:09AM +, Thorsten Glaser wrote:
> >that the way people tend to use mksh is by adding a local diversion for
> 
> Unfortunately not.
> 
> The way we have to do it since squeeze, when dash unilaterally broke
> cross-package coordination, is:
> 
> dpkg-reconfigure dash ⇒ remove its owning of /bin/sh
>  (so it reverts to bash)
> ln -sf lksh /bin/sh
> 
> This cleanly persists across upgrades, bash was never problematic
> wrt this.

I fear this approach no longer works.

In bullseye and earlier, I guess it works.

If you start with bullseye or earlier, upgrade to bookworm and then to
trixie, it continues to work, because the dash maintainer scripts
preserve any diversion that is not owned by dash.

If you start with bookworm, the debconf stuff is gone and your
dpkg-reconfigure does nothing. In order to change your default shell,
you get to remove dash's diversion and do your own diversion. dash will
not touch this diversion.

Before you ugrade to trixie, you'll have to add a diversion for
/usr/bin/sh.

If you start with trixie, debconf and diversion management is gone. All
that remains is code for removing the previous default diversion of
dash. You get to do your own diversion and dash will not touch it.

I see how the changes to /bin/sh management feel annoying to, but the
target state bears quite some benefits in my view:
 * In forky, we will remove all maintainer script snippets related to
   management of /bin/sh (i.e. the remaining diversion cleanup).
   These maintainer scripts posed significant maintenance costs earlier.
 * It is rare to want to change /bin/sh and local diversions are a
   suitable and established mechanism to change package-installed files.
 * Managing debconf stuff from scripting can be more difficult than
   creating a local diversion. For the scripting use case it actually
   becomes easier.

> There is absolutely no reason to force files to move, given they
> are now aliased already *anyway*.

The reason to force the file move is to entirely remove the problem
categories listed at https://subdivi.de/~helmu/dep17.html. Removing
entire classes of problems reduces the collaborative long-term
maintenance cost of the distribution, but it incurs the one-time cost of
performing the move. I see that you disagree with our judgement of the
cost-benefit trade-off, but we have wide agreement inside Debian with
this view. I've had long arguments about this a year ago listened to
concerns and raised my own. I suggest that the time for arguing on this
matter is over unless you bring new information to the table.

Helmut

Bug#1078095: libeccodes-tools: please drop ksh and alternatives

[Gioele Barabucci]

On Wed, 7 Aug 2024 07:29:46 +0200 Gioele Barabucci  wrote:
On Tue, 6 Aug 2024 22:59:42 +0200 Chris Hofstaedtler  
wrote:

> From what I can tell, only /usr/bin/bufr_compare_dir wants /bin/ksh,
> and it looks like it would work unmodified with /bin/bash.
> 
> Please patch /usr/bin/bufr_compare_dir to specify #!/bin/bash and

> drop the Depends: mksh | pdksh | zsh | ksh.

I submitted a PR upstream to make bufr_compare_dir compatible with POSIX 
sh: https://github.com/ecmwf/eccodes/pull/236


The upstream PR is now available as a MR against src:eccodes

https://salsa.debian.org/science-team/eccodes/-/merge_requests/1

Regards,

--
Gioele Barabucci

Bug#841433: ITP: gmat -- Spacecraft mission analysis, desing and simulation

[Christoph Berg]

Re: Rock Storm
> * Package name: gmat
>   Version : 2015a
>   Upstream Author : National Aeronautics and Space Administration
> * URL : http://gmatcentral.org

Seems to have moved to https://software.nasa.gov/software/GSC-17177-1

> * License : Apache-2.0
>   Programming Lang: C++
>   Description : Spacecraft mission analysis, desing and simulation

It requires Matlab to build, so it will need to be in contrib, with no
sane way to autobuild.

Given the last release was 2016 and this RFP hasn't attracted
interest, I'd suggest to just close it.

Christoph

Bug#1078152: libtickit-console-perl: FTBFS with Perl 5.40: Out of memory in perl:util:safesysmalloc

[Niko Tyni]

Package: libtickit-console-perl
Version: 0.12-1
Severity: important
User: debian-p...@lists.debian.org
Usertags: perl-5.40-transition

This package fails to build from source with Perl 5.40 (currently in
experimental.)

  t/05bind_key.t . 
  # Seeded srand with seed '20240804' from local date.
  ok 1 - Console-level key binding receives key
  ok 2 - Console-level key binding receives key with tab focused
  ok 3 - Tab-level key binding receives key
  ok 4 - Console-level key binding does not receive key with tab focused
  ok 5 - Removed tab-level key binding no longer receives key
  ok 6 - Console-level keybinding receives key again
  1..6
  ok
  Out of memory in perl:util:safesysmalloc
  # Tests were run but no plan was declared and done_testing() was not seen.
  # Looks like your test exited with 1 just after 1.
  t/06timestamp.t  
  # Seeded srand with seed '20240804' from local date.
  ok 1 - Display after tab->append_line with timestamp
  Dubious, test returned 1 (wstat 256, 0x100)
  All 1 subtests passed 
  t/99pod.t .. 
  # Seeded srand with seed '20240804' from local date.
  1..2
  ok 1 - POD test for blib/lib/Tickit/Console.pm
  ok 2 - POD test for blib/lib/Tickit/Console/Tab.pm
  ok
  
  Test Summary Report
  ---
  t/06timestamp.t  (Wstat: 256 (exited 1) Tests: 1 Failed: 0)
Non-zero exit status: 1
Parse errors: No plan found in TAP output
  Files=8, Tests=48,  1 wallclock secs ( 0.03 usr  0.01 sys +  1.11 cusr  0.17 
csys =  1.32 CPU)
  Result: FAIL
  
This seems to be quite deterministic on perl.debian.net, with five builds
failing the same way, on both perl_5.40.0~rc1-1 and perl_5.40.0-1.

A full build log is at

  
https://perl.debian.net/rebuild-logs/perl-5.40-throwaway/libtickit-console-perl_0.12-1/libtickit-console-perl_0.12-1_amd64-2024-08-04T13:51:01Z.build

-- 
Niko Tyni   nt...@debian.org