Bug#1072619: apt-get full-download

[Julian Andres Klode]

On Wed, Jun 05, 2024 at 09:46:59AM +0200, Harald Dunkel wrote:
> Package: apt
> Version: 2.6.1
> Severity: wishlist
> 
> For managing a private, limited clone of bookworm backports I am
> looking for an easy way to download *all* binary packages for a given
> source package, version and architecture from a single repository.
> Some one-liner like
> 
> apt-get full-download -a amd64,all linux=6.7.12+1~bpo12+1
> 
> The workarounds you can find at various sites based upon parsing the
> output of apt-cache showsrc are misleading and buggy. apt-get should
> do better in this case.

This doesn't work if you have binaries with different versions but
otherwise,

'?any-version(?source-package(^apt$)?source-version(^2.9.3$)?architecture(amd64))'=2.9.3

works fine to download amd64 and all binaries (note that all gets mapped
to the native architecture).

The problem is the patter nobject is matching against packages here,
so we need to specify the version again in =. 
if we made download match it against versions it would just
automagically work, but we can't do that by default. Maybe we need
special syntax for it, or a command-line option.

But there's some more issues because I believe the parsing for
command-line arguments runs at a point where it can only communicate
packages not versions.

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

Bug#1071744: apt: search '?installed ?not(?automatic)' causes regex compilation error

[Julian Andres Klode]

Control: retitle -1 search does not support patterns

On Sat, May 25, 2024 at 12:50:53AM +1000, Konomi wrote:
> Package: apt
> Version: 2.9.3
> Severity: normal
> X-Debbugs-Cc: konomikit...@gmail.com
> 
> Dear Maintainer,
> 
> Running `apt search '?installed ?not(?automatic)'` results in the
> following message: "Error: Regex compilation error". Using the same search
> terms in aptitude `aptitude search '?installed ?not(?automatic)'` works
> as expected.

Yes this is well known, the apt search command specifically can only
do text search, you are looking for the apt list command.

There's some limitations to actually allow search to take patterns,
as it currently builds a regular expression vector and then runs them
over the descriptions, hence why there's no patterns yet.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1071519: apt: "--solver 3.0" does not want to upgrade some packages

[Julian Andres Klode]

Control: retitle -1 --solver 3.0 fails to select candidate for -t, --mark-auto 
request

On Mon, May 20, 2024 at 02:37:29PM +0200, Gábor Gombás wrote:
> Package: apt
> Version: 2.9.3
> Severity: normal
> 
> Hi,
> 
> Well, it's alpha, but still - using "--solver 3.0", I cannot upgrade some 
> packages to the version in sid:
> 
> # apt policy iproute2
> iproute2:
>   Installed: 6.8.0-1
>   Candidate: 6.8.0-1
>   Version table:
>  6.9.0-1 102
> 102 http://ftp.hu.debian.org/debian sid/main amd64 Packages
> 102 http://ftp.at.debian.org/debian sid/main amd64 Packages
>  *** 6.8.0-1 103
> 103 http://ftp.hu.debian.org/debian trixie/main amd64 Packages
> 103 http://ftp.at.debian.org/debian trixie/main amd64 Packages
> 100 /var/lib/dpkg/status
>  6.1.0-3 990
> 990 http://ftp.hu.debian.org/debian bookworm/main amd64 Packages
> 990 http://ftp.at.debian.org/debian bookworm/main amd64 Packages
> # apt install -t unstable --mark-auto --solver 3.0 iproute2
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 56
> 
> Without "--solver 3.0", it works:
> 
> # apt install -t unstable --mark-auto iproute2
> Upgrading:  
>   iproute2
> 
> Summary:
>   Upgrading: 1, Installing: 0, Removing: 0, Not Upgrading: 55
>   Download size: 1,064 kB
>   Space needed: 4,096 B / 99.1 GB available
> 
> Get:1 http://ftp.hu.debian.org/debian sid/main amd64 iproute2 amd64 6.9.0-1 
> [1,064 kB]
> Fetched 1,064 kB in 0s (15.7 MB/s) 
> Reading changelogs... Done
> apt-listchanges: Do you want to continue? [Y/n] n
> apt-listchanges: Aborting

It's not quite clear to me what goes on there, but this may get lost in
translation between the old solver and the new one.

If you can do so, please use -o Dir::Log::Solver=
to specify a file to dump the solver request to, and then compress and
attach it to the bug report (it might need --solver internal if you
default to 3.0, I need to check and eventually fix solver logging for
3.0 still).

It is possible that this is one of the weird cases where it would crash
with -o Debug::APT::Solver=1 (as that enables more assertions). I'm
currently in the process of getting the test suite to work, adjusting
the tests that can work in the first step, to then have a solid base to
check for regressions when making further changes.

It could also be that the reason is the --mark-auto. This marks the
request to install that specific version as automatic presumably, and
you are in an install request, so the solver will first try to satsify
dependencies, where it will see the installed iproute2 as the preferred
option (since it's not upgrading, it minimizes upgrades), and then later
it will try to install the chosen iproute2 but it's not possible anymore
so it backtracks a level and just skips the request since it is
optional. I think this can be fixed however, that's a problem of
translating the selection state to the solver problem (i.e. this package
is marked auto now; but we actually have requested it manually so it
should be executed).

It also turns out we sometimes lose unsatisfiable items when
backtracking. We did not lose the item here presumably, otherwise
iproute2 would have been removed, but not sure.

In any case, attaching an EDSP file is best so we can reproduce it;
running with -o Debug::APT::Solver={1,2,3} (depending on how much output is
needed) could also give you a good insight to the point you can just
tell me.

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

Bug#1071219: apt: debListParser fails to parse arch lists with extraneous whitespace: terminate called after throwing an instance of 'std::length_error'

[Julian Andres Klode]

Control: severity -1 normal

On Thu, May 16, 2024 at 02:11:41PM +0200, Andreas Beckmann wrote:
> Package: apt
> Version: 2.9.2
> Severity: serious
> 
> one package to reproduce this bug is mpich 4.2.0-5.1
> 
> mpich-4.2.0# apt-get build-dep -y .
> Note, using directory '.' to get the build dependencies
> terminate called after throwing an instance of 'std::length_error'
>   what():  basic_string::_M_create
> Aborted (core dumped)
> 
> Running this through gdb and extracting the interesting part of the
> backtrace:
> 
> #11 0x77e28c6c in std::__cxx11::basic_string std::char_traits, std::allocator >::basic_string void> (__a=...,
> __end=0x555baade " amd64 powerpc armhf],\n"...,
> __beg=0x555baadf "amd64 powerpc armhf],\n"..., this=0x7fffd670) 
> at /usr/include/c++/13/bits/basic_string.h:765
> #12 debListParser::ParseDepends (Start=,
> Start@entry=0x555baabb "valgrind [i386 arm64 ppc64el ppc64  amd64 
> powerpc armhf],\n"...,
> Stop=Stop@entry=0x555bab15 "\nBuild-Conflicts: libamdhip64-dev\n"..., 
> Package=..., Ver=..., Op=@0x7fffd930: 0, ParseArchFlags=, 
> StripMultiArch=, ParseRestrictionsList=, 
> Arch=...) at ./apt-pkg/deb/deblistparser.cc:667
> 
> Note the double space in ..."ppc64  amd64"...
> It tries to create a std::string with __end < __beg resulting in a
> negative (or insane) length.

Don't do that then. I mean it is failing safely, this is highly
unusual so it's not a critical bug in any sort of shape for apt
(but sure for packages actually doing that in the archive since
they don't build correctly or whatever).

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

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Julian Andres Klode]

Control: severity -1 important
Control: user release.debian@packages.debian.org
Control: usertags -1 time-t-downgrade

On Thu, Mar 07, 2024 at 04:00:35PM +0100, Vincent Lefevre wrote:
> Package: libmtp9t64
> Version: 1.1.21-3.1
> Severity: serious
> 
> During an upgrade with aptitude:
> 
> dpkg: dependency problems prevent removal of libmtp-common:
>  libmtp9t64:amd64 depends on libmtp-common.
>  libmtp-runtime depends on libmtp-common.
> 
> dpkg: error processing package libmtp-common (--purge):
>  dependency problems - not removing
> Errors were encountered while processing:
>  libmtp-common
> 
> Note that "apt install -f" has nothing to fix; this upgrade just
> triggered a dpkg error (similar to bug 1065603).
> 
> Moreover, like in bug 1065603, aptitude did not propose the removal
> of libmtp-common:
> 
> Aptitude 0.8.13: log report
> Thu, Mar  7 2024 15:49:03 +0100
> 
>   IMPORTANT: this log only lists intended actions; actions which fail
>   due to dpkg problems may not be completed.
> 
> Will install 11 packages, and remove 3 packages.
> 8192 B of disk space will be used
> 
> [...]
> [HOLD, DEPENDENCIES] libmtp-common:amd64 1.1.21-3
> [...]
> [INSTALL, DEPENDENCIES] libgphoto2-6t64:amd64 2.5.31-2.1
> [INSTALL, DEPENDENCIES] libgphoto2-port12t64:amd64 2.5.31-2.1
> [INSTALL, DEPENDENCIES] libmtp9t64:amd64 1.1.21-3.1
> [REMOVE, DEPENDENCIES] libgphoto2-6:amd64 2.5.31-2
> [REMOVE, DEPENDENCIES] libgphoto2-port12:amd64 2.5.31-2
> [REMOVE, DEPENDENCIES] libmtp9:amd64 1.1.21-3
> [...]
> [UPGRADE] gvfs:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-backends:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-common:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-daemons:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-fuse:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-libs:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] libgphoto2-l10n:amd64 2.5.31-2 -> 2.5.31-2.1
> [UPGRADE] libmtp-runtime:amd64 1.1.21-3 -> 1.1.21-3.1
> 

This bug has since been reassigned to aptitude. Solver limitations
in aptitude wrt t64 handling should not be considered release critical,
it makes no sense to remove aptitude from testing for it; there are
still plenty of other valid use cases that are unaffected by these
particular bugs, so I am downgrading it to important.

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

Bug#1069844: More debug info

[Julian Andres Klode]

On Thu, Apr 25, 2024 at 09:10:08PM +0100, Alex Bennée wrote:
> Alex Bennée  writes:
> 
> > Julian Andres Klode  writes:
> >
> >> On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
> >>> 
> >>> Continuing to debug on QEMU it seems there is an incompatibility with
> >>> the images and the peloader (which overrides the normal efi loader):
> >>> 
> 
> >
> >> In the error case you can see though, that one of the section
> >> addresses in the Xen binary to be relocated points into the (PE)
> >> header of the binary, which obviously seems wrong.
> >>
> >> So go check your PE sections and check which one is wrong?
> >
> > Is there any tooling for examining PE sections?
> 
> Nothing really jumps out from objdump:
> 
> 1:08:50 [root@debian-arm64:~] # objdump -h /boot/xen
> 
>   /boot/xen: file format pei-aarch64-little
> 
>   Sections:
>   Idx Name  Size  VMA   LMA   File off  
> Algn
> 0 .reloc        
> 2**0
> ALLOC, LOAD, READONLY, DATA


This looks suspicious. Yes it's 0 size but it's address is 0 which
clearly points into the header, and we don't skip 0 size sections when
loading the PE binary for later relocation, and we don't use any .reloc
section.


> 1 .text 00107ea8  0160  0160  0160  
> 2**4
> CONTENTS, ALLOC, LOAD, CODE
>   21:08:53 [root@debian-arm64:~] # objdump -h /boot/vmlinuz


I suppose the header is smaller than 0x160 bytes and this is ok.

My colleague Heinrich has written a nice PE analyser tool too:

https://github.com/xypron/efi_analyzer


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

Bug#1069844: More debug info

[Julian Andres Klode]

On Thu, Apr 25, 2024 at 06:30:52PM +0100, Alex Bennée wrote:
> 
> Continuing to debug on QEMU it seems there is an incompatibility with
> the images and the peloader (which overrides the normal efi loader):
> 
>   Thread 1 hit Breakpoint 3.2, grub_load_normal_mode () at 
> ../../../grub-core/kern/main.c:241
>   241 in ../../../grub-core/kern/main.c   
>   
>
>   (grub gdb) hbreak do_load_image 
>   
>
>   Hardware assisted breakpoint 4 at 0x23bdf0e00: do_load_image. (2 locations) 
>   
>
>   (grub gdb) c
>   
>
>   Continuing. 
>   
>
>   add symbol table from file "bli.module" at  
>   
>
>   .text_addr = 0x23ba772e0
>   
>
>   .bss_addr = 0x0 
>   
>
>   .module_license_addr = 0x23ba7764a 
>   .data_addr = 0x0
>   
>
>   .rodata.str1.1_addr = 0x23ba77560   
>   
>
>   .rodata_addr = 0x23ba77550  
>   
>
>   add symbol table from file "xen_boot.module" at 
>   
>
>   .text_addr = 0x23bcef3c0
>   
>
>   .bss_addr = 0x23bcf0370 
>   
>
>   .module_license_addr = 0x23bcf035e  
>   
>   .data_addr = 0x0
>   
>   .rodata.str1.1_addr = 0x23bcefff8
> 
>   Thread 1 hit Breakpoint 4.1, do_load_image (boot_policy=0 '\000', 
> parent_image_handle=0x23e889f18, file_path=0x237d1bce0, 
> source_buffer=0x239f0, source_size=1081352, 
>   image_handle=0x4766c498) at ../../../grub-core/loader/efi/peimage.c:745
>   warning: 745../../../grub-core/loader/efi/peimage.c: No such file or 
> directory
>   (grub gdb) hbreak grub_error
>   Hardware assisted breakpoint 5 at 0x6db0: grub_error. (2 locations)
>   (grub gdb) c
>   Continuing.
> 
>   Thread 1 hit Breakpoint 4.2, 0x00023bdf0e4c in do_load_image 
> (boot_policy=, parent_image_handle=, 
> image_handle=, 
>   source_size=, source_buffer=, 
> file_path=) at ../../../grub-core/loader/efi/peimage.c:751
>   751 in ../../../grub-core/loader/efi/peimage.c
>   (grub gdb) c
>   Continuing.
> 
>   Thread 1 hit Breakpoint 5.2, grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bdf1703 
> "section inside header") at ../../../grub-core/kern/err.c:41
>   warning: 41 ../../../grub-core/kern/err.c: No such file or directory
>   (grub gdb) bt
>   #0  grub_error (n=GRUB_ERR_BAD_OS, fmt=0x23bdf1703 "section inside header") 
> at ../../../grub-core/kern/err.c:41
>   #1  0x00023bdf0e34 in do_load_image (boot_policy=, 
> parent_image_handle=, file_path=, 
> source_buffer=, 
>   source_size=, image_handle=) at 
> ../../../grub-core/loader/efi/peimage.c:747
>   #2  0x00023bedabdc in grub_arch_efi_linux_boot_image (addr=9561964544, 
> size=1081352, 
>   args=0x23bbb8b00 "placeholder dom0_mem=4G,max:4G loglvl=all 
> guest_loglvl=all no-real-mode edd=off") at 
> ../../../grub-core/loader/efi/linux.c:210
>   #3  0x00023bff41bc in grub_loader_boot () at 
> ../../../grub-core/commands/boot.c:211
>   #4  grub_loader_boot () at ../../../grub-core/commands/boot.c:190
>   #5  

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[Julian Andres Klode]

Control: severity -1 important

Control: user release.debian@packages.debian.org
Control: usertags -1 time-t-downgrade

On Thu, Mar 07, 2024 at 04:10:17PM +0100, Vincent Lefevre wrote:
> Package: libgtk2.0-0t64
> Version: 2.24.33-4
> Severity: serious
> 
> During an upgrade with aptitude:
> 
> dpkg: dependency problems prevent removal of libgtk2.0-common:
>  libgtk2.0-bin depends on libgtk2.0-common.
>  libgtk2.0-0t64:amd64 depends on libgtk2.0-common.
> 
> dpkg: error processing package libgtk2.0-common (--purge):
>  dependency problems - not removing
> Errors were encountered while processing:
>  libgtk2.0-common
> 
> Note that "apt install -f" has nothing to fix; this upgrade just
> triggered a dpkg error (similar to bugs 1065603 and 1065625).
> 
> Moreover, like in these bugs, aptitude did not propose the removal
> of libgtk2.0-common:
> 
> Aptitude 0.8.13: log report
> Thu, Mar  7 2024 16:01:36 +0100
> 
>   IMPORTANT: this log only lists intended actions; actions which fail
>   due to dpkg problems may not be completed.
> 
> Will install 5 packages, and remove 2 packages.
> 2048 B of disk space will be used
> 
> [...]
> [HOLD, DEPENDENCIES] libgtk2.0-common:amd64 2.24.33-3
> [...]
> [INSTALL, DEPENDENCIES] libgail18t64:amd64 2.24.33-4
> [INSTALL, DEPENDENCIES] libgtk2.0-0t64:amd64 2.24.33-4
> [REMOVE, DEPENDENCIES] libgail18:amd64 2.24.33-3
> [REMOVE, DEPENDENCIES] libgtk2.0-0:amd64 2.24.33-3
> [...]
> [UPGRADE] gtk2-engines-pixbuf:amd64 2.24.33-3 -> 2.24.33-4
> [UPGRADE] libgail-common:amd64 2.24.33-3 -> 2.24.33-4
> [UPGRADE] libgtk2.0-bin:amd64 2.24.33-3 -> 2.24.33-4
> 


Downgrading this bug to important as it is currently a blocker
for aptitude migration due to the dual assignment, and even for
libgtk2.0-0t64, I'd argue getting it migrated is more important
than a aptitude ordering issue.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

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

[Julian Andres Klode]

On Mon, Apr 22, 2024 at 07:41:42PM +0200, Dominique Dumont wrote:
> On Sunday, 21 April 2024 18:07:00 CEST Julian Andres Klode wrote:
> > This should be fixed in apt git already, just needs an upload,
> > which is waiting-ish for some more merges
> 
> Given [1], I need to ask... 
> 
> Is this a definitive fix or will this feature come back with apt 3.0 ?

The feature remains available in output version 3.0 which is what
apt(8) is defaulting to right now. apt-get remains at output version
0 at least until 4.0.

This should be fixed in apt side on 2.9.2 I just uploaded, but
either way it's a weird thing to break because we change progress
messages for interactive output, maybe run with -q instead or don't
pretend to be a tty.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

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

[Julian Andres Klode]

On Sun, Apr 21, 2024 at 04:32:48PM +0300, Niko Tyni wrote:
> [Copying Julian as the apt maintainer.]
> 
> On Sat, Apr 20, 2024 at 09:02:35PM +0300, Niko Tyni wrote:
> > On Sat, Apr 20, 2024 at 11:09:17AM +0200, Dominique Dumont wrote:
> > > On Thursday, 18 April 2024 19:21:55 CEST you wrote:
> > > > Source: libconfig-model-dpkg-perl
> > > > Version: 3.004
> > > > Severity: serious
> > > > Tags: ftbfs
> > > > Justification: fails to build from source
> > > 
> > > This really looks like a bug with prove:
> > > 
> > > $ perl t/reorder.t 
> > > ok 1 -  test re-ordered list
> > > 1..1
> > 
> > > I can't see what's wrong with the output of reorder test...
> > 
> > Looks like something is injecting apt progress messages to stdout with
> > CR characters hiding it on the terminal but obviously not from `prove`.
> > 
> > $ perl t/reorder.t |od -c
> 
> > 460   f   o   r   m   a   t   i   o   n   .   .   .   0   %  \r
> > 500
> > *
> > 540  \r   o   k   1   -   t   e   s   t   r   e
> > 560   -   o   r   d   e   r   e   d   l   i   s   t  \n   1   .
> > 600   .   1  \n
> 
> These come from apt, via libapt-pkg-perl which I don't think has ever
> filtered them away. The thing that broke this is surely output changes
> in apt 2.9.
> 
> The crucial difference wrt. at least bookworm seems to be that the
> apt messages used to end with a line feed "\n" before the actual TAP
> format started.  Now it only has a carriage return "\r" there. Apparently
> `prove` ignores unknown lines, but now interprets all the apt output to
> be part of the first line that ends with the 'ok 1' part. So that gets
> ignored as well.
> 
> I see the TAP format spec says at
> 
>   https://testanything.org/tap-version-14-specification.html
> 
>   A Harness should normalize line endings by replacing any instances of
>   \r\n or \r in the TAP document with \n.
> 
> so I suppose this might be a normal/wishlist bug in `prove`. In that case,
> please note that it needs to be fixed in libtest-harness-perl first as
> src:perl just bundles an older version of it.
> 
> Not sure if apt should go back to ending its output with a line
> feed. Julian, what do you think?
> -- 
> Niko

This should be fixed in apt git already, just needs an upload,
which is waiting-ish for some more merges
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1069275: apt: random display of the "Summary:" line

[Julian Andres Klode]

On Fri, Apr 19, 2024 at 10:06:31AM +0200, Antonio wrote:
> Package: apt
> Version: 2.9.1
> Severity: minor
> X-Debbugs-Cc: antde...@gmail.com
> 
> Dear Maintainer,
> I report a minor bug on apt that I sometimes get by running the commands
> below
> in sequence.
> 
> Note that in the last commands the "Summary:" line is not displayed whereas
> previously, with the same commands, it was displayed.
> 
> I tried this sequence as root; as a user I see that the word "Summary" never
> appears.
> 
> Seems to be a random problem.

Thank you for your bug report,

looking at your output, everything seems to be in order:

All your apt(8) executions use the apt(8) modern interface,
and all your apt-get(8) executions use the classic interface
- as they should for backwards-compatibility.

Is it possible your muscle memory is playing tricks on you, making
you type sudo apt-get whereas you use apt as a user?

But maybe I missed it, so do double check.

Have a nice day!

> 
> -- SEQUENCE --
> 
> $ apt autoremove
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ apt autoremove --purge
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ sudo apt autoremove --purge
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ (sudo apt autoremove --purge)
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0


These are all apt(8) with the modern interface.

> 
> $ gawk '{print}'< <(sudo apt-get autoremove; sudo apt-get clean; sudo
> apt-get
> autoclean; sudo apt-get -f install; sudo apt-get check)
> Lettura elenco dei pacchetti...
> Generazione albero delle dipendenze...
> Lettura informazioni sullo stato...
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> Lettura elenco dei pacchetti...
> Generazione albero delle dipendenze...
> Lettura informazioni sullo stato...
> Lettura elenco dei pacchetti...
> Generazione albero delle dipendenze...
> Lettura informazioni sullo stato...
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> Lettura elenco dei pacchetti...
> Generazione albero delle dipendenze...
> Lettura informazioni sullo stato...

These are all apt-get(8) with the classic interface.

> 
> $ apt autoremove
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ apt autoremove --purge
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
> 
> $ (sudo apt autoremove --purge)
> Summary:
>   Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

These are all apt(8) and all have the summary line.

> 
> $ sudo apt-get autoremove; sudo apt-get clean; sudo apt-get autoclean; sudo
> apt-get -f install; sudo apt-get check
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ sudo apt-get autoremove
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ sudo apt-get autoremove
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ sudo apt-get autoremove --purge
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ sudo apt-get autoremove --purge
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ apt-get autoremove
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.
> 
> $ apt-get autoremove --purge
> 0 aggiornati, 0 installati, 0 da rimuovere e 0 non aggiornati.

These are all apt-get(8) which uses the classic interface.

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

Bug#1068825: apt: possible super minor security issue in apt-get source

[Julian Andres Klode]

On Thu, Apr 11, 2024 at 05:52:47PM +0200, Christoph Anton Mitterer wrote:
> Package: apt
> Version: 2.7.14
> Severity: normal
> Tags: security
> 
> 
> Hey.
> 
> I noted the following behaviour - which may or may not be regarded as
> security relevant.
> So this is rather a heads up, and in case you think it's fine as it is,
> just close it.
> 
> I always remembered that apt-get source was ought to verify hashes of
> the downloaded files (i.e. secure APT as signed by the repo).
> 
> Likewise, I thought to remember that at least at one point in time,
> downloads of binary packages (via e.g. apt-get download or aptitude
> download) were NOT verified.
> Because of that I never trusted these which was quite unhandy.
> 
> So I though I'd simply test that (using a local package repo and simply
> changing one byte of the files to download), and turns out that apt-get
> download DOES also verify the binary packages and exit with non-zero
> status of the don't match.
> Nice.
> 
> 
> So just to be sure I did the same with the source package files.
> And here I noted some things:
> - It does check freshly downloaded files and exit with non-zero in case
>   their hashes mismatch.
> - But it does so as well, with *already* downloaded files, and if they
>   don't match it silently downloads (also verified) fresh files.
>   => First, I'm not sure whether this is the right behaviour, as the
>  "original/modified" file seems to get removed, but it - being a
>  local file - may actually be something of value to the user.
>  So maybe it should just move the file to foo.FAILED and error
>  with non-zero exit status?
> 
> 
> Then I made some particular tries:
> a) On a previously (valid) downloaded source package I modified a byte
>in the local .dsc and modified a byte in the remote .orig.tar.xz.
>apt again notcies the valid local .orig.tar.xz and does nothing and
>notices the invalid local .dsc and re-downloads it (which succeeds
>as I haven't mangled the remote .dsc).
> 
>In principle I'd say this is fine, and there's no direct security
>issue ... and probably not even an indirect one.
>What does however happen - due to the skipped download of the already
>present+valid files - is that the remote corruption of he .orig.tar.xz
>isn't notice.
> 
>I'd say, not an issue, but nevertheless wanted to give a heads up.
> 
> 
> b) What may now be the “super minor security issue” is the following:
>apt *does* check already downloaded files for validity and exits
>with zero if they match, right?
> 
>So conceptuall one could have gone two ways:
>- anything local is already trusted because it was verified before
>  or the user somehow manually brought it to the system and should
>  know what he's doing
>- `apt-get source` acts also like a checker and if the exit status is
>  one can assume that the files present are valid
> 
>It seems to be the 2nd, given that it verifies the local files.
> 
>It does however NOT again verify any already unpacked tree.
> 
>So in some super obscure scenarios, a user could come to assume that
>exit status zero means that all the stuff is verified, while in fact
>only the non unpacked files are.
> 
>Again of course, for an attack, there would need to be some way to
>introduce a modified unpacked tree, where one could say that if an
>attacker can do that, it's anyway already too late.
> 
>But simply from that conceptual PoV, it seems to me as if that
>behaviour is unfortunate.
> 
>I do however have no idea for a better behaviour.
>Checking would anyway mean that we need to unpack it - therefore
>wasting further resources.
>And the tree may differ simply because of user modifications, what
>then? Move the dir to xx.NON-PRISTINE?

I think I'm fine just exiting 1 if the directory already exists,
after doing the download dance.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1068698: hdf-eos5 2:2.0-2 silently reverts the 64-bit time_t transition

[Julian Andres Klode]

Source: hdf-eos5
Severity: serious
X-Debbugs-Cc: j...@debian.org

hdf-eos5 2:2.0-2 ignores the hdf-eos5 2:2.0-1.1 NMU that introduced the
time_t renames (that was Bug##1063118), causing misbuilt libhe5-hdfeos0
with the new ABI, potentially breaking applications built against it.

-- System Information:
Debian Release: trixie/sid
  APT prefers noble-updates
  APT policy: (500, 'noble-updates'), (500, 'noble'), (500, 'mantic-security'), 
(100, 'noble-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

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

Bug#1068637: apt does not always install Recommends

[Julian Andres Klode]

Control: severity -1 wishlist

On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote:
> Package: apt
> Version: 2.7.14
> Severity: serious
> 
> The lvm2 package is installed, but not thin-provisioning-tools,
> though lvm2 recommends it. This can yield a broken system:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142
> 
> the fix of this bug being
> 
>* Make lvm2 recommend thin-provisioning-tools. (closes: #857142)

That's a packaging bug. If the tool is mandatory for correct behavior
of the system it should be a Depends.

Now back to the topic, this is not a release critical bug in APT. APT
installs any Recommends with easily satisfiable dependencies. Recommends
will get broken easily if there's large scale dependency issues like
now.

This works out well if you Recommend an Architecture: all package and
it Depends on packages that are not available on all architectures -
it is just being skipped on those.

In this particular instance you're getting bit by time_t transition
issues and Recommends disappear on you (even if they may be satisfiable
it may simply be easier to break the Recommends for apt than to figure
out the right solution).

However I do agree with you and I've already set this a couple of times
before that I want to move away from treating Recommends as optional
dependencies that we want to satisfy as many of as we can.

My proposal is quite simple:

 Recommends that point to an existing real package are promoted to
 Depends, except that you may remove them by explicit action (remove
 them after install, mark them for removal before installing, or if
 it is unsatisfied in the installed package it remains unsatisfied).

 This applies to the entire or group. If you Recommends: real | virtual,
 the recommends may also be satisfied by the virtual package.

I do not know what the behavior should be for Recommends exclusively
n virtual packages, I feel like promoting them could have unforeseen
issues, people think less about them than real packages.

Ultimately this may be a bit challenging to implement but I didn't
actually get around to looking at it yet, and it certainly will take
some time to sort out the uninstallabilities this introduces in the
archive especially on niche architectures where Architecture: all
packages are Recommended but not installable.

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

Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed

[Julian Andres Klode]

Control: reassign -1 grub-efi-amd64-signed
Control: fixed -1 1+2.12+1+b1
Control: close -1

On Sun, Mar 24, 2024 at 06:23:56PM +0100, Eduard Bloch wrote:
> reopen 1067486
> reassign 1067486 apt
> severity 1067486 normal
> thanks

This is stupid, you should know better.

> 
> Am Fri, Mar 22, 2024 at 11:46:02PM +0100 schrieb Julian Andres Klode:
> 
> > > Please upload a new version so grub-efi-amd64-signed can be installable.
> > > Thanks!
> > 
> > I'm getting a bit tired of this. This is normal, the packages are
> > automatically generated but need to be approved by ftpteam. 
> 
> This might be a normal condition but a) this is not transparent to user,
> and b) it really does break apt's operation, at least partly.
> 
> For a) maybe we should make this somehow auto-checked remotely and shown
> in reportbug? Or would you have a better idea?
> 
> And for b) all "dist-upgrade" or "full-upgrade" failed suddenly. Yes,
> failing, user getting completely locked out. And "upgrade" operation
> installed just a fraction of the potential candidates (there were more
> reasons for that but the lack of dist-upgrade feature is still PITA).
> And the reason has not been obvious, and even debugging with
> -oDebug::pkgProblemResolver=true is NO FUN on bigger upgrades.
> 
> And the eventual solution was close examination, and some
> guessing/observing that apt is confused and jumps between amd64 and
> i386, and then some FORCE magic, i.e.
> 
> dpkg --remove --force-depends grub-common:i386
> 
> (don't ask me how this package got installed before, that system
> installation has been migrated a lot). Another candidate was an old
> iproute:i386 package which I also had to remove.


These kinds of issues will be resolved eventually on grubs side, but
that aside, if you want to run unstable, you gotta learn to live with
these kind of situations and you gotta know what is a bug and what is
not. Seemingly you don't know how to deal with unstable, because you
should know that this is not a bug in apt.

This was a conscious decision by the release team to not have an
unstable-proposed and gate unstable by installability (and testing),
and we gotta live with it.

Users should be running testing, not unstable. We do not provide any
guarantees that dependencies can be resolved or that a dist-upgrade
won't remove your entire system for unstable. You should not use it.

The unsolicited backport to bookworm was worse because people trying
to install that also ended up with breakage, sadly there is no migration
for backports, there should be a bookworm-backports-proposed and a
britney. Again this is a process issue that you are welcome to raise
with the ftp team, release team, and backports team.

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

Bug#1067609: gbrainy: Avoid hardcoded libcanberra-gtk3-0 build-depends, use libcanberra-gtk3-dev

[Julian Andres Klode]

Package: gbrainy
Version: 1:2.4.6-1
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch


*** /tmp/tmpxuguf7sd/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Replace libcanberra-gtk3-0 build-depends with libcanberra-gtk3-dev to
pick up the latest libcanberra-gtk3 soname.

Otherwise it fails to build with libcanberra-gtk3-0-t64

Thanks for considering the patch.

*** /tmp/tmpxuguf7sd/gbrainy_1:2.4.6-1ubuntu1.debdiff
diff -Nru gbrainy-2.4.6/debian/control.in gbrainy-2.4.6/debian/control.in
--- gbrainy-2.4.6/debian/control.in 2024-03-19 07:10:14.0 +0100
+++ gbrainy-2.4.6/debian/control.in 2024-03-24 16:50:00.0 +0100
@@ -12,7 +11,7 @@
  dh-sequence-gnome,
  intltool (>= 0.35),
  itstool,
- libcanberra-gtk3-0,
+ libcanberra-gtk3-dev,
  libgtk3.0-cil-dev,
  librsvg2-dev,
  yelp-tools


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

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

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

Bug#1067570: freeipa: [time_t] Replace hardcoded librpm9 depends

[Julian Andres Klode]

Package: freeipa
Version: 4.10.2-2
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch


*** /tmp/tmpy02tel37/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Replace hardcoded librpm9 depends

This is librpm9t64 now, and this makes the package binNMUable (well
don't know if Arch: all is binNMUable, anyway, this is better than
hardcoding)

Thanks for considering the patch.

*** /tmp/tmpy02tel37/freeipa_4.10.2-2ubuntu1.debdiff
diff -Nru freeipa-4.10.2/debian/control freeipa-4.10.2/debian/control
--- freeipa-4.10.2/debian/control   2024-03-04 18:55:50.0 +0100
+++ freeipa-4.10.2/debian/control   2024-03-23 20:45:20.0 +0100
@@ -1,8 +1,7 @@
 Source: freeipa
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian FreeIPA Team 

+Maintainer: Debian FreeIPA Team 
 Uploaders: Timo Aaltonen 
 Standards-Version: 4.5.0
 Vcs-Git: https://salsa.debian.org/freeipa-team/freeipa.git
@@ -23,6 +22,7 @@
  libldap2-dev,
  libnspr4-dev,
  libpopt-dev,
+ librpm-dev,
  libsasl2-dev,
  libssl-dev,
  libtalloc-dev,
@@ -172,7 +172,6 @@
  gpg,
  gpg-agent,
  keyutils,
- librpm9,
  python3-cffi,
  python3-cryptography,
  python3-dbus,
@@ -194,6 +193,7 @@
  ${misc:Depends},
  ${python3:Depends},
  ${shlibs:Depends},
+ ${lib:Depends},
 Description: FreeIPA centralized identity framework -- shared Python3 modules
  FreeIPA is an integrated solution to provide centrally managed Identity
  (machine, user, virtual machines, groups, authentication credentials), Policy
diff -Nru freeipa-4.10.2/debian/rules freeipa-4.10.2/debian/rules
--- freeipa-4.10.2/debian/rules 2023-10-18 11:46:40.0 +0200
+++ freeipa-4.10.2/debian/rules 2024-03-23 20:45:18.0 +0100
@@ -126,6 +126,11 @@
chmod 0700 $(CURDIR)/debian/freeipa-server/var/lib/ipa/backup; \
fi
 
+override_dh_gencontrol:
+   dh_gencontrol -- \
+ -Vlib:Depends=$(shell dpkg-query -W -f '$${Depends}' librpm-dev \
+   | sed -E 's/.*(librpm[[:alnum:].-]+).*/\1/')
+
 %:
dh $@ --with python3
 #  --builddirectory=build


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

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

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

Bug#1067175: exaile: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Julian Andres Klode]

Package: exaile
Followup-For: Bug #1067175
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch




*** /tmp/tmpzxivfv1g/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Drop hardcoded libgtk-3-0 dependency; gir1.2-gtk-3.0 gets the right one


Thanks for considering the patch.

*** /tmp/tmpzxivfv1g/exaile_4.1.3+dfsg-2ubuntu1.debdiff
diff -Nru exaile-4.1.3+dfsg/debian/control exaile-4.1.3+dfsg/debian/control
--- exaile-4.1.3+dfsg/debian/control2024-03-19 07:09:54.0 +0100
+++ exaile-4.1.3+dfsg/debian/control2024-03-23 20:30:18.0 +0100
@@ -1,8 +1,7 @@
 Source: exaile
 Section: sound
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: luzip665 
+Maintainer: luzip665 
 Build-Depends: debhelper-compat (= 13), python3 (>= 3.6), python3-sphinx (>= 
1.6), python3-gi-cairo (>=3.26), help2man
 Rules-Requires-Root: no
 Standards-Version: 4.6.2
@@ -13,7 +12,6 @@
 Depends:
  python3 (>= 3.6),
  python3-bsddb3 (>=6.1),
- libgtk-3-0 (>= 3.22),
  gstreamer1.0-plugins-good (>=1.14),
  python3-mutagen (>=1.38),
  python3-gi-cairo (>=3.26),


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

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

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

Bug#1067568: emacs-pdf-tools: [time_t] Remove hardcoded dependency on libpoppler-glib8

[Julian Andres Klode]

Package: emacs-pdf-tools
Version: 1.1.0-1
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch




*** /tmp/tmpjxu2sdja/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Remove hardcoded libpoppler-glib8 dependency

libpoppler-glib8 becomes libpoppler-glib8t64, and the dependency is no
longer needed.

Thanks for considering the patch.

*** /tmp/tmpjxu2sdja/emacs-pdf-tools_1.1.0-1ubuntu1.debdiff
diff -Nru emacs-pdf-tools-1.1.0/debian/control 
emacs-pdf-tools-1.1.0/debian/control
--- emacs-pdf-tools-1.1.0/debian/control2024-02-29 07:25:51.0 
+0100
+++ emacs-pdf-tools-1.1.0/debian/control2024-03-23 20:19:34.0 
+0100
@@ -1,8 +1,7 @@
 Source: emacs-pdf-tools
 Section: editors
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Emacsen team 
+Maintainer: Debian Emacsen team 
 Uploaders: Rémi Vanicat ,
  Aymeric Agon-Rambosson ,
 Build-Depends: debhelper-compat (= 13),
@@ -30,7 +29,7 @@
 
 Package: elpa-pdf-tools-server
 Architecture: any
-Depends: libpoppler-glib8 (>= 20.09.0~), ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: server for Emacs's pdf-tools
  This package contain the server needed by elpa-pdf-tools to transform
  pdf into png to be displayed by Emacs.


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

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

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

Bug#1067567: dhcp-probe: [time_t] Remove hardcoded dependencies on libpcap0.8, libnet, shlibs takes care of them

[Julian Andres Klode]

Package: dhcp-probe
Version: 1.3.0-10.1
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch




*** /tmp/tmp9u3imu66/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Remove hardcoded libpcap0.8, libnet1 dependencies; shlibs adds right ones

libpcap0.8 becomes libpcap0.8t64, hence it fails to install and the
package is not binNMUable.

Thanks for considering the patch.

*** /tmp/tmp9u3imu66/dhcp-probe_1.3.0-10.1ubuntu1.debdiff
diff -Nru dhcp-probe-1.3.0/debian/control dhcp-probe-1.3.0/debian/control
--- dhcp-probe-1.3.0/debian/control 2018-04-03 14:19:19.0 +0200
+++ dhcp-probe-1.3.0/debian/control 2024-03-23 20:16:10.0 +0100
@@ -1,15 +1,14 @@
 Source: dhcp-probe
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Laurent Guignard 
+Maintainer: Laurent Guignard 
 Build-Depends: debhelper (>= 7), quilt, autotools-dev, libpcap-dev (>= 0.9), 
libnet1-dev (>= 1.1.2.1-3), dpkg-dev (>=1.15.4), dh-autoreconf
 Standards-Version: 3.9.2
 Homepage: http://www.net.princeton.edu/software/dhcp_probe/
 
 Package: dhcp-probe
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ucf, libpcap0.8 (>= 0.9), libnet1 
(>= 1.1.2.1-3), net-tools
+Depends: ${shlibs:Depends}, ${misc:Depends}, ucf, net-tools
 Description: network DHCP or BootP server discover
  dhcp_probe attempts to discover DHCP and BootP servers on a directly-attached
  Ethernet network. A network administrator can use this tool to locate un-


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

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

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

Bug#1067566: Do not hardcode dependency on libhamlib4

[Julian Andres Klode]

Package: cqrlog
Version: 2.5.2-3
Severity: serious
Tags: patch
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch




*** /tmp/tmpb0h60c58/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Don't hardcode libhamlib4 dependency, determine from libhamlib-dev

As libhamlib4 becomes libhamlib4t64 in the time_t transition, and we
want this package to become binNMUable.

Thanks for considering the patch.

*** /tmp/tmpb0h60c58/cqrlog_2.5.2-3ubuntu1.debdiff
diff -Nru cqrlog-2.5.2/debian/control cqrlog-2.5.2/debian/control
--- cqrlog-2.5.2/debian/control 2024-03-08 05:08:51.0 +0100
+++ cqrlog-2.5.2/debian/control 2024-03-22 16:53:55.0 +0100
@@ -1,8 +1,7 @@
 Source: cqrlog
 Section: hamradio
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Hamradio Maintainers 

+Maintainer: Debian Hamradio Maintainers 
 Uploaders:
  Petr Hlozek ,
 Build-Depends:
@@ -36,9 +35,9 @@
  default-mysql-client-core | virtual-mysql-client-core,
  default-mysql-server-core | virtual-mysql-server-core,
  libhamlib-utils,
- libhamlib4,
  libmariadb-dev-compat,
  ${misc:Depends},
+ ${lib:Depends},
  ${shlibs:Depends},
 Breaks: cqrlog-data (<< 2.5.2-2)
 Replaces: cqrlog-data (<< 2.5.2-2)
diff -Nru cqrlog-2.5.2/debian/rules cqrlog-2.5.2/debian/rules
--- cqrlog-2.5.2/debian/rules   2022-09-07 11:59:57.0 +0200
+++ cqrlog-2.5.2/debian/rules   2024-03-22 16:53:55.0 +0100
@@ -2,3 +2,10 @@
 
 %:
dh $@
+
+
+override_dh_gencontrol:
+   dh_gencontrol -- \
+ -Vlib:Depends=$(shell dpkg-query -W -f '$${Depends}' 
libhamlib-dev \
+   | sed -E 's/.*(libhamlib[[:alnum:].-]+).*/\1/')
+


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

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

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

Bug#1067174: cpupower-gui: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Julian Andres Klode]

Package: cpupower-gui
Followup-For: Bug #1067174
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch




*** /tmp/tmpedc6k3en/bug_body

In Ubuntu, the attached patch was applied to achieve the following:


  * Drop unnecessary libgtk-3-0 dependency, gir1.2-gtk-3.0 pulls it in.


Thanks for considering the patch.

*** /tmp/tmpedc6k3en/cpupower-gui_0.7.2-2.1ubuntu1.debdiff
diff -Nru cpupower-gui-0.7.2/debian/control cpupower-gui-0.7.2/debian/control
--- cpupower-gui-0.7.2/debian/control   2024-03-19 07:08:56.0 +0100
+++ cpupower-gui-0.7.2/debian/control   2024-03-23 19:59:13.0 +0100
@@ -1,8 +1,7 @@
 Source: cpupower-gui
 Section: admin
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Evangelos Rigas 
+Maintainer: Evangelos Rigas 
 Build-Depends: debhelper-compat (= 12),
  meson (>= 0.50.0),
  ninja-build,
@@ -20,7 +19,7 @@
 
 Package: cpupower-gui
 Architecture: any
-Depends: libgtk-3-0, gir1.2-gtk-3.0, python3-gi, hicolor-icon-theme,
+Depends: gir1.2-gtk-3.0, python3-gi, hicolor-icon-theme,
  policykit-1, python3-dbus, ${misc:Depends}, ${python3:Depends}
 Suggests: policykit-1-gnome, lxqt-policykit, mate-polkit, lxsession
 Description: GUI utility to change the CPU frequency


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

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

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

Bug#1067173: clearlooks-phenix-theme: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Julian Andres Klode]

Package: clearlooks-phenix-theme
Followup-For: Bug #1067173
X-Debbugs-Cc: juli...@ubuntu.com
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch


*** /tmp/tmpsylwqvoq/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Remove unneccessary libgtk-3-0 depends. This should have been a Breaks
of the old unsupported version instead...


Thanks for considering the patch.

*** /tmp/tmpsylwqvoq/clearlooks-phenix-theme_7.0.1-3ubuntu1.debdiff
diff -Nru clearlooks-phenix-theme-7.0.1/debian/control 
clearlooks-phenix-theme-7.0.1/debian/control
--- clearlooks-phenix-theme-7.0.1/debian/control2024-03-19 
07:08:49.0 +0100
+++ clearlooks-phenix-theme-7.0.1/debian/control2024-03-23 
19:56:31.0 +0100
@@ -1,8 +1,7 @@
 Source: clearlooks-phenix-theme
 Section: gnome
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Desktop Theme Team 

+Maintainer: Debian Desktop Theme Team 

 Uploaders: Jeremy Bicha 
 Standards-Version: 4.2.1
 Build-Depends: debhelper (>= 11)
@@ -12,7 +11,7 @@
 
 Package: clearlooks-phenix-theme
 Architecture: all
-Depends: libgtk-3-0 (>= 3.20), ${misc:Depends}
+Depends: ${misc:Depends}
 Recommends: gtk2-engines
 Description: GTK3 port of Clearlooks theme
  Clearlooks-Phénix is a GTK3 theme which is a port of Clearlooks, the


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

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

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

Bug#1067440: Compression makes searching packages very slow

[Julian Andres Klode]

On Thu, Mar 21, 2024 at 09:25:47PM +0100, Julian Andres Klode wrote:
> On Thu, Mar 21, 2024 at 06:01:12PM +0200, Laurențiu Nicola wrote:
> > Package: apt
> > Version: 2.7.12
> > 
> > I noticed that searching for packages is very slow if the package lists are 
> > compressed. To reproduce, remove `/var/lib/apt/lists`, enable
> > 
> > Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz";
> > 
> > , run `apt update`. This enables LZ4 compression on my systems, but I don't 
> > think the exact method matters. You can then run `apt search librust`, 
> > which takes about 19 seconds in a Debian 12 container (docker.io/debian:12 
> > has compression already set up), compared to 0.4 seconds without 
> > compression.
> > 
> > Also tested on Ubuntu 22.04 and 24.04, so the exact APT version shouldn't 
> > matter too much.
> > 
> > I tried to look into it, and `strace -e trace=openat apt-cache search 
> > librust` shows it reopen and re-read one of the package lists:
> > 
> > openat(AT_FDCWD, 
> > "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
> >  O_RDONLY) = 16
> > librust-addr2line+default-dev - Cross-platform symbolication library - 
> > feature "default"
> > openat(AT_FDCWD, 
> > "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
> >  O_RDONLY) = 16
> > librust-addr2line+object-dev - Cross-platform symbolication library - 
> > feature "object"
> > openat(AT_FDCWD, 
> > "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
> >  O_RDONLY) = 16
> > librust-addr2line+rustc-demangle-dev - Cross-platform symbolication library 
> > - feature "rustc-demangle"
> > openat(AT_FDCWD, 
> > "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
> >  O_RDONLY) = 16
> > librust-addr2line+std-dev - Cross-platform symbolication library - feature 
> > "std"
> > 
> > (you can use -e trace=openat,read to confirm that it's actually reading the 
> > file)
> > 
> > I believe it's quadratic in the number of search results, and this is 
> > related to the pseudo-indexing mechanism used by APT (see 
> > `pkgRecords::Lookup` in apt-pkg). Each lookup call will have to decompress 
> > the file in order to seek to the destination.
> > 
> > Unfortunately, I suspect this isn't exactly an easy fix, given the current 
> > design.
> > 
> 
> Going to respond to this but also including responses to your followup email
> which has a broken Subject:
> 
> 
> Searching works by ordering the packages based on file, offset
> and then iterating over them and looking them up. Seeking forward
> to a higher offset does not involve a reopen, we just skip content
> in betwene.
> 
> Full-text search is inside the description in the section parsed
> for each package.
> 
> It's not clear why this fails on bookworm - I can reproduce that -
> t certainly is fine in git main on my Ubuntu 24.04 system.

This should be fixed in

https://salsa.debian.org/apt-team/apt/-/merge_requests/336

What happened was that we got called for the same offset twice, e.g.
let's say 42.

Now our section size is let's say 7.

So what happened is that we did:

- Jump to 42  =>  offset = 42
- Parse   =>  offset = 49
- Jump to 42  => ugh gotta go back

Luckily we still have the currently used section in the Buffer; i.e.
we only looked at bytes 49... but our buffer still starts
at 42, so we can just look back to find our section again.

Sadly we can't avoid the reparse of the section here, because the
pkgTagSection passed to pkgTagFile::Jump() could be a different one
than the last one.

I have a patch to avoid the reparse by storing offset a level higher
where the pkgTagSection is fixed but I'm in favour of not shipping that
- those would only be marginal gains and we want to exercise this code
path.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1067440: Compression makes searching packages very slow

[Julian Andres Klode]

On Thu, Mar 21, 2024 at 06:01:12PM +0200, Laurențiu Nicola wrote:
> Package: apt
> Version: 2.7.12
> 
> I noticed that searching for packages is very slow if the package lists are 
> compressed. To reproduce, remove `/var/lib/apt/lists`, enable
> 
> Acquire::GzipIndexes "true"; Acquire::CompressionTypes::Order:: "gz";
> 
> , run `apt update`. This enables LZ4 compression on my systems, but I don't 
> think the exact method matters. You can then run `apt search librust`, which 
> takes about 19 seconds in a Debian 12 container (docker.io/debian:12 has 
> compression already set up), compared to 0.4 seconds without compression.
> 
> Also tested on Ubuntu 22.04 and 24.04, so the exact APT version shouldn't 
> matter too much.
> 
> I tried to look into it, and `strace -e trace=openat apt-cache search 
> librust` shows it reopen and re-read one of the package lists:
> 
> openat(AT_FDCWD, 
> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
>  O_RDONLY) = 16
> librust-addr2line+default-dev - Cross-platform symbolication library - 
> feature "default"
> openat(AT_FDCWD, 
> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
>  O_RDONLY) = 16
> librust-addr2line+object-dev - Cross-platform symbolication library - feature 
> "object"
> openat(AT_FDCWD, 
> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
>  O_RDONLY) = 16
> librust-addr2line+rustc-demangle-dev - Cross-platform symbolication library - 
> feature "rustc-demangle"
> openat(AT_FDCWD, 
> "/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_jammy_universe_binary-amd64_Packages.lz4",
>  O_RDONLY) = 16
> librust-addr2line+std-dev - Cross-platform symbolication library - feature 
> "std"
> 
> (you can use -e trace=openat,read to confirm that it's actually reading the 
> file)
> 
> I believe it's quadratic in the number of search results, and this is related 
> to the pseudo-indexing mechanism used by APT (see `pkgRecords::Lookup` in 
> apt-pkg). Each lookup call will have to decompress the file in order to seek 
> to the destination.
> 
> Unfortunately, I suspect this isn't exactly an easy fix, given the current 
> design.
> 

Going to respond to this but also including responses to your followup email
which has a broken Subject:


Searching works by ordering the packages based on file, offset
and then iterating over them and looking them up. Seeking forward
to a higher offset does not involve a reopen, we just skip content
in betwene.

Full-text search is inside the description in the section parsed
for each package.

It's not clear why this fails on bookworm - I can reproduce that -
t certainly is fine in git main on my Ubuntu 24.04 system.


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

Bug#848194: Want way to get Release (or InRelease) file from cache

[Julian Andres Klode]

On Tue, Mar 19, 2024 at 04:51:35PM +, Colin Watson wrote:
> Hi,
> 
> I don't know if it helps or hinders this bug since I have rather
> different reasons from Ian, but I found myself looking at this bug today
> because I also wanted a way to get hold of an [In]Release file.  The
> difference is that I'm not trying to get hold of it for a particular
> package, but for (roughly) a sources.list entry; but all my other
> requirements seem basically the same as Ian's.  My use case is as
> follows, and you can tell me if it's too different to include in the
> same report:
> 
>  * In order to be able to implement an "import the contents of this
>repository into our database" task in debusine
>(https://freexian-team.pages.debian.net/debusine/), I want to
>discover which architectures are supported by a given suite in a
>repository, assuming that it has at least a Release file.  And of
>course then I want to be able to fetch all the files, but at least
>that part isn't so hard.
> 
>  * If you already know which architectures you want, then this is easy.
>But if you want to ask the repository which architectures it
>supports, as far as I know the only sensible way is to consult the
>Release file.
> 
>  * Acquiring and verifying Release files correctly is, as I'm sure you
>know, challenging.  I would like to avoid writing my own code to call
>gpgv in just the right way (again).  I've been here before with
>#918304.
> 
>  * I'd hoped to use python-debian, but its GPG verification support is
>currently not as good as it should be (#710923) and in any case what
>you get from its Release file handling is not very helpful
>(#1067160).
> 
>  * So I looked at apt/python-apt.  I know how to instantiate a temporary
>apt cache with its own configuration (in the manner of chdist(1), for
>instance), and if I could discover the available architectures after
>an initial fetch then I could call "apt-get update" a second time
>with APT::Architectures set and then I'd have everything.  However,
>given a cache, I seem to be able to access basically everything
>_except_ for the Release file in documented ways.  As mentioned in
>this bug, "apt-get indextargets" omits the Release file

Sorry I'm afraid this is not exposed in the apt code. There is only a
function to check which architectures are supported but you can't get
a list.

Meanwhile apt-get indextargets omits release files by design as they
are not indextargets, but uh metaindex targets.

python-apt omits bindings for ReleaseFile, there really should be
a Cache.release_files list of release file objects. You'd still need
to parse them yourself because we don't have the data in the cache
but that will get you most of the way there.

You may also for now rely on the file matching *Release in the lists
dir.

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

Bug#1067155: debian-policy: prerm scripts cannot actually rely on dependencies

[Julian Andres Klode]

Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: de...@lists.debian.org, debian-d...@lists.debian.org

APT's installation planner does not consider dependencies of packages
being scheduled for removal, so a prerm must fail equally gracefully
as a postrm does in absence of its dependencies.

This does break dpkg's assumptions which it happily tells you about,
but this is the reality we live in.

So e.g. one thing you see is that apt removes libapt-pkg6.0, then
unpacks libapt-pkg6.0t64, then removes libapt-pkg6.0 reverse
dependencies.

Clearly APT should be considering dependencies when removing packages
but even in that case, removals may sometimes need to be forced in the
wrong order because any order leads to broken dependencies, so still,
prerms should not rely on dependencies, but only on essential packages.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Julian Andres Klode]

Control: retitle -1 document package specifiers for `upgrade`

On Mon, Mar 11, 2024 at 10:12:33PM -0400, Wesley Schwengle wrote:
> On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote:
> > > I see. It looks like `apt upgrade ' behaves as `apt install
> > > '. Which (to me) is unexpected behaviour, as the man page is
> > quite
> > >clear on its behaviour (man 8 apt-get):
> > 
> > Well, clearly it shouldn’t. To begin with, “apt install” should mark a
> > package as manual installed while “apt upgrade” shouldn’t (my assumption).
> > And you’re right that “apt install” can remove a package if needed to
> > satisfy dependencies.
> > 
> > On top of that, documentation clearly states that “apt upgrade” should not
> > remove any package, but it does when you specify an individual package to
> > upgrade.
> > 
> > If this is not the expected behavior, maybe this is a bug (unless I am
> > missing something here).
> 
> I do not know what the bug here is, it could be one of these options:
> 
> 1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
>doesn't. The behaviour needs to change to not accept packages.
> 
> 2) apt-get/apt upgrade accepts packages and removes packages to satisfy deps
>where the docs state it doesn't. The behaviour need to change to not remove
>any packages. There is a small edge case where you can say: `apt upgrade 
> foo
>bar-'. Technically, it shouldn't remove packages, yet you want and instruct
>it to remove bar.

The behavior is correct if potentially unexpected, but it should be
documented better.

> 
> FWIW, aptitude does not remove packages where you call `aptitude safe-upgrade
> foo'. It does remove packages when you call `aptitude full-upgrade foo'. It
> also removes bar when you run `aptitude safe-upgrade foo bar-'. 

That is an entirely different command; `aptitude safe-upgrade foo`
upgrades (only) `foo`, whereas `apt upgrade foo` first does the normal
install argument handling and then runs an upgrade, so `foo` could also
be a new package that is not currently installed to hint the solver if
it is unable to find a solution.

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

Bug#1060246: perl: diff for NMU version 5.38.2-3.1

[Julian Andres Klode]

Control: tags 1060246 + patch
Control: tags 1060246 + pending

Dear maintainer,

I have prepared the following NMU, taking into consideration the
feedback to only override the ABI on the affected architectures.

I'm not sure I want to upload it now, but as it stands, anything
build-depending on libapt-pkg-perl and other perl bindings to t64
libraries will FTBFS.

I uploaded it to Ubuntu but it's stuck waiting for db5.3; I believe
vorlon has done binary-uploads for db5.3 in Debian to unblock it
there though.

Let me know what you think.

Regards.


-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en
diff -Nru perl-5.38.2/debian/changelog perl-5.38.2/debian/changelog
--- perl-5.38.2/debian/changelog	2024-01-12 17:16:08.0 +0100
+++ perl-5.38.2/debian/changelog	2024-02-29 10:18:06.0 +0100
@@ -1,3 +1,9 @@
+perl (5.38.2-3.1) unstable; urgency=medium
+
+  * debian/rules: Use t64 perl ABI on 32-bit architectures
+
+ -- Julian Andres Klode   Thu, 29 Feb 2024 10:18:06 +0100
+
 perl (5.38.2-3) unstable; urgency=medium
 
   * Unbreak locale initialization when embedding perl. (Closes: #1060456)
diff -Nru perl-5.38.2/debian/control perl-5.38.2/debian/control
--- perl-5.38.2/debian/control	2024-01-09 20:57:59.0 +0100
+++ perl-5.38.2/debian/control	2024-02-29 10:07:25.0 +0100
@@ -1,7 +1,8 @@
 Source: perl
 Section: perl
 Priority: standard
-Maintainer: Niko Tyni 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Niko Tyni 
 Uploaders: Dominic Hargreaves 
 Standards-Version: 3.9.8
 Homepage: http://dev.perl.org/perl5/
diff -Nru perl-5.38.2/debian/rules perl-5.38.2/debian/rules
--- perl-5.38.2/debian/rules	2024-01-06 16:59:56.0 +0100
+++ perl-5.38.2/debian/rules	2024-02-29 10:04:01.0 +0100
@@ -23,7 +23,12 @@
 
 # If nonempty, this will determine $Config{debian_abi} and Provides: entries
 # (otherwise, the Provides: entries will be generated by debian/mkprovides)
-perlabi =
+ifeq (,$(findstring $(DEB_HOST_ARCH), amd64 arm64 hurd-i386 i386 mips64el ppc64el riscv64 s390x))
+	# see #1060246
+	perlabi = 5.38.2t64
+else
+	perlabi =
+endif
 
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)

Bug#1064969: apt: can't upgrade with aptitude

[Julian Andres Klode]

Control: reassign -1 aptitude

On Wed, Feb 28, 2024 at 03:49:12PM +0100, Vincent Lefevre wrote:
> Source: apt
> Version: 2.7.12+nmu1
> Severity: serious
> 
> While there are no upgrade issues with apt itself (according
> to "apt install -s apt"), aptitude does not want to upgrade
> apt automatically, while this just appears to be a package
> rename:
> 
> # aptitude install apt
> The following packages will be upgraded: 
>   apt{b} apt-doc 
> 2 packages upgraded, 0 newly installed, 0 to remove and 180 not upgraded.
> Need to get 1622 kB of archives. After unpacking 0 B will be used.
> The following packages have unmet dependencies:
>  apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going to be 
> installed
>  apt-utils : Depends: apt (= 2.7.12) but 2.7.12+nmu1 is to be installed
> The following actions will resolve these dependencies:
> 
>  Keep the following packages at their current version:
> 1) apt [2.7.12 (now, testing)]
> 
> I don't know whether this is actually an issue with aptitude, but at
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059068#15
> 
> David Kalnischkies says:
> | You should really know this by now as that isn't your first report, but
> | okay: Upgrade problems are NEVER a problem to be solved in apt,
> | they are ALWAYS a problem in the involved packages. NO EXCEPTIONS.
> 
> So, I suppose that this is also the case for aptitude: if aptitude
> cannot upgrade just because of a rename, then this is a problem in
> the involved packages.

aptitude is not our chosen tool for distribution upgrades, as such
failures there are not release critical for the packages. So while
this is release critical for aptitude, it's a wishlist bug for apt
that probably would end up being closed.

I do believe the correct syntax for aptitude would be to use

aptitude upgrade apt

though

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

Bug#1064945: grub-efi-amd64: Sudden boot failures on ZFS systems

[Julian Andres Klode]

Control: severity -1 normal
Control: tag -1 - patch

On Tue, Feb 27, 2024 at 10:36:01PM -0600, John Goerzen wrote:
> Package: grub-efi-amd64
> Version: 2.06-13+deb12u1
> Severity: critical
> Tags: upstream patch
> Justification: breaks the whole system
> 
> My system suddenly refused to start up grub.  An error message flashed by, but
> too quickly for me to be able to see.  Then I got the grub emergency prompt.
> 
> Upon booting from a Debian live image to attempt to fix this, after chrooting
> into an appropriately-configured filesystem from the target (with bind-mount
> /proc, /sys, /dev, /boot/efi, etc), grub-install failed with:
> 
> error: compression algorithm inherit not supported
> 
> I'll note that "inherit" is not really a compression algorithm for ZFS.  
> (root,
> and also boot, are part of ZFS on this system.)
> 
> Upon researching this, I see that https://github.com/openzfs/zfs/issues/15261
> discusses the problem.  https://github.com/openzfs/zfs/issues/13873 does as
> well.
> 
> https://github.com/openzfs/zfs/issues/13873#issuecomment-1905182760 suggests
> that it is the ZFS feature extensible_dataset that is responsible for this.
> That feature can get auto-enabled by other features at runtime.

My understanding is that this happens when snapshots are used on /boot which
as you can see is not a supported configuration.

Also note that zfs on /boot is one of the file systems we are looking at
phasing out for a future Debian release because it is overly complex for
the use case and hence a significant risk factor for secure boot.

> 
> Both of these bugs indicate that grub 2.12 contains patches to fix the issue.
> Indeed, the four patches listed at
> https://git.savannah.gnu.org/cgit/grub.git/log/grub-core/fs/zfs/zfs.c 
> pertaining
> to ZFS are thought to fix it.

I don't know who started that rumour, but that is a lie, there are 12 patches,
not 4, between 2.06 and 2.12

$ git shortlog grub-2.06..grub-2.12 grub-core/fs/zfs/
Darren Kenny (1):
  fs/zfs/zfs: Fix possible insecure use of chunk size in 
zap_leaf_array_get()

Elyes Haouas (1):
  fs: Remove trailing whitespaces

Glenn Washburn (1):
  zfs: Use grub_uint64_t instead of 1ULL in BF64_*CODE() macros

Jagannathan Raman (4):
  fs/zfs/zfs: make_mdn() - avoid pointer downcasting
  fs/zfs/zfs: zfs_mount() - avoid pointer downcasting
  fs/zfs/zfs: Pass pointer to dnode_end_t instead of value to fill_fs_info()
  fs/zfs/zfs: Update dangling dn_new pointer in dnode_get_path()

Vladimir 'phcoder' Serbinenko (1):
  Revert "zfsinfo: Correct a check for error allocating memory"

Vladimir Serbinenko (4):
  ZFS: support inode type embed into its ID
  ZFS: Fix invalid memcmp
  ZFS: Don't iterate over null objsets
  ZFS: Check bonustype in addition to dnode type


> 
> I have built a bookworm-backports version of grub 2.12 and it does indeed 
> solve
> the problem.
> 
> I think this issue justifies backporting those ZFS patches into the version in
> bookworm for stable-proposed-updates.

Patches welcome. I'm not sure you can pick a subset, but it's worth trying.


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

Bug#1064840: dh-ada-library: Tests will fail after glibc DEP17 migration

[Julian Andres Klode]

Source: dh-ada-library
Version: 8.9
Severity: normal
X-Debbugs-Cc: j...@debian.org
User: helm...@debian.org
Usertags: dep17m2
Control: block 1061248 by -1

Following the upload of 1061248, your package will fail to test due to safety 
diversions
in glibc:

287s autopkgtest [12:18:40]: test standard-gpr:  - - - - - - - - - - results - 
- - - - - - - - -
287s standard-gpr FAIL stderr: dpkg-shlibdeps: warning: diversions 
involved - output may be incorrect
287s autopkgtest [12:18:40]: test standard-gpr:  - - - - - - - - - - stderr - - 
- - - - - - - -
287s dpkg-shlibdeps: warning: diversions involved - output may be incorrect
287s  diversion by libc6 from: /lib/ld-linux-aarch64.so.1
287s dpkg-shlibdeps: warning: diversions involved - output may be incorrect
287s  diversion by libc6 to: /lib/ld-linux-aarch64.so.1.usr-is-merged
287s autopkgtest [12:18:40]: test unusual-soname-gpr: preparing testbed

329s autopkgtest [12:19:22]: test several-libraries-gpr:  - - - - - - - - - - 
results - - - - - - - - - -
329s several-libraries-gpr FAIL stderr: dpkg-shlibdeps: warning: diversions 
involved - output may be incorrect
329s autopkgtest [12:19:22]: test several-libraries-gpr:  - - - - - - - - - - 
stderr - - - - - - - - - -
329s dpkg-shlibdeps: warning: diversions involved - output may be incorrect
329s  diversion by libc6 from: /lib/ld-linux-aarch64.so.1
329s dpkg-shlibdeps: warning: diversions involved - output may be incorrect
329s  diversion by libc6 to: /lib/ld-linux-aarch64.so.1.usr-is-merged

You may solve this by adding allow-stderr as a test suite restriction to the 
affected
tests, or by redirecting standard error output of the build process to stdout, 
which may
be nicer. Or you can come up with other solutions.

You can find a full test log from Ubuntu 24.04 - where we already executed the 
DEP17 move - at

https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/arm64/d/dh-ada-library/20240226_121928_dd418@/log.gz

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

Kernel: Linux 6.8.0-11-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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


signature.asc
Description: PGP signature

Bug#1064839: Consider not using an ephemeral key or document its security model

[Julian Andres Klode]

Source: linux
Severity: normal
X-Debbugs-Cc: j...@debian.org

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040901 I asked you
to switch to an ephemeral key which was a misunderstanding from a
discussion with xnox, which we still need to sort out fully.

Please either document how the buildds ensure that

- private key generation has enough, and high quality enough, entropy
- private keys are safely erased after not being needed anymore

or revert to signing modules with the CA key and use MODVERSIONS
and co to ensure that modules built for one ABI cannot be used
with another.

I need to update the question in shim-review accordingly, I think
I never reverted it or adjusted it, but it will likely take the
form of the previous three paragraphs.

I sincerely apologize for causing this misunderstanding.

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

Kernel: Linux 6.8.0-11-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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

Bug#1064838: New package names break APT safety features, ability to co-install different ABIs

[Julian Andres Klode]

On Mon, Feb 26, 2024 at 02:20:41PM +0100, Julian Andres Klode wrote:
> Source: linux
> Severity: serious
> X-Debbugs-Cc: j...@debian.org
> 
> After we had discussed the new proposal a couple months ago and were
> left with severe open questions and concerns it seems that these have
> been ignored and the packages uploaded anyway, breaking APT's algorithm
> that ensures the currently booted kernel is not offered for removal, as
> well as possibly others.
> 
> In addition, this means that the ABI changes within the same package
> names, causing different ABIs to no longer be co-installable, which can
> have drastic effect on thef function of systems:
> 
> - modules will fail to load until you reboot
> - modules needed to reboot will fail to load until you reboot (if any)
> 
> I do not believe fucking up our users for convenience of the maintainers
> and lacking of tools on the ftpmaster side to automatically approve new
> ABI renames is the right call here.
> 
> As such if this change is not reverted, I intend to reassign this to
> the technical committee for deliberation.

This is a followup to the discussion in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040901

which we discussed all this in October all these concerns were already
raised in, and lots of open questions remained that we were nowhere near
ready to do this even if we all agreed that was the right move.

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

Bug#1064838: New package names break APT safety features, ability to co-install different ABIs

[Julian Andres Klode]

Source: linux
Severity: serious
X-Debbugs-Cc: j...@debian.org

After we had discussed the new proposal a couple months ago and were
left with severe open questions and concerns it seems that these have
been ignored and the packages uploaded anyway, breaking APT's algorithm
that ensures the currently booted kernel is not offered for removal, as
well as possibly others.

In addition, this means that the ABI changes within the same package
names, causing different ABIs to no longer be co-installable, which can
have drastic effect on thef function of systems:

- modules will fail to load until you reboot
- modules needed to reboot will fail to load until you reboot (if any)

I do not believe fucking up our users for convenience of the maintainers
and lacking of tools on the ftpmaster side to automatically approve new
ABI renames is the right call here.

As such if this change is not reverted, I intend to reassign this to
the technical committee for deliberation.

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

Kernel: Linux 6.8.0-11-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

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

Bug#1061248: glibc: DEP17: move most files but rtld to /usr

[Julian Andres Klode]

On Sun, Feb 04, 2024 at 09:20:09PM +0100, Helmut Grohne wrote:
> Hi Aurelien and Sven,
> 
> On Wed, Jan 24, 2024 at 09:19:12PM +0100, Aurelien Jarno wrote:
> > On 2024-01-23 17:40, Helmut Grohne wrote:
> > > Conflicting runtime dynamic linkers between multiarch packages
> > > ==
> > > 
> > > Some architecture combinations such as s390, powerpc, hppa, m68k,
> > > mipsn32, and hurd-i386 or alpha, i386, sh4, and sparc have conflicting
> > > runtime dynamic loaders. In theory this violates Multi-Arch: same, but
> > > there is basically nothing we can do about this and dropping Multi-Arch:
> > > same from the packages would completely break any kind of multiarch
> > > setup. There is little we can do here and this is also unrelated to
> > > DEP17.
> > 
> > We tried to add conflicts for those, like it's done for the multilib
> > packages, but at the time the infrastructure exploded (see #745552). I
> > don't remember the details, but I guess it was either dak or
> > dose-builddebcheck.
> 
> Yeah, I also remember something like that. It's not the first time I
> trip into this. "There is little we can do here" still counts.
> 
> > I guess the symlink in the maintainer script could indeed work. I am not
> > sure why it has been done like that, it was part of the multiarch
> > patchset from Steve Langasek more than 10 years ago.
> 
> Practically speaking, it appears to work rather well. On the flip side,
> I also thought that way of my first patch. ;)
> 
> > Note however that the those packages are used by cross-toolchain-base
> > (which builds them from glibc-source) and mangled to install them in the
> > cross path. See for instance libc6-amd64-x32-cross. For such cases, we
> > probably do want to keep the dynamic linker symlink, as those packages
> > do not have maintainer scripts.
> 
> I don't think those -$arch-cross packages need the runtime dynamic
> linker at all. Unlike the libc6-$multilib packages, we don't use
> -$arch-cross packages to actaully run any binary. Simply not installing
> it might just work in practice.
> 
> So here is an updated patch with a few notes:
>  * This patch moves all the files including the runtime dynamic linker
>in the main multiarch library. Therefore, this patch needs to be
>synced with the corresponding base-files change to add the aliasing
>symlinks or debootstrap breaks. In other words: Don't upload this
>yet.
>  * As mentioned earlier, only the multiarch packages install the runtime
>dynamic linker via data.tar. All the multilib packages install it via
>maintainer scripts now.
>  * When installing libc6-x32, /libx32 will be created because partial
>upgrades might otherwise be broken. Removing libc6-x32 will not
>remove /libx32 though. I suggest fixing this in base-files by
>installing a trigger interest in /usr/libx32 and having
>base-files.postinst create/remove /libx32 as needed. This way, we
>centralize the management of aliasing links into base-files. libx32
>only serves as an example here and it works the same way for any
>other non-essential multilib directory. Do you agree with the
>approach?
>  * The multilib packages install a trigger interest on the runtime
>dynamic linker such that they notice when a multiarch package deletes
>it and can then recreate it as needed. Thus the multiarch packages do
>not have to pay attention to a possibly installed multilib package
>when they are removed.
>  * I've tried quite a few multiarch upgrades involving amd64 and i386
>using dpkg --auto-deconfigure --unpack with various packages and even
>cross grading libc6-x32 from :i386 to :amd64 during the upgrade.
>While dpkg --verify was occasionally unhappy during a partial upgrade
>(where half-unpacked packages were around), once no package was
>half-installed, dpkg --verify was also happy again in all attempts. I
>did not come up with a systematic enumeration of possible upgrade
>scenarios though.
>  * The patch works will deboostrap/cdebootstrap/mmdebstrap (in
>combination with more patches including base-files, bash, dash and
>util-linux).
>  * The change to install ldconfig to /usr/sbin can be uploaded right
>away. It's limited to debian/debhelper.in/libc-bin.install and
>debian/debhelper.in/libc-bin.lintian-overrides and doesn't contribute
>much diff, so doing it later is fine as well.
> 
> I hope you don't manage to punch holes into my theory this time around.

Ubuntu testing revealed that due to /lib64 going away in the package we
also are going to need Depends or PreDepends on base-files, such that
base-files trigger can then create the symlink.

Or we temporarily handle the trigger ourselves or so.

I am not sure if Depends are enough, I guess if you do a release
upgrade we could end up with

unpack base-files
unpack libc6 
preinst for something we want to unpack -> poof, no /lib64 here, can't 

Bug#1032131: deb822-style sources.list

[Julian Andres Klode]

On Tue, Feb 28, 2023 at 07:00:57PM +0100, Cyril Brulebois wrote:
> Hi,
> 
> David Prévot  (2023-02-28):
> > I may be late to the bookworm party but… It would be nice if d-i could
> > provide deb822-style sources.list (by default) for newly installed
> > machines.
> 
> This seems late indeed.

Hiya, we just flipped the switch for Ubuntu, I think it's about time
we switch apt-setup for trixie.

The path we picked for Ubuntu was to keep a transtional sources.list
file:

# Ubuntu sources have moved to the /etc/apt/sources.list.d/ubuntu.sources
# file, which uses the deb822 format. Use deb822-formatted .sources files
# to manage package sources in the /etc/apt/sources.list.d/ directory.
# See the sources.list(5) manual page for details.

We probably should use the same text with s/Ubuntu/Debian/;s/ubuntu/debian/.

Having the transitional commented sources.list helps various tools
that identify a debian-style system by looking at sources.list
presence and guides the user.

The Debian sources should then be in sources.list.d/debian.sources. See
the Docker images tianon builds for Debian, they have already switched
and provide (only) the debian.sources.

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


signature.asc
Description: PGP signature

Bug#1064040: src:gnupg2: Please remove Recommends: gnupg from all binary packages

[Julian Andres Klode]

On Fri, Feb 16, 2024 at 11:19:33AM +0100, Julian Andres Klode wrote:
> Control: tag -1 patch
> 
> On Fri, Feb 16, 2024 at 10:42:35AM +0100, Julian Andres Klode wrote:
> > Source: gnupg2
> > Severity: normal
> > X-Debbugs-Cc: juli...@ubuntu.com
> > 
> > gnupg is a big meta package pulling in all sorts of weird stuff
> > people don't want by default on their machine, like a wks server.
> > 
> > That wks server in experimental now pulls in a mail transport
> > agent.
> > 
> > Hence installing gpg for example pulls in gnupg by Recommends,
> > and then the wks server and then the mail transport agent. Ugh.
> > 
> > It stands to reason that gnupg2 should have:
> > 
> > 1. gnupg should move to the metapackages section
> > 2. All Recommends on gnupg should be removed, we don't want that
> >installed by default.
> > 3. gpg should Recommends keyboxd and dirmngr as they will frequently be
> >needed when using gpg
> > 
> > And then we should clean up all reverse dependencies to say gpg.
> > 
> > I think I plan to do this in Ubuntu. The alternative would be
> > to demote all non-interesting gnupg dependencies to suggests,
> > those would be:
> > 
> > - gnupg-utils
> > - gpg-wks-server
> > - gpgv [stuff will depend on that anyway if it needs it, like apt does]
> > - maybe gpg-wks-client
> > 
> > This may make the gnupg package *actually useful* rather than
> > be a pointless metapackage that nobody actually wants to install.
> > 
> > Let me know what you think but this surely is a mess
> > we need to sort out, and I have about ~ next week to
> > do so downstream.
> 
> Implemented in
> https://salsa.debian.org/debian/gnupg2/-/merge_requests/13
> 
> as just uploaded to Ubuntu.

Also note MR 14, which fixes the autopkgtests for 2.4.

My intention is to also change other packages' Depends and Recommends on
gnupg to generally say gpg instead, but not in the next weeks, but like
after Ubuntu has import stop as I don't want to do that in 24.04 cycle.

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

Bug#1064040: src:gnupg2: Please remove Recommends: gnupg from all binary packages

[Julian Andres Klode]

Control: tag -1 patch

On Fri, Feb 16, 2024 at 10:42:35AM +0100, Julian Andres Klode wrote:
> Source: gnupg2
> Severity: normal
> X-Debbugs-Cc: juli...@ubuntu.com
> 
> gnupg is a big meta package pulling in all sorts of weird stuff
> people don't want by default on their machine, like a wks server.
> 
> That wks server in experimental now pulls in a mail transport
> agent.
> 
> Hence installing gpg for example pulls in gnupg by Recommends,
> and then the wks server and then the mail transport agent. Ugh.
> 
> It stands to reason that gnupg2 should have:
> 
> 1. gnupg should move to the metapackages section
> 2. All Recommends on gnupg should be removed, we don't want that
>installed by default.
> 3. gpg should Recommends keyboxd and dirmngr as they will frequently be
>needed when using gpg
> 
> And then we should clean up all reverse dependencies to say gpg.
> 
> I think I plan to do this in Ubuntu. The alternative would be
> to demote all non-interesting gnupg dependencies to suggests,
> those would be:
> 
> - gnupg-utils
> - gpg-wks-server
> - gpgv [stuff will depend on that anyway if it needs it, like apt does]
> - maybe gpg-wks-client
> 
> This may make the gnupg package *actually useful* rather than
> be a pointless metapackage that nobody actually wants to install.
> 
> Let me know what you think but this surely is a mess
> we need to sort out, and I have about ~ next week to
> do so downstream.

Implemented in
https://salsa.debian.org/debian/gnupg2/-/merge_requests/13

as just uploaded to Ubuntu.

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

Bug#1064040: src:gnupg2: Please remove Recommends: gnupg from all binary packages

[Julian Andres Klode]

Source: gnupg2
Severity: normal
X-Debbugs-Cc: juli...@ubuntu.com

gnupg is a big meta package pulling in all sorts of weird stuff
people don't want by default on their machine, like a wks server.

That wks server in experimental now pulls in a mail transport
agent.

Hence installing gpg for example pulls in gnupg by Recommends,
and then the wks server and then the mail transport agent. Ugh.

It stands to reason that gnupg2 should have:

1. gnupg should move to the metapackages section
2. All Recommends on gnupg should be removed, we don't want that
   installed by default.
3. gpg should Recommends keyboxd and dirmngr as they will frequently be
   needed when using gpg

And then we should clean up all reverse dependencies to say gpg.

I think I plan to do this in Ubuntu. The alternative would be
to demote all non-interesting gnupg dependencies to suggests,
those would be:

- gnupg-utils
- gpg-wks-server
- gpgv [stuff will depend on that anyway if it needs it, like apt does]
- maybe gpg-wks-client

This may make the gnupg package *actually useful* rather than
be a pointless metapackage that nobody actually wants to install.

Let me know what you think but this surely is a mess
we need to sort out, and I have about ~ next week to
do so downstream.

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

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

-- no debconf information

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

Bug#1063907: apt: symbol lookup error

[Julian Andres Klode]

Control: tag -1 unreproducible

On Wed, Feb 14, 2024 at 04:22:21PM +0100, Michael Ott wrote:
> Package: apt
> Version: 2.7.11
> Severity: important
> 
> Dear Maintainer,
> 
> after update apt I got the following error:
> apt autoremove --purge
> apt: symbol lookup error: /lib/x86_64-linux-gnu/libapt-private.so.0.0:
> undefined symbol: _ZNK11pkgDepCache14PhasingAppliedEN8pkgCache11PkgIteratorE,
> version APTPKG_6.0

I'm afraid something on your system is messed up, but I don't see
how this can be a bug in apt.

This should not be possible, the apt binary and libapt-private
are in the same binary package (apt), and that Depends on libapt-pkg6.0
(>= 2.7.11) which adds the symbol.

The autopkgtests have passed, it runs on my (Ubuntu) system, and
works fine in a clean OCI container:

root@b6047fa9374e:/#  apt autoremove --purge
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

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

Bug#1062192: piuparts fails to remove grub-efi-amd64-signed as it is now Protected: yes

[Julian Andres Klode]

Package: piuparts
Severity: normal
X-Debbugs-Cc: j...@debian.org

This is breaking the transition of grub-efi-amd64-signed. piuparts needs
to pass --allow-remove-essential to the apt command to be able to remove
this package (or any package with Protected: yes).

It presumably should also check that yes, Protected: yes packages cannot
be removed on their own.

Thank you!

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

Bug#1061555: apt: augment signature verification for key-usage transparency (Sigstore/Sigsum)

[Julian Andres Klode]

On Fri, Jan 26, 2024 at 11:39:03AM +0100, Simon Josefsson wrote:
> Package: apt
> Severity: wishlist
> 
> I believe it would be nice if apt could verify signatures from Sigstore
> cosign and/or verify Sigsum proofs, to augment the current PGP-based
> signature verification.
> 
> While this can be handled outside of apt's awareness, it would also be
> possible for apt to support improved signature verification in-band.
> 
> I'm interested in exploring any approach that leads to improved
> signature verification offering similar functionality as
> Sigstore/Sigsum, and offer to help work on this.
> 
> To get the design process started on the in-band approach: one proposal
> is to extend the InRelease and Release.gpg file formats with additional
> information needed for Sigstore and Sigsum.
> 
> After the PGP signature in InRelease and Release.gpg, you could include
> additional sections.  For Sigstore cosign:
> 
> -BEGIN SIGSTORE COSIGN-
> MEUCIQDz6ggeNw3FXj6TRZajQYUaVce6Wbw5++Pl+fLuwChejwIgJ0ZUbS+Gtyd/PTlLu5Yw7mI7EJtFbmGJ2ucKTjeEA+M=
> -END SIGSTORE COSIGN-
> 
> For Sigsum proofs:
> 
> -BEGIN SIGSUM PROOF-
> version=1
> log=5955bfe2150ee2e667c4e418228f9ee89835d6990248aad9b39c0e2120c1b022
> leaf=7244
> 4f313845ab7b7bc4592e437869e838fcccef45b402bd970f8aa2628ec17ef5cf
> e1f43026d9bf03ee21bb87db59f34593ec8c5f5a32abbbdeab23c24083f6078f5cc731e2a44ac66ac251640e850d69a94b1810012ca062b760a9cdf477e68a0a
> 
> size=21
> root_hash=40574f3463b822fddaeed6cd6fd286b2c1229eb6059e27f127488b9625e299b7
> signature=d9c19494a30c20c390967d8c8de452876a82559a26ee159d18d35081b701b610b6fb614ccb59644ba01e70bacd3a5ae6dad420235a30d7f5119857d68306fb02
> cosignature=70b861a010f25030de6ff6a5267e0b951e70c04b20ba4a3ce41e7fba7b9b7dfc
> 1705693592
> e51006f8f8d5415add21d24c4f5f2e1f6231030c70ba7a78f69aebaf2162c16627dbd6c461f8b71351281475d1ffc4cd8ff110df62cdc349a99faf0558de3705
> 
> leaf_index=20
> node_hash=ee51a73cedb8d27e4b50359dad5be1f76f667134fef55b9d80c63fb80bbdb95e
> node_hash=7b7f715c37c43a50164f585ba31c111e409074cc8a8dc8f51415587efff3dc57
> -END SIGSUM PROOF-

I'm strongly opposed to add support for these off-the-shelve solutions.
We need end-to-end control of all aspects of signing.

What we learned with OpenPGP is that we don't want to be tied to third
party off-the-shelve solutions as we cannot control the cryptography and
are subject to the whims of their developers.

Hence we're still stuck with 1024-bit RSA keys in freaking 2024.

I have started apt-sign to get rid of the horrors of OpenPGP and get
a sensible format. I still have to make some changes to it, but if
we want to have a solution it essentially will boil down to adding
this to the Signatures field which will have lines of the form:

   

where  currently is apt-ed448 or apt-ed25519.

It's entirely possible to require signatures from multiple keys
and implement co-signing that way rather than bolt on off-the-shelve
crap that we cannot control.

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


signature.asc
Description: PGP signature

Bug#1060705: grub-pc: Symbol grub_env_get not found

[Julian Andres Klode]

Control: tag -1 moreinfo

On Sat, Jan 13, 2024 at 11:48:21AM +0100, Bastian Germann wrote:
> Package: grub-pc
> Severity: grave
> Version: 2.12~rc1-12+b1
> 
> Hi,
> 
> Booting my i386 sid installation after an update fails because grub cannot 
> find one of its symbols.
> I cannot even boot to an initramfs but I can run a grub shell.
> 
> I guess this is an issue introduced by the recent binNMU because I think 
> before I have updated to 2.12~rc1-12.
> Thanks for any hint.

This is missing grub-install log that triggers the bug at the
very least. I wouldn't know why this would happen in a binNMU,
it sounds like your install is messed up somehow, like the core.img
rebuilt but not modules or something.

Does 2.12~rc1-13 work? Does 2.12-1 work which I just uploaded? 

If I don't hear other reports this week I'll have to assume that's a
fluke on your end - weird things happen sometimes - and close it.

testing is still at 2.06, and that's an untenable situation and we
do not have the means to go debug every single machine out there.

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

Bug#1056764: grub-efi-amd64: can't boot with GRUB 2.12~rc1-12

[Julian Andres Klode]

Control: severity -1 important

On Sat, Nov 25, 2023 at 05:36:41PM -0500, Nicolas Haller wrote:
> Package: grub-efi-amd64
> Version: 2.06-13
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> My old laptop (Lenovo 11e) runs Sid and all was right before I updated
> it the other day (I don't do that very often). After that upgrade, GRUB
> wasn't able to load any kernel with the pretty much generic error
> "Error: can't load image". The version of GRUB was 2.12~rc1-12.
> If I try to boot again, GRUB tells me that I need to load the image
> first (I guess it somehow ignores the linux command and sends that when
> trying to load the initrd).

I'm downgrading this bug severity, as a single system regressing in
boot ability is not release critical. It is not possible for us to
ensure that grub continues working on every single device out there,
this grub will work for more hardware than previous grubs, and blocking
the transition to testing because it doesn't work on your 11e is not
helping anyone.

We have now also uploaded 2.12-1 and of course we welcome any patches,
but an old Lenovo 11e is not a priority, and we don't have any to test
ourselves.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1061148: apt: option -a has several meanings and is unusable

[Julian Andres Klode]

On Fri, Jan 19, 2024 at 05:10:40PM +0100, Vincent Lefevre wrote:
> On 2024-01-19 16:43:24 +0100, Julian Andres Klode wrote:
> > On Fri, Jan 19, 2024 at 03:43:25PM +0100, Vincent Lefevre wrote:
> > > Package: apt
> > > Version: 2.7.9
> > > Severity: normal
> > > 
> > > In the apt-get(8) man page:
> > > 
> > >apt-get [-asqdyfmubV] [-o=config_string] [-c=config_file]
> > >[-t=target_release] [-a=architecture] {update | upgrade |
> > >dselect-upgrade | dist-upgrade |
> > >install pkg [{=pkg_version_number | /target_release}]...  |
> > >remove pkg...  | purge pkg...  |
> > >source pkg [{=pkg_version_number | /target_release}]...  |
> > >build-dep pkg [{=pkg_version_number | /target_release}]... 
> > >  |
> > >download pkg [{=pkg_version_number | /target_release}]...  
> > > |
> > >check | clean | autoclean | autoremove | {-v | --version} |
> > >{-h | --help}}
> > > 
> > > So option -a appears both as a single option -a and as -a=architecture.
> > > 
> > > In the apt(8) man page, only the second form is listed, but for both
> > > commands, it is unusable:
> > > 
> > > # apt-get -a=i386 install libfontconfig-dev
> > > E: Command line option 'a' [from -a=i386] is not understood in 
> > > combination with the other options.
> > > 
> > > # apt -a=i386 install libfontconfig-dev
> > > E: Command line option 'a' [from -a=i386] is not understood in 
> > > combination with the other options.
> > 
> > -a in that sense is an argument to build-dep and family (source --build,
> > satisfy). It is short for host-architecture, and makes no sense in any
> > other command.
> 
> Perhaps this should be explicitly documented. And the error message
> should be clarified (note: "install" is a command, not an option).
> 
> > You seem to be trying to install libfontconfig-dev:i386
> 
> OK, but I was looking at an option to install several packages
> (package list to be copy-pasted) for a foreign architecture
> without much typing.
> 
> > We haven't explained that it works outside of source --compile and
> > build-dep (i.e. in satisfy) but I fail to see how you get to try
> > to pass this to install after reading the manual page.
> 
> The -a=... version is not documented in the manual, only -a alone,
> but even for that, I don't understand the manual; the grammar seems
> incorrect:
> 
>-a, --host-architecture
>This option controls the architecture packages are built for by
>apt-get source --compile and how cross-builddependencies are
>satisfied. By default is it not set which means that the host
>architecture is the same as the build architecture (which is
>defined by APT::Architecture). Configuration Item:
>APT::Get::Host-Architecture.
> 
> There are 2 verbs "controls" and "are built". And I don't see how
> to parse "for by". In the next sentence: "is it". Should this be
> "it is"? The comma is missing before "which". Still, I don't see
> what this option does.

apt-get source --compile compiles packages. For cross-compilation,
you need to set the host architecture. This option controls that.

And yes this is just runaway without punctuation, but uh wording
is hard and we really just want to rewrite all manual pages from
scratch.

Then you'll see -a, --host-architecture in the apt-build-dep
and apt-source and apt-satisfy manual pages (maybe they are all
the same, who knows).


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

Bug#1061148: apt: option -a has several meanings and is unusable

[Julian Andres Klode]

On Fri, Jan 19, 2024 at 03:43:25PM +0100, Vincent Lefevre wrote:
> Package: apt
> Version: 2.7.9
> Severity: normal
> 
> In the apt-get(8) man page:
> 
>apt-get [-asqdyfmubV] [-o=config_string] [-c=config_file]
>[-t=target_release] [-a=architecture] {update | upgrade |
>dselect-upgrade | dist-upgrade |
>install pkg [{=pkg_version_number | /target_release}]...  |
>remove pkg...  | purge pkg...  |
>source pkg [{=pkg_version_number | /target_release}]...  |
>build-dep pkg [{=pkg_version_number | /target_release}]...  |
>download pkg [{=pkg_version_number | /target_release}]...  |
>check | clean | autoclean | autoremove | {-v | --version} |
>{-h | --help}}
> 
> So option -a appears both as a single option -a and as -a=architecture.
> 
> In the apt(8) man page, only the second form is listed, but for both
> commands, it is unusable:
> 
> # apt-get -a=i386 install libfontconfig-dev
> E: Command line option 'a' [from -a=i386] is not understood in combination 
> with the other options.
> 
> # apt -a=i386 install libfontconfig-dev
> E: Command line option 'a' [from -a=i386] is not understood in combination 
> with the other options.

-a in that sense is an argument to build-dep and family (source --build,
satisfy). It is short for host-architecture, and makes no sense in any
other command.

You seem to be trying to install libfontconfig-dev:i386

We haven't explained that it works outside of source --compile and
build-dep (i.e. in satisfy) but I fail to see how you get to try
to pass this to install after reading the manual page.

The help output obviously can't tell you which commands support
which arguments.

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

Bug#1042391: gpgv: add --min-rsa-length

[Julian Andres Klode]

On Tue, Jan 16, 2024 at 11:02:28AM +0100, Julian Andres Klode wrote:
> Control: severity -1 important
> 
> On Thu, Jul 27, 2023 at 12:16:54PM +0200, Julian Andres Klode wrote:
> > Package: gpgv
> > Version: 2.2.40-1.1ubuntu1
> > Severity: normal
> > X-Debbugs-Cc: j...@debian.org
> > 
> > I believe this allows APT to request a safe minimum RSA length from gpgv for
> > verification purposes, and then we could even run gpgv a 2nd time
> > without the flag and print a diagnostic for an orderly transition to
> > at least 2048R.
> 
> Bumping this. 1024R keys are becoming increasingly unsafe, and this
> will eventually become release critical for trixie because we shouldn't
> ship it with trust for those keys.
> 
> And APT is not capable of checking the key size itself because gpg
> status fd doesn't expose it - that'd be an alternative solution.

OK the option does not do what it said back then. Logs are below; tl,dr is:

1. Without de-vs compliance setting, it is ignored silently
2. With de-vs compliance setting it is still a good signature
3. Only way to notice it is to also set --require-compliance

For APT we want to just ban sub-2048R keys, possibly sub-3072R keys (apparently
2048R is no longer considered safe enough for some draft standards).

-- logs:

root@n:~# gpg --compliance de-vs --require-compliance --min-rsa-length 4096 
--status-fd 2 --no-options --homedir /tmp/x --keyring /root/vlc.gpg --verify 
/var/lib/apt/lists/ppa.launchpadcontent.net_videolan_master-daily_ubuntu_dists_noble_InRelease
 ; echo $?
gpg: WARNING: unsafe permissions on homedir '/tmp/x'
[GNUPG:] NEWSIG
gpg: Signature made Tue Jan 16 10:30:22 2024 UTC
gpg:using RSA key 3361E59FF5029E6B90A9A80D09589874801DF724
[GNUPG:] KEY_CONSIDERED 3361E59FF5029E6B90A9A80D09589874801DF724 0
[GNUPG:] SIG_ID sSNe0v8YekIqvdODJR2bHE3DiZY 2024-01-16 1705401022
[GNUPG:] KEY_CONSIDERED 3361E59FF5029E6B90A9A80D09589874801DF724 0
[GNUPG:] GOODSIG 09589874801DF724 Launchpad Daily Build of master branch
gpg: Good signature from "Launchpad Daily Build of master branch" [unknown]
[GNUPG:] VALIDSIG 3361E59FF5029E6B90A9A80D09589874801DF724 2024-01-16 
1705401022 0 4 0 1 10 01 3361E59FF5029E6B90A9A80D09589874801DF724
gpg: WARNING: This key is not suitable for signing in --compliance=de-vs mode
[GNUPG:] KEY_CONSIDERED 3361E59FF5029E6B90A9A80D09589874801DF724 0
[GNUPG:] TRUST_UNDEFINED 0 pgp
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3361 E59F F502 9E6B 90A9  A80D 0958 9874 801D F724
[GNUPG:] FAILURE compliance-check 33554683
gpg: operation forced to fail due to unfulfilled compliance rules
2
root@n:~# gpg --compliance de-vs  --min-rsa-length 4096 --status-fd 2 
--no-options --homedir /tmp/x --keyring /root/vlc.gpg --verify 
/var/lib/apt/lists/ppa.launchpadcontent.net_videolan_master-daily_ubuntu_dists_noble_InRelease
 ; echo $?
gpg: WARNING: unsafe permissions on homedir '/tmp/x'
[GNUPG:] NEWSIG
gpg: Signature made Tue Jan 16 10:30:22 2024 UTC
gpg:using RSA key 3361E59FF5029E6B90A9A80D09589874801DF724
[GNUPG:] KEY_CONSIDERED 3361E59FF5029E6B90A9A80D09589874801DF724 0
[GNUPG:] SIG_ID sSNe0v8YekIqvdODJR2bHE3DiZY 2024-01-16 1705401022
[GNUPG:] KEY_CONSIDERED 3361E59FF5029E6B90A9A80D09589874801DF724 0
[GNUPG:] GOODSIG 09589874801DF724 Launchpad Daily Build of master branch
gpg: Good signature from "Launchpad Daily Build of master branch" [unknown]
[GNUPG:] VALIDSIG 3361E59FF5029E6B90A9A80D09589874801DF724 2024-01-16 
1705401022 0 4 0 1 10 01 3361E59FF5029E6B90A9A80D09589874801DF724
gpg: WARNING: This key is not suitable for signing in --compliance=de-vs mode
[GNUPG:] KEY_CONSIDERED 3361E59FF5029E6B90A9A80D09589874801DF724 0
[GNUPG:] TRUST_UNDEFINED 0 pgp
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 3361 E59F F502 9E6B 90A9  A80D 0958 9874 801D F724
0
root@n:~# gpg --require-compliance --min-rsa-length 4096 --status-fd 2 
--no-options --homedir /tmp/x --keyring /root/vlc.gpg --verify 
/var/lib/apt/lists/ppa.launchpadcontent.net_videolan_master-daily_ubuntu_dists_noble_InRelease
 ; echo $?
gpg: WARNING: unsafe permissions on homedir '/tmp/x'
[GNUPG:] NEWSIG
gpg: Signature made Tue Jan 16 10:30:22 2024 UTC
gpg:using RSA key 3361E59FF5029E6B90A9A80D09589874801DF724
[GNUPG:] KEY_CONSIDERED 3361E59FF5029E6B90A9A80D09589874801DF724 0
[GNUPG:] SIG_ID sSNe0v8YekIqvdODJR2bHE3DiZY 2024-01-16 1705401022
[GNUPG:] KEY_CONSIDERED 3361E59FF5029E6B90A9A80D09589874801DF724 0
[GNUPG:] GOODSIG 09589874801DF724 Launchpad Daily Build of master branch
gpg: Good signature from "Launchpad Daily Build of master branch" [unknown]
[GNUPG:] VALIDSIG 3361E59FF5029E6B90A9A80D0958

Bug#1042391: gpgv: add --min-rsa-length

[Julian Andres Klode]

Control: severity -1 important

On Thu, Jul 27, 2023 at 12:16:54PM +0200, Julian Andres Klode wrote:
> Package: gpgv
> Version: 2.2.40-1.1ubuntu1
> Severity: normal
> X-Debbugs-Cc: j...@debian.org
> 
> I believe this allows APT to request a safe minimum RSA length from gpgv for
> verification purposes, and then we could even run gpgv a 2nd time
> without the flag and print a diagnostic for an orderly transition to
> at least 2048R.

Bumping this. 1024R keys are becoming increasingly unsafe, and this
will eventually become release critical for trixie because we shouldn't
ship it with trust for those keys.

And APT is not capable of checking the key size itself because gpg
status fd doesn't expose it - that'd be an alternative solution.

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

Bug#1060251: Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

[Julian Andres Klode]

On Thu, Jan 11, 2024 at 10:18:58PM +0100, Emanuele Rocca wrote:
> Hi Julian,
> 
> On 2024-01-11 05:46, Julian Andres Klode wrote:
> > And there aren't any hard errors. We could zero initialize
> > those or add supressions to make things look nicer I suppose.
> 
> Mmmh no, they are all actual errors as far as valgrind is concerned.
> 
> The thing is, you're running valgrind without --error-exitcode. By doing
> so, the exit code of your tests is the exit code of apt-get, not of
> valgrind.
> 
> Try this instead:
> 
> (sid-amd64)root@ariel:~# valgrind --error-exitcode=1 apt-get update
> [...]
> ==308534== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 0 from 0)
> (sid-amd64)root@ariel:~# echo $?
> 1

That's all just strawman arguments.

As said before, these aren't the issue. These all occur in locations
where we read the entire memory arena of our allocator, either for
hashing or writing it to a file.

While they _should_ be zero-initialized if you look at the code, we
actually initialize things with a header object. The problem is the
header object looks like:

uint32_t magic;
uint16_t major;
uint16_t minor;
bool dirty;
uint16_t boo;

And the padding bytes are never initialized but will inevitably
be read by the hashing and write back of the entire arena.

We can fix these errors by either zero initializing the padding in
the object constructor: 


diff --git a/apt-pkg/pkgcache.cc b/apt-pkg/pkgcache.cc
index 76336b9b3..b845cb13c 100644
--- a/apt-pkg/pkgcache.cc
+++ b/apt-pkg/pkgcache.cc
@@ -52,6 +52,7 @@ using APT::StringView;
 /* Simply initialize the header */
 pkgCache::Header::Header()
 {
+   memset(this, 0, sizeof(*this));
 #define APT_HEADER_SET(X,Y) X = Y; 
static_assert(std::numeric_limits::max() > Y, "Size violation 
detected in pkgCache::Header")
APT_HEADER_SET(Signature, 0x98FE76DC);
 


or by not creating a header on the stack (with uninitialized padding) and then 
copying
it in, by using placement new operator:


diff --git a/apt-pkg/pkgcachegen.cc b/apt-pkg/pkgcachegen.cc
index 9e47ef369..3a85a9585 100644
--- a/apt-pkg/pkgcachegen.cc
+++ b/apt-pkg/pkgcachegen.cc
@@ -89,7 +89,7 @@ bool pkgCacheGenerator::Start()
   
Map.UsePools(*Cache.HeaderP->Pools,sizeof(Cache.HeaderP->Pools)/sizeof(Cache.HeaderP->Pools[0]));
 
   // Starting header
-  *Cache.HeaderP = pkgCache::Header();
+  new (Cache.HeaderP) pkgCache::Header();
 
   // make room for the hashtables for packages and groups
   if (Map.RawAllocate(2 * (Cache.HeaderP->GetHashTableSize() * 
sizeof(map_pointer))) == 0)


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

Bug#1060251: Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

[Julian Andres Klode]

On Thu, Jan 11, 2024 at 03:53:17PM +0100, Emanuele Rocca wrote:
> Hi Julian,
> 
> On 2024-01-08 10:28, Julian Andres Klode wrote:
> > (in Ubuntu we have partially recovered by disabling stack clash
> > protection but it crashes on invalid writes there, I suppose we need
> > to rebuild some more apt dependencies without the flag...).
> 
> The 'invalid writes' issue seems unrelated to armhf and 
> stack-clash-protection,
> I can reproduce it on my x86 workstation. It would be interesting to see if
> once these problems are fixed valgrind on armhf still segfaults.
> 
> (sid-amd64)root@ariel:~# valgrind apt-get update
> ==194196== Memcheck, a memory error detector
> ==194196== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
> ==194196== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
> ==194196== Command: apt-get update
> ==194196== 
> Hit:1 http://127.0.0.1:3142/debian sid InRelease
> ==194196== Conditional jump or move depends on uninitialised value(s)
> ==194196==at 0x4A89B3B: pkgCache::ReMap(bool const&) (in 
> /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0.0)
> [... more errors follow]

The uninitialized values in ReMap are actually normal and
correct behavior, not errors. It happens because we need to
grow the array/map without having written all bytes of it first.

The same applies to uninitalized bytes passed to write from
pkgCacheFile::BuildCaches(), it's writing the partially
initialized memory pool to the file.

And there aren't any hard errors. We could zero initialize
those or add supressions to make things look nicer I suppose.

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

Bug#1054137: apt: let dh_installsystemd choose the location of units

[Julian Andres Klode]

On Tue, Jan 09, 2024 at 07:49:48PM +0100, Julian Andres Klode wrote:
> On Tue, Jan 09, 2024 at 06:46:14PM +0100, Chris Hofstaedtler wrote:
> > Dear APT Maintainers,
> > 
> > On Tue, Oct 17, 2023 at 04:36:19PM +0200, Helmut Grohne wrote:
> > [Move systemd files to /usr]
> > > I'm attaching a patch for your convenience.
> > 
> > Could I ask you to apply this patch some time soon, please?
> 
> No, the patch is currently not in an actionable state to my
> knowledge, we spend a couple hours trying to sort things out
> in October or so but didn't get anywhere.
> 
> And there's urgent RC bug fixing in python-apt I
> do need to finish up first before I can wrap my head around
> this again.

FWIW, I'm more inclined to move the files to /usr manually, that
avoids all the risky business we identified trying to whack
dh_installsystemd into shape to install that successfully.

I could do that before the time_t transition, presumably next
Monday.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1054137: apt: let dh_installsystemd choose the location of units

[Julian Andres Klode]

On Tue, Jan 09, 2024 at 06:46:14PM +0100, Chris Hofstaedtler wrote:
> Dear APT Maintainers,
> 
> On Tue, Oct 17, 2023 at 04:36:19PM +0200, Helmut Grohne wrote:
> [Move systemd files to /usr]
> > I'm attaching a patch for your convenience.
> 
> Could I ask you to apply this patch some time soon, please?

No, the patch is currently not in an actionable state to my
knowledge, we spend a couple hours trying to sort things out
in October or so but didn't get anywhere.

And there's urgent RC bug fixing in python-apt I
do need to finish up first before I can wrap my head around
this again.


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

Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

[Julian Andres Klode]

Hey Steve,

On Sat, Jan 06, 2024 at 07:38:42PM -0800, Steve Langasek wrote:
> On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote:
> > Hi,
> 
> > Am 06.01.24 um 06:51 schrieb Steve Langasek:
> > > > > - dpkg will be uploaded to experimental with 64-bit time_t in the 
> > > > > default
> > > > > flags
> > > [...]
> > > What about the suggestion to not push changes to experimental for packages
> > > that already have new versions in experimental, and do the binary package
> > > renames in unstable instead, leaving the package in experimental alone?
> 
> > How does that play together with the needed dpkg only in experimental?
> 
> > You can't build stuff for unstable involving experimental packages (except
> > manually with binary upload, which would block testing migration)
> 
> The ordering here would be:
> 
> - dpkg will be uploaded to experimental with 64-bit time_t in the default
>   flags
> 
> - the source packages which need an ABI change
>   ("source-packages"+"lfs-and-depends-time_t") and do not already have
>   versions in experimental, will have sourceful NMUs to experimental with
>   the new binary package names in order to clear binary NEW, in coordination
> 
> - once these packages have all cleared binary NEW, the new dpkg defaults
>   will be uploaded to unstable

What happened to the plan to workaround this by doing dak database
shenanigans prior to uploading to avoid binary-NEW altogether, that
I chatted about with mhy/#debian-ftp and you? Did that not work out?

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


signature.asc
Description: PGP signature

Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

[Julian Andres Klode]

Control: clone -1 -2
Control: reassign -2 valgrind
Control: retitle -2 valgrind: armhf is broken

On Sat, Dec 23, 2023 at 08:46:27AM +0100, Paul Gevers wrote:
> Source: apt
> Version: 2.7.6
> Severity: serious
> Control: close -1 2.7.7
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:apt has been trying to migrate for 31 days [2]. Hence,
> I am filing this bug. The version in unstable fails its own autopkgtest on
> armhf.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on other
> packages, which makes preparing for the release more difficult. Finally, it
> often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that hamper
> the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if that
> version or a later version migrates, this bug will no longer affect testing.
> I have also tagged this bug to only affect sid and trixie, so it doesn't
> affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
> [2] https://qa.debian.org/excuses.php?package=apt
> 

This is a release critical bug in valgrind. valgrind does not understand
the new toolchain defaults like stack clash protection on armhf and just
segfaults (in Ubuntu we have partially recovered by disabling stack
clash protection but it crashes on invalid writes there, I suppose we
need to rebuild some more apt dependencies without the flag...).

As there doesn't appear to be any progress on the valgrind or toolchain
sides to fix these issues, I'll go and disable valgrind on armhf in the
next apt upload, but I am cloning this to valgrind to make it clear that
it's horribly borked.

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


signature.asc
Description: PGP signature

Bug#1041248: keepass update

[Julian Andres Klode]

On Mon, Jan 01, 2024 at 02:23:12PM +0100, Matthias Geiger wrote:
> On Sat, 11 Nov 2023 09:06:22 +0200 Julian Andres Klode 
> wrote:
> 
> > As I have explained in the previous comment, this is highly security
> > sensitive and requires careful review, hence updates aside from CVEs
> > can only happen during Christmas break when there's time to review
> > the code.
> >
> 
> 
> Hi,
> 
> any update on this ?

Please stop harassing me and especially not on fucking new year after
people blew up shit half the night. Have some decency.

I took the rest of this messed up week off and I'll try to come up
with an update but each time you send an email it wastes a lot of
resources to respond to it and it slips more and more.

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

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Julian Andres Klode]

On Mon, Dec 25, 2023 at 04:33:36PM +0100, Cyril Brulebois wrote:
> Julian Andres Klode  (2023-12-25):
> > The final grub 2.12 that includes the fix should hit unstable in the
> > middle of January. As you might be aware many are busy with family
> > stuff and holiday celebrations right now.
> 
> Sure. I wasn't aware an upstream release was in the pipes, only that
> patches have existed and been confirmed OK for close to 2 months.

We picked the previous XFS patch for extent parsing but did not pick
this one because it had not been merged at that point yet, the fix
only got merged two weeks or so ago, and we didn't want to take chances
and pick it ahead of time as it's security critical code (filesystem
parsing is where all the security bugs live!).

The release was supposed to be out 2 weeks ago but got pushed back
another week to last week's release, sadly.

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

Bug#1059424: Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Julian Andres Klode]

Control: tag 1059424 patch

(switching to the cloned xfsprogs bug)

On Mon, Dec 25, 2023 at 09:15:59AM +0100, Julian Andres Klode wrote:
> Control: clone -1 -2
> Control: reassign -2 xfsprogs
> 
> On Sat, Dec 23, 2023 at 11:11:53PM +0100, Cyril Brulebois wrote:
> > Hi,
> > 
> > Anthony Iliopoulos  (2023-10-30):
> > > On Mon, Oct 30, 2023 at 04:19:32PM +0100, Philip Hands wrote:
> > > > Anthony Iliopoulos  writes:
> > > > 
> > > > > On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
> > > > ...
> > > > >>   error: invalid XFS directory entry.
> > > > ...
> > > > > This issue exists independently of the large extent counter, and it is
> > > > > related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> > > > > fuzzing the XFS filesystem"). That's actually the issue described in
> > > > > #1051543.
> > > > 
> > > > Ah, yes -- good point.
> > > > 
> > > > > There's a proposed fix at [1], and it works as expected with that 
> > > > > patch
> > > > > applied.
> > > > ...
> > > > > [1] 
> > > > > https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/
> > > > 
> > > > I can confirm that having applied both patches:
> > > > 
> > > >   https://salsa.debian.org/philh/grub2/-/pipelines/596346
> > > > 
> > > > it now succeeds at both installing grub, and then booting the system:
> > > > 
> > > >   https://openqa.debian.net/tests/200503#details
> > > 
> > > Thanks for confirming, perhaps then you can add your tested-by in the
> > > respective patches upstream.
> > > 
> > > BTW, another handy way to test if this works is via grub-mount.
> > 
> > Any chance we could have an updated grub2 package to fix this?
> 
> The final grub 2.12 that includes the fix should hit unstable in the
> middle of January. As you might be aware many are busy with family
> stuff and holiday celebrations right now.
> 
> As always though it stands to reason that this is a change that should
> (have been) reverted in xfsprogs first until a grub that understands it
> has been released in a stable point release such that you can use a
> stable grub to inspect an XFS filesystem created by a trixie xfsprogs.
> 
> It seems the bug has been wrongly reassigned instead of being cloned
> and reassigned, so I'm cloning it back to xfsprogs.

Ah I see I fixed this in Ubuntu's xfsprogs back in November, so patch
attached, I seem to have forgotten to forward this?

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


xfsprogs_6.5.0-1_6.5.0-1ubuntu1.diff.gz
Description: application/gzip

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Julian Andres Klode]

Control: clone -1 -2
Control: reassign -2 xfsprogs

On Sat, Dec 23, 2023 at 11:11:53PM +0100, Cyril Brulebois wrote:
> Hi,
> 
> Anthony Iliopoulos  (2023-10-30):
> > On Mon, Oct 30, 2023 at 04:19:32PM +0100, Philip Hands wrote:
> > > Anthony Iliopoulos  writes:
> > > 
> > > > On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
> > > ...
> > > >>   error: invalid XFS directory entry.
> > > ...
> > > > This issue exists independently of the large extent counter, and it is
> > > > related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> > > > fuzzing the XFS filesystem"). That's actually the issue described in
> > > > #1051543.
> > > 
> > > Ah, yes -- good point.
> > > 
> > > > There's a proposed fix at [1], and it works as expected with that patch
> > > > applied.
> > > ...
> > > > [1] 
> > > > https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/
> > > 
> > > I can confirm that having applied both patches:
> > > 
> > >   https://salsa.debian.org/philh/grub2/-/pipelines/596346
> > > 
> > > it now succeeds at both installing grub, and then booting the system:
> > > 
> > >   https://openqa.debian.net/tests/200503#details
> > 
> > Thanks for confirming, perhaps then you can add your tested-by in the
> > respective patches upstream.
> > 
> > BTW, another handy way to test if this works is via grub-mount.
> 
> Any chance we could have an updated grub2 package to fix this?

The final grub 2.12 that includes the fix should hit unstable in the
middle of January. As you might be aware many are busy with family
stuff and holiday celebrations right now.

As always though it stands to reason that this is a change that should
(have been) reverted in xfsprogs first until a grub that understands it
has been released in a stable point release such that you can use a
stable grub to inspect an XFS filesystem created by a trixie xfsprogs.

It seems the bug has been wrongly reassigned instead of being cloned
and reassigned, so I'm cloning it back to xfsprogs.

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

Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf

[Julian Andres Klode]

On Sat, Dec 23, 2023 at 08:46:27AM +0100, Paul Gevers wrote:
> Source: apt
> Version: 2.7.6
> Severity: serious
> Control: close -1 2.7.7
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 30 days as having a Release Critical bug in testing
> [1]. Your package src:apt has been trying to migrate for 31 days [2]. Hence,
> I am filing this bug. The version in unstable fails its own autopkgtest on
> armhf.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on other
> packages, which makes preparing for the release more difficult. Finally, it
> often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that hamper
> the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new bugs,
> there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if that
> version or a later version migrates, this bug will no longer affect testing.
> I have also tagged this bug to only affect sid and trixie, so it doesn't
> affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to issues
> beyond your control, don't hesitate to contact the Release Team.

I know this is automated but I feel lije it would be sensible to scan
the logs for well known bugs so that you don't end up filing bugs
against every package broken by valgrind's missing support for the new
NOP sequences in binutils.

Like this work is tracked in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057693

and normally we would forcemerge this into it.

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

Bug#1059267: ITP: apt-verify - extend apt's gpgv-based verification mechanism

[Julian Andres Klode]

On Fri, Dec 22, 2023 at 10:54:10AM +0100, Simon Josefsson wrote:
> Package: wnpp
> Severity: wishlist
> Owner: si...@josefsson.org
> X-Debbugs-CC: debian-de...@lists.debian.org
> 
> * Package name: apt-verify
>   Version : 2.0
>   Upstream Contact: Simon Josefsson 
> * URL : https://gitlab.com/debdistutils/apt-verify
> * License : AGPLv3+
>   Programming Lang: Shell script
>   Description : extend apt's gpgv-based verification mechanism
> 
> Apt-verify extends apt to call all tools in /etc/verify.d/ instead of
> always only calling gpgv, to verify apt archive integrity and
> authenticity.  A symbolic link in /etc/verify.d/gpgv is installed by
> default to provide full backwards compatibility.


David already said a lot of good things but let me extend on that:

- apt-key use is slated for removal no later than Feb 29th.
- apt signature verification should not involve shell scripts
  (hence the removal in the first place)
- apt-verify looks like it's an apt tool and is easy to confuse
  with apt-sign, apt's openpgp replacement, and what will likely
  be the name of the method verifying apt-ed25519 signatures,
  'verify'

In closing let me say I consider overriding APT's signature verification
to be RC-buggy and would immediately file an RC bug should that package
be accepted.

-- The road forward, signature verification and sandboxing concerns

I do not think we currently have a way to move forward with signature
verification hooks due to issues with the download sandbox. If we want
to come up with solutions to plug in additional verification steps, we
first need to

1) finish the sandboxing to move verification of files outside the
   sandbox, or writes from the download and decompressor steps into
   a deeper sandbox

   Essentially my consideration is to replace the entire acquire stack
   with a new event-based stack that's easier to reason about because at
   this point the interactions between the classes we have are
   unreasonable and not understandable.

2) figure out how we can integrate additional verification steps
   with well known security properties that ensure reliability of
   the sandbox. We don't just want to run arbitrary hooks in the
   sandbox (or as root really).

3) figure out a protocol for this. My goal is to adopt varlink in
   APT for IPC to provide a daemon for APT as well as to replace
   custom IPC protocols we currently have like the various classic
   hooks, the JSON hooks, and the acquire protocol.

   Then it would be nice to be able to say "hook in after
   'org.debian.apt.verify' and do additional things".

This will probably take until 2030 or so if I'm the only one working on
it but that's the position that we should aim for rather than blindly
hooking in things where they're not expected or creating hooks that we
don't know how they will work in the final design.

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

Bug#1058118: python-apt: FTBFS: AssertionError: pyflakes failed with: 1

[Julian Andres Klode]

Control: clone -1 -2
Control: reassign -2 pyflakes 3.1.0-1

On Tue, Dec 12, 2023 at 09:06:33AM +0100, Lucas Nussbaum wrote:
> Source: python-apt
> Version: 2.7.0
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20231212 ftbfs-trixie
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > dh_auto_test || [ "linux" = "hurd" ];
> > I: pybuild base:310: env 
> > PYTHONPATH=/<>/.pybuild/cpython3_3.12_apt/build python3.12 
> > tests/test_all.py
> > [tests] Running on 3.12.1 (main, Dec  8 2023, 16:20:54) [GCC 13.2.0]
> > Using pybuild supplied build dir
> > s
> > Reading package lists... 0%
> > 
> > Reading package lists... 100%
> > 
> > Reading package lists... Done
> > 
> > 
> > Building dependency tree... 0%
> > 
> > Building dependency tree... 0%
> > 
> > Building dependency tree... 50%
> > 
> > Building dependency tree... 50%
> > 
> > Building dependency tree... Done
> > 
> > 
> > Reading state information... 0% 
> > 
> > Reading state information... 0%
> > 
> > Reading state information... Done
> > 
> > .
> > Reading package lists... 0%
> > 
> > Reading package lists... 100%
> > 
> > Reading package lists... Done
> > 
> > 
> > Building dependency tree... 0%
> > 
> > Building dependency tree... 0%
> > 
> > Building dependency tree... 50%
> > 
> > Building dependency tree... 50%
> > 
> > Building dependency tree... Done
> > 
> > 
> > Reading state information... 0% 
> > 
> > Reading state information... 0%
> > 
> > Reading state information... Done
> > 
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > ..WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .WARNING: Failed to read mirror file
> > .s...s../<>/apt/auth.py:40:1:
> >  'typing.List' imported but unused
> > /<>/apt/auth.py:40:1: 'typing.Optional' imported but unused
> > /<>/apt/auth.py:40:1: 'typing.Tuple' imported but unused
> > /<>/apt/utils.py:21:1: 'datetime' imported but unused
> > /<>/apt/utils.py:24:1: 'typing.Optional' imported but unused
> > /<>/apt/utils.py:24:1: 'typing.Tuple' imported but unused
> > /<>/apt/utils.py:26:1: 'apt' imported but unused
> > /<>/apt/cdrom.py:25:1: 'typing.Optional' imported but unused
> > /<>/apt/package.py:30:1: 'threading' imported but unused
> > /<>/apt/package.py:36:1: 'typing.Iterable' imported but unused
> > /<>/apt/package.py:36:1: 'typing.Iterator' imported but unused
> > /<>/apt/package.py:36:1: 'typing.Optional' imported but unused
> > /<>/apt/package.py:36:1: 'typing.Set' imported but unused
> > /<>/apt/package.py:36:1: 'typing.Tuple' imported but unused
> > /<>/apt/package.py:36:1: 'typing.Union' imported but unused
> > /<>/apt/package.py:53:1: 'apt.progress.base.AcquireProgress' 
> > imported but unused
> > /<>/apt/package.py:53:1: 'apt.progress.base.InstallProgress' 
> > imported but unused
> > /<>/apt/debfile.py:29:1: 'typing.Dict' imported but unused
> > /<>/apt/debfile.py:29:1: 'typing.Iterable' imported but unused
> > /<>/apt/debfile.py:29:1: 'typing.List' imported but unused
> > /<>/apt/debfile.py:29:1: 'typing.Optional' imported but unused
> > /<>/apt/debfile.py:29:1: 'typing.Set' imported but unused
> > /<>/apt/debfile.py:29:1: 'typing.Tuple' imported but unused
> > /<>/apt/debfile.py:29:1: 'typing.Union' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.Any' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.Callable' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.Dict' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.Iterator' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.List' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.Optional' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.Set' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.Tuple' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.Union' imported but unused
> > /<>/apt/cache.py:30:1: 'typing.KeysView' imported but unused
> > 

Bug#976673: dget: DEB822-style .sources files unsupported

[Julian Andres Klode]

Control: severity -1 important

On Sun, Dec 06, 2020 at 02:25:15PM -0500, Richard Noble wrote:
> Package: devscripts
> Version: 2.19.5+deb10u1
> File: /usr/bin/dget
> 
> 
> dget isn't able to download any packages given a package name on
> my system:
> 
> $ dget devscripts
> no repository found in /etc/apt/sources.list or sources.list.d at 
> /usr/bin/dget line 378.
> 
> It seems that the problem is that dget only supports one-line-style 
> sources.list files, and not multi-line DEB822-style .sources files
> (the manpage sources.list(5) describes both formats).

Docker images for bookworm are already using debian.sources, so
this is failing to work out of the box now on some images. Once
d-i has switched this is arguably RC.

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

Bug#1056985: wireshark: Unversioned Breaks: wireshark-qt should be Conflicts

[Julian Andres Klode]

Package: wireshark
Version: 4.2.0-1
Severity: normal
X-Debbugs-Cc: j...@debian.org

Breaks are not intended to be used without a version, it essentially
triggers the coded path to upgrade the broken package.

The correct relationship to use here is Conflicts as per policy 7.6.2,
"Replacing whole packages, forcing their removal".

Note that using Breaks means that you can end up in a not-fully-consistent
state where wireshark-qt is just deconfigured. APT's behavior of removing
packages in this case rather than allowing an inconsistent state like
that is not part of policy.

This may break other solvers who rely on the Conflicts+Replaces special
semantics per 7.6.2, such as downstream ubuntu-release-upgrader.

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

Kernel: Linux 6.5.0-10-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wireshark depends on:
ii  libc62.38-3ubuntu1
ii  libgcc-s113.2.0-6ubuntu1
ii  libgcrypt20  1.10.2-3ubuntu1
ii  libglib2.0-0 2.78.1-4
ii  libminizip1  1.1-8build1
ii  libnl-3-200  3.7.0-0.2
ii  libnl-genl-3-200 3.7.0-0.2
ii  libnl-route-3-2003.7.0-0.2
ii  libpcap0.8   1.10.4-4
ii  libqt5svg5   5.15.10-2
ii  libqt6core5compat6   6.4.2-4
ii  libqt6core6  6.4.2+dfsg-19
ii  libqt6gui6   6.4.2+dfsg-19
ii  libqt6multimedia66.4.2-11
ii  libqt6printsupport6  6.4.2+dfsg-19
ii  libqt6widgets6   6.4.2+dfsg-19
ii  libspeexdsp1 1.2.1-1
ii  libstdc++6   13.2.0-6ubuntu1
ii  libwireshark17   4.2.0-1
ii  libwiretap14 4.2.0-1
ii  libwsutil15  4.2.0-1
ii  wireshark-common 4.2.0-1

Versions of packages wireshark recommends:
ii  libqt5multimedia5-plugins  5.15.10-2

wireshark suggests no packages.

-- no debconf information

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

Bug#1056595: dgit: must not override dpkg include lists

[Julian Andres Klode]

On Thu, Nov 23, 2023 at 05:57:42PM +, Ian Jackson wrote:
> Severity: -1 normal
> 
> Julian Andres Klode writes ("Bug#1056595: dgit: must not override dpkg 
> include lists"):
> > dgit overrides the include lists for dpkg, causing packages to include
> > additional .gitignore and similar files which dpkg-source -b will
> > exclude.
> 
> Yes.
> 
> This is necessary (1) so that the git trees correspond precisely to
> the .dscs (which is the invariant of the dgit git view), and
> (2) to comply with our promise to provide people with the source code.
> 
> I consider dpkg-source's behaviour, of excluding .gitignore by default,
> to be wrong:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908747
> (You may recall that report, since you commented on it.)


I see, I consider dpkg's behavior to be the correct one, and if you
want to override it, do it in debian/source/options, not by passing
arguments to dpkg.

> 
> > This creates a significant hurdle to the NMU process and downstream
> > distribution maintainers who have to figure out how to reduce the
> > delta again, because in both cases, unrelated changes should not
> > be present in the diff between the two uploads.
> 
> I'm afraid I don't understand your scenario precisely.  I'm
> sympathetic to the goal of removing hurdles for NMUers and downstream
> maintainers.
> 
> > Like I had to spend about 20 minutes or so today trying to figure out
> > how to actually get that sorted out for a native package (I was trying
> > -i all the time when I should have passed -I), in turn I discovered
> > some other process issues but that's beside the point :D
> 
> Were you trying to use dgit to make an NMU?  If so what git branch
> did you start with?  What options did you give to dgit?


No, I have no intention to ever use dgit. I believe its design is
directly opposed to what I consider the right workflow.

In my case it was not actually an NMU but I was building a prepared
merge downstream in Ubuntu which removed files that were present
in the Debian upload, but it's the same issue NMUers in Debian
face.

If I start with the .dsc, have no intention of ever touching dgit,
I need to manually figure out why files go missing vs the previous
upload and how to make them not disappear.

Like for both NMUs, and downstream work, what we care about is not
"oh rebuild is cleaning out some garbage in the tarball" (normally
we are happy about that), but about maintaining the smallest possible
change to the base version.

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

Bug#1056596: lintian could check if source is NMUable / doesn't cause delta due to non-standard dpkg source options

[Julian Andres Klode]

Package: lintian
Severity: wishlist
X-Debbugs-Cc: j...@debian.org

In Bug##1056595 I outlined how dgit overrides dpkg filters
and files like .gitignore appear in tarballs, meaning that
if you download the .dsc and try to NMU it, your NMU suddenly
misses a lot of files.

lintian should check that dpkg-source -x && dpkg-source -b
does not

* add additional files
* remove files
* modify files

Arguably it may be reasonable to parse the Perl bindings
in dpkg to get the ignore list and just check that we don't
ship any ignored files.

Likewise it can ensure that other options like compression of
the tarball matches the dpkg options for that package,
i.e. archive defaults or debian/source/options.

Maybe this is better solved in something like piuparts,
I don't know.

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

Bug#1056595: dgit: must not override dpkg include lists

[Julian Andres Klode]

Package: dgit
Severity: important
X-Debbugs-Cc: j...@debian.org

dgit overrides the include lists for dpkg, causing packages to include
additional .gitignore and similar files which dpkg-source -b will
exclude.

This creates a significant hurdle to the NMU process and downstream
distribution maintainers who have to figure out how to reduce the
delta again, because in both cases, unrelated changes should not
be present in the diff between the two uploads.

Like I had to spend about 20 minutes or so today trying to figure out
how to actually get that sorted out for a native package (I was trying
-i all the time when I should have passed -I), in turn I discovered
some other process issues but that's beside the point :D

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

Kernel: Linux 6.5.0-10-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt2.7.6
ii  ca-certificates20230311ubuntu1
ii  coreutils  9.1-1ubuntu2
ii  curl   8.4.0-2ubuntu1
ii  devscripts 2.23.6build1
ii  dpkg-dev   1.22.1ubuntu2
ii  dput   1.1.3ubuntu3
ii  git [git-core] 1:2.40.1-1ubuntu1
ii  git-buildpackage   0.9.32
ii  libdpkg-perl   1.22.1ubuntu2
ii  libjson-perl   4.1-1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-gettext-perl 1.07-6
ii  libtext-csv-perl   2.03-1
ii  libtext-glob-perl  0.11-3
ii  libtext-iconv-perl 1.7-8
pn  libwww-curl-perl   
ii  perl [libdigest-sha-perl]  5.36.0-9ubuntu1

Versions of packages dgit recommends:
ii  distro-info-data 0.59
ii  liburi-perl  5.21-1
ii  openssh-client [ssh-client]  1:9.4p1-1ubuntu1

Versions of packages dgit suggests:
ii  cowbuilder  0.89
ii  pbuilder0.231build1
ii  sbuild  0.85.2ubuntu1

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

Bug#1055931: apt ignores bullseye-backports

[Julian Andres Klode]

Control: reassign -1 src:linux

On Tue, Nov 14, 2023 at 01:45:21PM +0100, Vincent Lefevre wrote:
> Package: apt
> Version: 2.6.1
> Severity: important
> 
> When I want to report a bug against the Linux kernel, reportbug
> recommends to use bullseye-backports to get a more recent version
> (even though this is currently a bookworm based machine):
> 
> Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of 
> date.
> The following newer release(s) are available in the Debian archive:
>   bullseye-backports (backports-policy): 6.1.55+1~bpo11+1
> Please try to verify if the bug you are about to report is already addressed 
> by these releases.  Do you still want to file a report [y|N|q|?]? 
> 
> So I've added
> 
> deb http://deb.debian.org/debian bullseye-backports main contrib non-free
> 
> as documented in .
> 
> I did an "apt update". In particular:
> 
> [...]
> Get:19 http://deb.debian.org/debian bullseye-backports/main Translation-en 
> [343 kB]
> Get:20 http://deb.debian.org/debian bullseye-backports/main amd64 Contents 
> (deb) [1367 kB]
> Get:21 http://deb.debian.org/debian bullseye-backports/main all Contents 
> (deb) [4773 kB]
> Get:22 http://deb.debian.org/debian bullseye-backports/contrib amd64 Packages 
> [5968 B]
> Get:23 http://deb.debian.org/debian bullseye-backports/contrib Translation-en 
> [6004 B]
> Get:24 http://deb.debian.org/debian bullseye-backports/contrib amd64 Contents 
> (deb) [17.1 kB]
> Get:25 http://deb.debian.org/debian bullseye-backports/contrib all Contents 
> (deb) [22.2 kB]
> Get:26 http://deb.debian.org/debian bullseye-backports/non-free amd64 
> Packages [13.9 kB]
> Get:27 http://deb.debian.org/debian bullseye-backports/non-free 
> Translation-en [27.6 kB]
> Get:28 http://deb.debian.org/debian bullseye-backports/non-free amd64 
> Contents (deb) [10.8 kB]
> Get:29 http://deb.debian.org/debian bullseye-backports/non-free all Contents 
> (deb) [58.5 kB]
> [...]
> 
> But "apt show -a linux-image-6.1.0-13-amd64" just gives the 6.1.55-1
> version (no 6.1.55+1~bpo11+1 version), and
> 
>   apt install -t bullseye-backports linux-image-6.1.0-13-amd64
> 
> also thinks that 6.1.55-1 is the version to be installed.

There is no apt bug here, the backports have linux-image-6.1.0-0.deb11.13 
ABI. I don't know where the hook comes from so I'm just reassigning it
to src:linux.

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

Bug#1041248: keepass update

[Julian Andres Klode]

On Fri, Nov 10, 2023 at 11:36:18PM +0100, Matthias Geiger wrote:
> debdiff attached, I will upload this as a delayed NMU.

I will remove or overwrite any attempt to upload a new version.

As I have explained in the previous comment, this is highly security
sensitive and requires careful review, hence updates aside from CVEs
can only happen during Christmas break when there's time to review
the code.

I do not appreciate an NMU when I have clearly outlined my position
on the topic and am generally responsive.

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


signature.asc
Description: PGP signature

Bug#1029125: Please update to a 2.x version

[Julian Andres Klode]

Control: affects -1 src:gmailieer
Control: severity -1 normal

On Wed, Jan 18, 2023 at 08:42:42AM +0100, Sjoerd Simons wrote:
> Source: python-google-auth
> Version: 1.5.1-3
> Severity: wishlist
> 
> Hey,
> 
> Version 2.0 was released well over a year ago now :). It would be great to
> update to a reent 2.x version

The old version renders lieer unusable:

Traceback (most recent call last):
  File "/usr/bin/gmi", line 24, in 
g.main ()   
  File "/usr/share/lieer/lieer/gmailieer.py", line 418, in main
args.func(args) 
  File "/usr/share/lieer/lieer/gmailieer.py", line 498, in sync
self.remote.get_labels()
  File "/usr/share/lieer/lieer/remote.py", line 138, in func_wrap
self.authorize()
  File "/usr/share/lieer/lieer/remote.py", line 495, in authorize
self.credentials = self.__get_credentials__()
   ^^
  File "/usr/share/lieer/lieer/remote.py", line 560, in __get_credentials__
self.__store_credentials__(credential_path, credentials)
  File "/usr/share/lieer/lieer/remote.py", line 509, in __store_credentials__
storage.write(credentials.to_json())
  ^^^
AttributeError: 'Credentials' object has no attribute 'to_json'


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

Bug#932491: python3-apt: segfault reading from lzma stream

[Julian Andres Klode]

Control: clone -1 -2
Control: retitle -2 python3-apt: add support for non-gzip compressed file 
objects
Control: severity -2 wishlist

On Thu, Nov 02, 2023 at 01:18:23PM +0100, Cyril Brulebois wrote:
> Cyril Brulebois  (2023-11-02):
> > Today I had a few more minutes to spend on this, so here's a little
> > debugging session. My main system is still bullseye, but the same tests
> > in a bookworm chroots fail the same way.
> 
> “But maybe it's a bug in the lzma library?” one might ask.
> 
> Adding a bzip2 test between gzip and lzma leads to the following, again
> on both bullseye and bookworm (after creating a Test.bz2/Packages.bz2
> from one of the other files):
> 
> With bug-932491-aa.py (bug-932491-a.py + bzip2):
> 
> $ ./bug-932491-aa.py Test
> gz == bz: True
> gz == xz: True
> gz: section 1 size: 29
> gz: section 1 keys: ['Package', 'Desc']
> gz: section 2 size: 47
> gz: section 2 keys: ['Package', 'Desc']
> Traceback (most recent call last):
>   File "/home/kibi/tmp/./bug-932491-c.py", line 37, in 
> tf_bz.step()
> apt_pkg.Error: E:Unable to parse package file  (1)
> 
> $ ./bug-932491-aa.py Packages
> gz == bz: True
> gz == xz: True
> gz: section 1 size: 1281
> gz: section 1 keys: ['Package', 'Version', 'Installed-Size', 
> 'Maintainer', 'Architecture', 'Depends', 'Pre-Depends', 'Description', 
> 'Homepage', 'Description-md5', 'Tag', 'Section', 'Priority', 'Filename', 
> 'Size', 'MD5sum', 'SHA256']
> gz: section 2 size: 585
> gz: section 2 keys: ['Package', 'Version', 'Installed-Size', 
> 'Maintainer', 'Architecture', 'Pre-Depends', 'Suggests', 'Description', 
> 'Homepage', 'Description-md5', 'Tag', 'Section', 'Priority', 'Filename', 
> 'Size', 'MD5sum', 'SHA256']
> bz: section 1 size: 1410
> Segmentation fault
> 
> With bug-932491-bb.py (bug-932491-b.py + bzip2):
> 
> $ ./bug-932491-bb.py Test
> gz packages: 2
> Traceback (most recent call last):
>   File "/home/kibi/tmp/./bug-932491-bb.py", line 26, in 
> for stanza in tf_bz:
> apt_pkg.Error: E:Unable to parse package file  (1)
> 
> $ ./bug-932491-bb.py Packages
> gz packages: 50771
> Traceback (most recent call last):
>   File "/home/kibi/tmp/./bug-932491-bb.py", line 27, in 
> bz_packages.append(stanza['Package'])
>~~^^^
> KeyError: 'Package'
> 
> 
> It looks like we might be getting chunks of different sizes depending on
> the underlying file objects, and some buffering/seeking code is buggy on
> the apt_pkg side?

You are literally just fuzzing the tagfile parser with compressed
streams, there is no decompression going on.

We don't talk to the the file-like object you pass to at all, we just
call it's fileno() method to get the underlying file descriptor, and
then apt's gzip support reads from that, and that works automagically
because zlib just passes through uncompressed content.

If you want it to automatically guess the compressor, you can do that
by passing a filename with the right file extension.

For existing open files, the right way to approach this arguably is
o provide apt_pkg.FileFd bindings to the FileFd class such that you
can specify a decompressor, and then parse the FileFd to TagFile.

But I think this is a different issue than the segfault because we
probably still should not be segfaulting on fuzzing with random
data like you do, we probably ought to error out at some point.


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


signature.asc
Description: PGP signature

Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Julian Andres Klode]

OK,

it seems my original email got lost somewhere in tech hickups,
it's possible the kernel crashed before sending the email, AMD
just crashes once or twice a day.

So I'm writing this email a bit in a hurry, so it's not quite
as thought out as the last one weeks ago, but yesterday's email
was pretty concerning.

We should not rush this. we need to be realistic that this will
take a couple of months to sort out a new scheme, don't expect
this to be done before the end of the year, and that seems to
be very optimistic.

On Sat, Oct 07, 2023 at 04:53:33PM +0200, Bastian Blank wrote:
> Moin
> 
> On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> 
> This is now
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.
> 
> > ## Image packages contains more version info
> > 
> > Example: linux-image-6.5.3-cloud-arm64
> 
> > It will not longer be possible to reliably derive the package name from
> > kernel release (see above), as both values are not really related
> > anymore.

This package name seems to be missing the Debian release, which is
mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in
parallel, which again is mandatory. That's not something we can
compromise on; it's absolutely vital that

- you can revert to the kernel you last booted succesfully, i.e. 6.5.3-1
  if 6.5.3-2 is broken (think toolchain broke or something on buildds)

- the currently booted kernel is not impacted. This means it must be
  able to load additional modules. Some platforms even require
  additional modules to be loaded to reboot, I've seen this on
  laptops.

  It is fine to say "you must reboot", but it is not fine to just
  break the running system until you do.

> 
> I missed that apt does something similar (maintainers cced).  It wants
> to see if a particular package matches the current kernel to make the
> autoremove prevention work.  That lookup is quite a hard problem.
> 
> What should work:  We define a new control field.  It contains both the
> kernel name and a version prefix. 
> 
> Example:
> - Linux 6.6 (would match 6.6-1, 6.6.1-1)
> - Linux 6.6.3 (would match 6.6.3-1, but not 6.6.3+2-1)
> - Linux 6.6.3+2
> 
> The algorithm would be something like this:
> - Check $(uname -s) against the first word.  Otherwise completely
>   ignore.

Needless to say I do not believe that uname -s is necessarily a
single word.

> - Check if $(uname -r) matches the version prefix in this field.  Mark
>   as keep if it matches.
> - Aggregate packages by version prefix.
> - Sort as version, keep newest two(?).

I don't really care about the ordering, I want to order by package
version.

I need to identify:

* Which kernel image package is currently booted. Hence I need to
  go from the uname -r to exactly one installed kernel image package
  that acts as the key package to determine if a kernel version is
  installed.

* What are other installed kernel image packages

* Given a uname / kernel image package, which other kernel packages
  belong to it

This allows me to keep the currently installed kernels around.

The flip side of the coin is the code in APT that actually autoremoves
kernels: It needs to identify, given a list of kernel images to keep
which other kernel packages can be removed. Optimally it can still
remove headers for 6.6 if you don't even have 6.6 images installed
anymore and _somehow_ pulled them in.

Essentially I want to order kernel image packages by version,
and keep the currently booted and the latest one, and the 2nd
latest if currently booted == latest one, and then remove any
other versioned kernel package not related to them.

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

Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Julian Andres Klode]

On Thu, Oct 26, 2023 at 01:36:50PM +0200, Bastian Blank wrote:
> On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> > Or would it be easier to re-use normal dependency resolving, like:
> > Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> > This would allow full flexibility and re-uses existing code to check
> > such definitions.
> 
> Okay, noone complained, so it looks like this should work.
> 

No no it doesn't. Did nobody read my email? Did I even send my
email? I don't know what the hell is going on here, but I spend
an hour writing an email discussing the options outlined before
this ridiculousness and the requirements, but I can't find it
in my notmuch.

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

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Julian Andres Klode]

On Fri, Oct 13, 2023 at 10:29:10AM -0400, Antoine Beaupré wrote:
> On 2023-10-12 21:25:20, Kyle Fazzari wrote:
> > On 10/11/23 22:45, Antoine Beaupré wrote:
> >> On 2023-10-11 22:30:16, Kyle Fazzari wrote:
> >>> On 10/11/23 19:24, Antoine Beaupré wrote:
> >> 
> >> [...]
> >> 
> >>> Yeah I won't lie, my immediate thought was "huh, I've never seen that
> >>> happen." Then my follow-up was "actually, how would I even know?" But at
> >>> the same time, I could make that argument for a lot of collectors! Is
> >>> there an established pattern for gathering this kind of data?
> >> 
> >> Filing a timestamp and duration of the last run is typical.
> >
> > Very good.
> >
> > By the way, I came across this Ubuntu bug today, which sounds eerily 
> > familiar, no?
> >
> >  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851
> 
> Oh wow, so that would mean a bug in APT itself. And a regression too,
> because we certainly never witnessed this in buster or bullseye...
> 
> I wonder if we should clone this bug into apt...

If you use apt-cacher-ng, stop using it. apt is *not* compatible
with apt-cacher-ng. We already have bugs for that, and the only
way things will change is if we gets https HTTP/2 on the mirrors
and then can switch to libcurl.

Also please do not run apt update in the background or try to
calculate dist upgrades, that is evil and you're breaking stuff.
If you want to check for updates, make sure the periodic apt service
is configured to run. You are entitled to one run per day. If you
do not operate the mirror infrastructure please do not run your own
updates out of band.

Then you may calculate the upgrade, but don't open the cache
with locking so you don't go block other clients.

Generally speaking it is likely that we will come up with a daemon
on the road to Ubuntu 26.04 that you can ask to check for updates
if it hasn't (again please don't if you don't own your infra) and
then query for available upgrades; but it's nothing for the next 12 months.

Also Kyle's emails don't arrive at all, well one did in the
entire thread.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1053712: python3-apt: Please make network errors downloading changelogs visible to caller

[Julian Andres Klode]

Control: notfound -1 2.6.0ubuntu1
Control: found -1 2.6.0

On Mon, Oct 09, 2023 at 08:03:44AM -0400, Jonathan Kamens wrote:
> Package: python3-apt
> Version: 2.6.0ubuntu1
> Severity: normal
> 
> My use case of apt.package.Package.get_changelog needs to know whether
> a changelog failed to download because it is not available on the
> server vs. it failed because of a connectivity issue with the server.
> Right now the function completely masks that information, simply
> returning a string in both cases. I can't try to parse the string to
> extract the information because it's not always explicit and because
> it's internationalized so that's a whole can of worms.
> 
> I know you probably can't change the default behavior of the
> get_changelog function because too many things depend on it, but two
> other options would be to (a) add a lower-level function that just
> tries to do the download and lets exceptions bubble up instead of
> catching them and turning them into strings, or (b) add a keyword
> argument to get_changelog which enables bubbling up exceptions instead
> of converting them to strings.

I'm afraid that this is not an option. I noticed the code is currently
using Python URL downloading facilities which is a bug, it should be
using apt_pkg.Acquire instead (and really it should use APT's native
changelog support instead of partially badly reimplementing it).

APT's error handling meanwhile does not have error codes or anything
so all you get back is an apt_pkg.Error which is not going to help
you.

This is something I want to address for the APT 3.0 API break in
April so it's possible that we can have this addressed in 9 months
or so, but it's not a priority as people should not be using the
'apt' set of Python modules anyhow, but use apt_pkg directly; and
the fix essentially will be adding apt_pkg.AcquireChangelog class
and may not involve any changes to apt.package.

There is a limited set of utility functions that we should make
available on top of apt_pkg, and then we really need to raise
DeprecationWarning.

People write so many broken incredibly slow code by using the
apt modules that it is not funny. The API is utterly misleading
and destructive.

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

Bug#1053559: Feature: argon2id support

[Julian Andres Klode]

On Fri, Oct 06, 2023 at 01:36:04PM +0300, Alexey Kuznetsov wrote:
> > Feel free to land the support upstream, but it's not something that
> > we should be shipping downstream.
> 
> I report upstream. But seems like it not going to be fixed anytime
> soon. So, I share my smartmem.patch here. But I have no idea how it
> works here at Debian. Maybe I better to keep it as is, rebuilding grub
> locally.

Regarding the memory allocation, it is much more complex than you think
it is. Unfortunately plenty of devices have broken firmware and will
fail to work with allocations over 4GB, some just DMA files to different
regions when you pass them high memory.

Luckily we managed to fit most initrds into 4GB now so we're probably
safe for now if you don't do crazy things like high-memory password
hashing.

> 
> > Going forward, for secure boot, our focus is not on adding things,
> but on removing
> > existing things like f2fs file support again. It stands to reason
> > that encrypted /boot should not be supported either as there is no
> > practical use case (it is security by obscurity) and you are better
> > served by an unencrypted boot with a pre-built signed initrd or
> > a MOK-signed initrd (or really UKI), and decrypting untrusted data
> > hence is unnecessary danger.
> > 
> 
> Saying things I put in my pocket are untrusted, but items gaven to me
> by other guys with sign, are trusted?! That how security treated here
> at debian from all members?

I have absolutely no idea what you're saying, but as you may have seen
by the recent CVE again, we have a lot of problem with code quality and
need to minimize the attack surface as much as reasonably possible.

> 
> Beside security point, having hudge many GB boot partition with all
> kernel installed is a pain. I keep my EFI under 50MB for binaries to
> boot.

In an optimal world, /boot would be a separate FAT partition (or well
the ESP directly) and kernels would be copied there [and would be UKI
with pre-built initrd] and we would not have any support for other
file systems or luks or crap. Heck optimally we'd not have any disk
drivers and file systems and just use the firmware implementations :D

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

Bug#1053559: Feature: argon2id support

[Julian Andres Klode]

Control: tag -1 wontfix upstream

On Fri, Oct 06, 2023 at 12:51:40PM +0300, Alexey Kuznetsov wrote:
> Package: grub-efi-amd64-bin
> 
> Dear Maintainer,
> 
> I managed to install argon2i patches from Arch repo and it works!
> But argon2 may fail on some system due to lack of memory error and
> makes some systems unbootable.
> 
> In short: grub2 by default on x64 machines only allocates memory only
> from first 4GB (0x1000) physical address to avoid EFI bugs (which
> are very common, when programmers EFI using 32bit register for pointers,
> which as result causing EFI to crash when system sends x64 bit pointers
> during IO proc calls). As result not every machines has enough (1GB
> continuous) memory for argon2id keys. So we need allocate memory from higher
> regions >4gb. I wrote a smartmem.patch (hack, since it need more work).
> 
> You need argon_*.patch:
> 
> * https://aur.archlinux.org/packages/grub-improved-luks2-git
> 
> smartmem.patch (allow to allocate >4gb if original allocation <4gb
> fails)
> 
> This is my original conversation (about smartmem.patch >4gb patch):
> 
> * https://savannah.gnu.org/bugs/index.php?64471

Feel free to land the support upstream, but it's not something that
we should be shipping downstream.

Going forward, for secure boot, our focus is not on adding things, but on 
removing
existing things like f2fs file support again. It stands to reason
that encrypted /boot should not be supported either as there is no
practical use case (it is security by obscurity) and you are better
served by an unencrypted boot with a pre-built signed initrd or
a MOK-signed initrd (or really UKI), and decrypting untrusted data
hence is unnecessary danger.

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

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Julian Andres Klode]

On Fri, Sep 29, 2023 at 10:36:03PM +0200, Sebastian Andrzej Siewior wrote:
> On 2023-09-27 21:45:03 [-0400], Jon DeVree wrote:
> > I posted an updated v3 version of the patch:
> > 
> > https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00110.html
> 
> Just rebuilt grub with v3 of the patch and I can confirm that it works.
> Thank you.
> 
> Referencing the message-id or the link to lore
>   https://lore.kernel.org/all/20230928004354.32685-1-n...@vault24.org
> 
> makes it easier to grab the patch. The GNU list archive contains html
> encoding among other things which make it imposible…

Being subscribed to the mailing list, grabbing the patch and applying
it and shipping it isn't hard, but if you were wondering why it's
not fixed, it hasn't been merged or received a Reviewed-By yet;
and I don't really want to carry file system (parser) patches
outside of upstream for security reasons, needing separate
revocation if that is broken.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1053186: apt dist-upgrade wants to remove manually installed packages

[Julian Andres Klode]

Control: severity -1 wishlist

On Thu, Sep 28, 2023 at 11:31:56PM +, Witold Baryluk wrote:
> Package: apt
> Version: 2.7.3
> Severity: important
> X-Debbugs-Cc: witold.bary...@gmail.com
> 
> Hi.
> 
> Happens in 2.7.3 and 2.7.6
> 
> When on testing and unstable.  (as of this writing)
> 
> root@debian:~# apt dist-upgrade  --purge  -V
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Calculating upgrade... Done
> The following packages were automatically installed and are no longer 
> required:
>erlang-dev (1:25.2.3+dfsg-1)
>erlang-dialyzer (1:25.2.3+dfsg-1)
>erlang-diameter (1:25.2.3+dfsg-1)
>erlang-edoc (1:25.2.3+dfsg-1)
>erlang-erl-docgen (1:25.2.3+dfsg-1)
>erlang-eunit (1:25.2.3+dfsg-1)
>erlang-examples (1:25.2.3+dfsg-1)
>erlang-jinterface (1:25.2.3+dfsg-1)
>erlang-megaco (1:25.2.3+dfsg-1)
>erlang-mode (1:25.2.3+dfsg-1)
>erlang-odbc (1:25.2.3+dfsg-1)
>erlang-src (1:25.2.3+dfsg-1)
>erlang-ssh (1:25.2.3+dfsg-1)
>gir1.2-javascriptcoregtk-4.0 (2.42.0-1)
>gir1.2-javascriptcoregtk-6.0 (2.42.0-1)
>libaom-dev (3.7.0~really3.6.1-1)
>libcld2-0 (0.0.0-git20150806-9)
>libcolord-gtk1 (0.3.0-4)
>libcpprest2.10 (2.10.18-1+b1)
>libdav1d-dev (1.2.1-2)
>libde265-dev (1.0.12-2)
>libheif-dev (1.16.2-2+b1)
>libjavascriptcoregtk-6.0-1 (2.42.0-1)
>liblucene++0v5 (3.0.8-8)
>libosmgpsmap-1.0-1 (1.2.0-2)
>libvpx-dev (1.12.0-1)
>poedit-common (3.3.2-2)
>python3-arrow (1.2.3-1)
>python3-listparser (0.18-3)
>python3-readability (0.8.1+dfsg1-3)
>python3-syndom (1.0-2)
> Use 'apt autoremove' to remove them.
> The following packages will be REMOVED:
>darktable* (4.4.2-1)
>erlang* (1:25.2.3+dfsg-1)
>erlang-common-test* (1:25.2.3+dfsg-1)
>erlang-debugger* (1:25.2.3+dfsg-1)
>erlang-et* (1:25.2.3+dfsg-1)
>erlang-observer* (1:25.2.3+dfsg-1)
>erlang-reltool* (1:25.2.3+dfsg-1)
>erlang-wx* (1:25.2.3+dfsg-1)
>gir1.2-webkit-6.0* (2.42.0-1)
>gir1.2-webkit2-4.0* (2.42.0-1)
>gnome* (1:44+1)
>gnome-calendar* (45.0-1)
>gnome-feeds* (2.2.0-2)
>gnome-initial-setup* (45.0-1)
>kimageformat-plugins* (5.107.0-3)
>libavif-dev* (0.11.1-3+b1)
>libedataserverui4-1.0-0* (3.50.0-1)
>libgd-dev* (2.3.3-9)
>libwebkit2gtk-4.0-37* (2.42.0-1)
>libwebkitgtk-6.0-4* (2.42.0-1)
>libwxgtk-webview3.2-1* (3.2.2+dfsg-4)
>network-manager-openconnect-gnome* (1.2.10-1)
>poedit* (3.3.2-2)
>rebar* (2.6.4-3)
> The following packages have been kept back:
>gnuradio (3.10.5.1-3 => 3.10.7.0-3+b2)
>gnuradio-dev (3.10.5.1-3 => 3.10.7.0-3+b2)
>libavif15 (0.11.1-3 => 0.11.1-3+b1)
>libavif15:i386 (0.11.1-3 => 0.11.1-3+b1)
>libomp-dev (1:14.0-55.7 => 1:16.0-57)
>lldb (1:14.0-55.7 => 1:16.0-57)
>svt-av1 (1.6.0+dfsg-1 => 1.7.0+dfsg-2)
> The following packages will be upgraded:
>libmpfr6 (4.2.0-1 => 4.2.1-1)
>librados2 (16.2.11+ds-2 => 16.2.11+ds-3)
>librbd1 (16.2.11+ds-2 => 16.2.11+ds-3)
> 3 upgraded, 0 newly installed, 24 to remove and 7 not upgraded.
> Need to get 6,494 kB of archives.
> After this operation, 213 MB disk space will be freed.
> Do you want to continue? [Y/n] 
> 
> 
> 
> It is trying to remove erlang, gnome, dartkable, and few more programs
> that were installed explicitly.

The solver does not distinguish between manually and automatically
installed packages. I'm trying to find the time to write a new solver
from scratch because essentially if you dare touch that it's going
to explode in other bits, but I can't make any promises. You can
track work in

https://salsa.debian.org/apt-team/solver3

Like consider you installed foo manually and it got renamed bar, you
want to remove foo and install bar when you upgrade. But if you try to
teach that to apt's existing solver it will go fail in all sorts of
hilarious places because it's 30 year spaghetti code that's not
capable of running with that many restrictions.

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

Bug#1053151: unblock: apt/2.7.6

[Julian Andres Klode]

On Thu, Sep 28, 2023 at 11:32:26AM +0200, Julian Andres Klode wrote:
> On Thu, Sep 28, 2023 at 11:22:44AM +0200, Julian Andres Klode wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: unblock
> > X-Debbugs-Cc: a...@packages.debian.org, j...@debian.org, 
> > debian-c...@lists.debian.org
> > Control: affects -1 + src:apt
> > 
> > Please unblock package apt (well remove the sramacher block)
> > 
> > apt 2.7.5 was blocked last week by sramacher because there were
> > arguments it broke chroots. The concerns have been addressed 
> > promptly in 2.7.6 by downgrading the error to 2 warnings.
> > 
> > Sebastian has been ignoring me since raising the issue and
> > instituting the block.
> 
> Please also override the age to 10 though, or remove the block
> on Monday / end of Sunday; it's mostly I want to have some
> confirmation, not an immediate unblock, I don't believe that
> is strictly necessary to migrate precisely now.
> 
> I do think this was an unnecessary use of power given that
> we did have an RC bug preventing the transition due to the
> added error and another one could have been filed instead
> if so wished.
> 
> For more context: apt 2.7.5 instituted an error on unmerged-usr
> systems to prevent people from running into broken maintainer
> scripts due to running on unsupported system layouts; apt
> 2.7.6 turned this into a warning before the Y/n prompt and
> a warning at the end of the run so that you can't miss it.

It seems there has been some misunderstanding on my side.

In my mind, I wanted to not "escalate" this to the team and
give Sebastian the chance to take care of this himself, which
is why I pinged him on Monday after not hearing since Wednesday
and then only send the email today after it's been a total of
8 days.

I understand now that I should have just asked the team directly,
and want to apologize if I caused any grief. The whole merged-usr
topic is pretty heated, and I realize that the way I mistakingly
framed this was not the most constructive way to make progress.

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

Bug#1053151: unblock: apt/2.7.6

[Julian Andres Klode]

On Thu, Sep 28, 2023 at 11:22:44AM +0200, Julian Andres Klode wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: a...@packages.debian.org, j...@debian.org, 
> debian-c...@lists.debian.org
> Control: affects -1 + src:apt
> 
> Please unblock package apt (well remove the sramacher block)
> 
> apt 2.7.5 was blocked last week by sramacher because there were
> arguments it broke chroots. The concerns have been addressed 
> promptly in 2.7.6 by downgrading the error to 2 warnings.
> 
> Sebastian has been ignoring me since raising the issue and
> instituting the block.

Please also override the age to 10 though, or remove the block
on Monday / end of Sunday; it's mostly I want to have some
confirmation, not an immediate unblock, I don't believe that
is strictly necessary to migrate precisely now.

I do think this was an unnecessary use of power given that
we did have an RC bug preventing the transition due to the
added error and another one could have been filed instead
if so wished.

For more context: apt 2.7.5 instituted an error on unmerged-usr
systems to prevent people from running into broken maintainer
scripts due to running on unsupported system layouts; apt
2.7.6 turned this into a warning before the Y/n prompt and
a warning at the end of the run so that you can't miss it.

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

Bug#1053151: unblock: apt/2.7.6

[Julian Andres Klode]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: a...@packages.debian.org, j...@debian.org, 
debian-c...@lists.debian.org
Control: affects -1 + src:apt

Please unblock package apt (well remove the sramacher block)

apt 2.7.5 was blocked last week by sramacher because there were
arguments it broke chroots. The concerns have been addressed 
promptly in 2.7.6 by downgrading the error to 2 warnings.

Sebastian has been ignoring me since raising the issue and
instituting the block.

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

Bug#1038974: grub2: Update Linux erases Windows entry in boot list

[Julian Andres Klode]

On Fri, Sep 22, 2023 at 04:36:37AM +0100, Chris Carr wrote:
> On Thu, 21 Sept 2023, 14:28 Julian Andres Klode, 
> wrote:
> 
> > Control: retitle -1 grub doesn't run os-prober by default anymore, so no
> > more other OS detected
> > Control: tag -1 wontfix
> >
> > On Fri, Jun 23, 2023 at 04:31:55PM -0400, bud wrote:
> > > Package: grub2
> > > Severity: important
> > > File: grub2
> > > X-Debbugs-Cc: budheal...@gmail.com
> > >
> > > Dear Maintainer,
> > >
> > >* What led up to the situation?
> > > I installed the 2023-04-24 weekly build, downloaded the 2023-06-05 build
> > and used that as the jigdo base to download bookworm 12.0.0
> > > Then I added the 21 DVD images and synaptic suggested adding the online
> > main repository. After apt-get update --allow-insecure-repositories, I
> > rebooted.
> > >* What exactly did you do (or not do) that was effective (or
> > >  ineffective)?
> > > The computer booted into bookworm. However, the existing option to boot
> > Windows is no longer available. Looking in the Advanced options finds the
> > prior Linux entry.
> > >
> > > Compare Bugs #1033985, #1008294 and #250626
> > >
> > >* What was the outcome of this action?
> > > Without a Windows option, there is a suggestion in bug #1033985 that
> > os-prober will help set me reset the grub list. Otherwise, the Windows DVD
> > will contrarily erase grub. I only added a Linux partition to this laptop
> > to investigate a HDMI bug, as this one has HDMI, VGA and DisplayPort
> > connectors.
> > >* What outcome did you expect instead?
> > > Just because the Linux kernel has been updated, any existing entries
> > should not be erased - except for the one being replaced.
> > >
> > > An update should not erase the settings the user or administrator has
> > added to customize the system. This looks like a bug.
> >
> > The followup comment from Chris Carr made me understand that this seems
> > to be about the os-prober entries. For security reasons, os-prober is
> > no longer run when writing a new grub.cfg.
> >
> > You can either re-enable it and get exposed to any bug in grub
> > filesystem implementations which will then run as root to mount
> > any disk attached to the system, or add a /etc/grub.d file that
> > echos additional fixed boot entries for your other OS.
> >
> 
> 
> But this still leaves the user significantly worse off than before the
> update. A very small proportion of users will be knowledgeable enough to
> write their own /etc/grub.d file without instructions (I'm not) or
> confident enough to re-enable OS-prober after the update tells them it's an
> attack vector (I am).
> 
> It feels like the correct behaviour is to look at the existing entries at
> the start of the update and write a grub.d file on the user's behalf. There
> aren't going to be many users who want to lose access to an OS on updating
> grub.

It's no secret that we ship a patch in Ubuntu to keep running
os-prober if the existing grub.cfg has os-prober entries in it to
avoid the regression, but the ship has sailed for Debian, everyone
has received the update by now, so introducing it again isn't helping
anyone (arguably the patch keeps it on if you install fresh but that
wasn't my personal decision).

If you are interested in multi boot via grub menum, my suggestion would
be to invest the time to write the code to do os-probing from grub. The
most important piece - dual booting windows can be easily done by
checking if the correct windows files exist and then adding a boot
entry.

Ultimately this is becoming less and less a priority for people because
it doesn't even work. If you have Windows installed in a normal setup,
it does its TPM based Bitlocker encryption, you won't be able to start
it via grub anyhow, but have to boot via the firmware menu. Same for
other OS, as we move forward to increasingly TPM encrypt OS, dual
booting only works without a foreign grub in the chain.

What I do want to do is add a boot menu to grub to allow you to boot
other OS in the boot menu by setting BootNext and resetting the machine;
but I don't think there's much value to be had sinking considerable
resources into legacy boot multi booting.

And yes, I want to also add that Windows detection, but I think that's
a reasonable level of regression for the security benefits.

Alternatively if you feel you need os-prober because you install
multiple Linux distributions in a BIOS system, I mean, by all means
enable it and live with the risk or work to sandbox grub-mount, I think
it could just drop its privileges after opening the device and install
seccomp filters and whatnot.

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

Bug#1038974: grub2: Update Linux erases Windows entry in boot list

[Julian Andres Klode]

Control: retitle -1 grub doesn't run os-prober by default anymore, so no more 
other OS detected
Control: tag -1 wontfix

On Fri, Jun 23, 2023 at 04:31:55PM -0400, bud wrote:
> Package: grub2
> Severity: important
> File: grub2
> X-Debbugs-Cc: budheal...@gmail.com
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> I installed the 2023-04-24 weekly build, downloaded the 2023-06-05 build and 
> used that as the jigdo base to download bookworm 12.0.0
> Then I added the 21 DVD images and synaptic suggested adding the online main 
> repository. After apt-get update --allow-insecure-repositories, I rebooted.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> The computer booted into bookworm. However, the existing option to boot 
> Windows is no longer available. Looking in the Advanced options finds the 
> prior Linux entry. 
> 
> Compare Bugs #1033985, #1008294 and #250626
> 
>* What was the outcome of this action?
> Without a Windows option, there is a suggestion in bug #1033985 that 
> os-prober will help set me reset the grub list. Otherwise, the Windows DVD 
> will contrarily erase grub. I only added a Linux partition to this laptop to 
> investigate a HDMI bug, as this one has HDMI, VGA and DisplayPort connectors.
>* What outcome did you expect instead?
> Just because the Linux kernel has been updated, any existing entries should 
> not be erased - except for the one being replaced. 
> 
> An update should not erase the settings the user or administrator has added 
> to customize the system. This looks like a bug.

The followup comment from Chris Carr made me understand that this seems
to be about the os-prober entries. For security reasons, os-prober is
no longer run when writing a new grub.cfg.

You can either re-enable it and get exposed to any bug in grub
filesystem implementations which will then run as root to mount
any disk attached to the system, or add a /etc/grub.d file that
echos additional fixed boot entries for your other OS.

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

Bug#910377: System-critical package management

[Julian Andres Klode]

On Mon, Sep 18, 2023 at 12:24:20PM +0200, Guillem Jover wrote:
> While dpkg on systems using systemd _could_ by default take an
> system inhibitor lock, and could provide a good enough reason like say
> "Packaging system upgrade" or whatever, my concern has been with the
> added dependency chain, and after reading your mail and thinking about
> this now, I have to agree this seems like a higher level policy.
> (Of course dpkg could also do that and grow a new --no-inhibit,
> or --refuse-inhibit or similar option, but still.)
> 
> But then, I recalled I had a git branch adding a dpkg-db-lock command
> with a --wait-lock option, that I could recover and polish to provide
> an example pre-hook script that would call that via a background
> systemd-inhibit if systemd is running and the command is available,
> where an admin that wanted to do that for their system or fleet of
> systems could hook into the dpkg config. I've done that locally, and
> will check whether that's viable and probably merge it for 1.22.1
> or 1.22.2, so that people that want to do it can easily do so.

I'm not sure how that works because you'd need to respawn yourself
with systemd-inhibit, whereas the API essentially gives you a file
descriptor over dbus that you keep open until it is safe to reboot.

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

Bug#981594: neomutt: Please use openssl

[Julian Andres Klode]

Package: neomutt
Followup-For: Bug #981594
X-Debbugs-Cc: j...@debian.org

OpenSSL is now also licensed under the Apache license, and GnuTLS
does not support Let's encrypt certificates as used on gmane.io,
complaining about the expired DST Root CA X3.

OpenSSL supports this Let's encrypt root CA change just fine, so
please just build with it.

I can also file a separate bug about gmane.io, but arguably the
solution here should be clear.

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

Bug#1052058: apt: refuses to downgrade itself to a version that works on the system

[Julian Andres Klode]

Control: severity -1 serious

As maintainer, I do consider this a blocker for testing migration.

On Sat, Sep 16, 2023 at 08:36:21PM +0200, Adam Borowski wrote:
> Package: apt
> Version: 2.7.5
> Severity: important
> 
> 
> Once again we have a package that some people consider broken.  That's
> natural, disagreements happen.  That apt insists on a bad scheme not
> supported by dpkg has been said about elsewhere.  Normally, that would
> be solvable by a simple downgrade.
> 
> Except, in this case, apt refuses to do this:
> 
> # apt install apt=2.7.3 apt-utils=2.7.3
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Suggested packages:
>   apt-doc
> The following packages will be DOWNGRADED:
>   apt apt-utils
> 0 upgraded, 0 newly installed, 2 downgraded, 0 to remove and 2 not upgraded.
> E: /bin resolved to a different inode than /usr/bin
> E: Unmerged usr is no longer supported, install usrmerge to continue.
> N: See 
> https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#a-merged-usr-is-now-required
>  for more details.
> 
> As you can see, the action I requested specifically solves the problem,
> yet apt considers it no good.  Thus, I'd need to take steps that are not
> obvious to a regular user, and for this specific package risky to break the
> system if done wrong.
> 
> Thus, apt should consider an operation that touches apt itself to be
> another exception for the usrmerge demand.

Thank you for your bug report.

I have considered the situation and I believe that all downgrades
should be considered safe operations, so as long as all operations
are downgrades, they may go ahead.

On the flip side, this also shows we need to build mechanisms to
ensure repositories are not being used by apt versions that do
not support the features required by the repositories, so we
will be implementing a feature flag mechanism in Release files
to that effect.

Perhaps we should also have a Depends field in Release files
so that repositories can list minimum versions of essential
packages.

This would have addressed this issue in that you could downgrade
but would be unable to continue to use Debian repositories.

Perhaps more importantly, this allows us to roll out critical
fixes to stable-updates and enforce that users have upgraded
to those when upgrading to testing.

This will severely improve our ability to deal with upgrade
problems outside of hacking package dependencies or hoping
people read release notes.

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

Bug#1051251: /usr/sbin/grub-mkconfig: 300: /etc/grub.d/25_bli: not found due to wrong shell location

[Julian Andres Klode]

On Sun, Sep 17, 2023 at 01:18:19AM +0200, gregor herrmann wrote:
> On Sat, 16 Sep 2023 11:43:41 +0200, Julian Andres Klode wrote:
> 
> > You have literally hacked around the dependencies of the packages by
> > inserting a fake package to pretend to have merged-usr installed to be
> > able to maintain a file system layout the project has decided is no
> > longer supported.
> 
> That's wrong.
> Another option is to put init on hold (at the version before it
> depends on usr-merge).

init-system-helpers is the one specifying the dependency on merged
usr, and it is essential. Packages in testing/unstable may require
all essential packages to be at least at the version used in stable,
therefore that is not a supported configuration either.

>  
> > FWIW, if you people keep being annoying I (with my apt head on) am
> > just going to deliberately make apt error out and refuse any operation
> > on unmerged systems.
> 
> Your communication style is uncacceptable. Please reconsider.

I admit that my choice of words was suboptimal, and I'd like to
apologise for it.

That being said, I went ahead and implemented the feature in
apt 2.7.4/2.7.5 yesterday in a first version. This is a bit
stronger than I might want the final version to be, so you can
expect further adjustments in the following week.

Drew has shown me that people can get into this mess inadvertently
by having followed the temporary warnings in dpkg, and as per social
contract "Our priorities are our users and free software", it is
our duty as maintainers to make sure this doesn't happen.

As for this bug, you can expect it to be resolved in next week's
upload. I do have a couple of further fixes to review and include,
and I was at all systems go last week talking to people.

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


signature.asc
Description: PGP signature

Bug#1051731: apt: [INTL:pt] Update on Portuguese translation of MANPAGE

[Julian Andres Klode]

Control: tag -1 moreinfo

On Mon, Sep 11, 2023 at 09:01:54PM +0100, Américo Monteiro wrote:
> Package: apt
> Version: 2.7.3
> Tags: l10n, patch
> Severity: wishlist
> 
> Updated Portuguese translation for apt's manpage
> Translator: Américo Monteiro 
> Feel free to use it.

Please provide evidence of peer review by the pt translator
email list, I cannot merge translations from a new third party.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1050876: apt-doc:[INTL:fr] updated translation of apt-doc 2.6.1

[Julian Andres Klode]

Control: tag -1 moreinfo

On Wed, Aug 30, 2023 at 07:14:59PM +0200, bu...@no-log.org wrote:
> Package: apt-doc
> Version:2.6.1
> Severity: wishlist
> Tags: patch l10n
> 
> Dear mainteners,
> Hello, please find the updated french translation for apt-doc attached,
> proofread by the debian-l10n-french mailing list contributors.

It doesn't seem we have interacted before and you haven't provided
any proofs to the review claims nor your real name, so I won't be 
picking this up for the time being.

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

Bug#1051251: /usr/sbin/grub-mkconfig: 300: /etc/grub.d/25_bli: not found due to wrong shell location

[Julian Andres Klode]

Control: severity -1 wishlist

On Sat, Sep 16, 2023 at 12:01:36PM +0200, Drew Parsons wrote:
> Control: severity -1 critical
> 
> 
> On 2023-09-16 11:43, Julian Andres Klode wrote:
> > Control: severity -1 wishlist
> > 
> > On Sat, Sep 16, 2023 at 10:36:39AM +0200, Drew Parsons wrote:
> > > Source: grub2
> > > Version: 2.12~rc1-7
> > > Followup-For: Bug #1051251
> > > Control: severity 1051251 critical
> > > 
> > > This is a critical bug.  apt fails on this bug early in its run, and
> > > therefore this one bug is preventing *every* *other* package from
> > > updating.
> > 
> > You have literally hacked around the dependencies of the packages by
> > inserting a fake package to pretend to have merged-usr installed to be
> > able to maintain a file system layout the project has decided is no
> > longer supported.
> 
> I have done literally nothing to change merged-usr status, apart from
> regularly upgrade packages as they come along.

This is not true. init-system-helpers depends on usrmerge | merged-usr, and
merged-usr only installs if your usr is merged, and usrmerge will
convert your system to the supported layout.

And that package is essential.

The only way you end up in that situation is by messing with the
package management system so that you generate a fake package using
equivs or similar that Provides: usrmerge or merged-usr, or using
the buildd workaround. 

Maybe you have followed the warnigns from dpkg that were added by
his hostile maintainer declaring merged-usr to be unsupported and
asking you to run a dangerous dpkg-fsys-usrunmess to mess up your
system.

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

Bug#1051251: /usr/sbin/grub-mkconfig: 300: /etc/grub.d/25_bli: not found due to wrong shell location

[Julian Andres Klode]

Control: severity -1 wishlist

On Sat, Sep 16, 2023 at 10:36:39AM +0200, Drew Parsons wrote:
> Source: grub2
> Version: 2.12~rc1-7
> Followup-For: Bug #1051251
> Control: severity 1051251 critical
> 
> This is a critical bug.  apt fails on this bug early in its run, and
> therefore this one bug is preventing *every* *other* package from updating.

You have literally hacked around the dependencies of the packages by
inserting a fake package to pretend to have merged-usr installed to be
able to maintain a file system layout the project has decided is no
longer supported.

FWIW, if you people keep being annoying I (with my apt head on) am
just going to deliberately make apt error out and refuse any operation
on unmerged systems.

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

Bug#1051514: grub-common: Please remove grub-common.service from boot hot path

[Julian Andres Klode]

On Sun, Sep 10, 2023 at 03:45:52PM +0200, Paul Menzel wrote:
> Dear Andres,
> 
> 
> Thank you for your reply.
> 
> Am 10.09.23 um 13:54 schrieb Julian Andres Klode:
> > On Sat, Sep 09, 2023 at 12:21:29AM +0200, Paul Menzel wrote:
> > > Package: grub-common
> > > Version: 2.12~rc1-9
> > > Severity: normal
> 
> > > The unit `grub-common.service` is installed to the multi-user.target and
> > > therefore run during boot-up, slowing down the boot, especially as shell
> > > commands are used.
> > > 
> > > ```
> > > $ systemctl cat grub-common.service
> > > # /lib/systemd/system/grub-common.service
> > > [Unit]
> > > Description=Record successful boot for GRUB
> > > After=suspend.target hibernate.target hybrid-sleep.target
> > > suspend-then-hibernate.target
> > > ConditionPathExists=/boot/grub/grub.cfg
> > > 
> > > [Service]
> > > Type=oneshot
> > > Restart=no
> > > ExecStartPre=/bin/sh -c '[ -s /boot/grub/grubenv ] || rm -f
> > > /boot/grub/grubenv; mkdir -p /boot/grub'
> > > ExecStart=grub-editenv /boot/grub/grubenv unset recordfail
> > > ExecStartPost=/bin/sh -c 'if grub-editenv /boot/grub/grubenv list | grep 
> > > -q
> > > initrdless_boot_fallback_triggered=1; then echo "grub: GRUB_FORCE_PARTUUID
> > > set, initrdless boot paniced, fallback triggered."; fi'
> > > StandardOutput=kmsg
> > > 
> > > [Install]
> > > WantedBy=multi-user.target suspend.target hibernate.target
> > > hybrid-sleep.target suspend-then-hibernate.target
> > > ```
> > 
> > As you can see, there are no Before relations in the service,
> > so grub-common is not in the hot path, nothing depends on it
> > having finished startup.
> > 
> > I'm sure this was well intended and not a troll attempt, but
> > systemd doesn't start services in a sequence, so services can
> > run in parallel and there is in general very little ordering
> > requirements.
> 
> That is exactly, what I was saying. Due to the missing ordering, systemd
> starts this service as early as possible causing pressure on the possibly
> scarce system resources at the beginning. So care has to be taken
> introducing these things. Looking into decreasing the start time of an
> Ubuntu system once, grub-common showed up there, so it will make the startup
> time of quite a lot of Debian systems longer now too. Please keep in mind,
> that Debian is also run on older systems.

I think bug reports like this are ill-advised, it is not our decision
to make how to start services and abusing timers for this is wrong.

If you want units that do not contribute to the target to run only
when idle, then my suggestion would be to add such a feature to
systemd itself rather than go around trying to hack each such instance
with timers.

That said, I strongly disagree with the assessment. Boot is not
interactive so it is less of a priority to have it fast vs having
a performant interactive session.

On the extreme, if you boot into your desktop and then it eats up
all your cores and locks up the UI on your resource constrained
device that's a worse experience than waiting longer at boot and
then having things work correctly.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1051507: grub-common.service fails on read-only root

[Julian Andres Klode]

Control: tag -1 wontfix

On Fri, Sep 08, 2023 at 09:50:23PM +0200, Jörg Sommer wrote:
> Package: grub-common
> Version: 2.12~rc1-9
> Severity: normal
> 
> Hi,
> 
> my root filesystem (including /boot) is mounted read-only, which makes the
> service grub-common fail:
> 
> ```text
> % journalctl -b -u grub-common
> Sep 08 21:15:44 systemd[1]: Starting grub-common.service - Record successful 
> boot for GRUB...
> Sep 08 21:15:44 grub-editenv[865]: grub-editenv: Fehler: »/boot/grub/grubenv« 
> kann nicht geöffnet werden: Das Dateisystem ist nur lesbar.
> Sep 08 21:15:44 systemd[1]: grub-common.service: Main process exited, 
> code=exited, status=1/FAILURE
> Sep 08 21:15:44 systemd[1]: grub-common.service: Failed with result 
> 'exit-code'.
> Sep 08 21:15:44 systemd[1]: Failed to start grub-common.service - Record 
> successful boot for GRUB.
> ```
> 
> I've added an additional condition:
> 
> ```text
> [Unit]
> ConditionPathIsReadWrite=/boot/grub/gruben
> ```

Write access to the file is a necessity of recording a successful
boot, and hence a failure is the correct outcome here, otherwise
you don't notice the failure.

A write-only /boot should be considered unsupported.

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


signature.asc
Description: PGP signature

Bug#1051469: keepassxc: please update to new upstream release 2.7.6

[Julian Andres Klode]

Control: forcemerge 1041248 -1

On Fri, Sep 08, 2023 at 02:23:11PM +0200, Matthias Geiger wrote:
> Package: keepassxc
> Version: 2.7.4+dfsg.1-2
> Severity: wishlist
> X-Debbugs-Cc: werdah...@riseup.net
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi Julian,
> 
> please consider updating keepassxc to the latest upstream version
> (2.7.6). The version in debian is now almost a year (!) old compared to 
> the latest one (Oct 22 vs. Aug 23). 
> 
> Something as sensible as a password manager should always be 
> the latest version imho, if possible. If you are busy atm I can prepare
> a MR in salsa. Let me know if you want to work together on this.


Unfortunately a password manager is quite sensitive, so it requires
at least a cursory security review for each update. This means that
we effectively need to find a couple days where I'm not working to
undertake that arduous task, which is how we end up with a yearly
feature update over the end of/new year break.

Outside of the yearly feature update I will CVEs and release critical
bugs by applying a targeted patch if possible.

I hope you have a good day and try to look for existing bugs next
time before reporting a duplicate.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Bug#1051412: grub-common: leftover directory

[Julian Andres Klode]

Control: tag -1 confirmed

On Thu, Sep 07, 2023 at 03:40:48PM +0200, Christoph Anton Mitterer wrote:
> Package: grub-common
> Version: 2.12~rc1-9
> Severity: normal
> 
> 
> Hey.
> 
> 
> This package apparently used to contain/create /etc/default/grub.d but no 
> longer
> does so.
> 
> On upgrade:
> Unpacking grub-common (2.12~rc1-9) over (2.06-13) ...
> dpkg: warning: unable to delete old directory '/etc/default/grub.d': 
> Directory not empty
> 
> it's leftover and empty afterwards.
> 
> 
> Could you please clean that up on a future upgrade, so that it doesn't stick
> around for ever on people's systems?

Thank you for your bug report,

I think this is a regression from dropping the
/etc/default/grub.d/init-select.cfg file, we now need
to create an empty directory I suppose.

Cleaning it up would certainly be the wrong choice, after all the reason
it sticks around for you is your local configuration snippets you dropped in
there.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1051304: error: out of memory

[Julian Andres Klode]

On Thu, Sep 07, 2023 at 01:18:31AM -0400, Daniel Richard G. wrote:
> Hi Julian,
> 
> On Wed, 2023 Sep  6 04:17-04:00, Julian Andres Klode wrote:
> >
> > Yes, so please just try the 2.12~rc1-9 in unstable and see if it
> > fixes your issue.
> 
> I've confirmed that this version no longer gives the "out of memory"
> error, and can load and boot the ISO images that previously failed.
> 
> Is this a long way from making it into stable? Or at least -backports?

Things are quite complex with the memory management patch set, while
I have a backport to 2.06 in Ubuntu, I also did not release the final
patch set there yet. There was concern of additional regressions from
that. But we know for sure the current state was regressing some, but
I guess they are all regressed now if that makes sense.

I can try to get the patches together for a stable update, but I think
we might want to wait until the final set landed in Ubuntu updates for
LTS so we don't get the regression potential on both ends (and we have
more control over the update phasing in Ubuntu than Debian).

For a wholesale upload of grub 2.12 to stable, we need to wait for
the final 2.12 release and also we don't plan to do this if we can
backport any security patches coming up to 2.06.

I think generally this is a low priority issue for Debian if you
can't loopback large images, and Debian doesn't have initrds as huge
as Ubuntu so that never became a significant issue.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1051338: lintian: Downgrade wrong-path-for-interpreter from error to pedantic, merged-usr is mandatory now

[Julian Andres Klode]

Package: lintian
Severity: normal

Merged-usr has been mandatory since bookworm, so use of /usr/bin/sh
and such can no longer constitute an error, it's just for pedantic
people who want to stay behind the times and annoy everyone.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1051328: grub-common: wrong-path-for-interpreter /usr/bin/sh != /bin/sh [etc/grub.d/25_bli]

[Julian Andres Klode]

Control: forcemerge 1051251 -1

On Wed, Sep 06, 2023 at 11:20:00AM +0200, Axel Beckert wrote:
> Package: grub-common
> File: /etc/grub.d/25_bli
> Version: 2.12~rc1-7
> Version: 2.12~rc1-9
> Severity: serious
> 
> For some reason, possibly usrmerge-triggered, since 2.12~rc1-7
> /etc/grub.d/25_bli sports the following non-standard shebang line:
> 
>   #!/usr/bin/sh
> 
> as lintian also reports:
> 
>   → lintian grub-common_2.12\~rc1-9_amd64.deb
>   E: grub-common: wrong-path-for-interpreter /usr/bin/sh != /bin/sh 
> [etc/grub.d/25_bli]
> 
> Interestingly only this single file seems to be affected.

Merged-usr has been mandatory since bookworm so we have opted
not to ship a patch for this, but it has been addressed in the
upstream git branch and will be fixed in the final 2.12 release.

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

Bug#1051292: grub-efi-amd64 post install script 10_linux.orig fails with locally compiled kernel

[Julian Andres Klode]

On Wed, Sep 06, 2023 at 10:16:19AM +0200, tv.debian wrote:
> Le 06/09/2023 à 09:21, Julian Andres Klode a écrit :
> > On Tue, Sep 05, 2023 at 10:49:00PM +0200, tv.debian wrote:
> > > Package: grub-efi-amd64
> > > Version: 2.12~rc1-7
> > > Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > > I think I have hit a corner case with latest grub-efi-amd64 upgrade in
> > > unstable. On my machine with a locally compiled kernel (installed along
> > > Debian kernel) the installation fails with error 127.
> > > Here is the output of the process:
> > > 
> > > "
> > > script -c "dpkg --configure -a" dpkg.log
> > > Script started, output log file is 'dpkg.log'.
> > > Setting up grub-efi-amd64 (2.12~rc1-7) ...
> > > Installing for x86_64-efi platform.
> > > Installation finished. No error reported.
> > > Generating grub configuration file ...
> > > Found background: /boot/grub/bush_viper.jpg
> > > Found background image: /boot/grub/bush_viper.jpg
> > > Found linux image: /boot/vmlinuz-6.5.1-deb64
> > > Found initrd image: /boot/initrd.img-6.5.1-deb64
> > > Found linux image: /boot/vmlinuz-6.4.0-4-amd64
> > > Found initrd image: /boot/initrd.img-6.4.0-4-amd64
> > > + prefix=/usr
> > > + exec_prefix=/usr
> > > + datarootdir=/usr/share
> > > + . /usr/share/grub/grub-mkconfig_lib
> > > + prefix=/usr
> > > + exec_prefix=/usr
> > > + datarootdir=/usr/share
> > > + datadir=/usr/share
> > > + bindir=/usr/bin
> > > + sbindir=/usr/sbin
> > > + [ x/usr/share/grub = x ]
> > > + test x = x
> > > + grub_probe=/usr/sbin/grub-probe
> > > + test x = x
> > > + grub_file=/usr/bin/grub-file
> > > + test x = x
> > > + grub_mkrelpath=/usr/bin/grub-mkrelpath
> > > + command -v gettext
> > > + :
> > > + grub_tab=
> > > + export TEXTDOMAIN=grub
> > > + export TEXTDOMAINDIR=/usr/share/locale
> > > + CLASS=--class gnu-linux --class gnu --class os
> > > + [ xDebian = x ]
> > > + [ Debian = Ubuntu ]
> > > + OS=Debian GNU/Linux
> > > + echo Debian
> > > + tr A-Z a-z
> > > + cut -d  -f1
> > > + CLASS=--class debian --class gnu-linux --class gnu --class os
> > > + [ x45b120bd-c7a5-4d00-9c5b-a72c48a663fc = x ]
> > > + [ x = xtrue ]
> > > + test -e /dev/disk/by-uuid/45b120bd-c7a5-4d00-9c5b-a72c48a663fc
> > > + uses_abstraction /dev/mapper/deb64crypt lvm
> > > + device=/dev/mapper/deb64crypt
> > > + old_ifs=
> > > 
> > > + IFS=
> > > 
> > > + /usr/sbin/grub-probe --device /dev/mapper/deb64crypt 
> > > --target=abstraction
> > > + abstraction=cryptodisk
> > > luks2
> > > gcry_twofish
> > > gcry_twofish
> > > gcry_sha256
> > > gcry_sha256
> > > + test xcryptodisk = xlvm
> > > + test xluks2 = xlvm
> > > + test xgcry_twofish = xlvm
> > > + test xgcry_twofish = xlvm
> > > + test xgcry_sha256 = xlvm
> > > + test xgcry_sha256 = xlvm
> > > + IFS=
> > > 
> > > + return 1
> > > + LINUX_ROOT_DEVICE=UUID=45b120bd-c7a5-4d00-9c5b-a72c48a663fc
> > > + /usr/sbin/grub-probe --device /dev/mapper/deb64crypt --target=fs
> > > + GRUBFS=ext2
> > > + [ xext2 = x ]
> > > + title_correction_code=
> > > + uname -m
> > > + machine=x86_64
> > > + grub_file_is_not_garbage /boot/vmlinuz-6.4.0-4-amd64
> > > + test -f /boot/vmlinuz-6.4.0-4-amd64
> > > + return 0
> > > + echo -n /boot/vmlinuz-6.4.0-4-amd64
> > > + grub_file_is_not_garbage /boot/vmlinuz-6.5.1-deb64
> > > + test -f /boot/vmlinuz-6.5.1-deb64
> > > + return 0
> > > + echo -n /boot/vmlinuz-6.5.1-deb64
> > > + grub_file_is_not_garbage /vmlinuz-*
> > > + test -f /vmlinuz-*
> > > + return 1
> > > + grub_file_is_not_garbage /boot/kernel-*
> > > + test -f /boot/kernel-*
> > > + return 1
> > > + list=/boot/vmlinuz-6.4.0-4-amd64 /boot/vmlinuz-6.5.1-deb64
> > > + GENKERNEL_ARCH=x86_64
> > > + prepare_boot_cache=
> > > + prepare_root_cache=
> > > + boot_device_id=
> > > + title_correction_code=
> > > + submenu_indentation=
> > > + is_first_entry=true
> > > + [ x/boot/vmlinuz-6.4.0-4-amd64 /boot/vmlinuz-6.5.1-deb64  != x ]
> > > + version_find_latest /boot/vmlinuz-6.4.0-4-amd64 
> > > /boot/vmlinuz-6.5.1-deb64
> > > /etc/grub.d/10_linux.orig: 1: version_find_latest: not found
> > 
> > If you maintain a custom script like your 10_linux.orig, it's up to you
> > to adjust it to changes in the script library, sorry
> 
> Sorry for the confusion, the ".orig" is a local rename after I tried
> modifying the original. This script is actually shipped with grub-common it
> appears:
> 
> dpkg -S /etc/grub.d/10_linux
> grub-common: /etc/grub.d/10_linux
> 
> but it is blocking grub-efi-amd64 installation.

That script was obviously adjusted though, it was the very first bit
that got the new version sort algorithm and is what I'd refer you to
to patch your own one.

And yes, I think because you renamed it you did not get the new
version and now have an outdated .orig one.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en