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

2024-09-16 Thread 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

2024-09-16 Thread 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

2024-09-15 Thread 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#1071090: iso-codes: installs broken symbolic links

2024-09-15 Thread 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#1038882: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)

2024-09-14 Thread 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

2024-09-13 Thread 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

2024-09-13 Thread 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

2024-09-13 Thread 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

2024-09-13 Thread 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#1081193: apt: please implement purge-build-dep

2024-09-11 Thread 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#1081197: linux: please Build-Depends on 'gcc' or on 'build-essential' rather than 'gcc-13'

2024-09-09 Thread 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'

2024-09-09 Thread 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'

2024-09-09 Thread 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   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  g

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

2024-09-09 Thread 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#1079688: openshot-qt: please migrate pyqt5 dependencies to pyqt6

2024-08-26 Thread 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)

2024-08-23 Thread 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#1079023: udisks2: please move btrfs dependencies from Suggests to Recommends

2024-08-18 Thread 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#1078924: hostapd: please package new upstream 2.11

2024-08-17 Thread 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

2024-08-17 Thread 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

2024-08-17 Thread 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#1078756: lintian-brush is not updated for 3.12

2024-08-17 Thread 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

2024-08-16 Thread 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#1078755: python3-fastbencode: failed to load compiled extension: No module named 'fastbencode._bencode_pyx'

2024-08-15 Thread 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'

2024-08-15 Thread 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'

2024-08-15 Thread 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'

2024-08-15 Thread 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'

2024-08-14 Thread 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'

2024-08-13 Thread 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#1078656: grub-pc: please use 'grub-install --disk-module=native /dev/sdX'

2024-08-13 Thread 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-88de-5516da7b3414
fi
echo'Loading Linux 6.1.0-23-686-pae ...'
linux   /boot/vmlinuz-6.1.0-23-686-pae 
root=UUID=cc540c15-0f8a-4933-88de-5516da7b3414 ro panic=15 noquiet loglevel=4 
nosplash
echo'Loading initial ra

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

2024-08-12 Thread 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#1077620: Bug#1071456: fixed in autopkgtest 5.39

2024-08-12 Thread 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

2024-08-12 Thread 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

2024-08-11 Thread 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

2024-08-11 Thread 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'.

2024-08-11 Thread 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#1078023: login: SIGHUP upon executing 'login'

2024-08-08 Thread 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'

2024-08-07 Thread 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#1078023: login: SIGHUP upon executing 'login'

2024-08-06 Thread 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'

2024-08-06 Thread 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'

2024-08-06 Thread 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'

2024-08-06 Thread 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#1078023: login: SIGHUP upon executing 'login'

2024-08-05 Thread 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#1077637: lintian: unknown-field Protected

2024-07-30 Thread Martin-Éric Racine
Package: lintian
Version: 2.118.0
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I recently added "Protected: yes" to a src:control file, since it's preferred 
to Essential for packages that are merely meant to not be auto-removed. Lintian 
apparently still doesn't know about that field.

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 lintian depends on:
ii  binutils2.42.90.20240720-2
ii  bzip2   1.0.8-5.1
ii  diffstat1.66-1
ii  dpkg1.22.10
ii  dpkg-dev1.22.10
ii  file1:5.45-3
ii  gettext 0.22.5-2
ii  gpg 2.2.43-8
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b5
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b3
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b3
ii  libclone-perl   0.46-1+b2
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.38-1
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-3
ii  libdevel-size-perl  0.84-1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.10
ii  libemail-address-xs-perl1.05-1+b3
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.049-1
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.146-1
ii  libperlio-gzip-perl 0.20-1+b3
ii  libperlio-utf8-strict-perl  0.010-1+b2
ii  libproc-processtable-perl   0.636-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b2
ii  libsereal-encoder-perl  5.004+ds-1+b2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-2
ii  libterm-readkey-perl2.38-2+b3
ii  libtext-levenshteinxs-perl  0.03-5+b3
ii  libtext-markdown-discount-perl  0.16-1+b2
ii  libtext-xslate-perl 3.5.9-2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2+b2
ii  liburi-perl 5.28-1
ii  libwww-mechanize-perl   2.18-1
ii  libwww-perl 6.77-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-4
ii  libyaml-libyaml-perl0.89+ds-1+b1
ii  lzip [lzip-decompressor]1.24.1-2
ii  lzop1.04-2
ii  man-db  2.12.1-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.38.2-5
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.6.2-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmapx+0ACgkQrh+Cd8S0
17anGA//WYuYf6SWPb7zPhoT8HZ9MlGcwEWyegz6fL7A0ixE3Qbzja585jlSm+QK
uQ4nputYJ5aKPbtC7JEyBaI06myzey5Z2O7qUl9MG0mLB71Hr7pxpDOX6Wq+qnAm
EMYAYBUoqiNwBwnQfPsEoxFEPbfnMoWtzfjtPstOxqg6N1QePbt23jd/bcLGElhy
DyBPcv1ewo8P6NzKDakneQG+mOd0TeMk8upBjHVBM07sQSJENnEXYLFGdmYAm3+G
/c0pGYuyz0Im2cCT49vEgHloGY2vxibYqJJsOuXKHI6Q+yJaZgFyZViVIDRskFqe
t3PfQCJe11h8na7aMQbjM1uKaz+JuyM7ftnn0EYcwzAsNkMk+ANJjcXDmLJqcr/Y
lX2gT4M13yCLs0GMcTx1ZcP+/XP7r15rZhWIQXuyfg0mR/2+sQQNfAodb9GQLLp6
2eQHlMlbfAp+PDMksnKwPP3FOVNGYKI1CuudcisTEkuZHPLXa2RG2cyb0wdJaGCO
uDxAbckmru/f5BAIVuGGcHlPSQ+UsWnWsFn0Srk8nGua/8EwX3KP7f9ptlKh+KM1
JvTsKnB3ZInvDP/teq/QupbdISpQkANXgv+ua0H7/vLJBI1T1u/OevPwV0ZLBmP4
POQ1jLG6nZmh8hRSrFGGKItGsd58NxA0bP/AtEMTLiEoVPzce6Q=
=8Pd8
-END PGP SIGNATURE-


Bug#743198: adequate: Please provide examples how to use adequate with autopkgtest

2024-07-30 Thread Martin-Éric Racine
Package: adequate
Version: 0.16.5
Followup-For: Bug #743198

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Given how the sample autopkgtest doesn't check package functionality, it should 
probably be marked as superficial:

Tests: adequate
Depends: adequate,
 debhelper,
 @
Restrictions: superficial

As for the test script itself, parentheses are generally preferable to 
backticks:

#!/bin/sh
adequate $(dh_listpackages) >&2

- -- 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 adequate depends on:
ii  debconf  1.5.87
ii  libc62.39-6

Versions of packages adequate recommends:
ii  pkgconf  1.8.1-3

adequate suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmapKocACgkQrh+Cd8S0
17bPOw/8CpB5x/01Qmco3s2cTwjPCJ8/PgnMSaggIup0/zHgcbDb3ziXtqwwnUkJ
1raV52bYfMHKHxLIg3OxEjxdIRYIXUJ3ZpMWWE5tkiHSs1H71oNtag1ONvflIUiB
yfrgTqTjsO7z6xlGSl4Jc4stVtPjFUa8ScSLwGo9QC5BO7KxbgvPtDUSMBiCtM1L
6eEmEbRFSGk0Pn39DuN8FkA8X41w3o49biiZgCHKgksMgStI/GymKafYGF+8cW0M
jUnA/pKG8KThNOQDM/bonMfMSuwahQ8u6wygix6uJlK4MrMh4G0J4EVe3ZcViyHN
iP1BgI69VWcvsl0+LsdP45+E9joOur8A3rCERtHWytH7WtIcGPKMYofBzN+i/Ak7
Ko73fZCXjadIapM9DN7avxzUrJzu+P0kaRSPC9Qju9SMOJtym7w+s32eUw5VusU2
sSqGj2tg9CE32tOKBZxhrO1Qt70C2YsN3aExPrdkkFDKNBYh6mopXfC3vF2XCQu4
6asTVDerDnJCiLof5Y47TU3TK67YYNPcJ3MI2FXfYjZfEOuMUnDWc3v1xk7/+DsM
HQ0ivZOTDkdfFvzDFedWpeNe4vrw/wBMpAxX/FpAfzQyUyi5zN01UJyMeWk790l7
+K5smNn7rTsYenH9H+vzEJ7WopkTNFWwPGfU6AzWM9bodGJlASo=
=XJ7O
-END PGP SIGNATURE-


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

2024-07-30 Thread Martin-Éric Racine
ti 30. heinäk. 2024 klo 20.17 Paul Gevers (elb...@debian.org) kirjoitti:
> On 30-07-2024 19:08, Martin-Éric Racine wrote:
> > Running a test with that image following instructions found at the same URL 
> > repeatedly fails with a timeout:
>
> This is linux kernel bug 1071456.

Ouch. Nice one.
Awaiting fix.

Martin-Éric



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

2024-07-30 Thread Martin-Éric Racine
Package: autopkgtest
Version: 5.37
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I built a qemu image using instructions found at 
(https://wiki.debian.org/ContinuousIntegration/autopkgtest):

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

Running a test with that image following instructions found at the same URL 
repeatedly fails with a timeout:

autopkgtest [19:42:55]: host p8h61; command line: /usr/bin/autopkgtest 
printer-driver-cups-pdf -- qemu --ram-size=2047 
/var/tmp/autopkgtest-unstable.img
qemu-system-i386: terminating on signal 15 from pid 84626 (/usr/bin/python3)
: failure: timed out waiting for 'login prompt on serial console'
autopkgtest [19:43:55]: ERROR: testbed failure: unexpected eof from the testbed

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 autopkgtest depends on:
ii  apt-utils   2.9.7
ii  libdpkg-perl1.22.10
ii  mawk1.3.4.20240622-2
ii  procps  2:4.0.4-5
ii  python3 3.12.4-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28+nmu1
ii  fakeroot  1.35.1-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
pn  genisoimage  
pn  incus
pn  lxc  
pn  lxd  
pn  ovmf 
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.7
pn  qemu-efi-aarch64 
pn  qemu-efi-arm 
pn  qemu-efi-riscv64 
pn  qemu-system  
ii  qemu-utils   1:9.0.2+ds-1
pn  schroot  
ii  util-linux   2.40.2-1
ii  vmdb20.40-1
pn  zerofree 

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmapHfcACgkQrh+Cd8S0
17YXDQ/9GxUGSimaA/ua9RRWgycjjwNmieKYkAi7BXluQKvZ3/ZOQJuZW+GhDNK4
XFVRaFtzkmvarONnm9wezFXluvAlPWj1ULpaNrSNnqg9fjN6MWe6AUpXuMdGafCz
tRRbo6KSPMpHNQsl3zaGnROLf93akSr+RO3o8AjItKwOd1EtQrtpS/pFX9lkrOZF
Nym+vOrAup19QIlzluWNJZL+V/y5UVzkBJmIuJWGAhtKJBB8aFeXg4DRpSrV9Ksy
b3ZkGJ6gmyLZnvB5+f9Jp+FdH7qyIiJ9Br/P08CYyYSZc2QLKce+kj4y1FN8ir+u
/Ew1i0veGe+qaiKjnMm5Zx7nEAbwU4VGrkNKf7tLbMobKqBl5zhnJPCP7gyYysHs
X6Vh95GvUPCXNkuCZWFQx1eWklpnRXhRH50FXw1BUOWdWH2rBSaGrrwWwr+rUxrt
UQQocznFW7NzMUHw4bN6J+gfp5vNkoj84jTAL+WY3T+U1hsWvS/tQiOKXMF7MWEL
2/pwzmyZSwev93EOB9eFP7hWJAfa26z5Vy3D761NnthYLHpVmdjB4htDMhjv0jSM
FntP+3T9uSPsj0ODcXqUFW0lUENVC3oFvlohyMwxD+Ph0dJIAszCdUXg6mLI/eAm
feaQlDdi7nSdqieqY0yKMyexdndwNCzhSQjzczGdxEJJ3wvmFiw=
=9XWx
-END PGP SIGNATURE-


Bug#1076432: systemd: [networkd] incorrect IPv6 address generation

2024-07-29 Thread Martin-Éric Racine
On Tue, 23 Jul 2024 18:15:48 +0100 Luca Boccassi  wrote:
> Control: tags -1 upstream
>
> On Tue, 23 Jul 2024 19:45:33 +0300 =?UTF-
> 8?Q?Martin=2D=C3=89ric_Racine?=  wrote:
> > Please note that if you only reply to the bug itself, the reporter
> > will never know that you requested more information.
> >
> > On Tue, 16 Jul 2024 11:37:43 +0100 Luca Boccassi 
> wrote:
> > > Control: tags -1 moreinfo
> > >
> > > On Tue, 16 Jul 2024 13:29:36 +0300 =?utf-8?q?Martin-
> =C3=89ric_Racine?=
> > >  wrote:
> > > > Package: systemd
> > > > Version: 252.26-1~deb12u2
> > > > Severity: important
> > > > Tags: ipv6
> > > >
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > >
> > > > I have enabled networkd and created the following
> > > /etc/systemd/network/dhcp.network:
> > > >
> > > > [Match]
> > > > Name=en* wl*
> > > >
> > > > [Network]
> > > > DHCP=yes
> > > > IPv6PrivacyExtensions=yes
> > > > IPv6LinkLocalAddressGenerationMode=stable-privacy
> > > >
> > > > Two issues:
> > > >
> > > > 1) networkd creates a new link address with the stable-privacy
> flag,
> > > in addition to the existing one created by the kernel on bootup.
> > > > 2) Regardless, the stable-privacy flag is not inherited by the
> > > mngtmpaddr address. It steadfastly uses an EUI64 address.
> > >
> > > Can you reproduce in testing/unstable?
> >
> > Yes. It still ignores the fe80 created by the kernel at boottime with
> > the stable-privacy flag, it still creates an additional one, and it
> > still creates a public address with EUI64 instead of stable-privacy.
>
> Ok, then please open an issue upstream, after gathering debug level
> logs (SYSTEMD_LOG_LEVEL=debug env var in networkd) and attach them too,
> and also attach the "ip addr" output

I have no idea of where to enable debug only for networkd.

Martin-Éric



Bug#1076432: systemd: [networkd] incorrect IPv6 address generation

2024-07-23 Thread Martin-Éric Racine
Please note that if you only reply to the bug itself, the reporter
will never know that you requested more information.

On Tue, 16 Jul 2024 11:37:43 +0100 Luca Boccassi  wrote:
> Control: tags -1 moreinfo
>
> On Tue, 16 Jul 2024 13:29:36 +0300 =?utf-8?q?Martin-=C3=89ric_Racine?=
>  wrote:
> > Package: systemd
> > Version: 252.26-1~deb12u2
> > Severity: important
> > Tags: ipv6
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > I have enabled networkd and created the following
> /etc/systemd/network/dhcp.network:
> >
> > [Match]
> > Name=en* wl*
> >
> > [Network]
> > DHCP=yes
> > IPv6PrivacyExtensions=yes
> > IPv6LinkLocalAddressGenerationMode=stable-privacy
> >
> > Two issues:
> >
> > 1) networkd creates a new link address with the stable-privacy flag,
> in addition to the existing one created by the kernel on bootup.
> > 2) Regardless, the stable-privacy flag is not inherited by the
> mngtmpaddr address. It steadfastly uses an EUI64 address.
>
> Can you reproduce in testing/unstable?

Yes. It still ignores the fe80 created by the kernel at boottime with
the stable-privacy flag, it still creates an additional one, and it
still creates a public address with EUI64 instead of stable-privacy.

Martin-Éric



Bug#1076097: DeprecationWarning: This process (pid=3710789) is multi-threaded, use of fork() may lead to deadlocks in the child.

2024-07-22 Thread Martin-Éric Racine
Package: unattended-upgrades
Version: 2.11
Followup-For: Bug #1076097

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I bumped into the same issue on my Trixie host.

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.9.9-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 unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.87
ii  lsb-release12.1-1
ii  python33.12.3-1
ii  python3-apt2.9.0+b1
ii  python3-dbus   1.3.2-5+b3
ii  python3-distro-info1.7
ii  sysvinit-utils [lsb-base]  3.09-2
ii  ucf3.0043+nmu1
ii  xz-utils   5.6.2-2

Versions of packages unattended-upgrades recommends:
ii  systemd-sysv  256.2-1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20220412cvs-1
ii  needrestart3.6-8
ii  nullmailer [mail-transport-agent]  1:2.2+10~g7ed88a0-6
ii  powermgmt-base 1.37+nmu1
ii  python3-gi 3.48.2-1+b1

- -- debconf information:
* unattended-upgrades/enable_auto_updates: true

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmaeRZsACgkQrh+Cd8S0
17b0OhAAr4+bLAooXNLLr0AFYOtoNJWFF9C6H/RK9aOhDWcA6OzfjgPcQcUZLf5q
yCudrzab6i0FxAsiRR9eaYxRFrMEXJtWLQPDgeuTYgduRSS3SCd6mvr3+g86F1vo
NvIabD6z9jxO51PK8iUDtQyX3KLZgiYSj5ycqY09lvQ6qPmZQpQ1qWOqg0DG73h6
+GC1rGTYH4N2nCwu5d+GWWMF5zv0YHtNznchlsZZIA/KbJ2uW2i9tiujyCpmhPNx
tdgRUqLUYrQ5/q8OYYvAS8MwlhlhhUAKJxG9VUwPzGvJMOuKx92OwXgzJUhEhrxw
TLWqLrvx0jtdv6uhl5WEYJJJj+o3CDpERJUJY8QFbGFTRcX6iMGHdNug+9vmF3U9
xkfrl2zG7VDUCRJekY6JO/F6+KxtAIY1sTY+QXTOoSVZKIHk2g0nePjPW+g+avvH
Su859rpPgUDFChm98hS1bODc7HFcg8K+bLL2pc+r8X6s5ctLKePGKKz9GxmxCpTz
TYpRjVVs8nO/Z4PS4o48VyE/ODK9bm5fsjOaNwjo09/vJ5pF+4fpD4WRiPQgpxMg
6GMngxs0RwAHgzsvlal0Yy8OgQ/v0LS6owiEWa+eDWXFHekl1RXSMXpHbLW44w6U
Fhmik+oXL1shjQNpIDnjRFBM+kUh8IUVzPz9wMG+04QqajmXa1Q=
=mXYE
-END PGP SIGNATURE-


Bug#1076706: lintian-brush: please rebuild against python 3.12

2024-07-22 Thread Martin-Éric Racine
Package: lintian-brush
Version: 0.155
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

lintian-brush still depends upon python 3.11 components. Can you please trigger 
a rebuild?

Thanks!
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 lintian-brush depends on:
ii  devscripts   2.23.7
ii  libc62.39-4
ii  libgcc-s114.1.0-5
ii  liblzma5 5.6.2-2
pn  libpython3.11t64 
ii  libssl3t64   3.2.2-1
ii  python3  3.12.4-1
ii  python3-breezy   3.3.6-1+b2
ii  python3-debian   0.1.49
ii  python3-debmutate0.68
ii  python3-distro-info  1.7
ii  python3-dulwich  0.21.6-1+b2
ii  python3-iniparse 0.5-2
ii  python3-iso8601  1.0.2-1
ii  python3-levenshtein  0.25.1-3+b1
ii  python3-psycopg2 2.9.9-1+b2
ii  python3-pyinotify0.9.6-3
ii  python3-ruamel.yaml  0.18.6+ds-3
ii  python3-semver   2.10.2-3
ii  python3-tomlkit  0.12.5-1
ii  python3-tqdm 4.66.4-1
ii  python3-upstream-ontologist  0.1.37-1+b1

Versions of packages lintian-brush recommends:
ii  debhelper 13.16
ii  decopy0.2.4.8-0.1
ii  dos2unix  7.5.2-1
ii  gpg   2.2.43-7
ii  lintian   2.117.0
ii  ognibuild 0.0.20-1+b1
ii  python3-bs4   4.12.3-1
ii  python3-docutils  0.20.1+dfsg-3
ii  python3-lxml  5.2.2-1
ii  python3-markdown  3.6-1

Versions of packages lintian-brush suggests:
ii  brz-debian 2.8.79
ii  git-buildpackage   0.9.34
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
pn  postgresql-common  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmaeNZYACgkQrh+Cd8S0
17Y0HA//U5cQEjUrWNL92ntVnVR/JpWCHYAHMRQDTpUxpe+yfYCfKZ6jvQE9qPZQ
1tE+T1fSVS84X/EQNKys6GI/g8Ty3bYRZyDXh6tto+9YcjSmaIug7aJTx/shlwny
KuIaGzKKgA6AYMIqbxLlOZk+/KniMeRiZmpJlWRL+10Qu9IxZvaYVMvTmq1uLwko
vjwrEASjZ81wZ0uM3DhkSFl1tWd/MOYcoddEXOVl4pSA5yfmnK8nNxrAtz3WVFn4
LmWuCTisH4EGqVZW3lLV1eDrKKQXxoCO7mQ6zzuAX+UXAQXk5XQdiq3g+6lBKge5
gdy0tyZMrJV9PQQc93jeYo9U/kqu5lfCUitF3TMKR+UOwwP/nrmdA5L4msPlsrK1
e8LLYjjH5WU+jDlcA/WImakEj3fAI4qBb/2Q96xiTbBqyPo/vSvKRGGrNlnarARY
Cg7AnBkBqA4XPzNWmg3lurAOoan3BxZZu/GzmwbW38Z8lkNg/gmDu/MqiIMi6q7z
Z+fhqTI5DooOSpUL9UIG5MgmpRg9ikwK49Zf/HxNFNn83n/671Y+0Hx3TAXrXNgH
kJ5ACNTjoDMieR9aNSQEB1TXg/XgNltUZLHVTLlAh48TkNvuV83mET318vodQ0M7
2JnWkX/u84yOCM/RIAWnZSNhfFFzcFb4kbXsswI9NxUuu07uNkg=
=gGyh
-END PGP SIGNATURE-


Bug#1012289: RFH: lintian -- Debian package checker

2024-07-17 Thread Martin-Éric Racine
On Mon, 05 Feb 2024 13:20:07 + Bastien
=?ISO-8859-1?Q?Roucari=E8s?=  wrote:
> Le lundi 5 février 2024, 12:42:04 UTC Bill Allombert a écrit :
> > On Mon, Feb 05, 2024 at 12:28:02PM +0100, Axel Beckert wrote:
> > > Hi Bill,
> > >
> > > Bill Allombert wrote:
> > > > By the way, what happened to lintian.debian.org ?
> > >
> > > Seems as if someone (not me, just noticed it today when
> > > "private/refresh-data" failed…) pulled the plug on at least the DNS
> > > name. Probably because it hasn't been updated since Felix' try to
> > > rewrite it, which AFAIK was never finished, but the old thing also no
> > > more worked. (There's probably a lot of legacy code in
> > > "lib/Lintian/Output" related to one of these two website generations,
> > > maybe even both.)
> >
> > I used to generate my own copy of it because the official one was
> > out of date.
>
> Help here is welcome. I really like the l.d.o site particularly the graph
> >
> > > IMHO it's generally a good thing, except that it would have been
> > > better to redirect it to the according UDD pages instead.
> >
> > Yes, because there are ton of places still linking to lintian.debian.org
> > (e.g. wikipedia). We should ask DSA to redirect to salsa or UDD.

I just noticed this RFH. The last Lintian dates back from February
2024. Is there any way I can help? At the very least, we need a new
release that tests for standards 4.7.0 compatibility ASAP.

Martin-Éric



Bug#1076432: systemd: [networkd] incorrect IPv6 address generation

2024-07-16 Thread Martin-Éric Racine
Package: systemd
Version: 252.26-1~deb12u2
Severity: important
Tags: ipv6

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I have enabled networkd and created the following 
/etc/systemd/network/dhcp.network:

[Match]
Name=en* wl*

[Network]
DHCP=yes
IPv6PrivacyExtensions=yes
IPv6LinkLocalAddressGenerationMode=stable-privacy

Two issues:

1) networkd creates a new link address with the stable-privacy flag, in 
addition to the existing one created by the kernel on bootup.
2) Regardless, the stable-privacy flag is not inherited by the mngtmpaddr 
address. It steadfastly uses an EUI64 address.

Martin-Éric

- -- Package-specific info:

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

Kernel: Linux 6.1.0-22-686 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
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 systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+deb12u1
ii  libc6  2.36-9+deb12u7
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-4~deb12u2
ii  libfdisk1  2.38.1-5+deb12u1
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20221128-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+deb12u1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+deb12u1
ii  libselinux13.4-1+b6
ii  libssl33.0.13-1~deb12u1
ii  libsystemd-shared  252.26-1~deb12u2
ii  libsystemd0252.26-1~deb12u2
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+deb12u1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-1~deb12u1
ii  systemd-timesyncd [time-daemon]  252.26-1~deb12u2

Versions of packages systemd suggests:
ii  libfido2-11.12.0-2+b1
pn  libqrencode4  
ii  libtss2-esys-3.0.2-0  3.2.1-3
ii  libtss2-mu0   3.2.1-3
pn  libtss2-rc0   
ii  polkitd   122-3
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-1~deb12u1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 252.26-1~deb12u2
ii  libpam-systemd 252.26-1~deb12u2
ii  udev   252.26-1~deb12u2

- -- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
MaxFileSec=7day


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmaWS4YACgkQrh+Cd8S0
17ZwOA/+KHdPcvNvw+NU3Pl3ECzfqOPN16U38PcCti/GIJwBBWPvq6u28aYyOqLv
wpcGKrEGhE1poHgBBKB1i0JY9Xj0X243osdNFdhc/g6+pCP9WaVIY493JPXY2+mB
3t6KASCk4dZJMtxjWBG/ybCoYmBQ1e2Dc5fyCsfQkUXhB9KAexiBd8VmUURdlCuK
NPJuA8sP5e4vl9oeffgK1gPdywkiL78TX3CLUhTQkd1Mw3GKmFyR5+beImkckf4e
P8S5bKfq9+A2Eoay4VloiAP7Bcx1gEmMfVwtpYC3ETe5E/YFEOe70hyPdac0Wats
orsGkzmnX0XFwbk3q35oD7tCfTQ4eHV/ri8QwE0WBd9aSgWW5sjnwX8R6zxAI2sr
fTWejEuUVN47hMBcQVTKfApW8V2sKWlWnb0Z0TL2RU13wqGzmDmuOxdWyOvrTNCW
PREi8wE5PHRFdTYdE2vwvKWvx4Ub8Ay3VNLTx2dRBlMsqqiKPHsUUMRlyknK/rAw
pKdhrPrWr+IC+rMbBiWwXrw9NRYCZcQXh5HRclVT+ZjR9eLXu1LHcFeieeK1cecr
0cb/krlAyPSxkwA/o7sQEB+jbAz9LguFaSVRctS8tkSVS0YZ6hoN6ir3BtWFoSOq
XkSq0BdTyNpqKIi2IRfzXFFoQA8fJg6AMNEX/F4cp0duuc2SLbg=
=rvYg
-END PGP SIGNATURE-


Bug#1076072: slim: please Recommends libpam-gnome-keyring

2024-07-10 Thread Martin-Éric Racine
Package: slim
Version: 1.3.6-5.3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

heinä 10 13:05:31 geode slim[494]: PAM unable to dlopen(pam_gnome_keyring.so): 
/lib/security/pam_gnome_keyring.so: cannot open shared object file: No such 
file or directory
heinä 10 13:05:31 geode slim[494]: PAM adding faulty module: 
pam_gnome_keyring.so

Fixing this requires a Recommends on libpam-gnome-keyring.

Martin-Éric

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

Kernel: Linux 6.1.0-22-686 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
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 slim depends on:
ii  dbus   1.14.10-1~deb12u1
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u7
ii  libgcc-s1  12.2.0-14
ii  libjpeg62-turbo1:2.1.5-2
ii  libpam0g   1.5.2-6+deb12u1
ii  libpng16-161.6.39-2
ii  libstdc++6 12.2.0-14
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxext6   2:1.3.4-1+b1
ii  libxft22.3.6-1
ii  libxmu62:1.1.3-3
ii  libxrandr2 2:1.5.2-2+b1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages slim recommends:
ii  xterm  379-1

Versions of packages slim suggests:
pn  scrot  
ii  xauth  1:1.1.2-1

- -- debconf information:
* shared/default-x-display-manager: slim
  slim/daemon_name: /usr/bin/slim

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmaOXqkACgkQrh+Cd8S0
17YjXhAAo/H2XD3kHQSiSFNC/F6km3WEN9JQse2hB5bY4QtABCasqpkJmC997AEI
tf+tizu5Tobw3Ol+gH0iylrkbPxeuvwTilB5kobcinlqXeol152F0r0fY60rz8vs
vhQ2osGKUxQQ5EvJKiN+Pxdaj/BOId5ZrP6iVCCBmkPobUUGmMGZCeEZaxSDUlLd
Gw1arAYI2YsvDZ2MMXkNGogpTxkim6lpNWRtiZlL+K3rOo2mqLpD4+o3xlY02f+M
60E8XBxW3DoEBB0hXu0TbzmVTrj4j6kKIHBvXs7CSezN7J9lUfy7hbE8VIHYczXK
pDBfb8Et8sVpxiaiNNHL5NfX5GJfpY8unZyHC4/s5EPCqabMiw4rvz0vy0jD+Icq
RPFAZcuFSr9izg7lggYC/ElmFj6zeQkDb57ykRGPfW98QlsHQQLrqs1cXV3p08ie
7G6iGhwvV1YP7/x2Ltvk+b1/SrVzXd8pPFPubWbMS4mN2quG8dShp3MR+erepwGB
PwGsQCRf0lwgDFiRbt91lQrpSRfJUpHVFAvUgoc6Jv6DwKwt8z3E9ED3D/8D0AxH
0Ef4fmgNAK3gIhLrn9KiiWRmpDgBtRRwgQaC+89LD63atZ4/X6OUTwFkedQINUoz
KKJtB7856CHw8E4aH9EkmuU3DaJosFUqbNnxJRk8Z11Awk6akXI=
=U7kX
-END PGP SIGNATURE-


Bug#1076070: rsyslogd: error during parsing file /etc/rsyslog.d/50-default.conf, on or before line 46: warnings occurred in file '/etc/rsyslog.d/50-default.conf' around line 46 [v8.2302.0 try https://

2024-07-10 Thread Martin-Éric Racine
Package: rsyslog
Version: 8.2302.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I get the following error with the stock config:

rsyslogd: error during parsing file /etc/rsyslog.d/50-default.conf, on or 
before line 46: warnings occurred in file '/etc/rsyslog.d/50-default.conf' 
around line 46 [v8.2302.0 try https://www.rsyslog.com/e/2207 ]

This seems to be caused by the following line after the comments:

#
# Emergencies are sent to everybody logged in.
#
*.emerg *

This was among the results of "sudo journalctl -p 3 -xb".

Martin-Éric

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

Kernel: Linux 6.1.0-22-686 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
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 rsyslog depends on:
ii  libc6 2.36-9+deb12u7
ii  libestr0  0.1.11-1
ii  libfastjson4  1.2304.0-1
ii  liblognorm5   2.0.6-4
ii  libsystemd0   252.26-1~deb12u2
ii  libuuid1  2.38.1-5+deb12u1
ii  libzstd1  1.5.4+dfsg2-5
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages rsyslog recommends:
ii  logrotate  3.21.0-1

Versions of packages rsyslog suggests:
pn  rsyslog-doc   
pn  rsyslog-gssapi
pn  rsyslog-mongodb   
pn  rsyslog-mysql | rsyslog-pgsql 
pn  rsyslog-openssl | rsyslog-gnutls  
pn  rsyslog-relp  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmaOUN8ACgkQrh+Cd8S0
17bYFw//fcY7h46QCtpAczqjfM/7dAULCt2YYowUQL9RptrIjyHjscvG82pw77Fh
zhW9DipplGo1OxIkS6IxBX7xrg9Qcg7481FSfDX9yNwjw7b8BxoxMJQ0WKTQtawe
eD21e7zIB5Cxqr3IoiFtZoWmyT5Gb6RTdtNjfMSvlQ7sNC58ByuT/jUnjJ9AxTCP
lpfJ5yME7ifqYwdEHahNo3vD8xXdQZYNA6o8J6QXynt41lTIjJv8nBpJ+SOcgnQQ
nr1iA0ZC5nlAoGAVW+drVVLFYKQR9qvGtdjqo1DLdZQXCzao/V9XlChwxskbbgXs
nLgCTXh1kUcjKdypfA0gcN1/erH2GXZUrsRuTXwGNm72nGv9DMEaQxmFViYc+yQq
acX//OksYdg7kmvwNFYOD4reuhRrcV6W1NywiEvU8GIyoZbdqCZ3ixU89N7RKESz
M7avYE57V3PPd9Z7JMwYMyjs7XFxIIp0NtLM3HNElTJ/5kSlkisHebm/X2mtgTMu
ItGA4WCAli1hlVLIrHrANh+qYTQFc/Yp2zOWrdDJyDaUJ8zMGkaZjEFhShZ+cK2R
UTFMIMETwgPmugLVU8XDIHTUP7OT7Tf3aQNEOD1ChbrXwjip97aboBtTSmo2qyEb
3aCWtdSaPyjojv0ldfqB8xV+OWEHsGHS8oWyEQXBxboKu1JjXz8=
=jc+A
-END PGP SIGNATURE-


Bug#1060011: ERROR: Clamonacc: at least one of OnAccessExcludeUID, OnAccessExcludeUname, or OnAccessExcludeRootUID must be specified

2024-07-10 Thread Martin-Éric Racine
Package: clamav-daemon
Followup-For: Bug #1060011

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This issue remains unresolved. Can you please fix that service file?

Thanks!
Martin-Éric

- -- 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-22-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 clamav-daemon depends on:
ii  adduser 3.134
ii  clamav-base 1.0.5+dfsg-1~deb12u1
ii  clamav-freshclam [clamav-data]  1.0.5+dfsg-1~deb12u1
ii  debconf [debconf-2.0]   1.5.82
ii  dpkg1.21.22
ii  init-system-helpers 1.65.2
ii  libc6   2.36-9+deb12u7
ii  libclamav11 1.0.5+dfsg-1~deb12u1
ii  libcurl47.88.1-10+deb12u6
ii  libncurses6 6.4-4
ii  libsystemd0 252.26-1~deb12u2
ii  libtinfo6   6.4-4
ii  procps  2:4.0.2-3
ii  ucf 3.0043+nmu1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages clamav-daemon recommends:
ii  clamdscan  1.0.5+dfsg-1~deb12u1

Versions of packages clamav-daemon suggests:
ii  apparmor  3.0.8-3
pn  clamav-docs   
pn  daemon
pn  libclamunrar  

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmaOS8wACgkQrh+Cd8S0
17Z+3Q//RFTDCXESNHxXgwoiFMA5z/Aia1X9IbsXzv4R9A/CSIVF6sTvyzKfyKJs
+CDJUpRT6PmRlnMdyGwB/FJdRCcoKXSTlDueRcg0fp1rpDNfwHGj2dfi6Kbg6zY1
2J9kjnLgH9SAhq6+Q3bCuKKL91/1Doy4P4z8VWHhmfFDqoufkBcZBk0E63oBh0Ey
hDn+MTh0UkBTGtyrJwom4Ud7pHXXDpycoWyVPCMdWWMAlWdvsqmzk28Kr1PYJoq7
TBWfKzVmKHyLUJ4osojjGzRRQuZlwpFXrql1SVU5nltcgdhA9MscpMvw1j4fsdwd
YuwN3F2fMXSPMboWJK0l72N5YxdOGFIlhQ1lLWcrM08TqPHEew7GLUKH2sVe4v+Q
3XcU49/0fC4jc5xKGJlZmzUVW3kLXSEwyBsK58SYgjfuHQB8cJdjbqllnCfE30bq
1roBTVij2zbCrxEsjqoN62qypBxljf6/l54IbMWMjT5IzkIFnPI4ruSzEgOhp/S7
2SviGyV9iyjJX/yYAe16gov0Peojvdyd5OwdLn2e0g6m/G2UKVXU+iZ0hkB89l3P
d/iVNgmYSDTZ5W78HNweO1EGiNswjPumsM+3hAfElnHGuVhsBx4dMLPmrJ5u6B8e
4iFdZ/Nte4gWx59CiBFQtn5hIHhq5ue8VFldxc5lveVAXBx2Joo=
=EHrA
-END PGP SIGNATURE-


Bug#1036448: dh-autoreconf: please perform autoupdate too

2024-07-08 Thread Martin-Éric Racine
ma 8. heinäk. 2024 klo 15.30 Julian Andres Klode (j...@debian.org) kirjoitti:
>
> On Sun, Jul 07, 2024 at 12:41:44PM GMT, Martin-Éric Racine wrote:
> > Package: dh-autoreconf
> > Version: 20
> > Followup-For: Bug #1036448
> >
> > Greetings,
> >
> > Has there been any progress on this?
>
> If we want to do this for the next debhelper compat level,
> we need to figure out when to call autoupdate, and possibly
> also need a switch to disable it.

Why would this necessitate a new compat level?

> It's not clear to me that this is something we should always
> be running, maybe it is?

I think it is. There's a lot of code that upstream ships with outdated macros.

> I'm not particularly concerned about this issue, after all,
> you can easily run autoupdate yourself anyway using something
> like:
>
> override_dh_autoreconf:
> dh_autoreconf debian/rules autoreconf
>
> autoreconf:
> autoupdate -f
> autoreconf -f -i

Last time I tried something similar, dpkg barfed and asked me to create a patch.

Martin-Éric



Bug#1036448: dh-autoreconf: please perform autoupdate too

2024-07-07 Thread Martin-Éric Racine
Package: dh-autoreconf
Version: 20
Followup-For: Bug #1036448

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Greetings,

Has there been any progress on this?

Martin-Éric


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

Kernel: Linux 6.1.0-22-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 dh-autoreconf depends on:
ii  autoconf   2.71-3
ii  automake   1:1.16.5-1.3
ii  autopoint  0.22.5-1
ii  debhelper  13.16
ii  libdebhelper-perl  13.16
ii  libtool2.4.7-7
ii  perl   5.38.2-5

dh-autoreconf recommends no packages.

dh-autoreconf suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmaKYtUACgkQrh+Cd8S0
17bD0A/9EH/23xJ9zIC/JhcFZs4j8J5TstmNMzm24vtXNA89QO0NMBig9+jmwBkW
SIdhwfcAbrr591oDbJjzJHwQ51NzgYqPA23X/4kxXaRm2JbvIftCWauh3SIbjqHj
DZUi3p08/qp866g1kIGHrOzRKkaDMoUV01LNz2FSXkxrMN7BI1BgjESBz6MS0vS+
1Gz0mkjah/2y3wL1WO/23EwWAALGbS00Lmk593vslzC5aMVG5t8I21W8NKojDU6w
0DG9JfxDJoaR9xtI9L/8MVcfqGyLYHb60mKTcn7xFJ1P9xu0yjxyEKnLUUwXlFQh
koepvz+UX+sbUGCdOyj4/cK1mqD7NunwELMbt8+oi62utDakOmu7VPSXKRQIRRdt
3DIa1n+olf+wkouDgB5aKTQsUwpoC+3fJss/2XZUHH2N97DdvB17n40DlJuug6Ca
ZAUXaH/oydvj04fbfn0LG478W4RyAEXbkOduAGk9SpJ4KSufFW9ocpyrf9eEGbKd
JPvASZjzxVE855RZzsfabyg3G9OzMhxYkL0WODk6v22ldTgiGBqR0Q1UouJznfGU
SX/dQ9wsDvnslO4eqDvWCOLAeRi4LEPdZvKvijvYeW7agqVgy2BYSoYUy8ISgmiS
dz5g7UN3Mvjy59wj5J59yCm/3dIDjsqGWPoTCacKxfmsu1E7NFs=
=m9u1
-END PGP SIGNATURE-


Bug#1073992: pci.ids: configuration fails

2024-06-22 Thread Martin-Éric Racine
la 22. kesäk. 2024 klo 14.39 Chris Hofstaedtler (z...@debian.org) kirjoitti:
>
> On Fri, Jun 21, 2024 at 01:42:59PM +0300, Martin-Éric Racine wrote:
> > APT logs and 'dpkg -L debconf' are attached.
>
> Could you also attach dpkg.log? That might reveal which package was
> deconfigured there.

Attached.

Martin-Éric
2024-06-21 10:50:49 startup archives unpack
2024-06-21 10:50:57 upgrade sysvinit-utils:i386 3.09-1 3.09-2
2024-06-21 10:50:57 status half-configured sysvinit-utils:i386 3.09-1
2024-06-21 10:50:57 status unpacked sysvinit-utils:i386 3.09-1
2024-06-21 10:50:57 status half-installed sysvinit-utils:i386 3.09-1
2024-06-21 10:50:58 status triggers-pending man-db:i386 2.12.1-2
2024-06-21 10:50:58 status unpacked sysvinit-utils:i386 3.09-2
2024-06-21 10:51:00 startup packages configure
2024-06-21 10:51:00 configure sysvinit-utils:i386 3.09-2 
2024-06-21 10:51:00 status unpacked sysvinit-utils:i386 3.09-2
2024-06-21 10:51:00 status half-configured sysvinit-utils:i386 3.09-2
2024-06-21 10:51:01 status installed sysvinit-utils:i386 3.09-2
2024-06-21 10:51:02 startup archives unpack
2024-06-21 10:51:03 upgrade ntfs-3g:i386 1:2022.10.3-2 1:2022.10.3-3
2024-06-21 10:51:03 status triggers-pending initramfs-tools:all 0.142
2024-06-21 10:51:03 status half-configured ntfs-3g:i386 1:2022.10.3-2
2024-06-21 10:51:03 status unpacked ntfs-3g:i386 1:2022.10.3-2
2024-06-21 10:51:03 status half-installed ntfs-3g:i386 1:2022.10.3-2
2024-06-21 10:51:04 status unpacked ntfs-3g:i386 1:2022.10.3-3
2024-06-21 10:51:05 upgrade libntfs-3g89t64:i386 1:2022.10.3-2 1:2022.10.3-3
2024-06-21 10:51:05 status triggers-pending libc-bin:i386 2.38-13
2024-06-21 10:51:05 status half-configured libntfs-3g89t64:i386 1:2022.10.3-2
2024-06-21 10:51:05 status unpacked libntfs-3g89t64:i386 1:2022.10.3-2
2024-06-21 10:51:06 status half-installed libntfs-3g89t64:i386 1:2022.10.3-2
2024-06-21 10:51:06 status unpacked libntfs-3g89t64:i386 1:2022.10.3-3
2024-06-21 10:51:07 upgrade libgprofng0:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:07 status half-configured libgprofng0:i386 2.42-4
2024-06-21 10:51:07 status unpacked libgprofng0:i386 2.42-4
2024-06-21 10:51:08 status half-installed libgprofng0:i386 2.42-4
2024-06-21 10:51:09 status unpacked libgprofng0:i386 2.42.50.20240618-1
2024-06-21 10:51:09 upgrade libctf0:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:09 status half-configured libctf0:i386 2.42-4
2024-06-21 10:51:09 status unpacked libctf0:i386 2.42-4
2024-06-21 10:51:09 status half-installed libctf0:i386 2.42-4
2024-06-21 10:51:10 status unpacked libctf0:i386 2.42.50.20240618-1
2024-06-21 10:51:10 upgrade libctf-nobfd0:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:10 status half-configured libctf-nobfd0:i386 2.42-4
2024-06-21 10:51:10 status unpacked libctf-nobfd0:i386 2.42-4
2024-06-21 10:51:11 status half-installed libctf-nobfd0:i386 2.42-4
2024-06-21 10:51:11 status unpacked libctf-nobfd0:i386 2.42.50.20240618-1
2024-06-21 10:51:11 upgrade binutils-i686-linux-gnu:i386 2.42-4 
2.42.50.20240618-1
2024-06-21 10:51:11 status half-configured binutils-i686-linux-gnu:i386 2.42-4
2024-06-21 10:51:11 status unpacked binutils-i686-linux-gnu:i386 2.42-4
2024-06-21 10:51:12 status half-installed binutils-i686-linux-gnu:i386 2.42-4
2024-06-21 10:51:14 status unpacked binutils-i686-linux-gnu:i386 
2.42.50.20240618-1
2024-06-21 10:51:15 upgrade binutils:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:15 status half-configured binutils:i386 2.42-4
2024-06-21 10:51:15 status unpacked binutils:i386 2.42-4
2024-06-21 10:51:15 status half-installed binutils:i386 2.42-4
2024-06-21 10:51:15 status unpacked binutils:i386 2.42.50.20240618-1
2024-06-21 10:51:16 upgrade libbinutils:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:16 status half-configured libbinutils:i386 2.42-4
2024-06-21 10:51:16 status unpacked libbinutils:i386 2.42-4
2024-06-21 10:51:16 status half-installed libbinutils:i386 2.42-4
2024-06-21 10:51:17 status unpacked libbinutils:i386 2.42.50.20240618-1
2024-06-21 10:51:17 upgrade binutils-common:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:17 status half-configured binutils-common:i386 2.42-4
2024-06-21 10:51:17 status unpacked binutils-common:i386 2.42-4
2024-06-21 10:51:17 status half-installed binutils-common:i386 2.42-4
2024-06-21 10:51:20 status unpacked binutils-common:i386 2.42.50.20240618-1
2024-06-21 10:51:20 upgrade libsframe1:i386 2.42-4 2.42.50.20240618-1
2024-06-21 10:51:20 status half-configured libsframe1:i386 2.42-4
2024-06-21 10:51:20 status unpacked libsframe1:i386 2.42-4
2024-06-21 10:51:21 status half-installed libsframe1:i386 2.42-4
2024-06-21 10:51:21 status unpacked libsframe1:i386 2.42.50.20240618-1
2024-06-21 10:51:22 upgrade libbpf1:i386 1:1.4.2-1 1:1.4.3-1
2024-06-21 10:51:22 status half-configured libbpf1:i386 1:1.4.2-1
2024-06-21 10:51:22 status unpacked libbpf1:i386 1:1.4.2-1
2024-06-21 10:51:22 status half-installed libbpf1:i386 1:1.4.2-1
2024-06-21 10:51:22 status unpac

Bug#1073992: pci.ids: configuration fails

2024-06-21 Thread Martin-Éric Racine
Hi!
pe 21. kesäk. 2024 klo 13.18 Guillem Jover (guil...@debian.org) kirjoitti:
> There is not enough context in the report to really see what's going
> on here.

Agreed. APT remains pretty vague on exactly what caused this.

> On Fri, 2024-06-21 at 10:53:20 +0300, Martin-Éric Racine wrote:
> > Package: pci.ids
> > Version: 0.0~2024.05.31-1
> > Severity: normal
>
> > 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) ...
>
> I don't see pci.ids failing to configure, at least there's no error
> message after «Setting up» which would indicate that step of the
> process. The errors happen between Unpacking and Setting up, but then
> pci.ids has no debconf support at all, so this should be something
> else. I'd assume something (apt perhaps?) is invoking something
> debconf related in-between. But then the modules being complained
> about are all inside debconf, so if those are failing then this would
> look like a debconf issue?

Possibly.

> In any case:
>   - this is definitely not a pci.ids issue,
>   - it's not clear who is invoking debconf (checking logs might help),
>   - this looks like a potential debconf issue (but could be something
> else, like damaged system or partially configured packages).

APT logs and 'dpkg -L debconf' are attached.

> So I'd either close this, or reassign, but it's not clear where, and
> given the unclear culprit I'm a bit reluctant to dump this as is into
> someone else tracker. :/

I'm as baffled as you are. I just noticed debconf barfing at the
pci.ids point and pasted what I saw.

Martin-Éric
Log started: 2024-06-21  10:50:49
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 47805 files and directories currently installed.)
Preparing to unpack .../sysvinit-utils_3.09-2_i386.deb ...
Unpacking sysvinit-utils (3.09-2) over (3.09-1) ...
Setting up sysvinit-utils (3.09-2) ...
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 47805 files and directories currently installed.)
Preparing to unpack .../00-ntfs-3g_1%3a2022.10.3-3_i386.deb ...
Unpacking ntfs-3g (1:2022.10.3-3) over (1:2022.10.3-2) ...
Preparing to unpack .../01-libntfs-3g89t64_1%3a2022.10.3-3_i386.deb ...
Adding 'diversion of /lib/i386-linux-gnu/libntfs-3g.so.89 to 
/lib/i386-linux-gnu/libntfs-3g.so.89.usr-is-merged by libntfs-3g89t64'
Adding 'diversion of /lib/i386-linux-gnu/libntfs-3g.so.89.0.0 to 
/lib/i386-linux-gnu/libntfs-3g.so.89.0.0.usr-is-merged by libntfs-3g89t64'
Unpacking libntfs-3g89t64:i386 (1:2022.10.3-3) over (1:2022.10.3-2) ...
Preparing to unpack .../02-libgprofng0_2.42.50.20240618-1_i386.deb ...
Unpacking libgprofng0:i386 (2.42.50.20240618-1) over (2.42-4) ...
Preparing to unpack .../03-libctf0_2.42.50.20240618-1_i386.deb ...
Unpacking libctf0:i386 (2.42.50.20240618-1) over (2.42-4) ...
Preparing to unpack .../04-libctf-nobfd0_2.42.50.20240618-1_i386.deb ...
Unpacking libctf

Bug#939713: add support for ifupdown bridge

2024-06-21 Thread Martin-Éric Racine
Package: ifupdown
Followup-For: Bug #939713

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Howdy!

Is there any news on this?

Getting rid of the deprecated bridge-utils and implementing support for setting 
up bridges using 'ip' from iproute2 (ifupdown already depends on this) would be 
extremely desirable.

Martin-Éric

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

Kernel: Linux 6.1.0-21-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 ifupdown depends on:
ii  adduser   3.137
ii  iproute2  6.9.0-1
ii  libc6 2.38-13

Versions of packages ifupdown recommends:
pn  isc-dhcp-client | dhcp-client  

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZ1PKwACgkQrh+Cd8S0
17ZufRAAgyLP5+ph2ujHmf2638K0pqG5vb4fk6gXlkMOvo/Idvgh3PvZW4Y/lfg3
1ajcfz4oXeh+W2SpJJKQeP+vvfGdjm3EEytsI5ry0E5NkDJOP2A9jLOMO1LGcGXO
u/3r1U16ydHDZTku2WZWIU7E1kxAza2hCE4K1jVgZXvFeIPkxZB6EjfZE1cSgtt0
RZSRDF33bH0WM5ERzvvKt7vZ94w2qrcAmq7QEuq8qEuBv16zZT18nogwlQRcjCYh
VKgNMvGyqCjpPwDfSgmNWQN2J2XD45T2DOrQC/RlWcFW3rYFXYvHHnnur22b57Lv
ZYdnxJBT/jX9fHVjieV/LaQwnF6R2Z80LajzYfFC4uyx9TQ31eswlf6hKA0TVn5G
fVPZ9r57ycRMxf7nBxoghbXPTRMGFBzb1IhxLibz+rFyyxJmmLD5qcq9l44ZTTi2
BOaeMyQqMsqhEXnvN907A9KamD0tFeYoWSk38XXRqQTY0UgbIndHt5gzZb8OdGEN
VuHyDGSHALhR8NqZTFIMT2Whg67MMG7fmc+lfDf+gIZOR945fJx+2nP453HJfqOI
Vt+YxA2s/9R+K4TFdePlXgdZ2r1AARO/5aXM6vnaY80HhDmsvLG+/rbr0+wsrGQi
6FM1p8Tw623c5NEVsv96FWWwDZLukpkuf/vY2DOpBeEn6OSoWHE=
=U5PH
-END PGP SIGNATURE-


Bug#1073992: pci.ids: configuration fails

2024-06-21 Thread Martin-Éric Racine
Package: pci.ids
Version: 0.0~2024.05.31-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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

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

Kernel: Linux 6.8.12-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+Cd8S017YFAmZ1MWoACgkQrh+Cd8S0
17bMkQ/+PvdIKRvN4rhWNXlsLFhTBEdw5AHWUC1RdvQZjquGNj49OaTx0V9UKOno
zHyNYbtKZZdWCPMSB+/YvdLG/7R95d+6c1sEVry6YPj70KAuhAJOJafMYfq7BNa8
tVGmlP9kct7LRW+KplV0CI8M8F9stqbWmbwRJ37M6mQYp0wVpszqCoxV98XKqtuc
nzpgYXdG6nGoe7XuVfaQLpjw2DWqYThj7b9nRMvufoCmapthXxi+djJaclkfQaoU
9e5sPw2YnP0UBFN97kV+2PR2yiKkc0qYiWaGcos3/JYIBNp5D3bFbREE4Y2x2CdE
IVtIBvETah+YZ5RyXmYeEALMKyJbrr9Yz6g0vF9k9QucW34EYcuWkOfhnAEEn2o6
svm4YAnb786H00bY/0RW0luZI/o/iZJBC6jqDfK9v7++ueMdPC0Im7PEbIEqbOZu
UgnswgPf0QG4mZjNbuxD+cI7qI0WxDAK76NX9FsNrax55/4ybcve2SmbXk7JCibw
OW5Jz6RPB6p/PQPSJD+NiYSguIE+YpyNCoS9dnRfLlEe1MYW+fxTpz05NAoYT2Bm
IDXLseivESILsBptapu9pzdMMRuCDmHI6pF2JeH8Dc9vhhOGt4UOg2JH280qsJAn
6hakwz7w7l3sePOGcNn1gd5CobSTqIxEX+xfN1+7vkhuzVav02o=
=80GF
-END PGP SIGNATURE-



Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration

2024-06-20 Thread Martin-Éric Racine
to 20. kesäk. 2024 klo 11.32 Nicolas Cavallari
(nicolas.cavall...@green-communications.fr) kirjoitti:
>
> On 18/06/2024 16:39, Martin-Éric Racine wrote:
> > ti 18. kesäk. 2024 klo 15.52 Nicolas Cavallari
> > (nicolas.cavall...@green-communications.fr) kirjoitti:
> >>
> >> On 18/06/2024 13:14, Martin-Éric Racine wrote:
> >>> su 16. kesäk. 2024 klo 9.05 Martin-Éric Racine
> >>> (martin-eric.rac...@iki.fi) kirjoitti:
> >>>>
> >>>> la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari
> >>>> (nicolas.cavall...@green-communications.fr) kirjoitti:
> >>>>
> >>>>> I didn't check if there were any adverse effect or if leases are still
> >>>>> renewed. I can't check on the production system before Monday.
> >>>>
> >>>> Please let me know.
> >>>
> >>> Any news on this?
> >>
> >> My dedicated server receives leases of 86400s, it takes a while to check
> >> if leases are renewed correctly.
> >
> > Noted.
>
> After two days and multiples renews, I can confirm that it works.

Excellent. I'll upload to bookworm-pu.

Martin-Éric



Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration

2024-06-18 Thread Martin-Éric Racine
ti 18. kesäk. 2024 klo 15.52 Nicolas Cavallari
(nicolas.cavall...@green-communications.fr) kirjoitti:
>
> On 18/06/2024 13:14, Martin-Éric Racine wrote:
> > su 16. kesäk. 2024 klo 9.05 Martin-Éric Racine
> > (martin-eric.rac...@iki.fi) kirjoitti:
> >>
> >> la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari
> >> (nicolas.cavall...@green-communications.fr) kirjoitti:
> >>
> >>> I didn't check if there were any adverse effect or if leases are still
> >>> renewed. I can't check on the production system before Monday.
> >>
> >> Please let me know.
> >
> > Any news on this?
>
> My dedicated server receives leases of 86400s, it takes a while to check
> if leases are renewed correctly.

Noted.

> I installed it today. For some reason, dhcpcd was stopped when upgrading
> the 'dhcpcd' package but was not restarted afterward. Looking at the
> dhcpcd maintainer scripts, I see the deb-systemd-invoke stop in preinst
> but i don't see any start in postinst or anywhere else.

Which was fixed in Testing a while back.

For Stable, this is what I would upload, once you've confirmed that
the 3 cherry-picks work:

dhcpcd5 (9.4.1-24~deb12u4) bookworm; urgency=medium
  * Add --no-stop-on-upgrade --no-restart-after-upgrade (Closes: #1057959).
  * Cherry-pick upstream backported fixes for RC bug (Closes: #1050805).
  * Update dhcpcd.preinst version check to match current one.

On the plus side, no attempt will be made to restart it, to prevent
connection loss. On the minus side, it means that the administrator
must restart manually or reboot.

Martin-Éric



Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration

2024-06-18 Thread Martin-Éric Racine
su 16. kesäk. 2024 klo 9.05 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari
> (nicolas.cavall...@green-communications.fr) kirjoitti:
> >
> > On 15/06/2024 11:33, Martin-Éric Racine wrote:
> > > On Tue, 29 Aug 2023 13:17:51 +0200 Nicolas Cavallari
> > >> This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2
> > >> (stable proposed update) but not 1:10.0.2-4 (testing/unstable) as
> > >> upstream fixed it in 10.0.2:
> > >>
> > >> Upstream Bug report: 
> > >> https://github.com/NetworkConfiguration/dhcpcd/issues/179
> > >> Upstream Fix: 
> > >> https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae
> > >>
> > >> This patch does not apply cleanly to 9.4.1 because the privsep
> > >> structure changed in 10.0.2.  It's likely that only the src/privsep.c
> > >> hunks about len == 0 and eloop_exit() needs to be backported, the other
> > >> changes are just here to avoid compiler warnings about unused
> > >> parameters.
> > >
> > > Upstream got around releasing a backport of this for branch 9 as
> > > commits 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 and
> > > 6e127eac6903524d401b31893167e4529b8ab111 respectively.
> > >
> > > You are hereby invited to test and report whether this fixes it for 
> > > Stable.
> >
> > I did some quick tests on a VM:
> >
> > First, with 9.4.1-24~deb12u3 as present in debian stable:
>
> > Then I apt sourced dhcpcd, applied the two patches, rebuilt debian
> > packages and tested them.  The situation is now worse:
>
> > I then tested this patch from issue #283:
> >
> > https://github.com/NetworkConfiguration/dhcpcd/commit/727c78f503d456875e2a3cee7609288b537d9d25.patch
> >
> > And this time, it appears to fix the problem:
>
> > I didn't check if there were any adverse effect or if leases are still
> > renewed. I can't check on the production system before Monday.
>
> Please let me know.

Any news on this?

Martin-Éric



Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out

2024-06-17 Thread Martin-Éric Racine
to 13. kesäk. 2024 klo 11.52 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> Adding the dnsmasq maintainer in CC.
>
> to 13. kesäk. 2024 klo 11.39 Paul Gevers (elb...@debian.org) kirjoitti:
> > On 13-06-2024 3:36 a.m., Martin-Éric Racine wrote:
> > > Subsequent ones randomly timeout waiting for an IP from the DHCP
> > > server. This could well be an issue with dnsmasq, which is what we use
> > > for the test. Alternately, it could be caused by those constant fails
> > > on glibc. Without more detailed logs, I am not in a position to
> > > investigate this. Help is welcome.
> >
> > Well, I can't give you more logs than what your test writes. So that's
> > in your hands, I suggest you try and make the test more verbose of
> > what's going on, or maybe ensure some logs end up in the artifacts for
> > inspection. Also, if dnsmasq is the problem, you might want to contact
> > the maintainer and discuss the issue (e.g. in a bug report). From my
> > standpoint, it's the autopkgtest of dhcpcd that's having issues and that
> > *is* an issue for src:dhcpcd. You could reassign this bug and mark it
> > "affects dhcpcd".
>
> I'm curious to hear whether any of what appears in the log rings any
> bell for Simon.
>
> > I acknowledge that something fishy seems to be ongoing in the archive
> > when new version of src:glibc binaries appear (not only with dhcpcd I
> > mean). For now I'll not hold that against autopkgtest failures of
> > packages too much.
>
> Which is where I suspect the real issue is.
>
> Personally, I already find it suspicious that the tracker tells me
> about unrelated packages' transitions or issues. If the problem is in
> someone else's code, while mine hasn't changed in ages, that's where
> the bug report needs to go. In this case, dhcpcd's autopkgtest hasn't
> changed in ages, and has been verified to work as-is at Ubuntu, where
> isolation machines were implemented a long time before Debian.

Sorry Paul but, at this point, I'm gonna call CI itself flaky.

Right now, CI hasn't even registered any test attemps for recent
uploads to Unstable and its results for Testing out of sync. Given
this, if you're gonna start mass-filing bugs against any package whose
test reults show discrepancy, first make sure that, in fact, your code
is not the one causing others unnecesary work.

Martin-Éric



Bug#1073261: bookworm-pu: package dhcpcd5/9.4.1-24~deb12u4

2024-06-16 Thread Martin-Éric Racine
la 15. kesäk. 2024 klo 18.04 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> la 15. kesäk. 2024 klo 17.48 Adam D. Barratt
> (a...@adam-barratt.org.uk) kirjoitti:
> >
> > Control: tags -1 + confirmed
> >
> > On Sat, 2024-06-15 at 14:38 +0300, Martin-Éric Racine wrote:
> > > RC bug #1050805 was fixed in Testing with src:dhcpcd 10.0.2, but
> > > upstream only got around back-porting the fix to Stable src:dhcpcd5
> > > 9.x.x today.
> >
> > Please go ahead.
>
> Thanks. Awaiting confirmation from the bug reporter that it fixes the
> issue for him and I'll upload.

Fixing this for Stable apparently requires cherry-picking a third
patch. Updated debdiff attached.

Martin-Éric
diff -Nru dhcpcd5-9.4.1/debian/changelog dhcpcd5-9.4.1/debian/changelog
--- dhcpcd5-9.4.1/debian/changelog  2023-10-20 11:12:13.0 +0300
+++ dhcpcd5-9.4.1/debian/changelog  2024-06-15 12:37:49.0 +0300
@@ -1,3 +1,11 @@
+dhcpcd5 (9.4.1-24~deb12u4) bookworm; urgency=medium
+
+  * Add --no-stop-on-upgrade --no-restart-after-upgrade (Closes: #1057959).
+  * Cherry-pick upstream backported fixes for RC bug (Closes: #1050805).
+  * Update dhcpcd.preinst version check to match current one.
+
+ -- Martin-Éric Racine   Sat, 15 Jun 2024 12:37:49 
+0300
+
 dhcpcd5 (9.4.1-24~deb12u3) bookworm; urgency=medium
 
   * Move Breaks/Replaces dhcpcd5 (<< 9.4.1-2) to Conflicts (Closes: #1053657).
diff -Nru dhcpcd5-9.4.1/debian/dhcpcd.preinst 
dhcpcd5-9.4.1/debian/dhcpcd.preinst
--- dhcpcd5-9.4.1/debian/dhcpcd.preinst 2023-10-20 11:12:08.0 +0300
+++ dhcpcd5-9.4.1/debian/dhcpcd.preinst 2023-12-13 22:50:19.0 +0200
@@ -2,7 +2,7 @@
 # As per Debian bug #1037190.
 # Copyright 2023 Andreas Beckmann 
 set -e
-if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24~deb12u3~" ; then
+if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24~deb12u4~" ; then
   # Cleanup leftovers from dhcpcd 1:3.* in Wheezy.
   # Can be removed after Trixie is released.
   update-alternatives --remove dhcpcd /sbin/dhcpcd3
diff -Nru 
dhcpcd5-9.4.1/debian/patches/53e2f6de4ba87d0534c89cae674e6c1a48724ef0.patch 
dhcpcd5-9.4.1/debian/patches/53e2f6de4ba87d0534c89cae674e6c1a48724ef0.patch
--- dhcpcd5-9.4.1/debian/patches/53e2f6de4ba87d0534c89cae674e6c1a48724ef0.patch 
1970-01-01 02:00:00.0 +0200
+++ dhcpcd5-9.4.1/debian/patches/53e2f6de4ba87d0534c89cae674e6c1a48724ef0.patch 
2024-06-15 12:34:41.0 +0300
@@ -0,0 +1,121 @@
+From 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 Mon Sep 17 00:00:00 2001
+From: Roy Marples 
+Date: Sat, 15 Jun 2024 10:04:06 +0100
+Subject: [PATCH] privsep: Allow zero length messages through
+
+They should be handled gracefully without privsep anyway.
+Fix for #179.
+---
+ src/privsep-inet.c | 12 ++--
+ src/privsep.c  | 15 +++
+ src/privsep.h  |  2 +-
+ 3 files changed, 10 insertions(+), 19 deletions(-)
+
+diff --git a/src/privsep-inet.c b/src/privsep-inet.c
+index 3a192ee0..7f7494f6 100644
+--- a/src/privsep-inet.c
 b/src/privsep-inet.c
+@@ -53,7 +53,7 @@ ps_inet_recvbootp(void *arg)
+ {
+   struct dhcpcd_ctx *ctx = arg;
+ 
+-  if (ps_recvmsg(ctx, ctx->udp_rfd, PS_BOOTP, ctx->ps_inet_fd) == -1)
++  if (ps_recvmsg(ctx->udp_rfd, PS_BOOTP, ctx->ps_inet_fd) == -1)
+   logerr(__func__);
+ }
+ #endif
+@@ -67,12 +67,12 @@ ps_inet_recvra(void *arg)
+   struct rs_state *state = RS_STATE(ifp);
+   struct dhcpcd_ctx *ctx = ifp->ctx;
+ 
+-  if (ps_recvmsg(ctx, state->nd_fd, PS_ND, ctx->ps_inet_fd) == -1)
++  if (ps_recvmsg(state->nd_fd, PS_ND, ctx->ps_inet_fd) == -1)
+   logerr(__func__);
+ #else
+   struct dhcpcd_ctx *ctx = arg;
+ 
+-  if (ps_recvmsg(ctx, ctx->nd_fd, PS_ND, ctx->ps_inet_fd) == -1)
++  if (ps_recvmsg(ctx->nd_fd, PS_ND, ctx->ps_inet_fd) == -1)
+   logerr(__func__);
+ #endif
+ }
+@@ -84,7 +84,7 @@ ps_inet_recvdhcp6(void *arg)
+ {
+   struct dhcpcd_ctx *ctx = arg;
+ 
+-  if (ps_recvmsg(ctx, ctx->dhcp6_rfd, PS_DHCP6, ctx->ps_inet_fd) == -1)
++  if (ps_recvmsg(ctx->dhcp6_rfd, PS_DHCP6, ctx->ps_inet_fd) == -1)
+   logerr(__func__);
+ }
+ #endif
+@@ -374,7 +374,7 @@ ps_inet_recvinbootp(void *arg)
+ {
+   struct ps_process *psp = arg;
+ 
+-  if (ps_recvmsg(psp->psp_ctx, psp->psp_work_fd,
++  if (ps_recvmsg(psp->psp_work_fd,
+   PS_BOOTP, psp->psp_ctx->ps_data_fd) == -1)
+   logerr(__func__);
+ }
+@@ -463,7 +463,7 @@ ps_inet_recvin6dhcp6(void *arg)
+ {
+   struct ps_process *psp = arg;
+ 
+-  if (ps_recvmsg(psp->psp_ctx, psp->psp_work_fd,
++  if (ps_recvmsg(psp->psp_work_fd,
+   PS_DHCP6, psp->psp_ctx->ps_data_fd) == -1)
+   logerr(__func__);
+ }
+diff --git a/src/privsep.c b/src/privsep.c
+index ab29bb7b..0f78907a 1006

Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration

2024-06-15 Thread Martin-Éric Racine
la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari
(nicolas.cavall...@green-communications.fr) kirjoitti:
>
> On 15/06/2024 11:33, Martin-Éric Racine wrote:
> > On Tue, 29 Aug 2023 13:17:51 +0200 Nicolas Cavallari
> >> This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2
> >> (stable proposed update) but not 1:10.0.2-4 (testing/unstable) as
> >> upstream fixed it in 10.0.2:
> >>
> >> Upstream Bug report: 
> >> https://github.com/NetworkConfiguration/dhcpcd/issues/179
> >> Upstream Fix: 
> >> https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae
> >>
> >> This patch does not apply cleanly to 9.4.1 because the privsep
> >> structure changed in 10.0.2.  It's likely that only the src/privsep.c
> >> hunks about len == 0 and eloop_exit() needs to be backported, the other
> >> changes are just here to avoid compiler warnings about unused
> >> parameters.
> >
> > Upstream got around releasing a backport of this for branch 9 as
> > commits 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 and
> > 6e127eac6903524d401b31893167e4529b8ab111 respectively.
> >
> > You are hereby invited to test and report whether this fixes it for Stable.
>
> I did some quick tests on a VM:
>
> First, with 9.4.1-24~deb12u3 as present in debian stable:

> Then I apt sourced dhcpcd, applied the two patches, rebuilt debian
> packages and tested them.  The situation is now worse:

> I then tested this patch from issue #283:
>
> https://github.com/NetworkConfiguration/dhcpcd/commit/727c78f503d456875e2a3cee7609288b537d9d25.patch
>
> And this time, it appears to fix the problem:

So you had to apply 3 patches to fix 9.4.1 in Stable? The 2
aforementioned ones and the one from upstream issue 283?

> I didn't check if there were any adverse effect or if leases are still
> renewed. I can't check on the production system before Monday.

Please let me know.

Martin-Éric



Bug#1073261: bookworm-pu: package dhcpcd5/9.4.1-24~deb12u4

2024-06-15 Thread Martin-Éric Racine
la 15. kesäk. 2024 klo 17.48 Adam D. Barratt
(a...@adam-barratt.org.uk) kirjoitti:
>
> Control: tags -1 + confirmed
>
> On Sat, 2024-06-15 at 14:38 +0300, Martin-Éric Racine wrote:
> > RC bug #1050805 was fixed in Testing with src:dhcpcd 10.0.2, but
> > upstream only got around back-porting the fix to Stable src:dhcpcd5
> > 9.x.x today.
>
> Please go ahead.

Thanks. Awaiting confirmation from the bug reporter that it fixes the
issue for him and I'll upload.

Martin-Éric



Bug#1073261: bookworm-pu: package dhcpcd5/9.4.1-24~deb12u4

2024-06-15 Thread Martin-Éric Racine
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: dhcp...@packages.debian.org
Control: affects -1 + src:dhcpcd5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[ Reason ]
RC bug #1050805 was fixed in Testing with src:dhcpcd 10.0.2, but upstream only 
got around back-porting the fix to Stable src:dhcpcd5 9.x.x today.

[ Impact ]
As per #1050805, "This bug can be triggered remotely over the internet from any 
UDP port and is critical on an internet-facing system that needs DHCP to get an 
IP address, such as a gateway, a dedicated server or a VM."

[ Tests ]
Verified to boot on a Stable host.

[ Risks ]
None.

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

[ Changes ]
* Add --no-stop-on-upgrade --no-restart-after-upgrade (Closes: #1057959).
* Cherry-pick upstream backported fixes for RC bug (Closes: #1050805).
* Update dhcpcd.preinst version check to match current one.


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZtfSEACgkQrh+Cd8S0
17afbA//b7UQXcbT6qtNheW5w53MyFeD2qQbqOOQ8qmiMm+rZJJ3w4oIjRZ6E4tY
TQRc90yRmR/3RxQb7h5XHomM1ERl29CDh5+03rhdtk1WOUcWM5q+aIjhYfeLsTk2
fUW7vZdH9NwTNs+IBEtTIGsnrpFg1CzWh63kBOO934RhVIUVWLzY5zZX7p44+atL
26yJRcOWMjmhh0ciWocbmMjVvuxmxBuoZczZoMR8Pg0YYCFo7qIjgOvfrxMJaOts
TK/kTuNGoyuF2dPGW9p9byscLk/EiGp1UivH2rOu4cAAyu4rV6Wb38cYm66lwdee
ZJRyoFu3YdDv8M+Bzrd+K/rdiSqFcZCpcioYqhdUQ84tcCc5HA/cBtRNr3Xe9wwO
+Jq3FBd4dE0UfK2Mh7xupVb4YzsFiuVB6LwqR4bu9NmZ3c29jjum6Piy+DseGLGU
PW6Svq5KBxO3SJUI5+sB/wRKI7Ziu95xURbFjq0NnB1LDw6YXofNpsu+pJMwczdU
67/FT9WCQTBD7rpS4TW+ykROGt0kQic2U50RNnh5j+R8f9u+B4VmbM06NhhcZ1NO
TKjc+abzaVLkEPamUig9Nq4QQxB7WmudsHFS+qSiTHsu/ouSG4KFGXWjxWIQw8PD
NIZyQu/+lsTdL46prN9pwGekEudGRX4oOVEbMOV5EZ1GDo2jq9g=
=SM4R
-END PGP SIGNATURE-
diff -Nru dhcpcd5-9.4.1/debian/changelog dhcpcd5-9.4.1/debian/changelog
--- dhcpcd5-9.4.1/debian/changelog  2023-10-20 11:12:13.0 +0300
+++ dhcpcd5-9.4.1/debian/changelog  2024-06-15 12:37:49.0 +0300
@@ -1,3 +1,11 @@
+dhcpcd5 (9.4.1-24~deb12u4) bookworm; urgency=medium
+
+  * Add --no-stop-on-upgrade --no-restart-after-upgrade (Closes: #1057959).
+  * Cherry-pick upstream backported fixes for RC bug (Closes: #1050805).
+  * Update dhcpcd.preinst version check to match current one.
+
+ -- Martin-Éric Racine   Sat, 15 Jun 2024 12:37:49 
+0300
+
 dhcpcd5 (9.4.1-24~deb12u3) bookworm; urgency=medium
 
   * Move Breaks/Replaces dhcpcd5 (<< 9.4.1-2) to Conflicts (Closes: #1053657).
diff -Nru dhcpcd5-9.4.1/debian/dhcpcd.preinst 
dhcpcd5-9.4.1/debian/dhcpcd.preinst
--- dhcpcd5-9.4.1/debian/dhcpcd.preinst 2023-10-20 11:12:08.0 +0300
+++ dhcpcd5-9.4.1/debian/dhcpcd.preinst 2023-12-13 22:50:19.0 +0200
@@ -2,7 +2,7 @@
 # As per Debian bug #1037190.
 # Copyright 2023 Andreas Beckmann 
 set -e
-if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24~deb12u3~" ; then
+if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24~deb12u4~" ; then
   # Cleanup leftovers from dhcpcd 1:3.* in Wheezy.
   # Can be removed after Trixie is released.
   update-alternatives --remove dhcpcd /sbin/dhcpcd3
diff -Nru 
dhcpcd5-9.4.1/debian/patches/53e2f6de4ba87d0534c89cae674e6c1a48724ef0.patch 
dhcpcd5-9.4.1/debian/patches/53e2f6de4ba87d0534c89cae674e6c1a48724ef0.patch
--- dhcpcd5-9.4.1/debian/patches/53e2f6de4ba87d0534c89cae674e6c1a48724ef0.patch 
1970-01-01 02:00:00.0 +0200
+++ dhcpcd5-9.4.1/debian/patches/53e2f6de4ba87d0534c89cae674e6c1a48724ef0.patch 
2024-06-15 12:34:41.0 +0300
@@ -0,0 +1,121 @@
+From 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 Mon Sep 17 00:00:00 2001
+From: Roy Marples 
+Date: Sat, 15 Jun 2024 10:04:06 +0100
+Subject: [PATCH] privsep: Allow zero length messages through
+
+They should be handled gracefully without privsep anyway.
+Fix for #179.
+---
+ src/privsep-inet.c | 12 ++--
+ src/privsep.c  | 15 +++
+ src/privsep.h  |  2 +-
+ 3 files changed, 10 insertions(+), 19 deletions(-)
+
+diff --git a/src/privsep-inet.c b/src/privsep-inet.c
+index 3a192ee0..7f7494f6 100644
+--- a/src/privsep-inet.c
 b/src/privsep-inet.c
+@@ -53,7 +53,7 @@ ps_inet_recvbootp(void *arg)
+ {
+   struct dhcpcd_ctx *ctx = arg;
+ 
+-  if (ps_recvmsg(ctx, ctx->udp_rfd, PS_BOOTP, ctx->ps_inet_fd) == -1)
++  if (ps_recvmsg(ctx->udp_rfd, PS_BOOTP, ctx->ps_inet_fd) == -1)
+   logerr(__func__);
+ }
+ #endif
+@@ -67,12 +67,12 @@ ps_inet_recvra(void *arg)
+   struct rs_state *state = RS_STATE(ifp);
+   struct dhcpcd_ctx *ctx = ifp->ctx;
+ 
+-  if (ps_recvmsg(ctx, state->nd_fd, PS_ND, ctx->ps_inet_fd) == -1)
++  if (ps_recvmsg(state->nd_fd, PS_ND, ctx->ps_inet_fd) == -1)
+   logerr(__func__);
+ #else
+   

Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration

2024-06-15 Thread Martin-Éric Racine
On Tue, 29 Aug 2023 13:17:51 +0200 Nicolas Cavallari
 wrote:
> Package: dhcpcd-base
> Version: 9.4.1-22
> Severity: critical
> Tags: security
> Justification: breaks unrelated software
> X-Debbugs-Cc: Debian Security Team 
>
> When the dhcpcd DHCPv4 client receives a zero-length UDP packet on port
> 68, the "network proxy" dhcpcd process exits with status 0.  dhcpcd then
> stops all network activity:  It does not renew leases and eventually expires
> the current lease (unless it has infinite duration) and removes the IP
> address, leaving the system without networking.
>
> This bug can be triggered remotely over the internet from any UDP port
> and is critical on an internet-facing system that needs DHCP to get
> an IP address, such as a gateway, a dedicated server or a VM.
>
> This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2
> (stable proposed update) but not 1:10.0.2-4 (testing/unstable) as
> upstream fixed it in 10.0.2:
>
> Upstream Bug report: https://github.com/NetworkConfiguration/dhcpcd/issues/179
> Upstream Fix: 
> https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae
>
> This patch does not apply cleanly to 9.4.1 because the privsep
> structure changed in 10.0.2.  It's likely that only the src/privsep.c
> hunks about len == 0 and eloop_exit() needs to be backported, the other
> changes are just here to avoid compiler warnings about unused
> parameters.

Upstream got around releasing a backport of this for branch 9 as
commits 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 and
6e127eac6903524d401b31893167e4529b8ab111 respectively.

You are hereby invited to test and report whether this fixes it for Stable.

Martin-Éric



Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out

2024-06-13 Thread Martin-Éric Racine
Adding the dnsmasq maintainer in CC.

to 13. kesäk. 2024 klo 11.39 Paul Gevers (elb...@debian.org) kirjoitti:
> On 13-06-2024 3:36 a.m., Martin-Éric Racine wrote:
> > Subsequent ones randomly timeout waiting for an IP from the DHCP
> > server. This could well be an issue with dnsmasq, which is what we use
> > for the test. Alternately, it could be caused by those constant fails
> > on glibc. Without more detailed logs, I am not in a position to
> > investigate this. Help is welcome.
>
> Well, I can't give you more logs than what your test writes. So that's
> in your hands, I suggest you try and make the test more verbose of
> what's going on, or maybe ensure some logs end up in the artifacts for
> inspection. Also, if dnsmasq is the problem, you might want to contact
> the maintainer and discuss the issue (e.g. in a bug report). From my
> standpoint, it's the autopkgtest of dhcpcd that's having issues and that
> *is* an issue for src:dhcpcd. You could reassign this bug and mark it
> "affects dhcpcd".

I'm curious to hear whether any of what appears in the log rings any
bell for Simon.

> I acknowledge that something fishy seems to be ongoing in the archive
> when new version of src:glibc binaries appear (not only with dhcpcd I
> mean). For now I'll not hold that against autopkgtest failures of
> packages too much.

Which is where I suspect the real issue is.

Personally, I already find it suspicious that the tracker tells me
about unrelated packages' transitions or issues. If the problem is in
someone else's code, while mine hasn't changed in ages, that's where
the bug report needs to go. In this case, dhcpcd's autopkgtest hasn't
changed in ages, and has been verified to work as-is at Ubuntu, where
isolation machines were implemented a long time before Debian.

Martin-Éric



Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out

2024-06-12 Thread Martin-Éric Racine
ke 12. kesäk. 2024 klo 7.20 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ti 11. kesäk. 2024 klo 23.21 Paul Gevers (elb...@debian.org) kirjoitti:
> >
> > Source: dhcpcd
> > Version: 1:10.0.8-1
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: flaky
> >
> > Dear maintainer(s),
> >
> > I looked at the results of the autopkgtest of your package because it
> > was tested for glibc. I noticed that it regularly fails.
> >
> > Because the unstable-to-testing migration software now blocks on
> > regressions in testing, flaky tests, i.e. tests that flip between
> > passing and failing without changes to the list of installed packages,
> > are causing people unrelated to your package to spend time on these
> > tests.
> >
> > Don't hesitate to reach out if you need help and some more information
> > from our infrastructure.
>
> This is a non-bug.  This package has only one test and it requires an
> isolation machine. amd64 is the only architecture that provides it.
> Other architectures will always be marked flakey. Additionally,
> looking at the tracker for this package, amd64 always passes.

This being said, if you can spot what makes it randomly fails, please
do send me a patch.

Martin-Éric



Bug#1073014: dhcpcd: flaky autopkgtest: Obtaining network configuration for veth1 via dhcp... timed out

2024-06-11 Thread Martin-Éric Racine
ti 11. kesäk. 2024 klo 23.21 Paul Gevers (elb...@debian.org) kirjoitti:
>
> Source: dhcpcd
> Version: 1:10.0.8-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: flaky
>
> Dear maintainer(s),
>
> I looked at the results of the autopkgtest of your package because it
> was tested for glibc. I noticed that it regularly fails.
>
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
>
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.

This is a non-bug.  This package has only one test and it requires an
isolation machine. amd64 is the only architecture that provides it.
Other architectures will always be marked flakey. Additionally,
looking at the tracker for this package, amd64 always passes.

Martin-Éric



Bug#1072978: rdate: please implement ifup script

2024-06-11 Thread Martin-Éric Racine
Package: rdate
Version: 1:1.11-3
Severity: normal

The Hurd port still depends on the deprecated reference 'ntpdate' to sync 
clocks at bootup. That reference NTP implementation was replaced by ntpsec in 
Debian a long time ago.

The only NTP client that still builds for Hurd is rdate. What is missing is an 
ifup script to issue the following command whenever the network is up:

rdate -n debian.pool.ntp.org

You may want to use an /etc/default/rdate to source the command options and the 
server.

You may check 

 for ideas on how to implement this.

Once rdate has implemented such an ifup script, the Hurd port will finally be 
able to retire its obsolete fork of ntpdate.

Thanks!
Martin-Éric

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

Kernel: GNU-Mach 1.8+git20240406-up-486/Hurd-0.9
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: sysvinit (via /sbin/init)

Versions of packages rdate depends on:
ii  libbsd0  0.12.2-1
ii  libc0.3  2.38-13

rdate recommends no packages.

rdate suggests no packages.

-- no debconf information


Bug#1072973: ntpdate: please drop transitional package

2024-06-11 Thread Martin-Éric Racine
Package: ntpdate
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The ntpdate package nowadays merely is a transitional package. Keeping it no 
longer serves a purpose.

Meanwhile, the Hurd port still depends on the original University of Delaware 
NTP implementation that provided ntpdate. Since that codebase is now obsolete, 
the plan would be to re-introduce ntpdate as a wrapper for rdate that can be 
launched upon bootup the same way the original ntpdate did.

Once ntpsec has dropped its ntpdate transitional package, the new wrapper could 
be introduced with the next rdate upload.

Thanks!
Martin-Éric

- -- System Information:
Debian Release: 12.5
  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-21-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 ntpdate depends on:
pn  ntpsec-ntpdate  

ntpdate recommends no packages.

ntpdate suggests no packages.

-BEGIN PGP SIGNATURE-

iQIyBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZn/b4ACgkQrh+Cd8S0
17YMrQ/2LhYwIgm06/HN8KzeuxeeG7cgH7v0L+QEUU0La/Jdyboi9L6dp7QX78bN
SIGIjJfXnXU8mEIb02hAs9taQW813xh14RjH73KC55TjYtn3UruPFovHw8UsXG77
VYS/wuV7Rwh7A2IayxNj+1NoRG+cKURZ1Uf6hKAbm0qjQdvTr5+XMLFyDx5GOPGU
DHRzp5RGOTfBiC30cInHGpjTPgoqeaMSY1j19FwgqnDpWWIvx+vHRLRuBv9P+miT
7DrEIOejl6Y8UaW4LgJIeR7fA3JfcLAkZTvIwJRVV4mWF8UiJAN6KRFlR5Dav+ZP
1crgp7yIl1exWZP8ewMzVrK8MkkRZouzUMuAxpO4I9D+lqMfOI67v1+5N0v+S9tu
8M/ID3FLUm4qC0Gi1GBE1sQ8IfBZ9PKjPkY4C19UQTWNOhZ9y0sasTPHcmQE8deM
/ePzJufY/x7ZG9B/jAfOFynKUnUIMHfvmNqBVXpbfxtbIfOBftCMoGPxmchc1Lfo
i8qgsAimp/39CESsko+1jqBAkVzHF2kaDJmqV5gz1hi35CEcHbuFOrP/0uSc02Hb
SnhUA1Xlpc86MUK+PhJxx7kIUAV7MRulfD2aoUzrHvE1td6rJPmtmPVPRP/VXce0
NShUqW5xj8bjbSYchWGb80ksDd2v/6QizotlvEzENt737yFYfQ==
=vRjx
-END PGP SIGNATURE-


Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:

2024-06-09 Thread Martin-Éric Racine
ma 10. kesäk. 2024 klo 2.18 Ben Finney (bign...@debian.org) kirjoitti:
>
> Howdy Martin-Éric,
>
> On 09-Jun-2024, Martin-Éric Racine wrote:
>
> > Incorrect delayed argument: ValueError: delayed days value must be a 
> > decimal integer:
> >
> > I did not specify any delayed queue, so I am perplexed as to what
> > produced this.
>
> You did not specify a command-line option for the delayed queue; but your
> configuration file does specify a value.
>
> […]
>
> So, that configuration section overrides default behaviour and specifies
> empty-string values for many options that would otherwise have no value
> defined.

The script ANDs /etc/dput.cf and the user's own.

My config actually is much shorter than that.

Martin-Éric



Bug#1036448: debhelper: please add helper for autoconf 2.71 autoupdate

2024-06-09 Thread Martin-Éric Racine
Fair enough.

Could the dh-autoreconf maintainer acknowledge this bug and tell us
his intentions?

Martin-Éric

On Mon, 22 May 2023 09:30:55 +0200 Niels Thykier  wrote:
> Control: reassign -1 dh-autoreconf
>
> The dh-autoreconf tool is maintained in a separate package; re-assigning.
>
> Best regards,
> Niels
>
> Martin-Éric Racine:
> > Package: debhelper
> > Version: 13.11.4
> > Severity: wishlist
> >
> > Possibly related to dh_autoreconf:
> >
> > Since autoconf 2.71 has entered the archive, it often complains about 
> > outdated macros, asking for 'autoupdate' to be run. Example:
> >
> > dh binary --builddirectory=build/
> > dh_update_autotools_config -O--builddirectory=build/
> > dh_autoreconf -O--builddirectory=build/
> > libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
> > libtoolize: copying file 'build-aux/ltmain.sh'
> > libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> > libtoolize: copying file 'm4/libtool.m4'
> > libtoolize: copying file 'm4/ltoptions.m4'
> > libtoolize: copying file 'm4/ltsugar.m4'
> > libtoolize: copying file 'm4/ltversion.m4'
> > libtoolize: copying file 'm4/lt~obsolete.m4'
> > configure.ac:42: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
> > configure.ac:42: You should run autoupdate.
> > m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from...
> > configure.ac:42: the top level
> > configure.ac:48: warning: The macro `AC_PROG_CC_C99' is obsolete.
> > configure.ac:48: You should run autoupdate.
> > ./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
> > aclocal.m4:1899: XORG_COMPILER_BRAND is expanded from...
> > aclocal.m4:2018: XORG_COMPILER_FLAGS is expanded from...
> > aclocal.m4:2190: XORG_DEFAULT_OPTIONS is expanded from...
> > configure.ac:48: the top level
> > configure.ac:52: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
> > configure.ac:52: You should run autoupdate.
> > m4/libtool.m4:100: AC_PROG_LIBTOOL is expanded from...
> > configure.ac:52: the top level
> >
> > Running 'autoupdate' indeed makes autoconf stop complaining, but it also 
> > results in dpkg forcing us to create a patch against autoconf.ac, which is 
> > IMHO the wrong approach.
> >
> > Unless I'm mistaken, this is a case similar to updating config.guess and 
> > config.sub, so there should be a way to tell dh_autoreconf to run 
> > 'autoupdate' without making dkpg complain.
> >
> > Martin-Éric
> >
> > [...]
> >
>
>



Bug#1072857: dput: Incorrect delayed argument: ValueError: delayed days value must be a decimal integer:

2024-06-09 Thread Martin-Éric Racine
Package: dput
Version: 1.2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

$ dput mentors ../xserver-xorg-video-geode_2.11.21-4_source.changes
Checking signature on .changes
gpg: ../xserver-xorg-video-geode_2.11.21-4_source.changes: Valid signature from 
AE1F8277C4B4D7B6
Checking signature on .dsc
gpg: ../xserver-xorg-video-geode_2.11.21-4.dsc: Valid signature from 
AE1F8277C4B4D7B6
Incorrect delayed argument: ValueError: delayed days value must be a decimal 
integer:

I did not specify any delayed queue, so I am perplexed as to what produced this.

Martin-Éric

- -- Package-specific info:

- -- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

- -- /home/perkelix/.config/dput/dput.cf --

- -- /home/perkelix/.dput.cf --
[mentors-ftp]
fqdn = mentors.debian.net
incoming = /pub/UploadQueue/
method = ftp
allow_unsigned_uploads = 0
run_lintian = 1
passive_ftp = 1
login = anonymous

[mentors-https]
fqdn = mentors.debian.net
incoming = /upload
method = https
allow_unsigned_uploads = 0
run_lintian = 1

[ppa]
fqdn = ppa.launchpad.net
incoming = ~q-funk/ppa/ubuntu/
method = ftp
allow_unsigned_uploads = 0
run_lintian = 1
login = anonymous

[esteid]
fqdn = ppa.launchpad.net
incoming = ~esteid/ppa/ubuntu/
method = ftp
allow_unsigned_uploads = 0
run_lintian = 1
login = anonymous

[x-swat]
fqdn = ppa.lau

Bug#1072066: systemd: upgrade to 256~rc3-3: legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

2024-05-27 Thread Martin-Éric Racine
Package: systemd
Version: 256~rc3-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Setting up systemd (256~rc3-3) ...
/usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", 
ignoring.


- -- Package-specific info:

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

Kernel: Linux 6.1.0-21-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 systemd depends on:
ii  libacl12.3.2-2
ii  libapparmor1   3.0.13-2
ii  libaudit1  1:3.1.2-2.1
ii  libblkid1  2.40.1-2
ii  libc6  2.38-11
ii  libcap21:2.66-5
ii  libcryptsetup122:2.7.2-2
ii  libfdisk1  2.40.1-2
ii  libmount1  2.40.1-2
ii  libpam0g   1.5.3-7
ii  libseccomp22.5.5-1
ii  libselinux13.5-2+b2
ii  libssl3t64 3.2.1-3
ii  libsystemd-shared  256~rc3-3
ii  libsystemd0256~rc3-3
ii  mount  2.40.1-2

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-4+b1
ii  libzstd1 1.5.5+dfsg2-2
ii  systemd-timesyncd [time-daemon]  256~rc3-3

Versions of packages systemd suggests:
ii  libgcrypt20   1.10.3-3
ii  libidn2-0 2.3.7-2
ii  liblz4-1  1.9.4-2
ii  liblzma5  5.6.1+really5.4.5-1
pn  libtss2-rc0t64
pn  libtss2-tcti-device0  
pn  polkitd   
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-4+b1
pn  dracut 
pn  initramfs-tools
ii  libnss-systemd 256~rc3-3
ii  libpam-systemd 256~rc3-3
pn  udev   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZVThMACgkQrh+Cd8S0
17Yj1w//TvIy5IYO9yHe1FPWTzerSTwgIeSjkaYD9Ch0yHzz0vtKWFW0EaQq4b/s
QzELfhVMDVhfwIKWCIiOB0LSk5i6MXkWIwmUU2c5uXRaRfirRG5jS8ItG+ZEibbr
MGh2JtOYIxpKPnScubx/lprjeWJDVehQJ6P6xEjZ2bE4n7+Y9MLWt/Nx1dk4a1Ix
dpN45g1iSybbs/KKvg0Fx8KI46gdn+K8hf9dp06khiQTgOYwIuMnU5p1hvNgHlyu
z3ezNOw4jKlugyJPnYYTTyrGk89rFJTA+omGh6Z4dhf/v8j0flZRnj31DPkeICKo
hNk2h0u0moD01D5E/OXpwvHdMIwmFH0A7bqUEieYAAcls7mZCHgX7hMRiE/8qOFv
DfTy9STAJO0Xm9Y5mvRCovCmrEmJ5AePZavm8ymdmA/m1ApIMAUz/+nk0CyLwnL4
/7Oa+kektmgG4Dp+XxK2lOjVd40duQ7HRNs2mpFcJ9yBWya1+gv3Lf/utt9uuGk2
VqVetoLl/0AYlP9g0PSdFxdqXZ7cbCVAC8TzLTPXu3UOlhBXziAxi/fQgCAYtDow
8Dj0MVv5uzd43m+4AGL7q7SaPkZMH2/Isl/VbnaJuirfpOXAq6/b85JALGd10Jg2
fkKwxphsZT4UjAfYsSUOLumLfe/3s8KuiVCLsJ4SL6jbpcIeJoM=
=M99n
-END PGP SIGNATURE-



Bug#1019922: debian-archive-keyring: Machine-readable copyright conversion

2024-05-25 Thread Martin-Éric Racine
Package: debian-archive-keyring
Version: 2023.4
Followup-For: Bug #1019922

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Alternately, please find attached this other version of a DEP-5 copyright.

Also included in the diff are automated improvements by 'routine-update'.

You're welcome to further edit as desired before merging.

Martin-Éric

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

Kernel: Linux 6.1.0-21-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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZS27wACgkQrh+Cd8S0
17ZM2g/+KUeBgou27VU2K37JxGAcpCifgKlWVN2rFaGBkqYzxp/xg9eh1WKA8HVC
9M9xT3EBR1qhSgcckOmzySnEETVR1ItWeYqpi6MlpCCOZTmiBECn8M4XNEPxwbvA
CsX4WCA8Qkrw3aBmS28IthKukmexHRVktIoDPc2/xdxTG8LlHJ5wSlaOJLd8vqYm
90S7kHAbSNquk2SC1bB2Nn9KMNAjkI55wkqPxoXZiqC5Ue+dZwhdzRQc9W2iUS71
qFc7np2BdIZVz3Nv9IbgpT6BYq7y8HfHBnljSIib0T8HsYW/C1VlXzL3/4+PUO+G
tt4lOUp4u6IfB+02XCGQGhUjj0rUbNWTyINlkx9ZQEqDdEuwqnes0udRMXQRZWcR
QjtvQsMFvnjunEYQn5NncHtJAxgJ1jBZIomf3bviUTACn9d6pLv5zonLj7irozdJ
rKEFIEpta7STBKmVcrk9KiobFgX1By7+X+/iPEM/rkIs4NWOxGGHWNEj7ZAAzW/4
5+vGVSxihs9zgJIxcgz4aQjHAFSdyglCBSVBXmLRh76xANptfIIZHfP1uw3eNvbR
O4KwKJ5LESRnEP4xs3rVySWTfp9BDlBdJaEkapygTYBmrK1NBcqoYzqUaCaVfavx
6Zmsl/Qd2QjstGMX5N31oSSG1+xQ97htAGFc0pqqtGHiUihm9SQ=
=65gg
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index a3dd09e..86e4967 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+debian-archive-keyring (2023.4+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Standards-Version: 4.7.0 (routine-update).
+  * debhelper-compat 13 (routine-update).
+  * Remove trailing whitespace in debian/copyright (routine-update).
+  * Remove 7 obsolete maintscript entries in 1 files (routine-update).
+  * Migrated debian/copyright to DEP-5.
+
+ -- Martin-Éric Racine   Sun, 26 May 2024 09:36:32 
+0300
+
 debian-archive-keyring (2023.4) unstable; urgency=medium
 
   * Clean up leftover keyrings in trusted.gpg.d
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index f599e28..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-10
diff --git a/debian/control b/debian/control
index 6af283a..b5450d5 100644
--- a/debian/control
+++ b/debian/control
@@ -3,10 +3,10 @@ Priority: important
 Section: misc
 Maintainer: Debian Release Team 
 Uploaders: Niels Thykier ,
- Jonathan Wiltshire ,
-Build-Depends: debhelper (>= 10), jetring, gnupg
+   Jonathan Wiltshire 
+Build-Depends: debhelper-compat (= 13), gnupg, jetring
 Rules-Requires-Root: no
-Standards-Version: 4.6.0
+Standards-Version: 4.7.0
 Vcs-Browser: https://salsa.debian.org/release-team/debian-archive-keyring
 Vcs-Git: https://salsa.debian.org/release-team/debian-archive-keyring.git
 
diff --git a/debian/copyright b/debian/copyright
index d934ced..e2c7a1b 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,27 +1,19 @@
-This is Debian GNU's GnuPG keyrings of archive keys.
-
-This package was originally put together by Michael Vogt
- 
-
-The keys in the keyrings don't fall under any copyright.  Everything
-else in the package is covered by the GNU GPL.
-
-Debian support files Copyright (C) 2006 Michael Vogt  
-based on the debian-keyring package maintained by James Troup 
-
-Debian support files for debian-archive-keyring are free software; you
-can redistribute them and/or modify them under the terms of the GNU
-General Public License as published by the Free Software Foundation;
-either version 2, or (at your option) any later version.
-
-Debian support files for debian-archive-keyring are distributed in the
-hope that they will be useful, but WITHOUT ANY WARRANTY; without even
-the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
-PURPOSE.  See the GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License with
-your Debian system, in /usr/share/common-licenses/GPL, or with the
-Debian GNU debian-archive-keyring source package as the file COPYING.
-If not, write to the Free Software Foundation, Inc., 51 Franklin Street,
-Fifth Floor, Boston, MA 02110-1301 USA.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Source: https://salsa.debian.org/release-team/debian-archive-keyring
+Upstream-Name: debian-archive-keyring
+Upstream-Contact: Debian Release Team 
 
+Files: *
+Copyright: © 2024 Martin-Éric Racine 
+   © 2021-2023 Jonathan Wiltshire 
+   © 2017-2018 Niels Thykier 
+   © 2014-2017 Adam D. Barratt 
+   © 2010-2014 Philipp Kern 
+   © 2008 Bastian Blank 
+   © 2008-2009 Luk Claes 
+   © 2007 Joey Hess 
+   © 2006 Anthony Towns 
+   © 2

Bug#1071823: console-setup: [Hurd i386] debconf: lsmod: not found

2024-05-25 Thread Martin-Éric Racine
Package: console-setup
Version: 1.223
Severity: important

While upgrading from 1.223 to 1.226 on Hurd i386:

Fetched 32.4 MB in 23s (1429 kB/s)  

   
Extracting templates from packages: 100%
Preconfiguring packages ...
/var/cache/debconf/tmp.ci/console-setup.config.otOVsK: 1196: lsmod: not found

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

Kernel: GNU-Mach 1.8+git20231217-486/Hurd-0.9
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: sysvinit (via /sbin/init)

Versions of packages console-setup depends on:
ii  debconf [debconf-2.0]   1.5.85
ii  hurd1:0.9.git20231217-1
ii  keyboard-configuration  1.223
ii  xkb-data2.38-2

console-setup recommends no packages.

Versions of packages console-setup suggests:
iu  locales2.38-11
ii  sysvinit-utils [lsb-base]  3.08-6

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0]   1.5.85
ii  liblocale-gettext-perl  1.07-6+b1
ii  xkb-data2.38-2

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
pn  gnome-control-center  
pn  kbd   
pn  systemd   

-- debconf information:
* keyboard-configuration/variant: Finnish
* keyboard-configuration/optionscode:
* keyboard-configuration/modelcode: pc105
* console-setup/codesetcode: guess
* console-setup/charmap47: UTF-8
* keyboard-configuration/compose: No compose key
* keyboard-configuration/model: Generic 105-key PC
* console-setup/store_defaults_in_debconf_db: false
* keyboard-configuration/store_defaults_in_debconf_db: false
* keyboard-configuration/toggle: No toggling
  console-setup/guess_font:
* console-setup/fontface47: Fixed
  debian-installer/console-setup-udeb/title:
* keyboard-configuration/other:
  console-setup/framebuffer_only:
* keyboard-configuration/altgr: The default for the keyboard layout
* console-setup/fontsize-text47: 8x16
* keyboard-configuration/layout:
  keyboard-configuration/unsupported_options: true
* console-setup/fontsize: 8x16
  keyboard-configuration/unsupported_config_layout: true
* keyboard-configuration/ctrl_alt_bksp: false
* console-setup/codeset47: Guess optimal character set
  console-setup/use_system_font:
  keyboard-configuration/unsupported_layout: true
* keyboard-configuration/switch: No temporary switch
* keyboard-configuration/layoutcode: fi
* keyboard-configuration/xkb-keymap: fi
  keyboard-configuration/unsupported_config_options: true
* keyboard-configuration/variantcode:
* console-setup/fontsize-fb47: 8x16



Bug#1071489: tracker.debian.org: please upgrade Lintian to the latest

2024-05-20 Thread Martin-Éric Racine
ma 20. toukok. 2024 klo 18.09 Lucas Nussbaum (lu...@debian.org) kirjoitti:
> On 20/05/24 at 08:39 +0300, Martin-Éric Racine wrote:
> > Package: tracker.debian.org
> > Severity: important
> >
> > The Lintian on tracker.debian.org complains that 4.7.0 is 
> > newer-standards-version.
> >
> > Can you please upgrade it to the latest version?
>
> I think that tracker.d.o gets its lintian information from UDD (so the
> data is the same as one available from
> https://udd.debian.org/lintian/?email1=martin-eric.racine%40iki.fi&email2=&email3=&packages=&ignpackages=&format=html<_error=on<_warning=on&lintian_tag=#all
> )
>
> As you can see in the footer of that page, UDD runs lintian 2.117.0.
> That's the latest lintian version.
>
> So the real problem is that the lintian version in the archive doesn't
> know about the debian-policy version in the archive...

Noted. This really needs to become a streamlined process i.e. whenever
a new policy is published, debian-policy and lintian get pushed into
Unstable at the same time, and Lintian immediately updated on all
applicable hosts. Otherwise, Lintian generates false positives on
newer-standards-version and also misses new things it should check to
match compliance with the new standard, all of which needlessly
complicates package maintainers' job.

Martin-Éric



Bug#1071489: tracker.debian.org: please upgrade Lintian to the latest

2024-05-19 Thread Martin-Éric Racine
Package: tracker.debian.org
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The Lintian on tracker.debian.org complains that 4.7.0 is 
newer-standards-version.

Can you please upgrade it to the latest version?

Thanks!
Martin-Éric


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZK4hAACgkQrh+Cd8S0
17ZFURAAp9KXen+WQbxVK+guJxZGlyounwk1mUh/Y1wU1nTNkYZUc4FiUmUbboo+
suzPRjMaovnsXZtDkhBWaz0jLRf/F4ZleLW2WoEgd9t61+PnAOJ2J3GR4kfoYTT0
Dh/jBX6IWVGfhcT7U7rcrfIZHrn7Vi1+58T9mN4WnW6ja19M5ruBbmOik9Bt+zol
pBKEdSFdlNORt+b1yO7Kvz/vQOaOUZrtOUfEBl8L23LPJPger1P0BVcl1410hHXs
I1kq3fHT7+2wzpEaiziTbVH/eLWaOEAZCIkvqbKXfQbS5n8GvaIXFhcYN3PtEJJO
qfcrSZth7fMH0YOd9klkQ4i4C8SFI5R6FqPUIkifTb4xKfAa6GBU8tG7WxGz8Sja
rqSWr1A4uw+Q8A1MAjlLOVZGNYx71tN25nGcYdWtwnW0sYxTouAbsl+c7iLSIPu5
MIuNtnPb4kB1iSVJdF4vgfZ5DVk9THh72neCUe40tiq3IlPA1qjFs8Gzstr7V6UX
m9wbqxHAAhVwQt/fIlRd0cFcWkq2/1de3Fpi4BabC6M8RtiXvD7tDG4eBv/m7gfc
OFLqhzHIcA72rLs4SoIiaFkMO1YiHgnP1Ko301crS92gfZdTgLBG8ofbaE9PbkuY
8MNjLtPPBrQUWuj6w/7cGsK6u7he0qCEjK7+fP4b6dXz49axuIw=
=hj3T
-END PGP SIGNATURE-


Bug#1071093: libc6: [adequate] undefined-symbol

2024-05-14 Thread Martin-Éric Racine
Package: libc6
Version: 2.38-11
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

$ adequate --all --tags -py-file-not-bytecompiled
libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_pdwrite
libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => 
ps_pglobal_lookup
libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => 
ps_lsetregs
libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_getpid
libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => 
ps_lgetfpregs
libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => 
ps_lsetfpregs
libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => 
ps_lgetregs
libc6:i386: undefined-symbol /lib/i386-linux-gnu/libthread_db.so.1 => ps_pdread


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

Kernel: Linux 6.1.0-21-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 libc6 depends on:
ii  libgcc-s1  14-20240429-1

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

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.86
pn  glibc-doc  
ii  libc-l10n  2.38-11
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.38-11

- -- debconf information excluded

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZDD1wACgkQrh+Cd8S0
17ZR7w/+OsMP7IW5GyIghTc+CkaIYuD6qT0a4v8SeNtfER5h1Y5THEx7Nylp02yz
fkS3RdsDa+GK3kMxOLK/OgNJ5Xv46ULX0/Dov+2OSHXcSMIuq3GwBwy4IZWN22WU
TDLwTl9+CPY3yX6v+03CpyoJTvb7dT2g4tgCamR1lOTwpmwg2gO9O5QBhB3gYGCb
i9+LatQMKWTnPc3MOKiVR3ABSGRGvoUB0Re51qdRyojq1w8cgzzCQeHsZYsM7ovX
oLMcMBXlvyL4/nQYkI+CMZwHabCM0RLCrUsb2lowcHi3bs66nK/p4LkiO68Za2vH
/kp7vykd5Sd+M08PatNxHQSUujmXPj+fQb6DwQtRVI85BlrSnUcuAOis/OUnk8uM
fjloB0svB47BFH4RGcggYGn5lTKKDoLRo1qxx1f3PLdvxyFqhliBL5ZJDu5ETi94
1QRmV8MfnSpGA1I1VSSPlmTjs9NiNMK0hJMGHVmQVzq/xmAt+m4ITbc6iyxs4mzu
bRdNRmkfhaJid+RZhkzwkIX77SlgvQXnN/ujvo/T2Q/xIgXoTCGgRnVf9IkglfmK
AcrH8CrkEr0KxDnlHWidSx5kiEmdUYavslAxROnDrSLTSk/Dnx8qSv65l6oBfr2f
Eq+83yv7BGHzjuu0T0tsIyGhYB+M0zgKD5nTCoUWTDtaWH/MEt0=
=xNVU
-END PGP SIGNATURE-



Bug#1071091: systemd: installs broken symbolic links

2024-05-14 Thread Martin-Éric Racine
Package: systemd
Version: 255.5-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

$ adequate --all --tags -py-file-not-bytecompiled
systemd: broken-symlink /etc/modules-load.d/modules.conf -> ../modules


- -- Package-specific info:

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

Kernel: Linux 6.1.0-21-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 systemd depends on:
ii  libacl12.3.2-2
ii  libapparmor1   3.0.13-2
ii  libaudit1  1:3.1.2-2.1
ii  libblkid1  2.40-8
ii  libc6  2.38-11
ii  libcap21:2.66-5
ii  libcryptsetup122:2.7.2-2
ii  libfdisk1  2.40-8
ii  libgcrypt201.10.3-2+b1
ii  libkmod2   32-1
ii  liblz4-1   1.9.4-2
ii  liblzma5   5.6.1+really5.4.5-1
ii  libmount1  2.40-8
ii  libpam0g   1.5.3-7
ii  libseccomp22.5.5-1
ii  libselinux13.5-2+b2
ii  libssl3t64 3.2.1-3
ii  libsystemd-shared  255.5-1
ii  libsystemd0255.5-1
ii  libzstd1   1.5.5+dfsg2-2
ii  mount  2.40-8
ii  systemd-dev255.5-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-4+b1
ii  systemd-timesyncd [time-daemon]  255.5-1

Versions of packages systemd suggests:
ii  libbpf1   1:1.4.1-1
ii  libfido2-11.14.0-1+b2
ii  libip4tc2 1.8.10-3
ii  libp11-kit0   0.25.3-5
pn  libpwquality1 
pn  libqrencode4  
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu-4.0.1-0
pn  libtss2-rc0   
pn  libtss2-tcti-device0  
pn  polkitd   
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-4+b1
pn  dracut 
pn  initramfs-tools
ii  libnss-systemd 255.5-1
ii  libpam-systemd 255.5-1
pn  udev   

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZDDsEACgkQrh+Cd8S0
17ashA//VRcFHX1hLvzXIS1nF3+EnHkKgtllDpQwQbyjtSYZqcfyQ33LAPWdLAQB
cqyUhc8+Swm5vksaBQPv2tGt2wrCft8UAhFiBWLTsrC2vD4R6bRr8+CcNboj3AWH
7XOpQf/h8Ow9NIjhhy97gF3njBBrsl4g5zhrgWweL9QTlQCvfxwaYEt3dv11+dJq
x2EfXTf5jpKHnHXHTIA51rqzrlDOLBwpchQ123Pmw1Wo6QXYNkfyQqbhjFW0Ne9+
PB/dHsiq9hkBOuhQYjdQ75RfuYqoGN+QK5tVpBTotOu4z+t0sDwOsvlbz/Q5uBMn
UXlORLWb/LYahGO1+HCEgGKif0pb8HL69MA/GC6qSF/rRyDlr7JE7yLeqb2ac2z8
HmHwAfG5CVEI7PuOwCN9b+YBz5d798KkuEJRdP64pczxAr9Bk2QA/nnjWz+SQlLZ
FJ0N30mqi1/4kQPu9KHChBR0vzTt1vUYtY+qun6kWvb2poScfyfMSbQo1rN8/B4B
Ls89uAzUmj03LKOisXeWLDgBoqKg/Nvj4/P8Ydoluy4lvY9BqK/4OWwVwXBwoXHi
IwV57IAveVx9/Mgqg/Rcik5l+9iiEdnXgHv1N6jTmTTA2+JMTnEqN8ihAeo3otmW
UwFBnsIPn4zbKBr2cjw3+l86oR/txkGtDUbGcHYvhjh5tBwjne4=
=Zkx7
-END PGP SIGNATURE-



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

2024-05-14 Thread Martin-Éric Racine
Package: iso-codes
Version: 4.16.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

$ 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


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

Kernel: Linux 6.1.0-21-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

iso-codes depends on no packages.

iso-codes recommends no packages.

Versions of packages iso-codes suggests:
pn  isoquery  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmZDDl8ACgkQrh+Cd8S0
17ZYLhAAsnzBthGEae4tlpZAjIy6yZ9LDDo4Pgujlz7br1cqKm19fHqd3Di/7W0N
qaNS5zFG86hEvDe5UClmTVIx40yI6r+LsKc6tHMLfVZc25cSYEkKG/RhquNF7H5X
eDXfPwXDhv85CrvHjW4fA1DlRK5lcjEie7WjVK9p2sl+BzmkCbARiopRnD2YIqzs
sp0lzWz0w6Lryv8COJOJ6PV3i27WHL4WZVPedSyOkHkHEb4rrpAja59Xr3s37cas
VV1zrjtnreQU7hbQsQjMUeLlC2v0I+/pQNIArFrz8dXxBuYr63xCZE7TPU3j9ANt
jC2UrmPGgrm0JuXtcwoeLPbhR7rVhXLhfw64hl21IAVOHJg4E6QkhdvrYO8MIKLk
9m9Sc9KiSU4TodrXDdaNoY/vBqhGNnUakZA2O5+LQTGCcagaOv0nni8D3h8YbKng
5HzDcn2dz+qbtrCGFlm7sjn7Pb3oydXzVJgr9EpRDljzps2+/00wg2RG9XSGTC4e
nHhOHnODQlropYkT46kCUD40bFvAgwZ41iykYHAHAJW1/C8dDvPH7OyzFDB3296Q
Rpx9YY0CLVRj9otwrcj9Si2ZPx9SD6JXExt0PQ51dFD/VoZIq9hVtnJyV4Te3y6o
Brofp0caZHJt7XBwHAtGe1nRk/9iKc+pGA37FKIWY8X5E0S7xZ0=
=bqAZ
-END PGP SIGNATURE-



Bug#1070735: micro-httpd: debian/copyright update attached

2024-05-07 Thread Martin-Éric Racine
Source: micro-httpd
Version: 20140814-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Authors for the Debian folder content are updated. See attachment.

Martin-Éric

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

Kernel: Linux 6.1.0-21-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+Cd8S017YFAmY7HcoACgkQrh+Cd8S0
17aT7A//QBnHF7BnwdrluacAzTnY+0GY5sNFTG42RRnL/s3VU3aNetQLQCJGz1ow
RZ/je9Jr8JzMtR6usv/eoRyH3YhrDwzu8ZjDm5/395tVNAgJPEBzl1NtDfGMujMT
JRY04EtdcSvj0rSXF0jxHauI+tARvtGyiNTS95cUEB9Tyb0dEz5F+II41aEJwjN6
8YjMYBzTgQxAho/vDFVUzazinFCmBJiHMoqxHz85wNXaG2tdckwI6L4zI+UWoW9P
2BaT6nDcwkahiUZ/Ry1QnNdK5e720dshfaFE22+5Rem4U1zmxz8v/vzFGWelB4+8
6c8IU19aiVLNnQbGp7zlFukB2jkyqHdO9veBmxZfzP0cdaECbhdUGwSPWLuySiTD
ZCHjiiCBsLMEx+1gIwGiPvKx1L0Dhc3m1hIrB3KHBo51ZIV/9ZfyOCJDvJ0VDNWC
5gJrkKT6LDSYXGOeIkmpAh1hFe1LqNtAW8ovQhh+EWh0gjeqS2GxHaC+C3RDDCFn
26Fb2oXg4UjEd0LrH2sJKTZQrdzhjuuHim3qkVJOgjyCKYmv6H3VRI/9AW23EB7L
xbyNKpmFysZlfsIMExBzPyLB4wf9Z5C18oA+9n0vo9TPDzRwtLpkif+zIaZfYt66
UTF1Kr0jTu9r+70P5eOxx2RMjkwAToy9iBwPjyc0k1bHNkgl8W4=
=/kLu
-END PGP SIGNATURE-
--- a/debian/copyright  2024-05-04 14:01:59.0 +0300
+++ b/debian/copyright  2024-05-08 09:34:55.977467089 +0300
@@ -10,6 +10,9 @@ License: BSD-2-Clause
 
 Files: debian/*
 Copyright:
+  2021-2024 Martin-Éric Racine 
+  2019-2024 Sudip Mukherjee 
+  2016 Christian Hofstaedtler 
   2009-2012 Jari Aalto 
   2004-2007 Daniel Baumann 
 License: BSD-2-Clause


Bug#1070734: micro-httpd: Lintian-brush fixes attached

2024-05-07 Thread Martin-Éric Racine
Source: micro-httpd
Version: 20140814-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please find attached some minor fixes performed by Lintian-brish.

Martin-Éric

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmY7Gj0ACgkQrh+Cd8S0
17b09g/8CSJpwhTaLIQryL66OUUV2GaAzkr6Q+aTDFH7jhLG+gB3vEAkzJAEetgg
NiNGRQ0eDeYef1EGvAQmnmDbVCiNQPQYAHyHgnivFnawk5bGrHGqS83d3yuSO9rw
6ayFDuameg4gAZ+IXdWm9xjk9U/AXc7cOyVyg+vpG+gq2VworPjAg1smCCXcfw/Y
8O24SxIR0NekVW3i936Tov7/VfN2pnMEJICiAnagIS6f/OITrl0BW9bYWi0YGoYN
22siaPW2Ha6VQOkgeRQotDsXFig0KRHNfAfu18rvCOzoZIlYF99G/2VnbJj0c+VX
xKeABJBoZcsl/aCNOx/3ljRLdrMgsUg4ejXgGqzlql2+UkROGWfraVUkZ/XYfKHC
1HntIh7JOO2fvbaa+S6dzC25Wc9imTD6fS+1hX7nsy9N0i7W1E3GkqwG9r94NJll
mLhnHNAf3KR7UCeNE4m07F9f0zwHtFbhC0zkbI9uFbH2zf+LyQ/s2+HOl+YHixvj
srKlZWxGYCOZazdn0JTp8fCszgc8hbuHHKfX1NUBgvdK27ePaTy/BRKFQ9Bc+QTB
LjioSER1B0Il+zWAZ8B1yo/85xHxui1G/f1ft6+tyrPTv4nRhKQbTC8JUkE5PASJ
BVssPL6+4Vg5T/4+Go5abFHx8vfiHJNpHQff8HYGhIt+s+q7sVE=
=Q5j4
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index 40bbe2b..1a9fcf6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+micro-httpd (20140814-4) unstable; urgency=low
+
+  [ Debian Janitor ]
+  * Update watch file format version to 4.
+  * Avoid explicitly specifying -Wl,--as-needed linker flag.
+
+ -- Sudip Mukherjee   Mon, 06 May 2024 16:34:16 
+0300
+
 micro-httpd (20140814-3) unstable; urgency=medium
 
   [ Martin-Éric Racine ]
diff --git a/debian/rules b/debian/rules
index 14be6bb..9f3b272 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,6 @@ include debian/debian-vars.mk
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
-export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 man:
# target: man -- convert *.pod to manual page
diff --git a/debian/watch b/debian/watch
index 77f22e8..65061e7 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,2 @@
-version=3
+version=4
 https://www.acme.com/software/micro_httpd/ .*micro_httpd_(.+).tar.gz


Bug#1027978: micro-httpd: sends invalid HTTP when listing unreadable directories

2024-04-29 Thread Martin-Éric Racine
ma 29. huhtik. 2024 klo 20.59 Sudip Mukherjee
(sudipm.mukher...@gmail.com) kirjoitti:
>
> On Mon, 29 Apr 2024 at 09:00, Martin-Éric Racine
>  wrote:
> >
> > On Thu, 05 Jan 2023 13:08:45 + Vincent Duvert  
> > wrote:
> > > Package: micro-httpd
> > > Version: 20140814-2.1+b2
> > > Severity: normal
> > > Tags: patch
> > > X-Debbugs-Cc: report...@duvert.net
> >
> > I have an NMU ready to cover this, debdiff attached.
>
> Thanks for the debdiff. But the diff is removing few of the Depends:
>
> micro-inetd | netcat-traditional | systemd-sysv
>
> Was that intentional or did you miss them? If intentional, then can
> you please explain why those are not needed now.

What is currently there is exactly what Lintian wants to see for any
package that updates any variant of inetd. Any additional alternative
makes Lintian barf, and overriding this particular one would not make
sense.

Meanwhile, systemd-sysv has a priority:important so it comes installed
by default on Linux-based hosts. If the Depends was only there because
you ship a systemd unit, it's not needed.

Martin-Éric



Bug#1027978: micro-httpd: sends invalid HTTP when listing unreadable directories

2024-04-29 Thread Martin-Éric Racine
On Thu, 05 Jan 2023 13:08:45 + Vincent Duvert  wrote:
> Package: micro-httpd
> Version: 20140814-2.1+b2
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: report...@duvert.net

I have an NMU ready to cover this, debdiff attached.

Martin-Éric
diff -Nru micro-httpd-20140814/debian/changelog 
micro-httpd-20140814/debian/changelog
--- micro-httpd-20140814/debian/changelog   2021-10-14 16:02:47.0 
+0300
+++ micro-httpd-20140814/debian/changelog   2024-04-29 10:01:57.0 
+0300
@@ -1,3 +1,15 @@
+micro-httpd (20140814-2.2) unstable; urgency=medium
+
+  * Non-Maintainer Upload.
+  * Bump debhelper-compat to 13.
+  * Fix Lintian override syntax.
+  * Fix "Lintian: W: missing Depends on update-inetd" (Closes: #997691).
+  * Fix "sends invalid HTTP when listing unreadable dirs" (Closes: #1027978).
+Implemented the first alternative proposed in the bug report i.e.
+redirect standard error to systemd journal.
+
+ -- Martin-Éric Racine   Mon, 29 Apr 2024 10:01:57 
+0300
+
 micro-httpd (20140814-2.1) unstable; urgency=medium
 
   * Non-Maintainer Upload.
diff -Nru micro-httpd-20140814/debian/control 
micro-httpd-20140814/debian/control
--- micro-httpd-20140814/debian/control 2020-02-06 01:14:09.0 +0200
+++ micro-httpd-20140814/debian/control 2024-04-29 10:01:15.0 +0300
@@ -2,7 +2,7 @@
 Section: httpd
 Priority: optional
 Maintainer: Sudip Mukherjee 
-Build-Depends: debhelper-compat (= 12)
+Build-Depends: debhelper-compat (= 13)
 Standards-Version: 4.5.0
 Rules-Requires-Root: no
 Vcs-Browser: https://github.com/sudipm-mukherjee/micro-httpd.git
@@ -11,7 +11,7 @@
 
 Package: micro-httpd
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, openbsd-inetd | inet-superserver 
| micro-inetd | netcat-traditional | systemd-sysv
+Depends: update-inetd | inet-superserver | openbsd-inetd | inetutils-inetd | 
rlinetd | xinetd, ${misc:Depends}, ${shlibs:Depends}
 Suggests: micro-proxy
 Provides: httpd
 Description: really small HTTP server
diff -Nru micro-httpd-20140814/debian/micro-httpd.lintian-overrides 
micro-httpd-20140814/debian/micro-httpd.lintian-overrides
--- micro-httpd-20140814/debian/micro-httpd.lintian-overrides   2020-02-06 
01:14:09.0 +0200
+++ micro-httpd-20140814/debian/micro-httpd.lintian-overrides   2024-04-29 
09:59:40.0 +0300
@@ -1,3 +1,3 @@
 # Using var/www/html/ as a new default document root
 # See #730372 and https://lists.debian.org/debian-devel/2012/04/msg00301.html
-micro-httpd: dir-or-file-in-var-www var/www/html/
+dir-or-file-in-var-www *var/www/html/*
diff -Nru micro-httpd-20140814/debian/micro-httpd@.service 
micro-httpd-20140814/debian/micro-httpd@.service
--- micro-httpd-20140814/debian/micro-httpd@.service2021-10-14 
16:02:47.0 +0300
+++ micro-httpd-20140814/debian/micro-httpd@.service2024-04-29 
09:38:36.0 +0300
@@ -7,3 +7,4 @@
 Group=www-data
 ExecStart=-/usr/sbin/micro-httpd /var/www/html
 StandardInput=socket
+StandardError=journal


Bug#1027978: micro-httpd: sends invalid HTTP when listing unreadable directories

2024-04-28 Thread Martin-Éric Racine
On Thu, 05 Jan 2023 13:08:45 + Vincent Duvert  wrote:
> When micro-httpd tries to list the contents of a directory but fails (if the
> directory is not readable, for instance), an invalid HTTP response is 
> returned:
>
> > GET /.well-known/ HTTP/1.0
> >
> < scandir: Permission denied
> < HTTP/1.0 200 Ok
> < Server: micro_httpd
> < ...
>
> Looking at the source code, micro-httpd calls perror( "scandir" ); after
> sending the HTTP headers, but due to standard output buffering, the error
> message ends up being sent first.
>
> An easy fix is to change micro-httpd@.service so micro-httpd's standard error
> is sent to the logs instead of the connection socket:
>
> [Service]
> StandardError=journal

I can implement this in an NMU.

> A more complete fix would be to move the call to scandir (line 119) just 
> before
> the call to send_headers(200, ...) (line 108), and to call send_error if 
> scandir
> fails.

This one needs to be sent to upstream.

If you do so, please take the opportunity to ask him to consider using
e.g. micro-httpd_2024-04-29.tar.xz as his tarball name. Tracking dates
in ISO format is a lot easier to implement than e.g. 14Aug2014.

Martin-Éric



Bug#1038882: proposal: dhcpcd-base as standard DHCP client starting with Trixie

2024-04-28 Thread Martin-Éric Racine
ma 11. maalisk. 2024 klo 7.02 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti:
> > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote:
> > > I hereby propose bin:dhcpcd-base:
> > >
> > > 1) already supported by ifupdown.
> > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege
> > > separation.
> > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf
> > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail
> > > 5) a mere inet line in /etc/network/interfaces is sufficient to
> > > configure both stacks.
> > >
> >
> > why not switch to systemd-networkd + networkmanager for gui installs?
>
> NM already is pulled by most desktop environments.
>
> Meanwhile a bare minimal system needs a non-GUI solution and swaping
> which DHCP client gets pulled by ifupdown is the simplest, least
> disruptive way of accomplishing this.

This bug is almost one year old. Are we going ahead with this or not?

Martin-Éric



Bug#1069870: linux-image-6.7.7-686-pae: please enable i915 mtl_* modules

2024-04-25 Thread Martin-Éric Racine
Package: src:linux
Version: 6.7.7-1
Severity: normal


W: Possible missing firmware /lib/firmware/i915/mtl_gsc_1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/mtl_huc_gsc.bin for module i915
W: Possible missing firmware /lib/firmware/i915/mtl_guc_70.bin for module i915


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

Kernel: Linux 6.7.7-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 linux-image-6.7.7-686-pae depends on:
ih  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod31+20240202-2
ii  linux-base  4.9

Versions of packages linux-image-6.7.7-686-pae recommends:
ii  apparmor 3.0.13-2
ii  firmware-linux-free  20200122-4

Versions of packages linux-image-6.7.7-686-pae suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.12-2~deb13u1
pn  linux-doc-6.7   

Versions of packages linux-image-6.7.7-686-pae is related to:
ii  firmware-amd-graphics 20230625-2
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20230625-2
pn  firmware-libertas 
ii  firmware-linux-nonfree20230625-2
ii  firmware-misc-nonfree 20230625-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20230625-2
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information



Bug#1069599: dhcpcd: isolation-machine autopkgtest fails: Unit systemd-timesyncd.service not found.

2024-04-21 Thread Martin-Éric Racine
su 21. huhtik. 2024 klo 14.59 Martin-Éric Racine
(martin-eric.rac...@iki.fi) kirjoitti:
>
> su 21. huhtik. 2024 klo 14.12 Paul Gevers (elb...@debian.org) kirjoitti:
> >
> > Source: dhcpcd
> > Version: 1:10.0.6-1
> > Severity: important
> > User: debian...@lists.debian.org
> > Usertags: isolation-machine
> >
> > Dear maintainer(s),
> >
> > Your package has an autopkgtest, great. I recently added support for
> > isolation-machine tests on ci.debian.net for amd64 and added your
> > package to the list to use that. However, it fails. Can you please
> > investigate the situation and fix it? I copied some of the output at the
> > bottom of this report.
>
> [...]
>
> >   29s autopkgtest [11:03:42]: test timesyncd-ntp-servers-from-dhcp:
> > [---
> >   30s Preparing virtual interfaces...
> >   30s Actual changes:
> >   30s tx-checksum-ip-generic: off
> >   30s tx-tcp-segmentation: off [not requested]
> >   30s tx-tcp-ecn-segmentation: off [not requested]
> >   30s tx-tcp-mangleid-segmentation: off [not requested]
> >   30s tx-tcp6-segmentation: off [not requested]
> >   30s tx-checksum-sctp: off
> >   30s Preparing dnsmasq configuration...
> >   35s Obtaining network configuration for veth1 via dhcp...
> >   37s RA from non local address fdae:9322:f1cc::1
> >   43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit
> > systemd-timesyncd.service not found.
> >   43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit
> > systemd-timesyncd.service not found.
> >   48s Check if the NTP server is made available to daemon...Failed to
> > parse bus message: No route to host
> >   49s autopkgtest [11:04:02]: test timesyncd-ntp-servers-from-dhcp:
> > ---]
>
> That service unit is provided by systemd-timesyncd, which systemd
> recommends. Basically, unless your testing environment explicitly
> installs another package providing time-daemon, this shouldn't happen,
> since systemd would have pulled systemd-timesyncd by default.

Anyhow, no harm done. The following commit should fix it:

https://salsa.debian.org/debian/dhcpcd/-/commit/55e588b0d7561c697f3fedfddef3feeb6c8b34b9

Martin-Éric



Bug#1069599: dhcpcd: isolation-machine autopkgtest fails: Unit systemd-timesyncd.service not found.

2024-04-21 Thread Martin-Éric Racine
su 21. huhtik. 2024 klo 14.12 Paul Gevers (elb...@debian.org) kirjoitti:
>
> Source: dhcpcd
> Version: 1:10.0.6-1
> Severity: important
> User: debian...@lists.debian.org
> Usertags: isolation-machine
>
> Dear maintainer(s),
>
> Your package has an autopkgtest, great. I recently added support for
> isolation-machine tests on ci.debian.net for amd64 and added your
> package to the list to use that. However, it fails. Can you please
> investigate the situation and fix it? I copied some of the output at the
> bottom of this report.

[...]

>   29s autopkgtest [11:03:42]: test timesyncd-ntp-servers-from-dhcp:
> [---
>   30s Preparing virtual interfaces...
>   30s Actual changes:
>   30s tx-checksum-ip-generic: off
>   30s tx-tcp-segmentation: off [not requested]
>   30s tx-tcp-ecn-segmentation: off [not requested]
>   30s tx-tcp-mangleid-segmentation: off [not requested]
>   30s tx-tcp6-segmentation: off [not requested]
>   30s tx-checksum-sctp: off
>   30s Preparing dnsmasq configuration...
>   35s Obtaining network configuration for veth1 via dhcp...
>   37s RA from non local address fdae:9322:f1cc::1
>   43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit
> systemd-timesyncd.service not found.
>   43s Failed to reload-or-try-restart systemd-timesyncd.service: Unit
> systemd-timesyncd.service not found.
>   48s Check if the NTP server is made available to daemon...Failed to
> parse bus message: No route to host
>   49s autopkgtest [11:04:02]: test timesyncd-ntp-servers-from-dhcp:
> ---]

That service unit is provided by systemd-timesyncd, which systemd
recommends. Basically, unless your testing environment explicitly
installs another package providing time-daemon, this shouldn't happen,
since systemd would have pulled systemd-timesyncd by default.

Martin-Éric



Bug#1068293: flowblade: 2.14 fails to launch due to missing app.py

2024-04-03 Thread Martin-Éric Racine
Solving this requires adding Depends: python3-libusb1



Bug#1068293: flowblade: 2.14 fails to launch due to missing app.py

2024-04-02 Thread Martin-Éric Racine
As see in 
:

"Distro packagers, please see info on the needed configuration file
addition (/etc/udev/rules.d/90-flowblade.rules) described in the link
to docs above."

Martin-Éric



Bug#1068293: flowblade: 2.14 fails to launch due to missing app.py

2024-04-02 Thread Martin-Éric Racine
Package: flowblade
Version: 2.14.0.1-1
Severity: important

$ flowblade 
FLOWBLADE MOVIE EDITOR 2.14.0.1
---
Launch script dir: /usr/bin
Running from installation...
modules path: /usr/share/flowblade/Flowblade
MLT found, version: 7.12.0
Failed to import module app.py to launch Flowblade!
ERROR: No module named 'usb1'
Installation was assumed to be at: /usr/share/flowblade/Flowblade


-- System Information:
Debian Release: 12.5
  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-18-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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flowblade depends on:
ii  ffmpeg7:5.1.4-0+deb12u1
ii  frei0r-plugins1.8.0-1+b1
ii  gir1.2-gdkpixbuf-2.0  2.42.10+dfsg-1+b1
ii  gir1.2-glib-2.0   1.74.0-3
ii  gir1.2-gtk-3.03.24.38-2~deb12u1
ii  gir1.2-pango-1.0  1.50.12+ds-1
ii  gmic  2.9.4-4+b4
ii  libmlt-data   7.12.0-1
ii  librsvg2-common   2.54.7+dfsg-1~deb12u1
ii  python3   3.11.2-1+b1
ii  python3-cairo 1.20.1-5+b1
ii  python3-dbus  1.3.2-4+b1
ii  python3-distutils 3.11.2-3
ii  python3-gi3.42.2-3+b1
ii  python3-gi-cairo  3.42.2-3+b1
ii  python3-mlt   7.12.0-1+b1
ii  python3-numpy 1:1.24.2-1
ii  python3-opencv4.6.0+dfsg-12
ii  python3-pil   9.4.0-1.1+b1
ii  swh-plugins   0.4.17-2

flowblade recommends no packages.

flowblade suggests no packages.

-- no debconf information



Bug#1067909: libc-devtools: please relax Depends on libgd3

2024-03-28 Thread Martin-Éric Racine
pe 29. maalisk. 2024 klo 1.01 Aurelien Jarno (aure...@debian.org) kirjoitti:
>
> On 2024-03-28 20:35, Martin-Éric Racine wrote:
> > Package: libc-devtools
> > Severity: normal
> >
> > libgd3 pulls an excessive amount of dependencies, including fonts. It would 
> > thus be desirable to downgrade it to a mere Recommends.
> >
>
> The /usr/bin/memusagestat binary is linked against libgd3, so we can't just
> changes the Depends to a Recommends.

Noted.

Alternately, dropping libc-dev-bin's Recommends on libc-devtools to a
mere Suggests would accomplish the same thing. The key idea here is to
avoid pulling fonts and tons of graphics libraries in.

Martin-Éric



Bug#1067909: libc-devtools: please relax Depends on libgd3

2024-03-28 Thread Martin-Éric Racine
Package: libc-devtools
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

libgd3 pulls an excessive amount of dependencies, including fonts. It would 
thus be desirable to downgrade it to a mere Recommends.

Martin-Éric

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

Kernel: Linux 6.1.0-18-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 libc-devtools depends on:
ii  libc6   2.37-15.1
pn  libgd3  

Versions of packages libc-devtools recommends:
ii  manpages  6.05.01-1
ii  manpages-dev  6.05.01-1

libc-devtools suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmYFuH0ACgkQrh+Cd8S0
17ayNw/+KowbskIoaRqYApa3kOPNWPtLD/rvbEOISdjvJKBz9chs7cYImdtQdd7h
9Z+R6U9AGnxrOTUXxO2a1lfGtpgxVFMemiHIN361zV3kA7IdqX62e1kvAT2dympy
Gselwg1Jr5PULghzDAdBcYlZ82S7roYnbh7lhd0vcS90xjCatL4Hk7+/bwCgISvB
2wgICAeXV5YrYxx4pX8FfeLUfGbsCRxzW0sKnG61a+RxGRykP5p+hiccSG2IACyL
Wks1Jymf5jLO3Qk3hzYykN3iCikx/dM6wMscDXp36olD+kliD+0I6YDAFHXFIcrb
FeL97pqFvNhoz8Q81IbML2BfZfMAEoAlSp5ROqqxyGuqo9BYzc9tDUkwaacPEJCY
9R2sAB1SHgwObOITueTRynfm1kIbemwi/ydiOBT7jjnYNTV3I52DdAdRaqqhSeUM
hbCxk960xqF/v2IcMjc92wNepwI8dj4FGmQPgGwJ3JYuVa4y5IncFhf3N93KK00V
bduJya6sT/2vR0PtsLnXnAQzh71SyEnqPGGvgQ8031JJ5zivqHZuLx0Huf/ZcjWY
CMBmTI2WRByOwqGgA3kpSh5fc7gozb2to/XHTuS7vWFS03KNwZTe+oacHJaVEYTW
rL04tKeCZD5t4e4rvrjKABFgheH/Q+TQPS0VfA2NrSYk76qfIeY=
=mkEr
-END PGP SIGNATURE-


  1   2   3   4   5   6   7   8   9   10   >