Bug#1069588: src:tcplay: libtcplay package name doesn't match soname

[Daniel Kahn Gillmor]

Source: tcplay
Version: 1.1-6
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

In looking at cleaning up the tcplay package in debian, i noticed that
the libtcplay package name doesn't match the SONAME of libtcplay.so.1.1

It looks like upstream hasn't actually been doing normal C library
versioning (the library versioning is exactly the same as the whole
package version number), and i see no reverse dependencies on libtcplay,
so maybe this isn't a big deal.  But future package cleanup might want
to rename the library packages in some way that fits with the rest of
the C library ecosystem, if this library package is expected to be
useful.

Even tools like luckyluks and zulucrypt don't appear to depend on the
libtcplay library, instead depending on /usr/sbin/tcplay.  That suggests
that the library isn't well-integrated into the ecosystem of tools that
might manage veracrypt or truecrypt volumes.

   --dkg

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)


signature.asc
Description: PGP signature

Bug#1069589: src:tcplay: libtcplay is not cross-platform or multi-arch in any modern way

[Daniel Kahn Gillmor]

Source: tcplay
Version: 1.1-6
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

libtcplay gets installed directly in /usr/lib, and tcplay.pc gets placed
in /usr/lib/pkgconfig.  For modern, multiarch systems, these should
probably be placed in a different location.

We're also currently patching the build system (with
debian/patches/do_not_add_lib_suffix.patch) to avoid sticking "64" on
the end of the library name -- this suggests that upstream also isn't
handling multiarch in any standard debian way.

The library doesn't actually seem to be used anywhere at the moment,
which suggests both that this isn't a big deal, but maybe also that if
the library was adapted to modern practice, maybe it would encourage
more use.

 --dkg

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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)


signature.asc
Description: PGP signature

Bug#1069587: linux-cpupower: turbostat core dump in compute_average, regression

[Witold Baryluk]

Package: linux-cpupower
Version: 6.7.9-2
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com


turbostat 6.7.9-2 core dumps on my AMD Threadripper 2950X

linux-cpupower_6.6.15-2_amd64.deb works fine.

gdb session with 6.7.9-2

root@debian:~# gdb turbostat 
GNU gdb (Debian 13.2-1) 13.2
Reading symbols from turbostat...
Reading symbols from 
/usr/lib/debug/.build-id/6f/8e4bb8d39e0b45899098c6bd0307918833eeb8.debug...
(gdb) r
Starting program: /usr/sbin/turbostat 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
turbostat version 2023.11.07 - Len Brown 
Kernel command line: BOOT_IMAGE=/live/vmlinuz-6.6.15-amd64 intel_iommu=on 
iommu=pt amd_iommu=on radeon.si_support=0 radeon.cik_support=0 
amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.ppfeaturemask=0x 
amdgpu.audio=0 processors.max_cstate=1 intel_idle.max_cstate=0 idle=halt 
modprobe.blacklist=snd_hda_codec_hdmi,snd_hda_intel boot=live components 
locales=en_US.UTF-8 findiso=
CPUID(0): AuthenticAMD 0xd CPUID levels
CPUID(1): family:model:stepping 0x17:8:2 (23:8:2) microcode 0x0
CPUID(0x8000): max_extended_levels: 0x801f
CPUID(1): SSE3 MONITOR - - - TSC MSR - HT -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, 
No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX No-Hybrid
cpu0: cpufreq driver: acpi-cpufreq
cpu0: cpufreq governor: performance
cpufreq boost: 1
/dev/cpu_dma_latency: 4000 usec (constrained)
current_driver: none
current_governor: menu
current_governor_ro: menu
RAPL: 234 sec. Joule Counter Range, at 280 Watts
[New Thread 0x77fc1740 (LWP 1098480)]
[New Thread 0x77d886c0 (LWP 1098481)]
[Thread 0x77d886c0 (LWP 1098481) exited]

Thread 1 "turbostat" received signal SIGFPE, Arithmetic exception.
0xfc24 in compute_average (t=, c=, 
p=) at 
/build/reproducible-path/linux-6.7.9/tools/power/x86/turbostat/turbostat.c:2479
2479  
/build/reproducible-path/linux-6.7.9/tools/power/x86/turbostat/turbostat.c: No 
such file or directory.
(gdb) bt
#0  0xfc24 in compute_average (t=, c=, p=) at 
/build/reproducible-path/linux-6.7.9/tools/power/x86/turbostat/turbostat.c:2479
#1  0x555676ea in turbostat_loop () at 
/build/reproducible-path/linux-6.7.9/tools/power/x86/turbostat/turbostat.c:4364
#2  0x7542 in main (argc=1, argv=0x7fffebe8) at 
/build/reproducible-path/linux-6.7.9/tools/power/x86/turbostat/turbostat.c:6753
(gdb) 


Probably some division by zero in the code.


For comparison older version of turbostat (on same cpu and kernel) shows:

Die Core  CPU Avg_MHz Busy% Bzy_MHz TSC_MHz IPC IRQ CorWatt PkgWatt
- - - 21  1.37  1511  1750  0.67  14450 2.59  39.87
1 0 8 50  1.74  2893  3500  0.73  1115  0.38  39.87
1 0 24  44  1.42  3111  3500  0.66  822
1 1 9 68  2.17  3127  3500  0.75  1051  0.35
1 1 25  20  0.73  2696  3500  0.33  1244
1 2 10  50  1.59  3158  3500  0.50  987 0.30
1 2 26  31  0.99  3151  3500  0.61  1036
1 3 11  40  1.25  3174  3500  0.77  658 0.46
1 3 27  114 3.62  3137  3500  0.85  1186
1 4 12  102 3.20  3171  3500  0.56  1180  0.44
1 4 28  19  0.67  2860  3500  0.40  887
1 5 13  3 0.12  2810  3500  0.33  112 0.18
1 5 29  22  0.81  2768  3500  0.47  899
1 6 14  22  0.83  2670  3500  0.36  1403  0.23
1 6 30  14  0.48  2855  3500  0.35  617
1 7 15  19  0.73  2607  3500  0.41  936 0.26
1 7 31  45  1.59  2833  3500  1.21  317





-- 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.6.15-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-cpupower depends on:
ii  libc6 2.37-17
ii  libcap2   1:2.66-5
ii  libcpupower1  6.7.9-2
ii  libpci3   1:3.10.0-2

linux-cpupower recommends no packages.

linux-cpupower suggests no packages.

-- no debconf information

Bug#1066036: black: Consider building faster native packages with mypyc

[Julian Gilbey]

On Sat, Apr 20, 2024 at 04:50:20PM +0200, Michael R. Crusoe wrote:
> On 19/04/2024 07.17, Julian Gilbey wrote:
> > [...]
> > > Dear Maintainer,
> > > 
> > > I noticed that your package supports building native code extensions using
> > > mypyc. Upstream themselves ship portable binary wheels for better
> > > performance. As a member of the Debian Package Team, I would be happy to 
> > > add
> 
> I should have said "Debian Python Package Team"
> > > this to your package. Please let me know.
> > [...]
> 
> Thanks for the positive response. How do you want the mypyc compilation added 
> to the package? Do you want a diff, a merge-request on Salsa, or a team 
> upload?

I'm not the primary maintainer, so I suggest a team upload once
hatch-pypyc has made it to testing.

Best wishes,

   Julian

Bug#1069586: Chromium native Wayland support broken

[Andres Salomon]

Control: tags -1 forwarded https://crbug.com/329678163
Control: severity -1 serious

On 4/20/24 23:13, Stephan Verbücheln wrote:

Package: chromium
Version: 124.0.6367.60-1~deb12u1

Since the last update, Chromium does work with native Wayland. It is
starting up, but it is displaying an invisible window. It is listed in
the window switchers (Alt+Tab), Gnome Shell etc., but invisible.

Note: The default configuration uses X11 via XWayland and is working.

The setting can be managed via command line arguments or by typing
chrome://flags into the URL bar (filter for ozone).

Available settings:
default -> X11works
auto-> Wayland if available   does not work
x11   works
wayland   does not work

I have been using Chromium with native Wayland for many months without
problems until the last update.



Thanks for the heads up. Seems like this is v124-specific, and reported 
upstream at .


If they don't fix it in the stable channel, I'll backport a fix. In the 
meantime it does seem like you can get it work in wayland mode using 
command-line args, according to that bug report thread, though I haven't 
tested it myself (I'm on X11 here).




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069586: Chromium native Wayland support broken

[Stephan Verbücheln]

Workaround:

If you are stuck Chromium using native Wayland support, you can reset
it with the following steps:

1. Log out GNOME on Wayland session and log in with Gnome on Xorg
session.
2. Launch Chromium.
3. Enter chrome://flags into URL bar and reset the setting “Preferred
Ozone platform” to “Default”.
4. Log out and log in again with Wayland session.

Regards
Stephan

Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?

[Xiyue Deng]

Sean Whitton  writes:

> Hello,
>
> On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote:
>
>> Sean Whitton  writes:
>>
>>> Hello,
>>>
>>> Rob, can you review the implementation in d/rules for Xiyue's patch to
>>> this bug, please?  I'm not sure it's the straightforward way to do it.
>>>
>>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2),
>>> for the relationships.
>>
>> Ah indeed, I should update the versions after the Emacs 29.3 upload,
>> though I think you meant "1:29.3+1-2".  Also, as we are just moving
>> files from emacs-common to emacs-pgtk, breaks/replaces is only needed
>> from emacs-pgtk to emacs-common but no the other way around, so I
>> dropped the breaks on emacs-pgtk from emacs-common.
>>
>> I have updated the patch accordingly and attached here.  PTAL.
>
> Thanks.
>
>> (BTW, I'm always curious about the "+1" part of the version number.  I
>> would expect something like "+dfsg" or "+ds" as we are dropping some
>> of the non-DFSG conformant files, but why "+1"? :)
>
> It's just in case the DFSG split is done incorrectly and another attempt
> is required -- given how complex it is.

Ack, totally understandable.

With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it
and bumped the breaks/replaces version.  PTAL.

-- 
Xiyue Deng

>From c0a4ee1d76f2206594ce9897b651bbdd22baf716 Mon Sep 17 00:00:00 2001
From: Xiyue Deng 
Date: Wed, 13 Mar 2024 10:22:46 -0700
Subject: [PATCH] Install GSettings schema in pgtk build only (Closes:
 #1050393)

* In PGTK build it generates the GSettings schema file
"/usr/share/glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml" which
is not needed in other variant.
* Move the file from emacs-common to emacs-pgtk, and adds proper
breaks/replaces to ensure a smooth upgrade.
---
 debian/changelog |  7 +++
 debian/control   | 11 +--
 debian/rules |  9 -
 3 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 5d4e9f050ae..e2a31a36fcb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+emacs (1:29.3+1-3) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Install GSettings schema in pgtk build only (Closes: #1050393)
+
+ -- Xiyue Deng   Wed, 13 Mar 2024 10:22:10 -0700
+
 emacs (1:29.3+1-2) unstable; urgency=medium
 
   * Change native-comp-async-report-warnings-errors to `silent'.
diff --git a/debian/control b/debian/control
index e168717089f..3c04652c769 100644
--- a/debian/control
+++ b/debian/control
@@ -138,8 +138,15 @@ Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader
 Recommends: fonts-noto-color-emoji
 Suggests: emacs-common-non-dfsg
 Conflicts: emacs-gtk, emacs-lucid, emacs-nox
-Replaces: emacs-gtk, emacs-lucid, emacs-nox, emacs-bin-common (<< 1:29.2)
-Breaks: emacs-bin-common (<< 1:29.2)
+Replaces:
+ emacs-gtk,
+ emacs-lucid,
+ emacs-nox,
+ emacs-bin-common (<< 1:29.2),
+ emacs-common (<< 1:29.3+1-3~),
+Breaks:
+ emacs-bin-common (<< 1:29.2),
+ emacs-common (<< 1:29.3+1-3~),
 Description: GNU Emacs editor (with GTK+ Wayland GUI support)
  GNU Emacs is the extensible self-documenting text editor.  This
  package contains a version of Emacs with a graphical user interface
diff --git a/debian/rules b/debian/rules
index 6250f60ea9b..205c45dff65 100755
--- a/debian/rules
+++ b/debian/rules
@@ -425,6 +425,9 @@ override_dh_auto_install: $(autogen_install_files)
 	  cp -a $(install_dir_pgtk)/* $(pkgdir_common)
 
 	  rm -r $(pkgdir_common)/usr/bin
+	  # PGTK builds a GSettings schema that is PGTK specific and
+	  # should not be shipped in emacs-common
+	  rm -r $(pkgdir_common)/usr/share/glib-2.0
 	  rm \
 	$(pkgdir_common)/$(libexec_dir_emacs)/hexl \
 	$(pkgdir_common)/$(libexec_dir_emacs)/emacs-*.pdmp \
@@ -548,7 +551,7 @@ override_dh_auto_install: $(autogen_install_files)
 
 ##
 # emacs-pgtk
-ifneq (,$(findstring emacs, $(shell dh_listpackages)))
+ifneq (,$(findstring emacs-pgtk, $(shell dh_listpackages)))
 	  $(call install_common_binpkg_bits,$(install_dir_pgtk),$(pkgdir_pgtk),emacs-pgtk,pgtk)
 
   # install desktop entries
@@ -557,6 +560,10 @@ override_dh_auto_install: $(autogen_install_files)
 	debian/emacs.desktop \
 	debian/emacs-term.desktop \
 	$(pkgdir_pgtk)/usr/share/applications/
+	  # install GSettings schema
+	  install -d $(pkgdir_pgtk)/usr/share/glib-2.0
+	  cp -a $(install_dir_pgtk)/usr/share/glib-2.0/* \
+	$(pkgdir_pgtk)/usr/share/glib-2.0
 endif
 
 ##
-- 
2.39.2

Bug#1069586: Chromium native Wayland support broken

[Stephan Verbücheln]

Package: chromium
Version: 124.0.6367.60-1~deb12u1

Since the last update, Chromium does work with native Wayland. It is
starting up, but it is displaying an invisible window. It is listed in
the window switchers (Alt+Tab), Gnome Shell etc., but invisible.

Note: The default configuration uses X11 via XWayland and is working.

The setting can be managed via command line arguments or by typing
chrome://flags into the URL bar (filter for ozone).

Available settings:
default -> X11works
auto-> Wayland if available   does not work
x11   works
wayland   does not work

I have been using Chromium with native Wayland for many months without
problems until the last update.

I reproduced this with a completely new browser profile.

Regards
Stephan

Bug#979617: tcplay: VeraCrypt support

[Daniel Kahn Gillmor]

Retitle: 979617 tcplay: new upstream version 3.3 (includes VeraCrypt support)

On Thu 2023-02-16 15:07:10 +0100, Johannes Truschnigg wrote:
> tc-play 3.3 seems to build fairly cleanly on bullseye from its tag/release
> tarball [0]. It'd be *really* nice to have in Debian to be able to handle
> VeraCrypt volumes.

It would be great to have this updated version of tcplay in debian.

If there's some reason to not update tcplay in debian, it would be good
to know.

The package hasn't seen any updates in debian since oldoldstable.

--dkg


signature.asc
Description: PGP signature

Bug#477166: aptitude: Does not automatically remove python-elementtree after upgrading python to 2.5

[Vincent Lefevre]

On 2008-04-21 19:13:43 -0700, Daniel Burrows wrote:
[...]
>   The autoremoval stuff is designed to be conservative in what it
> removes: it only removes packages if it can prove that nothing depends
> on them.  This sometimes results in oddities like the above, but those
> are much better than the alternative.  *Even if* a complicated algorithm
> existed to decide what should be removed (and as I noted above, I don't
> believe any such algorithm exists because the package that should be
> removed is not a function of the inputs to the dependency resolver), I
> think the grounds of simplicity and comprehensibility argue in favor of
> aptitude's current behavior.  When it misbehaves, you can understand why
> without reading an AI textbook first. :)

Since this does not apply to transitional packages, I've submitted
a new bug for the case where such packages appear in a OR dependency:

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

This now also becomes more important as deborphan has been removed
from Debian, so that one can only rely on "apt autoremove".

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

Bug#996397: closed by Luca Boccassi (Re: rpm-common: macros.* are no longer in any package provided in Debian)

[Rich]

This is a curious response.

My report was "this doesn't work any more because no package in Debian has
this," not "you should make rpm-common still have this."

You should probably remove the rpm packages from Debian entirely, at the
point where people need to install a bunch of external packages to get core
functionality to work.

- Rich

On Sat, Apr 20, 2024 at 8:33 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the rpm-common package:
>
> #996397: rpm-common: macros.* are no longer in any package provided in
> Debian
>
> It has been closed by Luca Boccassi .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Luca Boccassi <
> bl...@debian.org> by
> replying to this email.
>
>
> --
> 996397: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996397
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Luca Boccassi 
> To: 996397-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 21 Apr 2024 01:31:26 +0100
> Subject: Re: rpm-common: macros.* are no longer in any package provided in
> Debian
> Control: tags -1 wontfix
>
> On Wed, 13 Oct 2021 13:16:03 -0400 Rich Ercolani 
> wrote:
> > Package: rpm-common
> > Version: 4.16.1.2+dfsg1-3
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > When debugging why %{python_version} no longer expanded in an alien
> package,
> > I discovered that in bullseye and up, the macros.* packages (and
> their
> > associated macros) seem entirely absent.
> >
> > It seems like upstream RPM stopped including them between 4.14.2.1
> and 4.15.0.
> > The alpha changelog [1] notes:
> > - Remove script language helper macros and associated scripts
> >
> > And the commit [2] explicitly says:
> > yes this will break existing packages and force distros to deal
> > with the fallout, but we believe its for the best:
> > these macros are also best maintained by people closer to the
> languages
> > in question, as has been done with all the newer languages predating
> > perl and python. rpm-extras exists as the place for maintaining and
> > collaborating on such material.
> >
> > - Rich
> >
> > [1] - https://rpm.org/timeline.html
> > [2] -
>
> https://github.com/rpm-software-management/rpm/commit/ba85c95963f9b62f237c0442f6b5aca3e355fa83
>
> That was done intentionally upstream, the macros live in separate
> source packages such as:
>
> https://src.fedoraproject.org/rpms/python-rpm-macros
>
> --
> Kind regards,
> Luca Boccassi
>
>
>
> -- Forwarded message --
> From: Rich Ercolani 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 13 Oct 2021 13:16:03 -0400
> Subject: rpm-common: macros.* are no longer in any package provided in
> Debian
> Package: rpm-common
> Version: 4.16.1.2+dfsg1-3
> Severity: normal
>
> Dear Maintainer,
>
> When debugging why %{python_version} no longer expanded in an alien
> package,
> I discovered that in bullseye and up, the macros.* packages (and their
> associated macros) seem entirely absent.
>
> It seems like upstream RPM stopped including them between 4.14.2.1 and
> 4.15.0.
> The alpha changelog [1] notes:
> - Remove script language helper macros and associated scripts
>
> And the commit [2] explicitly says:
> yes this will break existing packages and force distros to deal
> with the fallout, but we believe its for the best:
> these macros are also best maintained by people closer to the languages
> in question, as has been done with all the newer languages predating
> perl and python. rpm-extras exists as the place for maintaining and
> collaborating on such material.
>
> - Rich
>
> [1] - https://rpm.org/timeline.html
> [2] -
> https://github.com/rpm-software-management/rpm/commit/ba85c95963f9b62f237c0442f6b5aca3e355fa83
>
> -- System Information:
> Debian Release: 11.1
>   APT prefers stable-updates
>   APT policy: (1000, 'stable-updates'), (1000, 'stable-security'), (1000,
> 'stable'), (900, 'oldstable-debug'), (900, 'testing'), (800,
> 'unstable-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
> (500, 'oldstable-proposed-updates-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC,
> TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages rpm-common depends on:
> ii  libaudit11:3.0-2
> ii  libc62.31-13+deb11u2
> ii  libdbus-1-3  1.12.20-2
> ii  librpm9  4.16.1.2+dfsg1-3
> ii  librpmio94.16.1.2+dfsg1-3
> ii  libselinux1  3.1-3
>

Bug#1069585: apt: autoremoval forgets transitional packages in a OR dependency

[Vincent Lefevre]

Package: apt
Version: 2.9.1
Severity: normal

There is the wontfix bug

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

"apt: autoremoval keeps all branches of an OR on the system even if
I don't want one".

While I can understand the reason why this is wontfix, this reason
makes no sense on transitional packages.

As an example:

qaa:~> apt autoremove -s
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 82

but policykit-1 (marked as automatically installed) could be removed:

qaa:~> aptitude remove -s policykit-1
The following packages will be REMOVED:  
  policykit-1 
0 packages upgraded, 0 newly installed, 1 to remove and 82 not upgraded.
Need to get 0 B of archives. After unpacking 34.8 kB will be freed.
Would download/install/remove packages.

I suppose that "apt autoremove" doesn't remove it because of
the OR dependency:

qaa:~> aptitude why policykit-1
i   synaptic Depends pkexec | policykit-1

(at least, this seems to be one of the reasons).

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Key "";
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Clean-Installed "false";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary 

Bug#1063501: building curl from source fails the island test

[P. J. McDermott]

Hi josch,

On 2024-04-21 at 01:26, Johannes Schauer Marin Rodrigues wrote:
> Quoting Milan Kupcevic (2024-04-21 01:03:12)
> > On 4/20/24 15:59, Johannes Schauer Marin Rodrigues wrote:  
> > > How about using the upstream git instead of the release tarball as the 
> > > base for
> > > the packaging?  
> > I would rather stick with the official release tarballs as they get signed
> > with the upstream developer's key.  
> 
> I think we just recently had a long discussion in Debian about using the
> upstream git as source for the packaging instead of the release tarball in the
> light of how the recent xz-utils attack was performed. Maybe you can convince
> upstream to sign their git commits and/or tags.

It's actually more than just commit/tag signing.  Upstream releases[1]
"RECOMMENDED" release and "BETA" versions, doesn't distinguish[2]
between them in Git tags[3], and tells users to get release versions as
tar archives[4] and only use the Git repository for developing less[5].

[1]: https://www.greenwoodsoftware.com/less/download.html
[2]: https://github.com/gwsw/less/issues/441
[3]: https://github.com/gwsw/less/tags
[4]: https://github.com/gwsw/less/issues/245#issuecomment-1012323104
[5]: https://github.com/gwsw/less/blob/5e425e2/README#L20
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/


pgpSQxAXR5WeB.pgp
Description: OpenPGP digital signature

Bug#1055190: apt: autoremove forgets a package

[Vincent Lefevre]

Control: found -1 2.9.1

On 2023-11-01 21:53:26 +0100, Vincent Lefevre wrote:
> Package: apt
> Version: 2.6.1
> Severity: normal
> 
> I've installed several -perl packages with "apt install", including
> libio-async-perl, and libtest-fatal-perl:amd64 was automatically
> installed as a dependency:
> 
> Start-Date: 2023-11-01  21:03:35
> Commandline: apt install libio-async-perl
> Install: libdevel-mat-dumper-perl:amd64 (0.46-1+b1, automatic), 
> libio-async-perl:amd64 (0.802-1), libtest-fatal-perl:amd64 (0.017-1, 
> automatic), libtest-metrics-any-perl:amd64 (0.01-2, automatic), 
> libsereal-perl:amd64 (5.003-1, automatic), libmetrics-any-perl:amd64 (0.09-1, 
> automatic), libstruct-dumb-perl:amd64 (0.14-1, automatic), 
> libtest-refcount-perl:amd64 (0.10-4, automatic), 
> libasync-mergepoint-perl:amd64 (0.04-4, automatic)
> End-Date: 2023-11-01  21:03:39
> 
> A bit later, I found that this was not needed, so that I removed the
> packages and also did a "apt autoremove --purge". Now, this command
> says:
> 
> root@qaa:~# apt autoremove --purge
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 
> but while libtest-fatal-perl:amd64 (from /var/log/apt/history.log
> above) isn't installed, libtest-fatal-perl still is:
> 
> root@qaa:~# dpkg -s libtest-fatal-perl:amd64
> dpkg-query: package 'libtest-fatal-perl' is not installed and no information 
> is available
> Use dpkg --info (= dpkg-deb --info) to examine archive files.
> 
> root@qaa:~# dpkg -s libtest-fatal-perl
> Package: libtest-fatal-perl
> Status: install ok installed
> Priority: optional
> Section: perl
> Installed-Size: 43
> Maintainer: Debian Perl Group 
> Architecture: all
> Multi-Arch: foreign
> Version: 0.017-1
> Depends: perl:any, libtry-tiny-perl

Well, this isn't really the right explanation. This is due to an
output bug in apt, which should have output "libtest-fatal-perl:all"
instead of "libtest-fatal-perl:amd64".

> So "apt autoremove" forgot it.

And I can reproduce the issue on another machine:

disset:~> apt-mark showauto | grep libtest-fatal-perl
libtest-fatal-perl

disset:~> apt autoremove -s
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 18

disset:~> aptitude why libtest-fatal-perl
i   libmastodon-client-perl Depends  libdatetime-perl  
i A libdatetime-perlDepends  libspecio-perl
i A libspecio-perl  Suggests libtest-fatal-perl

disset:~> aptitude remove -s libtest-fatal-perl
The following packages will be REMOVED:  
  libtest-fatal-perl 
0 packages upgraded, 0 newly installed, 1 to remove and 18 not upgraded.
Need to get 0 B of archives. After unpacking 44.0 kB will be freed.
Would download/install/remove packages.

So, there's only a "Suggests", and note that I do not install
"Suggests" by default.

The only place this package appears in the history is

Start-Date: 2024-01-06  02:53:49
Commandline: apt install libhtml-gumbo-perl libidn-dev libimage-exiftool-perl 
libipc-run-perl liblinux-inotify2-perl libmastodon-client-perl
Install: libdevel-mat-dumper-perl:amd64 (0.47-1, automatic), 
libclass-load-perl:amd64 (0.25-2, automatic), libsafe-isa-perl:amd64 
(1.10-1, automatic), libmastodon-client-perl:amd64 (0.017-2), 
libhash-multivalue-perl:amd64 (0.16-3, automatic), 
libimage-base-bundle-perl:amd64 (1.0.7-3.5, automatic), libio-async-perl:amd64 
(0.802-2, automatic), libtest-fatal-perl:amd64 (0.017-1, automatic), 
pkgconf:amd64 (1.8.1-1, automatic), libtest-metrics-any-perl:amd64 (0.01-2, 
automatic), libcompress-raw-lzma-perl:amd64 (2.206-2, automatic), 
libsereal-perl:amd64 (5.004-1, automatic), libio-async-ssl-perl:amd64 (0.25-1, 
automatic), libidn-dev:amd64 (1.41-1), libhtml-gumbo-perl:amd64 (0.18-3+b2), 
libimage-info-perl:amd64 (1.44-1, automatic), libimage-exiftool-perl:amd64 
(12.67+dfsg-1), libmetrics-any-perl:amd64 (0.10-1, automatic), 
libcompress-bzip2-perl:amd64 (2.28-1+b3, automatic), pkg-config:amd64 (1.8.1-1, 
automatic), libfuture-perl:amd64 (0.50-1, automatic), 
liblinux-inotify2-perl:amd64 (1:2.3-2), libstruct-dumb-perl:amd64 (0.14-1, 
automatic), pkgconf-bin:amd64 (1.8.1-1, automatic), 
libtypes-path-tiny-perl:amd64 (0.006-2, automatic), libtest-refcount-perl:amd64 
(0.10-4, automatic), libpkgconf3:amd64 (1.8.1-1, automatic), 
libasync-mergepoint-perl:amd64 (0.04-4, automatic), libhttp-thin-perl:amd64 
(0.006-2, automatic), libnet-async-http-perl:amd64 (0.49-1, automatic), 
librole-eventemitter-perl:amd64 (0.003-2, automatic), libfuture-xs-perl:amd64 
(0.12-1, automatic), libfuture-io-perl:amd64 (0.15-1, automatic)
End-Date: 2024-01-06  02:53:54

I suppose that libtest-fatal-perl was automatically installed
because 

Bug#1069267: 2.1.2-59 preinst script fails

[Lorenzo]

control: found -1 runit/2.1.2-55

Hi,

On Fri, 19 Apr 2024 00:32:51 +
Jamie Heilman  wrote:

> Package: runit
> Version: 2.1.2-59
> 
> I have a long standing installation of runit which does not use the
> runsvchdir(8) symlink flipping mechanics.  /etc/service is a normal
> directory.  This isn't some customization I did, this is simply the
> natural state of my sid host after years of following sid.

It seems you are right, I did some digging and found the following

* until 2.1.2-3 /etc/service was shipped as a directory
* 2.1.2-4 no longer ships /etc/service at all
  [I guess that /etc/service does not disappear if is not empty]
* 2.1.2-7 ships /etc/service as a symlink (no migration code to deal
  with /etc/service as directory)
 [I thought that dpkg would error if there is already a directory where
   it has to create a symlink, but evidently it does not ?]
* meanwhile the new runit-init 2.1.2-6 package has code in preinst with
  readlink that breaks when /etc/service is a directory
* 2.1.2-55 changes the logic around a test in preinstall and fails
  if /etc/service exists and is not a symlink

So if a system has runit installed since before 2016, and runit-init
package was not installed at the time, it will simply fail to upgrade to
2.1.2-59.. I didn't see it coming.

> /etc/runit/runsvdir/current does exist, and is a symlink to the
> svmanaged directory which is empty.  The preinst script that attempts
> to migrate away from this layout fails because it sets errexit (-e)
> and readlink returns non-zero.
> 
> Checking if "$servlink" != '/etc/runit/runsvdir/current' is never
> reached.
> 
> Newer installations won't have this problem, they get set up with the
> symlink nest that the runit-init stuff uses, but as it stands, older
> installs can't upgrade.
skipping releases is not supported, but a clean install for each
release is not required, and failing to install/upgrade is not ok, even
if affects only a small subset of users; not sure about the severity,
maybe it is RC.
At least the package has to be installable when /etc/service is a
directory; probably having a NEWS where is recommended to change to
a symlink would be nice

> Obviously migrating /etc/service to a symlink
> is delicate, I was able to get away with:

I have to think about this, but I see trouble, for example
> 
> T=`mktemp -d /etc/runit.`
> ln -s /etc/runit/runsvdir/current "$T/service"
> rmdir /etc/runit/runsvdir/svmanaged
[rmdir fails if svmanaged it's not empty]
> mv /etc/service /etc/runit/runsvdir/svmanaged
[ in this moment /etc/service does not exists, not sure what happens if
runsvdir perform a scan in this moment, but it can be dangerous
expecially if runit is init]
> mv -T "$T/service" /etc/service
> rmdir "$T"

also, if I remember correctly there is a setup where /etc/service is a
mountmpoint for tmpfs, not sure what happens if I move it. Overall it
seems that if do that automatically too many things can go wrong.
However the code can be used as an example in the NEWS, so thanks for
sharing and test it!

Best,
Lorenzo

> 
> but I can't say that will work flawlessly for everybody.  I use
> sysvinit and my inittab entry is:
> 
> SV:123456:respawn:/etc/runit/2
> 
> I tried the same fix on a old guest I had running systemd and it
> worked there too, FWIW.
> 

Bug#1069584: widelands-data depends on deprecated font package culmus-fancy

[Jedd Rashbrooke]

Package: widelands-data
Version: 2:1.1-4

Running sid/unstable.

widelands-data has a dependency on package "culmus-fancy"

(full dependency list is:  fonts-freefont-ttf, fonts-dejavu-core,
fonts-dejavu-extra, fonts-hosny-amiri, fonts-nakula, fonts-wqy-microhei,
culmus-fancy)

culmus-fancy package has this description:

  "Package culmus-fancy was renamed to fonts-culmus-fancy. Make sure
   you have it installed instead. You can remove this package."

Naturally, attempting to remove culmus-fancy package cascades to an
attempt to remove widelands + widelands-data packages.

cheers,
Jedd.

Bug#1067316: gnucash-docs: FTBFS: Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file:

[Vincent Lefevre]

[Not reassigning yet to openjdk-17-jre-headless, as the change
was done on purpose, but Cc-ing the OpenJDK Team.]

Hi,

Since no-one looked at this issue in a month and gnucash-docs
has now been removed from testing...

On 2024-03-20 22:03:18 +0100, Lucas Nussbaum wrote:
[...]
> > Exception in thread "main" java.lang.UnsatisfiedLinkError: 
> > /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: 
> > cannot open shared object file: No such file or directory
[...]

Indeed, on my machine

qaa:~> ldd /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so | grep 
libharfbuzz
libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 
(0x7fe984534000)

where /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
comes from openjdk-17-jre-headless, but the build log shows
that libharfbuzz0b is not installed, while being recommended by
openjdk-17-jre-headless. However, I would say that even though
libharfbuzz.so.0 is used by a particular library, this should
be a "Depends:", not a "Recommends:". In any case, I think
that gnucash-docs is not supposed to know the libfontmanager.so
internals, i.e. this cannot be a bug in gnucash-docs.

But also

qaa:~> ldd /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so | grep 
freetype
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 
(0x7f835ed1d000)

while libfreetype6 is also only recommended.

openjdk-17 (17.0.10+7-3) unstable; urgency=medium
[...]
  * Make the dependencies for libfontmanager.so and libjsound.so
recommendations in jre-headless, and dependencies in jre.
[...]
 -- Matthias Klose   Mon, 11 Mar 2024 16:08:33 +0100

which was done in commit

https://salsa.debian.org/openjdk-team/openjdk/-/commit/6f0e4b17a1ff58aaf32da9be9abcf0224c481885

But why?

A warning has been added in

https://salsa.debian.org/openjdk-team/openjdk/-/commit/8010273018af3ada65de8901735ab60bb0dd5c0e

but this is the kind of things that building systems will ignore.

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

Bug#1069094: [debian-mysql] Bug#1069094: mariadb: FTBFS on hurd-i386

[Otto Kekäläinen]

I converted this to MR at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/77

Waiting for CI to pass and for a second person to approve. Perhaps Daniel Black?

Svante: Would you like to submit the two patches upstream as well?

Bug#1069583: ITP: python-pytest-randomly -- Pytest plugin to randomly order tests and control random seed

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-pytest-randomly
  Version : 3.15.0
  Upstream Contact: Adam Johnson 
* URL : https://github.com/pytest-dev/pytest-randomly
* License : Expat
  Programming Lang: Python
  Description : Pytest plugin to randomly order tests and control random 
seed

Randomness in testing can be quite powerful to discover hidden
 flaws in the tests themselves, as well as giving a little more
 coverage to your system. By resetting the random seed to a
 repeatable number for each test, tests can create data based
 on random numbers and yet remain repeatable, for example
 factory boy's fuzzy values. This is good for ensuring that
 tests specify the data they need and that the tested system is
 not affected by any data that is filled in randomly due to not
 being specified. Planned to maintain it under DPT, and need
 sponsorship.

Bug#1069179: pandoc: use "--enable-executable-dynamic" in d/rules to reduce binary size on loong64

[Jonas Smedegaard]

Hi Dandan Zhang.

Quoting zhangdandan (2024-04-17 14:13:00)
> The pandoc is blocked from building by haskell-pandoc and 
> haskell-pandoc-lua-engine in the Debian Package Auto-Building environment.
> I have built haskell-pandoc and haskell-pandoc-lua-engine locally, and 
> then compiling pandoc for loong64 in my local ENV failed.
> 
> The error message is related to "relocation R_LARCH_B26 overflow .." 
> during static linking when built pandoc binary.
> The build error log of pandoc from my local ENV is as follows,
> ```
> [4 of 4] Linking dist-ghc/build/pandoc/pandoc
> /usr/bin/ld.bfd: 
> /usr/lib/ghc/lib/../lib/loongarch64-linux-ghc-9.4.7/rts-1.0.2/libHSrts-1.0.2_thr.a(NonMovingMark.thr_o):
>  
> relocation R_LARCH_B26 overflow 0xf62f45e4
> Dump relocate record:
> stack top        relocation name        symbol
> at 
> /usr/lib/gcc/loongarch64-linux-gnu/13/../../../loongarch64-linux-gnu/crt1.o(.text+0x0):
> ...
> 0x R_LARCH_NONE    `' + 3(0x3)
> ..
> ```
> 
> It is recommended to use "--enable-executable-dynamic" in d/rules to 
> reduce binary size on loong64.
> The parameter "--enable-executable-dynamic" means "enable dynamic 
> linking of executable files".
> Please consider the patch I attached.
> With the attached patch, the pandoc was built successfully in my local ENV.
> ```
> ..
> if grep -q '^Component:[[:space:]]*main' /CurrentlyBuilding 2>/dev/null; 
> then dh_scour -ppandoc ; fi
> dh_md5sums -ppandoc
> dh_builddeb -ppandoc
> dpkg-deb: building package 'pandoc' in '../pandoc_3.1.3+ds-2_loong64.deb'.
>   dpkg-genbuildinfo -O../pandoc_3.1.3+ds-2_loong64.buildinfo
>   dpkg-genchanges -O../pandoc_3.1.3+ds-2_loong64.changes
> ```
> 
> Your opinions are welcome.
> In addition, before the pandoc was built for loong64 in the Debian 
> Package Auto-Building environment, could I dupload the pandoc compiled 
> locally using "-enable-executable-dynamic" to the 
> debian-ports/pool-loong64 repository?
> Looking forward to your reply.

Unfortunately, Debian treat Haskell libraries as development code, and
the option --enable-executable-dynamic works only when development files
are also installed.

I have instead added loong64 to the list of low-memory architectures,
which means these options are applied:
--ghc-options="-optc--param -optcggc-min-expand=10 -O0"
Hopefully that is enough for the build for loong64 succeeds.

Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[James Addison]

Ok, that's reasonable.

Re: content-negotation: the www FAQ[1] makes me think that, at least currently,
it's not worth attempting anything more advanced than language negotiation.

Re: file suffixes: after re-reading the Sphinx code and experimenting with a
few builds: I'm convinced that the html_file_suffix setting does _not_ help.

I couldn't think of a better near-term alternative than using the cron script
to adjust the searchindex.js src attribute, similar to the HTML hrefs.  I don't
really like that, though.

And finally, re: other Sphinx-built documentation, I noticed some JavaScript
errors for the language chooser in the online HTML developers-reference[2], so
I've opened a merge request[3] related to that.  It's not directly related here,
but I'm mentioning it because the documentation projects share some
similarities.

[1] - https://www.debian.org/devel/website/desc.en.html#faq

[2] - https://www.debian.org/doc/manuals/developers-reference/

[3] - https://salsa.debian.org/debian/developers-reference/-/merge_requests/48

Bug#1069535: [debian-mysql] Bug#1069535: galera-3: FTBFS on armel: dh_auto_test: error: cd obj-arm-linux-gnueabi && make -j1 test ARGS\+=--verbose ARGS\+=-j1 ARGS=--output-on-failure returned exit cod

[Otto Kekäläinen]

Galera 25.3.37 was last release from upstream in 3.x series. I suspect
the best resolution here is to wait a bit and then just file removal
request for galera-3 in sid/trixie when we are confident there is no
MariaDB 10.1/2/3 users out there anymore.

Bug#1063501: building curl from source fails the island test

[Johannes Schauer Marin Rodrigues]

Quoting Milan Kupcevic (2024-04-21 01:03:12)
> On 4/20/24 15:59, Johannes Schauer Marin Rodrigues wrote:
> > Quoting Milan Kupcevic (2024-04-20 21:46:14)
> >> On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote: [...]
> >>> Quoting Milan Kupcevic (2024-04-20 20:50:27)
>  This package builds just fine either on or off an island. The "pre-built
>  artifacts" is actually the build support provided by the upstream for 
>  their
>  official release package. It is nice to rebuild the build support, but 
>  is not
>  required nor always desired.
> >>>
> >>> what is your reasoning to not rebuild them and to instead use the 
> >>> pre-built
> >>> artifacts from the release package?
> >>>
> >>> Would anything break?
> >>>
> >>
> >> Stunt lines injected in the building scripts would be very undesirable.
> > 
> > How about using the upstream git instead of the release tarball as the base 
> > for
> > the packaging?
> I would rather stick with the official release tarballs as they get signed
> with the upstream developer's key.

I think we just recently had a long discussion in Debian about using the
upstream git as source for the packaging instead of the release tarball in the
light of how the recent xz-utils attack was performed. Maybe you can convince
upstream to sign their git commits and/or tags.

If you think there is nothing actionable about this bug, feel free to close it.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1053183: marked as done (galera-4: FTBFS on sparc64: one of sever post-build test fail)

[Otto Kekäläinen]

This seems to be passing now with latest version:

>From 
>https://buildd.debian.org/status/fetch.php?pkg=galera-4=sparc64=26.4.18-1%7Eexp1=1713134650=0:


Running tests...
/usr/bin/ctest --force-new-ctest-process --output-on-failure
Test project /<>/obj-sparc64-linux-gnu
Start 1: gu_tests
1/7 Test #1: gu_tests .   Passed4.80 sec
Start 2: gu_tests++
2/7 Test #2: gu_tests++ ...   Passed   18.70 sec
Start 3: check_gcomm
3/7 Test #3: check_gcomm ..   Passed6.97 sec
Start 4: gcache_tests
4/7 Test #4: gcache_tests .   Passed0.69 sec
Start 5: gcs_tests
5/7 Test #5: gcs_tests    Passed   11.46 sec
Start 6: galera_check
6/7 Test #6: galera_check .   Passed   20.74 sec
Start 7: wsrep_test
7/7 Test #7: wsrep_test ...   Passed0.03 sec

100% tests passed, 0 tests failed out of 7

Bug#970043: Info received (galera-4: FTBFS on ia64: [libgalera_smm.so] Error 1)

[Otto Kekäläinen]

Status update: This exact same issue is still affecting ia64 builds
for latest Galera 26.4.18 in Debian:
https://buildd.debian.org/status/fetch.php?pkg=galera-4=ia64=26.4.18-1%7Eexp1=1713220669=0

Bug#1063501: building curl from source fails the island test

[Milan Kupcevic]

On 4/20/24 15:59, Johannes Schauer Marin Rodrigues wrote:

Quoting Milan Kupcevic (2024-04-20 21:46:14)

On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote: [...]

Quoting Milan Kupcevic (2024-04-20 20:50:27)

This package builds just fine either on or off an island. The "pre-built
artifacts" is actually the build support provided by the upstream for their
official release package. It is nice to rebuild the build support, but is not
required nor always desired.


what is your reasoning to not rebuild them and to instead use the pre-built
artifacts from the release package?

Would anything break?



Stunt lines injected in the building scripts would be very undesirable.


How about using the upstream git instead of the release tarball as the base for
the packaging?




I would rather stick with the official release tarballs as they get 
signed with the upstream developer's key.


Milan

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

Release 0.106.0-alpha.1 succesfully builds as an unofficial draft package,
embedding 30 crates (21 missing, 4 outdated, 5 ahead)
which needs to be packaged before this can officially enter Debian.
The built binary runs and seems to work from a brief test use.

Main task now is packaging remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary that I've built - then I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/safe-network/-/blob/debian/latest/debian/TODO

 - Jonas

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

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

signature.asc
Description: signature

Bug#1064293: Bug#1068938: less: diff for NMU version 590-2.1

[Milan Kupcevic]

On 4/19/24 11:31, Salvatore Bonaccorso wrote:

Control: tags 1064293 + patch
Control: tags 1064293 + pending
Control: tags 1068938 + patch
Control: tags 1068938 + pending


Dear maintainer,

I've prepared an NMU for less (versioned as 590-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

As well pushed in a separte branch on salsa, which can be merged if
accepted to unstable:

https://salsa.debian.org/debian/less/-/tree/sid-2024-security-fixes?ref_type=heads

Regards.
Salvatore



ACK.

Thank you Salvatore; much appreciated.

Milan

Bug#1008016: ITP: safe-network -- network routing and service daemon for the Safe Network

[Jonas Smedegaard]

Release 0.106.0-alpha.1 succesfully builds as an unofficial draft package,
embedding 30 crates (21 missing, 4 outdated, 5 ahead)
which needs to be packaged before this can officially enter Debian.
The built binary runs and seems to work from a brief test use.

Main task now is packaging remaining missing Rust crates.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it
yourself from source or tell (by posting to this bugreport) if you
prefer testing the binary that I've built - then I will share that.

As developer (any developer: you need not be official member of Debian!)
you can join the Debian Rust team and help package these missing crates:
https://salsa.debian.org/debian/safenet/-/blob/debian/latest/debian/TODO

 - Jonas

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

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

signature.asc
Description: signature

Bug#1069582: gnome-software: "the interface of this program will be shown in american english" is shown for all programs

[two]

Subject: gnome-software: "the interface of this program will be shown in 
american english" is shown for all programs
Package: gnome-software
X-Debbugs-Cc: t...@envs.net
Version: 46~beta-1
Severity: normal
Tags: l10n

Dear Maintainer,
open any page in gnome-software, installed or not, and see that message that 
says it will be in US english, even if the page about the program and the 
interface itself is actually shown in your language

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

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.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 gnome-software depends on:
ii  appstream1.0.2-1
ii  apt-config-icons 1.0.2-1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  gnome-software-common46~beta-1
ii  gsettings-desktop-schemas46.0-1
ii  libadwaita-1-0   1.5~beta-1
ii  libappstream51.0.2-1
ii  libc62.37-15
ii  libfwupd21.9.14-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0 2.78.4-1
ii  libgtk-4-1   4.12.5+ds-3
ii  libgtk3-perl 0.038-3
ii  libgudev-1.0-0   238-3
ii  libjson-glib-1.0-0   1.8.0-2
ii  libmalcontent-0-00.11.1-1+b2
ii  libpackagekit-glib2-18   1.2.8-2
ii  libpango-1.0-0   1.52.0+ds-1
ii  libpolkit-gobject-1-0124-1
ii  libsoup-3.0-03.4.4-5
ii  libxmlb2 0.3.15-1
ii  packagekit   1.2.8-2
ii  software-properties-gtk  0.99.30-4

Versions of packages gnome-software recommends:
ii  fwupd  1.9.14-1

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
ii  gnome-software-plugin-flatpak  46~beta-1
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#1069581: pymongo: CVE-2024-21506 out-of-bound read

[Markus Koschany]

Package: pymongo
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for pymongo.

CVE-2024-21506[0]:
| Versions of the package pymongo before 4.6.3 are vulnerable to Out-
| of-bounds Read in the bson module. Using the crafted payload the
| attacker could force the parser to deserialize unmanaged memory. The
| parser tries to interpret bytes next to buffer and throws an
| exception with string. If the following bytes are not printable
| UTF-8 the parser throws an exception with a single byte.


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Regards,

Markus


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

Bug#1069580: mailman3-web: post-installation script fails with `django.core.exceptions.ImproperlyConfigured'

[Laura Orvokki Kursula]

Package: mailman3-web
Version: 0+20200530-2
Severity: important

Dear Maintainer,


I tried to install mailman3-full on my server, but the post-installation script
keeps failing. Please find below the error message.

The error message mentions database configuration, but it occurs whether I
choose postgresql or sqlite during mailman3 installation.

Reading package lists...
Building dependency tree...
Reading state information...
mailman3-web is already the newest version (0+20200530-2).
The following packages were automatically installed and are no longer required:
  libbloom1 libc-ares2 libcork16 libcorkipset1 libev4 libjsonparser1.1
  libmbedcrypto3 python3-mailman-hyperkitty
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Setting up mailman3-web (0+20200530-2) ...
dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf
dbconfig-common: flushing administrative password
Traceback (most recent call last):
  File "/usr/bin/django-admin", line 5, in 
management.execute_from_command_line()
  File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 381, in execute_from_command_line
utility.execute()
  File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 375, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
323, in run_from_argv
self.execute(*args, **cmd_options)
  File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
364, in execute
output = self.handle(*args, **options)
  File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
83, in wrapped
res = handle_func(*args, **kwargs)
  File 
"/usr/lib/python3/dist-packages/django/core/management/commands/migrate.py", 
line 87, in handle
executor = MigrationExecutor(connection, self.migration_progress_callback)
  File "/usr/lib/python3/dist-packages/django/db/migrations/executor.py", line 
18, in __init__
self.loader = MigrationLoader(self.connection)
  File "/usr/lib/python3/dist-packages/django/db/migrations/loader.py", line 
49, in __init__
self.build_graph()
  File "/usr/lib/python3/dist-packages/django/db/migrations/loader.py", line 
212, in build_graph
self.applied_migrations = recorder.applied_migrations()
  File "/usr/lib/python3/dist-packages/django/db/migrations/recorder.py", line 
73, in applied_migrations
if self.has_table():
  File "/usr/lib/python3/dist-packages/django/db/migrations/recorder.py", line 
56, in has_table
return self.Migration._meta.db_table in 
self.connection.introspection.table_names(self.connection.cursor())
  File "/usr/lib/python3/dist-packages/django/db/backends/base/base.py", line 
256, in cursor
return self._cursor()
  File "/usr/lib/python3/dist-packages/django/db/backends/dummy/base.py", line 
20, in complain
raise ImproperlyConfigured("settings.DATABASES is improperly configured. "
django.core.exceptions.ImproperlyConfigured: settings.DATABASES is improperly 
configured. Please supply the ENGINE value. Check settings documentation for 
more details.
dpkg: error processing package mailman3-web (--configure):
 installed mailman3-web package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 mailman3-web
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

Kernel: Linux 5.10.0-28-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=ANSI_X3.4-1968) (ignored: 
LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.19
ii  debconf [debconf-2.0]  1.5.77
ii  init-system-helpers1.60
ii  lsb-base   11.1.0
ii  python33.9.2-3
ii  python3-django-hyperkitty  1.3.4-4
ii  python3-django-postorius   1.3.4-2+deb11u1
ii  python3-psycopg2   2.8.6-2
ii  python3-whoosh 2.7.4+git6-g9134ad92-5
ii  ucf3.0043
ii  uwsgi-core 2.0.19.1-7.1
ii  uwsgi-plugin-python3   2.0.19.1-7.1

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.59-1~deb11u1

Versions of packages mailman3-web suggests:
ii  postgresql  13+225+deb11u1

-- debconf information:
  mailman3-web/mysql/app-pass: (password omitted)
  mailman3-web/mysql/admin-pass: (password omitted)
  mailman3-web/password-confirm: (password omitted)
  mailman3-web/superuser-password: (password 

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Viðarr]

Hey folks,

just to chime in. I had been using the commercial driver from Paragon 
without issues _before_. I switched some of my machines to Manjaro and 
and kernel 6.6. So I "had" to switch to ntfs3, given their commercial 
driver won't build against the 6.6 kernel.


Boy, was I surprised to find that the ntfs3 driver corrupted a partition 
(see forum thread here: 
https://forum.manjaro.org/t/re-ntfs3-keeps-corrupting-my-ntfs-partitons/157736). 
Nothing that their _commercial_ chkntfs wasn't able to repair (the 
userland tools work, but their commercial driver lags behind in terms of 
linking to the latest kernels), but that's: DATA CORRUPTION.


Performance in terms of speed is nice to have, but data integrity is a 
more important performance feature for a file system; at least in my book.


So, my confidence in the ntfs3 driver has been shattered for now, I have 
to admit. I had in the past used the commercial Paragon driver on some 
of my machines, but ntfs-3g where ever I didn't have a license. So I 
have worked with both before. The better tool support from Paragon and 
the performance improvement were the main selling points to me, compared 
to ntfs-3g. I never encountered data corruption with the commercial 
driver or ntfs-3g.


But the ntfs3 driver evidently has such issues. And while those quoted 
threads are old, I think there is more recent evidence that there are 
issues ...


Citing the stability of their commercial driver makes no sense, by the 
way. They don't share the same lineage. Their Linux driver is - 
according to them - a rewrite, whereas the commercial one traces its 
roots to NTFS for DOS.


In light of my experiences with ntfs3, I can understand Salvatore's 
skepticism towards that driver.


Just my two cents,

Viðarr

PS: the only thing that can be said in favor of enabling the driver 
would be that it enables a larger user base to test it and weed out 
issues. But I wouldn't call its current state stable or robust, given my 
experiences and those that turned up in web searches once I started to 
look for solutions.

Bug#1069579: ITP: python-neapolitan -- quick CRUD views for Django

[Michael Fladischer]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-neapolitan
  Version : 24.2
  Upstream Contact: Carlton Gibson 
* URL : https://github.com/carltongibson/neapolitan
* License : Expat
  Programming Lang: Python
  Description : quick CRUD views for Django

 Neapolitan's CRUDView provides the standard list, detail, create, edit, and
 delete views for a model, as well as the hooks you need to be able to customise
 any part of that.
 .
 Neapolitan provides base templates and re-usable template tags to make getting
 your model on the page as easy as possible.

I intend to maintain this as part of DPT.

-BEGIN PGP SIGNATURE-

iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmYkLOEbHGZsYWRpc2No
ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqtrwH/2RP6jnghxqGbfmLLhDX
JyGdJ2zMMIEGNJraIIFJvjVe0vwhdw17ssISPFnElKQlUZTIWqrZx5lK/ZGgeyP5
0+XP+fUKprjgYDlGJecUKqIJ0ji2vW3CnZTwqQrBSKChNWhZtsodlmSHPM5NjeVm
3c69misODIwhIFsl1tOlY7qOPoU216eX0aGOSu5yJglcQLYqf0zChrPNZ9wWH+KE
mtGbTtl6LK8DnpE6IOHQhZ9URt8oCR1hH/qadPUlgeY69uCsI8f45+pklsaOsQsR
gVB+yANdZddMW4Zwj+NyB7r76sRDKF18GEbyS5esrdalWBBXpnpjYYVrXW0SS6oe
uM8=
=ez94
-END PGP SIGNATURE-

Bug#1069343: ITP: uart-devices -- Python library for managing UART devices on Linux

[Edward Betts]

Jonas Smedegaard  wrote:
> If, as the above indicates, this is a Python _library_, then please
> avoid occupying the global namespace "uart-devices" but instead also as
> source package (not only binary package) use a python-specific prefix.
> 
> Concretely, I suggest to use "python-uart-devices" as name for the
> source package, since that leaves room for the same source package
> providing binary packages for both current major version 3 of Python,
> and also other major versions and e.g. versions of pypy.

Makes sense, I'm happy to make this change.
-- 
Edward

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

[Vincent Lefevre]

On 2024-04-20 19:40:16 +0100, Richard Lewis wrote:
> fwiw my understanding is that release-notes should be used less often, than
> NEWS.Debian because
> - it only covers stable-to-stable upgrades (i doubt many unstable users
> read it at all - certainly at the moment i don't think there is any single
> post-bookworm content)
> - release-notes will only be ready once, on stable upgrades, whereas
> NEWS.Debian might be more useful for people tracking unstable (personally i
> would hope everything in release-notes is covered in NEWS.Debian for that
> reason!)
> - release-notes is meant to be understandable by less experienced
> non-technical "users" (all documentation should of course aim for that, in
> theory)
> - NEWS.Debian is "opt-in": if you install apt-listchanges you'll see
> NEWS.Debian, but that package isnt installed by the default. Even fewer
> users will read the changelog (although apt-listchanges can email that as
> well)

As a user of both Debian/stable and Debian/unstable machines,
I have apt-listchanges installed on all machines, but this is
most useful for Debian/unstable (I also have a quick look at
the changelog). I don't remember about the release notes with
stable upgrades.

BTW, during the package upgrade, if there are /etc/profile.d files
that were sourced but that will no longer be, I think that the user
should specifically be warned about them.

I'm also wondering whether some message should be output on the
standard error if there are *.sh files that do not satisfy the
regexp (but run-parts cannot do that).

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

Bug#1069554: [Pkg-pascal-devel] Bug#1069554: winff: FTBFS on armel: build-dependency not installable: libreoffice-draw-nogui

[Paul Gevers]

Hi,

On 20-04-2024 3:22 p.m., Lucas Nussbaum wrote:

The following packages have unmet dependencies:
  sbuild-build-depends-main-dummy : Depends: libreoffice-draw-nogui but it is 
not installable
E: Unable to correct problems, you have held broken packages.
apt-get failed.


I recall rene mentioning that parts of lo are expected to not work on 
armel due to java being broken. Probably the best way forward is to 
request binary removal on armel.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1069433: gtg-trace: FTBFS on armhf: tests fail

[Samuel Thibault]

Control: reassign -1 openmpi
Control: affects -1 gtg-trace

Hello,

Lucas Nussbaum, le sam. 20 avril 2024 14:52:03 +0200, a ecrit:
> > --
> > Sorry!  You were supposed to get help about:
> > pmix_init:startup:internal-failure
> > But I couldn't open the help file:
> > /usr/share/pmix/help-pmix-runtime.txt: No such file or directory.  
> > Sorry!
> > --
> > [ip-10-84-234-251:1132190] PMIX ERROR: NOT-FOUND in file 
> > ../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c 
> > at line 237
> > running testEvent_parall 1
> > --

This happens on i386 too, but also with the following trivial testcase
on armhf and i386:

$ cat test.c
#include 
#include 
int main(int argc, char *argv[]) {
int size, rank;
MPI_Init(, );
MPI_Comm_size(MPI_COMM_WORLD, );
MPI_Comm_rank(MPI_COMM_WORLD, );
printf("%d/%d\n", rank, size);
MPI_Finalize();
return 0;
}
$ mpicc test.c -o test
$ mpirun -np 2 ./test
--
Sorry!  You were supposed to get help about:
pmix_init:startup:internal-failure
But I couldn't open the help file:
/usr/share/pmix/help-pmix-runtime.txt: No such file or directory.  Sorry!
--
[abel:25256] PMIX ERROR: NOT-FOUND in file 
../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c at 
line 237

Thus reassigning to openmpi. It seems that even if pmix is not built on
32bit archs any more, openmpi is still enabling pmix support, perhaps
that needs to be disabled?

Samuel

Bug#1069578: mir FTCBFS: runs host arch code

[Helmut Grohne]

Source: mir
Version: 2.14.1-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mir fails to cross build from source as it fails running the built
mir_wayland_generator. This is a typical problem for cmake based
projects as cmake has very little idea of what a build architecture is
or what a native executable is. mir_wayland_generator happens to be
installed into libmirwayland-bin and that's what should be used during a
cross build. I'm attaching a patch implementing this and it is
conditional to the cross build profile in order to not affect native
builds. While at it, I noticed that the noinsttest build profile FTBFS
and I think mir-wlcs-integration should also be disabled by that
profile. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru mir-2.14.1/debian/changelog mir-2.14.1/debian/changelog
--- mir-2.14.1/debian/changelog 2024-03-23 07:29:01.0 +0100
+++ mir-2.14.1/debian/changelog 2024-04-19 11:04:42.0 +0200
@@ -1,3 +1,12 @@
+mir (2.14.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Use packages mir_wayland_generator during cross
+builds. (Closes: #-1)
+  * Fix noinsttest build profile: skip package mir-wlcs-integration.
+
+ -- Helmut Grohne   Fri, 19 Apr 2024 11:04:42 +0200
+
 mir (2.14.1-5) unstable; urgency=medium
 
   [ Matthias Klose ]
diff --minimal -Nru mir-2.14.1/debian/control mir-2.14.1/debian/control
--- mir-2.14.1/debian/control   2024-02-28 21:03:56.0 +0100
+++ mir-2.14.1/debian/control   2024-04-19 11:04:42.0 +0200
@@ -27,6 +27,7 @@
libglm-dev,
libgoogle-glog-dev,
liblttng-ust-dev,
+   libmirwayland-bin ,
libxkbcommon-dev (>= 0.5),
libumockdev-dev (>= 0.6) ,
umockdev (>= 0.8.7) ,
@@ -238,6 +239,7 @@
 
 Package: mir-wlcs-integration
 Architecture: linux-any
+Build-Profiles: 
 Pre-Depends: ${misc:Pre-Depends}
 Breaks: mir-test-tools (<< 2.0.0.0+dev148~)
 Replaces: mir-test-tools (<< 2.0.0.0+dev148~)
diff --minimal -Nru mir-2.14.1/debian/patches/cross.patch 
mir-2.14.1/debian/patches/cross.patch
--- mir-2.14.1/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ mir-2.14.1/debian/patches/cross.patch   2024-04-19 11:04:42.0 
+0200
@@ -0,0 +1,43 @@
+--- mir-2.14.1.orig/cmake/MirCommon.cmake
 mir-2.14.1/cmake/MirCommon.cmake
+@@ -310,6 +310,14 @@
+   add_dependencies(${DEPENDENT_TARGET} ${TARGET_NAME})
+ endfunction()
+ 
++set(
++  MIR_WAYLAND_GENERATOR_EXECUTABLE
++  "${CMAKE_BINARY_DIR}/bin/mir_wayland_generator"
++  CACHE
++  STRING
++  "Location of an externally supplied mir_wayland_generator executable"
++)
++
+ function (mir_generate_protocol_wrapper TARGET_NAME NAME_PREFIX PROTOCOL_FILE)
+   if (NAME_PREFIX STREQUAL "")
+ set(NAME_PREFIX "@") # won't match anything
+@@ -322,9 +330,9 @@
+ OUTPUT "${OUTPUT_PATH_HEADER}" "${OUTPUT_PATH_SRC}"
+ VERBATIM
+ COMMAND "sh" "-c"
+-"${CMAKE_BINARY_DIR}/bin/mir_wayland_generator ${NAME_PREFIX} 
${PROTOCOL_PATH} header > ${OUTPUT_PATH_HEADER}"
++"${MIR_WAYLAND_GENERATOR_EXECUTABLE} ${NAME_PREFIX} ${PROTOCOL_PATH} 
header > ${OUTPUT_PATH_HEADER}"
+ COMMAND "sh" "-c"
+-"${CMAKE_BINARY_DIR}/bin/mir_wayland_generator ${NAME_PREFIX} 
${PROTOCOL_PATH} source > ${OUTPUT_PATH_SRC}"
++"${MIR_WAYLAND_GENERATOR_EXECUTABLE} ${NAME_PREFIX} ${PROTOCOL_PATH} 
source > ${OUTPUT_PATH_SRC}"
+ DEPENDS mir_wayland_generator "${PROTOCOL_PATH}"
+   )
+   target_sources("${TARGET_NAME}" PRIVATE "${OUTPUT_PATH_HEADER}" 
"${OUTPUT_PATH_SRC}")
+--- mir-2.14.1.orig/tests/acceptance-tests/wayland-generator/CMakeLists.txt
 mir-2.14.1/tests/acceptance-tests/wayland-generator/CMakeLists.txt
+@@ -5,9 +5,9 @@
+   OUTPUT "${GENERATED_HEADER}" "${GENERATED_SRC}"
+   VERBATIM
+   COMMAND "sh" "-c"
+-  "${CMAKE_BINARY_DIR}/bin/mir_wayland_generator wl_ ${PROTOCOL_PATH} header 
> ${GENERATED_HEADER}"
++  "${MIR_WAYLAND_GENERATOR_EXECUTABLE} wl_ ${PROTOCOL_PATH} header > 
${GENERATED_HEADER}"
+   COMMAND "sh" "-c"
+-  "${CMAKE_BINARY_DIR}/bin/mir_wayland_generator wl_ ${PROTOCOL_PATH} source 
> ${GENERATED_SRC}"
++  "${MIR_WAYLAND_GENERATOR_EXECUTABLE} wl_ ${PROTOCOL_PATH} source > 
${GENERATED_SRC}"
+   DEPENDS mir_wayland_generator "${PROTOCOL_PATH}"
+ )
+ add_custom_target(wayland_generator_test_generated_files ALL DEPENDS 
"${GENERATED_SRC}" "${GENERATED_HEADER}")
diff --minimal -Nru mir-2.14.1/debian/patches/series 
mir-2.14.1/debian/patches/series
--- mir-2.14.1/debian/patches/series2024-03-23 07:29:01.0 +0100
+++ mir-2.14.1/debian/patches/series2024-04-19 10:57:39.0 +0200
@@ -1,3 +1,4 @@
 1002_arch-indep-only-install-target.patch
 2002_dont-dpkg-gensymbols-by-upstream.patch
 2001_time64.patch
+cross.patch
diff --minimal -Nru mir-2.14.1/debian/rules mir-2.14.1/debian/rules
--- mir-2.14.1/debian/rules 2024-02-28 21:03:54.0 +0100
+++ 

Bug#1069551: numpy: FTBFS on armel: dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11" returned exit code 13

[Timo Röhling]

Hi Lucas,

* Lucas Nussbaum  [2024-04-20 15:21]:

Relevant part (hopefully):


self = 

@pytest.mark.skipif(IS_WASM, reason="fp errors don't work in wasm")
@pytest.mark.skipif(arm_softfloat,
reason='platform/cpu issue with FPU (gh-413,-15562)')
def test_invalid(self):


This test is supposed to be skipped on armel, as arm_softfloat is 
initialized with


hosttype = sysconfig.get_config_var('HOST_GNU_TYPE')
arm_softfloat = False if hosttype is None else hosttype.endswith('gnueabi')

Can you help me figure out why this did not work with your rebuild? 
Judging from the configuration output,



libdir   : lib/arm-linux-gnueabi


I would have expected that arm_softfloat is True. Maybe 
sysconfig.get_config_var('HOST_GNU_TYPE') returns None?



Cheers
Timo

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


signature.asc
Description: PGP signature

Bug#1069577: squeekboard: Please package 1.38.0

[Jeremy Bícha]

Source: squeekboard
Version: 1.24.0-1
Severity: wishlist
Control: affects -1 phosh-core

Please package squeekboard 1.38.0. The phosh-core metapackage version
38 (in experimental) has Depends: squeekboard (>= 1.38.0) |
phosh-osk-stub (>= 0.38.0)

https://gitlab.gnome.org/World/Phosh/squeekboard/-/releases/v1.38.0

Thank you,
Jeremy Bícha

Bug#1063501: building curl from source fails the island test

[Johannes Schauer Marin Rodrigues]

Quoting Milan Kupcevic (2024-04-20 21:46:14)
> On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote: [...]
> > Quoting Milan Kupcevic (2024-04-20 20:50:27)
> >> This package builds just fine either on or off an island. The "pre-built
> >> artifacts" is actually the build support provided by the upstream for their
> >> official release package. It is nice to rebuild the build support, but is 
> >> not
> >> required nor always desired.
> > 
> > what is your reasoning to not rebuild them and to instead use the pre-built
> > artifacts from the release package?
> > 
> > Would anything break?
> > 
> 
> Stunt lines injected in the building scripts would be very undesirable.

How about using the upstream git instead of the release tarball as the base for
the packaging?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1004863: Bootstrapping a Fedora produces a system with an empty package database

[Luca Boccassi]

On Mon, 15 Apr 2024 at 10:34, Peter Pentchev  wrote:
>
> On Sun, Apr 14, 2024 at 07:39:54PM +0100, Luca Boccassi wrote:
> > > Le 2/13/22 à 09:00, Mihai Moldovan a écrit :
> > >
> > > > I'm pretty sure that we can, at some point in the future, drop the
> > > offending
> > > > patch from the RPM package and all of this will be redundant. It
> > > just requires a
> > > > bit of work to make sure that older use cases (mostly alien) don't
> > > break due to
> > > > this, which might require a bit of development on RPM itself. It's
> > > on my TODO
> > > > list for very rainy and boring days, but unfortunately there's
> > > almost always a
> > > > truckload of other things to do, so I keep dragging it out.
> > > >
> > > >
> > > >
> > > > Mihai
> > > >
> > >
> > > I fully agree on removing the RPM patch that causes all of our issues
> > > on packages depending on it. If needed, I'm willing to be part of
> > > reviewing what would be the impact of returning to a standard RPM
> > > package on Debian and to help into solving those issues. Don't
> > > hesitate to ping me for that.
> >
> > I think the time has come to drop the RPM Debian-specific patches and
> > avoid these workarounds altogether.
> >
> > Once upon a time it made sense to redirect the RPM DB, and to go out of
> > our way to stop users installing RPMs locally, when RPMs were popular
> > as a way to distribute upstream applications.
> >
> > Nowadays, the most common way to distribute upstream apps is via
> > Flatpak/Appimage/etc, or (thanks to Ubuntu's popularity) via deb
> > repositories, so the chances someone tries to 'sudo rpm -i foo.rpm' are
> > very low.
> >
> > The main use of having rpm/dnf/zypper in Debian is not to convert RPMs
> > with Alien or so, but it's to be able to do cross-distribution
> > bootstraps and image building using native tools, like we do in mkosi
> > (and in other tools as well).
> >
> > So these patches to print warnings and divert the database and so on
> > are a hindrance.
> >
> > Hence, for Trixie I think we should just drop them all.
> >
> > It should also make it easier to maintain the RPM stack, which has
> > languished. We are trying to move everything under the RPM Team Salsa
> > org, which should also help.
> >
> > If there are any objections please speak up.
>
> I've thought about making this change at least once a year, but
> I have always been, hm, should I say "too careful" (when of course
> I actually mean "too scared")... so if you feel the time has come,
> yeah, go ahead!
>
> G'luck,
> Peter

If there are no objections, I will do this next weekend.

Bug#1063501: building curl from source fails the island test

[Milan Kupcevic]

Hi Josch,

On 4/20/24 15:05, Johannes Schauer Marin Rodrigues wrote:
[...]

Quoting Milan Kupcevic (2024-04-20 20:50:27)

This package builds just fine either on or off an island. The "pre-built
artifacts" is actually the build support provided by the upstream for their
official release package. It is nice to rebuild the build support, but is not
required nor always desired.


what is your reasoning to not rebuild them and to instead use the pre-built
artifacts from the release package?

Would anything break?




Stunt lines injected in the building scripts would be very undesirable.

Milan

Bug#1069576: blhc: False positive NONVERBOSE BUILD in src:fim

[Rafael Laboissière]

Package: blhc
Version: 0.14-1
Severity: normal
Tags: patch

Dear Maintainer,

blhc triggers a NONVERBOSE BUILD error in src:fim

https://salsa.debian.org/debian/fim/-/jobs/5618524

  [snip]
  $ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS} 
${WORKING_DIR}/*.build || [ $? -eq 1 ]
  338:NONVERBOSE BUILD: CXX  : g++
  [snip]

blhc is complaining about the output of the upstream configure script, 
which indicates to the user which C++ compiler will be used.

The patch attached to this bug report fixes the problem for me. 
Hopefully, it will not introduce false negatives.

Best regards,

Rafael Laboissi
--- blhc	2024-04-20 15:10:28.965108347 -0300
+++ blhc-new	2024-04-20 15:10:38.509055996 -0300
@@ -554,7 +554,7 @@
 }
 
 if (not (index($line, 'checking if you want to see long compiling messages... no') == 0
-or $line =~ /^\s*\[?(?:CC|CCLD|C\+\+|CXX|CXXLD|LD|LINK)\]?\s+(.+?)$/
+or $line =~ /^\s*\[?(?:CC|CCLD|C\+\+|CXX|CXXLD|LD|LINK)\]?\s+([^:]+?)$/
 or $line =~ /^\s*[][\/0-9 ]*[Cc]ompiling\s+(.+?)(?:\.\.\.)?$/
 or $line =~ /^\s*[Bb]uilding (?:program|shared library)\s+(.+?)$/
 or $line =~ /^\s*\[[\d ]+%\] Building (?:C|CXX) object (.+?)$/)) {

Bug#1068174: Debian FPGA toolchain update and testing (Was: Bug#1068174: yosys: Please package the latest upstream release)

[J . Neuschäfer]

On Sat, Apr 20, 2024 at 04:15:08PM +0200, Daniel Gröber wrote:
[...]
> Are you open to doing some testing for the new package version once I get
> around to putting it together? I can do end-to-end testing on ICE40(HX) and
> (probably) GW1N (if I can figure out how to flash this thing) maybe
> @Jonathan (in CC) can cover ECP5 and you could do ICE40UP and GateMate?

Count me in!

> I've been meaning to look into what we could use for testing beyond simple
> blinkies. Perhaps some CPU? I'd like to have something that can run
> internal consistency checks. If anyone has any ideas let me know.

That's a good question.

If you find a good answer, let me know, and it's probably a good idea to
write it down as a recommendation somewhere, so it doesn't get lost in time.

https://github.com/olofk/corescore might be an interesting option, but I
haven't looked at it in depth.


-jn


signature.asc
Description: PGP signature

Bug#1063501: building curl from source fails the island test

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Milan Kupcevic (2024-04-20 20:50:27)
> This package builds just fine either on or off an island. The "pre-built
> artifacts" is actually the build support provided by the upstream for their
> official release package. It is nice to rebuild the build support, but is not
> required nor always desired.

what is your reasoning to not rebuild them and to instead use the pre-built
artifacts from the release package?

Would anything break?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1065643: debian-policy: Refer to «dpkg-buildtree clean» for dpkg generated files

[Guillem Jover]

Hi!

On Thu, 2024-03-28 at 09:58:29 +0800, Sean Whitton wrote:
> On Thu 07 Mar 2024 at 11:22pm +01, Guillem Jover wrote:
> > diff --git a/policy/ch-source.rst b/policy/ch-source.rst
> > index 4307e89..2fb05cd 100644
> > --- a/policy/ch-source.rst
> > +++ b/policy/ch-source.rst
> > @@ -685,7 +685,7 @@ variables are also available.
> >
> >  The ``debian/substvars`` file is usually generated and modified
> >  dynamically by ``debian/rules`` targets, in which case it must be
> > -removed by the ``clean`` target.
> > +removed by the ``clean`` target (for example with ``dpkg-buildtree 
> > clean``).
> >
> >  See :manpage:`deb-substvars(5)` for full details about source variable
> >  substitutions, including the format of ``debian/substvars``.
> > @@ -725,8 +725,9 @@ building packages to record which files are being 
> > generated.
> >
> >  It should not exist in a shipped source package, and so it (and any
> >  backup files or temporary files such as ``files.new``)  [#]_ should be
> > -removed by the ``clean`` target. It may also be wise to ensure a fresh
> > -start by emptying or removing it at the start of the ``binary`` target.
> > +removed by the ``clean`` target (for example with ``dpkg-buildtree 
> > clean``).
> > +It may also be wise to ensure a fresh start by emptying or removing it at 
> > the
> > +start of the ``binary`` target.
> >
> >  When ``dpkg-gencontrol`` is run for a binary package, it adds an entry
> >  to ``debian/files`` for the ``.deb`` file that will be created when
> 
> Instead of "It may also be wise ..." can you use one of the sets of
> magic words from Policy 1.1, please?

This text was already part of policy and the proposed patch did not
really touch it, except for wrapping it into a new line. I think
modifying it feels a bit out-of-scope for this request? But if you
think it's relevant, and the sentence should be improved as part of
this, then I'll try to provide some wording. :)

Thanks,
Guillem

Bug#1068255: dnf: dnf aborts with ImportError: cannot import name '_module' from partially initialized module 'libdnf'

[Luca Boccassi]

Control: reassign -1 dh-python 6.20240401
Control: retitle -1 dh-python: dh_python3 loses cpython module name when 
renaming shared object

On Tue, 2 Apr 2024 22:47:12 +0300 Michael Ivanov 
wrote:
> Package: dnf
> Version: 4.14.0-4.1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I have just tried to start up dnf and it aborts with a following
error:
> 
> Traceback (most recent call last):
> File "/usr/bin/dnf", line 61, in 
> from dnf.cli import main
> File "/usr/lib/python3/dist-packages/dnf/__init__.py", line 30, in

> import dnf.base
> File "/usr/lib/python3/dist-packages/dnf/base.py", line 29, in

> import libdnf.transaction
> File "/usr/lib/python3/dist-packages/libdnf/__init__.py", line 13, in
> 
> from . import module
> File "/usr/lib/python3/dist-packages/libdnf/module.py", line 10, in

> from . import _module
> ImportError: cannot import name '_module' from partially initialized
module
> 'libdnf' (most likely due to a circular import)
(/usr/lib/python3/dist-
> packages/libdnf/__init__.py)
> 
> Python version is 3.11.8 (python package version is 3.11.8-3+b2)

This is caused by dh_python3. A regression was introduced at some
point, and when renaming the cpython shared object dh_python3 loses the
name, and _module.so is renamed to _.cpython-311-x86_64-linux-gnu.so
when libdnf is built, breaking the import at runtime:

I: dh_python3 fs:418: renaming _module.so to _.cpython-311-x86_64-linux-gnu.so

https://buildd.debian.org/status/fetch.php?pkg=libdnf=amd64=0.73.1-1=1713175615=0

Renaming the shared library manually to the expected filename makes dnf
work again.

Reassigning to dh-python. A binnmu of libdnf (and any other affected
package) will be needed once resolved and uploaded.

-- 
Kind regards,
Luca Boccassi


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

Bug#1063501: building curl from source fails the island test

[Milan Kupcevic]

Hi Josch,

This package builds just fine either on or off an island. The "pre-built 
artifacts" is actually the build support provided by the upstream for 
their official release package. It is nice to rebuild the build support, 
but is not required nor always desired.


Milan


On 2/8/24 18:24, Johannes Schauer Marin Rodrigues wrote:

Source: less
Version: 590-2
Severity: serious
Tags: patch

Hi,

the current curl packaging uses pre-built artifacts from the upstream
tarball without regenerating them. Attempting to regenerate them by
running "make -f Makefile.aut" proceeds to call curl to download stuff
from ftp://ftp.unicode.org. To fix this, I added a build dependency on
unicode-data and symlinked the relevant files in the source tree to the
files shipped by the unicode-data package. While I was at it, my patch
also regenerates all the other files which were so far just copypasted
from the upstream tarball without verifying whether they can really be
built using Debian main. This is the patch:

diff -Nru less-590/debian/control less-590/debian/control
--- less-590/debian/control 2023-03-12 15:49:03.0 +0100
+++ less-590/debian/control 2024-02-08 23:12:54.0 +0100
@@ -4,7 +4,8 @@
  Maintainer: Milan Kupcevic 
  Build-Depends:
   debhelper (>= 12),
- libncurses-dev
+ libncurses-dev,
+ unicode-data
  Standards-Version: 4.6.2
  Vcs-Git: https://salsa.debian.org/debian/less.git
  Vcs-Browser: https://salsa.debian.org/debian/less
diff -Nru less-590/debian/rules less-590/debian/rules
--- less-590/debian/rules   2023-02-12 11:17:35.0 +0100
+++ less-590/debian/rules   2024-02-08 23:16:58.0 +0100
@@ -12,3 +12,20 @@
dh_auto_configure -- \
  --with-regex=gnu \
  --with-editor=/usr/bin/editor
+
+execute_before_dh_auto_build:
+   mkdir -p unicode
+   ln -s /usr/share/unicode/UnicodeData.txt unicode/UnicodeData.txt
+   ln -s /usr/share/unicode/EastAsianWidth.txt unicode/EastAsianWidth.txt
+   make -f Makefile.aut
+
+execute_before_dh_auto_clean:
+   set -e; for t in "" echo key; do mv "less$$t.nro" "less$$t.bak"; done
+   make -f Makefile.aut clean
+   rm -f *.nro *.man help.c funcs.h defines.h.in configure
+   rm -f unicode/UnicodeData.txt unicode/EastAsianWidth.txt
+   [ ! -d unicode ] || rmdir unicode
+   set -e; for t in "" echo key; do mv "less$$t.bak" "less$$t.nro"; touch 
"less$$t.nro.VER" "less$$t.nro"; done
+
+execute_before_dh_auto_install:
+   make -f Makefile.aut distfiles


The stunt with preserving the *.nro files is necessary because the upstream
tarball does not ship the *.nro.VER files which are then made into *.nro files
by replacing @@VERSION@@ and @@DATE@@ with their respective values. Technically
this is a case where the original source is missing from the Debian tarball but
this replacement is probably trivial enough to not be a DFSG violation.

The patch could be made much simpler if you were using a tarball from the
upstream git instead of the distribution tarball which is missing sources but
you probably have your reasons for doing it this way.

Thanks!

cheers, josch

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

[Richard Lewis]

On Thu, 18 Apr 2024, 23:18 Santiago Vila,  wrote:

> El 18/4/24 a las 22:17, Richard Lewis escribió:
> >>> '^[a-zA-Z0-9_][a-zA-Z0-9._-]*\.sh$'
> >>
> >> Hi. I confirm that this is appropriate for what we distribute:
> >
> > What about local scripts added by users (which this change might
> > prevent loading): perhaps a NEWS.Debian entry would suffice?
>
> Are there any guidelines about when NEWS.Debian should be used
> and when the Release Notes?
>
> (I'd like to avoid spamming the users with non-important information)
>

i may well be missing something, but I think:
-  policy is entirely silent on this (i may well be missing something here!)
-  devref has:
<
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#supplementing-changelogs-with-news-debian-files
>
which says "This is the preferred means to let the user know about
significant changes in a package." and "Only update them if you have
something particularly newsworthy that user should know about."
- release notes has very little -
https://salsa.debian.org/ddp-team/release-notes/-/blob/master/README.md
which says "The Release Notes contain important information for people
updating from the previous version of Debian, particularly for less
experienced users."

fwiw my understanding is that release-notes should be used less often, than
NEWS.Debian because
- it only covers stable-to-stable upgrades (i doubt many unstable users
read it at all - certainly at the moment i don't think there is any single
post-bookworm content)
- release-notes will only be ready once, on stable upgrades, whereas
NEWS.Debian might be more useful for people tracking unstable (personally i
would hope everything in release-notes is covered in NEWS.Debian for that
reason!)
- release-notes is meant to be understandable by less experienced
non-technical "users" (all documentation should of course aim for that, in
theory)
- NEWS.Debian is "opt-in": if you install apt-listchanges you'll see
NEWS.Debian, but that package isnt installed by the default. Even fewer
users will read the changelog (although apt-listchanges can email that as
well)

(i dont think people would take a radically different view, but i may be
mistaken!)

i think in both cases, what gets included is a matter of judgement  --- my
personal view is that this change is not quite important enough (in terms
of likely impact) for release-notes, but i would also happily help draft
text for release-notes or drop the issue entirely: i dont feel strongly
about this, i just happened to spot this bug

Bug#868095: base-files: clean up legacy conffiles

[Guillem Jover]

Hi!

On Mon, 2024-04-15 at 13:15:13 +0200, Santiago Vila wrote:
> Hi. I'm scared about removing /etc/profile by accident.
> 
> Guillem: I see that dpkg contains some helper programs to remove
> "obsolete conffiles".
> 
> Are they meant to be used for conffiles which should no longer exist,
> or also for conffiles which are no longer conffiles but should
> continue to exist?

I'm afraid they are for the former.

> The end goal is to make "dpkg -s base-files" not to show /etc/profile anymore
> on systems which were upgraded from an old Debian release (where the file
> was still a conffile). Is there a tested and fool-proof way to do that?

I don't think there is one. I guess at least right now it would require
devising, testing and adding a new action to dpkg-maintscript-helper.
But perhaps I should just focus on the conffile handling rework, with
dynamic conffile support. I've at least added an explicit entry for
this specific case to my dpkg TODO list (even though I think this was
already implicit in that planned rework).

Thanks,
Guillem

Bug#1069575: FTBFS in experimental

[Matthias Geiger]

Source: rust-async-process
Version: 1.7.0-4
Severity: important
Tags: ftbfs
X-Debbugs-Cc: jbi...@debian.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Jonas,

asnyc-process currently fail to build in experimental:

=

error[E0599]: the method `next` exists for reference ``, but 
its trait bounds were not satisfied
   --> src/lib.rs:313:33
|
313 | ().next().await;
|  method cannot be called on 
`` due to unsatisfied trait bounds
   --> /usr/src/rustc-1.70.0/library/std/src/sync/mutex.rs:175:1
|
= note: doesn't satisfy `_: Stream`
|
= note: doesn't satisfy `std::sync::Mutex: StreamExt`
|
= note: the following trait bounds were not satisfied:
`::sync::Mutex: futures_lite::Stream`
which is required by `::sync::Mutex: StreamExt`
`std::sync::Mutex: futures_lite::Stream`
which is required by `std::sync::Mutex: StreamExt`

error[E0599]: no function or associated item named `new` found for struct 
`EventListener` in the current scope
   --> src/lib.rs:513:43
|
513 | let listener = EventListener::new();
|   ^^^ function or associated item 
not found in `EventListener`

error[E0277]: the `?` operator can only be applied to values that implement 
`Try`
   --> src/lib.rs:307:30
|
307 | signals: Mutex::new(Signals::new([SIGCHLD]))?,
|   the `?` 
operator cannot be applied to type `std::sync::Mutex>`
|
= help: the trait `Try` is not implemented for 
`std::sync::Mutex>`

Some errors have detailed explanations: E0277, E0599.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `async-process` due to 3 previous errors

warning: build failed, waiting for other jobs to finish...
dh_auto_test: error: env DEB_BUILDDIR= 
/<>/debian/dh-cargo/bin/cargo test returned exit code 101
make: *** [debian/rules:9: binary-indep] Error 25

==

I didn't have time to investigate this yet. I'd appreciate it if you
coud take a look at this as it is blocking the
event-listener-transition.

best,

werdahias




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

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmYkCxcVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1EhMQAKe69jDJ2+e+DEaWDfSgVhgXW8je
WQ8U4WHhk38rIaKfZmxem3GfQZWj+WSeRCY07E2JHurgci82iCzKw3mp1hnAZeoV
DsMsKQlNQmMnrNCk+vYgb0zjv65KN9iDjcZwuCOwm7Qy8v3N6yRru8yzHs7GsJEH
tJgcUjo6lAi3MuDm0Znl35vrBvhU/oNLMUqVWb3I4Rv9/woeHllXvZtxx9Nfz7Rj
ltzkLWTFbrWS1bWBCVLS3heJ980wuS9hVb+s9YYtkcy6FZDWUUZGQZ4nNKZBwAhf
5krwZMhsMTF3h22e+61wE4wIpbCVTBsWICROTXQeQLtwiWRqknFRdHOVfX8XfWSG
VxGx60Zw076tRtzrZ3DvXJvztt3eKSK3pEv+ZtQjwDiQQDjpUUQyMafeMa6wHd8y
Xm0AhQK4zCDHwntnHjnCUVDLp9JU1DxnUCx1CE98Iarhv5p1PUyXLRC3IXqmbvbe
zbumMaKgiEkXabA1FaUJpgO5E871B1Dcod+EC8nQi5KlVGnhK8E85qY2Z/2W4wKz
1veTg1ZKKRsuaveZx6Dhn0sB0mwJVrLfgLc4kBcvtjkoFPOeA+vpPY+Rp0NAY4CJ
K5as+DJyRHSNFkj23e/dvNKYQlHAfzfYIDRI5EI/gZ71c0hzrRZSJe+5Qg95I7SP
EWU2XUhf6aFUO3Rc
=vZWi
-END PGP SIGNATURE-

Bug#1069574: age-old and insecure webkit package

[Hadmut Danisch]

Package: libqt5webkit5

Version: 5.212.0~alpha4-30


Hi,

this was originally a bug report against Ubuntu 24.04 as 2061191, but 
since the package is community maintained and not by Ubuntu, they asked 
me to report it "upstreams".



Ubuntu 24.04 beta / Debian bookworm still use libqt5webkit5.

It is not obvious, where it comes from, but the version is still an 
alpha4, and the link in the README seems to suggest, that it still comes 
from https://github.com/annulen/webkit 
, which redirects to 
https://github.com/qtwebkit/qtwebkit 
 , where the alpha4 tag is over 4 
years old.


There, the latest README tells:

Code in this repository is obsolete. If you are looking for up-to-date 
QtWebKit use this fork: https://github.com/movableink/webkit 



https://github.com/movableink/webkit 
 seems to be still maintained – 
more or less. And calls itself "inofficial mirror"


Have a look at

https://blogs.gnome.org/mcatanzaro/2022/11/04/stop-using-qtwebkit/ 



which calls qtwebkit insecure, poorly maintained, and cites CVEs about 
remote code execution (some of them would have to be fixed in the fork, 
but probably not in the version here in ubuntu).


The problem is, that tools like wkhtmltopdf do use this library and are 
typically used to pull contents from a given URL, i.e. from foreign 
websites.


Processing foreign HTML and Javascript code in conjunction with 
vulnerabilities to remote code execution, this is highly dangerous.



regards

Hadmut

Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"

[Guillem Jover]

Hi!

On Wed, 2024-04-17 at 04:24:16 +0200, Vincent Lefevre wrote:
> Package: developers-reference
> Version: 13.5
> Severity: normal

> Now that the deborphan package has been removed from unstable,
> the section "Make transition packages deborphan compliant" in
> "Best Packaging Practices" is out of date and should be updated.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312
> where "apt-mark auto ..." (for autoremove) is suggested as a
> replacement. But with it, putting transition packages to oldlibs
> is even more necessary.

While I fully support properly marking obsolete packages by putting
them in the (unfortunately misnamed :) oldlibs section (well excluding
library-like depended on packages that get dropped as a mater of course).
I wanted to note that I've received some pushback from the archive
maintainers about this being considered unnecessary churn (paraphrasing
from what ISTR). So it would be nice to clarify this with them before
creating and proposing a procedure that might end up generating social
friction.

Thanks,
Guillem

Bug#1069256: debian-policy: clarify requirement for use of Static-Built-Using

[Guillem Jover]

Hi!

On Thu, 2024-04-18 at 23:29:11 +0300, Maytham Alsudany wrote:
> Package: debian-policy
> Version: 4.7.0.0
> Severity: normal
> X-Debbugs-Cc: debian-de...@lists.debian.org

> In early 2022, Guillem added support for a new Static-Built-Using field to
> dpkg, encouraging packagers to use it over Built-Using to specify
> statically-linked dependencies [2]. The commit message states the following:
> 
>   This field mimics the previous Built-Using field semantics, but is
>   specifically intended for shadow dependencies stemming from static builds.
>   
>   In Debian, the Rust and Go teams agreed to use this language agnostic field,
>   instead of one for each of the languages. This means it can be easily
>   supported by dpkg, and can be used by other languages and run-times.
> 
> This was also added to the deb-control(5) manpage, specifically 
> differentiating
> it from Built-Using as a field to be used "for static building purposes (for
> example linking against static libraries, builds for source-centered languages
> such as Go or Rust[...])".

I think this (and the policy proposal) is omitting several important
parts for the intended use for the field, as it was considered on its
addition. Quoting from deb-control(5) for context, which I think
covers the concerns from the mails from Simon and Chris:

   Built-Using: 
   This dependency field lists extra source packages that were used
   during the build of this binary package, for license compliance
   purposes.  This is an indication to the archive maintenance
   software that these extra source packages must be kept whilst this
   binary package is maintained.  This field must be a comma-separated
   list of source package names with strict ‘=’ version relationships
   enclosed within parenthesis.  Note that the archive maintenance
   software is likely to refuse to accept an upload which declares a
   Built-Using relationship which cannot be satisfied within the
   archive.

   Static-Built-Using: 
   This dependency field lists extra source packages that were used
   during the build of this binary package, for static building
   purposes (for example linking against static libraries, builds for
   source-centered languages such as Go or Rust, usage of header-only
   C/C++ libraries, injecting data blobs into code, etc.).  This is
   useful to track whether this package might need to be rebuilt when
   source packages listed here have been updated, for example due to
   security updates.  This field must be a comma-separated list of
   source package names with strict ‘=’ version relationships enclosed
   within parenthesis.

   Supported since dpkg 1.21.3.

> The proposed change is to clarify and formally mandate the requirement to
> declare statically-linked libraries used to build packages containing binaries
> in Static-Built-Using. Attached is a draft patch of the proposed change.

Thanks for starting this!

As mentioned before I think the currently proposed description is too
restrictive and specific to Go and Rust, and it should be expanded. The
example usage seems also too specific, and might lead people to think
this is the only valid use, and their placement feels a bit odd, perhaps
these should be given as a footnote? (But this is really for the Policy
editors to decide.)

Thanks,
Guillem

Bug#1069247: libconfig-model-dpkg-perl: test failures

[Niko Tyni]

On Sat, Apr 20, 2024 at 11:09:17AM +0200, Dominique Dumont wrote:
> On Thursday, 18 April 2024 19:21:55 CEST you wrote:
> > Source: libconfig-model-dpkg-perl
> > Version: 3.004
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source
> 
> This really looks like a bug with prove:
> 
> $ perl t/reorder.t 
> ok 1 -  test re-ordered list
> 1..1

> I can't see what's wrong with the output of reorder test...

Looks like something is injecting apt progress messages to stdout with
CR characters hiding it on the terminal but obviously not from `prove`.

$ perl t/reorder.t |od -c
000  \r   R   e   a   d   i   n   g   p   a   c   k   a   g   e
020   l   i   s   t   s   .   .   .   0   %  \r  \r   R   e
040   a   d   i   n   g   p   a   c   k   a   g   e   l   i
060   s   t   s   .   .   .   1   0   0   %  \r
100
120  \r  \r   B   u   i   l
140   d   i   n   g   d   e   p   e   n   d   e   n   c   y
160   t   r   e   e   .   .   .   0   %  \r  \r   B   u   i   l
200   d   i   n   g   d   e   p   e   n   d   e   n   c   y
220   t   r   e   e   .   .   .   0   %  \r  \r   B   u   i   l
240   d   i   n   g   d   e   p   e   n   d   e   n   c   y
260   t   r   e   e   .   .   .   5   0   %  \r  \r   B   u   i
300   l   d   i   n   g   d   e   p   e   n   d   e   n   c   y
320   t   r   e   e   .   .   .   5   0   %  \r
340
360  \r  \r   R
400   e   a   d   i   n   g   s   t   a   t   e   i   n   f
420   o   r   m   a   t   i   o   n   .   .   .   0   %  \r  \r
440   R   e   a   d   i   n   g   s   t   a   t   e   i   n
460   f   o   r   m   a   t   i   o   n   .   .   .   0   %  \r
500
*
540  \r   o   k   1   -   t   e   s   t   r   e
560   -   o   r   d   e   r   e   d   l   i   s   t  \n   1   .
600   .   1  \n
603

HTH,
-- 
Niko

Bug#945203: fwupd: Cannot update firmware

[Matt Taggart]

I also ran into this "No space left on device" error, but in a different 
situation.


I knew that a particular Dell laptop I was working on had firmware 
available via fwupd, so I had the bright idea to boot Debian Live and 
install fwupd to update it.


But I realized some firmware images (maybe _all_ system BIOS images?) 
actually work by writing things into the EFI partition, to be updated 
upon reboot (like how MS Windows also does it). So my bright idea didn't 
work, since I didn't yet have a drive installed with an EFI partition. 
But due to the error being about "No space" I wasted some time trying to 
resolve that, before realizing the real issue. After I had a proper 
Debian install with EFI it worked fine.


So I think part of the issue here is that fwupd should better detect 
when it's completely missing things it needs to be successful and give 
an improved error and maybe point to documentation about how it works.


In my case it was "no EFI partition", but others in this bug report have 
alluded to things like efivars, the BIOS locking things down, etc. So 
some additional sanity checks of these things would be nice.


Thanks,

--
Matt Taggart
m...@lackof.org

Bug#1056901: network-manager-fortisslvpn: 1.4.0-1

[Bastian Germann]

Done. I haev uploaded a NMU with the referenced patch.

Bug#1068324: lintian: patch-not-forwarded-upstream for upstream patches

[Nilesh Patra]

On Sat, Apr 20, 2024 at 02:57:28PM +, Thorsten Glaser wrote:
> >Right. AFAICS, lintian spews that warning because the header in that patch in
> >incomplete. It also needs a "From" and "Subject" (which can be same as commit
> 
> this is not entirely correct.
> 
> The full patch header is:
> 
> Description: fix typeset -p confusion between empty and unset
> Origin: commit:10065BC69BE555D6721
> 
> Description is the standard name for Subject (the same way
> Author is the standard DEP 3 name for From), and it’s present,
> and when Origin indicates an upstream commit (as shown here),
> Author does not need to be present, per DEP 3.

OK, makes sense to me -- thank you!

I dived a little deeper and it seems lintian is checking
whether or not the Origin field's first value before comma is a valid value
(upstream or vendor). However, in your header, you did not specify such a field.
As per dep3, it is optional and hence lintian should not do stringent checks on
this field i.e. assuming that it will have a first paramater of "upsteam, foo"
or "backports, foo".

I've opened an MR https://salsa.debian.org/lintian/lintian/-/merge_requests/499
which is potentially fixing this, and based on local testing
this does not cause regressions, and does not spew that warning/info with your
header as well. However, the fix may still not be proper -- not a perl champ.

I'll leave the review for lintian maintainers.

> bye,
> //mirabilos
> -- 
> If Harry Potter gets a splitting headache in his scar
> when he’s near Tom Riddle (aka Voldemort),
> does Tom get pain in the arse when Harry is near him?
>   -- me, wondering why it’s not Jerry Potter………
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1069480: bochs: FTBFS on armhf: build-dependency not installable: gcc-i686-linux-gnu

[Lucas Nussbaum]

On 20/04/24 at 19:11 +0200, Stephen Kitt wrote:
> gcc-i686-linux-gnu is in Build-Depends-Indep, it’s only used to build Arch:
> all packages. Is there a requirement that these build on armhf? Given that
> armhf doesn’t have gcc-i686-linux-gnu, I’m not sure how I would go about
> fixing this, short of asking for the cross-compiler to be added to armhf
> (which doesn’t seem all that useful).

No, indeed. That could be closed, or downgraded to wishlist + wontfix as
"arch:all packages can only be built on amd64 due to missing
build-depends(-Indep) on other architectures". (I'd prefer a downgrade,
because if that bug had existed, I would have seen it and would not have
filed the bug)

Lucas

Bug#1020533: Bug#825385: Bug#1020533: dpkg should use /var/lib/dpkg/arch to determine native arch when running chrootless

[Guillem Jover]

Hi!

On Fri, 2023-06-16 at 16:29:17 +0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Guillem Jover (2022-10-10 12:23:58)
> > On Thu, 2022-09-22 at 22:13:34 +0200, Johannes Schauer Marin Rodrigues 
> > wrote:
> > As mentioned on IRC, the problem here (and on #825385) is indeed that dpkg
> > considers its own arch the native one, and when operating on a cross-arch
> > chroot, that goes wrong, both in dependency resolution and when outputting
> > arch-qualified package names for example.
> > 
> > Fixing this properly is tricky though, because there are multiple
> > requirements in tension here:
> > 
> >   * The external dpkg should be able to tell what's the arch for the
> > internal one w/o having to execute anything (that it might not be
> > able to run anyway).
> >   * Setting a file on the database means either requiring a dpkg
> > maintscript (for the bootstrap phase) which we are trying to get
> > rid of, or offloading this to the bootstrappers (even worse), it
> > also means it could be modified w/o dpkg noticing, which can break
> > dependency resolution from an existing system.
> >   * Shipping a file with the arch would seem like the best option (as
> > that is checksummed) and not in the db, but that means then, that
> > pathname under /usr needs to be selectable too at run-time, as
> > that encodes configure-time vendor-specific fsys layout.
> >   * Setting that directory from the config file is currently
> > problematic as dpkg does not have a way to specify a different
> > config directory.
> >   * Perhaps just adding a new --foodir option to dpkg could be enough
> > for now, if the inner dpkg uses a different pathname, in the
> > same way if it uses a different database pathname.
> >   * But then only specifying the db pathname would no longer be
> > enough, and dependency resolution and arch-qualifying would still
> > be wrong. :/
> >   * But then if the file does not exist (or cannot be found in the
> > «right» place) it could still fallback to the currently running
> > native arch, but that looks flaky (not worse than now, though,
> > but not ideal). :/
> > 
> > I guess I can prototype something with the --foodir idea though, but that's
> > still rather meh.
> 
> once you have a prototype (even if it's not release-ready) feel free to share
> it, because our CI setup is able to apply patches to source packages. So if 
> you
> have something that we can test, just send it over and we'll build a patched
> dpkg to run this with our scripts.

I provided a prototype patch some time ago which got integrated in
Helmut's dpkg-root-demo CI system. But I've not been entirely happy
with it though. I've been rethinking about it from a clean slate and
I went with a file in the db instead which seems way cleaner after all.
My current reasoning is:

  * Shipping a file under /usr/share means:
- The chroot has no defined native arch until dpkg is unpacked, which
  again imposes an installation ordering, which we'd rather avoid I
  think.
- It also requires to install a dpkg in the chroot! (Which is generally
  desirable but might not be in cases such as for testing purposes.)
- It requires hardcoding a filesystem pathname (worse) in addition to
  the database pathname.
- It creates a public interface.
  * It creates a potential out-of-sync situation between the admindir
and the root directory, as these can be specified separately.
  * It would require adding a new --foodir option for this new
directory.
  * If we need to pre-create the file in the chroot, I think doing
that inside the db is always preferable than creating one in the
filesystem part, because the latter is a filesystem policy
governed by the chroot distributor, and is part of the packaged
data while the location of the latter is still a policy issue,
it is something already handled by the tooling and more
independent than the packaged bits.
  * In the future pre-creating the file could be done by extending
dpkg to provide a new dpkg action to initialize a chroot db for
example, that could hide any such detail, while doing the same for
the chroot filesystem seems just wrong.

The annoying part is that this information is already present in the
Architecture field for the dpkg package, but that is also a downstream
policy decision and I'd consider it a regression to try to infer the
package name dpkg itself is being packaged as inside the chroot, not
to mention that still does not cover some of the points above anyway.

I've queued the changes and I'm planning to push them during the
weekend.

Thanks,
Guillem

Bug#1069573: libdar-dev: Some libraries listed by `pkg-config --libs libdar64` are not installed

[J. T. Elscott]

Package: libdar-dev
Version: 2.7.14-1
Severity: normal
X-Debbugs-Cc: jtelscot...@fastmail.com

Dear Maintainer,

Please forgive me if this is just a misunderstanding. Having installed libdar-
dev:
$ cat test.cpp
#include 
int main() {libdar::get_version();return 0;}
$ g++ -o test test.cpp $(pkg-config --libs --cflags libdar64)
/usr/bin/ld: cannot find -lthreadar: No such file or directory
/usr/bin/ld: cannot find -lgpgme: No such file or directory
/usr/bin/ld: cannot find -lrsync: No such file or directory
/usr/bin/ld: cannot find -lcap: No such file or directory
collect2: error: ld returned 1 exit status

As I understand it these things (for instance libthreadar-dev) should have been
automatically installed.


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

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

Versions of packages libdar-dev depends on:
ii  libargon2-dev 0~20190702+dfsg-4+b1
ii  libassuan-dev 2.5.6-1
ii  libbz2-dev1.0.8-5.1
ii  libdar64-6000t64  2.7.14-1
ii  libgcrypt20-dev   1.10.3-2
ii  libgpg-error-dev  1.47-3
ii  liblz4-dev1.9.4-2
ii  liblzma-dev   5.6.1+really5.4.5-1
ii  liblzo2-dev   2.10-2+b1
ii  libzstd-dev   1.5.5+dfsg2-2
ii  zlib1g-dev1:1.3.dfsg-3.1

libdar-dev recommends no packages.

libdar-dev suggests no packages.

-- no debconf information

Bug#1069480: bochs: FTBFS on armhf: build-dependency not installable: gcc-i686-linux-gnu

[Stephen Kitt]

Hi Lucas,

On Sat, 20 Apr 2024 14:46:39 +0200, Lucas Nussbaum  wrote:

> Source: bochs
> Version: 2.8+dfsg-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on armhf.
> 
> 
> Relevant part (hopefully):
> > +--+
> > | Install package build dependencies
> >  |
> > +--+
> > 
> > 
> > Setup apt archive
> > -
> > 
> > Merged Build-Depends: bison, debhelper-compat (= 13), flex, libaa1-dev,
> > libasound2-dev, libgtk-3-dev, libice-dev, libltdl-dev, libncurses-dev,
> > libreadline-dev, libsdl2-dev, libsm-dev, libtool, libwxgtk3.2-dev,
> > libx11-dev, libxpm-dev, libz-dev, build-essential, fakeroot,
> > acpica-tools, bcc, bin86, docbook-dsssl, gcc-i686-linux-gnu Filtered
> > Build-Depends: bison, debhelper-compat (= 13), flex, libaa1-dev,
> > libasound2-dev, libgtk-3-dev, libice-dev, libltdl-dev, libncurses-dev,
> > libreadline-dev, libsdl2-dev, libsm-dev, libtool, libwxgtk3.2-dev,
> > libx11-dev, libxpm-dev, libz-dev, build-essential, fakeroot,
> > acpica-tools, bcc, bin86, docbook-dsssl, gcc-i686-linux-gnu dpkg-deb:
> > building package 'sbuild-build-depends-main-dummy' in
> > '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1
> > copy:/<>/apt_archive ./ InRelease Get:2
> > copy:/<>/apt_archive ./ Release [609 B] Ign:3
> > copy:/<>/apt_archive ./ Release.gpg Get:4
> > copy:/<>/apt_archive ./ Sources [915 B] Get:5
> > copy:/<>/apt_archive ./ Packages [908 B] Fetched 2432 B in
> > 0s (0 B/s) Reading package lists... Reading package lists...
> > 
> > Install main build dependencies (apt-based resolver)
> > 
> > 
> > Installing build dependencies
> > Reading package lists...
> > Building dependency tree...
> > Reading state information...
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> > 
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-main-dummy : Depends: gcc-i686-linux-gnu but it is
> > not installable E: Unable to correct problems, you have held broken
> > packages. apt-get failed.  

gcc-i686-linux-gnu is in Build-Depends-Indep, it’s only used to build Arch:
all packages. Is there a requirement that these build on armhf? Given that
armhf doesn’t have gcc-i686-linux-gnu, I’m not sure how I would go about
fixing this, short of asking for the cross-compiler to be added to armhf
(which doesn’t seem all that useful).

Regards,

Stephen


pgpOdtyiQY5dR.pgp
Description: OpenPGP digital signature

Bug#1069307: FTBFS: configure: error: must specify --with-locking-method option

[Andreas Metzler]

Control: tags -1 patch

On 2024-04-19 Andrey Rakhmatullin  wrote:
> Source: courier
> Version: 1.0.16-3.2
> Severity: serious
> Tags: ftbfs

> https://buildd.debian.org/status/fetch.php?pkg=courier=armel=1.0.16-3.2%2Bb4=1712019536=0

> checking for locking method... configure: error: must specify --with-locking-
> method option
> configure: error: ./configure failed for libs/liblock
[...]

Multiple autoconf tests are thrown by
-Wno-error=implicit-function-declaration.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Description: Fixx FTBFS due to implicit declarations in autoconf tests.
Author: Andreas Metzler 
Bug-Debian: https://bugs.debian.org/1069307
Origin: vendor
Last-Update: 2024-04-20

--- a/libs/ldapaddressbook/configure.ac
+++ b/libs/ldapaddressbook/configure.ac
@@ -52,10 +52,11 @@ then
 	AC_TRY_LINK([
 #include 
 #if HAVE_LBER_H
 #include 
 #endif
+#define LDAP_DEPRECATED 1
 #include 
 ],
 [
 	LDAP *p=NULL;
 
--- a/libs/liblock/locktest.c
+++ b/libs/liblock/locktest.c
@@ -15,10 +15,13 @@
 #endif
 #include	
 #include	
 #include	
 #include	
+#include	
+#include	
+
 
 int main()
 {
 #define FILENAME	"courier-imap.locktest.XX"
 int	fd[2];
--- a/libs/tcpd/configure.ac
+++ b/libs/tcpd/configure.ac
@@ -221,10 +221,11 @@ AC_TRY_RUN(
 
 changequote(<<,>>)
 
 #include	
 #include	
+#include	
 
 int main(int argc, char **argv)
 {
 int	pipefd[2];
 char	c;
--- a/libs/waitlib/confwait.c
+++ b/libs/waitlib/confwait.c
@@ -22,10 +22,12 @@
 #include	
 
 #define	INCLUDED_FROM_CONFIGURE
 #include	"waitlib.c"
 
+#include	
+
 #define	NUMPROCS	10
 
 static int numterminated=0;
 
 

Bug#1062405: dolfin: NMU diff for 64-bit time_t transition

[Drew Parsons]

Source: dolfin
Followup-For: Bug #1062405
Control: severity 1062405 testing
Control: tags 1062405 moreinfo

This time_t patch was never applied.  Is it not needed after all? 
Can we close this bug now?

Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance

[Michael Tokarev]

On Tue, 6 Feb 2024 19:37:46 +0300 Michael Tokarev wrote:

03.02.2024 12:47, Michael Tokarev wrote:

>>> It looks like we broke suspend/resume in this version of qemu.
>> Oops. Is that related to the cryptsetup failure, or a separate issue?
> 
> Yes, it is related to cryptsetup autopkgtest failure.  It looks

> like this is the only place where suspend/resume code in qemu
> is actually being used, - it's rather rare to suspend (hybernate)
> a virtual machine, and cryptsetup performs testing of how the
> encrypted filesystem is unlocked (or not) on resume.

So, while the problematic upstream commit fixes quite a few real
potential qemu lockups, it introduces a new lockup in suspend-
resume-hibernate cycle.  The problem isn't understood yet, and
we're getting close to the 12.5 release.

The problematic upstream commit (on master) is this one:
https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7
It has links to 2 bugs it is fixing, and there are quite a few
other bugs which are fixed too.


It turned out this commit was innocent.  The bug most likely is
somewhere in qemu, but it is triggered by the guest kernel, it
looks like, not by this qemu commit.  Current bookworm kernels
(6.1.19 and 6.1.20) fails in this same suspend/resume test in
all current versions of qemu, including the ones with this
commit applied, including current qemu master, and including
versions much older than that, - including original qemu as
initially released with bookworm, before all updates.

It is not yet clear what's going on here.  But we'll have to
live with that somehow, and, - I guess - have to live with
the broken cryptsetup autopkgtests.

I'm preparing a new upstream stable/bugfix version of qemu 7.2.x
for bookworm, which will include a few CVE fixes, many other
fixes all other the place, and re-introduction of this commit
too, - which, as it turns out, has actually nothing to do with
the broken suspend-resume.

Thanks,

/mjt

Bug#1069533: sayonara: Please package new upstream version

[Ko Ko Ye`]

Thanks for the sponsor offering @Boyuan Yang .
Thank you for looking into this @s...@swm1.com 
Sounds good to me. let me check.

On Sun, Apr 21, 2024 at 2:15 AM Boyuan Yang  wrote:

> Hi,
>
> 在 2024-04-20星期六的 08:45 -0700，Steve M写道：
> > Is this not an issue that would prevent such an update for the time
> being?
> >
> >
> > This package is part of the ongoing testing transition known as
> auto-qtbase-
> > opensource-src. Please avoid uploads unrelated to this transition, they
> would
> > likely delay it and require supplementary work from the release
> managers. On the
> > other hand, if your package has problems preventing it to migrate to
> testing,
> > please fix them as soon as possible. You can probably find supplementary
> > information in the debian-release archives or in the corresponding
> > release.debian.org bug.
> >
> > This package is part of the ongoing testing transition known as
> libglib2.0-
> > 0t64. Please avoid uploads unrelated to this transition, they would
> likely delay
> > it and require supplementary work from the release managers. On the
> other hand,
> > if your package has problems preventing it to migrate to testing, please
> fix
> > them as soon as possible. You can probably find supplementary
> information in the
> > debian-release archives or in the corresponding release.debian.org bug.
>
> We can always upload to Debian Experimental first. Actually uploading to
> experimental
> sooner can help discover issues early. Once the transition is no longer a
> blocker,
> reuploading it to Unstable will be a lot more easier. If you have a
> prepared
> version, I would be happy to sponsor the upload.
>
> Thanks,
> Boyuan
>
> > On Sat, 2024-04-20 at 09:19 -0400, Boyuan Yang wrote:
> > > Source: sayonara
> > > Version: 1.8.0-beta1-1
> > > Tags: sid
> > > X-Debbugs-CC: kokoye2...@gmail.com s...@swm1.com
> > >
> > > Dear Debian sayonara package maintainers,
> > >
> > > A new upstream release of package sayonara was released in Jan 2024.
> > > Since you are listed as Debian package maintainers, please consider
> > > upgrading its Debian package. If you have any questions, please let
> > > me know.
> > >
> > > Thanks,
> > > Boyuan Yang
> >
>
>

-- 

with regards *Ko Ko Ye` *


kokoye2...@gmail.com
kokoye2...@ubuntu.com

https://www.linkedin.com/in/kokoye2007
https://ubuntu-mm.net
https://kokoye2007.github.io

Bug#1069572: firmware-nonfree: activate update-initramfs trigger declaratively

[Helmut Grohne]

Source: firmware-nonfree
Version: 20230625-2
Severity: wishlist
Tags: patch

This is the same bug as #1069571 (firmware-linux-free). The
update-initramfs trigger is activated procedurally and in postinst only.
Hence, removing a firmware package does not update the initramfs. I
propose activating the trigger declaratively to have dpkg figure out
when to activate.

Helmut
diff -Nru firmware-nonfree-20230625/debian/changelog 
firmware-nonfree-20230625/debian/changelog
--- firmware-nonfree-20230625/debian/changelog  2023-12-19 18:01:10.0 
+0100
+++ firmware-nonfree-20230625/debian/changelog  2024-04-20 18:11:28.0 
+0200
@@ -1,3 +1,10 @@
+firmware-nonfree (20230625-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Activate update-initramfs trigger declaratively. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 20 Apr 2024 18:11:28 +0200
+
 firmware-nonfree (20230625-2) unstable; urgency=medium
 
   [ Diederik de Haas ]
diff -Nru firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst 
firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst
--- firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst 
2023-12-19 18:01:10.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-amd-graphics.postinst 
1970-01-01 01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers 
firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers
--- firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers 
1970-01-01 01:00:00.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-amd-graphics.triggers 
2024-04-20 18:11:28.0 +0200
@@ -0,0 +1 @@
+activate-noawait update-initramfs
diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2.postinst 
firmware-nonfree-20230625/debian/firmware-bnx2.postinst
--- firmware-nonfree-20230625/debian/firmware-bnx2.postinst 2023-12-19 
18:01:10.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-bnx2.postinst 1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2.triggers 
firmware-nonfree-20230625/debian/firmware-bnx2.triggers
--- firmware-nonfree-20230625/debian/firmware-bnx2.triggers 1970-01-01 
01:00:00.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-bnx2.triggers 2024-04-20 
18:11:28.0 +0200
@@ -0,0 +1 @@
+activate-noawait update-initramfs
diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2x.postinst 
firmware-nonfree-20230625/debian/firmware-bnx2x.postinst
--- firmware-nonfree-20230625/debian/firmware-bnx2x.postinst2023-12-19 
18:01:10.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-bnx2x.postinst1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-nonfree-20230625/debian/firmware-bnx2x.triggers 
firmware-nonfree-20230625/debian/firmware-bnx2x.triggers
--- firmware-nonfree-20230625/debian/firmware-bnx2x.triggers1970-01-01 
01:00:00.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-bnx2x.triggers2024-04-20 
18:11:28.0 +0200
@@ -0,0 +1 @@
+activate-noawait update-initramfs
diff -Nru firmware-nonfree-20230625/debian/firmware-cavium.postinst 
firmware-nonfree-20230625/debian/firmware-cavium.postinst
--- firmware-nonfree-20230625/debian/firmware-cavium.postinst   2023-12-19 
18:01:10.0 +0100
+++ firmware-nonfree-20230625/debian/firmware-cavium.postinst   1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-nonfree-20230625/debian/firmware-cavium.triggers 
firmware-nonfree-20230625/debian/firmware-cavium.triggers
--- 

Bug#1056901: network-manager-fortisslvpn: 1.4.0-1

[Chris Boot]

Control: severity -1 serious
Control: tags -1 ftbfs
X-Debbugs-Cc: pkg-utopia-maintain...@lists.alioth.debian.org

On 12/01/2024 21:13, Bastian Germann wrote:

On Sun, 26 Nov 2023 11:21:56 + Chris Boot  wrote:

I'm preparing to upload ppp-2.5.0 to unstable, and
network-manager-fortisslvpn fails to build with the updated pppd plugin
API in ppp-2.5.0. I see there is a patch[1] in the GNOME GitLab instance
which may resolve this issue.

Please could you upload a fixed version to unstable soon?

I'll upgrade the bug to RC when I upload ppp-2.5.0 to unstable.


Hi,

I've just uploaded 2.5.0-1+2 to unstable. Please upload a patched 
network-manager-fortisslvpn as soon as you can.


Thanks,
Chris

--
Chris Boot
bo...@debian.org

Bug#1069571: firmware-linux-free: activate update-initramfs trigger declaratively

[Helmut Grohne]

Package: firmware-linux-free
Version: 20200122-4
Severity: wishlist
Tags: patch

Removing firmware-linux-free does not activate the update-initramfs
trigger. This is due to being done procedurally in postinst without
matching postrm. I propose using declarative activation let dpkg figure
out when to activate the trigger.

Helmut
diff -Nru firmware-free-20200122/debian/changelog 
firmware-free-20200122/debian/changelog
--- firmware-free-20200122/debian/changelog 2024-02-18 20:56:32.0 
+0100
+++ firmware-free-20200122/debian/changelog 2024-04-20 17:27:53.0 
+0200
@@ -1,3 +1,10 @@
+firmware-free (20200122-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Activate trigger declaratively. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 20 Apr 2024 17:27:53 +0200
+
 firmware-free (20200122-4) unstable; urgency=medium
 
   * Update to linux-support 6.6.15
diff -Nru firmware-free-20200122/debian/firmware-linux-free.postinst 
firmware-free-20200122/debian/firmware-linux-free.postinst
--- firmware-free-20200122/debian/firmware-linux-free.postinst  2024-02-18 
20:56:32.0 +0100
+++ firmware-free-20200122/debian/firmware-linux-free.postinst  1970-01-01 
01:00:00.0 +0100
@@ -1,19 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-   configure)
-   dpkg-trigger --no-await update-initramfs
-   ;;
-
-   abort-upgrade|abort-remove|abort-deconfigure)
-   ;;
-
-   *)
-   echo "postinst called with unknown argument \`$1'" 1>&2
-   exit 1
-   ;;
-esac
-
-#DEBHELPER#
diff -Nru firmware-free-20200122/debian/firmware-linux-free.triggers 
firmware-free-20200122/debian/firmware-linux-free.triggers
--- firmware-free-20200122/debian/firmware-linux-free.triggers  1970-01-01 
01:00:00.0 +0100
+++ firmware-free-20200122/debian/firmware-linux-free.triggers  2024-04-20 
17:27:36.0 +0200
@@ -0,0 +1 @@
+activate-noawait update-initramfs

Bug#1056898: pptpd: Build failures with ppp-2.5.0

[Chris Boot]

Control: severity -1 serious
Control: tags -1 ftbfs

On 26/11/2023 13:06, Christoph Biedl wrote:

Chris Boot wrote...

[...]

I'll upgrade the bug to RC when I upload ppp-2.5.0 to unstable.


Okay, just let me know when it's a good time to upload an updated
pptpd package.


Hi Christoph,

I've just uploaded 2.5.0-1+2 to unstable. Please upload your patched 
pptpd as soon as you can.


Thanks,
Chris

--
Chris Boot
bo...@debian.org

Bug#1069570: tailscale: wrong use of format() ?

[Alvaro Herrera]

Package: tailscale
Version: 1.64.0
Severity: normal

Dear Maintainer,

I noticed that some log entries are malformed, in that the %-specifiers
are not expanded.  For example, today I see these lines in journalctl:

abr 20 18:12:14 schmee tailscaled[3288907]: [RATELIMIT] format("magicsock: %v 
active derp conns%s")
abr 20 18:12:14 schmee tailscaled[3288907]: [RATELIMIT] 
format("onPortUpdate(port=%v, network=%s)")
abr 20 18:12:33 schmee tailscaled[3288907]: [RATELIMIT] format("monitor: %s: 
src=%v, dst=%v, gw=%v, outif=%v, table=%v") (19 dropped)
abr 20 18:12:33 schmee tailscaled[3288907]: [RATELIMIT] format("magicsock: %v 
active derp conns%s") (1 dropped)
abr 20 18:12:33 schmee tailscaled[3288907]: [RATELIMIT] format("monitor: %s: 
src=%v, dst=%v, gw=%v, outif=%v, table=%v")
abr 20 18:12:34 schmee tailscaled[3288907]: [RATELIMIT] 
format("onPortUpdate(port=%v, network=%s)")
abr 20 18:12:35 schmee tailscaled[3288907]: [RATELIMIT] format("magicsock: %v 
active derp conns%s")
abr 20 18:12:38 schmee tailscaled[3288907]: [RATELIMIT] format("dns: Set: %v")

(This is a small snippet from "journalctl -u tailscaled | grep format", so
obviously there could be other lines that work in the same way).

Thanks!  I've generally found tailscale enormously useful, though I had
to mess with `ip rule` in order to make it work together with the PIA VPN.

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

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

Versions of packages tailscale depends on:
ii  iptables  1.8.9-2

Versions of packages tailscale recommends:
ii  iproute2   6.1.0-3
ii  tailscale-archive-keyring  1.35.181

tailscale suggests no packages.

-- no debconf information

Bug#1069569: extra_system_ids setting does not work

[Ian Jackson]

Package: lvm2
Version: 2.03.11-2.1

root@recovery:~# lvcreate --config 'local/extra_system_id=["hub"]' -L 1G -n 
test -Z y hub-early-b
  Configuration setting "local/extra_system_id" unknown.
  Cannot access VG hub-early-b with system ID hub with local system ID recovery.
root@recovery:~# 

This is almost identical to the example from the lvmsystemid(7)
manpage, under "Overriding system ID".  I also tried the
"lvmlocal.conf" setting exhibited there, and that didn't work either.

I was able to work around the problem by setting "system_id_source" in
lvm.conf and setting and the system's hostname with hostname(8):

root@recovery:~# cat /etc/lvm/lvm.conf
global {
system_id_source = "uname"
}
root@recovery:~#

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1069533: sayonara: Please package new upstream version

[Boyuan Yang]

Hi,

在 2024-04-20星期六的 08:45 -0700，Steve M写道：
> Is this not an issue that would prevent such an update for the time being?
> 
> 
>     This package is part of the ongoing testing transition known as 
> auto-qtbase-
> opensource-src. Please avoid uploads unrelated to this transition, they would
> likely delay it and require supplementary work from the release managers. On 
> the
> other hand, if your package has problems preventing it to migrate to testing,
> please fix them as soon as possible. You can probably find supplementary
> information in the debian-release archives or in the corresponding
> release.debian.org bug.
> 
>     This package is part of the ongoing testing transition known as 
> libglib2.0-
> 0t64. Please avoid uploads unrelated to this transition, they would likely 
> delay
> it and require supplementary work from the release managers. On the other 
> hand,
> if your package has problems preventing it to migrate to testing, please fix
> them as soon as possible. You can probably find supplementary information in 
> the
> debian-release archives or in the corresponding release.debian.org bug.

We can always upload to Debian Experimental first. Actually uploading to 
experimental
sooner can help discover issues early. Once the transition is no longer a 
blocker,
reuploading it to Unstable will be a lot more easier. If you have a prepared
version, I would be happy to sponsor the upload.

Thanks,
Boyuan

> On Sat, 2024-04-20 at 09:19 -0400, Boyuan Yang wrote:
> > Source: sayonara
> > Version: 1.8.0-beta1-1
> > Tags: sid
> > X-Debbugs-CC: kokoye2...@gmail.com s...@swm1.com
> > 
> > Dear Debian sayonara package maintainers,
> > 
> > A new upstream release of package sayonara was released in Jan 2024.
> > Since you are listed as Debian package maintainers, please consider
> > upgrading its Debian package. If you have any questions, please let
> > me know.
> > 
> > Thanks,
> > Boyuan Yang
> 



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

Bug#1064293: less: CVE-2022-48624

[P. J. McDermott]

On 2024-04-20 at 16:19, Christoph Anton Mitterer wrote:
> On Sat, 2024-04-20 at 07:54 -0400, P. J. McDermott wrote:
> > Then the salvage procedure can play out for the full 28+ days
> > specified
> > by developers-reference (21 days to allow the maintainer to object
> > followed by a DELAYED/7 adoption upload).  I've already soft-proposed
> > to
> > salvage in bug #1069280 yesterday.  And as mentioned there I'm not
> > yet a
> > DD or DM, so I'd need to find a sponsor (and access to
> > debian/less.git).  
> 
> In the light of the recent XZ backdoor, wouldn't it generally be more
> desirable to get more co-maintainers, rather than replacing an existing
> one?

Sure, that's exactly the plan.  I don't intend to remove or prevent
anyone from co-maintaining src:less.  Note that my proposal to adopt,
co-maintain, or salvage (bug #1069280) said that I would keep the
current maintainer in Uploaders or Maintainer unless he requests
otherwise.  My intent is not to force out the existing maintainer,
but to help where he seems to have been too busy to properly maintain
src:less for at least two years.  (No shame in being busy, but it looks
like the package could use some help keeping up with new upstream
releases, security issues like these, etc.)

And the repository is already in the "debian" Salsa group (formerly
"collab-maint" on Alioth), where any DD can commit to it.  Also, if I
adopt or salvage src:less, I plan to allow low-threshold NMU[1].  Other
than that, I don't know of an appropriate team for it.

[1]: https://wiki.debian.org/LowThresholdNmu
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Bug#1069533: sayonara: Please package new upstream version

[Steve M]

Is this not an issue that would prevent such an update for the time being?


This package is part of the ongoing testing transition known as auto-qtbase-
opensource-src. Please avoid uploads unrelated to this transition, they would
likely delay it and require supplementary work from the release managers. On the
other hand, if your package has problems preventing it to migrate to testing,
please fix them as soon as possible. You can probably find supplementary
information in the debian-release archives or in the corresponding
release.debian.org bug.

This package is part of the ongoing testing transition known as libglib2.0-
0t64. Please avoid uploads unrelated to this transition, they would likely delay
it and require supplementary work from the release managers. On the other hand,
if your package has problems preventing it to migrate to testing, please fix
them as soon as possible. You can probably find supplementary information in the
debian-release archives or in the corresponding release.debian.org bug.



Thanks
-Steve




On Sat, 2024-04-20 at 09:19 -0400, Boyuan Yang wrote:
> Source: sayonara
> Version: 1.8.0-beta1-1
> Tags: sid
> X-Debbugs-CC: kokoye2...@gmail.com s...@swm1.com
> 
> Dear Debian sayonara package maintainers,
> 
> A new upstream release of package sayonara was released in Jan 2024.
> Since you are listed as Debian package maintainers, please consider
> upgrading its Debian package. If you have any questions, please let
> me know.
> 
> Thanks,
> Boyuan Yang

Bug#1069568: ITP: python-hatch-mypyc -- Hatch build hook plugin for Mypyc

[Michael R. Crusoe]

Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name : python-hatch-mypyc
Version : 0.16.0
Upstream Author : Ofek Lev 
* URL : https://github.com/ofek/hatch-mypyc
* License : Expat
Programming Lang: Python
Description : Hatch build hook plugin for Mypyc
Provides a build hook plugin for Hatch build system for Python that compiles
code with Mypyc.

Remark: This package is Team Maintained by Michael R. Crusoe and the Debian 
Python Team at
https://salsa.debian.org/python-team/packages/python-hatch-mypyc



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#932957: 'Official' Debian-style html theme for Sphinx-based docs

[Holger Wansing]

I tend to ignore the language-related issues with the search for now.

Currently we have no document-wide search functionality at all on the Sphinx-
based documents on our website.

So it's clearly an improvement, if it works for English at least.


Holger

Bug#1069247: libconfig-model-dpkg-perl: test failures

[gregor herrmann]

On Sat, 20 Apr 2024 11:09:17 +0200, Dominique Dumont wrote:

> This really looks like a bug with prove:
> 
> $ perl t/reorder.t 
> ok 1 -  test re-ordered list
> 1..1
> $ prove -l -v -p t/reorder.t 
> t/reorder.t .. 
> ok 1 -  test re-ordered list
> 1..1
> Failed 1/1 subtests 
> 
> Test Summary Report
> ---
> t/reorder.t (Wstat: 0 Tests: 0 Failed: 0)
>   Parse errors: Bad plan.  You planned 1 tests but ran 0.
> Files=1, Tests=0,  1 wallclock secs ( 0.02 usr  0.00 sys +  0.92 cusr  0.07 
> csys =  1.01 CPU)
> Result: FAIL

Good idea to run this directly with `perl'.
 
> I can't see what's wrong with the output of reorder test...

Ack, and same for the failing test in dh-make-perl (#1069246).

But I don't see that `prove' has changed recently … So maybe this is
in fact even somewhere "deeper"?
 
> I'll try to dig this later on..

Thanks!


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1069567: bookworm-pu: package filezilla/3.63.0-1+deb12u4

[Phil Wyett]

Package: release.debian.org
Severity: normal
Tags: bookworm
Control: affects -1 + src:filezilla
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Fix CVE-2024-31497.

[ Impact ]
In PuTTY 0.68 through 0.80 before 0.81, biased ECDSA nonce generation
allows an attacker to recover a user's NIST P-521 secret key.

https://security-tracker.debian.org/tracker/CVE-2024-31497

[ Tests ]
Manual testing on own infrastructure.

[ Risks ]
The fix is a clean one and the regression risk is quite low.

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

[ Changes ]
Imported and backported the upstream patch that fixes CVE-2024-31497.

Regards

Phil

-- 

Homepage: https://kathenas.org

Instagram: https://instgram.com/kathenasorg

Support my Free/Open Source Software contribution...

Buy Me A Coffee: https://www.buymeacoffee.com/kathenasorg



filezilla_3.63.0-1+deb12u3_to_filezilla_3.63.0-1+deb12u4.debdiff
Description: Binary data


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

Bug#1069566: Updating the gnome-settings-daemon Uploaders list

[Boyuan Yang]

Source: gnome-settings-daemon
Version: 46.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Gunnar Hjalmarsson  has retired [1][2].
Please remove them from the Uploaders list of the package.

Thank.

[1] https://nm.debian.org/person/gunnarhj/
[2] https://discourse.ubuntu.com/t/in-memoriam-gunnar-hjalmarsson/42284


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

Bug#1068324: lintian: patch-not-forwarded-upstream for upstream patches

[Thorsten Glaser]

Hi Nilesh,

>Right. AFAICS, lintian spews that warning because the header in that patch in
>incomplete. It also needs a "From" and "Subject" (which can be same as commit

this is not entirely correct.

The full patch header is:

Description: fix typeset -p confusion between empty and unset
Origin: commit:10065BC69BE555D6721

Description is the standard name for Subject (the same way
Author is the standard DEP 3 name for From), and it’s present,
and when Origin indicates an upstream commit (as shown here),
Author does not need to be present, per DEP 3.

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………

Bug#1069565: Updating the gnome-pkg-tools Uploaders list

[Boyuan Yang]

Source: gnome-pkg-tools
Version: 0.22.9
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Gunnar Hjalmarsson  has retired [1][2].
Please remove them from the Uploaders list of the package.

Thank.

[1] https://nm.debian.org/person/gunnarhj/
[2] https://discourse.ubuntu.com/t/in-memoriam-gunnar-hjalmarsson/42284


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

Bug#1069259: haskell-termonad: FTBFS on armhf: callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic

[Ilias Tsitsimpis]

Control: severity -1 important

On Thu, Apr 18, 2024 at 10:48PM, Sebastian Ramacher wrote:
> https://buildd.debian.org/status/fetch.php?pkg=haskell-termonad=armhf=4.5.0.0-1%2Bb4=1713092640=0

This appears to be a GHC bug. I have requested the removal of
haskell-termonad from armhf, for now.

-- 
Ilias

Bug#1066036: black: Consider building faster native packages with mypyc

[Michael R. Crusoe]

On 19/04/2024 07.17, Julian Gilbey wrote:

On Mon, Mar 11, 2024 at 02:49:26PM +0100, Michael R. Crusoe wrote:

Package: black
Version: 23.1.0-1
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Dear Maintainer,

I noticed that your package supports building native code extensions using
mypyc. Upstream themselves ship portable binary wheels for better
performance. As a member of the Debian Package Team, I would be happy to add


I should have said "Debian Python Package Team"

this to your package. Please let me know.


This sounds like a nice idea; the pyproject.toml file states:

[tool.hatch.build.targets.wheel.hooks.mypyc]
enable-by-default = false
dependencies = [
   "hatch-mypyc>=0.16.0",
   "mypy==1.7.1",
   "click==8.1.3",  # avoid https://github.com/pallets/click/issues/2558
]

so you would have to build python3-hatch-pypyc first, though.  If you
can do that, this would be plausible.


Sure, I'll make that package.


 I would guess that using mypyc
would depend on having mypyc in Debian, but at the moment it's only an
ITP (#932003).


Oh! mypyc has been apart of the mypy Debian package since 0.740-1; Thanks, I've 
gone and closed that bug.

Thanks for the positive response. How do you want the mypyc compilation added 
to the package? Do you want a diff, a merge-request on Salsa, or a team upload?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063026: helvum: Upcoming gtk update

[Jonas Smedegaard]

Quoting Jeremy Bícha (2024-04-20 16:36:45)
> On Sat, Apr 20, 2024 at 9:22 AM Jonas Smedegaard  wrote:
> > Quoting Jeremy Bícha (2024-04-20 13:20:23)
> > > I am attaching patches to update helvum and would like to upload to
> > > Experimental.
> > >
> > > Jonas, the Salsa repo is a little jumbled. Could you push your
> > > pristine-tar branch? And update debian/latest to include your latest
> > > upload?
> >
> > Git repo are now unentangled.  I did so by force-pushing and thereby
> > overriding most of your previous uncoordinated changes, Jeremy.
> >
> > Thanks for your contributing, but please coordinate ahead, especially
> > when introducing new upstream code is involved, since that is
> > particulary tricky to unentangle.
> 
> Thank you. Would you like to upload these patches to Experimental now?
> Or do you want me to?

I can do that.

Thanks a lot for preparing those patches!

 - Jonas

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

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

signature.asc
Description: signature

Bug#1069564: Updating the gnome-user-docs Uploaders list

[Boyuan Yang]

Source: gnome-user-docs
Version: 46.0-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Gunnar Hjalmarsson  has retired [1][2].
Please remove them from the Uploaders list of the package.

Thank.

[1] https://nm.debian.org/person/gunnarhj/
[2] https://discourse.ubuntu.com/t/in-memoriam-gunnar-hjalmarsson/42284


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

Bug#1068136: Updating golang-github-golang-protobuf-1-5 to fix FTBFS

[Shengjing Zhu]

On Sat, Apr 20, 2024 at 10:28 PM Mathias Gibbens  wrote:
>
> Hi Anthony,
>
>   A few weeks ago you uploaded a new version of golang-google-protobuf
> to unstable which caused a FTBFS in golang-github-golang-protobuf-1-5
> v1.5.3 [1,2,3]. This has been blocking the transition of various golang
> packages from unstable to testing.
>
>   I've verified that v1.5.4 of golang-github-golang-protobuf-1-5 builds
> fine on my amd64 system. `build-rdeps golang-github-golang-protobuf-1-
> 5-dev` identifies 219 rdeps in main, so I haven't kicked off a `ratt`
> run testing for any build regressions with the newer version yet.
>

This is a known regression in 1.5.3, see
https://github.com/golang/protobuf/issues/1596#issuecomment-1981208282


-- 
Shengjing Zhu

Bug#1069563: RM: haskell-termonad [armhf] -- ROM; FTBFS; GHC bug

[Ilias Tsitsimpis]

Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: haskell-termo...@packages.debian.org
Control: affects -1 + src:haskell-termonad
User: ftp.debian@packages.debian.org
Usertags: remove

haskell-termonad FTBFS on armhf, due to a GHC bug (#1069259).

Please remove haskell-termonad from armhf.

Bug#1069562: Updating the gnome-software Uploaders list

[Boyuan Yang]

Source: gnome-software
Version: 46.0-4
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Gunnar Hjalmarsson  has retired [1][2].
Please remove them from the Uploaders list of the package.

Thank.

[1] https://nm.debian.org/person/gunnarhj/
[2] https://discourse.ubuntu.com/t/in-memoriam-gunnar-hjalmarsson/42284


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

Bug#1063026: helvum: Upcoming gtk update

[Jeremy Bícha]

On Sat, Apr 20, 2024 at 9:22 AM Jonas Smedegaard  wrote:
> Quoting Jeremy Bícha (2024-04-20 13:20:23)
> > I am attaching patches to update helvum and would like to upload to
> > Experimental.
> >
> > Jonas, the Salsa repo is a little jumbled. Could you push your
> > pristine-tar branch? And update debian/latest to include your latest
> > upload?
>
> Git repo are now unentangled.  I did so by force-pushing and thereby
> overriding most of your previous uncoordinated changes, Jeremy.
>
> Thanks for your contributing, but please coordinate ahead, especially
> when introducing new upstream code is involved, since that is
> particulary tricky to unentangle.

Thank you. Would you like to upload these patches to Experimental now?
Or do you want me to?

Jeremy Bícha

Bug#1069561: Updating the gnome-shell-extension-desktop-icons-ng Uploaders list

[Boyuan Yang]

Source: gnome-shell-extension-desktop-icons-ng
Version: 46+really47.0.4-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Gunnar Hjalmarsson  has retired [1][2].
Please remove them from the Uploaders list of the package.

Thank.

[1] https://nm.debian.org/person/gunnarhj/
[2] https://discourse.ubuntu.com/t/in-memoriam-gunnar-hjalmarsson/42284


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

Bug#1069560: Updating the gnome-desktop Uploaders list

[Boyuan Yang]

Source: gnome-desktop
Version: 44.0-5
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Gunnar Hjalmarsson  has retired [1][2].
Please remove them from the Uploaders list of the package.

Thank.

[1] https://nm.debian.org/person/gunnarhj/
[2] https://discourse.ubuntu.com/t/in-memoriam-gunnar-hjalmarsson/42284


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

Bug#1068136: Updating golang-github-golang-protobuf-1-5 to fix FTBFS

[Mathias Gibbens]

Hi Anthony,

  A few weeks ago you uploaded a new version of golang-google-protobuf
to unstable which caused a FTBFS in golang-github-golang-protobuf-1-5
v1.5.3 [1,2,3]. This has been blocking the transition of various golang
packages from unstable to testing.

  I've verified that v1.5.4 of golang-github-golang-protobuf-1-5 builds
fine on my amd64 system. `build-rdeps golang-github-golang-protobuf-1-
5-dev` identifies 219 rdeps in main, so I haven't kicked off a `ratt`
run testing for any build regressions with the newer version yet.

  Are you waiting on something specific before updating golang-github-
golang-protobuf-1-5?

Thanks,
Mathias

[1] -- https://qa.debian.org/excuses.php?package=golang-google-protobuf
[2] -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068136
[3] -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069368


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

Bug#1067547: wmweather+: diff for NMU version 2.19~alpha+ds-1.1

[Jeremy Sowden]

[Cc'ing t...@debian.org as I probably should have done with the nmudiff.
Apologies]

On 2024-04-18, at 21:37:40 +0100, Jeremy Sowden wrote:
> Control: tags 1067547 + patch
> Control: tags 1067547 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for wmweather+ (versioned as 2.19~alpha+ds-1.1) and
> am going to upload it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

I've forked the Salsa repo and pushed the changes to my fork:

  https://salsa.debian.org/azazel/wmweather-plus

I note that 2.17-2 and 2.18-1 were not committed to master, and
2.19~alpha+ds-1 wasn't in the repo at all.  I merged the older releases
to master and then used gbp-import-dsc to import 2.19~alpha+ds-1.  Does
this look all right?  May I push?

J.

> diff -Nru wmweather+-2.19~alpha+ds/debian/changelog 
> wmweather+-2.19~alpha+ds/debian/changelog
> --- wmweather+-2.19~alpha+ds/debian/changelog 2022-09-06 22:02:18.0 
> +0100
> +++ wmweather+-2.19~alpha+ds/debian/changelog 2024-04-18 21:14:57.0 
> +0100
> @@ -1,3 +1,10 @@
> +wmweather+ (2.19~alpha+ds-1.1) UNRELEASED; urgency=medium

I fixed this before uploading.

> +
> +  * Non-maintainer upload.
> +  * d/patches: add patch to fix FTBFS (Closes: #1067547)
> +
> + -- Jeremy Sowden   Thu, 18 Apr 2024 21:14:57 +0100
> +
>  wmweather+ (2.19~alpha+ds-1) unstable; urgency=medium
>  
>* Bump standards version to 4.6.1.
> diff -Nru wmweather+-2.19~alpha+ds/debian/patches/series 
> wmweather+-2.19~alpha+ds/debian/patches/series
> --- wmweather+-2.19~alpha+ds/debian/patches/series1970-01-01 
> 01:00:00.0 +0100
> +++ wmweather+-2.19~alpha+ds/debian/patches/series2024-04-18 
> 21:14:57.0 +0100
> @@ -0,0 +1 @@
> +update-snprintf-and-vsnprintf-checks.patch
> diff -Nru 
> wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
>  
> wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
> --- 
> wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
> 1970-01-01 01:00:00.0 +0100
> +++ 
> wmweather+-2.19~alpha+ds/debian/patches/update-snprintf-and-vsnprintf-checks.patch
> 2024-04-18 21:14:57.0 +0100
> @@ -0,0 +1,80 @@
> +Description: update snprintf and vsnprintf checks for
> + -Werror=implicit-function-declaration
> + .
> + This is the upstream fix.
> +Author: Brad Jorsch 
> +Last-Update: 2024-03-23
> +Forwarded: not-needed
> +Applied-upstream: commit:393394818cf4aa9b34071297a6947409cb19d74b
> +Bug-Debian: https://bugs.debian.org/1067547
> +
> +---
> + m4/snprintf.m4  | 6 +++---
> + m4/vsnprintf.m4 | 6 +++---
> + 2 files changed, 6 insertions(+), 6 deletions(-)
> +
> +diff --git a/m4/snprintf.m4 b/m4/snprintf.m4
> +index 03567bc5931e..1131e93ce206 100644
> +--- a/m4/snprintf.m4
>  b/m4/snprintf.m4
> +@@ -24,7 +24,7 @@ int snprintf(char *str, size_t size, const char *format, 
> ...);
> + #endif
> + ]],
> + [[char foo[]="ABC"; snprintf(foo, 2, "%d", 12);
> +-exit((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
> ++return ((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
> + [x_cv_func_snprintf_size=yes],
> + [x_cv_func_snprintf_size=no],
> + [x_cv_func_snprintf_size=no])])
> +@@ -52,7 +52,7 @@ AC_CACHE_CHECK([if snprintf return value is sane], 
> x_cv_func_snprintf_retval,
> + int snprintf(char *str, size_t size, const char *format, ...);
> + #endif
> + ]],
> +-[[char foo[10]; exit((snprintf(foo, 1, "%d", 9876)==4)?0:1);]])],
> ++[[char foo[10]; return ((snprintf(foo, 1, "%d", 9876)==4)?0:1);]])],
> + [x_cv_func_snprintf_retval=yes],
> + [x_cv_func_snprintf_retval=no],
> + [x_cv_func_snprintf_retval=no])])
> +@@ -79,7 +79,7 @@ AC_CACHE_CHECK([if snprintf(NULL, 0, ...) works], 
> x_cv_func_snprintf_null_ok,
> + int snprintf(char *str, size_t size, const char *format, ...);
> + #endif
> + ]],
> +-[int r=snprintf(NULL, 0, "%d", 100); exit((r==3 || r==-1)?0:1);])],
> ++[int r=snprintf(NULL, 0, "%d", 100); return ((r==3 || r==-1)?0:1);])],
> + [x_cv_func_snprintf_null_ok=yes],
> + [x_cv_func_snprintf_null_ok=no],
> + [x_cv_func_snprintf_null_ok=no])])
> +diff --git a/m4/vsnprintf.m4 b/m4/vsnprintf.m4
> +index a5de274cfc00..b580f46d2fcc 100644
> +--- a/m4/vsnprintf.m4
>  b/m4/vsnprintf.m4
> +@@ -37,7 +37,7 @@ int doit(char *str, size_t size, const char *format, ...){
> + }
> + ]],
> + [[char foo[]="ABC"; doit(foo, 2, "%d", 12);
> +-exit((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
> ++return ((foo[0]=='1' && foo[1]=='\0' && foo[2]=='C')?0:1);]])],
> + [x_cv_func_vsnprintf_size=yes],
> + [x_cv_func_vsnprintf_size=no],
> + [x_cv_func_vsnprintf_size=no])])
> +@@ -74,7 +74,7 @@ int doit(char *str, size_t size, const char *format, ...){
> + return r;
> + }
> + ]],
> +-[[char foo[10]; exit((doit(foo, 1, "%d", 9876)==4)?0:1);]])],
> ++[[char foo[10]; return ((doit(foo, 1, "%d", 9876)==4)?0:1);]])],
> + [x_cv_func_vsnprintf_retval=yes],
> + [x_cv_func_vsnprintf_retval=no],
> + 

Bug#1069417: Reassign to package release-notes

[Andreas Rönnquist]

Control: reassign -1 release-notes
Control: thanks

Bugs on the release notes should be to the release-notes package, reassigning.

best
/Andreas
gus...@debian.org

Bug#1069343: ITP: uart-devices -- Python library for managing UART devices on Linux

[Jonas Smedegaard]

Hi Edwards,

Quoting Edward Betts (2024-04-20 11:46:37)
> Package: wnpp
> Severity: wishlist
> Owner: Edward Betts 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
> 
> * Package name: uart-devices
>   Version : 0.1.0
>   Upstream Author : J. Nick Koston 
> * URL : https://github.com/bdraco/uart-devices
> * License : MIT
>   Programming Lang: Python
>   Description : Python library for managing UART devices on Linux
> 
>   uart-devices is a Python library designed to facilitate interaction with 
> UART
>   (Universal Asynchronous Receiver/Transmitter) devices on Linux systems. This
>   library provides developers with tools to manipulate UART hardware
>   programmatically, making it easier to integrate UART operations within 
> Python
>   applications.
> 
> I plan to maintain this package as part of the Python team.

If, as the above indicates, this is a Python _library_, then please
avoid occupying the global namespace "uart-devices" but instead also as
source package (not only binary package) use a python-specific prefix.

Concretely, I suggest to use "python-uart-devices" as name for the
source package, since that leaves room for the same source package
providing binary packages for both current major version 3 of Python,
and also other major versions and e.g. versions of pypy.

 - Jonas


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

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

signature.asc
Description: signature

Bug#1064293: less: CVE-2022-48624

[Christoph Anton Mitterer]

On Sat, 2024-04-20 at 07:54 -0400, P. J. McDermott wrote:
> Then the salvage procedure can play out for the full 28+ days
> specified
> by developers-reference (21 days to allow the maintainer to object
> followed by a DELAYED/7 adoption upload).  I've already soft-proposed
> to
> salvage in bug #1069280 yesterday.  And as mentioned there I'm not
> yet a
> DD or DM, so I'd need to find a sponsor (and access to
> debian/less.git).

In the light of the recent XZ backdoor, wouldn't it generally be more
desirable to get more co-maintainers, rather than replacing an existing
one?


Cheers,
Chris.

Bug#1068174: Debian FPGA toolchain update and testing (Was: Bug#1068174: yosys: Please package the latest upstream release)

[Daniel Gröber]

Hi Philipp,

Thanks for reaching out, I rely on users to ask for FPGA toolchain updates
since I like to errr on the side of "keep the working version" with
electronics stuff until I have a reason to break it out and test it myself.

Note to self: I almost missed your email due to pre-vacation crunch.
Really need to teach my sieve scripts to flag bug mails for my packages :)

On Mon, Apr 01, 2024 at 11:48:16AM +0200, Philipp Klaus Krause wrote:
> I use yosys to synthesize for the iCE40UP and GateMate FPGAs. IMO, the
> current upstream release 0.38 has substantial improvements over the 0.33
> release currently in Debian.

Neat, are the GateMates finally available on the open market then? I'd love
to get my hands on some dev hardware.

Are you open to doing some testing for the new package version once I get
around to putting it together? I can do end-to-end testing on ICE40(HX) and
(probably) GW1N (if I can figure out how to flash this thing) maybe
@Jonathan (in CC) can cover ECP5 and you could do ICE40UP and GateMate?

I've been meaning to look into what we could use for testing beyond simple
blinkies. Perhaps some CPU? I'd like to have something that can run
internal consistency checks. If anyone has any ideas let me know.

Thanks,
--Daniel


signature.asc
Description: PGP signature