Bug#1069867: autopkgtest to test %U substitution in included config files

[Santiago Ruano Rincón]

Source: samba
Severity: wishlist
Tags: patch

Dear samba maintainers,

Please, find attached an autopkgtest that checks if %U variable
substitution in include config files works correctly.

I have include it and verified it works in the recent buster update
https://tracker.debian.org/news/1520926/accepted-samba-2495dfsg-5deb10u5-source-into-oldoldstable/
to confirm it didn't introduce regressions like the one described at:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2003867

Cheers,

  -- Santiago
#!/bin/sh -x
#
# Test to check regressions such as:
# https://bugs.launchpad.net/ubuntu/+source/samba/+bug/2003867

username="smbtest$$"
password="$$"

cat >> /etc/samba/smb.conf <> /etc/samba/${username}.conf  ${userhome}/data
chown ${username}:${username} ${userhome}/data
cd ${userhome}
md5sum data > data.md5

rm -f downloaded-data
echo "Downloading file and comparing its md5"
smbclient //localhost/${username} -U ${username}%${password} -c "get data 
downloaded-data"

mv -f downloaded-data data
md5sum -c data.md5


signature.asc
Description: PGP signature

Bug#1068718: freeimage: consider packaging r1909?

[Santiago Ruano Rincón]

Source: freeimage
Version: 3.18
Severity: normal
X-Debbugs-Cc: t...@security.debian.org

Dear freeimage maintainers and security team,

This is a bug report to discuss if freeimage r1909 should be packaged, while
there is no official 3.19 release.
The svn is found here: https://sourceforge.net/p/freeimage/svn/HEAD/tree/

It is to note that there a some CVEs reported against that SVN revision, and
there is no clear indication they affect 3.18 or older releases. So this could
mean introducing some bugs.
See: https://github.com/Ruanxingzhi/vul-report/tree/master/freeimage-r1909

Any thoughts? 

  -- Santiago


signature.asc
Description: PGP signature

Bug#921750: security-warning hook not found, fails open

[Santiago Ruano Rincón]

On Fri, 08 Feb 2019 15:18:55 -0500 Antoine Beaupre  wrote:
> Package: dput-ng
> Version: 1.22
> Severity: important
> 
> Hi!
> 
> I tried switching to dput-ng again, and here's what happened:
> 
> anarcat@curie:dist$ dput security-master 
> libreoffice_4.3.3-2+deb8u12_amd64.changes
> Uploading libreoffice using ftp to security-master (host: 
> ftp.security.upload.debian.org; directory: /pub/SecurityUploadQueue)
> running allowed-distribution: check whether a local profile permits uploads 
> to the target distribution
> running protected-distribution: warn before uploading to distributions where 
> a special policy applies
> running checksum: verify checksums before uploading
> running suite-mismatch: check the target distribution for common errors
> running gpg: check GnuPG signatures before the upload
> Could not execute /usr/share/dput/helper/security-warning: [Errno 2] No such 
> file or directory: '/usr/share/dput/helper/security-warning': 
> '/usr/share/dput/helper/security-warning'
> Error: You've set a hook (pre_upload_command) to run 
> (`/usr/share/dput/helper/security-warning`), but it can't be found (and 
> doesn't appear to exist). Please verify the path and correct it.
> Uploading libreoffice_4.3.3-2+deb8u12.dsc
> Uploading libreoffice_4.3.3-2+deb8u12.debian.tar.xz
> Uploading libreoffice_4.3.3-2+deb8u12_amd64.deb
> [...]
> 
> ie. it didn't find the `security-warning` file it's supposed to show
> and prompt the user but worse, it then just went on uploading the
> package normally.
> 
> The warning should be shown, and failing that, the upload should fail
> if the hook is missing.
> 
> Thanks for the nice work! :)

I've also been hit by this. And the problem seems to be the old-style
/etc/dput.cf, that overrides the dput-ng profiles. I've purged dput,
hoping this would help the next time.

FWIW, dput-ng comes with a protected-distribution hook, that has the
same goal of security-warning.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1059331: spip: XSS issue fixed in 4.1.13 upstream

[Santiago Ruano Rincón]

Control: fixed -1 4.1.9+dfsg-1+deb12u4

From 
https://sources.debian.org/src/spip/4.1.9%2Bdfsg-1%2Bdeb12u4/debian/changelog/

spip (4.1.9+dfsg-1+deb12u4) bookworm; urgency=medium

  * Backport security fix from 4.1.15
- fix XSS in uploaded files using bigup

 -- David Prévot   Fri, 12 Jan 2024 13:42:36 +0100

spip (4.1.9+dfsg-1+deb12u3) bookworm; urgency=medium

  * Backport security fix from 4.1.13
- fix XSS when calling some templates

 -- David Prévot   Thu, 21 Dec 2023 19:24:13 +0100

The 4.1.13 backport was part of 4.1.9+dfsg-1+deb12u3, but it seems it
was not uploaded.

On Fri, 22 Dec 2023 16:57:40 +0100 Salvatore Bonaccorso  
wrote:
> Source: spip
> Version: 4.1.12+dfsg-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: fixed -1 4.1.13+dfsg-1
> Control: found -1 4.1.9+dfsg-1+deb12u2
> Control: found -1 3.2.11-3+deb11u9
> 
> Filling a bug for tracking (as otherwise beeing a unspecified TEMP
> entry), as the issue has no CVE: 4.1.13 fixes an issue:
> 
>* fix: les modèles insérés dans un texte héritent automatiquement du
>  contexte, a l'insu des redacteurs. Securiser ce qui proviendrait de
>  variables envoyées par l'utilisateur
> 
> https://tracker.debian.org/news/1488834/accepted-spip-4113dfsg-1-source-into-unstable/
> 
> Regards,
> Salvatore


signature.asc
Description: PGP signature

Bug#1059331: spip: XSS issue fixed in 4.1.13 upstream

[Santiago Ruano Rincón]

Control: fixed -1 3.2.11-3+deb11u10

https://tracker.debian.org/news/1500839/accepted-spip-3211-3deb11u10-source-into-oldstable-proposed-updates/

On Fri, 22 Dec 2023 16:57:40 +0100 Salvatore Bonaccorso  
wrote:
> Source: spip
> Version: 4.1.12+dfsg-1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: fixed -1 4.1.13+dfsg-1
> Control: found -1 4.1.9+dfsg-1+deb12u2
> Control: found -1 3.2.11-3+deb11u9
> 
> Filling a bug for tracking (as otherwise beeing a unspecified TEMP
> entry), as the issue has no CVE: 4.1.13 fixes an issue:
> 
>* fix: les modèles insérés dans un texte héritent automatiquement du
>  contexte, a l'insu des redacteurs. Securiser ce qui proviendrait de
>  variables envoyées par l'utilisateur
> 
> https://tracker.debian.org/news/1488834/accepted-spip-4113dfsg-1-source-into-unstable/
> 
> Regards,
> Salvatore


signature.asc
Description: PGP signature

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

[Santiago Ruano Rincón]

Hi there,

El 20/11/23 a las 19:44, Martin-Éric Racine escribió:
> (non-subscriber - please keep me in CC)
> On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine
>  wrote:
> >
> > On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine
> >  wrote:
> > >
> > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine
> > >  wrote:
> > > >
> > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón
> > > >  wrote:
> > > > >
> > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> > > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > > > > > >  wrote:
> > > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > > > > > > Greetings,
> > > > > > > > >
> > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now 
> > > > > > > > > might be a
> > > > > > > > > good time to re-visit Debian's choice of standard DHCP client 
> > > > > > > > > shipping
> > > > > > > > > with priority:important.
> > > > > > > > >
> > > > > > > > > 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.
> > > > > > > > ...
> > > > > > > >
> > > > > > > > I agree that dhcpcd seems the best alternative to 
> > > > > > > > isc-dhcp-client for
> > > > > > > > the moment, and I'll make the relevant changes in ifupdown as 
> > > > > > > > soon as I
> > > > > > > > can. Josué, any thoughts?
> > > > > > >
> > > > > > > 1) As someone pointed out in the thread, the reason why
> > > > > > > isc-dhcp-client had priority:important probably was to ensure that
> > > > > > > debootstrap would pull it, since debootstrap ignores Recommends 
> > > > > > > and
> > > > > > > packages with a priority lower than standard.
> > > > > > >
> > > > > > > 2) However, as long as ifupdown explictly depends on a package, 
> > > > > > > it can
> > > > > > > also pull dependencies with a lower priority. Right now ifupdown
> > > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would
> > > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" 
> > > > > > > instead.
> > > > > > >
> > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and
> > > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of 
> > > > > > > both
> > > > > > > could, in principle, be optional, just as long as ifupdown 
> > > > > > > explicitly
> > > > > > > Depends on a DHCP client, and the first alternative is a real 
> > > > > > > package.
> > > > > >
> > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if
> > > > > > isc-client-dhcp is a Recommends, is because not all users want a 
> > > > > > dhcp
> > > > > > client installed, where all the ipv4 is handled statically, and 
> > > > > > ipv6 is
> > > > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base 
> > > > > > the
> > > > > > next upgrade.
> > > > > >
> > > > > > So I'd prefer to go forward with the steps proposed by Simon, and
> > > > > > s/isc-d

Bug#1039443: python3-paramiko: please package v3.2.0 an remove python3-six dependency

[Santiago Ruano Rincón]

On Thu, 8 Feb 2024 23:55:38 -0300 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= 
 wrote:
> Control: retitle: -1 python3-paramiko: please package v3.4.0 an remove 
> python3-six dependency
> Control: block #1059006 by -1
> 
> On Mon, 26 Jun 2023 01:49:36 +0200 Alexandre Detiste 
>  wrote:
> > Package: python3-paramiko
> > Version: 2.12.0-2
> > Severity: normal
> > 
> > Hi,
> > 
> > Please uplaod the new version to complete the Py2->3 conversion.
> > 
> > https://bitprophet.org/blog/2021/02/25/byethon2/
> > 
> > You might also close these two Py2 related bugs at the same time:
> > 
> >   #800386  obnam: UnicodeDecodeError python exception during backup
> >   #947470  paramiko: [Py3] TypeError: a bytes-like object is required,
> >not 'str' in pkey.write_private_key()
> > 
> > Greetings,
> > 
> 
> Dear paramiko maintainers,
> 
> v3.4.0 was released on Dec 18 2023. It especially fixes the Terrapin
> Attack (CVE-2023-48795).
> Do you need/want any help on this? (maybe under the Python Team
> umbrella)

I've started packaging 3.4.0 in the wip/debian/3.4.0 branch.

cheers,

  -- S


signature.asc
Description: PGP signature

Bug#1064260: omniorb-dfsg: NMU diff for 64-bit time_t transition

[Santiago Ruano Rincón]

El 29/02/24 a las 10:29, Santiago Ruano Rincón escribió:
> Hello Benjamin,
> 
> 
> El 29/02/24 a las 02:23, Benjamin Drung escribió:
> > Source: omniorb-dfsg
> > Dear maintainer,
> > 
> > Please find attached a final version of this patch for the time_t
> > transition.  This patch is being uploaded to unstable.
> > 
> > Note that this adds a versioned build-dependency on dpkg-dev, to guard
> > against accidental backports with a wrong ABI.
> > 
> > Thanks!
> 
> From Steve's report 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064260#5:
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Benjamin, thanks for your work, but why have you uploaded them to
> unstable without delay, and without any coordination/notice?
> 
> Steve, does the above notice still applies?
> 
> Without an answer that confirms this should be uploaded to unstable, I
> would prefer to revert these changes before they migrate to testing.

And it seems I was missing the announcement:
https://lists.debian.org/debian-devel-announce/2024/02/msg5.html

Thanks again for your work, and sorry for the noise.

 -- S


signature.asc
Description: PGP signature

Bug#1064260: omniorb-dfsg: NMU diff for 64-bit time_t transition

[Santiago Ruano Rincón]

Hello Benjamin,


El 29/02/24 a las 02:23, Benjamin Drung escribió:
> Source: omniorb-dfsg
> Dear maintainer,
> 
> Please find attached a final version of this patch for the time_t
> transition.  This patch is being uploaded to unstable.
> 
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental backports with a wrong ABI.
> 
> Thanks!

From Steve's report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064260#5:

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

Benjamin, thanks for your work, but why have you uploaded them to
unstable without delay, and without any coordination/notice?

Steve, does the above notice still applies?

Without an answer that confirms this should be uploaded to unstable, I
would prefer to revert these changes before they migrate to testing.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1055067: isc-dhcp-client: network-manager 1.44.2-3 changed path to nm-dhcp-helper, apparmor need update

[Santiago Ruano Rincón]

El 30/10/23 a las 18:29, Sven-Haegar Koch escribió:
> Package: isc-dhcp-client
> Version: 4.4.3-P1-4
> Severity: normal
> 
> Dear Maintainer,
> 
> I am using network manager with /etc/NetworkManager/NetworkManager.conf
> 
>   [main]
>   dhcp=dhclient
> 
> and thus using isc-dhcp-client as my DHCP client.
> 
> With the update of network-manager 1.44.2-3 the nm-dhcp-helper moved
> from /usr/lib/NetworkManager/ to /usr/libexec/.
> 
> Without a fix to /etc/apparmor.d/sbin.dhclient the system now fails to
> activate interfaces using DHCP, logging
> 
> audit: type=1400 audit(1698680734.539:50): apparmor="DENIED" operation="exec" 
> class="file" profile="/{,usr/}sbin/dhclient" 
> name="/usr/libexec/nm-dhcp-helper" pid=7523 comm="dhclient" 
> requested_mask="x" denied_mask="x" fsuid=0 ouid=0
> 
> The following diff fixes it for me - just duplicating the existing
> rules to the new path:
> 
> diff --git a/etc/apparmor.d/sbin.dhclient b/etc/apparmor.d/sbin.dhclient
> index 1acc6b92..b219d688 100644
> --- a/etc/apparmor.d/sbin.dhclient
> +++ b/etc/apparmor.d/sbin.dhclient
> @@ -69,6 +69,8 @@
># Support the new executable helper from NetworkManager.
>/usr/lib/NetworkManager/nm-dhcp-helper  Pxrm,
>signal (receive) peer=/usr/lib/NetworkManager/nm-dhcp-helper,
> +  /usr/libexec/nm-dhcp-helper Pxrm,
> +  signal (receive) peer=/usr/libexec/nm-dhcp-helper,
>  
># Site-specific additions and overrides. See local/README for details.
>#include 
> @@ -101,6 +103,21 @@
>network inet6 dgram,
>  }
>  
> +/usr/libexec/nm-dhcp-helper {
> +  #include 
> +  #include 
> +  /usr/libexec/nm-dhcp-helper mr,
> +
> +  /run/NetworkManager/private-dhcp rw,
> +  signal (send) peer=/sbin/dhclient,
> +
> +  /var/lib/NetworkManager/*lease r,
> +  signal (receive) peer=/usr/sbin/NetworkManager,
> +  ptrace (readby) peer=/usr/sbin/NetworkManager,
> +  network inet dgram,
> +  network inet6 dgram,
> +}
> +
>  /usr/lib/connman/scripts/dhclient-script {
>#include 
>#include 
> 
> 
> Greetings,
> Sven

Hi!

Really sorry, this has fallen through the cracks.

Could you please confirm the version available in this repo fixes the
issue:

https://debian.pages.debian.net/-/isc-dhcp/-/jobs/5350735/artifacts/aptly/index.html

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1039443: python3-paramiko: please package v3.2.0 an remove python3-six dependency

[Santiago Ruano Rincón]

Control: retitle: -1 python3-paramiko: please package v3.4.0 an remove 
python3-six dependency
Control: block #1059006 by -1

On Mon, 26 Jun 2023 01:49:36 +0200 Alexandre Detiste 
 wrote:
> Package: python3-paramiko
> Version: 2.12.0-2
> Severity: normal
> 
> Hi,
> 
> Please uplaod the new version to complete the Py2->3 conversion.
> 
> https://bitprophet.org/blog/2021/02/25/byethon2/
> 
> You might also close these two Py2 related bugs at the same time:
> 
>   #800386  obnam: UnicodeDecodeError python exception during backup
>   #947470  paramiko: [Py3] TypeError: a bytes-like object is required,
>not 'str' in pkey.write_private_key()
> 
> Greetings,
> 

Dear paramiko maintainers,

v3.4.0 was released on Dec 18 2023. It especially fixes the Terrapin
Attack (CVE-2023-48795).
Do you need/want any help on this? (maybe under the Python Team
umbrella)

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1019980: lintian: source-is-missing check for HTML is much too sensitive

[Santiago Ruano Rincón]

On Sat, 14 Oct 2023 20:23:18 +0200 Bill Allombert  wrote:
> On Sun, Sep 18, 2022 at 12:14:07AM +0100, Colin Watson wrote:
> > Package: lintian
> > Version: 2.115.3
> > Severity: normal
> > 
> > Lintian issues these errors for putty 0.77-1:
> > 
> >   E: putty source: source-is-missing [doc/html/AppendixA.html]
> >   E: putty source: source-is-missing [doc/html/AppendixB.html]
> >   E: putty source: source-is-missing [doc/html/AppendixE.html]
> >   E: putty source: source-is-missing [doc/html/Chapter10.html]
> >   E: putty source: source-is-missing [doc/html/Chapter2.html]
> >   E: putty source: source-is-missing [doc/html/Chapter3.html]
> >   E: putty source: source-is-missing [doc/html/Chapter4.html]
> >   E: putty source: source-is-missing [doc/html/Chapter5.html]
> >   E: putty source: source-is-missing [doc/html/Chapter7.html]
> >   E: putty source: source-is-missing [doc/html/Chapter8.html]
> >   E: putty source: source-is-missing [doc/html/Chapter9.html]
> >   E: putty source: source-is-missing [doc/html/IndexPage.html]
> > 
> > This is pretty oversensitive.  Firstly, it's HTML, which is still often
> > enough written by hand anyway.  As it happens, these particular HTML
> > files are generated from halibut input that's also provided in the
> > source package, though I can't see how Lintian could possibly expect to
> > know that.
> 
> Dear Lintian maintainers,
> 
> This test is causing hundreds of false positive and should be disabled as
> soon as possible. This is a huge waste of time for everybody.
> 
> If you need help with that, please tell me, I have worked on lintian in the 
> past.

Dear Lintian maintainers,

I cannot offer the same help as ballombe, but I also find it would help
to disable these errors. At least, could they be "demoted" to warnings?

Thanks in advance,

Santiago


signature.asc
Description: PGP signature

Bug#1025062: systemd-resolved Provides: resolvconf, but is missing the isc-dhcp-client integration from resolvconf

[Santiago Ruano Rincón]

Control: severity -1 important

On Mon, 5 Feb 2024 07:18:30 -0300 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= 
 wrote:
> El 31/01/24 a las 18:47, Antoine Durand-Gasselin escribió:
> > On Mon, 8 May 2023 00:43:30 +0100 Ken Milmore 
> > wrote:
> > > I was motivated to try fixing this after installing systemd-resolved
> > on bookworm and finding that my DNS was completely broken.
> > > 
> > > I have tested the Ubuntu hook scripts with DHCP enabled for both IPv4
> > and/or IPv6. They work well for me so far.
> > > 
> > > I have attached a source patch against isc-dhcp master on Salsa. This
> > just adds the verbatim hook scripts from Ubuntu.
> > > [...]
> > > 
> > 
> > Dear Debian ISC DHCP Maintainers,
> > 
> > Broken DNS after installing systemd-resolved is quite annoying.
> > Ubuntu has come up with a fix for that, so is there anything blocking
> > using the same fix here ?
> 
> Hi!
> 
> Sorry, I am not sure why I have missed this. I'll process this later
> today.

Since there is some /usr-merge-related changes already applied in
experimental, I've pushed to experimental too, and will upload to
unstable (and then bookworm), once it is safe to move all the changes.

Also, bumping the severity to important, since this bug breaks some DNS
resolution setups.

Cheers, and thanks for your patience,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1025062: systemd-resolved Provides: resolvconf, but is missing the isc-dhcp-client integration from resolvconf

[Santiago Ruano Rincón]

El 31/01/24 a las 18:47, Antoine Durand-Gasselin escribió:
> On Mon, 8 May 2023 00:43:30 +0100 Ken Milmore 
> wrote:
> > I was motivated to try fixing this after installing systemd-resolved
> on bookworm and finding that my DNS was completely broken.
> > 
> > I have tested the Ubuntu hook scripts with DHCP enabled for both IPv4
> and/or IPv6. They work well for me so far.
> > 
> > I have attached a source patch against isc-dhcp master on Salsa. This
> just adds the verbatim hook scripts from Ubuntu.
> > [...]
> > 
> 
> Dear Debian ISC DHCP Maintainers,
> 
> Broken DNS after installing systemd-resolved is quite annoying.
> Ubuntu has come up with a fix for that, so is there anything blocking
> using the same fix here ?

Hi!

Sorry, I am not sure why I have missed this. I'll process this later
today.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1060089: isc-dhcp: install dhclient into /usr/sbin, with DEP17 M18 diversions

[Santiago Ruano Rincón]

El 23/01/24 a las 10:34, Helmut Grohne escribió:
> On Tue, Jan 23, 2024 at 01:29:51AM +0100, Chris Hofstaedtler wrote:
> > Attached is an improved patch, that avoids the temporary file loss
> > that could occur in the old version. This is mostly based on work by
> > Helmut Grohne.
> 
> Thank you.
> 
> Reviewed-by: Helmut Grohne 
> 
> I could not identify issues. The begin-remove-after markup feels
> slightly inconsistent as it partially cleans up the mitigation, but
> cleaning up the part in -ddns using this simple markup is non-trivial
> and keeping those snippets a little longer shall not cause breakage, so
> while this isn't perfect, I think it's good to go as is.
> 
> I also locally built this change and performed bootstrap testing with
> debootstrap, cdebootstrap and mmebstrap (which include isc-dhcp-client
> in the larger variants).
> 
> > Please consider this version of the patch.
> 
> I second this request. I appreciate to have this resolved by the end of
> February. Preferrably, we have this change in experimental for a few
> days before transitioning to unstable to allow for more QA.
> 
> Helmut

Done. Thanks a lot to both of your for your work.


signature.asc
Description: PGP signature

Bug#1060426: autopkgtest-build-qemu doesn't pass --mirror (or the obsolete mirror positional argument) to setup-testbed

[Santiago Ruano Rincón]

Package: autopkgtest
Version: 5.31.2
Severity: normal
Tags: patch

Dear maintainers,

autopkgtest-build-qemu ends up in error when trying to build an image
for Freexian's stretch ELTS. The image is successfully built for the
archived (as in archive.d.o) stretch. This is the relevant part of the
log:

/usr/share/autopkgtest/setup-commands/setup-testbed: Attempting to set up 
Debian/Ubuntu apt sources automatically
Failed to auto-detect apt mirror; set $MIRROR explicitly
ERROR: Program failed: 1
ERROR: RuncmdError('Program failed: 1')
Something went wrong, cleaning up!

I'll prepare a MR, but in the meantime, the attache patch fixes the
issue.

Thanks!

 -- S

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.7.8
ii  libdpkg-perl1.22.2
ii  mawk1.3.4.20231126-1
ii  procps  2:4.0.4-2+b1
ii  python3 3.11.6-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.32.2-1+b1

Versions of packages autopkgtest suggests:
ii  docker.io20.10.25+dfsg1-2+b3
pn  fakemachine  
ii  genisoimage  9:1.1.11-3.4
ii  lxc  1:5.0.3-2
pn  lxd  
ii  ovmf 2023.11-4
pn  ovmf-ia32
pn  podman   
ii  python3-distro-info  1.7
ii  qemu-efi-aarch64 2023.11-4
ii  qemu-efi-arm 2023.11-4
ii  qemu-system  1:8.2.0+ds-4
ii  qemu-utils   1:8.2.0+ds-4
ii  schroot  1.6.13-3+b3
ii  util-linux   2.39.3-6
ii  vmdb20.28-1
ii  zerofree 1.1.1-1

-- no debconf information
From b21a596e11a2f5daf9ef4886a81911519ac4337e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Santiago=20Ruano=20Rinc=C3=B3n?= 
Date: Wed, 10 Jan 2024 22:11:21 -0500
Subject: [PATCH] autopkgtest-build-qemu pass MIRROR to setup-testbed

---
 tools/autopkgtest-build-qemu | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/autopkgtest-build-qemu b/tools/autopkgtest-build-qemu
index c3938b0..a7d135c 100755
--- a/tools/autopkgtest-build-qemu
+++ b/tools/autopkgtest-build-qemu
@@ -587,6 +587,7 @@ class BuildQemu:
 'shell': (
 'export AUTOPKGTEST_BUILD_QEMU=1; ' +
 'export RELEASE=' + shlex.quote(release) + '; ' +
+'export MIRROR=' + shlex.quote(mirror) + '; ' +
 shlex.quote(s) + ' "$ROOT"'
 ),
 'root-fs': 'root',
-- 
2.43.0



signature.asc
Description: PGP signature

Bug#1060300: virt-v2v: needs to update OVMF x86_64 pflash images path to match the new 4MB images

[Santiago Ruano Rincón]

Source: virt-v2v
Version: 2.2.0-1
Severity: important
Tags: upstream patch
X-Debbugs-Cc: Lee Garrett 

Dear maintainer,

With edk2 2023.11-2, the OVMF 2MB pflash images have been removed and
replaced with their 4MB counterparts.
See 
https://salsa.debian.org/qemu-team/edk2/-/blob/76f721d51f93647a8f3650f9f26593ff82089ad0/debian/ovmf.NEWS

Currently, virt-v2v is unable to convert a Win 11 image (from ova to
qcow2) since it is not able to find the UEFI files. ovmf 2023.11-3 is
currently installed on my system.

virt-v2v -v -x -i ova -o libvirt -of qcow2 -oo compressed -oc 
'qemu:///system' ~/.cache/ansible_bootstrap_win11_vm/win11.zip -on win11

fails with:

virt-v2v: error: cannot find firmware for UEFI guests.

You probably need to install OVMF (x86-64), or AAVMF (aarch64)

I can provide a full log, if needed

A fix can be found in 
https://salsa.debian.org/santiago/virt-v2v/-/commits/OVMF-4M

Cheers,

 -- Santiago

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

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

-- no debconf information


signature.asc
Description: PGP signature

Bug#1060296: virt-v2v: Wrong dependency on nbdkit-pthon-plugin

[Santiago Ruano Rincón]

Package: virt-v2v
Version: 2.4.0-1
Severity: serious
Tags: patch
X-Debbugs-Cc: Lee Garrett 

Dear maintainer,

virt-v2v 2.4.0-1 is not installable since it depends on a wrongly listed
package: nbdkit-python-plugin. The correct name is nbdkit-plugin-python.

I also suggests nbdkit-vddk-plugin, that doesn't exist.

I am preparing a MR that includes this fix. But the following simple
change solves the issue:

diff --git a/debian/control b/debian/control
index 313dba7..08de83e 100644
--- a/debian/control
+++ b/debian/control
@@ -33,7 +33,7 @@ Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends},
  libnbd-bin,
  nbdkit,
- nbdkit-python-plugin,
+ nbdkit-plugin-python,
  qemu-utils,
 Suggests: rhsrvany, nbdkit-vddk-plugin


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

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

Versions of packages virt-v2v depends on:
ii  libc62.37-13
ii  libglib2.0-0 2.78.3-1
ii  libguestfs0  1:1.50.1-4+b3
ii  libjansson4  2.14-2
ii  libnbd0  1.18.1-1
ii  libosinfo-1.0-0  1.11.0-2
ii  libpcre2-8-0 10.42-4
ii  libvirt0 9.10.0-1
ii  libxml2  2.9.14+dfsg-1.3+b1

virt-v2v recommends no packages.

virt-v2v suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1059755: grep: move files to /usr for DEP17

[Santiago Ruano Rincón]

Control: fixed -1 grep/3.11-4~exp1


signature.asc
Description: PGP signature

Bug#1059755: grep: move files to /usr for DEP17

[Santiago Ruano Rincón]

Control: tags -1 + fixed-in-experimental

Hi Helmut!

El 31/12/23 a las 13:55, Helmut Grohne escribió:
> Package: grep
> Version: 3.11-3
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2
> 
> Hi,
> 
> in order to finalize the /usr-merge via DEP17, we are about to move
> files to /usr. grep is relevant now, because it is part of the essential
> set used by debootstrap. Hence, I'm sending a patch. This patch must not
> be backported to bookworm-backports or older. If you want to keep grep
> easily backportable, please use dh_movetousr instead.
> 
> Helmut

> diff --minimal -Nru grep-3.11/debian/changelog grep-3.11/debian/changelog
> --- grep-3.11/debian/changelog2023-08-22 19:49:07.0 +0200
> +++ grep-3.11/debian/changelog2023-12-31 13:49:35.0 +0100
> @@ -1,3 +1,10 @@
> +grep (3.11-3.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Move files to /usr. (Closes: #-1)
> +
> + -- Helmut Grohne   Sun, 31 Dec 2023 13:49:35 +0100
> +
>  grep (3.11-3) unstable; urgency=medium
>  
>* Add patch to remove generated files in clean target. Patch by Bas
> diff --minimal -Nru grep-3.11/debian/rules grep-3.11/debian/rules
> --- grep-3.11/debian/rules2023-08-22 19:43:09.0 +0200
> +++ grep-3.11/debian/rules2023-12-31 13:49:34.0 +0100
> @@ -38,10 +38,6 @@
>  endif
>  DEB_CONFIGURE_SCRIPT_ENV += LIBS="$(LIBS)"
>  
> -# FIXME: CDBS should include a specific var for this
> -# (e.g. DEB_CONFIGURE_EXECDIR in autotools-vars.mk)?
> -DEB_CONFIGURE_EXTRA_FLAGS += --exec-prefix=/
> -
>  # Run expensive tests only on amd64 and i386. Builders have had some
>  # problems with expensive checks, e.g. long-pattern-perf, on other
>  # architectures such as s390x, ppc64el and hurd-i386.

This has been addressed in 3.11-4~exp1, that is now waiting in
experimental. If you are OK, I can upload it to unstable.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1059272: transition: tango

[Santiago Ruano Rincón]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: ta...@packages.debian.org, thomas.br...@byte-physics.de
Control: affects -1 + src:tango

Dear Release Team,

I would like to upload tango 9.5.0 to unstable. There has been a SONAME
bump from 9.4.2. Its reverse dependency pytango 9.5.0 builds and works
well. Both are available in experimental.

This set of uploads are needed to fix the pytango FTBFS bugs in unstable
related to python3.12:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055733
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049843

Even if there is only one reverse dependency, I prefer to ask: May I go
ahead?

Ben file:

title = "tango";
is_affected = .depends ~ "old="libtango9-4"" | .depends ~ "old="libtango95"";
is_good = .depends ~ "old="libtango95"";
is_bad = .depends ~ "old="libtango9-4"";

Thank you,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1057877: Package new tango upstream release: 9.5.0

[Santiago Ruano Rincón]

Source: tango
Severity: normal
Control: block 1057862 -1
Control: block 1055733 -1

Upstream has released version 9.5.0. Pytango 9.5.0 fixes the
python3.12-related versions, but it requires (cpp)tango 9.5.0 to be
packaged first.

I will prepare releases for both packages.


signature.asc
Description: PGP signature

Bug#1053246: Security support ended for Xen 4.14 in Bullseye

[Santiago Ruano Rincón]

El 01/12/23 a las 00:55, Maximilian Engelhardt escribió:
> On Montag, 2. Oktober 2023 19:18:49 CET Santiago Ruano Rincón wrote:
> > El 30/09/23 a las 00:09, Hans van Kranenburg escribió:
> > > Package: debian-security-support
> > > Version: 1:11+2023.05.04
> > > Severity: normal
> > > 
> > > Hi,
> > > 
> > > Upstream security support for Xen 4.14 has ended recently. This also
> > > means that security support for Debian Bullseye has ended.
> > > 
> > > The complexity of the software involved does not really allow for anyone
> > > else than the upstream developers, with a deep understanding of the
> > > inner workings of the hypervisor code, to apply/backport new patches.
> > > 
> > > For security-support-ended.deb11, this could be a line like:
> > > 
> > > xen 4.14.6-1 2023-09-21
> > > https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support
> > > 
> > > Note: This 4.14.6-1 package version is not visible for bullseye yet,
> > > right now, in the archive. It was submitted for the bullseye point
> > > release, and has just been accepted into it:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053177
> > > 
> > > Thanks,
> > > Hans
> > 
> > Hello,
> > 
> > Could you please wait a little bit before moving forward. In the Debian
> > bullseye LTS context, we would like to know if there are interest from
> > LTS users, and look for help to maintain it. At least, partially.
> > 
> > Thank you,
> > 
> >  -- Santiago
> 
> Hi Santiago,
> 
> Any update on this?
> As upstream security support for xen 4.14 has ended, the Debian xen team 
> doesn't have the knowledge and resources to provide further security support.
> So if there are people with the resources and knowledge to further provide 
> security support for xen in bullseye it would be good to know this is 
> happening.
> But if not, it would also be good to inform our users that there is no longer 
> security support for xen in bullseye.
> 
> Thanks,
> Maxi

Hello Maxi,

Thanks for the ping. We have been unable to find someone able to extend
the support of Xen 4.14 so far. Continue looking for help is still on my
duties, but it probably makes sense to just "officially" terminate the
support, informing our users. So please, let's go ahead adding it to
security-support-ended.deb11

Thank you,

-- 
Santiago Ruano Rincón ◈ Freexian SARL
https://www.freexian.com


signature.asc
Description: PGP signature

Bug#1056690: RFS: dhcpcd/1:10.0.5-4 -- DHCPv4 and DHCPv6 dual-stack client

[Santiago Ruano Rincón]

El 26/11/23 a las 10:53, Tobias Frost escribió:
> Control: tags -1 moreinfo
> 
> As Daniel said, this should be done on a VM, or if the hardware is
> important, on a porter box.
> 
> See https://dsa.debian.org/doc/guest-account/
> and then go to https://nm.debian.org/wizard to request an account.

Just to give a +1 to this. Having access to exodar.debian.net should be
quite easy.

And thanks a lot for your work.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1056106: nss: Please enable Salsa CI

[Santiago Ruano Rincón]

Source: nss
Version: 2:3.94-1
Severity: wishlist
Tags: patch

Dear nss maintainers,

Could you please enable the Salsa CI's Pipeline for nss? This would
allow to automate testing how nss builds and run some tests, as
autopkgtest, lintian, reprotest, among others.

Please consider the following merge request:
https://salsa.debian.org/mozilla-team/nss/-/merge_requests/7

Cheers,

Santiago


signature.asc
Description: PGP signature

Bug#1055370: debci setup should include security repositories

[Santiago Ruano Rincón]

Package: debci
Version: 3.7
Severity: normal

Dear debci maintainers,

Is there any reason why `debci setup ...` doen't configure the security
repostories inside the lxc containers? This is the sources.list of a
just created autopkgtest-bookworm-amd64 container:

deb http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian bookworm main contrib non-free 
non-free-firmware
deb http://deb.debian.org/debian-debug bookworm-debug main contrib non-free 
non-free-firmware
deb-src http://deb.debian.org/debian-debug bookworm-debug main contrib 
non-free non-free-firmware

Cheers,

 -- Santiago

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

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

Versions of packages debci depends on:
ii  adduser 3.137
ii  amqp-tools  0.11.0-1+b1
ii  curl8.4.0-2
ii  dctrl-tools 2.24-3+b1
ii  debian-archive-keyring  2023.4
ii  debootstrap 1.0.133
ii  distro-info 1.7
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  inotify-tools   4.23.9.0-1
ii  jq  1.7-1
ii  libjs-bootstrap 3.4.1+dfsg-3
ii  libjs-jquery3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-flot   4.2.1+dfsg-6
ii  moreutils   0.67-1
ii  patchutils  0.4.2-1
ii  retry   1.0.5-3
ii  rsync   3.2.7-1
ii  ruby1:3.1
ii  ruby-activerecord   2:6.1.7.3+dfsg-2
ii  ruby-bunny  2.19.0-2
ii  ruby-erubi  1.12.0-1
ii  ruby-kaminari-activerecord  1.2.2-1
ii  ruby-omniauth-gitlab4.1.0-1
ii  ruby-pg 1.5.3-1
ii  ruby-sinatra3.0.5-3
ii  ruby-sinatra-contrib3.0.5-3
ii  ruby-sqlite31.4.2-4+b3
ii  ruby-thor   1.2.2-1
ii  sudo1.9.14p2-1

Versions of packages debci recommends:
ii  systemd-timesyncd [time-daemon]  254.5-1

Versions of packages debci suggests:
ii  apt-cacher-ng   3.7.4-1+b2
pn  auto-apt-proxy  

-- Configuration Files:
/etc/sudoers.d/debci [Errno 13] Permission denied: '/etc/sudoers.d/debci'

-- no debconf information

Bug#1052875: borgbackup2: FTBFS: E FileNotFoundError: [Errno 2] No such file or directory: '/<>/.pybuild/cpython3_3.11/build/borg/testsuite/archiver/repo12.tar.gz'

[Santiago Ruano Rincón]

Control: tag -1 + patch

On Mon, 16 Oct 2023 11:25:12 +0200 Simon Chopin  wrote:
> Source: borgbackup2
> Version: 2.0.0b5-1
> Followup-For: Bug #1052875
> X-Debbugs-Cc: scho...@ubuntu.com
> 
> I fixed this in 
> https://salsa.debian.org/schopin/borgbackup2/-/commit/8f02b24dc022ad26c7d78b5efe80b9e933a3ebc8
> but wasn't able to open a PR against the original Salsa repo, so here's
> the commit attached as a patch if you prefer it that way.

Thanks!


signature.asc
Description: PGP signature

Bug#1015809: 1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Santiago Ruano Rincón]

Hi,

El 15/09/23 a las 22:40, Steven Haigh escribió:
> I'd suggest that even if nothing else, the package is updated with the same
> patches that Fedora have done - just to make the functionality the same - ie
> it actually works.
> 
> I know IPv6-PD isn't really wide-spread, but its enough that there should be
> at least one functional method to do it within Debian.

Regarding IPv6-PD in stable, I am preparing an upload, but I am unable
to actually test it. Are you able to give it a try?

You can use the repo described here:
https://debian.pages.debian.net/-/isc-dhcp/-/jobs/4842324/artifacts/aptly/index.html

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1054189: bullseye-pu: package debian-security-support/1:11+2023.10.17

[Santiago Ruano Rincón]

  done)
 IFS="$(printf '\nx')"
 IFS="${IFS%x}"
-LINE="$([% AWK %] '($1=="'"$SRC_NAME"'"){print}' "$LIST" | head -1)"
 case "$TYPE" in
 earlyend)
 TMP_WHEN="$(echo "$LINE" | [% AWK %] '{print $3}')"
@@ -256,34 +260,28 @@
 esac
 # for earlyend and ended, check packages actually affected (if 
TMP_WHEN not null)
 if [ -n "$TMP_WHEN" ] || [ "$TYPE" = limited ] ; then
-if \
-[ -z "$ALERT_VERSION" ] ||
-[ "$BIN_VERSION" = "$ALERT_VERSION" ] ||
-dpkg --compare-versions "$BIN_VERSION" '<=' "$ALERT_VERSION"
-then
-# need to alert, but check status db first
-TOKEN="$BIN_NAME/$BIN_VERSION"
-if [ "$STATUSDB_FILE" ] && [ -f "$STATUSDB_FILE" ]; then
-if grep -qFx "$TOKEN" "$STATUSDB_FILE" ; then
-continue
-fi
+# need to alert, but check status db first
+TOKEN="$BIN_NAME/$BIN_VERSION"
+if [ "$STATUSDB_FILE" ] && [ -f "$STATUSDB_FILE" ]; then
+if grep -qFx "$TOKEN" "$STATUSDB_FILE" ; then
+continue
+fi
+fi
+echo "$BIN_NAME $BIN_VERSION" >>"$TD/$SRC_NAME.bin"
+echo "$ALERT_VERSION" >"$TD/$SRC_NAME.version"
+echo "$ALERT_WHEN" >"$TD/$SRC_NAME.when"
+echo "$ALERT_WHY" >"$TD/$SRC_NAME.why"
+if [ "$STATUSDB_FILE" ] ; then
+# add to status db, remove any older entries
+if [ -f "$STATUSDB_FILE" ]; then
+TEMPFILE="$(mktemp --tmpdir="$(dirname "$STATUSDB_FILE")")"
+[% AWK %] -F/ '($1!="'"$BIN_NAME"'"){print}' \
+<"$STATUSDB_FILE" >"$TEMPFILE"
+mv "$TEMPFILE" "$STATUSDB_FILE"
 fi
-echo "$BIN_NAME $BIN_VERSION" >>"$TD/$SRC_NAME.bin"
-echo "$ALERT_VERSION" >"$TD/$SRC_NAME.version"
-echo "$ALERT_WHEN" >"$TD/$SRC_NAME.when"
-echo "$ALERT_WHY" >"$TD/$SRC_NAME.why"
-if [ "$STATUSDB_FILE" ] ; then
-# add to status db, remove any older entries
-if [ -f "$STATUSDB_FILE" ]; then
-TEMPFILE="$(mktemp --tmpdir="$(dirname 
"$STATUSDB_FILE")")"
-[% AWK %] -F/ '($1!="'"$BIN_NAME"'"){print}' \
-<"$STATUSDB_FILE" >"$TEMPFILE"
-mv "$TEMPFILE" "$STATUSDB_FILE"
-fi
-echo "$TOKEN" >>"$STATUSDB_FILE"
-fi  # maintain status db
-fi # package BIN_NAME's version is not supported
-fi
+echo "$TOKEN" >>"$STATUSDB_FILE"
+fi  # maintain status db
+    fi # package BIN_NAME's version is not supported
 done # read binary name and version for matching source name
 done # each source package from intersection
 
diff -Nru debian-security-support-11+2023.05.04/debian/changelog 
debian-security-support-11+2023.10.17/debian/changelog
--- debian-security-support-11+2023.05.04/debian/changelog  2023-05-04 
14:27:19.0 -0300
+++ debian-security-support-11+2023.10.17/debian/changelog  2023-10-17 
13:08:20.0 -0300
@@ -1,3 +1,15 @@
+debian-security-support (1:11+2023.10.17) bullseye; urgency=medium
+
+  * Team upload.
+  * Mark samba support limited to non-AD DC uses cases (Closes: #1053109)
+  * Drop version-based check (Closes: #986581) and update test suite
+accordingly. Backport changes made by Sylvain Beucler.
+  * Match ecosystems with limited support, test case updated. (Closes: #986333)
+Backport changes by Sylvain Beucler.
+* Use golang.* (as regex) instead of golang* in security-support-limited
+
+ -- Santiago Ruano Rincón   Tue, 17 Oct 2023 13:08:20 
-0300
+
 debian-security-support (1:11+2023.05.04) bullseye-updates; urgency=medium
 
   [ Holger Levsen ]
diff -Nru debian-security-support-11+2023.05.04/security-support-limited 
debian-security-support-11+2023.10.17/security-support-limited
--- debian-security-support-11+2023.05.04/security-su

Bug#986333: debian-security-support: Match ecosystems with limited support

[Santiago Ruano Rincón]

El 17/10/23 a las 16:49, Holger Levsen escribió:
> On Tue, Oct 17, 2023 at 09:28:04AM -0300, Santiago Ruano Rincón wrote:
> > El 17/10/23 a las 09:18, Holger Levsen escribió:
> > > On Mon, Oct 16, 2023 at 11:49:27PM -0300, Santiago Ruano Rincón wrote:
> > > > As discussed in #debian-lts, unarchiving & reopening since this bug is
> > > > present in bullseye and bookworm: "golang*" installed packages are not
> > > > reported.
> > > I really would have prefered a new bug, instead of unarchiving this one.
> > Why? It is the same bug. (Real question, I am happy to improve my
> > workflows)
> 
> because the bug is closed in unstable. if it's still fixed in older suite,
> we (in Debian, in general) don't keep the bugs open.

s/still/still to be/?

> 
> else you would need to re-open all other bugs too, which are not fixed in 
> older suites.

OK. My intention is/was to re-open bugs that I needed to fix. Along with
#986333, I need to close #986581 in bullseye and buster too (*). For
this update, may I stick with the unarchiving & reopening procedure, to
keep it consistent?

Or do you still want me to open a new bug for it?

> > > And pretty please, please fix this in bookworm first, and get it accepted 
> > > by
> > > SRMs, before pushing this into bullseye.
> > As discussed on #debian-lts, this is already fixed in bookworm.
> 
> I was merely refering to what you wrote above: "As discussed in #debian-lts,
> unarchiving & reopening since this bug is present in bullseye and bookworm" 
> :-D

Indeed, brain fail typo! 

I correct:
"As discussed in #debian-lts, unarchiving & reopening since this bug is
present in bullseye and buster"

Cheers!

 -- Santiago

* as documented in the #986333-related git commit
(bf9dc3b6b76f6aa5bee6591a20428744a214cb69). Thanks Sylvain for properly
documenting this!



signature.asc
Description: PGP signature

Bug#986333: debian-security-support: Match ecosystems with limited support

[Santiago Ruano Rincón]

El 17/10/23 a las 09:18, Holger Levsen escribió:
> On Mon, Oct 16, 2023 at 11:49:27PM -0300, Santiago Ruano Rincón wrote:
> > As discussed in #debian-lts, unarchiving & reopening since this bug is
> > present in bullseye and bookworm: "golang*" installed packages are not
> > reported.
> 
> I really would have prefered a new bug, instead of unarchiving this one.

Why? It is the same bug. (Real question, I am happy to improve my
workflows)

> (Also because retitling it now, to make it clear that this bug is now about
> bookworm and bullseye, obfuscates the original issue of the bug.)
> 

I would expect that information be visible in the bug tracker without
retitling.

> And pretty please, please fix this in bookworm first, and get it accepted by
> SRMs, before pushing this into bullseye.

As discussed on #debian-lts, this is already fixed in bookworm.

Thanks!

 -- S


signature.asc
Description: PGP signature

Bug#986333: debian-security-support: Match ecosystems with limited support

[Santiago Ruano Rincón]

Control: reopen -1
Control: fixed -1 debian-security-support/1:12+2021.09.30
Control: found -1 debian-security-support/1:11+2023.05.04
Control: found -1 debian-security-support/1:10+2022.08.23

On Sat, 3 Apr 2021 15:32:02 +0200 Sylvain Beucler  wrote:
> Package: debian-security-support
> Severity: normal
> 
> Hi,
> 
> Sometimes, entire ecosystems are affected by Debian support decisions.
> 
> These source package sets comes to mind:
> - node-*
>   
> https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#libv8
> - golang-*
>   
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#golang-static-linking
> 
> Currently 'check-support-status' fails to detect individual packages
> affected by these decisions, it only notifies about explicitly
> referenced packages such as 'nodejs'.
> Maybe regex matching would help.
> 
> (debian-security-support is an important tool in the Debian LTS/ELTS
> offering, so I believe we could offer help/time in this area.)
> 
> What do you think?
> 
> Cheers!
> Sylvain
> 
> 

As discussed in #debian-lts, unarchiving & reopening since this bug is
present in bullseye and bookworm: "golang*" installed packages are not
reported.

I am working on fixing this and will propose {old,}oldstable pu.

Cheers,

 -- S



signature.asc
Description: PGP signature

Bug#1036277: Ship keama - The KEA Migration Assistant

[Santiago Ruano Rincón]

El 13/09/23 a las 01:25, Athos Ribeiro escribió:
> On Mon, Sep 11, 2023 at 03:35:37PM +0530, Santiago Ruano Rincón wrote:
> > 
> > Do you think it would be possible to add an autopkgtest for keama?
> > 
> 
> Hi Santiago!
> 
> Thanks for having a look at this :)
> 
> I added an autopkgtest to run some upstream provided checks and also
> changed d/rules to run the same checks during the package build.
> 
> I needed to perform some changes to ensure the tests will make the build
> process halt on failures and removed one specific test which was
> performing a DNS query.
> 
> Let me know your thoughts on this.
> 
> Thanks again!

Oi Athos,

isc-dhcp is FTBFS on s390x, and I think it is keama-related.

The relevant part of a (giveback) build log:

[snip]
cat /tmp/keama-test-errors
configdata4.in4 doesn't provide expected output
test -f /tmp/keama-test-errors
test ! -s /tmp/keama-test-errors
make[1]: *** [debian/rules:83: override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:42: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2
[snip]

Full log:
https://buildd.debian.org/status/fetch.php?pkg=isc-dhcp=s390x=4.4.3-P1-3=1694824585=0

Do you have any idea why?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1053893: Please update VCS links

[Santiago Ruano Rincón]

Source: robber
Severity: normal

Dear robber maintainer(*),

I think your plain is to maintain robber inside the python-team/packages
namespace. Could you please move the repository there?

After that, the VCS* fields should be updated. If I am not wrong, the
correct location would be:

diff --git a/debian/control b/debian/control
index 48a54cd..809620f 100644
--- a/debian/control
+++ b/debian/control
@@ -15,8 +15,8 @@ Build-Depends:
 Testsuite: autopkgtest-pkg-python
 Standards-Version: 4.6.2
 Homepage: https://github.com/EastAgile/robber.py
-Vcs-Browser: https://salsa.debian.org/debian/python-team/robber
-Vcs-Git: https://salsa.debian.org/debian/python-team/robber.git
+Vcs-Browser: https://salsa.debian.org/python-team/packages/robber
+Vcs-Git: https://salsa.debian.org/python-team/packages/robber.git
 
 Package: python3-robber
 Architecture: all

* Congratulations for your first package in Debian!

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

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


signature.asc
Description: PGP signature

Bug#1053462: debian-security-support: merge .ended and .limited files together

[Santiago Ruano Rincón]

Source: debian-security-support
Severity: normal

El 27/09/23 a las 09:25, Raphael Hertzog escribió:
> Hi,
> 
> On Tue, 26 Sep 2023, Santiago Ruano Rincón wrote:
> > > > Agreed, a split makes sense, it causes marginal additional overhead and 
> > > > makes
> > > > the whole setup more explicit.
> > > 
> > > cloning this bug once more so we don't forget about this.
> > 
> > (I think the moreinfo tag comes from the original bug)
> > 
> > I hope this MR correctly splits the limited support file:
> > https://salsa.debian.org/debian/debian-security-support/-/merge_requests/17
> 
> As I commented on the MR, I think it would be a good move to merge "ended"
> and "limited" files together. This will require more code changes but
> gives a clearer overview of the restrictions affecting a given release.
> 
> We could have a single file per release with 3 fields:
> 
> * package (or package regexp)
> * supported (true/false), trues implies limited support, false means not 
> supported
> * comment (should explain the limitation if supported == true)
> 
> We could keep an unversioned file (for unstable?) that would serve as
> template when we have to create a new release.

Since #975301 has been closed now, I think this should be discussed in a
new bug report.

I like the above suggestion. Just wondering why don't keep the "latest
version with support" and "Date when support ended or will end" fields
currently found in "ended" files.


signature.asc
Description: PGP signature

Bug#1053246: Security support ended for Xen 4.14 in Bullseye

[Santiago Ruano Rincón]

El 30/09/23 a las 00:09, Hans van Kranenburg escribió:
> Package: debian-security-support
> Version: 1:11+2023.05.04
> Severity: normal
> 
> Hi,
> 
> Upstream security support for Xen 4.14 has ended recently. This also
> means that security support for Debian Bullseye has ended.
> 
> The complexity of the software involved does not really allow for anyone
> else than the upstream developers, with a deep understanding of the
> inner workings of the hypervisor code, to apply/backport new patches.
> 
> For security-support-ended.deb11, this could be a line like:
> 
> xen 4.14.6-1 2023-09-21
> https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support
> 
> Note: This 4.14.6-1 package version is not visible for bullseye yet,
> right now, in the archive. It was submitted for the bullseye point
> release, and has just been accepted into it:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053177
> 
> Thanks,
> Hans
> 

Hello,

Could you please wait a little bit before moving forward. In the Debian
bullseye LTS context, we would like to know if there are interest from
LTS users, and look for help to maintain it. At least, partially.

Thank you,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1053109: Mark limited support for Samba in buster and bullseye

[Santiago Ruano Rincón]

Package: debian-security-support
Version: 1:13+2023.09.27
Severity: normal
X-Debbugs-Cc: debian-...@lists.debian.org

Samba as AD Domain Controller is not supported in bullseye since [DSA 5477-1]
and in buster since [DSA 5015-1]. debian-security-support should include
this information in security-support-limited.{deb10,deb11}.

I will prepare a patch.

[DSA 5477-1] 
https://lists.debian.org/debian-security-announce/2023/msg00169.html
[DSA 5015-1] https://www.debian.org/security/2021/dsa-5015


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

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

Versions of packages debian-security-support depends on:
ii  adduser3.137
ii  debconf [debconf-2.0]  1.5.82
ii  gettext-base   0.21-13+b1

debian-security-support recommends no packages.

debian-security-support suggests no packages.

-- debconf information excluded


signature.asc
Description: PGP signature

Bug#975301: split security-support-limited into release specific files

[Santiago Ruano Rincón]

Control: tags -1 + patch

On Fri, 20 Nov 2020 08:40:22 + Holger Levsen  wrote:
> clone 975016 -1
> retitle -1 split security-support-limited into 
> security-support-limited.deb(9|10|11)
> thanks
> 
> On Thu, Nov 19, 2020 at 07:48:45PM +0100, Moritz Mühlenhoff wrote:
> > On Wed, Nov 18, 2020 at 12:46:52PM +, Holger Levsen wrote:
> > > looks good to me!
> > Thanks for the upload.
> 
> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is still
> open...
>  
> > > I've already switched to maintain the package in branches so this should 
> > > be
> > > fairly easy. That said, splitting security-support-limited into
> > > security-support-limited.deb(9|10|11) still sounds reasonable to me as 
> > > well.
> > Agreed, a split makes sense, it causes marginal additional overhead and 
> > makes
> > the whole setup more explicit.
> 
> cloning this bug once more so we don't forget about this.

(I think the moreinfo tag comes from the original bug)

I hope this MR correctly splits the limited support file:
https://salsa.debian.org/debian/debian-security-support/-/merge_requests/17

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1051563: Backporting mutt patches to Debian Buster

[Santiago Ruano Rincón]

Hi Chris,

El 17/09/23 a las 21:56, Chris Frey escribió:
> On Sun, Sep 17, 2023 at 08:34:57PM +0300, Santiago Ruano Rincón wrote:
> > Chris, thanks for preparing the patches. Much appreciated. I have a
> > question though: Why are you placing those two patches in
> > debian-specific, and not in upstream/? They come from the upstream repo.
> 
> I only put them there because I had to modify them for a clean patch.

I consider placing them in debian-specific is a little
counter-intuitive. However, buster already contained a
debian/patches/security, and I have placed there.

> I changed the headers to make it clear that I edited them, but kept
> the original wording as well.

That is not how I interpret DEP-3. I restored the headers structure and
uploaded the package. Will send the DLA soon!

> 
> I didn't think it was right to modify the patch contents without
> changing the name of who did it.

I kept the original From, tagged the Origin as backport, and kept your
name as Author.
Hope that makes sense for you.

Thanks a lot for your work!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1051563: Backporting mutt patches to Debian Buster

[Santiago Ruano Rincón]

hi!

El 16/09/23 a las 15:44, Utkarsh Gupta escribió:
> Hi Chris,
> 
> On Fri, Sep 15, 2023 at 8:09 PM Chris Frey  wrote:
> > Attached is a patch that applies to the unpackaged sources of Debian 
> > Buster's
> > version of mutt 1.10.
> >
> > It includes 3 patches:
> >
> > upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch
> > debian-specific/Check-for-NULL-userhdrs.patch
> > debian-specific/Fix-write_one_header-illegal-header-check.patch
> >
> > First one applied from Bullseye.  The other two I modified slightly
> > to match the older sources.
> 
> Many thanks, as usual. I'll look into it and let you know if we hit a
> bump backporting it.

Utkarsh, I have claimed mutt in both {d,e}la-needed, and started to work
preparing the repo. I am also OK if you want to finish the work.

Chris, thanks for preparing the patches. Much appreciated. I have a
question though: Why are you placing those two patches in
debian-specific, and not in upstream/? They come from the upstream repo.

Cheers!

 -- Santiago


signature.asc
Description: PGP signature

Bug#982894: isc-dhcp-client: Empty /etc/resolv.conf if root partition is full

[Santiago Ruano Rincón]

Control: tags -1 + pending

On Mon, 15 Feb 2021 23:49:40 +0100 =?utf-8?q?Johannes_Wei=C3=9Fl?= 
 wrote:
> Package: isc-dhcp-client
> Version: 4.4.1-2
> Severity: important
> Tags: patch
> 
> The Debian version of /sbin/dhclient-script creates a temporary file next to
> /etc/resolv.conf, and fills it with information. Then it replaces
> /etc/resolv.conf with the temporary file. So far so good.
> 
> The problem appears when the root partition is full. The temporary file is
> creates, but filling it with informations is not possible anymore (echo "..." 
> >
> temporary_resolv_conf fails). BUT: Instead of aborting, dhclient-script still
> replaced the perfectly good /etc/resolv.conf with an empty one.
> 
> This problem appears a lot on AWS EC2 instances (are configured using DHCP,
> despite being servers).

[snip]

Sorry for the radio noise here. I've just applied the patch, and it will
be part of the next release.

cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1015809: 1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Santiago Ruano Rincón]

On Sun, 23 Jul 2023 12:45:34 +1000 Steven Haigh  wrote:
> Ok, so after a day of messing around with Debian 12, it looks like 
> without these patches applied, there is no way to get a IPv6 PD working 
> with a PPPoE connection. Given the majority of ISPs in Australia use 
> PPPoE as their connection method, this is a much bigger issue in this 
> country than where the maintainers of this package live.
> 
> wide-dhcpv6-client doesn't seem to interpret the reply from the ISP as 
> a valid one.
> 
> dibbler-client binds to the wrong LL address and fails to open a socket.
> 
> Copying the dhclient binary from a Fedora 38 install and using that 
> works perfectly - which is using the Fedora patches for dhclient v4.4.3.
> 
> The current, functioning patch from Fedora is here:
> 
> 
> How are we able to fix this properly instead of a 'copy the binary from 
> Fedora' type fix?

Sorry, I really missed this bug report. That said, since the EOL of
isc-dhcp-server, I reduced the priority given to isc-dhcp.

If isc-dhcp is that broken for .au, I could consider a stable update,
after this has been solved in unstable and confirmed doesn't break
anything.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1036277: Ship keama - The KEA Migration Assistant

[Santiago Ruano Rincón]

Control: tags -1 + pending

El 13/09/23 a las 01:25, Athos Ribeiro escribió:
> On Mon, Sep 11, 2023 at 03:35:37PM +0530, Santiago Ruano Rincón wrote:
> > 
> > Do you think it would be possible to add an autopkgtest for keama?
> > 
> 
> Hi Santiago!
> 
> Thanks for having a look at this :)
> 
> I added an autopkgtest to run some upstream provided checks and also
> changed d/rules to run the same checks during the package build.
> 
> I needed to perform some changes to ensure the tests will make the build
> process halt on failures and removed one specific test which was
> performing a DNS query.
> 
> Let me know your thoughts on this.
> 
> Thanks again!

LGTM, thank you!

Just merged.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1036277: Ship keama - The KEA Migration Assistant

[Santiago Ruano Rincón]

On Thu, 18 May 2023 21:56:14 -0300 Athos Ribeiro  
wrote:
> I filed a salsa MR at
> https://salsa.debian.org/debian/isc-dhcp/-/merge_requests/10 with a
> patch to include keama as a new binary package here.

Obrigado!

Do you think it would be possible to add an autopkgtest for keama?

 -- Santiago


signature.asc
Description: PGP signature

Bug#1051438: transition: omniorb-dfsg

[Santiago Ruano Rincón]

El 08/09/23 a las 13:02, Sebastian Ramacher escribió:
> Control: tags -1 confirmed
> 
> On 2023-09-08 16:23:14 +0530, Santiago Ruano Rincón wrote:
> > > > binNMU will be required for them.
> > > 
> > > So they are bulding fine with the new version of omniorb-dfsg, right?
> > 
> > Yes.
> 
> Then please go ahead.

Done. Thank you!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1051438: transition: omniorb-dfsg

[Santiago Ruano Rincón]

Control: tags -1 - moreinfo

(I hope removing the tag is OK)

El 08/09/23 a las 10:34, Sebastian Ramacher escribió:
> Control: tags -1 moreinfo
> 
> On 2023-09-08 05:55:02 +0530, Santiago Ruano Rincón wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-Cc: omniorb-d...@packages.debian.org, 1042...@bugs.debian.org
> > Control: affects -1 + src:omniorb-dfsg
> > 
> > Dear release team,
> > 
> > Could you please schedule a transition for omniorb-dfsg 4.3.0. There has
> > been an ABI bump since 4.2.0. There are four reverse dependencies
> > listed: omnievents, tango, pytango and logservice. logservice has been
> > remove from unstable and testing. It is only available in buster.
> > 
> > I have checked how omnievent, tango and pytango:
> > 
> > * tango (don't pay attention the "omniorb-dfsg" in the URL. those
> > pipelines are run as child pipelines inside omniorb-dfsg:
> > amd64: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671324
> > i386: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671325
> > autopkgtest: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671332
> > 
> > * pytango:
> > amd64: https://salsa.debian.org/santiago/pytango/-/jobs/4671408
> > i386: https://salsa.debian.org/santiago/pytango/-/jobs/4671409
> > (setup autopkgtest in Salsa CI for it is not straightforward yet (WiP!))
> > 
> > * omnievents (orphaned package):
> > amd64: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4649320
> > i386: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4649322
> > it doesn't include autopkgtest
> > 
> > binNMU will be required for them.
> 
> So they are bulding fine with the new version of omniorb-dfsg, right?

Yes. From the tango's link jobs as example:
The build amd64 installs the new version of omniorb-dfsg:
https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671324#L371
as well as the autopkgtest job:
https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671332#L338

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1051438: transition: omniorb-dfsg

[Santiago Ruano Rincón]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: omniorb-d...@packages.debian.org, 1042...@bugs.debian.org
Control: affects -1 + src:omniorb-dfsg

Dear release team,

Could you please schedule a transition for omniorb-dfsg 4.3.0. There has
been an ABI bump since 4.2.0. There are four reverse dependencies
listed: omnievents, tango, pytango and logservice. logservice has been
remove from unstable and testing. It is only available in buster.

I have checked how omnievent, tango and pytango:

* tango (don't pay attention the "omniorb-dfsg" in the URL. those
pipelines are run as child pipelines inside omniorb-dfsg:
amd64: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671324
i386: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671325
autopkgtest: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4671332

* pytango:
amd64: https://salsa.debian.org/santiago/pytango/-/jobs/4671408
i386: https://salsa.debian.org/santiago/pytango/-/jobs/4671409
(setup autopkgtest in Salsa CI for it is not straightforward yet (WiP!))

* omnievents (orphaned package):
amd64: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4649320
i386: https://salsa.debian.org/santiago/omniorb-dfsg/-/jobs/4649322
it doesn't include autopkgtest

binNMU will be required for them.

Ben file:

title = "omniorb-dfsg";
is_affected = .depends ~ ""/libcos4-2|libomniorb4-2/"" | .depends ~ 
""/libcos4-3|libomniorb4-3/"";
is_good = .depends ~ ""/libcos4-3|libomniorb4-3/"";
is_bad = .depends ~ ""/libcos4-2|libomniorb4-2/"";

Thanks,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1042758: Please update to 4.3.0

[Santiago Ruano Rincón]

Control: tags -1 + fixed-in-experimental

On Mon, 31 Jul 2023 14:33:56 +0200 Thomas Braun  
wrote:
> Source: omniorb-dfsg
> X-Debbugs-Cc: thomas.br...@byte-physics.de
> Version: 
> Severity: normal
> 
> Dear Maintainer,
> 
> please update to 4.3.0. See also https://omniorb.sourceforge.io.

omniorb-dfsg 4.3.0 is now available in experimental


signature.asc
Description: PGP signature

Bug#1050344: lintian FTBFS in experimental, with perl 5.38

[Santiago Ruano Rincón]

Source: lintian
Version: 2.116.3
Severity: normal
Tags: ftbfs experimental
X-Debbugs-Cc: debian-salsa...@alioth-lists.debian.net

Dear Lintian developers,

Lintian currently FTBFS on experimental, due to unmet dependencies. From
the build log:

...
Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 dh-elpa : Depends: libdebian-source-perl but it is not installable or
dh-make-perl (>= 0.90) but it is not installable
 libberkeleydb-perl : Depends: perlapi-5.36.0
 libclass-xsaccessor-perl : Depends: perlapi-5.36.0
Depends: perl (< 5.36.1~) but 5.38.0-2 is to be 
installed
 libclone-perl : Depends: perlapi-5.36.0
 libcpanel-json-xs-perl : Depends: perlapi-5.36.0
 libdevel-cover-perl : Depends: perlapi-5.36.0
   Depends: perl (< 5.36.1~) but 5.38.0-2 is to be 
installed
 libdevel-size-perl : Depends: perlapi-5.36.0
 libemail-address-xs-perl : Depends: perlapi-5.36.0
 libhtml-parser-perl : Depends: perlapi-5.36.0
 libio-pty-perl : Depends: perlapi-5.36.0
 libmoose-perl : Depends: perlapi-5.36.0
 Depends: libclass-load-xs-perl but it is not going to be 
installed
 Depends: libpackage-stash-xs-perl but it is not going to 
be installed
 libnet-ssleay-perl : Depends: perlapi-5.36.0
 libnetaddr-ip-perl : Depends: perlapi-5.36.0
 libparams-classify-perl : Depends: libdevel-callchecker-perl but it is not 
going to be installed
   Depends: perlapi-5.36.0
 libparams-util-perl : Depends: perlapi-5.36.0
 libperl-critic-pulp-perl : Depends: liblist-moreutils-perl but it is not 
installable
Depends: libperl-critic-perl but it is not 
installable
Depends: libppi-perl but it is not installable
 libperl-minimumversion-perl : Depends: libppi-perl but it is not 
installable
 libperlio-gzip-perl : Depends: perlapi-5.36.0
 libperlio-utf8-strict-perl : Depends: perlapi-5.36.0
 libppix-regexp-perl : Depends: libppi-perl (>= 1.238) but it is not 
installable
 libppix-utils-perl : Depends: libppi-perl (>= 1.250) but it is not 
installable
 libproc-processtable-perl : Depends: perlapi-5.36.0
 libsereal-decoder-perl : Depends: perlapi-5.36.0
 libsereal-encoder-perl : Depends: perlapi-5.36.0
 libsub-identify-perl : Depends: perlapi-5.36.0
 libsub-name-perl : Depends: perlapi-5.36.0
 libsyntax-keyword-try-perl : Depends: perlapi-5.36.0
  Depends: libxs-parse-keyword-perl but it is 
not going to be installed
 libterm-readkey-perl : Depends: perlapi-5.36.0
 libtest-perl-critic-perl : Depends: libperl-critic-perl but it is not 
installable
 libtext-csv-xs-perl : Depends: perlapi-5.36.0
 libtext-iconv-perl : Depends: perlapi-5.36.0
 libtext-levenshteinxs-perl : Depends: perlapi-5.36.0
 libtext-markdown-discount-perl : Depends: perlapi-5.36.0
 libtext-xslate-perl : Depends: perlapi-5.36.0
   Depends: libdata-messagepack-perl but it is not 
going to be installed
   Depends: libmouse-perl but it is not going to be 
installed
 libtime-moment-perl : Depends: perlapi-5.36.0
 libunicode-utf8-perl : Depends: perlapi-5.36.0
 libvariable-magic-perl : Depends: perlapi-5.36.0
 libwww-curl-perl : Depends: perlapi-5.36.0
 libxml-libxml-perl : Depends: perlapi-5.36.0
 libyaml-libyaml-perl : Depends: perlapi-5.36.0
 lintian : Depends: libapt-pkg-perl but it is not installable
 sbuild-build-depends-main-dummy : Depends: libperl-critic-freenode-perl
E: Unable to correct problems, you have held broken packages.
apt-get failed.
E: Package installation failed
Not removing build depends: cloned chroot in use
...


For the record, the salsa-ci's lintian:experimental image, that doesn't
builds, only install lintian, has been unable to be updated for some
time, due to similar unmet dependencies problems. E.g.:

https://salsa.debian.org/salsa-ci-team/pipeline/-/jobs/4594234#L337

I am considering temporarily disabling the lintian:experimental build
image job.

Cheers,

 -- Santiago

-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 
'unstable'), 

Bug#1050294: grep: Fails to build twice

[Santiago Ruano Rincón]

El 22/08/23 a las 19:36, Bas Couwenberg escribió:
> Source: grep
> Version: 3.11-2
> Severity: important
> Tags: upstream patch
> 
> Dear Maintainer,
> 
> Builing your package twice reveals an issue with the clean target:
> 
>  dpkg-source: info: local changes detected, the modified files are:
>   source_dir/doc/grep.info
>  dpkg-source: error: aborting due to unexpected upstream changes, see 
> /tmp/grep_3.11-2+salsaci+20230822+19.diff.kbSnU8
> 
> The attached patch resolves the issue.

Thank you! You were faster than me :-)

I've pushed this MR: https://salsa.debian.org/debian/grep/-/merge_requests/11

and the test you create just passed. I'll merge and upload the package
after sending this mail.

Thanks again,

 -- S


signature.asc
Description: PGP signature

Bug#1043467: spinlock_gcc_arm.hpp possibly doesn't take into accout LDREX on arm64

[Santiago Ruano Rincón]

Source: boost1.81
Version: 1.81.0-6
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian-...@lists.debian.org

Hi there,

Please, correct me if I am wrong, but the conditional here:
https://sources.debian.org/src/boost1.81/1.81.0-6/libs/smart_ptr/include/boost/smart_ptr/detail/spinlock_gcc_arm.hpp/#L21
doesn't take into account that ARM64 also includes the LDREX instruction.

Without BOOST_SP_ARM_HAS_LDREX, the obsolete SWP ends up being used:
https://sources.debian.org/src/boost1.81/1.81.0-6/libs/smart_ptr/include/boost/smart_ptr/detail/spinlock_gcc_arm.hpp/#L69
needing to be software-emulated by the kernel.

Cheers,

 -- Santiago

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

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


signature.asc
Description: PGP signature

Bug#1041588: grep -r fails with "Operation not supported"

[Santiago Ruano Rincón]

Control: tags -1 + pending

El 21/07/23 a las 19:46, Vincent Lefevre escribió:
> Control: tags -1 patch
> 
> On 2023-07-21 19:38:08 +0200, Vincent Lefevre wrote:
> > Indeed, it's a bundled gnulib. I was surprised because there is
> > no "gnulib" directory. Actually these are just files under the m4
> > directory. The bug is in "m4/dirfd.m4". I can see
> > 
> >   if test $ac_cv_func_dirfd = no && test $gl_cv_func_dirfd_macro = no; then
> > HAVE_DIRFD=0
> >   else
> > HAVE_DIRFD=1
> > dnl Replace only if the system declares dirfd already.
> > if test $ac_cv_have_decl_dirfd = yes; then
> >   REPLACE_DIRFD=1
> > fi
> > 
> > where the last 4 lines
> > 
> > dnl Replace only if the system declares dirfd already.
> > if test $ac_cv_have_decl_dirfd = yes; then
> >   REPLACE_DIRFD=1
> > fi
> > 
> > need to be removed to match the upstream gnulib fix.
> 
> And I could check that the corresponding attached patch makes
> the error disappear.

Thank you! Patch and autopkgetst inclucded. As long as I can confirm the
autopkgtest works, I upload the fixed version.

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1041588: Info received (grep 3.11 -r on 100000+ files fails with "Operation not supported")

[Santiago Ruano Rincón]

Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64773
Control: tags -1 + upstream


signature.asc
Description: PGP signature

Bug#1041588: grep -r fails with "Operation not supported"

[Santiago Ruano Rincón]

Hi!

El 21/07/23 a las 11:02, Boyuan Yang escribió:
> Hi,
> 
> On Fri, 21 Jul 2023 10:39:54 +0200 Vincent Lefevre  wrote:
> > Control: severity -1 grave
> > Control: tags -1 - moreinfo
> > Control: retitle -1 grep -r on 10+ files fails with "Operation not
> supported"
> > 
> > On 2023-07-20 23:43:45 -0300, Santiago Ruano Rincón wrote:
> > > El 21/07/23 a las 04:06, Vincent Lefevre escribió:
> > > > On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote:
> > > > > There is a major regression in grep 3.11-1: I now get an error
> > > > > 
> > > > > cventin:~/Mail> grep -r xxxyyyzzz oldarc
> > > > > grep: oldarc/cur: Operation not supported
> > > > 
> > > > And no such issue with grep from the upstream git.
> > > 
> > > How are you compiling it?
> > 
> > $ ./bootstrap
> > $ ./configure --prefix=$HOME/opt/grep
> > $ make
> > $ make install
> > 
> > > My intuition is this comes from gnulib.
> > 
> > Yes, as in my next message, I said that the error disappeared
> > with the commit that updated gnulib (and did nothing else).
> > 
> > > But a reproducer is needed to confirm.
> > > 
> > > Tagging with moreinfo, and downgrading the severity since I cannot
> > > reproduce it myself:
> > [...]
> > > Please, feel free to bump the severity back again if you are able to
> > > find out a way to reproduce it.
> > 
> > One needs at least 10 files in the directory (9 is not enough).
> > With 10 empty files:
> > 
> > $ mkdir test-dir && for i in `seq 10` ; do : > test-dir/$i ; done
> > $ grep -r x test-dir
> > grep: test-dir: Operation not supported
> 
> Debian gnulib package maintainer here. I briefly checked grep source code,
> and it seems that grep is using the bundled gnulib and not using the packaged
> gnulib. Not 100% sure.

It indeed currently uses a bundled gnulib.

> 
> Whether to use the bundled gnulib is up to the packager's decision. Anyway,
> let me know if I could help.

I suppose we could give the packaged gnulib a try. Patches welcome ;-)

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1041588: grep 3.11 -r on 100000+ files fails with "Operation not supported"

[Santiago Ruano Rincón]

Dear grep developers,

I am forwarding this gnulib bug that affects grep 3.11. Full bug report
can be found at https://bugs.debian.org/1041588

El 21/07/23 a las 10:39, Vincent Lefevre escribió:
> Control: severity -1 grave
> Control: tags -1 - moreinfo
> Control: retitle -1 grep -r on 10+ files fails with "Operation not 
> supported"
> 
> On 2023-07-20 23:43:45 -0300, Santiago Ruano Rincón wrote:
> > El 21/07/23 a las 04:06, Vincent Lefevre escribió:
> > > On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote:
> > > > There is a major regression in grep 3.11-1: I now get an error
> > > > 
> > > > cventin:~/Mail> grep -r xxxyyyzzz oldarc
> > > > grep: oldarc/cur: Operation not supported
> > > 
> > > And no such issue with grep from the upstream git.
> > 
> > How are you compiling it?
> 
> $ ./bootstrap
> $ ./configure --prefix=$HOME/opt/grep
> $ make
> $ make install
> 
> > My intuition is this comes from gnulib.
> 
> Yes, as in my next message, I said that the error disappeared
> with the commit that updated gnulib (and did nothing else).

Indeed. Our mails crossed.

> 
> > But a reproducer is needed to confirm.
> > 
> > Tagging with moreinfo, and downgrading the severity since I cannot
> > reproduce it myself:
> [...]
> > Please, feel free to bump the severity back again if you are able to
> > find out a way to reproduce it.
> 
> One needs at least 10 files in the directory (9 is not enough).
> With 10 empty files:
> 
> $ mkdir test-dir && for i in `seq 10` ; do : > test-dir/$i ; done
> $ grep -r x test-dir
> grep: test-dir: Operation not supported

Thank you, Vincent. I confirm with 9 files grep works as expected.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1041588: grep -r fails with "Operation not supported"

[Santiago Ruano Rincón]

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

El 21/07/23 a las 04:06, Vincent Lefevre escribió:
> On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote:
> > There is a major regression in grep 3.11-1: I now get an error
> > 
> > cventin:~/Mail> grep -r xxxyyyzzz oldarc
> > grep: oldarc/cur: Operation not supported
> 
> And no such issue with grep from the upstream git.

How are you compiling it? My intuition is this comes from gnulib. But a
reproducer is needed to confirm.

Tagging with moreinfo, and downgrading the severity since I cannot
reproduce it myself:

santiago@novelo ~/C/Riseup> grep -r xxxyyyzzz INBOX/
INBOX/new/1689905669.3476970_3.novelo,U=46874:2,:cventin:~/Mail> grep -r 
xxxyyyzzz oldarc
INBOX/cur/1689905669.3476970_5.novelo,U=46876:2,S:> cventin:~/Mail> grep -r 
xxxyyyzzz oldarc

Please, feel free to bump the severity back again if you are able to
find out a way to reproduce it.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

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

[Santiago Ruano Rincón]

El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> >  wrote:
> > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > Greetings,
> > > >
> > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> > > > good time to re-visit Debian's choice of standard DHCP client shipping
> > > > with priority:important.
> > > >
> > > > 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.
> > > ...
> > >
> > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for
> > > the moment, and I'll make the relevant changes in ifupdown as soon as I
> > > can. Josué, any thoughts?
> > 
> > 1) As someone pointed out in the thread, the reason why
> > isc-dhcp-client had priority:important probably was to ensure that
> > debootstrap would pull it, since debootstrap ignores Recommends and
> > packages with a priority lower than standard.
> > 
> > 2) However, as long as ifupdown explictly depends on a package, it can
> > also pull dependencies with a lower priority. Right now ifupdown
> > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would
> > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead.
> > 
> > 3) At that point, swapping the priority of isc-dhcp-client and
> > dhcpcd-base merely becomes "nice to have". Heck, the priority of both
> > could, in principle, be optional, just as long as ifupdown explicitly
> > Depends on a DHCP client, and the first alternative is a real package.
> 
> I was about to bump dhcpcd-base as ifupdown dependency, but... if
> isc-client-dhcp is a Recommends, is because not all users want a dhcp
> client installed, where all the ipv4 is handled statically, and ipv6 is
> done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the
> next upgrade.
> 
> So I'd prefer to go forward with the steps proposed by Simon, and
> s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends:
> Unless there is a strong objection, I'll file the override bug report.

(sorry for taking so long to come back to this)

For the moment, ifupdown is still installed by the debian-installer as
default network interfaces manager. And after sleeping over it, and
discussing with debian fellows, I would like to call for consensus to
rise Priority: Important to dhcpcd-base (as initially requested in
#1038882), and switch to Recommends: dhcpcd-base | dhcp-client.

This addresses two scenarios: keep some systems as small as possible
(ifupdown users can remove dhcpcd if they want) and having a useful dhcp
client available after installing/bootstrapping.

So I would like to retitle #1038882 back as originally reported. (Sorry
for going back and forth) Objections?

The situation regarding the default network interfaces manager could
change, even in the short term. But that could be discussed in another
thread.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1035972: isc-dhcp EOL'ed

[Santiago Ruano Rincón]

El 05/07/23 a las 10:26, Moritz Muehlenhoff escribió:
> On Tue, Jul 04, 2023 at 03:17:43PM -0400, Roberto C. Sánchez wrote:
> > On Fri, Jun 16, 2023 at 10:12:22PM +0200, Moritz Muehlenhoff wrote:
> > > On Fri, Jun 16, 2023 at 01:29:28PM -0400, Roberto C. Sánchez wrote:
> > > > On Wed, May 17, 2023 at 10:50:34AM +0200, Moritz Muehlenhoff wrote:
> > > > > 
> > > > > My take would be to mark it as unsupported after the trixie 
> > > > > development cycle
> > > > > has started (this flags awareness, but has no impact on stable 
> > > > > releases)
> > > > > and then revisit the support situation before the trixie freeze (Kea 
> > > > > might be
> > > > > a full replacment by then or maybe it turns out the patch support is 
> > > > > ensured
> > > > > despite upstream's EOL)
> > > > > 
> > > > Hi Moritz,
> > > > 
> > > > Now that bookworm is out and (AFAICT) that the trixie development cycle
> > > > has started, are able to go ahead with marking isc-dhcp as unsupported?
> > > 
> > > Ultimately it's the maintainer(s) call, but sounds good to me.
> > > 
> > Are you referring to the maintainer of debian-security-support, or the
> > maintainer of isc-dhcp?
> 
> The isc-dhcp maintainers.

https://salsa.debian.org/debian/debian-security-support/-/merge_requests/16

I hope the above mentioned MR reflects the thread consensus. It is been
a long time since I haven't made any change to debian-security-support,
please review it, in case I am doing some stupidity.

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1038882: override: isc-dhcp-client:net/optional dhcpcd-base:net/important

[Santiago Ruano Rincón]

Control: retitle -1 override: isc-dhcp-client:net/optional

El 23/06/23 a las 09:36, Holger Levsen escribió:
> On Thu, Jun 22, 2023 at 10:11:21AM -0300, Santiago Ruano Rincón wrote:
> > ISC-DHCP has become EOL'ed by upstream. The best alternative for
> > isc-dhcp-client is dhcpcd-base. Could you please low the isc-dhcp-client
> > priority to optional and bump that of dhcpcd-base to important, as
> > suggested in https://lists.debian.org/debian-devel/2023/06/msg00210.html
> 
> I don't think that thread's consensus was to raise the priority to important,
> quite the contrary actually: they both should become optional.

Hard to say there is a unique consensus in that thread :-P But yeah,
both of them optional makes sense.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1038894: gbp setup-gitattributes: include an option to automatically defuse git attributes when present upstream

[Santiago Ruano Rincón]

Package: git-buildpackage
Version: 0.9.31
Severity: wishlist

Hi!

As discused here:
https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/424
it would be great to have an option to make `gbp setup-gitattributes`
mimic `gbp clone` behaviour, and only defuse git attributes when they
are present upstream. An option such as

  gbp setup-gitattributes --defuse-gitattributes=auto


Cheers!

 -- Santiago

 -- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages git-buildpackage depends on:
ii  devscripts 2.23.4
ii  git1:2.40.1+next.20230427-1
ii  man-db 2.11.2-2
ii  python33.11.2-1+b1
ii  python3-dateutil   2.8.2-2
ii  python3-pkg-resources  66.1.1-1
ii  python3-yaml   6.0-3+b2
ii  sensible-utils 0.0.19

Versions of packages git-buildpackage recommends:
ii  pristine-tar  1.50
ii  python3-requests  2.28.1+dfsg-1
ii  sbuild0.85.2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.13p3-1
ii  unzip6.0-28

-- no debconf information


signature.asc
Description: PGP signature

Bug#1038882: override: isc-dhcp-client:net/optional dhcpcd-base:net/important

[Santiago Ruano Rincón]

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

Hello there!

ISC-DHCP has become EOL'ed by upstream. The best alternative for
isc-dhcp-client is dhcpcd-base. Could you please low the isc-dhcp-client
priority to optional and bump that of dhcpcd-base to important, as
suggested in https://lists.debian.org/debian-devel/2023/06/msg00210.html

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1031236: ifupdown: diff for NMU version 0.8.41+nmu1

[Santiago Ruano Rincón]

El 21/06/23 a las 19:10, Uwe Kleine-König escribió:
> Control: tags 1031236 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for ifupdown (versioned as 0.8.41+nmu1) and intend
> to upload it to DELAYED/10 once I properly tested the patch.
> (Unfortunately I locked myself out of the affected machine while
> reconfiguring the network devices. So testing will have to wait until I
> find someone with physical access to that machine.)
> 
> The change is effectively what Ken Milmore proposed.

Thanks for this. Would you like to prepare a MR instead. I would like to
handle the switch to dependency on dhcpcd-base along.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1006263: ifupdown: outdated DHCP client support

[Santiago Ruano Rincón]

El 15/05/23 a las 14:17, Martin-Éric Racine escribió:
> Package: ifupdown
> Version: 0.8.41
> Followup-For: Bug #1006263
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> This is still broken.
> 
> "dhclient, udhcpc, dhcpcd. (They have been listed in their order of 
> precedence.)"
> 
> This really is a problem if someone wants to use udhcpc or dhcpcd, because 
> dhclient is installed by default, so it always gets used. ifupdown really 
> needs a way to configure the precedence order.

Indeed. I will work on this after the upcoming release.

Thanks for pointing this out,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1035972: isc-dhcp EOL'ed

[Santiago Ruano Rincón]

(Sorry, I have forgotten to answer this)

El 09/06/23 a las 15:35, Antoine Beaupré escribió:
> [adding package maintainer to CC]
> 
> On 2023-05-17 10:50:34, Moritz Muehlenhoff wrote:
> > On Fri, May 12, 2023 at 08:58:01AM +, Holger Levsen wrote:
> >> On Fri, May 12, 2023 at 10:08:52AM +0200, Raphael Hertzog wrote:
> >> > > ISC is not longer maintaing any of the components of isc-dhcp (client,
> >> > > I propose to mark it as unsupported. Or at least, limited, if we still
> >> > > have hope in those security update exceptions they claim they could do.
> >> [...]
> >> > It's not a service to our users to claim that we will not support them.
> >> [...]
> >> > But I'm afraid that we will have to keep maintaining those for the 
> >> > benefit
> >> > of our stable/oldstable (and even ELTS) users. I'm pretty sure that all
> >> > the other distributions will also continue to maintain those packages for
> >> > the lifetime of their respective releases so that we will have
> >> > opportunities to share the workload and patches.

Yeah, you are right. Sorry for my not-very-clever message, maybe due to
my disappointment of this deprecation.

> >
> > Agreed.
> >
> >> Given what Raphael wrote, should this bug maybe be about marking isc-dhcp
> >> unsupported in trixie?
> >
> > My take would be to mark it as unsupported after the trixie development 
> > cycle
> > has started (this flags awareness, but has no impact on stable releases)
> > and then revisit the support situation before the trixie freeze (Kea might 
> > be
> > a full replacment by then or maybe it turns out the patch support is ensured
> > despite upstream's EOL)
> 
> I think this is important enough to warrant an entry in the release
> notes. I started working on something to that effect here:
> 
> https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/194
> 
> Hopefully that makes sense here?
> 

Thanks Antoine for start working on the MR.

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1030320: tango: New version 9.4.1 available

[Santiago Ruano Rincón]

Control: tags -1 + fixed-in-experimental

On Thu, 02 Feb 2023 21:29:12 +0100 Thomas Braun  
wrote:
> Package: tango
> Severity: normal
> 
> We would really like to have 9.4.1 [0] in upcoming debian bookworm
> instead of the old 9.3.x.
> 
> I've already tested if our tests pass on debian testing on amd64, yes
> they do [1].
> 
> The changes compared to 9.3.x are listed at [2]. Packaging wise the
> biggest change is that we now only support cmake.
> 
> As you are using the TangoSourceDistribution we have some info posted
> at [3] wrt to the cmake options.
> 
> Thanks,
> Thomas
> 
> [0]: https://gitlab.com/tango-controls/cppTango/-/releases/9.4.1
> [1]: https://gitlab.com/tango-controls/cppTango/-/merge_requests/1044
> [2]:
> https://gitlab.com/tango-controls/cppTango/-/blob/main/RELEASE_NOTES.md
> [3]:
> https://gitlab.com/tango-controls/TangoSourceDistribution/-/tree/main/assets#installation

9.4.2-rc2 is now available in experimental.

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1036640: debian template's help lists archived releases that are not installable

[Santiago Ruano Rincón]

Source: lxc-templates
Version: 3.0.4.48.g4765da8-1
Severity: minor

Dear LXC team,

The help from the debian lxc template lists the following:

  -r, --release=RELEASE  Debian release. Can be one of: wheezy, jessie,
  stretch, buster, sid.

Wheezy, jessie and stretch are not found in the mirror.

Could you please, update that list? Or even better, make it possible to
install them from archive.debian.org?

Cheers!

 -- S

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

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

-- no debconf information


signature.asc
Description: PGP signature

Bug#1030320: tango: New version 9.4.1 available

[Santiago Ruano Rincón]

Control: retitle -1 Upstream version 9.4.2-rc2 available

On Thu, 02 Feb 2023 21:29:12 +0100 Thomas Braun  
wrote:
> Package: tango
> Severity: normal
> 
> We would really like to have 9.4.1 [0] in upcoming debian bookworm
> instead of the old 9.3.x.
> 
> I've already tested if our tests pass on debian testing on amd64, yes
> they do [1].
> 
> The changes compared to 9.3.x are listed at [2]. Packaging wise the
> biggest change is that we now only support cmake.
> 
> As you are using the TangoSourceDistribution we have some info posted
> at [3] wrt to the cmake options.
> 
> Thanks,
> Thomas
...

Hi!

Not exactly 9.4.1, but I've preparing a release of 9.4.2-rc2 for
experimental. A WIP branch can be found here:
https://salsa.debian.org/science-team/tango/-/tree/pre-9.4.2_rc2+dfsg1

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1035972: isc-dhcp EOL'ed

[Santiago Ruano Rincón]

Source: debian-security-support
Version: 1:12+2023.05.04
Severity: normal
X-Debbugs-Cc: secur...@debian.org, debian-...@lists.debian.org

Dear security and LTS teams,

ISC is not longer maintaing any of the components of isc-dhcp (client,
relay or server):
https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html
https://www.isc.org/blogs/isc-dhcp-eol/

I propose to mark it as unsupported. Or at least, limited, if we still
have hope in those security update exceptions they claim they could do.

Cheers,

 -- Santiago

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

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

-- debconf information excluded


signature.asc
Description: PGP signature

Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

[Santiago Ruano Rincón]

Control: severity -1 important

Hi!

On Fri, 6 Jan 2023 12:31:47 +0100 =?utf-8?B?0L3QsNCx?= 
 wrote:
> Hi!
> 
> On Fri, Jan 06, 2023 at 10:52:31AM +0100, Andrej Shadura wrote:
> > On Thu, 5 Jan 2023, at 21:32, наб wrote:
> > > Bisecting over the upstream git, I got
> > >   commit 8f9cca055bc661c4c690a5f5e1ca71370d129bc3 (HEAD, refs/bisect/bad)
> > >   Author: Herbert Xu 
> > >   Date:   Wed Jan 19 16:37:54 2022 +1100
> > >  
> > >   expand: Always quote caret when using fnmatch
> > 
> > > as the first bad commit with default configuration (HAVE_FNMATCH=1).
> > >
> > > I /cannot/ find a set-up where configuring like Debian
> > > (--disable-fnmatch --disable-lineno --disable-glob)
> > > isn't broken.
> > 
> > I’m not sure why this also affects configurations with --disable-fnmatch — 
> > from the description of it, it shouldn’t?
> 
> Well, dash's built-in globs Just Don't Support ^. Never have.
> (Defined as "current code doesn't and it blames to start-of-git".)
> They're strictly POSIX, and ^ is a regular character for them.
> 
> 8f9cca0 fixes the fact that glibc fnmatch() has a special meaning for ^
> by unconditionally escaping it (if configured for libc fnmatch) ‒
> it normalises [^0-9] to always mean [0-9^],
> regardless of --with-fnmatch/--disable-fnmatch.
> 
> > > Y'know what, I bisected the Salsa git, too, but then I consulted POSIX.
> > > Apparently, this is fine.
> > 
> > > Please for the love of god add this to the NEWS.
> > > I /guarantee/ people are using '[^0-9]' to mean "not 0-9",
> > > and similar constructs, even if they are well-versed in the shell 
> > > language.
> > >
> > > This is a breaking change going from bullseye, and quite an insidious one.
> > > I assume my reaction is gonna mirror others' quite well.
> > >
> > > /Please/ add this to the NEWS.
> > 
> > I’m actually considering reverting that patch, as it seems a bit too late 
> > in the release cycle to introduce such a breaking change.
> 
> I've bisected across snapshot.d.o, and the first Debian version
> that exhibits this behaviour is 0.5.11+git20210903+057cd650a4ed-4:
>   
> http://snapshot.debian.org/package/dash/0.5.11%2Bgit20210903%2B057cd650a4ed-4/
> 
> Which, if I understand it right, has landed in sid on 2022-03-04.
> Since march of last year, sid and testing have been using this;
> quoth tracker.d.o:
>   [2022-03-07] dash 0.5.11+git20210903+057cd650a4ed-7 MIGRATED to testing 
> (Debian testing watch) 
> 
> So it's been a good part of a year and no-one's complained
> (maybe I'm the idiot what doesn't know globs are negated with !s),
> from the point of view of "system compatibility",
> I think this has passed the test.
> 
> From the point of user code, a NEWS entry I'd consider sufficient,
> as usual for breaking-for-compat user-observable changes.
> 
> Reverting this now would probably have the opposite effect

I am taking the liberty to increase the severity of this bug. I'd say it
is serious, but I'd let the maintainer or the release team to decide on
that.

I am aware of at least one user hit by this. If the current behaviour
would be part of bookworm, a NEWS entry would be great.

Thanks,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1034177: bzip2: CVE-2023-29415 CVE-2023-29416 CVE-2023-29418 CVE-2023-29419 CVE-2023-29420 CVE-2023-29421

[Santiago Ruano Rincón]

Control: reassign -1 bzip3
Control: retitle -1 bipz3 CVE-2023-29415 CVE-2023-29416 CVE-2023-29418 
CVE-2023-29419 CVE-2023-29420 CVE-2023-29421

Dear Moritz and Sec Team,

Please, correct me if I am wrong, but it seems a bzip3 bug, instead of a
bzip2's.

El 10/04/23 a las 19:33, Moritz Mühlenhoff escribió:
> Source: bzip2
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for bzip2.
> 
> CVE-2023-29415[0]:
> | An issue was discovered in libbzip3.a in bzip3 before 1.3.0. A denial
> | of service (process hang) can occur with a crafted archive because
> | bzip3 does not follow the required procedure for interacting with
> | libsais.
> 
> https://github.com/kspalaiologos/bzip3/issues/95
> https://github.com/kspalaiologos/bzip3/commit/56c24ca1f8f25e648d42154369b6962600f76465

bzip2 -t 4.crashes.bz3
bzip2: 4.crashes.bz3: bad magic number (file not created by bzip2)

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

> 
> CVE-2023-29416[1]:
> | An issue was discovered in libbzip3.a in bzip3 before 1.3.0. A
> | bz3_decode_block out-of-bounds write can occur with a crafted archive
> | because bzip3 does not follow the required procedure for interacting
> | with libsais.
> 
> https://github.com/kspalaiologos/bzip3/commit/bfa5bf82b53715dfedf048e5859a46cf248668ff
>  (1.3.0)
> https://github.com/kspalaiologos/bzip3/issues/92
> 

I got similar errors.

> CVE-2023-29418[2]:
> | An issue was discovered in libbzip3.a in bzip3 before 1.2.3. There is
> | an xwrite out-of-bounds read.
> 
> https://github.com/kspalaiologos/bzip3/commit/aae16d107f804f69000c09cd92027a140968cc9d
>  (1.2.3)
> https://github.com/kspalaiologos/bzip3/issues/92
> 
> CVE-2023-29419[3]:
> | An issue was discovered in libbzip3.a in bzip3 before 1.2.3. There is
> | a bz3_decode_block out-of-bounds read.
> 
> https://github.com/kspalaiologos/bzip3/commit/8ec8ce7d3d58bf42dabc47e4cc53aa27051bd602
>  (1.2.3)
> https://github.com/kspalaiologos/bzip3/issues/92
> 
> CVE-2023-29420[4]:
> | An issue was discovered in libbzip3.a in bzip3 before 1.2.3. There is
> | a crash caused by an invalid memmove in bz3_decode_block.
> 
> https://github.com/kspalaiologos/bzip3/commit/bb06deb85f1c249838eb938e0dab271d4194f8fa
>  (1.2.3)
> https://github.com/kspalaiologos/bzip3/issues/92
> 
> CVE-2023-29421[5]:
> | An issue was discovered in libbzip3.a in bzip3 before 1.2.3. There is
> | an out-of-bounds write in bz3_decode_block.
> 
> https://github.com/kspalaiologos/bzip3/issues/94
> https://github.com/kspalaiologos/bzip3/commit/33b1951f153c3c5dc8ed736b9110437e1a619b7d
>  (1.2.3)

I am unable to find a similar code in my local bzip2 copy.

> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2023-29415
> https://www.cve.org/CVERecord?id=CVE-2023-29415
> [1] https://security-tracker.debian.org/tracker/CVE-2023-29416
> https://www.cve.org/CVERecord?id=CVE-2023-29416
> [2] https://security-tracker.debian.org/tracker/CVE-2023-29418
> https://www.cve.org/CVERecord?id=CVE-2023-29418
> [3] https://security-tracker.debian.org/tracker/CVE-2023-29419
> https://www.cve.org/CVERecord?id=CVE-2023-29419
> [4] https://security-tracker.debian.org/tracker/CVE-2023-29420
> https://www.cve.org/CVERecord?id=CVE-2023-29420
> [5] https://security-tracker.debian.org/tracker/CVE-2023-29421
> https://www.cve.org/CVERecord?id=CVE-2023-29421
> 
> Please adjust the affected versions in the BTS as needed.
> 

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1032049: knot-resolver: Unable to enable HTTP module

[Santiago Ruano Rincón]

Control: tags -1 + moreinfo

Hi,

El 27/02/23 a las 12:19, Andrew escribió:
> Package: knot-resolver
> Version: 5.3.1-1+deb11u1
> Severity: normal
> X-Debbugs-Cc: and...@lists.savchenko.net
> 
> Dear Maintainer,
> 
> HTTP module in knot-resolver can't be enabled by adding `http` directive
> in its config file.
> 
> I have  tried the separate `modules.load('http')` statement via
> config and control socket / `kresc`, but to no avail.
> 
> `kresd.conf` attached below. While `kresc` reports that the module is
> loaded, no new port is opened and stats can't be fetched via `curl`.
> 
> `stats.list()` works as expected, this confirms that there is a valid
> data to expose via http.
> 

[...]

> -- Configuration Files:
> /etc/default/kresd [Errno 13] Permission denied: '/etc/default/kresd'
> /etc/knot-resolver/kresd.conf changed:
> -- Listen locally, ipv4-only
> net = { '127.0.0.1' }
> net.ipv6 = false
> 
> -- Enable optional modules
> modules = {
>   'policy',  -- NXDOMAIN "bad" queries
>   'hints',   -- read /etc/hosts and whatever is defined below
>   'stats',   -- internal statistics
>   'serve_stale < cache', -- serve stale record if parent NS is unreachable
>   'rebinding < iterate', -- prevent rebinding attack, TODO: Remove?..
>   'prefill',
>   'predict',
>   'view',
>   http = {
> host = '127.0.0.1',
> port = 8053
>   }

I am unaware of this kind of configuration is possible. Documentation[1]
rather states addresses and ports should be configured by net.listen().
E.g.:

net.listen('127.0.0.1', 8453, { kind = 'webmgmt' }) -- see http module
net.listen('::1', 8453, { kind = 'webmgmt' }) -- see http module

The above works for me in 5.3.1 and 5.6.0.

[1] 
https://knot-resolver.readthedocs.io/en/v5.3.1/daemon-bindings-net_server.html

Could you please give it a try?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- light, fast, functional web server

[Santiago Ruano Rincón]

Control: tags -1 + moreinfo

El 14/02/23 a las 15:15, Glenn Strauss escribió:
> On Tue, Feb 14, 2023 at 05:50:12PM +0100, Santiago Ruano Rincón wrote:
> > Hello Glenn,
> > 
> > El 12/02/23 a las 08:54, Glenn Strauss escribió:
[...]
> > 2. d/lighttpd.NEWS:
> > 
> > As lintian complains, this entry relates a release not known by debian:
> > 
> > lighttpd (1.4.67-2) experimental; urgency=medium
> > 
> > Do you think NEWS could be updated?
> 
> Updated to 1.4.69-1, as this will be the release that contains the
> change.

Great, thanks! However, just a is a minor typo:

+++ lighttpd-1.4.69/debian/lighttpd.NEWS2023-02-11 04:34:51.0 +0100
@@ -1,3 +1,18 @@
+lighttpd (1.4.69-1) experimental; urgency=medium
+

You are uploading to unstable, not experimental. And lintian still
complains about that.

Once you have fixed that, could you please push a signed git tag, and
remove the moreinfo tag of this bug?

Thank you!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1031236: ifupdown: dns-nameservers with systemd-resolved is broken

[Santiago Ruano Rincón]

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

El 13/02/23 a las 20:38, Dmytro Kolesnykov escribió:
> Package: ifupdown
> Version: 0.8.41
> Severity: normal
> 
> Dear Maintainer,

Dear ifupdown user,

> 
> I was doing my network setup, which included statically configured
> logical interfaces. So there were dns-nameservers entries in my
> /etc/network/interfaces. My configuration files is below (the actual
> IPs and MACs is wiped).
> 
> I noted that ifup with my setup is producing error messages like this:
> 
> ...
> guessnet: Started tests
> guessnet: 3 candidates
> guessnet: Got ARP reply from 192.168.0.1 XX:XX:XX:XX:XX:XX
> guessnet: ARP reply from 192.168.0.1 XX:XX:XX:XX:XX:XX matches
> guessnet: Notified success of scan peer 192.168.0.1 XX:XX:XX:XX:XX:XX
> guessnet: Removing candidate enp4s0-direct
> guessnet: Keeping candidate enp4s0-router
> guessnet: We had changes, notifying the listener
> guessnet: Got ARP reply from 192.168.0.1 XX:XX:XX:XX:XX:XX
> /etc/network/if-up.d/resolved: 69: DNS: not found
> /etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-enp4s0: 
> DNS=192.168.0.1 192.168.0.12: not found
> Failed to parse DNS server address: DNS
> Failed to set DNS configuration: Invalid argument
> 
> I have found discussion about similar problem there:
> https://unix.stackexchange.com/questions/714901/dns-broken-when-using-ifupdown-and-systemd-resolved-after-upgrade-to-ubuntu-22-0
> 
> Also I had a look into the /etc/network/if-up.d/resolved and I assume
> this is a typo in the line 69:
> https://salsa.debian.org/debian/ifupdown/-/blob/master/debian/if-up.d/resolved#L69
> 

[...]

Thanks for reporting this issue, and for proposing the patch.

Have you had the chance to test an IPv6 configuration?
I'll need to change my setup for testing that. And I'd love add tests to
check this.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- light, fast, functional web server

[Santiago Ruano Rincón]

Hello Glenn,

El 12/02/23 a las 08:54, Glenn Strauss escribió:
> > Since you are listed in Uploaders:, this shouldn't be a NMU. I don't
> > understand why lintian doesn't complain about this in this job:
> > https://salsa.debian.org/debian/lighttpd/-/jobs/3931309
> > but don't have the time to investigate that right now.
> > 
> > Please, fix the changelog.
> 
> changelog updated.  Thanks for your guidance.
> Cheers, Glenn
> 

Sorry I was unable to give you more feedback the first time. So I am
iterating. ENOTIME…

Here you have some comments regarding two files:

1. d/changelog:

lighttpd (1.4.69-1) unstable; urgency=medium

  [ Glenn Strauss ]

Since you are the only one doing changes in this release, no need to
tell that twice. You can remove the line above.

  * New upstream version 1.4.69
  * (changes for 1.4.68; not released in Debian)

I am afraid I cannot parse that entry. What are the changes related to
1.4.68?

  * Remove deprecated lighttpd modules.
  * Skip installing modules now built into lighttpd.
  * Add to not-installed mods now built into lighttpd.

Is it worth to list those modules?
Is there any impact for the uses to they should be warned via e.g.
debian/NEWS too?

  * Declare compliance with policy 4.6.2 - no changes needed.
  * lighttpd.init reopen-logs only if lighttpd is currently running.
  * New upstream version 1.4.68

I don't think the line above is needed. You are doing a release for
1.4.69.

$ git branch --track upstream origin/upstream
$ git branch --track pristine-tar origin/pristine-tar
$ release=1.4.68
$ cd ..
$ wget 
https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-$release.tar.xz
$ wget 
https://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-$release.tar.xz.asc

(Just in case, you can use uscan for that)

$ cd -
$ git fetch origin
$ git checkout pristine-tar
$ git pull --rebase
$ git checkout master
$ gbp import-orig --uscan -u $release
# - adds commits to 'pristine-tar' and 'upstream' branches
# - tags 'upstream' branch upstream/$release
# - merges upstream/$release tag into master branch
$ git push origin master pristine-tar upstream/$release

Neither I wouldn't place these instructions in d/changelog.

 -- Glenn Strauss   Fri, 10 Feb 2023 22:34:51 -0500


2. d/lighttpd.NEWS:

As lintian complains, this entry relates a release not known by debian:

lighttpd (1.4.67-2) experimental; urgency=medium

Do you think NEWS could be updated?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- light, fast, functional web server

[Santiago Ruano Rincón]

Hi!

El 12/02/23 a las 08:18, Glenn Strauss escribió:
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-Cc: gs-bugs.debian@gluelogic.com
> 
> Dear mentors,
> 
> I am looking for a DD sponsor for my package "lighttpd":
> 
> https://salsa.debian.org/debian/lighttpd/
> 
> I am an upstream lighttpd developer and have participated in
> maintaining lighttpd on Debian for a number of years.
> 
> I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd
> 
> I put together a new package for lighttpd 1.4.69 and filed an NMU bug,
> but that got routed to lighttpd maintainers, which currently has no DD.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031069

Since you are listed in Uploaders:, this shouldn't be a NMU. I don't
understand why lintian doesn't complain about this in this job:
https://salsa.debian.org/debian/lighttpd/-/jobs/3931309
but don't have the time to investigate that right now.

Please, fix the changelog.

> 
> The previous DD maintainer had to step away and there is currently
> no DD part of the Debian lighttpd package maintainers.
> 
>  * Package name : lighttpd
>Version  : 1.4.69-1
>Upstream contact : team+light...@tracker.debian.org
>  * URL  : https://lighttpd.net/
>  * License  : BSD-3-Clause
>  * Vcs  : https://git.lighttpd.net/lighttpd/lighttpd1.4
> 
> Please help me to get lighttpd 1.4.69 into Debian Bookworm.
> Thank you.  Glenn
> 

Thanks for your work!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1030865: RFS: ncdu/1.18-0.2 [NMU] -- ncurses disk usage viewer

[Santiago Ruano Rincón]

Control: tags -1 + pending

El 09/02/23 a las 20:29, Christian Göttsche escribió:
> On Thu, 9 Feb 2023 at 15:51, Santiago Ruano Rincón
>  wrote:
> >
> > Have you been able to test how it builds on GNU/Hurd, and confirm it
> > fixes the FTBFS?
> 
> I have not tested the fixes directly on GNU/Hurd.
> But the main difference for the build is the absence of
> , and I tested building with HAVE_LINUX_MAGIC_H in
> config.h commented out.
> Without the two patches the build fails similar to the buildd log, and
> with them included the build passes.
> 

Thanks. I've uploaded it with a 5-day delay, to give Eugene some time to
react, if needed.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1030865: RFS: ncdu/1.18-0.2 [NMU] -- ncurses disk usage viewer

[Santiago Ruano Rincón]

Hi,

El 08/02/23 a las 17:26, Christian Göttsche escribió:
> Package: sponsorship-requests
> Severity: normal
> X-Debbugs-CC: jac...@debian.org
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ncdu":
> 
>  * Package name : ncdu
>Version  : 1.18-0.2
>Upstream contact : Yoran Heling 
>  * URL  : https://dev.yorhel.nl/ncdu/
>  * License  : Zlib, Expat
>Section  : admin
> 
> The source builds the following binary packages:
> 
>   ncdu - ncurses disk usage viewer
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/ncdu/
> 
> Alternatively, you can download the package with 'dget' using this command:
> 
>   dget -x https://mentors.debian.net/debian/pool/main/n/ncdu/ncdu_1.18-0.2.dsc
> 
> Changes since the last upload:
> 
>  ncdu (1.18-0.2) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* d/patches: cherry-pick commits to fix FTBFS on GNU/Hurd
[...]

Thanks for preparing this new release.

Have you been able to test how it builds on GNU/Hurd, and confirm it
fixes the FTBFS?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#961508: ifupdown: RTNETLINK answers: File exists

[Santiago Ruano Rincón]

Hi!

El 31/01/23 a las 14:10, Antoine Beaupré escribió:
> I have a similar problem with ifupdown on my home server which has
> accumulated a rather unfortunate pile of crap...
> 
> I am not sure where the problem comes from. I suspect it might be
> related to the initrd raising the interfaces before ifup actually runs,
> and the RTNETLINK error is about the gateway already being set.
> 
> The workaround I found was to just flush the device before the setup:
> 
> iface eth0 inet static
>   # fix RTNETLINK errors on boot see https://bugs.debian.org/961508
> pre-up ip addr flush dev eth0 || true
>   address 192.168.0.3
>   netmask 255.255.255.0
>   gateway 192.168.0.1
> 
> One might argue this should be the default and that ifup should clear
> interfaces before bringing them up, but I'm not familiar enough with
> ifup's intricacies to be certain.
...

I suppose this could be safe on a static configuration.

ael , your interfaces content is not available.
Could you please confirm your eth0 configuration is static?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1007150: ifupdown: for IPv6 drop RFC4291 EUI-64 generation in favor of RFC7217 stable privacy addressing

[Santiago Ruano Rincón]

Hi,

El 26/01/23 a las 13:34, Martin-Éric Racine escribió:
> Package: ifupdown
> Version: 0.8.41
> Followup-For: Bug #1007150
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Greetings,
> 
> Any progress on this?
> 

None for the moment. But thanks for the ping. I acknowledge this is an
important bug.

I see what I can do ASAP.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Santiago Ruano Rincón]

El 26/01/23 a las 19:29, Cyril Brulebois escribió:
> Hi Oleg,
> 
> Oleg A. Arkhangelsky  (2023-01-26):
> > After some digging I think that there is more elegant way to stop
> > ifup@*.service when stopping (or restarting) networking.serivce, we just
> > need to add PartOf to /lib/systemd/system/ifup@.service:
> > 
> >   [Unit]
> >   ...
> >   PartOf=networking.service
> > 
> > And this ExecStart to /lib/systemd/system/networking.service, to make
> > networking.service restart workable for "allow-hotplug" interfaces (as
> > per your suggestion):
> > 
> >   [Service]
> >   ...
> >   ExecStart=/usr/bin/udevadm trigger --action=add --subsystem-match=net
> >   ...
> > 
> > This changes should be on top of *.service files, before any Bug#1029352
> > modifications, of course.
> > 
> > Seems like more clearer way, than to use /bin/sh invocation and flag file
> > for the non-first run condition check.
> > 
> > Any pitfalls for this approach?
> 
> Just to clarify: I was mostly interested in getting the initial regression
> fixed, as it was in the way of finally fixing wireless support (via /e/n/i
> rather than NM) in the installer. I tried to keep the proposed enhancement
> while making sure the regression wouldn't come back, hence the “convoluted”
> approach.
> 
> I'm happy if you folks keep digging into this to find a better solution by
> tweaking systemd units. I'll just mention that the freeze is underway, that
> a simple enhancement (making restart work) totally broke a much more
> important use case (keeping start working), and someone probably needs to
> weigh pros (getting things better, in a clean way) versus cons (not a lot of
> time to discover and track down possible side effects, be them positive or
> negative).
> 
> If things break for the installer again:
> 
> (in a deep voice) I'll be back!
> 
> ;)
> 

:-)

Just to add: I am also happy for more clean, elegant, robust, etc.
better approaches. But life is keeping me more busy than expected these
days.
Please, feel free to propose MRs that enhance also debian/tests/hotplug,
or create any other autopkgtest that could help to identify and prevent
regressions. (No guarantee that those MR could be included in bookworm.)

Cheers!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1029680: bullseye-pu: package grep/3.6-1+deb11u1

[Santiago Ruano Rincón]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: g...@packages.debian.org, 1029...@bugs.debian.org
Control: affects -1 + src:grep

[ Reason ]
3.6-1 is affected by https://bugs.debian.org/1029235#19

[ Impact ]
Not fixing this means continue to have a POSIX-non-compliant behaviour.

[ Tests ]
I made similar tests as for https://bugs.debian.org/1029595:

This is a build job including only the upstream test:
https://salsa.debian.org/santiago/grep/-/jobs/3848015#L3199
And this is the pipeline of a fixed grep in stable:
https://salsa.debian.org/santiago/grep/-/pipelines/490293
reprotest fails, but that's independent of the fix.
It also fails for 3.6-1:
https://salsa.debian.org/debian/grep/-/pipelines/490296

[ Risks ]
grep is a key package. But the risks of introducing this release are
low, according to the tests.

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

[ Changes ]

There are mainly two changes:
+  * Fix sometimes mistakenly matches lines when last of multiple patterns
+includes backref (Closes: #1029235)
+  * debian/salsa-ci.yml set RELEASE: bullseye

The latter is the simplest change, to make salsa-ci's pipeline build
grep on bullseye:

diff -Nru grep-3.6/debian/salsa-ci.yml grep-3.6/debian/salsa-ci.yml
--- grep-3.6/debian/salsa-ci.yml2020-11-09 21:37:02.0 +0100
+++ grep-3.6/debian/salsa-ci.yml2023-01-25 09:23:20.0 +0100
@@ -1,3 +1,6 @@
 include:
   - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
   - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  RELEASE: 'bullseye'

The other change is the actual fix, that fixes the comparison between
multiple patterns when there are back-references-free patterns.

[ Other info ]
Null.
diff -Nru grep-3.6/debian/changelog grep-3.6/debian/changelog
--- grep-3.6/debian/changelog   2020-11-09 21:37:02.0 +0100
+++ grep-3.6/debian/changelog   2023-01-25 09:23:20.0 +0100
@@ -1,3 +1,11 @@
+grep (3.6-1+deb11u1) bullseye; urgency=medium
+
+  * Fix sometimes mistakenly matches lines when last of multiple patterns
+includes backref (Closes: #1029235)
+  * debian/salsa-ci.yml set RELEASE: bullseye
+
+ -- Santiago Ruano Rincón   Wed, 25 Jan 2023 09:23:20 
+0100
+
 grep (3.6-1) unstable; urgency=low
 
[ Debian Janitor ]
diff -Nru 
grep-3.6/debian/patches/1029235-grep-bug-backref-in-last-of-multiple-patterns.patch
 
grep-3.6/debian/patches/1029235-grep-bug-backref-in-last-of-multiple-patterns.patch
--- 
grep-3.6/debian/patches/1029235-grep-bug-backref-in-last-of-multiple-patterns.patch
 1970-01-01 01:00:00.0 +0100
+++ 
grep-3.6/debian/patches/1029235-grep-bug-backref-in-last-of-multiple-patterns.patch
 2023-01-25 09:23:20.0 +0100
@@ -0,0 +1,73 @@
+From b061d24916fb9a14da37a3f2a05cb80dc65cfd38 Mon Sep 17 00:00:00 2001
+From: Paul Eggert 
+Date: Mon, 5 Dec 2022 14:16:45 -0800
+Subject: [PATCH] grep: bug: backref in last of multiple patterns
+Bug-Debian: https://bugs.debian.org/1029235
+Author: Santiago Ruano Rincón 
+Last-Update: 2023-01-24
+
+* NEWS: Mention this.
+* src/dfasearch.c (GEAcompile): Trim trailing newline from
+the last pattern, even if it has back-references and follows
+a pattern that lacks back-references.
+* tests/backref: Add test for this bug.
+---
+ NEWS|  6 ++
+ src/dfasearch.c | 25 -
+ tests/backref   |  8 
+ 3 files changed, 26 insertions(+), 13 deletions(-)
+
+Index: grep/src/dfasearch.c
+===
+--- grep.orig/src/dfasearch.c
 grep/src/dfasearch.c
+@@ -267,20 +267,19 @@ GEAcompile (char *pattern, size_t size,
+   if (compilation_failed)
+ exit (EXIT_TROUBLE);
+ 
+-  if (prev <= patlim)
++  if (patlim < prev)
++buflen--;
++  else if (pattern < prev)
+ {
+-  if (pattern < prev)
+-{
+-  ptrdiff_t prevlen = patlim - prev;
+-  buf = xrealloc (buf, buflen + prevlen);
+-  memcpy (buf + buflen, prev, prevlen);
+-  buflen += prevlen;
+-}
+-  else
+-{
+-  buf = pattern;
+-  buflen = size;
+-}
++  ptrdiff_t prevlen = patlim - prev;
++  buf = xrealloc (buf, buflen + prevlen);
++  memcpy (buf + buflen, prev, prevlen);
++  buflen += prevlen;
++}
++  else
++{
++  buf = pattern;
++  buflen = size;
+ }
+ 
+   /* In the match_words and match_lines cases, we use a different pattern
+Index: grep/tests/backref
+===
+--- grep.orig/tests/backref
 grep/tests/backref
+@@ -43,4 +43,12 @@ if test $? -ne 2 ; then
+ failures=1
+ fi
+ 
++# https://bugs.gnu.

Bug#1029595: unblock: grep/3.8-4

[Santiago Ruano Rincón]

Hi Paul,

El 26/01/23 a las 09:05, Paul Gevers escribió:
> Confirmed.
> 
> Hi Santiago,
> 
> On 25-01-2023 09:01, Santiago Ruano Rincón wrote:
> > Please unblock package grep
> 
> Please go ahead.

Thanks

> 
> > [ Other info ]
> > Not sure about the version to use in the unblock tag/command below.
> 
> Our freeze policy [1] says this about it:
> """
> As the rules above are not automatically enforced, the 'standard' testing
> migration rules are enforced.
> """
> so technically there's nothing to unblock.

ACK!

> 
> Paul
> 
> [1] https://release.debian.org/testing/freeze_policy.html#transition





signature.asc
Description: PGP signature

Bug#1029595: unblock: grep/3.8-4

[Santiago Ruano Rincón]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: g...@packages.debian.org, 1029...@bugs.debian.org
Control: affects -1 + src:grep

Please unblock package grep

[ Reason ]
To fix RC bug https://bugs.debian.org/1029235#19 in unstable. The patch
is in the grep upstream development branch and will be part of next
release.

[ Impact ]
Not fixing this means continue to have a POSIX-non-compliant behaviour.

[ Tests ]
An upstream testcase is included in the patch. I've created a branch
applying the test only (without the fix)
https://salsa.debian.org/santiago/grep/-/commit/09c3b715e3fa1b21f9ec531781c8c0091db96f23
that fails:
https://salsa.debian.org/santiago/grep/-/jobs/3824648#L3368

This is the pipeline with the fixed branch (uploaded to experimental):
https://salsa.debian.org/santiago/grep/-/pipelines/487847
and this for the proposed release:
https://salsa.debian.org/debian/grep/-/pipelines/489911

[ Risks ]
grep is a key package. But the risks of introducing this release are
low, according to the tests.

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

[ Other info ]
Not sure about the version to use in the unblock tag/command below.

unblock grep/3.8-4
diff -Nru grep-3.8/debian/changelog grep-3.8/debian/changelog
--- grep-3.8/debian/changelog   2022-10-25 21:24:11.0 +0200
+++ grep-3.8/debian/changelog   2023-01-24 15:43:00.0 +0100
@@ -1,3 +1,16 @@
+grep (3.8-5) unstable; urgency=medium
+
+  * Upload to unstable
+
+ -- Santiago Ruano Rincón   Tue, 24 Jan 2023 15:43:00 
+0100
+
+grep (3.8-4) experimental; urgency=medium
+
+  * Fix sometimes mistakenly matches lines when last of multiple patterns
+includes backref (Closes: #1029235)
+
+ -- Santiago Ruano Rincón   Fri, 20 Jan 2023 17:25:51 
+0100
+
 grep (3.8-3) unstable; urgency=low
 
   * Temporarily add 1019724-handle-backslash-warning.patch to disable the
diff -Nru 
grep-3.8/debian/patches/1029235-grep-bug-backref-in-last-of-multiple-patterns.patch
 
grep-3.8/debian/patches/1029235-grep-bug-backref-in-last-of-multiple-patterns.patch
--- 
grep-3.8/debian/patches/1029235-grep-bug-backref-in-last-of-multiple-patterns.patch
 1970-01-01 01:00:00.0 +0100
+++ 
grep-3.8/debian/patches/1029235-grep-bug-backref-in-last-of-multiple-patterns.patch
 2023-01-24 15:43:00.0 +0100
@@ -0,0 +1,71 @@
+From b061d24916fb9a14da37a3f2a05cb80dc65cfd38 Mon Sep 17 00:00:00 2001
+From: Paul Eggert 
+Date: Mon, 5 Dec 2022 14:16:45 -0800
+Subject: [PATCH] grep: bug: backref in last of multiple patterns
+Bug-Debian: https://bugs.debian.org/1029235
+
+* NEWS: Mention this.
+* src/dfasearch.c (GEAcompile): Trim trailing newline from
+the last pattern, even if it has back-references and follows
+a pattern that lacks back-references.
+* tests/backref: Add test for this bug.
+---
+ NEWS|  6 ++
+ src/dfasearch.c | 25 -
+ tests/backref   |  8 
+ 3 files changed, 26 insertions(+), 13 deletions(-)
+
+Index: grep/src/dfasearch.c
+===
+--- grep.orig/src/dfasearch.c
 grep/src/dfasearch.c
+@@ -281,20 +281,19 @@ GEAcompile (char *pattern, idx_t size, r
+   if (compilation_failed)
+ exit (EXIT_TROUBLE);
+ 
+-  if (prev <= patlim)
++  if (patlim < prev)
++buflen--;
++  else if (pattern < prev)
+ {
+-  if (pattern < prev)
+-{
+-  idx_t prevlen = patlim - prev;
+-  buf = xirealloc (buf, buflen + prevlen);
+-  memcpy (buf + buflen, prev, prevlen);
+-  buflen += prevlen;
+-}
+-  else
+-{
+-  buf = pattern;
+-  buflen = size;
+-}
++  idx_t prevlen = patlim - prev;
++  buf = xirealloc (buf, buflen + prevlen);
++  memcpy (buf + buflen, prev, prevlen);
++  buflen += prevlen;
++}
++  else
++{
++  buf = pattern;
++  buflen = size;
+ }
+ 
+   /* In the match_words and match_lines cases, we use a different pattern
+Index: grep/tests/backref
+===
+--- grep.orig/tests/backref
 grep/tests/backref
+@@ -43,4 +43,12 @@ if test $? -ne 2 ; then
+ failures=1
+ fi
+ 
++# https://bugs.gnu.org/36148#13
++echo 'Total failed: 2 (1 ignored)' |
++grep -e '^Total failed: 0$' -e '^Total failed: \([0-9]*\) (\1 ignored)$'
++if test $? -ne 1 ; then
++echo "Backref: Multiple -e test, test #5 failed"
++failures=1
++fi
++
+ Exit $failures
diff -Nru grep-3.8/debian/patches/series grep-3.8/debian/patches/series
--- grep-3.8/debian/patches/series  2022-10-25 21:23:21.0 +0200
+++ grep-3.8/debian/patches/series  2023-01-24 15:43:00.0 +0100
@@ -4,3 +4,4 @@
 05-grep-wrapper-sh.patch
 upstream-0001-doc-improve-GREP_COLORS-doc-Bug-57696

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Santiago Ruano Rincón]

Hi!

El 23/01/23 a las 16:19, Cyril Brulebois escribió:
> Hi Santiago,
> 
> Santiago Ruano Rincón  (2023-01-23):
> > Thanks everybody for the inputs. I've applied Paul's solution, and the
> > generated .deb can be downloaded from here:
> > 
> > https://salsa.debian.org/debian/ifupdown/-/jobs/3841392/artifacts/raw/debian/output/ifupdown_0.8.41~1.gbp3a6fae+salsaci+20230123+42_amd64.deb
> > 
> > Would it be possible for you (Oleg, Paul, Jeff, kibi et al.) to give it
> > a try?
> 
> (Reading your mail with s/Paul/Pascal/g in mind.)

Oups, sorry! Thanks for patching that too.

> 
> Tests yesterday seem to indicate successful results, but again I've only
> tested a few combinations in a VM (to keep the feedback loop short).
> 
> From the installer team point of view, I'd welcome a swift upload with
> this patch, possibly with urgency=high so that the fix reaches testing
> soon. This will another blocker out of the way for the next D-I release!

Just uploaded with your patched patch.

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#1022843: Bug#1029352: Bug#1022843: ifupdown: network down after systemctl restart

[Santiago Ruano Rincón]

El 23/01/23 a las 00:24, Pascal Hambourg escribió:
> Oleg A. Arkhangelsky wrote:
> > Note that we have to use '--ignore-errors'. Otherwise if we have real
> > hotplug interface that is not present at the moment of restart, `ifup`
> > returns non-zero and systemd unit fail.
> 
> "--ignore-errors" marks missing interfaces as configured, so ifup will not
> configure them when invoked by udev. In order to not fail the systemd unit
> start on ifup error, you can prefix the command with "-".
> 
> On 22/01/2023 at 20:58, Cyril Brulebois wrote:
> > 
> > with an extra ens3 declared as auto, the following seems to work fine
> > for boot-up, stop and start, and restart:
> > 
> >  [Service]
> >  Type=oneshot
> >  EnvironmentFile=-/etc/default/networking
> >  ExecStart=/sbin/ifup -a --read-environment
> >  ExecStart=/bin/sh -c 'if [ -f /run/network/restart-hotplug ]; then 
> > /sbin/ifup -a --read-environment --allow=hotplug; fi'
> >  ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
> >  ExecStopPost=/usr/bin/touch /run/network/restart-hotplug
> >  RemainAfterExit=true
> >  TimeoutStartSec=5min
> 
> That seems needlessly convoluted. What about this:
> 
> [Service]
> Type=oneshot
> EnvironmentFile=-/etc/default/networking
> ExecStart=/sbin/ifup -a --read-environment
> ExecStart=-/sbin/ifup -a --read-environment --allow=hotplug
> ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
> RemainAfterExit=true
> TimeoutStartSec=5min
> 
> "start" and "restart" configure all existing "auto" and "allow-hotplug"
> interfaces.
> Missing "allow-hotplug" interfaces do not be marked as configured (so that
> they can be configured by udev) and do not make "start" or "restart" fail.

Thanks everybody for the inputs. I've applied Paul's solution, and the
generated .deb can be downloaded from here:

https://salsa.debian.org/debian/ifupdown/-/jobs/3841392/artifacts/raw/debian/output/ifupdown_0.8.41~1.gbp3a6fae+salsaci+20230123+42_amd64.deb

Would it be possible for you (Oleg, Paul, Jeff, kibi et al.) to give it
a try?

Cheers,

 -- S


signature.asc
Description: PGP signature

Bug#930247: grep: inconsistent behaviour with anchored regex containing back-references

[Santiago Ruano Rincón]

Control: -1 -2
Control: retitle -1 grep: inconsistent behaviour with anchored regex containing 
back-references
Control: severity -1 normal
Control: found -2 3.4-1
Control: notfound -2 2.27-2

On Fri, 02 Dec 2022 02:12:20 +0100 Thorsten Glaser  wrote:
> Package: grep
> Version: 3.6-1
> Followup-For: Bug #930247
> X-Debbugs-Cc: t...@mirbsd.de
> Control: found 930247 3.8-3
> Control: severity 930247 serious
> Control: retitle 930247 grep: does not handle backreferences correctly, 
> violating POSIX
> 
> I’m running into this, in stable and unstable both:
> 
> (sid-amd64)tglase@tglase:/tmp $ cat x
> Total failed: 0
> Total failed: 1 (1 ignored)
> Total failed: 2 (1 ignored)
> Total failed: 1 (2 ignored)
> Total failed: 1
> Total failed: 111
> (sid-amd64)tglase@tglase:/tmp $ grep -e '^Total failed: 0$' -e '^Total 
> failed: \([0-9]*\) (\1 ignored)$' x
> Total failed: 0
> Total failed: 1 (1 ignored)
> Total failed: 2 (1 ignored)
> Total failed: 1 (2 ignored)
> 
> By contrast, BSD handles it correctly:
> 
> tg@tglase-bsd:/tmp $ grep -e '^Total failed: 0$' -e '^Total failed: 
> \([0-9]*\) (\1 ignored)$' x
> Total failed: 0
> Total failed: 1 (1 ignored)
> 
> POSIX:
> 
> 3. The back-reference expression '\n' shall match the same (possibly
>empty) string of characters as was matched by a subexpression
>enclosed between "\(" and "\)" preceding the '\n'. The character
> 
> via 
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03
> from https://pubs.opengroup.org/onlinepubs/9699919799/utilities/grep.html
> 
> Please fix this clear standards violation; it makes grep
> virtually unusable.
> 
> 
> 
> -- System Information:
> Debian Release: 11.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads)
> Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), 
> LANGUAGE not set
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages grep depends on:
> ii  dpkg  1.20.12
> ii  install-info  6.7.0.dfsg.2-6
> ii  libc6 2.31-13+deb11u5
> ii  libpcre3  2:8.39-13
> 


signature.asc
Description: PGP signature

Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX

[Santiago Ruano Rincón]

El 05/12/22 a las 23:36, Thorsten Glaser escribió:
> Paul Eggert dixit:
> 
> > Although you sent your email to 36...@debbugs.gnu.org /
> > 930247@bugs.debian.9org, your email is reporting a separate bug
> 
> Oh OK, I wasn’t aware, it sounded similar enough.

I'll clone the bug in Debian (and adjust severities), to make it easier
to follow/differentiate both bugs.

Paul, do you want me to do the same in debbugs.gnu.org?

> 
> > I fixed it in the development version of GNU grep by installing the
> > attached patch. This patch should appear in the next GNU grep release.

grep is now freezed in Debian bookworm, and I'll have to contact
release-team about fixing this (in bullseye too).

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1029024: isc-dhcp-server: apparmor blocks reading files outside /etc/dhcpd

[Santiago Ruano Rincón]

Hi,

El 16/01/23 a las 18:29, Simone Piccardi escribió:
> Package: isc-dhcp-server
> Version: 4.4.3-P1-1.1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> After upgrading from version 4.4.3-P1-1 to 4.4.3-P1-1.1 the added
> apparmor configurations block the include of files outside /etc/dhcp/,
> like DDNS TSIG keys definition that are usually installed under
> /etc/bind.

As commented in usr.sbin.dhcpd:

  # access to bind9 keys for dynamic update
  # It's expected that users will generate one key per zone and have it
  # stored in both /etc/bind9 (for bind to access) and /etc/dhcp/ddns-keys
  # (for dhcpd to access).
  /etc/dhcp/ddns-keys/** r,

See also https://wiki.debian.org/DDNS

> I can understand avoiding to read files everywhere, but the use of
> TSIG keys defined by bind with is quite a common usage, that stop
> working with misleading permission denied error for readable files.
> 
> This break previously working configurations, whitout a note in
> the changelog.
> 

Indeed, unfortunately the NMU is missing a changelog update.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1028962: isc-dhcp-client: -x option no longer works (looks like apparmor configuration prevents it from having any effect)

[Santiago Ruano Rincón]

Control: tags -1 + moreinfo

Hello Francesco,

El 15/01/23 a las 11:53, Francesco Poli (wintermute) escribió:
> Package: isc-dhcp-client
> Version: 4.4.3-P1-1.1
> Severity: important
> 
> Hello and thanks for maintaining ISC DHCP in Debian!
> 

Thanks for your bug report!

> After upgrading packages ('isc-dhcp-client' itself or other libraries),
> it may happen that
> 
>   # checkrestart
> 
> (from the 'debian-goodies' package) tells me that an instance of dhclient
> should be restarted.
> 
> One option is bringing down the corresponding network interface and then
> bringing it up again:
> 
>   # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE
> 
> This works (well, used to work, see below...), but has some drawbacks:
> it leaves the box briefly without network, if all goes well; if something
> goes wrong, it leaves the box without network, until something else is
> done to fix the issue (and it could be troublesome, if you are
> administering the box through an SSH session from a distant remote host...);
> it may cut existing network connections down; and so forth...
> 
> A long time ago, I found what seems to be a better strategy.
> First of all, figure out the exact command line for dhclient:
> 
>   # ps aux | grep dhclien[t]
>   root 738  0.0  0.0   5868  3604 ?Ss   09:37   0:00 
> /sbin/dhclient -4 -v -i -pf /run/dhclient.enp0s25.pid -lf 
> /var/lib/dhcp/dhclient.enp0s25.leases -I -df 
> /var/lib/dhcp/dhclient6.enp0s25.leases enp0s25
> 
> Then, stop dhclient without releasing the current lease (as documented in
> the dhclient(8) man page):
> 
>   # /sbin/dhclient -x -pf /run/dhclient.enp0s25.pid
> 
> Finally start dhclient again with the previously found command line:
> 
>   # /sbin/dhclient -4 -v -i -pf /run/dhclient.enp0s25.pid -lf 
> /var/lib/dhcp/dhclient.enp0s25.leases -I -df 
> /var/lib/dhcp/dhclient6.enp0s25.leases enp0s25
> 
> This used to work without any network down-time, looked more failsafe and
> even quicker.
> 
> 
> Unfortunately, this second strategy no longer seems to work.
> When I issue the dhclient command with the "-x" option, nothing happens
> and dhclient goes on running.
> 
> I noticed the following line in /var/log/kern.log :
> 
>   2023-01-15T11:29:18.045334+01:00 $HOSTNAME kernel: [ 6692.708089] audit: 
> type=1400 audit(1673778558.040:25): apparmor="DENIED" operation="signal" 
> profile="/{,usr/}sbin/dhclient" pid=7192 comm="dhclient" 
> requested_mask="send" denied_mask="send" signal=term peer="unconfined"

I am not able to reproduce this with my current setup. I can
successfully run dhclient -x and it stops the related process.

Anyway, could you please test the attached patch?

> 
> It seems to me that the AppArmor configuration in 
> /etc/apparmor.d/sbin.dhclient
> is preventing the "-x" option from having any useful effect.
> 
> I am not familiar with AppArmor, but I think that this operation should
> be somehow possible, otherwise the AppArmor configuration makes the "-x"
> option (almost) completely useless.
> 
> Moreover, even the first strategy (ifdown/ifup) now seems to fail to
> work perfectly. After issueing the following command:
> 
>   # ifdown $NETWORK_INTERFACE ; ifup $NETWORK_INTERFACE
...

Do you see the same apparmor DENIED messages?

Cheers,

 -- Santiago
--- /var/tmp/sbin.dhclient	2023-01-16 14:23:17.981285558 +0100
+++ /etc/apparmor.d/sbin.dhclient	2023-01-16 14:25:04.975623364 +0100
@@ -70,6 +70,9 @@
   /usr/lib/NetworkManager/nm-dhcp-helper  Pxrm,
   signal (receive) peer=/usr/lib/NetworkManager/nm-dhcp-helper,
 
+  # https://bugs.debian.org/1028962
+  signal (send) set=("term") peer=unconfined,
+
   # Site-specific additions and overrides. See local/README for details.
   #include 
 }


signature.asc
Description: PGP signature

Bug#1024242: isc-dhcp FTCBFS: uses the build architecture compiler

[Santiago Ruano Rincón]

Version: 4.4.3-2.1.1

On Wed, 16 Nov 2022 09:25:32 +0100 Helmut Grohne  wrote:
> Source: isc-dhcp
> Version: 4.4.3-2.1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> isc-dhcp fails to cross build from source, because it uses the build
> architecture compiler for embedded bind build. This is difficult to
> observe, because the complete build log for the bind build (including
> configure output and all compiler invocation) is hidden from the build
> log (which violates a Debian policy should). Consider making the build
> verbose by default. In any case, I'm attaching a patch to fix the
> compiler for your convenience.
> 
> Helmut

This was included in the 4.4.3-1.1 NMU, but but the changelog is
incomplete.

https://tracker.debian.org/news/1407186/accepted-isc-dhcp-443-p1-11-source-into-unstable/

Cheers,

 -- Santiago



signature.asc
Description: PGP signature

Bug#1022843: ifupdown: network down after systemctl restart

[Santiago Ruano Rincón]

Control: tags -1 + pending

Hi!

El 29/10/22 a las 10:33, Oleg A. Arkhangelsky escribió:
> Package: ifupdown
> Tags: patch
> 
> Here is proposed patch.
> 
> Since the unit type is oneshot, we can have multiple ExecStart statements.
> 
> Note that we have to use '--ignore-errors'. Otherwise if we have real
> hotplug interface that is not present at the moment of restart, `ifup`
> returns non-zero and systemd unit fail.
> 
> 
> diff --git a/debian/networking.service b/debian/networking.service
> index 593172b..7ad246b 100644
> --- a/debian/networking.service
> +++ b/debian/networking.service
> @@ -16,6 +16,7 @@ WantedBy=network-online.target
>  Type=oneshot
>  EnvironmentFile=-/etc/default/networking
>  ExecStart=/sbin/ifup -a --read-environment
> +ExecStart=/sbin/ifup -a --allow=hotplug --ignore-errors --read-environment
>  ExecStop=/sbin/ifdown -a --read-environment --exclude=lo
>  RemainAfterExit=true
>  TimeoutStartSec=5min
> 

I applied the patch here:
https://salsa.debian.org/debian/ifupdown/-/merge_requests/17

Thanks,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1020902: RE: page not in the users language

[Santiago Ruano Rincón]

On Thu, 29 Sep 2022 04:01:44 +0200 (CEST) matthias.geiger1...@tutanota.de wrote:
>  Reported upstream as #91.

Hello Matthias,

Please, consider using the forwarded command to make BTS aware of the
above. Just in case, this is the syntax:
https://www.debian.org/Bugs/server-control#forwarded

(I don't have the proper URL, so I'd like to let you do it by yourself).

Cheers!

 -- Santiago


signature.asc
Description: PGP signature

Bug#1024328: IPv6 connectivity broken with 6.0.x. RAs seem to be dropped for the CDC_NCM interface

[Santiago Ruano Rincón]

Control: tags -1 + upstream patch

Hi there,

El 17/11/22 a las 17:08, Santiago R.R. escribió:
> Package: src:linux
> Version: 6.0.8-1
> Severity: important
> Tags: ipv6
> Control: Found -1 6.1~rc3-1~exp1
> 
> Dear linux maintainers,
> 
> The related machine to this bug is connected to the network via a Dell
> D6000 USB-C docking station. Since a recent linux-image-amd64 update, it
> cannot reach external networks on IPv6. It is able to autoconfigure an
> IPv6 address, but it doesn't get any answer to the router sollicitations
> messages, so it is not able to configure any default route.
> 
> A WiFi interface successfully configures its ip6 route, running on the
> same kernel.
> 
> The problem didn't exist on 5.x, since 5.9 (when IP6 multicast support
> for cdc_ncm was fixed). I've just checked with
> linux-image-5.10.0-12-amd64.
> And the problem is also present in linux-image-6.1.0-0-amd64 6.1~rc3-1~exp1.
> 
> Concerned devices is:
> 
>   *-network
>description: Ethernet interface
>physical id: 14
>bus info: usb@2:1.1
>logical name: enxabcdef123456
>serial: ab:cd:ef:12:34:56
>size: 100Mbit/s
>capabilities: ethernet physical
>configuration: autonegotiation=off broadcast=yes driver=cdc_ncm 
> driverversion=6.0.0-4-amd64 duplex=half firmware=CDC NCM (SEND ZLP) 
> ip=x.x.x.x link=yes multicast=yes port=twisted pair speed=100Mbit/s
> 
[snip]

I've tested the attached patch against debian/6.1_rc5-1_exp1, and IPv6
connectivity is restored in my machine on the DisplayLink-based Dell
D6000 dock.

For convenience, I've created a MR:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/588

Cheers,

 -- Santiago
From 308b171d568530d20ad721dfe72df697d9c0a0b6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Santiago=20Ruano=20Rinc=C3=B3n?=
 
Date: Mon, 21 Nov 2022 11:52:10 +0100
Subject: [PATCH] net/cdc_ncm: Fix multicast RX support for CDC NCM devices
 with ZLP
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

ZLP for DisplayLink ethernet devices was enabled in 6.0:
266c0190aee3 ("net/cdc_ncm: Enable ZLP for DisplayLink ethernet devices").
The related driver_info should be the "same as cdc_ncm_info, but with
FLAG_SEND_ZLP". However, set_rx_mode that enables handling multicast
traffic was missing in the new cdc_ncm_zlp_info.

usbnet_cdc_update_filter rx mode was introduced in linux 5.9 with:
e10dcb1b6ba7 ("net: cdc_ncm: hook into set_rx_mode to admit multicast
traffic")

Without this hook, multicast, and then IPv6 SLAAC, is broken.

Fixes: 266c0190aee3 ("net/cdc_ncm: Enable ZLP for DisplayLink ethernet
devices")

Signed-off-by: Santiago Ruano Rincón 
---
 drivers/net/usb/cdc_ncm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index 8d5cbda33f66..0897fdb6254b 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -1915,6 +1915,7 @@ static const struct driver_info cdc_ncm_zlp_info = {
 	.status = cdc_ncm_status,
 	.rx_fixup = cdc_ncm_rx_fixup,
 	.tx_fixup = cdc_ncm_tx_fixup,
+	.set_rx_mode = usbnet_cdc_update_filter,
 };
 
 /* Same as cdc_ncm_info, but with FLAG_WWAN */
-- 
2.38.1



signature.asc
Description: PGP signature

Bug#1024242: isc-dhcp FTCBFS: uses the build architecture compiler

[Santiago Ruano Rincón]

Control: tags -1 + pending

El 16/11/22 a las 09:25, Helmut Grohne escribió:
> Source: isc-dhcp
> Version: 4.4.3-2.1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> isc-dhcp fails to cross build from source, because it uses the build
> architecture compiler for embedded bind build. This is difficult to
> observe, because the complete build log for the bind build (including
> configure output and all compiler invocation) is hidden from the build
> log (which violates a Debian policy should). Consider making the build
> verbose by default. In any case, I'm attaching a patch to fix the
> compiler for your convenience.
> 
> Helmut

Thanks!

I can confirm this fixes the FTCBFS:
https://salsa.debian.org/santiago/isc-dhcp/-/jobs/3525647

The fix is now in git, and will be parted of the next release.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1023595: Mention End Of Life in package Description

[Santiago Ruano Rincón]

Control: tags -1 pending

El 07/11/22 a las 03:56, Dan Jacobson escribió:
> Package: isc-dhcp-client
> Version: 4.4.3-P1-1
> 
> In the package Description mention something about End Of Life.
> Yes, it's mentioned in /usr/share/doc/isc-dhcp-client,
> but it should also be mentioned in the package Description section,
> so e.g.,
> 
> $ apt show isc-dhcp-client
> ...
> Priority: important
> ...
> Description: 
> 
> will warn potential users that all is not sunny.
> 

Done in https://salsa.debian.org/debian/isc-dhcp/-/merge_requests/5

This will be part of the next release.

Thanks,

 -- S


signature.asc
Description: PGP signature

Bug#1010807: isc-dhcp: ftbfs on riscv64 arch

[Santiago Ruano Rincón]

Control: forwarded -1 https://gitlab.isc.org/isc-projects/dhcp/-/issues/256


signature.asc
Description: PGP signature

Bug#998088: Same issue when moving from kernel 5.17 to 5.18

[Santiago Ruano Rincón]

El 22/10/22 a las 15:56, Paul Leiber escribió:
> On Wed, 29 Jun 2022 15:03:31 +0200 =?UTF-8?B?RnLDqWTDqXJpYyBNQVNTT1Q=?=
>  wrote:
> > Hi,
> >
> > I have a local server that uses Debian testing. I updated the server, it
> > went from a kernel 5.17 to 5.18. After the reboot, the network was no
> > longer active. The network interfaces were down.
> >
> > In the logs I had these error messages:
> >
> > systemd-udevd[396]: :01:00.0: Worker [425] processing SEQNUM=2140 is
> > taking a long time
> > systemd[1]: systemd-udev-settle.service: Main process exited,
> > code=exited, status=1/FAILURE
> > systemd[1]: systemd-udev-settle.service: Failed with result 'exit-code'.
> > systemd[1]: Failed to start Wait for udev To Complete Device
> Initialization.
> > systemd[1]: systemd-udev-settle.service: Consumed 4.055s CPU time.
> > [...]
> > systemd[1]: ifupdown-pre.service: Main process exited, code=exited,
> > status=1/FAILURE
> > systemd[1]: ifupdown-pre.service: Failed with result 'exit-code'.
> > systemd[1]: Failed to start Helper to synchronize boot up for ifupdown.
> > systemd[1]: Dependency failed for Raise network interfaces.
> > systemd[1]: networking.service: Job networking.service/start failed with
> > result 'dependency'.
> > ithaqua systemd[1]: ifupdown-pre.service: Consumed 3.807s CPU time.
> >
> >
> > I found this bug report and replaced the line
> > "Requires=ifupdown-pre.service" with "Wants=ifupdown-pre.service" in
> > "/lib/systemd/system/networking.service".
> >
> > During boot there is a delay, but the network interfaces were up and the
> > network is active.
> >
> >
> > Regards.
> > --
> > ==
> > | FRÉDÉRIC MASSOT |
> > | http://www.juliana-multimedia.com |
> > | mailto:frede...@juliana-multimedia.com |
> > | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 |
> > ===Debian=GNU/Linux===
> >
> >
> 
> I have the same issue as described by Frédéric in an up-to-date Debian
> Bullseye 11.5, kernel 5.10.0-19-amd64. Manually starting the network via
> ifconfig works. The workaround described by Ron mitigates the error.
> However, the delay during boot exists also in my system.
> 
> Paul
> 

Sorry for the delay to answer on this.

For the moment, it seems replacing the dependency for Wants seems to be
the more suitable solution. Also, from systemd.unit(5):

Wants= … This is the recommended way to hook the start-up of one
unit to the start-up of another unit.

Requires= … Often, it is a better choice to use Wants= instead of
Requires= in order to achieve a system that is more robust when
dealing with failing services.

Happy to learn if there would be a better fix.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1023409: nagios-plugins-contrib: fix stray backslashes in check_ssl_cert

[Santiago Ruano Rincón]

Source: nagios-plugins-contrib
Version: 37.20211217
Severity: important
Tags: patch
User: g...@packages.debian.org
Usertags: stray-backslash
Control: block 1022828 by -1

Dear nagios-plugins-contrib maintainer,

nagios-plugins-contrib's check_ssl_cert contains stray backslashes that trigger
warnings from grep 3.8, causing autopkgtest to fail:
https://ci.debian.net/data/autopkgtest/unstable/amd64/n/nagios-plugins-contrib/26117196/log.gz

For convenience, the warning has been temporarily disabled with 3.8-3 by
default. It can be enabled by setting DEB_GREP_ENABLE_STRAY_BACKSLASH_WARN.
This workaround will be reverted in a next release. Also, Severity: important
since grep upstream will make these kind of warnings become errors in the
future.

https://salsa.debian.org/nagios-team/pkg-nagios-plugins-contrib/-/merge_requests/7
 should fix this.

Cheers,

 -- Santiago

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

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


signature.asc
Description: PGP signature

Bug#1022971: xautolock: Remove stray backlash in debian/tests/help

[Santiago Ruano Rincón]

Source: xautolock
Version: 1:2.2-7
Severity: normal
Tags: patch
User: g...@packages.debian.org
Usertags: stray-backslash
Control: block 1022828 by -1

Dear xautolock maintainer,

xautolock's debian/tests/version contains a stray backslash that triggers a
warning from grep 3.8, causing this autopkgtest to fail:
https://ci.debian.net/data/autopkgtest/unstable/amd64/x/xautolock/26130620/log.gz

For convenience, the warning has been temporarily disabled with 3.8-3 by
default. It can be enabled by setting DEB_GREP_ENABLE_STRAY_BACKSLASH_WARN.
This workaround will be reverted in the future.

https://salsa.debian.org/friki/xautolock/-/merge_requests/3 should fix this.

Cheers,

 -- Santiago

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

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


signature.asc
Description: PGP signature

Bug#1022828: grep: Remove patch than disables stray backslash warnings

[Santiago Ruano Rincón]

Control: block -1 by 1019725 1019326


signature.asc
Description: PGP signature