Bug#1081845: ejabberd: PEP notification filtering entity capabilities ignored

[Martin]

On 2024-10-04 23:31, Philipp Huebner wrote:
> Can you point to the relevant upstream commits?

Sure, I even did so in the patch, attached in the original report :-)

Bug: https://github.com/processone/ejabberd/issues/4158
Applied-Upstream: 3469a51f5896ef96b2e53d61fcfd2163b92ad11a

URL is:
https://github.com/processone/ejabberd/commit/3469a51f5896ef96b2e53d61fcfd2163b92ad11a

It only removes two lines of code.

Cheers

Bug#1081845: ejabberd: PEP notification filtering entity capabilities ignored

[Martin]

reopen 1081845
thanks

The upstream fix came after 24.07.
If the patch is not applied,
this bug needs to stay open for one more release.

Bug#1082989: dictionaries-common: Please update debian-ispell.el to support Enchant

[Agustin Martin]

On Sun, Sep 29, 2024 at 06:09:16PM +0100, Reuben Thomas wrote:
> Package: dictionaries-common
> Version: 1.29.7
> Severity: normal
> 
> Please update debian-ispell.el to support Enchant. I can help with this if
> desired, being both the Enchant upstream maintainer, and the author of
> Emacs’s Enchant support in ispell.el.
> 
> Since Enchant uses other spell-checkers under the hood, in particular both
> aspell and hunspell, it would be possible to reuse the Debian-specific code
> for finding appropriate dictionaries. Alternatively, since Enchant has its
> own mechanisms for configuring what to use, similar to those used in
> debian-ispell.el (e.g. based on the user’s configured language) it would be
> possible simply to do nothing. This might reduce confusion and complexity.

Hi, Reuben,

I have been looking a bit at this. It is not only debian-ispell.el, but
probably also DictionariesCommon.pm. There are some things that may not be
directly reusable, e.g., aspell supports "aspell -d castellano check
file.txt" while enchant not, only locale supported selection is allowed. So,
some aspell entries cannot be directly reused.

I have a rough first cut that does not yet address above issue. Will think
a bit more about this. spellchecker priorities will be the same as in FSF
Emacs.

> It seems to me that there are some non-Enchant-related things that could be
> changed, or perhaps removed; for example, there’s a comment that says:
> “Leave hunspell as last option, hunspell support for -a is still too buggy”,
> yet I used hunspell for many years from Emacs with no problem, until quite
> recently. Here, and elsewhere it might be possible to remove Debian-specific
> code, and avoid future confusion and breakage.

This comment is really ancient. Fixed in git repo.

Thanks for your suggestion.

-- 
Agustin

Bug#1082898: dhcpcd - Runs as service

[Martin-Éric Racine]

pe 27. syysk. 2024 klo 23.51 Bastian Blank (wa...@debian.org) kirjoitti:
> Package: dhcpcd
> Version: 1:10.0.10-2
> Severity: serious
> X-Debbugs-Cc: wa...@debian.org
>
> dhcpcd runs itself as service, not controlled by the network management.
> This makes it not a suitable replacement for isc-dhcp.

bin:dhcpcd does run as a service, since it ships the init script and
systemd unit, and launches the dhcpcd binary as a daemon. I purposely
package these separate precisely to avoid the issue you mentioned.

bin:dhcpcd-base doesn't run as a service. It merely provides the
binary and exit scripts.

Martin-Éric

Bug#1073992: debconf: failure between unpack and configure dpkg runs via apt

[Martin-Éric Racine]

ti 3. syysk. 2024 klo 12.47 Colin Watson (cjwat...@debian.org) kirjoitti:
>
> On Wed, Aug 28, 2024 at 12:56:32AM +0200, Guillem Jover wrote:
> > On Fri, 2024-06-21 at 10:53:20 +0300, Martin-Éric Racine wrote:
> > > Unpacking pci.ids (0.0~2024.05.31-1) over (0.0~2024.04.20-1) ...
> > > debconf: Unable to load Debconf::Element::Dialog. Failed because: Can't 
> > > locate Debconf/Element/Dialog.pm in @INC (you may need to install the 
> > > Debconf::Element::Dialog module) (@INC entries checked: /etc/perl 
> > > /usr/local/lib/i386-linux-gnu/perl/5.38.2 /usr/local/share/perl/5.38.2 
> > > /usr/lib/i386-linux-gnu/perl5/5.38 /usr/share/perl5 
> > > /usr/lib/i386-linux-gnu/perl-base /usr/lib/i386-linux-gnu/perl/5.38 
> > > /usr/share/perl/5.38 /usr/local/lib/site_perl) at (eval 19) line 1, 
> > >  line 3.
> > > BEGIN failed--compilation aborted at (eval 19) line 1,  line 3.
> > >
> > > Can't locate object method "new" via package "Debconf::Element::Dialog" 
> > > (perhaps you forgot to load "Debconf::Element::Dialog"?) at 
> > > /usr/share/perl5/Debconf/FrontEnd.pm line 69,  line 3.
> > > Setting up pci.ids (0.0~2024.05.31-1) ...
> >
> > As mentioned on the report, this is not an issue with pci.ids, but
> > with something (apt) calling debconf (perhaps indirectly) between the
> > unpack and configure runs. I'd assume an apt hook is causing this. I'm
> > reassigning this to debconf as the actual thing apparently failing, but
> > if the actual hook (or caller) can be tracked down then perhaps that
> > can be reassigned there. (Sorry for passing along this hot potato. :)
> >
> > (The BTS contains mails with several log files, and some analysis.)
>
> Martin-Éric, could you provide the output of "ls /etc/apt/apt.conf.d/"
> and "grep -E 'debconf|dpkg-' /etc/apt/apt.conf.d/*"?  That would
> probably speed up the search here.

$ ls /etc/apt/apt.conf.d/
00CDMountPoint  00trustcdrom  01autoremove  20apt-show-versions
50appstream  50apt-file.conf  50command-not-found  70debconf
99funkyware  99-localepurge  99needrestart

$ grep -E 'debconf|dpkg-' /etc/apt/apt.conf.d/*
/etc/apt/apt.conf.d/70debconf:// Pre-configure all packages with
debconf before they are installed.
/etc/apt/apt.conf.d/70debconf:DPkg::Pre-Install-Pkgs
{"/usr/sbin/dpkg-preconfigure --apt || true";};

Martin-Éric

Bug#1082730: openssh-client: please enable ext-info-c

[Martin-Éric Racine]

Package: openssh-client
Version: 1:9.2p1-2+deb12u3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

According to OpenSSH's feature list, ext-info-s and ext-info-c were implemented 
starting with version 7.2 upstream.

However, on the Debian port, ssh-audit doesn't report ext-info-c as supported 
and it only started reporting ext-info-s around 9.8. Is there any particular 
reason for disabling this?

Martin-Éric

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

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

Versions of packages openssh-client depends on:
ii  adduser   3.134
ii  libc6 2.36-9+deb12u8
ii  libedit2  3.1-20221030-2
ii  libfido2-11.12.0-2+b1
ii  libgssapi-krb5-2  1.20.1-2+deb12u2
ii  libselinux1   3.4-1+b6
ii  libssl3   3.0.14-1~deb12u2
ii  passwd1:4.13+dfsg1-1+b1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.2-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbzpz4ACgkQrh+Cd8S0
17YLaQ/9F41eZhZkZiEZtOoik3ONMFzbk7QC3Y5c6m/3Mc3xfU8qhzEIjzy4fqRm
vNbEoFP3XgHA0GIG8JVvBJMn7S6YKSJe8X9/jvF9BiU+aXAXKNJw8NfMza852j7O
jlAxAr5nfgelhJH8upWR6wIuUp0zEvvyqp/oBAEGObDT3MDMc0oGWbi6w2ISHNCk
Iv26WpRvCE+fs4W8AyP6lbREiXJANNR0FWpWqUaCPoybf8DjF3UqK33Ep9KCqkwd
aZFvEKh1f8DnYKKKD2UMOAKQ2B+5lAfdXBIqqUi2lq1oPNOpfffHYc7GXpAWh4Qi
Us3XBOCYesBELUgMu0ovBAL6BiDSAmtrL1d/dbiZveUja8UMKinvLr9ENAJ4Tjl5
fp73fv5xBKdsQFodq0ptI0Bej17JtQImhgRBaIP4M8HQjWgKCXOWoU/bi7/CLwHN
OUAAkkeSOu8EzPbkP2t9JTQFbzKQ5Ty6z5X/BgcsI+X6iODTVAAuLLr8BaHfApyF
wm9XXYfjKvoAHIc6h8zTF2CKocJQ8SkHpwFhkUcSwky4qtBwvl7TK2cX8Jv3V4EP
RdX+iyLGCja35Zkx7AxDg9f+ZBkrYmS+BHK584mY3yxsw6/R25D5TvbRsIOa5ZKO
m94lgLYxmaW+IEZpSB3WlAfhS1IxzZWiKCjpHWHbCRh5Vx2Md9w=
=Tv1c
-END PGP SIGNATURE-

Bug#1077423: fortunes-es: FTBFS: rot.c:23:5: error: implicit declaration of function ‘exit’ [-Wimplicit-function-declaration]

[Agustin Martin]

Control: tags -1 + patch

On Mon, Jul 29, 2024 at 07:42:04AM +0200, Lucas Nussbaum wrote:
> Source: fortunes-es
> Version: 1.36
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240728 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > gcc -O2 -DFORTDIR="\"/usr/share/games/fortunes\"" 
> > -DOFFDIR="\"/usr/share/games/fortunes/off\"" 
> > -DLOCFORTDIR="\"/usr/local/share/games/fortunes\"" 
> > -DLOCOFFDIR="\"/usr/local/share/games/fortunes/off\"" -Wall 
> > -fomit-frame-pointer -pipe -fsigned-char -Wdate-time -D_FORTIFY_SOURCE=2  
> > -c -o rot.o rot.c
> > rot.c: In function ‘main’:
> > rot.c:23:5: error: implicit declaration of function ‘exit’ 
> > [-Wimplicit-function-declaration]
> >23 | exit(0);
> >   | ^~~~
> > rot.c:8:1: note: include ‘’ or provide a declaration of ‘exit’
> > 7 | #include 
> >   +++ |+#include 
...

Hi, Javi,

Attached patch makes package build here.

Regards,

-- 
Agustin
diff --git a/util/rot.c b/util/rot.c
index 3064193..c9d5a95 100644
--- a/util/rot.c
+++ b/util/rot.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 
 int main(void)
 {

Bug#1081938: openshot-qt: please migrate to QT6

[Martin-Éric Racine]

Source: openshot-qt
Version: 3.1.1+dfsg1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

openshot-qt still depends on QT5 dependencies. It would be desirable to rebuild 
against QT6.

Martin-Éric

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

Kernel: Linux 6.1.0-25-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbn6tMACgkQrh+Cd8S0
17YOqhAAoHZ764A/y9ciboP0/99Uzpvf6i7rYB2icMuUd68e55QjT7FzW2rcHx8Y
QBJvq1TdIoavcZ6wOgf8oNVDX6I8WObhWT4os3MfTfYPHRSMGA9eCIJl57nZeTb3
BAhh1b/Z5ecgZsbN+E7/Ka473ugEEA/3JVGrOE1qH4pk4In3g4XS8BUjlrs9+ERc
FJmTbo5vA4osY8X5zTpEg41VuA+acavMhUYNwmQx9v/lXCVexeHDO/AbgzOlwSUt
pEACKSDSYXB+jmSA8HtsF4Xu9MsNaqBSsv4wDXOkglznWJUALbf3U7sZgOhIV915
vVPV5y4dgMerny2b7Bp2fDEndbqWGAjglEFs1tQmKfwV37MUCdtz2Ni/pJARFP/I
Hvm8UT7nnLj/iUDo7qt2GVPBHqehHjq4vxCyRl1w0V7HmhAricyYDjHQEwGoXWyF
ghj5SyUgQsFu7Vo10EmXY9x2e86x8QWXLSlKvN43tTuxag0lQ6y23S6erL0eoVqH
5HRoTIxSTlJPJvKF5i++PKutM41LUqeoPFjWf9G4KzWboNxsU6rKvIhA6HLAe29s
CHHbOIo90D5ULYNXmtljMDHx4L4aIgp23+//u1d2vt6aq6pIwEfjKHrIbZPvgiDB
4cEE0REMFwWUKY3urKFu7M8BG586nyNbA+LQ/xtZOxyzzvmWCG0=
=oOga
-END PGP SIGNATURE-

Bug#1081934: override: cron:admin/optional

[Martin-Éric Racine]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: c...@packages.debian.org, debian-b...@lists.debian.org
Control: affects -1 + src:cron

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

cron is still at Priority:important even though Lintian has long warned that 
packages should migrate to systemd timers before the next Debian release.

I therefore propose downgrading cron to Priority:optional and updating the 
override to match.

Exception: the Hurd port doesn't have systemd and still depends on traditional 
cron jobs. cron should therefore remain at Priority:important, but on Hurd only.

Best Regards,
Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbn2VEACgkQrh+Cd8S0
17Ya0xAApDPI1VkXfQT40JZstu6pMvlml4bZfPduYJRqZ72fmYRkDgBtNbz9gRSn
L8tIqZj2uTJHFn76tIfOXgwAlXAgjGXod7iFaReXe5Y0nvFJGOIoaG9S205CEGb7
oKF8h9EwpvYDZe4gO2aD8o8jhBKp9cDmMPkPcpj7M5xisaAvZSWStGnw04eH0rww
oCWBmubSmB6qVQLnxvssyhQVOPrnE1ocaEcaExNmORpD8xLItU6pQiuEO33+LO0L
RUKCUvsqNx6vOqBOLwULJdnQXy7VP16QryCuWgRmxFhTJWgKm0kP+kXsLGtICVic
nAE4IlIcpFsBw4CGGKbQuIyCG4MzwO/ypMFNV//YZTrGhxGHxjlhHrVOC0vzgSx3
sDJ1jlkU6H1UVzPLjef37b2tYBqS45UwSv9Fe0TwGU6TdQua+pzvSWQa+e/JaYOx
/kvWDK2FE5tnIDJCFrVzi2lI81jrv+G50G1zVAl7rQkgizDL6jB9qaGeFgZoFhjd
i84EQJ3G/VwCAL3Xyp/jVt5V3RLdLfPfiXkZSJOmd1AfXOGlv4BJLlTnLe+S3J28
+wSqHAq4JY9VojLKLdbmikgi7RCA4INK4O4ddUFPsFrKfpO9kX1Cs4uFMzOTOVQG
uX9xolHBxy97CRMY/roKR+RJ7Iuj2pEnoz5HhY0DxsYusHxEImk=
=G0bm
-END PGP SIGNATURE-

Bug#1071090: iso-codes: installs broken symbolic links

[Martin-Éric Racine]

control: reassign -1 localepurge

su 15. syysk. 2024 klo 22.05 Dr. Tobias Quathamer (to...@debian.org) kirjoitti:
>
> control: reopen -1
> control: tag -1 unreproducible
>
> Am 15.09.24 um 10:11 schrieb Martin-Éric Racine:
> > This IS in a Sid chroot. I have tried purging and re-installing. Same 
> > result.
> >
> > Martin-Éric
>
> Thanks for investigating again. I'm reopening the bug, but it's not
> reproducible by me, so tagging accordingly.
>
> Maybe I'll get another report about a similar problem with some hints
> where the problem might be -- right now, I don't have a clue what's
> going on in your sid chroot versus mine.

I checked and noticed the same issue on all of my hosts, not just that
Sid chroot.

Anyhow, I think that I found the cause:

I use 'localepurge' to have APT automatically remove unused
localizations and save disk space. As far as I can tell, the bug is
that it removes any unused FILE shipped by a package, but not symbolic
links. We are therefore left with 2 symbolic links pointing to
nothing, and 'adequate'  complains about them. 'localepurge' should
probably manage those too.

Reassigned.

Martin-Éric

Bug#1077419: libervia-templates: FTBFS: AttributeError: 'NoneType' object has no attribute 'get'

[Martin]

Control: severity -1 normal

I can't reproduce the failure in a clean and current sid pbuilder.
Maybe the error is just gone or I'm missing something...

Bug#1081845: ejabberd: PEP notification filtering entity capabilities ignored

[Martin]

Package: ejabberd
Version: 23.10-1
Severity: important
Tags: patch upstream
Forwarded: https://github.com/processone/ejabberd/issues/4158

Dear Maintainer,

this bug has been fixed by upstream recently. For tracking purposes,
it's entered it here.

Justification for severity important: Very negative effect regarding
bandwidth in applications using PEP heavily, mainly IoT.

Every `` sent to a PEP node gets a complete echo as
``.

If an IoT device sends a lot of measurement data, it gets all that data
back for no reason, which can get problematic and even expensive.

Cheers
Description: mod_pubsub: Don't blindly echo PEP notification
Author: Holger Weiss 
Origin: upstream
Bug: https://github.com/processone/ejabberd/issues/4158
Applied-Upstream: 3469a51f5896ef96b2e53d61fcfd2163b92ad11a
Last-Update: 2024-09-15
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/mod_pubsub.erl
+++ b/src/mod_pubsub.erl
@@ -3051,8 +3051,7 @@
 	   extended_headers([Publisher])),
 Pred = fun(To) -> delivery_permitted(Owner, To, NodeOptions) end,
 ejabberd_sm:route(jid:make(LUser, LServer, SenderResource),
-		  {pep_message, <<((Node))/binary, "+notify">>, Stanza, Pred}),
-ejabberd_router:route(xmpp:set_to(Stanza, jid:make(LUser, LServer)));
+		  {pep_message, <<((Node))/binary, "+notify">>, Stanza, Pred});
 broadcast_stanza(Host, _Publisher, Node, Nidx, Type, NodeOptions, SubsByDepth, NotifyType, BaseStanza, SHIM) ->
 broadcast_stanza(Host, Node, Nidx, Type, NodeOptions, SubsByDepth, NotifyType, BaseStanza, SHIM).
 

Bug#1071090: iso-codes: installs broken symbolic links

[Martin-Éric Racine]

la 14. syysk. 2024 klo 22.34 Dr. Tobias Quathamer (to...@debian.org) kirjoitti:
>
> Am 14.09.24 um 07:48 schrieb Martin-Éric Racine:
> > $ LC_ALL=C ls -l /usr/share/locale/fil/LC_MESSAGES/
> > total 0
> > lrwxrwxrwx 1 root root 13 2024-09-13 22:45 iso_3166.mo -> iso_3166-1.mo
> > lrwxrwxrwx 1 root root 13 2024-09-13 22:45 iso_3166_2.mo -> iso_3166-2.mo
> >
> > You might wanna check whether other files failed to install.
> >
> > Martin-Éric
>
> This is the output on my system:
>
> $ adequate iso-codes
> $
>
> $ LC_ALL=C ls -l /usr/share/locale/fil/LC_MESSAGES/
> total 44K
> -rw-r--r-- 1 root root  11K Jan 14  2024 iso_15924.mo
> -rw-r--r-- 1 root root  24K Jan 14  2024 iso_3166-1.mo
> -rw-r--r-- 1 root root 3.0K Jan 14  2024 iso_3166-2.mo
> lrwxrwxrwx 1 root root   13 Jan 14  2024 iso_3166.mo -> iso_3166-1.mo
> lrwxrwxrwx 1 root root   13 Jan 14  2024 iso_3166_2.mo -> iso_3166-2.mo
> $
>
> So I cannot reproduce this.
>
> Also, I'm not convinced that there is an actual problem in the iso-codes
> package, because I can see both files in the created .deb package. They
> are also listed in the package's contents, see e. g.
> https://packages.debian.org/sid/all/iso-codes/filelist.
>
> I would guess that there is some strange error in the system you are
> using for this test. Did you try to create a clean sid chroot and
> install iso-codes from scratch? Are those files still missing in that
> environment?

This IS in a Sid chroot. I have tried purging and re-installing. Same result.

Martin-Éric

Bug#1079091: Upgrading libssl3t64 fixed this for me

[martin f krafft]

Had the same issue with Remmina, and an upgrade of libssl3t64 from 
3.3.1 to 3.3.2 fixed it for me. Previously, the openssl legacy 
ciphers were only recommended and I didn't have them installed, now 
they are mandatory.


--
 .''`.   martin f. krafft 
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems

Bug#1038882: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)

[Martin-Éric Racine]

la 14. syysk. 2024 klo 15.30 Daniel Gröber (d...@darkboxed.org) kirjoitti:
> On Sat, Sep 14, 2024 at 08:31:06AM +0300, Martin-Éric Racine wrote:
> > Let's start with changing the ifupdown dependencies and DHCP stack
> > search order to effectively deprecate ISC.
>
> I don't think we're ready yet. I have some concerns:
>
>  1) How do you deal with the mismatch between dhcpd being a system daemon
> vs. ifudown wanting a per-interface process?

It's not a daemon unless it's started as one. dhcpcd-base doesn't
include the init script or systemd unit.

>  2) I'm worried about the behavioural change regarding inet/inet6 stanzas
> outlined in #1065085 with a patch by ktetzlaff pending.

That's largely a non-issue. The separate stanzas largely is the result
of IPv6 being an afterthought that had to be incorporated into
ifupdown later on. Simply removing inet6 stanzas fixes it. Anyhow, in
most cases, people don't even bother with explicitly configuring IPv6
unless they have a static IP, which therefore doesn't affect DHCP/RA
cases.

>  3) dhcpcd-base enables IPv6 privacy addressess by default.

Which is a good thing.

> 1) Looking at the packaging I see that `dhcpcd-base`, unlike `dhcpcd`
> (which was renamed from dhcpcd5), does not ship the daemon part of dhcpcd,
> which takes over dhcp duties on all interfaces by default as soon as it's
> installed. This may be problematic because on upgrade dhcpcd may take over
> an interface dhclient is still running on, causing havoc. Perhaps the
> sockets are bound such that this wouldn't succeed but I'm not sure.

It's not problematic. Someone who wants to use it as a daemon would
not keep ifupdown anyhow.

> Looking at ifupdown's inet.defn I see dhcpcd being operated in per-iface
> mode, like `dhcpcd [-h,-i,-I,-l options...] $IFACE`. In my experience
> dhcpcd is very finicky when you try to use it in a dhclient style
> one-per-interface mode. When I played with this a while back and found that
> the logic is such that dhcpcd will always connect to the system-wide daemon
> if one is running even if you ask it to operate on just one
> interface. Martin, Santiago: how have you done testing in this dark corner?
> My upstream issue is here:
> https://github.com/NetworkConfiguration/dhcpcd/issues/241

It works fine here on my laptop. I have separate lines for Ethernet
and wireless (with a known SSID and PSK), both of which get activated
if Ethernet happens to be plugged in.

> one-process-per-interface is going away in v11 does it make sense to rely
> on it in the first place?

v11 is unlikely to happen. Too many people explicitely told Roy that
it's not desirable.

> So even with the dhcpcd-base approach of not shipping the daemon, I am
> concerned that as soon as a user installs the daemon part ifupdown will
> stop working properly because we're not prepared for the daemon taking
> over. I just did a quick test and if a per-interface dhcpcd is running and
> indeed -k will stop working as soon as the system-wide daemon is started.

That's already the case. That's why ifupdown should Conflicts with the
package providing the init script and systemd unit (dhcpcd).

> 2) I see two problems with the "you only need the inet stanza" change:
> Firstly users are loosing control over whether v4/v6 is enabled on dhcp
> interfaces. IMO that's not just a break in backwards-compatibility but also
> loss of an important feature needed by network operators in complex
> environments. Secondly, IPv4 is legacy and will go away eventually so if
> anything starting the DHCP client should be attached to the inet6 stanza ;)
> Since remaining IPv4 users are going to disagree vehemently here I would
> suggest that either choice is utterly broken. We must support dhcp
> enablement seperately for each address family.

Control over which one currently works fine via dhcpcd.conf. It could
also be implemented via command options passed by ifupdown. As for the
day IPv4 becomes obsolete, dhcpcd will simply fork once it has reached
its timeout and presume an IPv6-only conenction.

> 3) Since ifupdown is mainly used in the server/embedded sorts of
> enviornments I'm not sure privacy addressing is the right default.
> (cf. /etc/dhcpcd.conf having `slaac private` thus enabling RFC 7217
> addressing). We can assume NM will be in use for most Desktop users so I
> believe it's safe in principle to retain the current MAC based SLAAC
> address behaviour we used to get from the kernel RA implementation.
> Thoughts?

Privacy by default is desirable. Globally traceable hosts is not.

> Further Martin raised the issue that "an upgrade would result in both
> remaining installed" while also noting this can be mitigated by changin

Bug#1071090: iso-codes: installs broken symbolic links

[Martin-Éric Racine]

la 14. syysk. 2024 klo 8.25 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> pe 13. syysk. 2024 klo 23.02 Dr. Tobias Quathamer (to...@debian.org) 
> kirjoitti:
> >
> > Am 14.05.24 um 09:10 schrieb Martin-Éric Racine:
> > > Package: iso-codes
> > > Version: 4.16.0-1
> > > Severity: important
> > >
> > > $ adequate --all --tags -py-file-not-bytecompiled
> > > iso-codes: broken-symlink /usr/share/locale/fil/LC_MESSAGES/iso_3166.mo 
> > > -> iso_3166-1.mo
> > > iso-codes: broken-symlink /usr/share/locale/fil/LC_MESSAGES/iso_3166_2.mo 
> > > -> iso_3166-2.mo
> >
> > Hi Martin-Éric,
> >
> > thanks for this bug report -- however, I cannot reproduce it. I've just
> > run adequate on my system with iso-codes 4.16.0-1 installed, and it
> > doesn't find any errors.
> >
> > It also looks like a false positive to me, because iso-codes does ship
> > both files which are the link targets. I'm therefore closing this bug
> > report.
> >
> > Could you try again to run the adequate command on your system and see
> > if you still get that error? If so, please do not hesitate to reopen the
> > bug and get back to me.
>
> Not fixed.
>
> $ adequate iso-codes
> iso-codes: broken-symlink
> /usr/share/locale/fil/LC_MESSAGES/iso_3166.mo -> iso_3166-1.mo
> iso-codes: broken-symlink
> /usr/share/locale/fil/LC_MESSAGES/iso_3166_2.mo -> iso_3166-2.mo
> $ dpkg -l | grep iso-codes
> ii  iso-codes 4.17.0-1
> all  ISO language, territory, currency, script codes and their
> translations
> $ cat /etc/issue
> Debian GNU/Linux trixie/sid \n \l

I just made a quick build. It clearly shows what the problem is:

$ LC_ALL=C ls -l debian/iso-codes/usr/share/locale/fil/LC_MESSAGES/
total 40
-rw-r--r-- 1 perkelix perkelix 10473 2024-09-14 08:35 iso_15924.mo
-rw-r--r-- 1 perkelix perkelix 23844 2024-09-14 08:35 iso_3166-1.mo
-rw-r--r-- 1 perkelix perkelix  3047 2024-09-14 08:35 iso_3166-2.mo
lrwxrwxrwx 1 perkelix perkelix13 2024-09-14 08:35 iso_3166.mo ->
iso_3166-1.mo
lrwxrwxrwx 1 perkelix perkelix13 2024-09-14 08:35 iso_3166_2.mo ->
iso_3166-2.mo

$ LC_ALL=C ls -l /usr/share/locale/fil/LC_MESSAGES/
total 0
lrwxrwxrwx 1 root root 13 2024-09-13 22:45 iso_3166.mo -> iso_3166-1.mo
lrwxrwxrwx 1 root root 13 2024-09-13 22:45 iso_3166_2.mo -> iso_3166-2.mo

You might wanna check whether other files failed to install.

Martin-Éric

Bug#1038882: ifupdown maintenance

[Martin-Éric Racine]

la 14. syysk. 2024 klo 1.17 Santiago Ruano Rincón
(santiag...@riseup.net) kirjoitti:
>
> Adding team+network...@tracker.debian.org to the loop.
>
> El 13/09/24 a las 12:31, Martin-Éric Racine escribió:
> > pe 13. syysk. 2024 klo 12.16 Sean Whitton (spwhit...@spwhitton.name) 
> > kirjoitti:
> > > Hello Santiago,
> > >
> > > What are your current intentions in this area?  Do you want to make the
> > > change for trixie?  If not, I'd like to close the override change bug
> > > for now.  Thanks.
> >
> > I am wondering the same. However, neither Santiago or Josue have
> > followed up on this and other pending ifupdown issues that I have
> > brought up. Santiago already indicated elsewhere that his spare time
> > is sparse, which might explain why, but Josue is essentially MIA.
> >
> > Personally, I'm ready to raise the Priority of dhcpcd-base to
> > important, to match the override, ...
>
> Regarding this particular issue, I have said somewhere that I preferred
> to sync the override with the Recommends update in ifupdown. So Sean, if
> you are willing to apply the override, we can go ahead with the
> ifupdown-related change.

Let's start with changing the ifupdown dependencies and DHCP stack
search order to effectively deprecate ISC.

If Sean agrees with the override, we can do that one separately. It's
just a one word change in 2 packages' control file.

> However, keep in mind that there is a current discussion about what will
> be the default networking stack for trixie.

Where? I haven't seen any discussion about this in a while. All I saw
was netplan, systemd and network-manager maintainers each pushing for
their package to become the default.

Martin-Éric

Bug#1071090: iso-codes: installs broken symbolic links

[Martin-Éric Racine]

pe 13. syysk. 2024 klo 23.02 Dr. Tobias Quathamer (to...@debian.org) kirjoitti:
>
> Am 14.05.24 um 09:10 schrieb Martin-Éric Racine:
> > Package: iso-codes
> > Version: 4.16.0-1
> > Severity: important
> >
> > $ adequate --all --tags -py-file-not-bytecompiled
> > iso-codes: broken-symlink /usr/share/locale/fil/LC_MESSAGES/iso_3166.mo -> 
> > iso_3166-1.mo
> > iso-codes: broken-symlink /usr/share/locale/fil/LC_MESSAGES/iso_3166_2.mo 
> > -> iso_3166-2.mo
>
> Hi Martin-Éric,
>
> thanks for this bug report -- however, I cannot reproduce it. I've just
> run adequate on my system with iso-codes 4.16.0-1 installed, and it
> doesn't find any errors.
>
> It also looks like a false positive to me, because iso-codes does ship
> both files which are the link targets. I'm therefore closing this bug
> report.
>
> Could you try again to run the adequate command on your system and see
> if you still get that error? If so, please do not hesitate to reopen the
> bug and get back to me.

Not fixed.

$ adequate iso-codes
iso-codes: broken-symlink
/usr/share/locale/fil/LC_MESSAGES/iso_3166.mo -> iso_3166-1.mo
iso-codes: broken-symlink
/usr/share/locale/fil/LC_MESSAGES/iso_3166_2.mo -> iso_3166-2.mo
$ dpkg -l | grep iso-codes
ii  iso-codes 4.17.0-1
all  ISO language, territory, currency, script codes and their
translations
$ cat /etc/issue
Debian GNU/Linux trixie/sid \n \l

Martin-Éric

Bug#1038882: ifupdown maintenance

[Martin-Éric Racine]

pe 13. syysk. 2024 klo 12.16 Sean Whitton (spwhit...@spwhitton.name) kirjoitti:
> Hello Santiago,
>
> What are your current intentions in this area?  Do you want to make the
> change for trixie?  If not, I'd like to close the override change bug
> for now.  Thanks.

I am wondering the same. However, neither Santiago or Josue have
followed up on this and other pending ifupdown issues that I have
brought up. Santiago already indicated elsewhere that his spare time
is sparse, which might explain why, but Josue is essentially MIA.

Personally, I'm ready to raise the Priority of dhcpcd-base to
important, to match the override, and I think that it should be done
now, because isc-dhcp has been mothballed upstream, while dhcpcd still
sees regular releases and it transparently handles IPv4 and IPv6
without requiring separate inet and inet6 lines in
/etc/network/interfaces.

Martin-Éric

Bug#1081536: Acknowledgement (whipper: Traces back when eject is not installed.)

[Martin Dosch]

Please find a MR in salsa: 
https://salsa.debian.org/python-team/packages/whipper/-/merge_requests/4

On 12.09.2024 14:24, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1081536: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081536.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
Debian Python Team 

If you wish to submit further information on this problem, please
send it to 1081...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
1081536: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081536
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


signature.asc
Description: PGP signature

Bug#1081536: whipper: Traces back when eject is not installed.

[Martin Dosch]

Package: whipper
Version: 0.10.0-4~bpo12+1
Severity: important

Dear Maintainer,

when using whipper it failed with a traceback:

```
whipper cd info
INFO:whipper.command.cd:checking device /dev/sr0
Traceback (most recent call last):
  File "/usr/bin/whipper", line 8, in 
sys.exit(main())
 ^^
  File "/usr/lib/python3/dist-packages/whipper/command/main.py", line 56, in 
main
ret = cmd.do()
  
  File "/usr/lib/python3/dist-packages/whipper/command/basecommand.py", line 
141, in do
return self.cmd.do()
   ^
  File "/usr/lib/python3/dist-packages/whipper/command/basecommand.py", line 
141, in do
return self.cmd.do()
   ^
  File "/usr/lib/python3/dist-packages/whipper/command/cd.py", line 104, in do
utils.load_device(self.device)
  File "/usr/lib/python3/dist-packages/whipper/program/utils.py", line 24, in 
load_device
subprocess.check_output(['eject', '-t', device],
  File "/usr/lib/python3.11/subprocess.py", line 466, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
   ^
  File "/usr/lib/python3.11/subprocess.py", line 548, in run
with Popen(*popenargs, **kwargs) as process:
 ^^^
  File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'eject'
```

I backported cdparanoia and whipper to bookworm, but no dice, whipper 
still fails. After installing "eject" whipper works as expected, so it 
seems that there is a dependency on eject missing.

Best regars,
Martin

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

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

Versions of packages whipper depends on:
ii  cd-paranoia 10.2+2.0.2-1~bpo12+1
ii  cdrdao  1:1.2.4-3
ii  flac1.4.2+ds-2
ii  libc6   2.36-9+deb12u8
ii  libsndfile1 1.2.0-1
ii  python3 3.11.2-1+b1
ii  python3-cdio2.1.1-1+b4
ii  python3-gi  3.42.2-3+b1
ii  python3-libdiscid   2.0.2-1+b2
ii  python3-musicbrainzngs  0.7.1-4
ii  python3-mutagen 1.46.0-1
ii  python3-pil 9.4.0-1.1+deb12u1
ii  python3-requests2.28.1+dfsg-1
ii  python3-ruamel.yaml 0.17.21-1
ii  python3-setuptools-scm  7.1.0-3
ii  sox 14.4.2+git20190427-3.5

whipper recommends no packages.

whipper suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1081395: Version 1.1.1 available

[Martin Michlmayr]

Package: libavif16
Severity: wishlist

Version 1.1.1 has been out since July: 
https://github.com/AOMediaCodec/libavif/releases

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1081193: apt: please implement purge-build-dep

[Martin-Éric Racine]

ti 10. syysk. 2024 klo 20.36 Julian Andres Klode (j...@debian.org) kirjoitti:
>
> On Mon, Sep 09, 2024 at 11:44:09PM GMT, David Kalnischkies wrote:
> > Am Mon, Sep 09, 2024 at 10:30:41AM GMT, schrieb Martin-Éric Racine:
> > > In its current form, 'apt-get build-dep package' pulls all Build-Depends 
> > > for 'package' and marks them as manually installed, which means that they 
> > > won't be removed when later running 'apt-get --purge autoremove'.
> >
> > I have to note that there is an option to disable the 'marks them as
> > manual' part of that sentence so that a later autoremove would catch
> > them: APT::Get::Build-Dep-Automatic which defaults to false, but can
> > be set to true, e.g. with: -o APT::Get::Build-Dep-Automatic=true

That's not the same as an easy-to-remember apt-get --option or command.

> > > It would therefore be desirable for apt-get to have a method for 
> > > recursively removing Build-Depends for 'package' either via an --option 
> > > or via its own command.
> >
> > Many packages can depend on rather generic things like say all KDE
> > things depending on many dev packages or in some cases packages even
> > build-depend on newer versions of packages like make or even of
> > essentials like dpkg.
> >
> > As such, iterating the build-depends and "blindly" removing them all
> > seems not that useful in many cases even if it probably works fine
> > for most "normal" packages.

I disagree.

> > I think what you are asking for is a way to remove the packages you
> > installed in a previous build-dep action again. The option above sort-of
> > does that if you set it. A more generic version would perhaps allow
> > setting a user-defined flag on packages and querying for that flag later
> > on.
> >
> > Another, perhaps better alternative, would be to "undo" the action.
> > apt keeps a record of previous actions (/var/log/apt/history.log),
> > but that is as far as that particular feature has been developed so
> > far. We would need to parse the files and offer a UI to interact with
> > this history, so you could tell apt to "undo" an entry from that
> > history.
> >
> > I have put "undo" in quotes as this is not really the type of undo
> > people know from a text editor: Package upgrades can not be undone
> > (downgrades are unsupported), removed packages that can't be downloaded
> > can't be (re)installed, purges are final and so on and so forth. So,
> > the hard part about this might very well be finding the right name…
> > apart from actually writing the code of course.
>
> I'm still going with undo, or rather `history undo` to match what users
> already know from DNF.
>
> But yes, I did not have the time so far to implement it, and I need
> to "finish" my new solver first :)

In a broad sense, what we need is an apt-get --option or command that
does something similar to what '--auto-remove purge' the metapackage
created by devscript's 'mk-build-deps' does. Alternately, setting
APT::Get::Build-Dep-Automatic default to true would accomplish the
same. Basically, users should never end up stuck with a plethora of
unwanted packages just because someone asked them to test whether a
patch fixes the bug they reported and it required pulling a couple of
GB of build-dependencies.

Martin-Éric

Bug#1081234: ronn: Failing tests

[Martin Dosch]

Package: ronn
Version: 0.10.1-1
Severity: normal
Tags: upstream

Dear Maintainer,

unfortunately 0.10.1-1 is not migrating due to failing tests. Looks like 
this is not a debian specific but an upstream issue: 
https://github.com/apjanke/ronn-ng/issues/44

Best regards,
Martin

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

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

Versions of packages ronn depends on:
ii  ruby   1:3.1+nmu1
ii  ruby-ronn  0.10.1-1

ronn recommends no packages.

ronn suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1081197: linux: please Build-Depends on 'gcc' or on 'build-essential' rather than 'gcc-13'

[Martin-Éric Racine]

ma 9. syysk. 2024 klo 13.50 Bastian Blank (wa...@debian.org) kirjoitti:
>
> On Mon, Sep 09, 2024 at 11:51:17AM +0300, Martin-Éric Racine wrote:
> > src:linux currently has an explicit Build-Depends on gcc-13. This defeats 
> > the whole point of building against whatever 'build-essential' pulls in for 
> > the target Debian release, and it results in several GCC suites getting 
> > unnecessarily installed. It would instead be desirable for src:linux to 
> > Build-Depends on either the generic 'gcc' or on 'build-essential' for its 
> > compiler requirements.
>
> And how will that work if src:linux uses gcc-13 to build?

Is there any compelling reason for src:linux to hardcode the GCC
version as an explicit dependency?

Martin-Éric

Bug#1081197: linux: please Build-Depends on 'gcc' or on 'build-essential' rather than 'gcc-13'

[Martin-Éric Racine]

Source: linux
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

src:linux currently has an explicit Build-Depends on gcc-13. This defeats the 
whole point of building against whatever 'build-essential' pulls in for the 
target Debian release, and it results in several GCC suites getting 
unnecessarily installed. It would instead be desirable for src:linux to 
Build-Depends on either the generic 'gcc' or on 'build-essential' for its 
compiler requirements.

Martin-Éric

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 6.10.6-686-pae (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbetwAACgkQrh+Cd8S0
17ZdqA/8DC4Wz/FgWWvfeHSI6h5BNzr3UjxgeZsoOGDc2JlvcpVRAEWnIiq0QJdj
tyhJGOcevKD8btAtGjxPbzXEQOavQNB66BBW1fY/9/cky+L3MZarpYIJqRbf63SG
blU+Gfn0kNbE/EwryP+i7wRfEs9yUzECb2pyGJKccycsmqbZm4M9M1wdZk72fV3s
cWQ/Jo+s4MnEHgidLesijLZkP/EPD4iT3znONVWhGkDa6A/B/P2yDywvNajyHrRV
N4FT6mAS4HWVhegnX5yJN2/ndT9EH5QDq0zbUZLpzz2R7Z6L0RVNPHBxKgR+IruL
yNjpoM7+ggFsRTzMDW4LvpQjWaoTgQVJstnbCPpZwWwFAib0RjKIYfZzJuxw75rk
aIj7Sg1fjj3uf8Tx8NG6aeICdK1JuUY7pN3l2mSk4k3SdG9sdtYODkYC3ee5qWbc
pPC41R4uBrPpq1mWDaci+FYihaZAcK40oZHHZYwsPiSncuYIWrgjmxzi/4iaJUiv
ic7L8FHktwph79IHtosQR1KErKmiyAOKFU74/8H8DypmcIWc+gS5MziO4oiyWJmC
Bw+7I+Fuo90vSgwe35+d4f5BtXFJqVRaG5YEQNt/bcOQUDUJftDuDn0kpOxe8Y98
MYXsn3JvE9aQucbfNLHBuEIPDe6FkifLHeDDib7FPeQumMxh4qI=
=rkLN
-END PGP SIGNATURE-

Bug#1081195: devscripts: test-patches KeyError: 'pae'

[Martin-Éric Racine]

Package: devscripts
Version: 2.23.7
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It appears that test-patches makes incorrect guesses for the target 
architecture:

$ debian/bin/test-patches  306803.patch 
PYTHONHASHSEED=0 debian/bin/gencontrol.py
Traceback (most recent call last):
  File "/home/perkelix/linux-6.10.6/debian/bin/gencontrol.py", line 643, in 

Gencontrol()()
  File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/gencontrol.py", 
line 385, in __call__
self.do_main()
  File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/gencontrol.py", 
line 404, in do_main
self.do_main_recurse(self.config, vars, makeflags)
  File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/gencontrol.py", 
line 447, in do_main_recurse
self.do_arch(arch, vars.copy(), makeflags.copy())
  File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/gencontrol.py", 
line 515, in do_arch
self.do_arch_recurse(config, vars, makeflags)
  File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/gencontrol.py", 
line 549, in do_arch_recurse
self.do_featureset(featureset, vars.copy(), makeflags.copy())
  File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/gencontrol.py", 
line 564, in do_featureset
self.do_featureset_recurse(config, vars, makeflags)
  File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/gencontrol.py", 
line 596, in do_featureset_recurse
for flavour in config.flavours:
   ^^^
  File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/config_v2.py", line 
543, in flavours
debianarch_flavour=debianarch_flavour[flavour.name],
   ~~^^
KeyError: 'pae'
make: *** [debian/rules:149: debian/control-real] Virhe 1


By the looks of it, it truncates anything after the last dash of the running 
kernel, which results in it trying to configure for flavor=pae instead of the 
expected flavor=686-pae.

Martin-Éric

- -- Package-specific info:

- --- /etc/devscripts.conf ---
Empty.

- --- ~/.devscripts ---
export DEBSIGN_KEYID=C89002C77A8BEC6A4E6D7390AE1F8277C4B4D7B6

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 6.10.6-686-pae (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages devscripts depends on:
ii  dpkg-dev  1.22.11
ii  file  1:5.45-3
ii  gnupg 2.2.43-8
ii  gpgv  2.2.43-8+b1
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20231003.0-2
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.77-1
ii  patchutils0.4.2-1
ii  perl  5.38.2-5
ii  python3   3.12.5-1
ii  sensible-utils0.0.24
ii  wdiff 1.2.2-6

Versions of packages devscripts recommends:
ii  apt 2.9.8
ii  curl8.9.1-2
pn  dctrl-tools 
pn  debian-keyring  
pn  dput | dupload  
pn  equivs  
pn  libdistro-info-perl 
ii  libdpkg-perl1.22.11
ii  libencode-locale-perl   1.05-3
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
ii  libjson-perl4.1-1
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.14-1
pn  libsoap-lite-perl   
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.32-1
ii  liburi-perl 5.28-1
pn  licensecheck
pn  lintian 
ii  man-db  2.13.0-1
ii  patch   2.7.6-7
pn  pristine-tar
ii  python3-apt 2.9.0+b1
ii  python3-debian  0.1.49
pn  python3-magic   
ii  python3-requests2.32.3+dfsg-1
pn  python3-unidiff 
pn  python3-xdg 
pn  strace  
pn  unzip   
ii  wget1.24.5-2
ii  xz-utils5.6.2-2

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20220412cvs-1
ii  build-essential  12.10
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.20
pn  diffoscope   
pn  disorderfs   
pn  dose-extra

Bug#1081193: apt: please implement purge-build-dep

[Martin-Éric Racine]

Package: apt
Version: 2.9.8
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In its current form, 'apt-get build-dep package' pulls all Build-Depends for 
'package' and marks them as manually installed, which means that they won't be 
removed when later running 'apt-get --purge autoremove'. It would therefore be 
desirable for apt-get to have a method for recursively removing Build-Depends 
for 'package' either via an --option or via its own command.

Thanks!
Martin-Éric

- -- Package-specific info:

- -- (/etc/apt/preferences present, but not submitted) --


- -- (/etc/apt/preferences.d/funkyware.pref present, but not submitted) --


- -- (/etc/apt/sources.list present, but not submitted) --


- -- (/etc/apt/sources.list.d/funkyware.list present, but not submitted) --


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

Kernel: Linux 6.1.0-25-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.4
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.43-8+b1
ii  libapt-pkg6.0t642.9.8
ii  libc6   2.40-2
ii  libgcc-s1   14.2.0-4
ii  libgnutls30t64  3.8.6-2
ii  libseccomp2 2.5.5-1+b1
ii  libstdc++6  14.2.0-4
ii  libsystemd0 256.5-2

Versions of packages apt recommends:
ii  ca-certificates  20240203

Versions of packages apt suggests:
pn  apt-doc  
pn  aptitude | synaptic | wajig  
ii  dpkg-dev 1.22.11
ii  gnupg2.2.43-8
ii  powermgmt-base   1.37+nmu1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbepB4ACgkQrh+Cd8S0
17akZg//YW5jylntbh93X7dQpdRLMJsu9pihkpMbqi/QmmA40gRDI1LaTElEZjgS
7FA5Z+OIlAJehtNyzbPN7eLhSNdJItY0DNzu/8+kjqBlYE3N9bKcZYkwzTkrekCQ
NCjru2ZSIeGX5ocICW6aFgVv3fKDOv3xtLv3VXSp+Y0lRjKPLM4Vqu2qadN5NxPl
V5POI7EU5TFNWfwwkvCNTfJtanJ/xeNLatz/3CDjaTF6OHH/060AoCl0AATv9yRK
XEebdN9ourJShZVuaM7SOZTHt9z65L65rdsMUpkX2zkb9yaXuEEUENTd5kDercn0
BMNnhvy8NptyEc7oxI4vM85c9jesKsjjG0S4OEw5+0etccsbVvzJ1UE61Mr8o599
/JJp4HgWO5vM/NW6oM1C9FiMnZjOJlEk6BbxzvFos25qYBKH9L7iajH/5CTKlUaG
5K/1T/UuwrpsvBslqGW/KYjqWT1RJEwZpormt0gALipwSC1xq0R6pYAQRHT63v5r
18qQJMz+7//fDyxwT66tD/PQMEYnPwabxpD8MURiywUuIltd3jmT2hRIWBqUc7u9
STTvsqMmAmHsxxaR5znHNHeeCa6USTAdy2ehMVzQhxXbtCJh1EV03pr3ZQk9uCTt
2fNziNeqmkBkfffYnAyUHJHdPYho0ENvk8F/YXlW+b4XM53qPtk=
=dxxg
-END PGP SIGNATURE-

Bug#1080983: [INTL:sv] Swedish strings for refind debconf

[Martin Bagge / brother]

On 2024-09-06 15:24, Anders Jonsson wrote:

Hi Martin,
fixed a typo (automtiskt->automatiskt) in the translation.


Dang.
Thanks. Excellent as always!

--
brother

Bug#1080983: [INTL:sv] Swedish strings for refind debconf

[Martin Bagge / brother]

package: refind
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

--
brother
# Translation of refind debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the refind package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: refind\n"
"Report-Msgid-Bugs-To: ref...@packages.debian.org\n"
"POT-Creation-Date: 2015-12-12 18:35-0500\n"
"PO-Revision-Date: 2024-09-06 13:42+0200\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Automatically install rEFInd to the ESP?"
msgstr "Ska rEFInd installeras automtiskt på ESP?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"It is necessary to install rEFInd to the EFI System Partition (ESP) for it "
"to control the boot process."
msgstr ""
"Det är nödvändigt att installera rEFInd på EFI System Partition (ESP) för "
"att den ska kunna kontrollera uppstartsprocessen."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"Not installing the new rEFInd binary on the ESP may leave the system in an "
"unbootable state. Alternatives to automatically installing rEFInd include "
"running /usr/sbin/refind-install by hand or installing the rEFInd binaries "
"manually by copying them from subdirectories of /usr/share/refind-{version}."
msgstr ""
"Installeras inte nya rEFInd-binärer på ESP så kan systemet hamna i ett läge "
"som innebär att det inte kan starta. Alternativ till att installera rEFInd "
"skulle kunna vara att köra /usr/sbin/refind-install själv eller installera "
"rEFInd-binärer manuellt genom att kopiera de från underkatalogerna i /usr/"
"share/refind-{version}."

Bug#1080423: profanity: Profanity segfaults when using gpg-from-sq

[Martin Dosch]

Package: profanity
Version: 0.14.0-1+b3
Severity: important
Tags: upstream

Dear Maintainer,

when using gpg-from-sq profanity backtraces on startup:

```
Program received signal SIGSEGV, Segmentation fault.
0x5560e552 in _gpgme_key_to_ProfPGPKey (key=key@entry=0x581a4800) 
at src/pgp/gpg.c:870
870p_pgpkey->name = strdup(key->uids->uid);
#0  0x5560e552 in _gpgme_key_to_ProfPGPKey 
(key=key@entry=0x581a4800) at src/pgp/gpg.c:870
p_pgpkey = 0x581a5750
sub = 0x5819d000
#1  0x5560eb7d in p_gpg_list_keys () at src/pgp/gpg.c:311
p_pgpkey = 
key = 0x581a4800
error = 0
result = 0x58195800
ctx = 0x581958a0
ids = 
curr = 
#2  0x5560ece6 in p_gpg_init () at src/pgp/gpg.c:124
keys = 
#3  0x55591325 in _init (theme_name=, 
log_file=, config_file=0x0, 
log_level=0x556180b0 "WARN") at src/profanity.c:209
prof_log_level = PROF_LEVEL_WARN
prof_version = 0x556f41f0 "0.14.0dev.master.996a1fdf"
prof_log_level = 
prof_version = 
theme = 
console = 
#4  prof_run (log_level=0x556180b0 "WARN", account_name=0x0, 
config_file=0x0, log_file=, 
theme_name=) at src/profanity.c:98
cont = 1
line = 
#5  0x5558c80d in main (argc=, argv=) at 
src/main.c:174
entries = {{long_name = 0x55618424 "version", short_name = 118 'v', 
flags = 0, arg = G_OPTION_ARG_NONE, 
arg_data = 0x556c7358 , description = 0x556246f7 
"Show version information", 
arg_description = 0x0}, {long_name = 0x5561e959 "account", 
short_name = 97 'a', flags = 0,
arg = G_OPTION_ARG_STRING, arg_data = 0x556c7340 
, 
description = 0x556449b0 "Auto connect to an account on 
startup", arg_description = 0x0}, {
long_name = 0x5562445f "log", short_name = 108 'l', flags = 0, 
arg = G_OPTION_ARG_STRING, 
arg_data = 0x556c7350 , 
description = 0x556449d8 "Set logging levels, DEBUG, INFO, WARN 
(default), ERROR", 
arg_description = 0x55624710 "LEVEL"}, {long_name = 
0x55621b47 "config", short_name = 99 'c', 
flags = 0, arg = G_OPTION_ARG_STRING, arg_data = 0x556c7338 
, 
description = 0x55644a10 "Use an alternative configuration 
file", arg_description = 0x0}, {
long_name = 0x55624716 "logfile", short_name = 102 'f', flags = 
0, arg = G_OPTION_ARG_STRING, 
arg_data = 0x556c7348 , description = 0x5562471e 
"Specify log file", 
arg_description = 0x0}, {long_name = 0x5561ed00 "theme", 
short_name = 116 't', flags = 0, 
arg = G_OPTION_ARG_STRING, arg_data = 0x556c7330 , 
description = 0x5562472f "Specify theme name", arg_description 
= 0x0}, {long_name = 0x0, 
short_name = 0 '\000', flags = 0, arg = G_OPTION_ARG_NONE, arg_data 
= 0x0, description = 0x0, 
arg_description = 0x0}}
error = 0x0
context = 0x556ee9e0
```

Best regards,
Martin

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

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

Versions of packages profanity depends on:
ii  libc6  2.40-2
ii  libcurl3t64-gnutls 8.9.1-2
ii  libgcrypt201.11.0-6
ii  libgdk-pixbuf-2.0-02.42.12+dfsg-1
ii  libglib2.0-0t642.82.0-1
ii  libgpgme11t64  1.18.0-5
ii  libgtk-3-0t64  3.24.43-3
ii  libncursesw6   6.5-2
ii  libnotify4 0.8.3-1+b1
ii  libotr5t64 4.1.1-5.1
ii  libpython3.12t64   3.12.5-4
ii  libqrencode4   4.1.1-1+b2
ii  libreadline8t648.2-5
ii  libsignal-protocol-c2.3.2  2.3.3-3+b1
ii  libsqlite3-0   3.46.1-1
ii  libstrophe00.13.1-1
ii  libtinfo6  6.5-2
ii  libx11-6   2:1.8.7-1+b1
ii  libxss11:1.2.3-1+b1

profanity recommends no packages.

profanity suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1080064: nfs-ganesha: /usr-move got reverted

[Christoph Martin]

Hi Helmut,

thanks for checking this. I am working on a fix.

Christoph

Am 30.08.24 um 09:34 schrieb Helmut Grohne:


we filed #1071916 about moving systemd units from aliased locations to
/usr earlier and you fixed it in 4.3-11. Now with version 5.9-3, aliased
units are reintroduced:



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1080311: railway-gtk: should handle timezones in a better way

[Martin]

Package: railway-gtk
Version: 2.4.0-4

Dear maintainer,

if users system has a different timezone then the train operator (common
use case when planning a trip in a different country), it's not obvious,
which time is used where.

E.g. if users system runs in UTC, searching for a connection in Germany
(CEST/UTC+2 atm.) at 16 hrs, this is interpreted as 16:00 UTC and it
shows a train at 18:00 CEST.

This is technically correct, but confusing. Web sites of train operators
interprete search time always as local time of the train, no matter
which is the time zone of the users system, which is better UX IMHO.

Alternatively, times zones could be displayed with the times, but that
would clutter the UI. Not so nice on mobile phone.

The obvious workaround would be to run railway-gtk with the desired
timezone, but it looks like railway-gtk ignores the TZ variable!

Cheers

Bug#1068898: Tested Martin's installer on OpenRD client and it works.

[Martin Michlmayr]

* Cyril Brulebois  [2024-09-01 14:44]:
> Just merged the pu/openrd branch into the bookworm one so it cannot
> be missed next time.

Thank you!

> Apologies for the missed opportunity.

No problem.  Thanks for your help.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1079545: gtk4: test regression in 4.15.x: css/parser/math2.css test fails on armel

[Martin]

On 2024-09-01 12:46, Simon McVittie wrote:
> So, I'm invoking Debian Constitution §2.1.1 and declining to attempt
> to fix this upstream myself. If someone from the ARM porting team
> feels strongly that armel should continue to be a first-class-citizen
> architecture for GTK for whatever reason, please take over here.

My company is still a heavy user of glib and gobject on armel. But
certainly not of GTK. Is there still any use case for GTK on armel?

Bug#1074337: libssh-gcrypt-dev: Drop gcrypt flavor

[Martin Pitt]

Control: block -1 by 1080270

Hello Bastian,

Bastian Germann [2024-06-26 22:05 +0200]:
> Please drop the libssh-gcrypt-dev and libssh-gcrypt-4 packages as soon as no 
> reverse dep is left.
> Upstream has deprecated the gcrypt flavor with v0.11 and only a few packages 
> still depend on it.
> They can all be updated because the OpenSSL license was changed, which was 
> presumably voids the
> reason to keep the additional flavor around.

Thanks for noticing! I'm afraid you missed the last remaining one in ffmpeg.
Just reported to https://bugs.debian.org/1080270

Hence I'll revert your libssh commit for now, but happy to re-apply it once
ffmpeg gets sorted out.

Cheers!

Martin

Bug#1080270: libavformat60: Please move libssh-gcrypt-4 dependency to libssh4

[Martin Pitt]

Package: libavformat60
Version: 7:6.1.1-5+b1

Hello Debian Multimedia Maintainers,

Bastian asked [1] for libssh to drop the gcrypt variant (libssh-gcrypt-4). It's
deprecated in libssh upstream, and with the recently changed OpenSSL license
there is no reason any more to have it.

The only remaining reverse dependencies in Debian are libavformat60 and
libavformat-extra60. Can you please move them to libssh-4, i.e. to the OpenSSL
variant?

Thanks,

Martin

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074337

Bug#1080263: paperwork: Update to latest upstream release

[Martin Dosch]

Source: paperwork
Version: 2.2.2-2
Severity: wishlist

Dear Maintainer,

thank you for maintaining paperwork, it is a really useful tool. However 
currently it doesn't work well for me (see #1080261). Also it was 
removed from testing.
Maybe updating to the latest release v2.2.5 will already solve this 
issues?

Best regards,
Martin

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

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


signature.asc
Description: PGP signature

Bug#1080261: paperwork-gtk: Throws traceback on start and hangs forever on document import

[Martin Dosch]

Package: paperwork-gtk
Version: 2.2.2-2
Severity: normal

Dear Maintainer,

paperwork-gtk throws the following traceback on every start:

```
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/openpaperwork_gtk/mainloop/glib.py", 
line 160, in decorator
func(*args, **kwargs)
  File 
"/usr/lib/python3/dist-packages/openpaperwork_core/work_queue/default.py", line 
30, in _on_error
raise exc
  File "/usr/lib/python3/dist-packages/openpaperwork_core/promise.py", line 
235, in _threaded_do
our_r = self.func(*args, **self.kwargs)
^^^
  File 
"/usr/lib/python3/dist-packages/paperwork_backend/guesswork/label/sklearn/__init__.py",
 line 909, in _reload_label_guessers
) = self._load_classifiers(
^^^
  File 
"/usr/lib/python3/dist-packages/paperwork_backend/guesswork/label/sklearn/__init__.py",
 line 948, in _load_classifiers
corpus.standardize_feature_vectors(vectorizer)
  File 
"/usr/lib/python3/dist-packages/paperwork_backend/guesswork/label/sklearn/__init__.py",
 line 340, in standardize_feature_vectors
doc_vector = scipy.sparse.hstack([
 ^
  File "/usr/lib/python3/dist-packages/scipy/sparse/_construct.py", line 733, 
in hstack
return _block([blocks], format, dtype, return_spmatrix=True)
   ^
  File "/usr/lib/python3/dist-packages/scipy/sparse/_construct.py", line 948, 
in _block
raise ValueError(msg)
ValueError: blocks[0,:] has incompatible row dimensions. Got 
blocks[0,1].shape[0] == 6, expected 1.
```

Also it was stuck for a long time on importing a document so I had to 
eventually kill it.

Best regards,
Martin

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

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

Versions of packages paperwork-gtk depends on:
ii  adwaita-icon-theme [gnome-icon-theme-symbolic]  47~beta-1
ii  aspell  0.60.8.1-1+b1
ii  gir1.2-glib-2.0 2.82.0-1
ii  gir1.2-gtk-3.0  3.24.43-3
ii  gir1.2-notify-0.7   0.8.3-1+b1
ii  gir1.2-pango-1.01.54.0+ds-2
ii  gnome-icon-theme3.12.0-5
ii  openpaperwork-core  2.2.2-2
ii  openpaperwork-gtk   2.2.2-2
ii  paperwork-backend   2.2.2-2
ii  python3 3.12.5-1
ii  python3-distro  1.9.0-1
ii  python3-gi  3.48.2-1+b1
ii  python3-gi-cairo3.48.2-1+b1
ii  python3-pycountry   24.6.1+ds1-1
ii  python3-pyocr   0.8.5-2
ii  python3-xdg 0.28-2
ii  tesseract-ocr   5.3.4-1.1+b1

paperwork-gtk recommends no packages.

paperwork-gtk suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1068898: Tested Martin's installer on OpenRD client and it works.

[Martin Michlmayr]

* Martin Michlmayr  [2024-07-23 11:58]:
> > > I have successfully installed Debian 12.6 on my OpenRD "client"
> > > machine using Martin's installer.
> > 
> > Great news, thanks.
> 
> Can you apply the patch to the bookworm branch?  I'll update my web
> site when 12.7 comes out.

Anything else needed to apply this patch?

It seems it didn't make 12.7.
-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1079663: mypaint segfaults on aarch64

[Martin Renold]

"OMP_NUM_THREADS=1 mypaint" prevents the crash. Rebuilding libmypaint-1.5 
without --enable-openmp (in debian/rules) does the same.

Upstream issue (long thread) with fix: 
https://github.com/mypaint/mypaint/issues/1107#issuecomment-688556684

The fix modifies only mypaint, not libmypaint. The analysis in the thread 
explains perfectly why disabling openmp in libmypaint prevented the crash.

The fix is on the v2.0.x branch: 
https://github.com/mypaint/mypaint/commit/356716e7bacfcbb1f3ab80171fea405fdd10b2b9

I have applied the patch with 'quilt import' and rebuilt the mypaint package 
(after reverting all my previous changes). I can confirm that this also fixes 
the crash. (I have tested only for a minute.)

Bug#1080164: [INTL:sv] Swedish strings for prometheus-smokeping-prober debconf

[Martin Bagge / brother]

package: prometheus-smokeping-prober
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

--
brother
# Translation of prometheus-smokeping-prober debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the prometheus-smokeping-prober package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: prometheus-smokeping-prober\n"
"Report-Msgid-Bugs-To: prometheus-smokeping-pro...@packages.debian.org\n"
"POT-Creation-Date: 2021-02-03 15:43+0100\n"
"PO-Revision-Date: 2024-08-30 23:37+0200\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Enable additional network privileges for ICMP probing?"
msgstr "Ska ytterligare nätverkstillgång tillåtas för ICMP-förfrågningar?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"/usr/bin/prometheus-smokeping-prober requires the CAP_NET_RAW capability to "
"be able to send out crafted packets to targets for ICMP probing."
msgstr ""
"/usr/bin/prometheus-smokeping-prober kräver inställningen CAP_NET_RAW för "
"att kunna skicka speciellt framtagna paket för att göra förfrågningar över "
"ICMP."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"ICMP probing will not work unless this option is enabled, or prometheus-"
"smokeping-prober runs as root."
msgstr ""
"ICMP-förfrågningarna kommer inte fungera utan att detta alternativ har "
"aktiverats, så vida prometheus-smokeping-prober inte körs som root."

Bug#1080162: [INTL:sv] Swedish strings for prometheus-homeplug-exporter debconf

[Martin Bagge / brother]

package: prometheus-homeplug-exporter
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

--
brother
# Translation of prometheus-homeplug-exporter debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the prometheus-homeplug-exporter package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: prometheus-homeplug-exporter\n"
"Report-Msgid-Bugs-To: prometheus-homeplug-expor...@packages.debian.org\n"
"POT-Creation-Date: 2020-05-16 20:01+\n"
"PO-Revision-Date: 2024-08-30 23:30+0200\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Enable additional network privileges for PLC communication?"
msgstr "Ska ytterligare nätverkstillgång tillåtas för PLC-kommunikation?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"prometheus-homeplug-exporter requires CAP_NET_RAW capabilities to be able to "
"send out raw Ethernet packets to the HomePlug/PLC devices."
msgstr ""
"prometheus-homeplug-exporter kräver inställningen CAP_NET_RAW för att kunna "
"skicka rena ethernet-paket till HomePlug/PLC-enheter."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"prometheus-homeplug-exporter will not work at all unless this option is "
"enabled, or it runs as root."
msgstr ""
"prometheus-homeplug-exporter kommer inte fungera utan att detta alternativ "
"har aktiverats, så vida prometheus-homeplug-exporter inte körs som root."

Bug#1080163: [INTL:sv] Swedish strings for prometheus-nextcloud-exporter debconf

[Martin Bagge / brother]

package: prometheus-nextcloud-exporter
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

--
brother
# Translation of prometheus-nextcloud-exporter debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the prometheus-nextcloud-exporter package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: prometheus-nextcloud-exporter\n"
"Report-Msgid-Bugs-To: prometheus-nextcloud-expor...@packages.debian.org\n"
"POT-Creation-Date: 2021-04-04 13:41+0200\n"
"PO-Revision-Date: 2024-08-30 23:35+0200\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../templates:1001
msgid "URL to Nextcloud server:"
msgstr "Nextcloud server URL:"

#. Type: string
#. Description
#: ../templates:2001
msgid "Username for connecting to Nextcloud:"
msgstr "Användarnamn att ansluta med:"

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"This user needs admin privileges in order to have access to the metrics."
msgstr ""
"Denna användare behöver ha administrationsrättigheter för att komma åt "
"mätetal."

#. Type: password
#. Description
#: ../templates:3001
msgid "Password for connecting to Nextcloud:"
msgstr "Lösenord:"

#. Type: password
#. Description
#: ../templates:3001
msgid ""
"It's highly recommended to generate an application password without "
"filesystem access."
msgstr ""
"Det är starkt rekommenderat att skapa ett applikationslösenord som inte har "
"tillgång till filsystemet."

Bug#1080161: [INTL:sv] Swedish strings for prometheus-blackbox-exporter debconf

[Martin Bagge / brother]

package: prometheus-blackbox-exporter
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.

--
brother
# Translation of prometheus-blackbox-exporter debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the prometheus-blackbox-exporter package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: prometheus-blackbox-exporter\n"
"Report-Msgid-Bugs-To: prometheus-blackbox-expor...@packages.debian.org\n"
"POT-Creation-Date: 2021-01-24 16:54+0100\n"
"PO-Revision-Date: 2024-08-30 23:20+0200\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Enable additional network privileges for ICMP probing?"
msgstr "Ska ytterligare nätverkstillgång tillåtas för ICMP-förfrågningar?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"/usr/bin/prometheus-blackbox-exporter requires the CAP_NET_RAW capability to "
"be able to send out crafted packets to targets for ICMP probing."
msgstr ""
"/usr/bin/prometheus-blackbox-exporter kräver inställningen CAP_NET_RAW för "
"att kunna skicka speciellt framtagna paket för att göra förfrågningar över "
"ICMP."

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"ICMP probing will not work unless this option is enabled, or prometheus-"
"blackbox-exporter runs as root."
msgstr ""
"ICMP-förfrågningarna kommer inte fungera utan att detta alternativ har "
"aktiverats, så vida prometheus-blackbox-exporter inte körs som root."

Bug#1079663: mypaint segfaults on aarch64

[Martin Renold]

I can reproduce the crash on an AWS Graviton2 instance with X11 forwarding.
It doesn't crash if I build libmypaint and mypaint from upstram git on the same 
machine.
Will try to narrow it down later.

Bug#1078522: Use of uninitialized value $value in substitution (s///) at /usr/bin/apt-show-versions

[Christoph Martin]

Hi Peter,

maybe the output depends on the error at the end of your output. Try to 
put the key for anydesk.com in a file in /etc/apt/trusted.gpg.d/ .


If this does not help, please run

apt-show-versions -i -v

and look for the file which is parsed and produces these warnings.

Regards
Christoph

Am 11.08.24 um 22:49 schrieb Peter Allebone:


I do not know how to resolve this bug below :(


...

Fetched 134 MB in 14s (9,722 kB/s)
Use of uninitialized value $value in substitution (s///) at 
/usr/bin/apt-show-versions line 607,  line 1.
Use of uninitialized value $value in substitution (s///) at 
/usr/bin/apt-show-versions line 608,  line 1.

...

Use of uninitialized value $value in substitution (s///) at 
/usr/bin/apt-show-versions line 607,  line 121.
Use of uninitialized value $value in substitution (s///) at 
/usr/bin/apt-show-versions line 608,  line 121.

Reading package lists... Done
W: http://deb.anydesk.com/dists/all/InRelease 
: Key is stored in legacy 
trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section 
in apt-key(8) for details.

aragorn@Aragorn:~$


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1079688: openshot-qt: please migrate pyqt5 dependencies to pyqt6

[Martin-Éric Racine]

Package: openshot-qt
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

openshot-qt still depends on pyqt5 packages even though pyqt6 packages are 
already in Stable. It would be desirable to fix this so as to avoid pulling 
outdated QT packages.

Martin-Éric

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

Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
LSM: AppArmor: enabled

Versions of packages openshot-qt depends on:
pn  fonts-cantarell 
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
pn  libjs-jquery-ui 
ii  python3 3.12.5-1
pn  python3-openshot
ii  python3-pkg-resources   73.0.1-1
pn  python3-pyqt5   
pn  python3-pyqt5.qtsvg 
pn  python3-pyqt5.qtwebkit  
ii  python3-requests2.32.3+dfsg-1
pn  python3-zmq 

openshot-qt recommends no packages.

Versions of packages openshot-qt suggests:
pn  blender  
pn  inkscape 
pn  openshot-qt-doc  

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbMXSMACgkQrh+Cd8S0
17Y45RAAisvT6QfACiWf+JWLsltq4LGNcv8i3wsKx78ZhwDG/siV2BTWjywGJ5QY
e5kGmWRnjsVaPjONpQyTmkTHgtLCEUsxQXEFf6pHT3GOIr/eCqM7bcvGBAXTvy0J
B6qhaavX/+8P6uJ6y8sdGV6yzRwQp+S6bPQC8fcmd9APujrNdAKDCrUU6eGG9/Zb
pu2Gwdze4C0W99H5NtSHwiR8g3TcYDbYs7OomM+WRrHHbS1VHlQMTMJaIEgZ6DpV
jkPODEvpOU5ZY+DBmowa1gPhMMiATfl3e2P4syDMxpHU6AuQnpFyW5FzRC2yy0hm
5ezc+Jdv+SsTqPs18EdZEWpK2yHr8WcJC1C2eANHme7LmXtb6/45Rt13WK2wuim4
gdPO3q4adepuDiICdpxfCoSGRjw/QYjnLXfRO7CYes53V7uVZzTVYzNYmx/E7NUM
d8l99Dx7mKWUmg//DXw5x+lN5IyVt3InhJIZHnqHqsr3jnujomtM+suNPvz+I57s
kaQUyEWVnXEWJbpTTUE6IWXx+hQ49A9/aqRFtF+X9ECBzgdLqRKzL6Ribsef9isy
taURd7yGOMuV335bCfjK7keTLUBeDxNx7dq6Rp+tB8CDA7rPouc4aBwskSanmCkb
f2aJYPy9GDzns4/GK9jNeU2Of0xdw/Dr7WwAwcJ629R302nzeUo=
=gg6w
-END PGP SIGNATURE-

Bug#1065085: ug#1065085: Acknowledgement (ifupdown: ifup fails when using dhcpcd on network with stateful DHCPv6)

[Martin-Éric Racine]

On Fri, 01 Mar 2024 13:37:34 +0100 ktetzlaff  wrote:
> after running some more tests I'm attaching a patch which might be a
> proper fix for the issue. It comprises the following changes (in
> inet.defn, inet6.defn):

You don't need a separate inet6 line with dhcpcd. This will configure
both IPv6 and IPv4:

allow-hotplug eth0
iface eth0 inet dhcp

Martin-Éric

Bug#1079463: [INTL:sv] Swedish strings for s-nail debconf

[Martin Bagge / brother]

package: s-nail
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
# Translation of s-nail debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the s-nail package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: s-nail\n"
"Report-Msgid-Bugs-To: s-n...@packages.debian.org\n"
"POT-Creation-Date: 2018-09-17 19:46+0200\n"
"PO-Revision-Date: 2024-08-23 15:44+0200\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../s-nail.templates:1001
msgid "Should the dotlock helper be installed ‘setgid mail’?"
msgstr "Ska dotlock installeras med \"setgid mail\"?"

#. Type: boolean
#. Description
#: ../s-nail.templates:1001
msgid ""
"S-nail protects mbox files via fcntl(2) file-region locks during file "
"operations in order to avoid inconsistencies due to concurrent "
"modifications. By default system mbox files are also locked using "
"traditional dotlock files."
msgstr ""
"S-nail skyddar mbox-filer med fcntl(2)-baserade filregionlås vid "
"filoperationer för att undvika att filer hamnar ursync på grund av samtidiga "
"ändringar i filerna. Som standard skyddas även systemets mbox-filer med "
"vanliga dotlock-fil-lås."

#. Type: boolean
#. Description
#: ../s-nail.templates:1001
msgid ""
"On Debian system users normally lack the permissions to create files in the "
"directory containing the system mailboxes (/var/mail/). In this case a "
"dedicated privileged (setgid mail) dotlock helper is needed, however this "
"may be a security concern."
msgstr ""
"På vanliga Debian-system har användare inte tillåtelse att skapa filer i "
"sökvägen där mailbox-filerna är placerade (/var/mail/). I dessa fall behövs "
"en separat hjälpprocess för dotlock med förhöjda rättigheter (setgid mail), "
"detta kan dock öppna för andra säkethetsöverväganden."

Bug#1079464: [INTL:sv] Swedish strings for yggdrasil debconf

[Martin Bagge / brother]

package: yggdrasil
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
# Translation of yggdrasil debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the yggdrasil package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: yggdrasil\n"
"Report-Msgid-Bugs-To: yggdra...@packages.debian.org\n"
"POT-Creation-Date: 2023-11-03 17:15-0500\n"
"PO-Revision-Date: 2024-04-25 12:02+0200\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv sv sv \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../yggdrasil.templates:1001
msgid "Upgrade Yggdrasil to new network?"
msgstr "Ska Yggdrasil uppdateras till nytt nätverk?"

#. Type: boolean
#. Description
#: ../yggdrasil.templates:1001
msgid "Your currently-installed Yggdrasil is from a version older than 0.5."
msgstr ""
"Din nuvarande Yggdrasil-installation kommer från en version som är äldre än "
"0.5."

#. Type: boolean
#. Description
#: ../yggdrasil.templates:1001
msgid ""
"Yggdrasil 0.5 changed the on-the-wire network protocol, and it cannot "
"communicate with Yggdrasil versions older than 0.5.  If you continue, your "
"system will be unable to communicate with older Yggdrasil nodes. If you are "
"upgrading over a Yggdrasil connection, that is of particular importance."
msgstr ""
"Yggdrasil 0.5 ändrade nätverksprotokollet som går i tråden och kan inte "
"kommunicera med Yggdrasil-versioner som är äldre än 0.5. Om du fortsätter "
"med detta kommer systemet inte kunna kommuncera med Yggdrasil-noder av äldre "
"snitt. Detta är extra viktigt att känna till om du uppdaterar över en "
"Yggdrasil-anslutning."

Bug#1079461: [INTL:sv] Swedish strings for rpki-trust-anchors debconf

[Martin Bagge / brother]

package: rpki-trust-anchors
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
# Translation of rpki-trust-anchors debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the rpki-trust-anchors package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: rpki-trust-anchors\n"
"Report-Msgid-Bugs-To: rpki-trust-anch...@packages.debian.org\n"
"POT-Creation-Date: 2019-12-14 17:54+0100\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../rpki-trust-anchors.templates:1001
msgid "Do you accept the ARIN Relying Party Agreement (RPA)?"
msgstr "Accepterar du avtalet ARIN Relying Party Agreement (RPA)?"

#. Type: boolean
#. Description
#: ../rpki-trust-anchors.templates:1001
msgid ""
"ARIN forbids third parties from distributing the Trust Anchor Locator (TAL) "
"for their RPKI repository, hence this package can download it only if you "
"will agree to ARIN's conditions."
msgstr ""
"ARIN förbjuder tredjepart från att distribuera Trust Anchor Locator (TAL) "
"för deras RPKI-förråd, detta paket kommer alltså att hämta detta till dig "
"automtiskt om du går med på villkoren som ARIN ställer."

#. Type: boolean
#. Description
#: ../rpki-trust-anchors.templates:1001
msgid ""
"If you want that this package automatically download and installs the ARIN "
"TAL, then you need to accept the ARIN Relying Party Agreement (RPA): https://";
"www.arin.net/resources/manage/rpki/rpa.pdf ."
msgstr ""
"Vill du att paketet automatiskt ska hämta och installera ARIN TAL måste "
"avtalet ARIN Relying Party Agreement (RPA) accepteras. Läs mer på https://";
"www.arin.net/resources/manage/rpki/rpa.pdf."

Bug#1079462: [INTL:sv] Swedish strings for sash debconf

[Martin Bagge / brother]

package: sash
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother
# Translation of sash debconf template to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the sash package.
#
# Martin Bagge , 2024
msgid ""
msgstr ""
"Project-Id-Version: sash\n"
"Report-Msgid-Bugs-To: s...@packages.debian.org\n"
"POT-Creation-Date: 2017-07-16 19:14+0200\n"
"PO-Revision-Date: 2024-08-23 15:47+0200\n"
"Last-Translator: Martin Bagge / \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: error
#. Description
#: ../templates:1001
msgid "sashroot user detected"
msgstr "Hittade användaren sashroot"

#. Type: error
#. Description
#: ../templates:1001
msgid ""
"Previous versions of sash offered to create a root user with shell set to /"
"bin/sash.  This system has such a user."
msgstr ""
"I tidigare versioner av sash kunde en root-användare med skalet /bin/sash "
"skapas. Detta system har en sådan användare."

#. Type: error
#. Description
#: ../templates:1001
msgid ""
"This can unfortunately not be automatically removed together with the "
"package, so you need to manually delete the sashroot user."
msgstr ""
"Denna användare kan tyvärr inte raderas automatiskt tillsammans med paketet "
"utan behöver lösas manuellt genom att radera användaren sashroot."

Bug#1079150: cryptsetop: Waiting for encrypted source device

[Agustin Martin]

On Thu, Aug 22, 2024 at 10:50:44AM +0200, José Luis Segura Lucas wrote:
> Package: initramfs-tools
> Version: 0.144
> Followup-For: Bug #1079150
> 
> Sadly, it is unable to regenerate the initramfs properly due to a different
> problem related to the reiserfsprogs hook.
> 
> ```
> /etc/kernel/postinst.d/initramfs-tools:
> update-initramfs: Generating /boot/initrd.img-6.10.6-amd64
> cp: cannot stat '/var/tmp/mkinitramfs_zoQopR//usr/sbin/reiserfsck': Too many
> levels of symbolic links
> ln: failed to create symbolic link
> '/var/tmp/mkinitramfs_zoQopR/sbin/reiserfsck': File exists
> cp: cannot stat '/var/tmp/mkinitramfs_zoQopR//usr/sbin/reiserfsck': Too many
> levels of symbolic links
> E: /usr/share/initramfs-tools/hooks/reiserfsprogs failed with return 1.
> ```
> 
> After commenting out the line where the reiserfsprogs hook was trying to copy
> reiserfsck, I was able to generate a valid initramfs that allowed me to boot
> normally.

Same problem here, 

First found the waiting for device problem making boot fail. Booting from an
older kernel image succeeded, but when upgrading kernel package I found
exact above problem.

Downgrading to testing initramfs-tools seems to help building the image (not
yet rebooted). Created image has size similar to that of working image. Note
that the image causing the "waiting for device problem" was remarkably
smaller.

Regards,

-- 
Agustin

Bug#1079281: python-dbusmock: please push pristine-tar branch

[Martin Pitt]

Control: tag -1 pending

Hello Simon,

Simon McVittie [2024-08-22  9:17 +0100]:
> The pristine-tar branch is missing data for recent upstream releases.

Whoops, thanks for pointing out!

> Please consider using `gbp push` to push changes to all relevant branches.

That's not it -- my local pristine-tar doesn't have 0.31 and 0.32 either.
I usually use `gbp import-orig --uscan`, and it seems that just stopped
updating the pristine-tar branch at some point!?

I indeed see the same problem on other packages, like
https://salsa.debian.org/debian/cockpit-podman/-/tree/pristine-tar?ref_type=heads
where the last version is 82, but the last upstream version in master is 92.

It *is* present in cockpit.git, but there I have an explicit gbp.conf [1] with
`pristine-tar = True`. Apparently this used to be the default, and
git-buildpackage switched that some months ago?

[1] 
https://salsa.debian.org/utopia-team/cockpit/-/blob/master/debian/gbp.conf?ref_type=heads

So I used `gbp pristine-tar commit` to retroactively add the latest upstream
release, and added a gbp.conf:
https://salsa.debian.org/python-team/packages/python-dbusmock/-/commit/26a210933e5282c021effb3fd795a7f2bfefd7b3

So hopefully everything should be unblocked for you to work on the package.

I'll fix my other packages accordingly.

Thanks!

Bug#1079023: udisks2: please move btrfs dependencies from Suggests to Recommends

[Martin-Éric Racine]

Package: udisks2
Version: 2.10.1-10
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Given how widespread btrfs usage has become over the years, it would be 
desirable for udisks2 to support it out of the box, rather than optionally. 
This would require moving btrfs dependencies from Suggests to Recommends.

Martin-Éric

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 6.10.4-686-pae (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages udisks2 depends on:
ii  dbus   1.14.10-4+b1
ii  libacl12.3.2-2
ii  libatasmart4   0.19-5+b1
ii  libblkid1  2.40.2-1
ii  libblockdev-crypto33.1.1-1
ii  libblockdev-fs33.1.1-1
ii  libblockdev-loop3  3.1.1-1
ii  libblockdev-mdraid33.1.1-1
ii  libblockdev-nvme3  3.1.1-1
ii  libblockdev-part3  3.1.1-1
ii  libblockdev-swap3  3.1.1-1
ii  libblockdev-utils3 3.1.1-1
ii  libblockdev3   3.1.1-1
ii  libc6  2.39-6
ii  libglib2.0-0t642.81.1-3
ii  libgudev-1.0-0 238-5
ii  libmount1  2.40.2-1
ii  libpolkit-agent-1-0125-2
ii  libpolkit-gobject-1-0  125-2
ii  libsystemd0256.4-3
ii  libudisks2-0   2.10.1-10
ii  libuuid1   2.40.2-1
ii  parted 3.6-4
ii  udev   256.4-3

Versions of packages udisks2 recommends:
ii  dosfstools  4.2-1.1
ii  e2fsprogs   1.47.1-1
ii  eject   2.40.2-1
ii  exfatprogs  1.2.4-1
ii  libpam-systemd  256.4-3
ii  ntfs-3g 1:2022.10.3-3
ii  polkitd 125-2

Versions of packages udisks2 suggests:
ii  btrfs-progs6.6.3-1.2+b1
pn  f2fs-tools 
pn  mdadm  
pn  nilfs-tools
pn  reiserfsprogs  
pn  udftools   
ii  udisks2-btrfs  2.10.1-10
pn  udisks2-lvm2   
pn  xfsprogs   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbCy2YACgkQrh+Cd8S0
17aimxAAkOOehRD7Uwj+HOkLqp7ZW64J/XzBilznkjfHPZs79a/YRJZ+hNZRCRRt
HBTtliP0Gk5fGf4ErMUfjTwpYTUyr3xux/wLe3yyOhgeSTEgnoQzyaaPJx80Zevh
NdzbeyUIxk6EYFaBtgoqa6OzZqPwLiWdu75Uleg8BgdOwA73ADz+kNWGKpFbPVaW
YSrv00auEDXS2l/gUj3DaF32vTBb6/IX6jk1ScRlhQv8WBkcsZO5II63P2UqsTRz
urX8zCg66qpyLdtomagDmwiSYuyJ1/YTJUgOMV+mqZb/XH8eZGfpMc8ZnSs8bzfE
KegRXEcu2OmTi+p0q1mXvP91xiSc2SnDqtsbesLuUU6Ck66v0he6bPtiLlgE6a1J
ZTtDL8wdf4BYJGXz9iOQmb8Ob79IgaXzU0Fsw1oExCYDEYH2dWZ7TaYFz/5+b6S8
H92ZkhIYL7GrGG8uZXc91FHqszHZ9fapSDDrX0t3fbqW8lmydrZBi3fZYJ49NrR+
2W+iYJIiWVhqam9JE+nhstYDEvT6udlHoxA53uym3InC3Ys1azoZmGzumxf4P+Ub
gqi6lD7u4VWcZiLc2zMA3EkWLn2T9sEGsrYXKCanzl/DW6aaW2SmEwPC4NXdZXyT
B7Yi3cfvyr/GUerovMoQdmisVxdXInV/aToDLeiQ40cbprSPS9o=
=r/84
-END PGP SIGNATURE-

Bug#1078959: golang-golang-x-text: Please provide a backport

[Martin Dosch]

Source: golang-golang-x-text
Version: 0.7.0-1
Severity: wishlist

Dear Maintainer,

the latest version of xmpp-dns requires golang-golang-x-net-dev >= 
0.22.0 to build. I'd like to continue to provide current xmpp-dns
versions in bookworm-backports and therefore require a backport of
golang-golang-x-net-dev.
To backport golang-golang-x-net-dev it is required to also update
golang-golang-x-text-dev in backports.

I would highly appreciate if you could backport the latest version to   
bookworm-backports.

Best regards,    
Martin   

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

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


signature.asc
Description: PGP signature

Bug#1078958: golang-golang-x-term: Please provide a backport.

[Martin Dosch]

Source: golang-golang-x-term
Version: 0.3.0-1
Severity: wishlist

Dear Maintainer,

the latest version of xmpp-dns requires golang-golang-x-net-dev >= 
0.22.0 to build. I'd like to continue to provide current xmpp-dns
versions in bookworm-backports and therefore require a backport of
golang-golang-x-net-dev.
To backport golang-golang-x-net-dev it is required to also update
golang-golang-x-term-dev in backports.

I would highly appreciate if you could backport the latest version to   
bookworm-backports.

Best regards,    
Martin

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

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


signature.asc
Description: PGP signature

Bug#1078957: golang-golang-x-sys: Please provide an backport.

[Martin Dosch]

Source: golang-golang-x-sys
Version: 0.3.0-1
Severity: wishlist

Dear Maintainer,

the latest version of xmpp-dns requires golang-golang-x-net-dev >= 
0.22.0 to build. I'd like to continue to provide current xmpp-dns 
versions in bookworm-backports and therefore require a backport of 
golang-golang-x-net-dev.
To backport golang-golang-x-net-dev it is required to also update 
golang-golang-x-sys-dev in backports.

I would highly appreciate if you could backport the latest version to 
bookworm-backports.

Best regards,
Martin

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

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


signature.asc
Description: PGP signature

Bug#1078924: hostapd: please package new upstream 2.11

[Martin-Éric Racine]

la 17. elok. 2024 klo 22.47 Andrej Shadura (and...@shadura.me) kirjoitti:
> On Sat, 17 Aug 2024, at 21:42, Martin-Éric Racine wrote:
> > Upstream recently produced release 2.11, as per
> > <https://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog>:
>
> Thanks, I have noticed this myself a week ago. Some users reported 
> regressions, I want this new release to brew a little bit elsewhere before 
> uploading it :) Or maybe I can do experimental ~now and then see how it goes.

Pushing to experimental could work. It wouldn't disturb unstable/testing.

Martin-Éric

Bug#1078925: hostapd: please add hostapd.conf.5

[Martin-Éric Racine]

Package: hostapd
Version: 2:2.10-12+deb12u2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

OpenBSD apparently got around producing a manual page for hostapd.conf.5 which 
would be nice to add to the Debian package.

It however comes with a caveat: OpenBSD apparently implemented an include 
option that doesn't exist upstream e.g.

include "/etc/hostapd.conf.local"

Which would also be nice to implement in the Debian package.

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

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

Versions of packages hostapd depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u7
ii  libnl-3-200  3.7.0-0.2+b1
ii  libnl-genl-3-200 3.7.0-0.2+b1
ii  libnl-route-3-2003.7.0-0.2+b1
ii  libssl3  3.0.13-1~deb12u1

hostapd recommends no packages.

hostapd suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbA/tsACgkQrh+Cd8S0
17bDWBAAqE/vCdY/zJTWXbp+opKfvdChyVu8aZWFRJLWVJussLg633205H6UWc2R
Xhlci4d1b7/mTCuquBTyMswpbTRrSQIsFxti4lZly+Bskfj4ROcYmIUSqtzp+qw8
mYUeNILa3aEGFXQMFnvJIjQ6RFura9fEf3BJa2QxfjdIU3OAzIFxKPl/q3hOF/Bh
YBgXXVjP62lzHfq97tf/f9aSGOsDdh4oNfhtmlBIsymfrkPUUQhi8TeyYJleKnNw
qqDmbv7hD/MpozAorFW5nwkLWWa1DIopQDIrd0LDCRidYWGTPoYsFbjPg5rsuERS
PpHdVM+jtX3mhBeSd70bgwjfx64OK0nON3mnTG2Plft6lZFUtlCoCPDBOMs6rKkH
T6yYrioejUB26z290FLURDEM4zGZWJn4t9wCGx95mZdkw8DdhZGT3TUdkcYOWYpK
QCJ1DOSBfaXpIzRykP++t7rry/GEw4J+SzJpDMq7pl68F1caEJMLh/+l47WePuKF
vzlpw9OIOhQa/u9HhUvmlMs7Web5MQV9fSTc9/2RvvnCStZIvkmve3se55YvFheX
0s/TBfnCBnZ/Fij1kcaQCzwqIqOnAJZdoBP9lgPeiVXnjZW2ohRol/gw0oKkwZ6r
WorMmX+HgTYRfE+oXC9Ldql1XOpftd7BsRVovftNPYjGMah2988=
=7d9O
-END PGP SIGNATURE-

Bug#1078924: hostapd: please package new upstream 2.11

[Martin-Éric Racine]

Package: hostapd
Version: 2:2.10-12+deb12u2
Severity: normal
X-Debbugs-Cc: t...@security.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream recently produced release 2.11, as per 
:

ChangeLog for wpa_supplicant

2024-07-20 - v2.11
* Wi-Fi Easy Connect
  - add support for DPP release 3
  - allow Configurator parameters to be provided during config exchange
* MACsec
  - add support for GCM-AES-256 cipher suite
  - remove incorrect EAP Session-Id length constraint
  - add hardware offload support for additional drivers
* HE/IEEE 802.11ax/Wi-Fi 6
  - support BSS color updates
  - various fixes
* EHT/IEEE 802.11be/Wi-Fi 7
  - add preliminary support
* support OpenSSL 3.0 API changes
* improve EAP-TLS support for TLSv1.3
* EAP-SIM/AKA: support IMSI privacy
* improve mitigation against DoS attacks when PMF is used
* improve 4-way handshake operations
  - discard unencrypted EAPOL frames in additional cases
  - use Secure=1 in message 2 during PTK rekeying
* OCV: do not check Frequency Segment 1 Channel Number for 160 MHz cases
  to avoid interoperability issues
* support new SAE AKM suites with variable length keys
* support new AKM for 802.1X/EAP with SHA384
* improve cross-AKM roaming with driver-based SME/BSS selection
* PASN
  - extend support for secure ranging
  - allow PASN implementation to be used with external programs for
Wi-Fi Aware
* FT: Use SHA256 to derive PMKID for AKM 00-0F-AC:3 (FT-EAP)
  - this is based on additional details being added in the IEEE 802.11
standard
  - the new implementation is not backwards compatible, but PMKSA
caching with FT-EAP was, and still is, disabled by default
* support a pregenerated MAC (mac_addr=3) as an alternative mechanism
  for using per-network random MAC addresses
* EAP-PEAP: require Phase 2 authentication by default (phase2_auth=1)
  to improve security for still unfortunately common invalid
  configurations that do not set ca_cert
* extend SCS support for QoS Characteristics
* extend MSCS support
* support unsynchronized service discovery (USD)
* add support for explicit SSID protection in 4-way handshake
  (a mitigation for CVE-2023-52424; disabled by default for now, can be
  enabled with ssid_protection=1)
  - in addition, verify SSID after key setup when beacon protection is
used
* fix SAE H2E rejected groups validation to avoid downgrade attacks
* a large number of other fixes, cleanup, and extensions

2022-01-16 - v2.10

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

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

Versions of packages hostapd depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u7
ii  libnl-3-200  3.7.0-0.2+b1
ii  libnl-genl-3-200 3.7.0-0.2+b1
ii  libnl-route-3-2003.7.0-0.2+b1
ii  libssl3  3.0.13-1~deb12u1

hostapd recommends no packages.

hostapd suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmbA/T8ACgkQrh+Cd8S0
17YQVg//XqMLT4aNKoAYX8gCasy1N1jslOKSj3DXEwGpGLDdNbb4O+j0pG3tDBl0
BYgdWDeUA75gDlTWCziinxag91Gmft5+t6yv1airdaU1+LKzIfUFJeJs6rGH4hJ5
qefwW3g9fs45k179ECoeYNl8RBPzdObLMEVfzYghFzYIiY4KJyo4bR7ZQrQzAfb2
oizoBajNaoXWhHLxMv8h8RXc2jq4YvHvFa+ZHjPuEBqaMdhyfNmibkcPeHJVQyal
mAPha6eEZgzWcUYcb262Y2oPq73hvCteUejhWdk+Cir7eTNKvsOCXDaPcmrzeq13
VdL5TOaX7mSj++eLCnZMhUMlsuzjXjnvOFZfEzDeoK1iGxc0V10pP2t71TnJfeU4
DwHPa+UyahEleXIEbYWSoG6yrp7SUOiyzAerJCKj41bNUP28FuA2Lpt9QtHmngsY
l7dMv5QlH3qH0Ofv0Yse6iNMpI23kYk0bEiVKibnL26wFhWDKWNTcxiFW45ah3be
NnP5DELCYgoTVoXpzxde3sdEk+nBwXRfiGatkSvmXkRcfdy/3F46EuIyM8zYN2WK
0Uh+ZucuZauqbM8/fiZYy+M61PVK8T5bYlKqhdBSumOnT4eIr7F210MsPuIl//u0
7m00u35iyE8//vGUDC7r0V+jP5u4QdQGAXh9yJ4piaSRTrOPjSo=
=bVWi
-END PGP SIGNATURE-

Bug#1078869: golang-golang-x-net: Please provide a backport for bookworm

[Martin Dosch]

Source: golang-golang-x-net
Version: 1:0.7.0+dfsg-1
Severity: wishlist

Dear Maintainer,

the next version of xmpp-dns, which I plan to release in the next days, 
will depend on golang-golang-x-net-dev >= 0.22.0. [xmpp-dns]

Before I provided the latest xmpp-dns releases in bookworm-backport and 
to be able to continue so I'd require a backported version of 
golang-golang-x-net-dev.

Best regards,
Martin

[xmpp-dns]: 
https://salsa.debian.org/go-team/packages/xmpp-dns/-/blob/debian/sid/debian/control?ref_type=heads#L12

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

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


signature.asc
Description: PGP signature

Bug#1078756: lintian-brush is not updated for 3.12

[Martin-Éric Racine]

la 17. elok. 2024 klo 0.56 Chris Hofstaedtler (z...@debian.org) kirjoitti:
>
> * Martin-Éric Racine  [240816 18:49]:
> > On Thu, 15 Aug 2024 15:17:53 +0200 Chris Hofstaedtler  
> > wrote:
> > > lintian-brush is built against python3.11. Thus all fixers etc fail,
> > > because the 3.11 modules are already gone.
> >
> > Could at least some of these 4 bugs be fixed by triggering a bin-NMU
> > rebuild to at least get rid of python3.11 dependencies?
>
> https://buildd.debian.org/status/package.php?p=lintian-brush
>
> Doesn't look like a rebuild would help.

Meanwhile:

https://qa.debian.org/cgi-bin/vcswatch?package=lintian-brush

It seems that at least some of it was already fixed, but is pending a release.

Martin-Éric

Bug#1078756: lintian-brush is not updated for 3.12

[Martin-Éric Racine]

On Thu, 15 Aug 2024 15:17:53 +0200 Chris Hofstaedtler  wrote:
> Package: lintian-brush
> Version: 0.157
> Severity: serious
>
> lintian-brush is built against python3.11. Thus all fixers etc fail,
> because the 3.11 modules are already gone.
>
> Gonna merge a few bugs into this one.

Could at least some of these 4 bugs be fixed by triggering a bin-NMU
rebuild to at least get rid of python3.11 dependencies?

Martin-Éric

Bug#1078796: ITP: meta-exwm -- Full EXWM Desktop Environment, with extra components

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: meta-exwm
  Version : none
  Upstream Author : Debian
* URL or Web page : https://salsa.debian.org/emacsen-team/meta-exwm/
* License : GPL3+
  Programming lang: none
  Description : Full EXWM Desktop Environment, with extra components

This will be a meta-package with dependencies to elpa-discomfort,
elpa-ednc, elpa-exwm, elpa-exwm-mff, elpa-xdg-appmenu, and probably
more. The binary package name will be just "exwm".

Bug#1078755: python3-fastbencode: failed to load compiled extension: No module named 'fastbencode._bencode_pyx'

[Martin-Éric Racine]

Package: python3-fastbencode
Version: 0.2-1+b2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

One of lintian-brush scripts produces the following warning:

/usr/lib/python3/dist-packages/fastbencode/__init__.py:52: UserWarning: failed 
to load compiled extension: No module named 'fastbencode._bencode_pyx'

Feel free to reassign as appropriate.

Martin-Éric

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

Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-fastbencode depends on:
ii  libc62.39-7
ii  python3  3.12.5-1

python3-fastbencode recommends no packages.

python3-fastbencode suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAma99t8ACgkQrh+Cd8S0
17ZaNBAAmpfp28PGUR1ybOBq6bAs2Ne9tWVVkSNi/nO/iBJxGn2vo6PolpvrZDgf
qut7rOy9gdN+O6Gg6jA0Y3IWwc8hX4itRU8aKNQbNveYt7lPWpvMTMd7WymwP2bY
aKzxyytDFH309nUwOQC4Bf8Eo88piOoSD8IMWhGttChKrZnTQJlW9KMfHhk24SIe
7ae0cay3Zz84vOq7mOakduZ7Yf4EIuuQYQz2neiN0fCIHsv1nVHTeNkjx96P9NPM
U6vRu+mZ0eC3RV9KRChwzSHzwnGeF467RekpwAXj1x9s5O9iEwf/fDFGX5pkR6fh
LPLenI6B1vOQJBrwZbw1sAoMSjay6nklCh+H96R95R8NyafZVtnJgk1XqfwPKIq+
pf1krmi+YXIeonU050P7K8LZXvAs5MPyAhlLIehNhzvcIEL4Q+1glH23kXHXoIi9
I0LmDSFAu/DDaqFPKhQiZPeRLjXAo+la8oDfXuG1eFPQx82BOgWaCy6OI+X9bdew
4i+sVI6beaJ0qok0eaesb9LOUZP/t0dzNTWvxmO8MMzOll0BDvJNXu5wllAmNFs7
DyOmga2ToqdRG3/F5IK1DtzxiMKmJW0qALL9uzhIHlGTTrG8WGIg+T63lMpniD42
Ck0meY19kQFoaH7SZB4ZSwF7vuQf8knHlO5ImSFcCPFlJw74k1s=
=S8Jn
-END PGP SIGNATURE-

Bug#1078754: ModuleNotFoundError: No module named 'psycopg2._psycopg'

[Martin-Éric Racine]

Package: python3-psycopg2
Version: 2.9.9-1+b2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

One of the lintian-brush scripts fails with the following error:

Script failed: /usr/share/lintian-brush/fixers/initial-upload-closes-no-bugs.py 
(exit code 1) (stderr:
Traceback (most recent call last):
  File "/usr/share/lintian-brush/fixers/initial-upload-closes-no-bugs.py", line 
25, in 
wnpp_bugs = find_wnpp_bugs(editor.changelog[-1].package)

  File "/usr/lib/python3/dist-packages/lintian_brush/debbugs.py", line 77, in 
find_wnpp_bugs
conn = connect_udd_mirror()
   
  File "/usr/lib/python3/dist-packages/lintian_brush/udd.py", line 31, in 
connect_udd_mirror
import psycopg2
  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 51, in 

from psycopg2._psycopg import ( # noqa
ModuleNotFoundError: No module named 'psycopg2._psycopg'
)

Feel free to reassign as appropriate.

Martin-Éric

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

Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-psycopg2 depends on:
ii  libc62.39-7
ii  libpq5   16.4-1
ii  python3  3.12.5-1

python3-psycopg2 recommends no packages.

Versions of packages python3-psycopg2 suggests:
pn  python-psycopg2-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAma99jAACgkQrh+Cd8S0
17bFCA/+KmBbWaEV+tlFaeOT2uZxiWXp/Pzhzw7uCobnoLFEwHfgQDy2jUSbNWAY
1p3hJvVl4PmMyqe/3Gh8K6vZ1Nbwpwh0fqqUrVpEp+Dwj6czVR/3Sz+itP+jTCZy
Lfrs9ZKkF3vdF6Sh2TgXTR/0IskNfKJw1Kcz09vZq0TGMgIm2TU7oIxhWRJtZj6a
3yRpcfJM+csNhU5DCauX68eUCkRk4e56JCZSXCuoWFkGo1T/V72e2RBcXNnHXZVQ
Q61DfQzgGKZM+TuvTue+s2U/8RxrnN5KN0jQAeFNIRgVGnrj/ZXISQn3mgAVvjWe
EaX6bYHfiYpJA2fBBqoiwQJ2+EDOPZBk55XaKhjwBdm06ap5FoHBjzBt0lb3ug6n
8kgGCC4gHjVHsyF7m8UaH7NjWl/XPEjBiS4lDWMoCvdhPnVEPlD71Ev+oPnPRIFt
ZITJz1W/Ias1wfcl5w1B4aJQ6qMC66fvAeTxD9DS5ZUrTYs29nhdGlP8k9VSeeI3
QYsAPe94rOksiOmvfb64i2lAB8P47482fMCMlOfuTb54WedfaLgrb+AcpChBZihT
etVP5/gipclxpQajdeKYzQz3GdbyFQxr4Xa75A8Emw+a0eDwJ7IkC2tXZ3ah6d5D
bIPSfA8FaXUHN+lILEHChx2gXnAqQ1mT74UpVfBkhCY6caoN1Fo=
=3CG2
-END PGP SIGNATURE-

Bug#1078753: ImportError: cannot import name '_upstream_ontologist'

[Martin-Éric Racine]

Package: python3-upstream-ontologist
Version: 0.1.37-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

One of lintian-brush's scripts fails with the following error:

Fixer vcs-broken-uri failed to run.
Script failed: /usr/share/lintian-brush/fixers/vcs-broken-uri.py (exit code 1) 
(stderr:
Traceback (most recent call last):
  File "/usr/share/lintian-brush/fixers/vcs-broken-uri.py", line 4, in 
from lintian_brush.vcs import fixup_broken_git_url
  File "/usr/lib/python3/dist-packages/lintian_brush/vcs.py", line 33, in 

from upstream_ontologist.vcs import (
  File "/usr/lib/python3/dist-packages/upstream_ontologist/__init__.py", line 
62, in 
from . import _upstream_ontologist
ImportError: cannot import name '_upstream_ontologist' from partially 
initialized module 'upstream_ontologist' (most likely due to a circular import) 
(/usr/lib/python3/dist-packages/u>
)

Feel free to reassign as appropriate.

Martin-Éric

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

Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-upstream-ontologist depends on:
ii  libbz2-1.0   1.0.8-5.1
ii  libc62.39-7
ii  libcurl3t64-gnutls   8.9.1-2
ii  libgcc-s114.2.0-2
ii  libgit2-1.7  1.7.2+ds-1+b2
ii  libssh2-1t64 1.11.0-7
ii  libssl3t64   3.3.1-6
ii  python3  3.12.5-1
ii  python3-breezy   3.3.6-1+b2
ii  python3-debian   0.1.49
ii  python3-debmutate0.68
ii  python3-ruamel.yaml  0.18.6+ds-3
ii  zlib1g   1:1.3.dfsg+really1.3.1-1

Versions of packages python3-upstream-ontologist recommends:
ii  perl-doc 5.38.2-5
ii  python3-bs4  4.12.3-1
ii  python3-distro-info  1.7
ii  python3-docutils 0.21.2+dfsg-2
ii  python3-dulwich  0.21.6-1+b2
ii  python3-lxml 5.2.2-2
ii  python3-markdown 3.6-1
ii  python3-setuptools   70.3.0-2
ii  python3-toml 0.10.2-1
ii  python3-tomlkit  0.13.0-1

python3-upstream-ontologist suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIyBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAma99YwACgkQrh+Cd8S0
17aPlw/1FlEvVSc8Hod78lPG0pJ5XdYEqfY+Si9ffMEb3W6JZtgunRjqINvBcZqR
gdVxJPP5yB6af6IBNyVRyKD8pxNYMPHv6KwcAq5UVU4IlD6sjJno74YlrXB4QgT+
nVYm+pEzWb9wYz+GUp8BGkMFxFBH1Wy4bNi2+Tz0eumtTzsnKB/E51i06yf7Ps4e
BFtNSJgkfMVB3szLKUydk/Ic2g3kbfRSTP8qQL3DBqUFdjMyXJY1Hc1dgdAeaFh8
akeHBMiHdg2+SOfcATfvqTnuYHY0rUo1JHWhomZWLezoTmqtfX1DjuJWhJwMdRdG
BeNIq9KcXjOcnW3iIZMDh3VMbvD4aItlSIPRe5dxGvO3e1CWxVFsqWKNVKBeJMHa
PduPo9IZifq9dUKIC4qB5WSAG6MJWCrxLB2sE10tXR/1X/OWe18BtcXWyeG2ZOGv
5crYtQhizEkXFCgziy//+bCXKtQgc5Y4gILkYqEzbYO4puLiVxRPchkMwKH+jqcy
hnmfYesW1yvFbtTBYASdGyKfz9m7RziwLwMJJzmkT3X8VzdLEFXdvNjylZmN8SQj
MJrZt+wcH2tdP+Q1ErhDzTszByv/p2gp2O6Lxg+evAE+hpForyj4MaDNlz/TcHkc
LWRXlY+5LYPuIZmPu8G4wcz2oxbgqFLVNY5ZU0MRCoD9g3v6sw==
=YVPe
-END PGP SIGNATURE-

Bug#1078752: ModuleNotFoundError: No module named 'pcre2.methods'

[Martin-Éric Racine]

Package: python3-pcre2
Version: 0.3.0+ds-1+b2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

lintian-brush fails for some scripts with the following error:

Fixer debian-watch-file-uses-github-releases failed to run.
Script failed: 
/usr/share/lintian-brush/fixers/debian-watch-file-uses-github-releases.py (exit 
code 1) (stderr:
Traceback (most recent call last):
  File 
"/usr/share/lintian-brush/fixers/debian-watch-file-uses-github-releases.py", 
line 3, in 
from debmutate.watch import WatchEditor
  File "/usr/lib/python3/dist-packages/debmutate/watch.py", line 27, in 
import pcre2
  File "/usr/lib/python3/dist-packages/pcre2/__init__.py", line 1, in 
from .methods import compile, findall, match, scan, split, substitute
ModuleNotFoundError: No module named 'pcre2.methods'
)

Feel free to reassign as appropriate.

Martin-Éric

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

Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-pcre2 depends on:
ii  libc6 2.39-7
ii  libpcre2-8-0  10.42-4+b1
ii  python3   3.12.5-1

python3-pcre2 recommends no packages.

python3-pcre2 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAma99PgACgkQrh+Cd8S0
17Z5LhAAkgRVryUiw63MsX9wWV+srvjprFjGuj8the/O92tzZ+nJnF/rkK8Wgr6v
VMGthafduXtxQ+MJue/KbxKCdnpTnHMnOIN2HEz18exAaVHBtqumTM+AScIAn576
8ClGyqtyzGrQCNaPkPvsNDzV/x++IFhmYEUFzSo7dUQLfUXEWXWyV/STpl4lsddU
4PncmhYPneb2AzJKtTdDYUDSvzfLyZeefxqH7yA+FjkmcfykV/6Wb8dMEHndOsMF
uB/NJdzB9ptocFljWnRFP8SMjkd1smIPmn/58irbw1thFwps9A04YSu/eXFjaHu1
Oiio+sdD6cGf2/gXkIicDKiOYI15LWXrchSIQ8lC1e4tTWt9bTenLyV3mM/cF19H
OZ5rC5X7Okr8iCeHZsXPbnPG/hCjodlyeGmmjpoLIrCsY25hrU3WDHDalx4PswaK
+qYp/jd5IL2/zuMybqz+CAuY0Z77OUnhZxDVw67lwOTE1MMrmwRBVgv6S2lQUljx
S2lgxDiM/O6NSPSYe0BResjrQdGX3leR3/pOfaggJgJYQOtPPuLCmyHsFObf2MQS
USGGKDQQaKxcs1cYqyOkSZNZWeXSTk0RvyYnk0n91s+uCgWF5DpbTSxxpY//edUq
3Qozxi1V05lovGHdKyqIegm2YA7ngCvq9Ow6wbzon0oAccQmFzA=
=j6gj
-END PGP SIGNATURE-

Bug#1078656: grub-pc: please use 'grub-install --disk-module=native /dev/sdX'

[Martin-Éric Racine]

Actually, it turns out that even installing this isn't practical on
anything else than media with a GTP partition. It won't fit into the
start of a DOS partition, whereas GTP always leaves plenty of empty
space at the start.

If there's any way to enable this for one specific menu entry, you're
welcome to propose a fix to my recipe.

Martin-Éric

ke 14. elok. 2024 klo 10.17 Mate Kukri (mate.ku...@canonical.com) kirjoitti:
>
> Finding external USB disks does not in fact require "nativedisk".
>
> GRUB can boot off USB disks if the firmware supports booting off USB
> disks, which I suspect isn't the case on your machine.
>
> GRUB's nativedisk driver is designed for use cases such as "GRUB as a
> coreboot payload" where firmware disk drivers are simply not
> available.
>
> It shouldn't be used with traditional firmware as it was never widely
> deployed in such a manner and may have compatibility issues, and such
> definitely not be the default in Debian.
>
> You are always able to enable them as a workaround on your incompatible 
> machine.
>
> On Tue, Aug 13, 2024 at 9:06 PM Martin-Éric Racine
>  wrote:
> >
> > Package: grub-pc
> > Version: 2.06-13+deb12u1
> > Severity: normal
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > I've been trying to implement a chainloader (see below at 
> > /etc/grub.d/40_custom) to boot off external USB disks as needed. Finding 
> > external disks requires using GRUB's 'nativedisk', but once that has been 
> > executed, the rest of the script cannot be completed because Debian's 
> > grub-install enforces BIOS device names (hd0,msdos1) instead of bus names 
> > (ata0,msdos1). Further investigating this suggests that if Debian used 
> > 'grub-install --disk-module=native /dev/sdX' to install GRUB, this would 
> > work as expected.
> >
> > Alternately, if there's any /etc/default/grub variable I can set to 
> > accomplish this, it would suit me just as well.
> >
> > Thanks!
> > Martin-Éric
> >
> > - -- Package-specific info:
> >
> > *** BEGIN /proc/mounts
> > /dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
> > *** END /proc/mounts
> >
> > *** BEGIN /boot/grub/device.map
> > (hd0)   /dev/disk/by-id/ata-ST320011A_3HT48T7R
> > *** END /boot/grub/device.map
> >
> > *** BEGIN /boot/grub/grub.cfg
> > #
> > # DO NOT EDIT THIS FILE
> > #
> > # It is automatically generated by grub-mkconfig using templates
> > # from /etc/grub.d and settings from /etc/default/grub
> > #
> >
> > ### BEGIN /etc/grub.d/00_header ###
> > if [ -s $prefix/grubenv ]; then
> >   set have_grubenv=true
> >   load_env
> > fi
> > if [ "${next_entry}" ] ; then
> >set default="${next_entry}"
> >set next_entry=
> >save_env next_entry
> >set boot_once=true
> > else
> >set default="0"
> > fi
> >
> > if [ x"${feature_menuentry_id}" = xy ]; then
> >   menuentry_id_option="--id"
> > else
> >   menuentry_id_option=""
> > fi
> >
> > export menuentry_id_option
> >
> > if [ "${prev_saved_entry}" ]; then
> >   set saved_entry="${prev_saved_entry}"
> >   save_env saved_entry
> >   set prev_saved_entry=
> >   save_env prev_saved_entry
> >   set boot_once=true
> > fi
> >
> > function savedefault {
> >   if [ -z "${boot_once}" ]; then
> > saved_entry="${chosen}"
> > save_env saved_entry
> >   fi
> > }
> > function load_video {
> >   if [ x$feature_all_video_module = xy ]; then
> > insmod all_video
> >   else
> > insmod efi_gop
> > insmod efi_uga
> > insmod ieee1275_fb
> > insmod vbe
> > insmod vga
> > insmod video_bochs
> > insmod video_cirrus
> >   fi
> > }
> >
> > if [ x$feature_default_font_path = xy ] ; then
> >font=unicode
> > else
> > insmod part_msdos
> > insmod ext2
> > set root='hd0,msdos1'
> > if [ x$feature_platform_search_hint = xy ]; then
> >   search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
> > --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
> > cc540c15-0f8a-4933-88de-5516da7b3414
> > else
> >   search --no-floppy --fs

Bug#1078656: grub-pc: please use 'grub-install --disk-module=native /dev/sdX'

[Martin-Éric Racine]

ke 14. elok. 2024 klo 1.08 Pascal Hambourg (pas...@plouf.fr.eu.org) kirjoitti:
>
> On 13/08/2024 at 22:02, Martin-Éric Racine wrote:
> >
> > I've been trying to implement a chainloader (see below at
> > /etc/grub.d/40_custom) to boot off external USB disks as needed.
> > Finding external disks requires using GRUB's 'nativedisk'
>
> Only with flawed BIOS which cannot boot from USB or do not expose all
> drives. I observed that some BIOS expose only a USB drive when booting
> from it, but others expose all USB drives regardless of the boot device.

This BIOS only shows fd0 and hd0, when I type 'ls' on GRUB's command line...

> > Further investigating this suggests that if Debian used 'grub-install
> > --disk-module=native /dev/sdX' to install GRUB, this would work as
> > expected.
>
> Native disk drivers do not work properly on all machines, so they cannot
> be enabled by default for a rare use case.

... however, typing 'nativedisk' suddenly finds the CD and USB drives,
except that it uses a different naming strategy.

> > menuentry "USB chainloader" {
> >   insmod part_msdos
> >   insmod ext2
> >   insmod fat
> >   insmod iso9660
>
> Why do you load these modules ? Chainloading a disk boot sector does not
> require to read any partition table nor filesystem.
> Instead you should load the "chain" module which provides the
> "chainloader" command.
>
> >   nativedisk
> >   set root='ata0,msdos1'
> >   chainloader (usb0)+1
> > }
>
> Why do you set $root to an internal disk partition if you intend to
> chainload a USB drive ? Did you mean to set $prefix so that GRUB can
> find its directory and modules after switching to native disk drivers ?

You're welcome to suggest a better recipe.

Martin-Éric

Bug#1078659: ITP: emacs-eat -- Emulate A Terminal, in a region, in a buffer and in Eshell

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: emacs-eat
  Version : 0.9.4
  Upstream Author : Akib Azmain Turja 
* URL or Web page : https://codeberg.org/akib/emacs-eat
* License : GPL3+
  Programming lang: Emacs Lisp
  Description : Emulate A Terminal, in a region, in a buffer and in Eshell

Eat is a terminal emulator. It can run most (if not all) full-screen
terminal programs, including Emacs.

Bug#1078656: grub-pc: please use 'grub-install --disk-module=native /dev/sdX'

[Martin-Éric Racine]

Package: grub-pc
Version: 2.06-13+deb12u1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I've been trying to implement a chainloader (see below at 
/etc/grub.d/40_custom) to boot off external USB disks as needed. Finding 
external disks requires using GRUB's 'nativedisk', but once that has been 
executed, the rest of the script cannot be completed because Debian's 
grub-install enforces BIOS device names (hd0,msdos1) instead of bus names 
(ata0,msdos1). Further investigating this suggests that if Debian used 
'grub-install --disk-module=native /dev/sdX' to install GRUB, this would work 
as expected.

Alternately, if there's any /etc/default/grub variable I can set to accomplish 
this, it would suit me just as well.

Thanks!
Martin-Éric

- -- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 / ext4 rw,relatime,errors=remount-ro 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-ST320011A_3HT48T7R
*** END /boot/grub/device.map

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

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

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

export menuentry_id_option

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

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

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
cc540c15-0f8a-4933-88de-5516da7b3414
else
  search --no-floppy --fs-uuid --set=root cc540c15-0f8a-4933-88de-5516da7b3414
fi
font="/usr/share/grub/unicode.pf2"
fi

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

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
cc540c15-0f8a-4933-88de-5516da7b3414
else
  search --no-floppy --fs-uuid --set=root cc540c15-0f8a-4933-88de-5516da7b3414
fi
insmod png
if background_image /usr/share/desktop-base/emerald-theme/grub/grub-4x3.png; 
then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=white/black
  set menu_color_highlight=black/light-gray
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=keep
export linux_gfx_mode
menuentry 'Debian GNU/Linux, with Linux 6.1.0-23-686-pae' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-6.1.0-23-686-pae-advanced-cc540c15-0f8a-4933-88de-5516da7b3414' {
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 
--hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  
cc540c15-0f8a-4933-88de-5516da7b3414
else
  search --no-floppy --fs-uuid --set=root 
cc540c15-0f8a-4933-

Bug#1061087: Fixed reprotest

[Martin Dosch]

Dear Phil,

thank you very much. Upstream already fixed the issue and I created a 
new build which builds successfully: https://salsa.debian.org/mdosch/bash-unit/-/jobs/6118128


Best regards,
Martin


signature.asc
Description: PGP signature

Bug#1078597: libradare2-5.0.0t64: symbolic links to unversioned *.so files missing

[martin schitter]

On 13.08.24 14:59, Gürkan Myczko wrote:
[...] can you tell me which version of iaito 
you are using? And how it was installed?


I used the `iaito` debian packages from the upstream github repos 
release section:


https://github.com/radareorg/iaito/releases/download/5.9.4/iaito_5.9.4_amd64.deb

and

https://github.com/radareorg/iaito/releases/download/5.9.2/iaito_5.9.2_amd64.deb


I don't think it's missing any symbolic link or anything. And I don't 
think this bug is a bug in radare2.



well -- if you install the 5.9.2 release of libradare2-5.0.0t64
you will find libs and unversioned link locations:

```
ls -lh /usr/lib/x86_64-linux-gnu/libr_core.so*
lrwxrwxrwx 1 root root   18 Mai 23 08:46 
/usr/lib/x86_64-linux-gnu/libr_core.so -> libr_core.so.5.9.2
-rw-r--r-- 1 root root 2,8M Mai 23 08:46 
/usr/lib/x86_64-linux-gnu/libr_core.so.5.9.2


```

but if you install the 5.9.4 release of your package, you will only get:

``
❯ ls -lh /usr/lib/x86_64-linux-gnu/libr_core.so*
-rw-r--r-- 1 root root 2,9M Aug 10 21:36 
/usr/lib/x86_64-linux-gnu/libr_core.so.5.9.4

```

this will cause an error in `iaito`:

```
❯ iaito
iaito: error while loading shared libraries: libr_core.so: cannot open 
shared object file: No such file or directory

```

I would guess that it is due a missing `ldconfigure` call in the 
installation script...



Would you mind trying this version? If it's not 5.9.4:
http://bananas.debian.net/debian/iaito/


I couldn't test this package on my machine, because it's only build for 
the arm architecture.

Bug#1078597: libradare2-5.0.0t64: symbolic links to unversioned *.so files missing

[martin schitter]

Package: libradare2-5.0.0t64
Version: 5.9.4+dfsg-1
Severity: important

Dear Maintainer,

The version 5.9.4 of the radare2 libs is missing the symbolic links to the 
unversioned *.so location.
This effects the GUI tool `iaito`, which will not start anymore because it
 doesn't find the requred libs.
Release 5.9.2 did work resp. installs the libs as expected.

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

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

Versions of packages libradare2-5.0.0t64 depends on:
ii  libc6  2.39-6
ii  libcapstone4   4.0.2-5.1
ii  liblz4-1   1.9.4-3
ii  libmagic1t64   1:5.45-3
ii  libradare2-common  5.9.4+dfsg-1
ii  libxxhash0 0.8.2-2+b1
ii  libzip4t64 1.7.3-1.1+b1
ii  zlib1g 1:1.3.dfsg+really1.3.1-1

libradare2-5.0.0t64 recommends no packages.

libradare2-5.0.0t64 suggests no packages.

-- no debconf information

Bug#1077620: autopkgtest-virt-qemu: timed out waiting for 'login prompt on serial console'

[Martin-Éric Racine]

ti 13. elok. 2024 klo 0.49 Simon McVittie (s...@debian.org) kirjoitti:
>
> Control: unmerge 1071456 1077620
> Control: retitle 1077620 autopkgtest-virt-qemu: timed out waiting for 'login 
> prompt on serial console'
> Control: reopen 1077620
> Control: tags 1077620 + moreinfo
>
> On Mon, 12 Aug 2024 at 23:17:02 +0300, Martin-Éric Racine wrote:
> > I created a fresh image as follow:
> >
> > sudo autopkgtest-build-qemu unstable /var/tmp/autopkgtest-unstable.img
> >
> > I then tried to launch a test as follow:
> >
> > $ autopkgtest dhcpcd -- qemu --ram-size 2047 
> > /var/tmp/autopkgtest-unstable.img
> ...
> > : failure: timed out waiting for 'login prompt on serial 
> > console'
>
> I think this must be a different failure mode than the 9pfs bug that
> caused #1071456, then. A similar setup is working well for me, on unstable,
> but I was getting similar timeouts intermittently in the past.

Agreed.

> Adding --debug and/or --show-boot after qemu on the command line might
> provide useful information?

DEBUG

$ autopkgtest dhcpcd -- qemu --debug --ram-size 2047
/var/tmp/autopkgtest-unstable.img
autopkgtest [08:09:22]: starting date and time: 2024-08-13 08:09:22+0300
autopkgtest [08:09:22]: version 5.39
autopkgtest [08:09:22]: host p8h61; command line: /usr/bin/autopkgtest
dhcpcd -- qemu --debug --ram-size 2047
/var/tmp/autopkgtest-unstable.img
autopkgtest-virt-qemu: DBG: Assuming nothing special needs to be done
to set up firmware to boot this machine (boot method: bios)
autopkgtest-virt-qemu: DBG: executing open
autopkgtest-virt-qemu: DBG: qemu architecture: i386
autopkgtest-virt-qemu: DBG: qemu command: qemu-system-i386
autopkgtest-virt-qemu: DBG: find_free_port: trying 10022
autopkgtest-virt-qemu: DBG: find_free_port: 10022 is free
autopkgtest-virt-qemu: DBG: execute-timeout: qemu-img info
--output=json /var/tmp/autopkgtest-unstable.img
autopkgtest-virt-qemu: DBG: Creating temporary overlay image in
/tmp/autopkgtest-qemu.6hxz4sjo/overlay.img
autopkgtest-virt-qemu: DBG: execute-timeout: qemu-img create -f qcow2
-F qcow2 -b /var/tmp/autopkgtest-unstable.img
/tmp/autopkgtest-qemu.6hxz4sjo/overlay.img
autopkgtest-virt-qemu: DBG: Forwarding local port 10022 to VM ssh port 22
autopkgtest-virt-qemu: DBG: full qemu command-line:
['qemu-system-i386', '-m', '2047', '-smp', '1', '-nographic',
'-device', 'virtio-net-pci,netdev=net0', '-netdev',
'user,id=net0,hostfwd=tcp:127.0.0.1:10022-:22', '-object',
'rng-random,filename=/dev/urandom,id=rng0', '-device',
'virtio-rng-pci,rng=rng0,id=rng-device0', '-monitor',
'unix:/tmp/autopkgtest-qemu.6hxz4sjo/monitor,server=on,wait=off',
'-virtfs', 
'local,id=autopkgtest,path=/tmp/autopkgtest-qemu.6hxz4sjo/shared,security_model=none,mount_tag=autopkgtest',
'-device', 'virtio-serial', '-chardev',
'socket,path=/tmp/autopkgtest-qemu.6hxz4sjo/hvc0,server=on,wait=off,id=hvc0',
'-device', 'virtconsole,chardev=hvc0', '-chardev',
'socket,path=/tmp/autopkgtest-qemu.6hxz4sjo/hvc1,server=on,wait=off,id=hvc1',
'-device', 'virtconsole,chardev=hvc1', '-serial',
'unix:/tmp/autopkgtest-qemu.6hxz4sjo/ttyS0,server=on,wait=off',
'-serial', 'unix:/tmp/autopkgtest-qemu.6hxz4sjo/ttyS1,server=on,wait=off',
'-drive', 
'index=0,file=/tmp/autopkgtest-qemu.6hxz4sjo/overlay.img,format=qcow2,cache=unsafe,if=virtio,discard=unmap']
autopkgtest-virt-qemu: DBG: expect: b' login: '
qemu-system-i386: terminating on signal 15 from pid 51363 (/usr/bin/python3)
autopkgtest-virt-qemu: DBG: cleanup...
: failure: timed out waiting for 'login prompt on serial console'
autopkgtest [08:10:22]: ERROR: testbed failure: unexpected eof from the testbed

SHOW-BOOT
[...kernel boots...]
[   23.298592] systemd[1]: systemd 256.4-3 running in system mode
(+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS
+OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD
+LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY
+P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK
-XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE)
[   23.301172] systemd[1]: Detected virtualization qemu.
[   23.302473] systemd[1]: Detected architecture x86.

Welcome to Debian GNU/Linux trixie/sid!

[   23.324735] systemd[1]: Hostname set to .
[   27.687764] systemd[1]: Queued start job for default target graphical.target.
[   28.042777] systemd[1]: Created slice system-autopkgtest.slice -
Slice /system/autopkgtest.
[  OK  ] Created slice system-autopkgtest.slice - Slice /system/autopkgtest.
[   28.076237] systemd[1]: Created slice system-getty.

Bug#1076946: libvirt-daemon-system: Apparmor prevents /proc/sys/vm/max_map_count to be read

[Martin Pitt]

Control: tag -1 upstream
Control: forwarded -1 https://gitlab.com/libvirt/libvirt/-/issues/660

Martin Pitt [2024-08-13  5:59 +0200]:
> However, the image log has the list of updated packages (at the bottom of 
> [3]),
> and the most plausible one is
>
> libvirt-daemon (10.5.0-1 -> 10.6.0-1)
>
> and we have NOT seen this with 10.5.0-1 on our previous image. As Laurent
> reported it against that version, then perhaps the change wasn't in libvirt,
> but in either of
>
>  qemu-system-x86 (1:8.2.4+ds-1 -> 1:9.0.2+ds-2+b1)
>  linux-image-cloud-amd64 (6.9.12-1 -> 6.10.3-1)
>
> (the other package updates are implausible).

I confirmed it is due to the QEMU update. Keeping libvirt 10.5.0-1 and linux
6.9.12-1 and just updating qemu-system-x86 (plus a few deps) from 1:8.2.4+ds-1
to 1:9.0.2+ds-2 causes this.

I reported this upstream.

Thanks,

Martin

Bug#1076946: libvirt-daemon-system: Apparmor prevents /proc/sys/vm/max_map_count to be read

[Martin Pitt]

Control: tag -1 confirmed

Laurent Bigonville [2024-07-24 15:39 +0200]:
> type=AVC msg=audit(1721828131.241:1176): apparmor="DENIED" operation="open" 
> class="file" profile="libvirt-6fde45f5-ff7e-4277-87b9-123a8aa30c7e" 
> name="/proc/sys/vm/max_map_count" pid=149623 comm="qemu-system-x86" 
> requested_mask="r" denied_mask="r" fsuid=64055 ouid=0^]FSUID="libvirt-qemu" 
> OUID="root"

We see the same in cockpit. Our latest Debian testing VM image refresh [1] now
runs into this denial a lot [2].

However, the image log has the list of updated packages (at the bottom of [3]),
and the most plausible one is

libvirt-daemon (10.5.0-1 -> 10.6.0-1)

and we have NOT seen this with 10.5.0-1 on our previous image. As Laurent
reported it against that version, then perhaps the change wasn't in libvirt,
but in either of

 qemu-system-x86 (1:8.2.4+ds-1 -> 1:9.0.2+ds-2+b1)
 linux-image-cloud-amd64 (6.9.12-1 -> 6.10.3-1)

(the other package updates are implausible).

Note: This does not actually break the test in the sense of
"cockpit-machines/libvirt fails", it just triggers this AppArmor noise.

Thanks,

Martin

[1] https://github.com/cockpit-project/bots/pull/6730
[2] 
https://cockpit-logs.us-east-1.linodeobjects.com/pull-6730-54fd8f07-20240812-225340-debian-testing-cockpit-project-cockpit-machines/log.html
[3] 
https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh-debian-testing-314032a6-20240812-223906/log.html

Bug#1077620: Bug#1071456: fixed in autopkgtest 5.39

[Martin-Éric Racine]

Sorry, this did not fix it.

I created a fresh image as follow:

sudo autopkgtest-build-qemu unstable /var/tmp/autopkgtest-unstable.img

I then tried to launch a test as follow:

$ autopkgtest dhcpcd -- qemu --ram-size 2047 /var/tmp/autopkgtest-unstable.img
autopkgtest [23:12:05]: starting date and time: 2024-08-12 23:12:05+0300
autopkgtest [23:12:05]: version 5.39
autopkgtest [23:12:05]: host p8h61; command line: /usr/bin/autopkgtest
dhcpcd -- qemu --ram-size 2047 /var/tmp/autopkgtest-unstable.img
qemu-system-i386: terminating on signal 15 from pid 34522 (/usr/bin/python3)
: failure: timed out waiting for 'login prompt on serial console'
autopkgtest [23:13:06]: ERROR: testbed failure: unexpected eof from the testbed

Martin-Éric

Bug#1043447: grub-efi-amd64: Should provide grub-efi

[Martin-Éric Racine]

Source: grub2
Followup-For: Bug #1043447

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The attached patch against 2.12-5 should accomplish what was requested.

Martin-Éric

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

Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAma5v+cACgkQrh+Cd8S0
17YNhQ/+NDRY2uISdWA/OvbLedvFkdcnWAy8+VGW4tyq56DKwBlozK/gzjSO9e2o
5lTflnfbI7tJph+aigljD5t7a+guLUsEtIgnNlZYdxTM7lkJ/U6u5h1AxrZsPMGf
FbbZ2jYLYZmO23a4duwpUB1Vke5PyWkPPC+2K4stwsO5cCwVTdmQYZ/VxzV1KO7y
Ok2fy7s+wouiGx7t/M16R5qjsIGtqSyLvCwQVDzUdsN6Qtj8rLeeEs6bwBYFP3MT
Zq6Ci5uZQO9aFp2Znn8Ixo5dp88NVUU0I2HHkd001YfEJuTWtG+Lk0OLqzQ7vYtr
NhPWNgJd6Y451BFUZYoMjZ6i7914IHcoqN51mmnon4iDSzXTAqKLizb+x2WOkOQi
4QDrC0fY8yp/j2m3GSlJ2DD4pZl1UcxLZkOMRGXsSuzsphfx8eqxMEdRHbwlNIdK
tRr9RdLvIDA582KkK4sJZpN4GugGH/gQkOnK4jypaNqtl9O4EKVF4+338PJeIEJS
rGWfpRZGA8f07fqch2+i+FFuKj42Rs6oZ351IRPmTlMWXE/ybKM1L4LhJk7FeYws
fiKveLic0U7ZlwuCMmoHNL0M5gBfGNIV5JgRLYNKhaaq+zdok6eVpfSD2l9p5AeL
hqUqAolice6H9pYFpnzv9n9gV+lmZnbl83bYVAXDWUcvg0i+F4E=
=7dCF
-END PGP SIGNATURE-
--- a/debian/control2024-07-15 18:05:20.0 +0300
+++ b/debian/control2024-08-12 10:48:55.437558346 +0300
@@ -312,6 +312,7 @@ Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, grub2-common (= 
${binary:Version}), grub-efi-ia32-bin (= ${binary:Version}), ucf
 Replaces: grub, grub-legacy, grub2 (<< ${source:Version}), grub-common (<= 
1.97~beta2-1), grub-efi, grub-efi-amd64, grub-pc, grub-coreboot, grub-ieee1275
 Conflicts: grub (<< 0.97-54), grub-legacy, grub-efi-amd64, grub-pc, 
grub-coreboot, grub-ieee1275, grub-xen, elilo
+Provides: grub-efi
 Multi-Arch: foreign
 Description: GRand Unified Bootloader, version 2 (EFI-IA32 version)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a
@@ -399,6 +400,7 @@ Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, grub2-common (= 
${binary:Version}), grub-efi-amd64-bin (= ${binary:Version}), ucf
 Replaces: grub, grub-legacy, grub2 (<< ${source:Version}), grub-common (<= 
1.97~beta2-1), grub-pc, grub-efi-ia32, grub-coreboot, grub-ieee1275
 Conflicts: grub, grub-legacy, grub-efi-ia32, grub-pc, grub-coreboot, 
grub-ieee1275, grub-xen, elilo
+Provides: grub-efi
 Multi-Arch: foreign
 Description: GRand Unified Bootloader, version 2 (EFI-AMD64 version)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a
@@ -477,6 +479,7 @@ Architecture: any-ia64
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, grub2-common (= 
${binary:Version}), grub-efi-ia64-bin (= ${binary:Version}), ucf
 Conflicts: elilo
+Provides: grub-efi
 Multi-Arch: foreign
 Description: GRand Unified Bootloader, version 2 (IA64 version)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a
@@ -550,6 +553,7 @@ Architecture: any-arm
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, grub2-common (= 
${binary:Version}), grub-efi-arm-bin (= ${binary:Version}), ucf
 Conflicts: grub-uboot
+Provides: grub-efi
 Multi-Arch: foreign
 Description: GRand Unified Bootloader, version 2 (ARM UEFI version)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a
@@ -624,6 +628,7 @@ Package: grub-efi-arm64
 Architecture: any-arm64
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, grub2-common (= 
${binary:Version}), grub-efi-arm64-bin (= ${binary:Version}), ucf
+Provides: grub-efi
 Multi-Arch: foreign
 Description: GRand Unified Bootloader, version 2 (ARM64 UEFI version)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a
@@ -702,6 +707,7 @@ Package: grub-efi-riscv64
 Architecture: any-riscv64
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, grub2-common (>= 2.02~beta2-9), 
grub-efi-riscv64-bin (= ${binary:Version}), ucf
+Provides: grub-efi
 Multi-Arch: foreign
 Description: GRand Unified Bootloader, version 2 (riscv64 UEFI version)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a
@@ -774,6 +780,7 @@ Package: grub-efi-loong64
 Architecture: any-loong64
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}, grub2-common (>= 2.02~beta2-9), 
grub-efi-loong64-bin (= ${binary:Version}), grub-efi-loong64-unsigned (= 
${binary:Version}), ucf
+Provides: grub-efi
 Multi-Arch: foreign
 Description: GRand Unified Bootloader, version 2 (loong64 UEFI version)
  GRUB is a portable, powerful bootloader.  This version of GRUB is based on a

Bug#1043447: grub-efi-amd64: Should provide grub-efi

[Martin-Éric Racine]

Package: grub-efi-amd64
Version: 2.12-5
Followup-For: Bug #1043447

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I agree with the above. grub-efi-amd64 and grub-efi-ia32 should both Provides: 
grub-efi.

Martin-Éric

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 6.10.3-686-pae (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages grub-efi-amd64 depends on:
ii  debconf [debconf-2.0]  1.5.87
pn  grub-efi-amd64-bin 
ii  grub2-common   2.12-5
ii  ucf3.0043+nmu1

grub-efi-amd64 recommends no packages.

grub-efi-amd64 suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAma5laMACgkQrh+Cd8S0
17alIQ/+M7fk5JWBEgvPOmPg9HsYpb/bpfQm899jY5+bZixHBY+nuvAU5Za9xEis
HjVTRQ1gnLRm1qa/HNsSS1vYfernO4Uw0duPiVlK/Nd3USVj3x9GhzfQNE0ZOxVg
FqhDSD4AGwHHoVm4QKOG+ruV5FhZXk4O+XgNDaDOF8hIbFmpdmTVWHx18FI5NgIU
gpXCX3ANVOO8wS8F1mqhmZjgJducdcvQyeiElr0DIu5gJFtkuKnkSVXWebfz2Foa
mcWMAx++FkTvhTI0AQY9WzEwA8xiTCOH+li4xcwfakVM3ymnfS8AK9P+gyBRRuiw
b4bJQh8Yh1HI7Zryq3Mp21BdpnsNaZ4U3jXkymvHs8V4ctXv677SHKHlerAeyWzy
7p02zEPcxO50DD2tXWtF7vX5W8TiUPjaFlEp4YVFaCLkxpW/hwqM1EBgxv204BB6
Ea74kp8COEJipmKHUs4g2DMtROwslERVBvuLPBLREkk+B5GBUhcVUUTqZpfVMIbo
Y9OynJ9bsRnR+bCoQcpNX7Z3qskeRzlv9NADpCsQUJDBlBK8c0j/eiQtZREvnTdw
MHf7RVfFc6SQApd4wWqfYSfZDvt+nJb/LJWs/PuEZrUN+2CUsCGfPKtSrVTxLHi6
mjLYFvGbwtX+Qf8HcvgnKwdr56KhouWr+S13ZewUud8Z8mdsWco=
=6dU/
-END PGP SIGNATURE-

Bug#1011947: undionly.kpxe doesn't handle IPv6 NDP

[Martin-Éric Racine]

On Fri, 27 May 2022 15:46:38 +0200 Marc Haber
 wrote:
> Package: ipxe
> Version: 1.0.0+git-20190125.36a4c85-5.1
> Severity: normal
> Tags: ipv6
>
> So I think we're having three bug reports here:
>
> - the IPv6 RFC violation of not doing IPv6 DAD and not joining required
>   multicast groups
> - not being able to properly receive the multicasted neighbor
>   solicitation of the gateway on one particular type of hardware
>  - not trying one of the other DNS servers after the queries to the first  
> one were unsuccessful
>
> I am not reporting this upstream since upstream has advanced considerably 
> since this package was uploaded to Debian. Do you need help packaging a 
> current version of ipxe?
>
> Can I do anything else to help with this bug report and/or ipxe?

This package is not only severely lagging WRT upstream, most bugs are
left unanswered, even though most of them are trivial to fix. This
package really needs a new maintainer.

Martin-Éric

Bug#1058329: ipxe: FTBFS: arch/x86/core/patch_cf.S:26: Error: 64bit mode not supported on `i386'.

[Martin-Éric Racine]

Package: ipxe
Version: 1.0.0+git-20190125.36a4c85-5.1
Followup-For: Bug #1058329
Control: tags -1 ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

That's because Debian presumes that EFI means x86-64 binary...

$ file /boot/ipxe.efi 
/boot/ipxe.efi: PE32+ executable (DLL) (EFI application) x86-64, for MS 
Windows, 6 sections
$ uname -a
Linux u1400 6.10.3-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.10.3-1 (2024-08-04) 
i686 GNU/Linux

Meanwhile, upstream has been able to generate separate 32-bit and 64-bit EFI 
images for some time:

$ dir -1 Projects/ipxe/src/
arch
bin
bin-i386-efi
bin-i386-linux
bin-x86_64-efi
config
core
crypto
doc
doxygen.cfg
drivers
hci
image
include
interface
libgcc
Makefile
Makefile.efi
Makefile.housekeeping
Makefile.linux
net
scripts
tests
usr
util

A new Debian upload that enables this, possibly built along similar methods as 
memtest86+, would probably fix this.

Martin-Éric

- -- System Information:
Debian Release: trixie/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 6.10.3-686-pae (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAma5A6kACgkQrh+Cd8S0
17Zg3w//e1oMjh13FudUgsnEgHzzv4rQ3EDpXRxW90ywzdNWrfbCf+zSI/9g2715
ErPYaoFx+/TSPAVcmwsOWUV51bLJ4yFc5oueimQQnTCQx1wzGJpYDouw1Zel0J2O
wVZ0EGY/153+oUwg0NELr8MrNx0A5GrTnYQfe//p7/DvrBJB+J+4q/rVTd7y2lSE
7pj3RLydoaL/vDguWQGlONmeudouBW3J76sZ5EDiQydHiqlefVtgDA9baIR/bVcO
sshGizbPaTDDbuhCpE1X1zrsg+J6wVUfmfaF7m8amG5ZHfbynL/ZLXtuCbfZtiwm
GYQGToAICXCBTImcFJ3fYQaRvMPEJTsYGKFMCNPSGW5xIBkWhIvIBE7NmhD/emco
9yFzCEv3XYQp9G5XAEdyEdVCtxliKHXGqposhOJn63roNCwll9XCn+S5X/dfy3Po
4Lrs9ndHfbnjkRls0mnDQ85oHjZtEnG6EPVfirDPNEBnvX13jX2qaOBfBQ5hwTI9
vUiswnbr2W0pfdbdUru9e7sdQzvOYHJsxOqOKKr7tTlGltIxH2AQGKlD+Fzu+HOA
DYc28ABiao8sJzBcNPU8rfViTx4ssGM5qVS7bew6zZMnFlIxBuBwFNw8XgW1DvNM
2QnKN65EkD/RdZ56ipdJoaVwvr2567esYflrmM2l/v40WZS+bNM=
=WAnb
-END PGP SIGNATURE-

Bug#1078474: ITP: emacs-xdg-appmenu -- run XDG desktop applications

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: emacs-xdg-appmenu
  Version : 0.1
  Upstream Author : Akib Azmain Turja 
* URL or Web page : https://codeberg.org/akib/emacs-xdg-appmenu
* License : GPL3+
  Programming lang: Emacs Lisp
  Description : run XDG desktop applications

XDG Appmenu allows you to run XDG desktop application right from your
Emacs. To run an application, just do M-x xdg-appmenu.

Bug#1078469: Acknowledgement (dino-im: Crashes when starting on testing)

[Martin]

On 2024-08-10 21:50, Diane Trout wrote:
> ii  libgtk-4-1:amd64   4.12.5+ds-6+b1 amd64   
> ii  libgtk-4-bin   4.12.5+ds-6+b1 amd64
> ii  libgtk-4-common4.14.4+ds-8all
> ii  libgtk-4-media-gstreamer   4.12.5+ds-6+b1 amd64
...
> I suspect libgtk-4-1 should have a stricter dependency.
>
> I'm going to retitle this and assign it to gtk4

Thank you!

Bug#1078194: cfengine3: missing "reports:" promise qualifier in cfe_internal/core/main.cf

[Christoph Martin]

Hi Gian,

this might be a leftover from your old installation.

/var/lib/cfengine3/inputs/cfe_internal/core/main.cf is your old file 
which you received from your master.


/usr/share/cfengine3/masterfiles/cfe_internal/core/main.cf is the 
version delivered from the package update.


You have to update your masterfiles.

Regards
Christoph

Am 08.08.24 um 08:02 schrieb Gian Piero Carrubba:

Package: cfengine3
Version: 3.24.0-1
Severity: normal
Tags: patch upstream

cfengine3-3.24.0-1 causes a lot of errors like the one below:


/var/lib/cfengine3/inputs/cfe_internal/core/main.cf:194:74:
warning: No action requested for processes promise with promiser
'Should restart cf-serverd because something in its data changed.'
in /var/lib/cfengine3/inputs/cfe_internal/core/main.cf:mpf_augments_control 
close to line 194 [-Wsanity-check]
"Should restart cf-serverd because something in its data changed.";


This is due to a missing "reports:" promise in
/var/lib/cfengine3/inputs/cfe_internal/core/main.cf.
Upstream opted for removing the messages altogether as they are deemed
useless:
https://github.com/cfengine/masterfiles/commit/f5e59f07698a2f7f4372b700333b3580aaa48bcd


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1078023: login: SIGHUP upon executing 'login'

[Martin-Éric Racine]

to 8. elok. 2024 klo 9.35 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ti 6. elok. 2024 klo 11.28 Martin-Éric Racine
> (martin-eric.rac...@iki.fi) kirjoitti:
> >
> > ti 6. elok. 2024 klo 11.15 Chris Hofstaedtler (z...@debian.org) kirjoitti:
> > >
> > > Control: severity -1 normal
> > > Control: tags -1 = wontfix
> > > Control: retitle -1 login: util-linux variant uses vhangup
> > >
> > > * Martin-Éric Racine  [240806 09:46]:
> > > > ti 6. elok. 2024 klo 10.19 Martin-Éric Racine
> > > > (martin-eric.rac...@iki.fi) kirjoitti:
> > > > >
> > > > > ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) 
> > > > > kirjoitti:
> > > > > >
> > > > > > Control: tags -1 + unreproducible moreinfo
> > > > > >
> > > > > > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote:
> > > > > > > The latest upload to unstable breaks login. Running the 'login' 
> > > > > > > command consistently returns SIGHUP. This effectively prevents 
> > > > > > > logging in.
> > > > > >
> > > > > > Works for me. Please provide additional info on when/how this
> > > > > > happens.
> > > > >
> > > > > When is systematically.
> > > > >
> > > > > I'm really not sure of what info would match 'how'.
> > >
> > > > What I run:
> > >
> > > See, that's exactly the relevant info that was missing in your bug 
> > > report. I
> > > was assuming agetty was running login for you. When you do something 
> > > manually,
> > > or change something that's not the default, please put it into the report.
> > >
> > > > sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER"
> > > >
> > > > Since this morning's 'login' update, this returns SIGHUP.
> > >
> > > Right. This is documented in login(1):
> > >
> > > | A recursive login, as used to be possible in the good old days, no 
> > > longer
> > > | works; for most purposes su(1) is a satisfactory substitute. Indeed, for
> > > | security reasons, login does a vhangup(2) system call to remove any 
> > > possible
> > > | listening processes on the tty. This is to avoid password sniffing. If 
> > > one
> > > | uses the command login, then the surrounding shell gets killed by
> > > | vhangup(2) because it’s no longer the true owner of the tty. This can be
> > > | avoided by using exec login in a top-level shell or xterm.
> > >
> > > As the man page says, give su a try, or runuser, depending on your 
> > > usecase.
> > > Or a container manager might be an even better solution, again, depending 
> > > on
> > > your usecase.
> >
> > None of these is a drop-in substitute. I still need something similar
> > to the above recipe to succesfully log me into a chroot.
>
> This gets worse. My current recipe:
>
> sudo --preserve-env chroot /srv/chroot/"$1" su --login "$USER"
>
> One cannot run 'debsign' in this chroot anymore:
>
> gpg: signing failed: Operation cancelled
>
> Sorry, but "try something or something else" really won't do.

In case anyone runs into the same issue, the equivalent using 'su'
(but without actually loging in) is:

sudo --preserve-env chroot /srv/chroot/"$1" su --pty - "$USER"

The important part is to create the pty, otherwise, e.g. gpg will fail.

Martin-Éric

Bug#1078023: login: SIGHUP upon executing 'login'

[Martin-Éric Racine]

ti 6. elok. 2024 klo 11.28 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ti 6. elok. 2024 klo 11.15 Chris Hofstaedtler (z...@debian.org) kirjoitti:
> >
> > Control: severity -1 normal
> > Control: tags -1 = wontfix
> > Control: retitle -1 login: util-linux variant uses vhangup
> >
> > * Martin-Éric Racine  [240806 09:46]:
> > > ti 6. elok. 2024 klo 10.19 Martin-Éric Racine
> > > (martin-eric.rac...@iki.fi) kirjoitti:
> > > >
> > > > ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) 
> > > > kirjoitti:
> > > > >
> > > > > Control: tags -1 + unreproducible moreinfo
> > > > >
> > > > > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote:
> > > > > > The latest upload to unstable breaks login. Running the 'login' 
> > > > > > command consistently returns SIGHUP. This effectively prevents 
> > > > > > logging in.
> > > > >
> > > > > Works for me. Please provide additional info on when/how this
> > > > > happens.
> > > >
> > > > When is systematically.
> > > >
> > > > I'm really not sure of what info would match 'how'.
> >
> > > What I run:
> >
> > See, that's exactly the relevant info that was missing in your bug report. I
> > was assuming agetty was running login for you. When you do something 
> > manually,
> > or change something that's not the default, please put it into the report.
> >
> > > sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER"
> > >
> > > Since this morning's 'login' update, this returns SIGHUP.
> >
> > Right. This is documented in login(1):
> >
> > | A recursive login, as used to be possible in the good old days, no longer
> > | works; for most purposes su(1) is a satisfactory substitute. Indeed, for
> > | security reasons, login does a vhangup(2) system call to remove any 
> > possible
> > | listening processes on the tty. This is to avoid password sniffing. If one
> > | uses the command login, then the surrounding shell gets killed by
> > | vhangup(2) because it’s no longer the true owner of the tty. This can be
> > | avoided by using exec login in a top-level shell or xterm.
> >
> > As the man page says, give su a try, or runuser, depending on your usecase.
> > Or a container manager might be an even better solution, again, depending on
> > your usecase.
>
> None of these is a drop-in substitute. I still need something similar
> to the above recipe to succesfully log me into a chroot.

This gets worse. My current recipe:

sudo --preserve-env chroot /srv/chroot/"$1" su --login "$USER"

One cannot run 'debsign' in this chroot anymore:

gpg: signing failed: Operation cancelled

Sorry, but "try something or something else" really won't do.

Martin-Éric

Bug#1078055: refind: ext4 driver in outdated debian version of refind (3.12) doesn't work

[martin schitter]

Package: refind
Version: 0.13.2-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

   The present refind package is outdated even in sid and testing.
   The actual upstream allready fixied this issue.

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

   I was trying to install refind, but could not see the installed 
   kernels in the chooser. The reason wasn't even reported in refinds 
   logfile.
   Another user in an internet forum pointed me to the refinds upstream
   Changelog, where yoz can read at realease 0.14.0 (3/4/2023):

   "The ext4fs driver now ignores the metadata_csum_seed flag,
   which is being set by default in e2fsprogs version 1.47.0 
   and later. Not ignoring the flag caused the driver to fail 
   to read such filesystems. Thanks to Martin Whitaker for the 
   relevant patch."

   * What was the outcome of this action?

   I installed the uptream release and everything worked!

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

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

Versions of packages refind depends on:
ii  debconf [debconf-2.0]  1.5.87
ii  efibootmgr 18-2
ii  gdisk  1.0.10-2
ii  mokutil0.6.0-2+b1
ii  openssl3.2.2-1

Versions of packages refind recommends:
ii  python3 3.12.4-1
ii  sbsigntool  0.9.4-3.1+b1

refind suggests no packages.

-- Configuration Files:
/etc/refind.d/keys/README.txt [Errno 13] Permission denied: 
'/etc/refind.d/keys/README.txt'
/etc/refind.d/keys/SLES-UEFI-CA-Certificate.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/SLES-UEFI-CA-Certificate.cer'
/etc/refind.d/keys/SLES-UEFI-CA-Certificate.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/SLES-UEFI-CA-Certificate.crt'
/etc/refind.d/keys/altlinux.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/altlinux.cer'
/etc/refind.d/keys/canonical-uefi-ca.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/canonical-uefi-ca.cer'
/etc/refind.d/keys/canonical-uefi-ca.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/canonical-uefi-ca.crt'
/etc/refind.d/keys/centossecureboot201.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/centossecureboot201.cer'
/etc/refind.d/keys/centossecureboot201.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/centossecureboot201.crt'
/etc/refind.d/keys/centossecurebootca2.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/centossecurebootca2.cer'
/etc/refind.d/keys/centossecurebootca2.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/centossecurebootca2.crt'
/etc/refind.d/keys/debian.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/debian.cer'
/etc/refind.d/keys/fedora-ca.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/fedora-ca.cer'
/etc/refind.d/keys/fedora-ca.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/fedora-ca.crt'
/etc/refind.d/keys/microsoft-kekca-public.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-kekca-public.cer'
/etc/refind.d/keys/microsoft-pca-public.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-pca-public.cer'
/etc/refind.d/keys/microsoft-uefica-public.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-uefica-public.cer'
/etc/refind.d/keys/microsoft-uefica-public.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/microsoft-uefica-public.crt'
/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.cer [Errno 13] Permission 
denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.cer'
/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.crt [Errno 13] Permission 
denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate-4096.crt'
/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.cer [Errno 13] Permission 
denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.cer'
/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.crt [Errno 13] Permission 
denied: '/etc/refind.d/keys/openSUSE-UEFI-CA-Certificate.crt'
/etc/refind.d/keys/refind.cer [Errno 13] Permission denied: 
'/etc/refind.d/keys/refind.cer'
/etc/refind.d/keys/refind.crt [Errno 13] Permission denied: 
'/etc/refind.d/keys/refind.crt'

-- debconf information:
* refind/install_to_esp: true

Bug#1076660: po4a: Fail to parse .ie in groff man pages

[Martin Quinson]

Hello Petter,

could you please give me the sequence of commands I should give to reproduce
the bugs? I've tried `make -C src translateddocs` from the docs directory as
advised by the README (IIUC), and I get an error that the Make target does not
exist. I fail to find the Makefile to fix it myself.

Thanks in advance,
Mt

Le mercredi 24 juillet 2024 à 10:08 +0200, Petter Reinholdtsen a écrit :
> [Martin Quinson]
> > Could you please check whether your problem is "fixed" with the 0.73
> > version?  If not, I'll try to find the time to dig into your
> > repository properly.
> 
> I retried the LinuxCNC master branch on trixie with 0.73, and the
> problem exist there too.
> 
> Note, the LinuxCNC master repository has worked around this issue by
> dropping the problematic change, so I reapplied it for my test using
> 'git cherry-pick d1414e63eb19f2ebb6c300ea40b4404869c516a3'.
> 
> > In any case, I'm rather reluctant to implement a proper support for
> > conditionals in po4a, as it would request to implement a complete
> > groff interpreter. Of course, I'd accept proper patches going in that
> > direction.
> 
> I would be happy with po4a not going into a endless loop printing
> errors, do not believe there is a need for a complete groff
> interpreter. :)
> 



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

Bug#1078023: login: SIGHUP upon executing 'login'

[Martin-Éric Racine]

ti 6. elok. 2024 klo 11.15 Chris Hofstaedtler (z...@debian.org) kirjoitti:
>
> Control: severity -1 normal
> Control: tags -1 = wontfix
> Control: retitle -1 login: util-linux variant uses vhangup
>
> * Martin-Éric Racine  [240806 09:46]:
> > ti 6. elok. 2024 klo 10.19 Martin-Éric Racine
> > (martin-eric.rac...@iki.fi) kirjoitti:
> > >
> > > ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) kirjoitti:
> > > >
> > > > Control: tags -1 + unreproducible moreinfo
> > > >
> > > > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote:
> > > > > The latest upload to unstable breaks login. Running the 'login' 
> > > > > command consistently returns SIGHUP. This effectively prevents 
> > > > > logging in.
> > > >
> > > > Works for me. Please provide additional info on when/how this
> > > > happens.
> > >
> > > When is systematically.
> > >
> > > I'm really not sure of what info would match 'how'.
>
> > What I run:
>
> See, that's exactly the relevant info that was missing in your bug report. I
> was assuming agetty was running login for you. When you do something manually,
> or change something that's not the default, please put it into the report.
>
> > sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER"
> >
> > Since this morning's 'login' update, this returns SIGHUP.
>
> Right. This is documented in login(1):
>
> | A recursive login, as used to be possible in the good old days, no longer
> | works; for most purposes su(1) is a satisfactory substitute. Indeed, for
> | security reasons, login does a vhangup(2) system call to remove any possible
> | listening processes on the tty. This is to avoid password sniffing. If one
> | uses the command login, then the surrounding shell gets killed by
> | vhangup(2) because it’s no longer the true owner of the tty. This can be
> | avoided by using exec login in a top-level shell or xterm.
>
> As the man page says, give su a try, or runuser, depending on your usecase.
> Or a container manager might be an even better solution, again, depending on
> your usecase.

None of these is a drop-in substitute. I still need something similar
to the above recipe to succesfully log me into a chroot.

Martin-Éric

Bug#1078023: login: SIGHUP upon executing 'login'

[Martin-Éric Racine]

ti 6. elok. 2024 klo 10.46 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ti 6. elok. 2024 klo 10.19 Martin-Éric Racine
> (martin-eric.rac...@iki.fi) kirjoitti:
> >
> > ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) kirjoitti:
> > >
> > > Control: tags -1 + unreproducible moreinfo
> > >
> > > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote:
> > > > The latest upload to unstable breaks login. Running the 'login' command 
> > > > consistently returns SIGHUP. This effectively prevents logging in.
> > >
> > > Works for me. Please provide additional info on when/how this
> > > happens.
> >
> > When is systematically.
> >
> > I'm really not sure of what info would match 'how'.
>
> What I run:
>
> sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER"
>
> Since this morning's 'login' update, this returns SIGHUP.
>
> Meanwhile:
>
> sudo --preserve-env chroot /srv/chroot/stable-amd64/ login "$USER"
>
> This presents me with the password prompt as normal.

PS: reverting to login_4.16.0-1_i386.deb from src:shadow restored
functionality. I can login using the above receipe as before.

Martin-Éric

Bug#1078023: login: SIGHUP upon executing 'login'

[Martin-Éric Racine]

ti 6. elok. 2024 klo 10.19 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) kirjoitti:
> >
> > Control: tags -1 + unreproducible moreinfo
> >
> > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote:
> > > The latest upload to unstable breaks login. Running the 'login' command 
> > > consistently returns SIGHUP. This effectively prevents logging in.
> >
> > Works for me. Please provide additional info on when/how this
> > happens.
>
> When is systematically.
>
> I'm really not sure of what info would match 'how'.

What I run:

sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER"

Since this morning's 'login' update, this returns SIGHUP.

Meanwhile:

sudo --preserve-env chroot /srv/chroot/stable-amd64/ login "$USER"

This presents me with the password prompt as normal.

Martin-Éric

Bug#1078023: login: SIGHUP upon executing 'login'

[Martin-Éric Racine]

ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (z...@debian.org) kirjoitti:
>
> Control: tags -1 + unreproducible moreinfo
>
> On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote:
> > The latest upload to unstable breaks login. Running the 'login' command 
> > consistently returns SIGHUP. This effectively prevents logging in.
>
> Works for me. Please provide additional info on when/how this
> happens.

When is systematically.

I'm really not sure of what info would match 'how'.

Martin-Éric

Bug#1076110: Confirmed, also affects keyboard backlight

[Ralph Martin]

I can confirm this issue on an LG Gram 16Z90Q laptop. A further side 
effect is that keyboard backlight control is affected.

Bug#1078023: login: SIGHUP upon executing 'login'

[Martin-Éric Racine]

Package: login
Version: 1:4.16.0-2+really2.40.2-4
Severity: grave
Justification: renders package unusable

The latest upload to unstable breaks login. Running the 'login' command 
consistently returns SIGHUP. This effectively prevents logging in.

I've thus had to do backflips with 'chroot' and 'su' just to be able to file 
this bug report.

Martin-Éric

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

Kernel: Linux 6.1.0-23-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

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

login recommends no packages.

login suggests no packages.

-- no debconf information

Bug#1061087: RFS: bash-unit/2.3.1-1 [ITP] -- bash_unit - bash unit testing

[Martin Dosch]

Dear Phil,

On 04.08.2024 10:17, Phil Wyett wrote:

2. Lintian [3]: Issue

'Standards-Version' in 'debian/control' requires updating to latest 4.7.0.


Fixed.


6. Reproducible builds [5]: Issue


I have created an issue upstream [1] as I think this should be fixed 
there.


Best regards,
Martin

[1] https://github.com/pgrange/bash_unit/issues/128


signature.asc
Description: PGP signature

Bug#1077873: reprotest: Traces back when trying to do a test

[Martin Dosch]

Hi Chris,

Am 05.08.2024 13:17, schrieb Chris Lamb:

In particular, whilst there is a traceback on Salsa, it looks like the
package's testsuite is failing and *that* reprotest traceback is a
symptom of that rather than a root cause. Is that observation right?


yes, the test fails. I already created an issue upstream. But a failing 
autopkgtest should not make reprotest traceback I guess.



I wonder if some part of the toolchain doesn't support expanding ~ to
$HOME.


Good remark, but using the full path doesn't help:


sudo reprotest --min-cpus=4 --vary=-build_path,domain_host.use_sudo=1 
--auto-build /home/martin/build/deb/bash-unit_2.3.1-1.dsc -- schroot 
unstable-amd64-sbuild
[SNIP]
Running hooks in /etc/ca-certificates/update.d...
done.
gpgv: Signature made Sat Aug  3 19:55:43 2024 GMT
gpgv:using RSA key FD5A92F4208137A4B6680B3D52A57CFCE13D657D
gpgv: Can't check signature: No public key
dpkg-source: warning: cannot verify inline signature for 
./bash-unit_2.3.1-1.dsc: no acceptable signature found
dpkg-source: error: cannot fstat file ./bash-unit_2.3.1.orig.tar.gz: No such 
file or directory
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 862, in run
return 0 if check_func(*check_args) else 1
^^^
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 410, in 
check_auto
dist_x0 = proc.send(("control", var_x0))
  ^^
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 339, in 
corun_builds
bctx.run_build(testbed, build, os.environ, artifact_pattern, 
testbed_build_pre, no_clean_on_error)
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 218, in 
run_build
testbed.check_exec2(build_argv,
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 63, in 
check_exec2
self.bomb('"%s" failed with status %i' % (' '.join(argv), code),
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 70, in bomb
raise _type(m)
reprotest.lib.adtlog.AutopkgtestError: "su -p -s /bin/sh root -c set -e; export 
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin; run_build() {
mkdir -p /tmp/reprotest.0IM44G/build-control-aux && \
mv /tmp/reprotest.0IM44G/build-control/ /tmp/reprotest.0IM44G/const_build_path 
&& \
SETARCH_ARCH=$(uname -m) && \
SETARCH_OPTS="$SETARCH_OPTS -R" && \
CPU_MAX=$(nproc) && \
CPU_MIN=$({ echo $CPU_MAX; echo 4; } | sort -n | head -n1) && \
CPU_NUM=$CPU_MIN && \
export CPU_LIST="$(echo $(shuf -i0-$((CPU_MAX - 1)) -n$CPU_NUM) | tr ' ' ,)" 
&& \
umask 0022 && \
export REPROTEST_BUILD_PATH=/tmp/reprotest.0IM44G/const_build_path/ && \
export REPROTEST_UMASK=$(umask) && \
taskset -a -c $CPU_LIST \
setarch $SETARCH_ARCH $SETARCH_OPTS \
sh -ec 'cd "$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH; umask "$REPROTEST_UMASK"; unset REPROTEST_UMASK; dpkg-source -x 
"bash-unit_2.3.1-1.dsc" "$(basename "$PWD")" && cd "$(basename "$PWD")" && dpkg-buildpackage 
--no-sign -b'
}

cleanup() {
__c=0; \
mv /tmp/reprotest.0IM44G/const_build_path 
/tmp/reprotest.0IM44G/build-control/ || __c=$?; \
rm -rf /tmp/reprotest.0IM44G/build-control-aux || __c=$?; \
exit $__c
}

trap '( cleanup )' HUP INT QUIT ABRT TERM PIPE # FIXME doesn't quite work 
reliably yet

if ( run_build ); then ( cleanup ); else
__x=$?; # save the exit code of run_build
if ( ! false ); then
if ( cleanup ); then :; else echo >&2 "cleanup failed with exit code 
$?"; fi;
fi
exit $__x
fi" failed with status 2


Best regards,
Martin


signature.asc
Description: PGP signature