Bug#1078355: autopkg tests fail, blocking other packages
Control: severity -1 important On Sat, Aug 10, 2024 at 04:14:57AM GMT, Matthias Klose wrote: > Package: command-not-found > Version: 23.04.0-1 > Severity: serious > Tags: sid trixie > > autopkg tests fail, blocking other packages (python3-defaults): > > [...] > 37s Reading package lists... > 37s Ensure we have results from c-n-f > 37s Command 'vim' not found, but there are 16 similar ones. > 38s autopkgtest [11:16:04]: test smoke: ---] > 38s autopkgtest [11:16:04]: test smoke: - - - - - - - - - - results - - - > - - - - - - - > 38s smokeFAIL non-zero exit status 1 > 38s autopkgtest [11:16:04]: summary > 38s smokeFAIL non-zero exit status 1 I see python3-defaults has migrated and the tests are passing again, both on testing and unstable. What seemingly happened is that with both testing and unstable there were 16 commands similar to vim, and then it switched from listing each to just giving the summary. Anyway I am downgrading the bug as this is not grounds for autoremoval. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#896834: /usr/bin/apt-key: also unstable with gpgv 2.2.43-{6,7} ...
On Thu, Jun 20, 2024 at 12:39:39PM GMT, Julian Andres Klode wrote:
> Control: reassign -1 gpgv-from-sq
> Control: affects -1 apt
> Control: severity -1 serious
>
> On Wed, Jun 19, 2024 at 09:59:52AM GMT, Pti Zoom wrote:
> > Package: apt
> > Version: 2.9.5
> > Followup-For: Bug #896834
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where appropriate
> > ***
> >
> > *_InRelease files fails signing,
> >
> > since 17/06/2024,
> >
> > when upgraded unstable gpgv to 2.2.43-{6,7} !
> >
> > then the package updates are quite stalled.
> >
> > oh dear...should have listened to gpgv package maintainer instead of madly
> > upgrading
> >
> > symptoms are also similare to bug...
> >
> > #896834 /usr/bin/apt-key: apt-key fails in an lxc environment after
> > upgrade to stretch
> >
> > which from ...
> >
> > apt -o Debug::Acquire::gpgv=1 update
> >
> > gives...
> >
> > "...
> > inside VerifyGetSigners
> > ...
> > Preparing to exec: /usr/bin/apt-key --quiet --readonly verify --status-fd
> > 3 /tmp/apt.sig.dQFfP7 /tmp/apt.data.mOm9vr
> > ...
> > 0% [Working]gpgv exited with status 1
> >
> >
> >
> > Summary:
> > Good:
> > Valid:
> > Bad:
> > Worthless:
> > SoonWorthless:
> > NoPubKey:
> > Signed-By:
> > NODATA: no
> > Err:3 http://deb.debian.org/debian stable InRelease
> > At least one invalid signature was encountered.
> > ...
> > Warning: An error occurred during the signature verification. The
> > repository is not updated and the previous index files will be used. GPG
> > error: http://deb.debian.org/debian stable InRelease: At least one invalid
> > signature was encountered.
> > ..."
> >
> > etc...
> >
> > maybe I shall downgrade to gpgv 2.2.40-1.1+b3 or is there a better setting
> > for gpgv ?
>
> The culprit is gpgv-from-sq as DonKult said, and it is:
>
> jak@jak-t14-g3:~:master$ apt-key verify --keyring
> /usr/share/keyrings/ubuntu-archive-keyring.gpg
> /var/lib/apt/lists/snapshot.ubuntu.com_ubuntu_dists_oracular_InRelease
> gpgv: error: While parsing rule "ed448"
> gpgv: because: Invalid argument: Unknown public key algorithm: ed
>
> So now it claims it accepts the argument but then it complains about
> unknown public key algorithms. You can verify manually with something
> like:
>
> jak@jak-t14-g3:~:master$ gpgv --assert-pubkey-algo ">=rsa2048,ed25519,ed448"
> --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg
> /var/lib/apt/lists/snapshot.ubuntu.com_ubuntu_dists_oracular_InRelease
> gpgv: error: While parsing rule "ed448"
> gpgv: because: Invalid argument: Unknown public key algorithm: ed
>
> (Adjusted for your sources, I'm testing Ubuntu :D)
>
> There are two bugs here:
>
> 1. sq strips the numerical bit from ed448, pretending it is a size. Maybe it
>doesn't support ed448?
> 2. sq fails on unknown algorithms, when it should silently ignore them. These
>are not safety critical, it is an allow list after all. If it doesn't
> support
>ed448 the right place to fail is when it actually encounters an ed448
> signature.
>
I want to reiterate what I said upstream: We strongly need this
feature, we have a _temporary_ workaround in place, but this is
not a long term solution, but rather a release critical bug - we
should not release trixie with an APT that is not able to enforce
it's crypto policy.
Hence we need this implemented in gpgv-from-sq in addition to gpgv
from gnupg2, or we need to declare Conflicts: gpgv-from-sq to make
sure APT keeps working correctly.
We need to talk about gnupg 2.4 too at some point; this or a backport
is necessary for the APT feature to work, and I will raise this as
an RC bug eventually. Alternatively implementing it just in sq's gpgv
implementation and forcing apt to that also would work I suppose and
may be the preferable solution for Debian anyhow.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
signature.asc
Description: PGP signature
Bug#1071219: apt: debListParser fails to parse arch lists with extraneous whitespace: terminate called after throwing an instance of 'std::length_error'
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
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
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
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
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
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#1065435: closed by Debian FTP Masters (reply to Julian Andres Klode ) (Bug#1065435: fixed in aptitude 0.8.13-6)
On Sat, Mar 23, 2024 at 11:21:07AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:aptitude package:
>
> #1065435: aptitude: FTBFS on armhf and armel: deduced conflicting types for
> parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
>
> It has been closed by Debian FTP Masters
> (reply to Julian Andres Klode ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters
> (reply to Julian Andres Klode
> ) by
> replying to this email.
I was told to ping the bug to prevent autoremoval, so doing this
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
signature.asc
Description: PGP signature
Bug#1069247: libconfig-model-dpkg-perl: test failures
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#1068698: hdf-eos5 2:2.0-2 silently reverts the 64-bit time_t transition
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
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#1067609: gbrainy: Avoid hardcoded libcanberra-gtk3-0 build-depends, use libcanberra-gtk3-dev
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
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
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
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
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
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
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
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#1064969: apt: can't upgrade with aptitude
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
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#1064838: New package names break APT safety features, ability to co-install different ABIs
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
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#1060705: grub-pc: Symbol grub_env_get not found
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
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#1060251: Bug#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf
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
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#1059352: src:apt: fails to migrate to testing for too long: autopkgtest regression on armhf
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#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices
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
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
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
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#1058657: marked as pending in python-apt
Control: tag -1 pending
Hello,
Bug #1058657 in python-apt reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/apt-team/python-apt/-/commit/c64748b17f875ae16783755122064e5abdc0cf0c
apt_inst: Import apt_pkg.Warning and export it again
Like apt_pkg.Error, we need to also proxy apt_pkg.Warning, and
specifically the PyAptWarning variable needs to be declared and
initialized with the object from apt_pkg as otherwise we get a
missing symbol from dlopen()
Fixes: 81a5896ee410c62ccf140b48142a5358a07331ca
("Issue warnings as apt_pkg.Warning instead of discarding when
there is no error")
Closes: #1058657
(this message was generated automatically)
--
Greetings
https://bugs.debian.org/1058657
Bug#1058904: marked as pending in python-apt
Control: tag -1 pending
Hello,
Bug #1058904 in python-apt reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/apt-team/python-apt/-/commit/735ff09c8688fb2bb5f984e439ac222dfd97c76b
Handle null pointer deference in error handler
The commit introducing support for warnings accidentally moved the Res
check outside of the if when it moved it to the end, causing a crash.
Fixes: 81a5896ee410c62ccf140b48142a5358a07331ca
("Issue warnings as apt_pkg.Warning instead of discarding when
there is no error")
Closes: #1058904
(this message was generated automatically)
--
Greetings
https://bugs.debian.org/1058904
Bug#1058118: marked as pending in python-apt
Control: tag -1 pending Hello, Bug #1058118 in python-apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/python-apt/-/commit/f7e6175357228462b0389b45bf9ec68309403483 Convert from type comments to type annotations Automatically converted using com2ann and some manual from future imports Closes: #1058118 (this message was generated automatically) -- Greetings https://bugs.debian.org/1058118
Bug#1058118: marked as pending in python-apt
Control: tag -1 pending Hello, Bug #1058118 in python-apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/python-apt/-/commit/f7e6175357228462b0389b45bf9ec68309403483 Convert from type comments to type annotations Automatically converted using com2ann and some manual from future imports Closes: #1058118 (this message was generated automatically) -- Greetings https://bugs.debian.org/1058118
Bug#1058118: python-apt: FTBFS: AssertionError: pyflakes failed with: 1
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 > > /<>/apt/cache.py:45:1:
Bug#1051543: marked as pending in grub2
Control: tag -1 pending Hello, Bug #1051543 in grub2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/grub-team/grub/-/commit/f18fbbb6a5b42909a45a7e4067557fab910297d7 Cherry-pick upstream XFS directory extent parsing fixes Closes: #1051543 LP: #2039172 (this message was generated automatically) -- Greetings https://bugs.debian.org/1051543
Bug#1040901: Upcoming changes to Debian Linux kernel packages
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
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#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.
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#1052058: marked as pending in apt
Control: tag -1 pending Hello, Bug #1052058 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/apt/-/commit/925ada57d999a502dc2342092f32232b803be254 Downgrade unmerged-usr from error to two warnings One warning will be issued before the Y/n prompt, the other will be issued at the end after package installs have been attempted or if there were other failures, such that the last line you see is warnings about unmerged-usr I do not anticipate this to be the final version either, but there we go. Closes: #1052058 (this message was generated automatically) -- Greetings https://bugs.debian.org/1052058
Bug#1051251: /usr/sbin/grub-mkconfig: 300: /etc/grub.d/25_bli: not found due to wrong shell location
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
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#1051328: grub-common: wrong-path-for-interpreter /usr/bin/sh != /bin/sh [etc/grub.d/25_bli]
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#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
On Tue, Sep 05, 2023 at 08:32:39PM +0200, Agustin Martin wrote: > On Tue, Sep 05, 2023 at 07:34:13PM +0200, Julian Andres Klode wrote: > > On Tue, Sep 05, 2023 at 12:26:56PM -0400, M. Zhou wrote: > > > I am able to boot with 2.12~rc1-7 now. And my currrent status is > > > > > > grub-common/unstable,now 2.12~rc1-7 amd64 [installed] > > > grub-efi-amd64-bin/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > > > grub-efi-amd64-signed/unstable,now 1+2.12~rc1+7 amd64 > > > [installed,automatic] > > > grub-efi-amd64/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > > > grub2-common/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > > > > > > I reinstalled grub using 2.12~rc1-7. > > > But I still cannot guarantee it is safe to upgrade. > > > > > > > > > I believe the issue is the missing versioned dependency, which > > > allowed partial upgrade. > > > > Thanks for confirming this, this makes sense, if you boot without > > secure boot, the signed grub 2.06 could then try to upload > > incompatible modules from 2.12~rc1 and crash. > > This may not be all the problem, I am still having problems with 2.12-rc1-7 > and most recent packages installed with my old setup (/boot/efi not > mounted by default). > > If /boot/efi is not mounted I get for new versions > > $ LC_ALL=C sudo dpkg-reconfigure grub-efi-amd64 > Installing for x86_64-efi platform. > grub-install: error: cannot find EFI directory. > Failed: grub-install --target=x86_64-efi --force-extra-removable > WARNING: Bootloader is not properly installed, system may not be bootable > Generating grub configuration file ... > > (same without --force-extra-removable). No such error with previous version. Also, that's not true. grub-install for EFI of course always requires /boot/efi present, always has and always will* * on Ubuntu we mount to /var/lib/grub/esp if /boot/efi is not mounted (or you have multiple ESPs configured), but the script isn't in Debian yet, it's a bit hacky and duplicates lots of postinst sightly different :( -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
On Tue, Sep 05, 2023 at 08:32:39PM +0200, Agustin Martin wrote: > On Tue, Sep 05, 2023 at 07:34:13PM +0200, Julian Andres Klode wrote: > > On Tue, Sep 05, 2023 at 12:26:56PM -0400, M. Zhou wrote: > > > I am able to boot with 2.12~rc1-7 now. And my currrent status is > > > > > > grub-common/unstable,now 2.12~rc1-7 amd64 [installed] > > > grub-efi-amd64-bin/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > > > grub-efi-amd64-signed/unstable,now 1+2.12~rc1+7 amd64 > > > [installed,automatic] > > > grub-efi-amd64/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > > > grub2-common/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > > > > > > I reinstalled grub using 2.12~rc1-7. > > > But I still cannot guarantee it is safe to upgrade. > > > > > > > > > I believe the issue is the missing versioned dependency, which > > > allowed partial upgrade. > > > > Thanks for confirming this, this makes sense, if you boot without > > secure boot, the signed grub 2.06 could then try to upload > > incompatible modules from 2.12~rc1 and crash. > > This may not be all the problem, I am still having problems with 2.12-rc1-7 > and most recent packages installed with my old setup (/boot/efi not > mounted by default). > > If /boot/efi is not mounted I get for new versions Well that's *your problem*, sorry. Mounting /boot/efi is mandatory, you can't just go unmount it. By the same argument unmounting /boot (if a separate partition) yields an unbootable system too (eventually once /boot on / becomes out of sync with actual boot partition grub uses). -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
On Tue, Sep 05, 2023 at 12:26:56PM -0400, M. Zhou wrote: > On Tue, 5 Sep 2023 18:11:55 +0200 "Miguel A. Vallejo" > wrote: > > M. Zhou wrote: > > > > > But after that I noticed that the most important > > > package grub-efi-amd64-signed:amd64 (1+2.06+13, > > > 1+2.12~rc1+7) was not upgraded along with the other > > > grub packages. > > > > You are right. I revised apt log and grub-efi-amd64-signed was NOT > > updated, in fact, the version I have installed now is 1+2.06+13, but > > all other grub packages have 2.06-3~deb11u5. > > > > Now, if I run apt update, and apt list --upgradable it shows: > > > > grub-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- > 3~deb11u5] > > grub-efi-amd64-bin/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- > 3~deb11u5] > > grub-efi-amd64-signed/unstable 1+2.12~rc1+7 amd64 [upgradable from: > 1+2.06+13] > > grub-efi-amd64/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- > 3~deb11u5] > > grub2-common/unstable 2.12~rc1-7 amd64 [upgradable from: 2.06- > 3~deb11u5] > > > > > > All of them with version 2.12~rc1-7 > > > > Is it safe to upgrade now? I'll wait a bit until I hear from the > > package maintainers. > > I am able to boot with 2.12~rc1-7 now. And my currrent status is > > grub-common/unstable,now 2.12~rc1-7 amd64 [installed] > grub-efi-amd64-bin/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > grub-efi-amd64-signed/unstable,now 1+2.12~rc1+7 amd64 > [installed,automatic] > grub-efi-amd64/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > grub2-common/unstable,now 2.12~rc1-7 amd64 [installed,automatic] > > I reinstalled grub using 2.12~rc1-7. > But I still cannot guarantee it is safe to upgrade. > > > I believe the issue is the missing versioned dependency, which > allowed partial upgrade. > > If you check the testing, you will find that > > grub-efi-amd64-signed/1+2.06+13 Depends: grub-common (>= 2.06-13) > > Then, if we upgrade grub-common to 2.12~rc1-7, without > upgrading grub-efi-amd64-signed itself, then the boot is broken. > > TLDR: the boot is broken with the following partial upgrade: > grub-common/2.12~rc1-7 > grub-efi-amd64-signed/2.06+13 > > A possible fix might be specifying > Depends: grub-common (>= 2.12~rc1-7)), grub-common (<= 2.13~) > to prevent incompatible grub-common and grub-efi-amd64-signed > from co-existing. Although it does not help this time. > Thanks for confirming this, this makes sense, if you boot without secure boot, the signed grub 2.06 could then try to upload incompatible modules from 2.12~rc1 and crash. The 2.12~rc1-8 and -9 uploads change this in two steps to avoid this by making the signed package require a matching unsigned one again, and by making the existing -bin package Breaks << 1+2.12~rc1 such that you cannot partially upgrade those with incompatible older grubs. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1051271: marked as pending in grub2
Control: tag -1 pending Hello, Bug #1051271 in grub2 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/grub-team/grub/-/commit/d893fe6af8c198c8094e3c153051f6439b4c9ff8 Have -bin packages Break pre-2.12 -signed packages On insecurely booted systems, upgrading the -bin packages with the modules before the -signed packages caused the signed binaries to crash when loading additional modules. The proper fix here is to ensure that we are always at the same version which happens in the next step. Closes: #1051271 (this message was generated automatically) -- Greetings https://bugs.debian.org/1051271
Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot
Control: tag -1 unreproducible On Tue, Sep 05, 2023 at 04:19:01PM +0200, Miguel A. Vallejo wrote: > Package: grub2 > Version: 2.12~rc1-7 > Severity: critical > > This morning I noticed an apt upgrade in Debian unstable/Sid upgraded > grub-common, grub2-common, grub-efi-amd64 and grub-efi-amd64-bin. The > upgrade went normally and no errors were shown. Then I turned the > computer off and after a few hours I tried to turn it on, but it > didn't boot, it tried to boot but finally showed the bios screen. You are going to have to provide a lot more details than this, because it works in qemu, on the XPS13 I have for testing, and it's been in Ubuntu devel for over a month now with no such issues. - What hardware are you running this on? - It seems you have not updated grub-efi-amd64-signed, is that installed? - Is grub even loaded, what happens if you press Shift very quickly all the time during boot? - If grub is loaded, drop to console (c) and set debug=all, then normal and try to boot the entry again. - If grub is not loaded, set mokutil --set-verbosity true before trying to boot and record a video of your device screen. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1051227: grub2: Block the 2.12 transition to testing
Source: grub2 Version: 2.12~rc1-7 Severity: serious X-Debbugs-Cc: j...@debian.org This bug is a blocking bug for grub2 to be lifted in in October barring further issues such that we get more testing. I sadly forgot to also adjust urgency to low. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#1050896: packagesearch: Incomplete/Misleading copyright file
Source: packagesearch Version: 2.8.0 Severity: serious X-Debbugs-Cc: j...@debian.org The copyright file only states that it is licensed under the GPL, but not which versions. This seems to imply it is licensed under the GPL version 1. The code meanwhile ships the GPL-2 in COPYING. It's unclear whether the code is GPL-3 compatible. I'm not sure this can be said, as there have been contributors aside from the maintainer. My advise would be to contact all the copyright holders, and make sure that everyone is onboard with this actually being GPL-2+ such that when dependencies update to GPL-3 or later versions, you still remain compatible. I am not sure if this bug can be reasonably solved right now, maybe the copyright file can be changed to say GPL-2, I'd certainly also advise using the machine-readable copyright format for it to make everything clear rather than this half-assed free form. The problem to consider with updating the copyright file to just say GPL-2 is whether contributors knew they were contributing to a GPL-2 codebase or whether they contributed thinking it was GPL-1. -- System Information: Debian Release: trixie/sid APT prefers mantic APT policy: (500, 'mantic') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-7-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#1040901: linux modules must not be signed with CA key, bump ABI every upload
On Wed, Jul 12, 2023 at 10:05:03AM +0200, Julian Andres Klode wrote: > Source: linux > Version: 6.3.0-7.7 > Severity: grave > Tags: security > X-Debbugs-Cc: j...@debian.org > > I know there's some work in progress but it appears we don't have a bug > for it yet. I raised this yesterday in our weekly upstream shim/grub > cabal meetings and Debian's current approach to sign modules with the > same key and not bump ABI on every upload should be considered a bug. FWIW, I'm adding this formally as a requirement to the shim-review process in https://github.com/rhboot/shim-review/pull/337 So that we do not accidentally accept submissions with this bug anymore. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1040901: linux modules must not be signed with CA key, bump ABI every upload
Control: notfound -1 6.3.0-7.7 On Wed, Jul 12, 2023 at 10:05:03AM +0200, Julian Andres Klode wrote: > Source: linux > Version: 6.3.0-7.7 > Severity: grave > Tags: security > X-Debbugs-Cc: j...@debian.org Sorry about that, it picked up the version from my work system's Ubuntu kernel and I forgot to clean it. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1040901: linux modules must not be signed with CA key, bump ABI every upload
Source: linux Version: 6.3.0-7.7 Severity: grave Tags: security X-Debbugs-Cc: j...@debian.org I know there's some work in progress but it appears we don't have a bug for it yet. I raised this yesterday in our weekly upstream shim/grub cabal meetings and Debian's current approach to sign modules with the same key and not bump ABI on every upload should be considered a bug. The current approach means that a kernel cannot be easily revoked, you would need to add its kernel modules to the dbx as well, which is a grave security bug. The state of the art solution is to sign everything using an ephemeral key, which yes, it will cause the package to be unreproducible, but if nobody commits to working on that merkle tree of modules, than this is very well going to have to be the solution to the issue. A reasonable compromise at a first step for a limited time is to ensure that 1) the kernel refuses to load modules for a different ABI in lockdown, for example, the modprobe --force-vermagic does not work anymore. 2) each upload bumps the ABI [this is also required for the ephemeral key and merkle tree approaches as otherwise the modules become no longer loadable] This is still somewhat problematic as there may be bugs in the code validating parsing the kernel module sections that could be exploited if there were some weird modules, but it's a significant improvement (turning this from grave to serious I guess). -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1034993: software-properties-qt: missing Breaks+Replaces for software-properties-kde when upgrading from bullseye
Control: tag -1 - patch
On Thu, Jun 08, 2023 at 10:18:44PM +0200, Sebastiaan Couwenberg wrote:
> Control: tags -1 patch
>
> The attached patch resolves the issue.
>
> Kind Regards,
>
> Bas
>
>
>* py3-software-properties: Depend on lazr.restfulclient (Closes: #1029047)
> diff -Nru software-properties-0.99.30/debian/control
> software-properties-0.99.30/debian/control
> --- software-properties-0.99.30/debian/control2023-01-20
> 22:52:46.0 +0100
> +++ software-properties-0.99.30/debian/control2023-06-08
> 22:13:54.0 +0200
> @@ -109,6 +109,8 @@
> ${misc:Depends},
> ${python3:Depends}
> Suggests: plasma-discover
> +Breaks: software-properties-kde (<< 0.99.30)
> +Replaces: software-properties-kde (<< 0.99.30)
> Description: manage the repositories that you install software from (Qt)
> This software provides an abstraction of the used apt repositories.
> It allows you to easily manage your distribution and independent software
FWIW, the premise of the bug is wrong, there is no
software-properties-kde package anymore and the -qt
one replaces it, so we must use unversioned Conflicts
and Breaks as per policy requirements.
No need to confuse the solver by pretending there should be an upgrade
avilable to a package that doesn't exist anymore.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#1035654: marked as pending in apt
Control: tag -1 pending Hello, Bug #1035654 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/apt/-/commit/780bbeaef4b5923c770891ede6a57c795dd54a64 Restore adduser dependency for bookworm This caused some regressions to late in the bookworm cycle. To keep upgrade paths (which will have adduser installed) the same, we drop the base-password alternative rather than requiring both dependencies, as that could change resolving or ordering bugs. Closes: #1035654 Gbp-Dch: full (this message was generated automatically) -- Greetings https://bugs.debian.org/1035654
Bug#1019273: marked as pending in apt
Control: tag -1 pending Hello, Bug #1019273 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/apt/-/commit/5039c586a833b67f00fe5e480bf2f3e074cf7fc5 machine-readable version of COPYING The debian/copyright (COPYING) file is missing at least two licenses (Expat, BSD-3-clause) and some copyright statements. A machine-readable version of COPYING is attached that fixes these. Closes: #1019273 (this message was generated automatically) -- Greetings https://bugs.debian.org/1019273
Bug#1019273: apt: diff for NMU version 2.5.6+nmu1
On Sun, Feb 26, 2023 at 03:19:47PM -0500, Louis-Philippe Véronneau wrote: > Control: tags 1019273 + pending > > Dear maintainer, > > I've prepared an NMU for apt (versioned as 2.5.6+nmu1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. I have erased the NMU per the review on the merge request: https://salsa.debian.org/apt-team/apt/-/merge_requests/284 I urge everyone to collaborate on salsa, the bug tracker is not a good place to submit or discuss patches - neither does it run the CI, nor does it allow me to reply sensibly from my phone, so response times, especially for "unimportant" issues like this are low. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1029803: command-not-found breaks dist-upgrade bullseye → bookworm
Sorry on my phone, but thank you and please do go ahead with the change! Paul Gevers schrieb am Mo., 20. Feb. 2023, 16:24: > Control: tags -1 patch > > Hi, > > On 19-02-2023 21:22, Paul Gevers wrote: > > On Sat, 28 Jan 2023 00:51:39 +0100 Lee Garrett > > wrote: > >> This is already fixed in unstable, but in it's current form this will > >> break the > >> upgrade path from bullseye to bookworm. The fix is trivial, adding > >> `'non-free-firmware': 60,` to CommandNotFound/db/creator.py is enough. > >> I propose > >> doing a p-u to fix it. > > > > What do you think of that? Are you OK if I prepare the upload? > > I have the attached debdiff ready to handle with the stable release > managers. > > Paul >
Bug#1027140: keepassxc: requires Qt 5.15.7 - dependencies outdated?
Control: reassign -1 qtbase5-dev 5.15.7+dfsg-2 Control: affects -1 keepassxc On Wed, Dec 28, 2022 at 03:11:55PM +0100, Jörg-Volker Peetz wrote: > Julian Andres Klode wrote on 28/12/2022 13:08: > > Control: tag -1 moreinfo > > > > On Wed, Dec 28, 2022 at 12:52:35PM +0100, Jörg-Volker Peetz wrote: > > > Package: keepassxc > > > Version: 2.7.4+dfsg.1-1 > > > Severity: grave > > > > > > Dear Julian Andres Klode, > > > > > > Qt libraries are not updated as necessary. The dependencies should be > > > updated? > > > > What is your issue? Dependencies are automatically generated at > > build-time from the shlibs files in the Qt packages, I don't control > > them. > > > > It can be built against any version >= 5.2.0 > > Hi, > > after upgrading keepassxc to version 2.7.4+dfsg.1-1 the executable keepassxc > won't start but an error message > > Executable 'keepassxc' requires Qt 5.15.7, found Qt 5.15.6. > > pops up in a window titled "Incompatible Qt Library Error". > The upgrade of keepassxc should have incurred an upgrade of the relevant Qt > libraries, I thought. I guess some symbol version needs bumping and then keepassxc and other rdeps need binNMUing, but it's not a keepassxc packaging issue. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1027140: keepassxc: requires Qt 5.15.7 - dependencies outdated?
Control: tag -1 moreinfo On Wed, Dec 28, 2022 at 12:52:35PM +0100, Jörg-Volker Peetz wrote: > Package: keepassxc > Version: 2.7.4+dfsg.1-1 > Severity: grave > > Dear Julian Andres Klode, > > Qt libraries are not updated as necessary. The dependencies should be > updated? What is your issue? Dependencies are automatically generated at build-time from the shlibs files in the Qt packages, I don't control them. It can be built against any version >= 5.2.0 -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1012626: sicherboot requires dependency on systemd-boot{,-efi}
On Fri, Jun 10, 2022 at 07:38:10PM +0100, Luca Boccassi wrote: > On Fri, 10 Jun 2022 18:38:15 +0200 Julian Andres Klode > wrote: > > On Fri, Jun 10, 2022 at 10:24:53AM -0500, Dustin L. Howett wrote: > > > Package: sicherboot > > > Version: 0.1.5 > > > Severity: normal > > > X-Debbugs-Cc: dus...@howett.net > > > > > > As of systemd-251.2-3, systemd-boot and systemd-boot-efi have been > split > > > out of the systemd package. This causes sicherboot to fail to > install > > > new kernels; confer bug #1012625 for the systemd report. Recommend > a > > > dependency on systemd-boot and systemd-boot-efi. > > > > AFAIU, systemd-boot also ships its own integration which conflicts > with > > sicherboot, as both would try to install kernels, so that's not just > > going to work like that. > > systemd-boot-efi is intentionally a (multiarch) leaf package with no > dependencies, and it contains the EFI binaries and nothing else, so > depending on that should be safe. sicherboot needs bootctl at the moment, and reimplementing that surely is going to take some effort if one wants to stay compatible - sicherboot bootctl [...] is documented to run bootctl [...] and then sign any images installed to /boot/efi -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1012626: sicherboot requires dependency on systemd-boot{,-efi}
On Fri, Jun 10, 2022 at 10:24:53AM -0500, Dustin L. Howett wrote: > Package: sicherboot > Version: 0.1.5 > Severity: normal > X-Debbugs-Cc: dus...@howett.net > > As of systemd-251.2-3, systemd-boot and systemd-boot-efi have been split > out of the systemd package. This causes sicherboot to fail to install > new kernels; confer bug #1012625 for the systemd report. Recommend a > dependency on systemd-boot and systemd-boot-efi. AFAIU, systemd-boot also ships its own integration which conflicts with sicherboot, as both would try to install kernels, so that's not just going to work like that. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1001057: grub2: hold 2.06 in unstable for now
Control: retitle -1 grub2: CVE-2022-28735 grub2: shim_lock verifier allows non-kernel files to be loaded On Fri, Dec 03, 2021 at 11:17:26AM +, Colin Watson wrote: > Package: grub2 > Version: 2.06-2 > Severity: serious > Justification: maintainer says so > > GRUB 2.06 is a pretty big change over 2.04. I'd like to hold this in > unstable for a while longer to let things shake out before we allow it > to move to testing. Now that it's public, we can say that here's the real reason for this: CVE-2022-28735 grub2: shim_lock verifier allows non-kernel files to be loaded 6.7/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H The GRUB2's shim_lock verifier allows non-kernel files to be loaded on shim-powered secure boot systems. Allowing such files to be loaded may lead to unverified code and modules to be loaded in GRUB2 breaking the secure boot trust-chain. https://lists.gnu.org/archive/html/grub-devel/2022-06/msg00035.html That's why we wanted to keep it ouf of testing to not expose our testing users to that. Planning to have updates ready in the next couple days. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
On Tue, May 03, 2022 at 08:47:56AM -0700, Clayton Craft wrote: > Hi folks, > > > what is the story there? I don't believe any of those MS reports > > are actually (important) security issues, > > The issue is basically that microsoft and/or their customers are allowing > arbitrary code execution under a system user account (the same one that > normally > runs systemd-networkd). I can't speak for Debian, but other distros I've seen > restrict who can "own" the systemd-networkd service name on the system dbus > session to that user, so obviously if you allow that user to run arbitrary > code > then you're going to allow anything to bypass those restrictions. That's my understanding and hence why I asked them to publish a correction within 4 business days that this is caused by local misconfiguration and not a result of undisclosed security vulnerabilities. > > That's important in this context because networkd-dispatcher derives paths to > scripts it runs based on the messages it receives on dbus for the > systemd-networkd service. So if something else can "own" that name on the bus > then it can (before the sanitation patch in the latest version) get > networkd-dispatcher to run things located elsewhere. > > I should have been sanitizing input from dbus, which networkd-dispatcher does > now. But again, in every other configuration I've seen, the user who is > sending > messages under that service is a dedicated system user who is only running > systemd-networkd. > > > also why was this being disclosed publicly rather than responsibly? > > It was disclosed responsibly, as far as I understand the "responsible > disclosure" process to be. They contacted me privately about a month ago about > it, giving me enough time to come up with something to address it (I'm not > paid > to work on this :D) They also gave me a script to reproduce it shortly after > contacting me, which (after a lot of effort) I was able to trigger it a couple > of times in a VM running Arch Linux, but only after doing things that I > shouldn't have been doing in the "real world" > (e.g. sudo -u systemd-network ./foo) So the way this usually goes is that distros also get notified, and fixes are held back until a date (well hour really) coordinated by the distros so everyone can release fixes at the same time, by way of contacting the distros mailing list (https://oss-security.openwall.org/wiki/mailing-lists/distros) or individual email. Given that you are just working on this in your spare time and had not had to deal with a CVE, I think MS should have at least helped ensure that this is being communicated properly. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
Hi Clayton (CC), what is the story there? I don't believe any of those MS reports are actually (important) security issues, also why was this being disclosed publicly rather than responsibly? The fixes for the alleged permission issue also only handles one parent directory and classic permissions, but not any other (grand)parents or ACLs. On Tue, May 03, 2022 at 01:21:12PM +0200, Julian Andres Klode wrote: > On Thu, Apr 28, 2022 at 01:53:58PM +0200, Salvatore Bonaccorso wrote: > > Source: networkd-dispatcher > > Version: 2.1-2 > > Severity: grave > > Tags: security upstream > > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > > > > Hi, > > > > The following vulnerabilities were published for networkd-dispatcher. > > > > CVE-2022-29799[0] and CVE-2022-29800[1]. > > > > If you fix the vulnerabilities please also make sure to include the > > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > I do not believe these are vulnerabilities. Microsoft claims a > vulnerability exists if there is vulnerable code running under > the systemd-network user, and claims that apt and epmd run under > such user, but neither has communicated how those processes are > vulnerable, nor why they would run under that user. > > It's likely that their tool is a confused deputy, running on a > system with broken containers where container _apt and epmd > users are mapped to the same UID as the host systemd-network > (which still would not give them access to the bus), or it's > a FUD smear campaign. > > Microsoft also claims that a vulnerability exists if scripts > are writable by the user, however the directory is owned by > root, so any scripts in there had to be written there by > root. As such, that is a local admin choice to allow that > user to run code as root. > > By the same argument, the code would have to check that any > parent directory of the scripts is not writable by non-root > users. > > The proposed fix also would not address this problem in the > context of ACLs, as it only checks owner user and group, > and mode, but not whether any ACLs are granted. Hence if that > were really a bug, it's still not fixed. > > I can prepare a security update for this if people want it, > but I do not believe in the existence of these bugs or that > the fixes address them in a meaningful way. > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#1010303: networkd-dispatcher: CVE-2022-29799 CVE-2022-29800
On Thu, Apr 28, 2022 at 01:53:58PM +0200, Salvatore Bonaccorso wrote: > Source: networkd-dispatcher > Version: 2.1-2 > Severity: grave > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > > Hi, > > The following vulnerabilities were published for networkd-dispatcher. > > CVE-2022-29799[0] and CVE-2022-29800[1]. > > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. I do not believe these are vulnerabilities. Microsoft claims a vulnerability exists if there is vulnerable code running under the systemd-network user, and claims that apt and epmd run under such user, but neither has communicated how those processes are vulnerable, nor why they would run under that user. It's likely that their tool is a confused deputy, running on a system with broken containers where container _apt and epmd users are mapped to the same UID as the host systemd-network (which still would not give them access to the bus), or it's a FUD smear campaign. Microsoft also claims that a vulnerability exists if scripts are writable by the user, however the directory is owned by root, so any scripts in there had to be written there by root. As such, that is a local admin choice to allow that user to run code as root. By the same argument, the code would have to check that any parent directory of the scripts is not writable by non-root users. The proposed fix also would not address this problem in the context of ACLs, as it only checks owner user and group, and mode, but not whether any ACLs are granted. Hence if that were really a bug, it's still not fixed. I can prepare a security update for this if people want it, but I do not believe in the existence of these bugs or that the fixes address them in a meaningful way. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#1008197: at-spi2-core: move gsettings-desktop-schemas to package Depends
Package: at-spi2-core
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
X-Debbugs-Cc: juli...@ubuntu.com
In Ubuntu, the attached patch was applied to achieve the following:
* Move the gsettings-desktop-schemas from tests/control to the main
package Depends. This package is absolutely necessary for the bus
service to start.
You can see the same issue in other tests, adding the dependency for
the tests only, when it is required for the service to start does not
make much sense - it's still a missing Depends.
Thanks for considering the patch.
-- System Information:
Debian Release: bookworm/sid
APT prefers jammy
APT policy: (500, 'jammy'), (500, 'impish-security'), (500, 'impish')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.15.0-2022-generic (SMP w/8 CPU threads)
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
diff -Nru at-spi2-core-2.44.0/debian/control at-spi2-core-2.44.0/debian/control
--- at-spi2-core-2.44.0/debian/control 2022-03-20 17:30:24.0 +0100
+++ at-spi2-core-2.44.0/debian/control 2022-03-24 10:21:06.0 +0100
@@ -24,7 +24,7 @@
Package: at-spi2-core
Architecture: any
Multi-Arch: foreign
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}, gsettings-desktop-schemas
Description: Assistive Technology Service Provider Interface (dbus core)
This package contains the core components of GNOME Accessibility.
diff -Nru at-spi2-core-2.44.0/debian/tests/control
at-spi2-core-2.44.0/debian/tests/control
--- at-spi2-core-2.44.0/debian/tests/control2022-03-20 18:03:41.0
+0100
+++ at-spi2-core-2.44.0/debian/tests/control2022-03-24 10:19:58.0
+0100
@@ -1,2 +1,2 @@
Tests: memory dbind
-Depends: libatspi2.0-dev, build-essential, xauth, xvfb, dbus, at-spi2-core,
gsettings-desktop-schemas
+Depends: libatspi2.0-dev, build-essential, xauth, xvfb, dbus, at-spi2-core
Bug#994018: gnome-tweaks must not suggest installing Extensions app from flathub
Package: gnome-tweaks
Version: 40.0-3
Severity: serious
gnome-tweaks suggests users install the Extensions app from flathub,
if not provided by the distribution. This is misleading the user to
install apps from outside of main, in violation of policy 2.2.1.
It should offer to install the gnome-shell-extension-prefs package
via gnome-software, tell people to install that package with apt,
or (in my case where it was already installed), tell me that it
is already installed.
The message under concern is:
self.format_secondary_markup(
"{0}\n\n{1}".format(
# Translators: Placeholder will be replaced with "GNOME
Extensions" in active link form
_("Extensions management has been moved to {0}.").format(
'https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/master/subprojects/extensions-app/README.md";>GNOME
Extensions',
),
# Translators: Placeholder will be replaced with "Flathub" in
active link form
_("We recommend downloading GNOME Extensions from {0} if your
distribution does not include it.").format(
'https://flathub.org/apps/details/org.gnome.Extensions";>Flathub'
)
)
)
it should say something like:
"Extensions management has been moved to Extension, which is part of
the gnome-shell-extensions-prefs package."
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gnome-tweaks/+bug/1943183
-- System Information:
Debian Release: 11.0
APT prefers impish
APT policy: (500, 'impish'), (500, 'hirsute-updates'), (500,
'hirsute-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.13.0-16-generic (SMP w/8 CPU threads)
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
Versions of packages gnome-tweaks depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-1
ii gir1.2-glib-2.0 1.68.0-1
ii gir1.2-gnomedesktop-3.0 40.2-1ubuntu1
ii gir1.2-gtk-3.0 3.24.30-1ubuntu1
ii gir1.2-handy-1 1.2.3-1
ii gir1.2-notify-0.70.7.9-3ubuntu2
ii gir1.2-pango-1.0 1.48.9+ds1-1
ii gir1.2-soup-2.4 2.72.0-3ubuntu3
ii gnome-settings-daemon40.0.1-1ubuntu2
ii gnome-shell-common 40.2-1ubuntu6
ii gnome-shell-extension-prefs 40.2-1ubuntu6
ii gsettings-desktop-schemas40.0-1ubuntu1
ii mutter-common40.2.1-1ubuntu1
ii python3 3.9.4-1
ii python3-gi 3.40.1-1
gnome-tweaks recommends no packages.
gnome-tweaks 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#991936: openssh-server: seccomp filter defaults to SIGSYS, could break any libc or kernel upgrade
Package: openssh-server Version: 1:8.4p1-5ubuntu2 Severity: serious X-Debbugs-Cc: j...@debian.org seccomp filters are currently setup to kill the process #define SECCOMP_FILTER_FAIL SECCOMP_RET_KILL /* Default deny */ BPF_STMT(BPF_RET+BPF_K, SECCOMP_FILTER_FAIL), this means every new libc or kernel release can cause openssh to break, requiring breaks from them on openssh, which does not scale, and is currently breaking SSH during upgrades. This also means openssh might fail to work inside containers because the host kernel is newer. The default policy needs to be changed to return ENOSYS instead, such that libc can fallback to other syscalls for its wrappers. With the caveat that umask is a bit broken, if you don't want to allow it, block it explicitly with RET_KILL: https://bugzilla.mozilla.org/show_bug.cgi?id=1724098 This should be fixed for bullseye+1, and fixed in a point release IMO, it might be a tad too late right now for the release itself. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#968458: makes crossgrader completely broken, bumping severity
Control: severity -1 normal On Mon, May 31, 2021 at 04:57:41PM +0200, Adam Borowski wrote: > Control: severity -1 serious > > Hi! > Because of this lacking M-A setting, crossgrader always fails in bullseye. > It had a hack to workaround this in buster, but for some reason that hack > is no longer working. > > I've discussed a bit with the maintainer in #989236. > > Thus, that package is broken for all users, which is RC. However, I find > little point in trying to debug why the hack fails -- fixing the real > cause is so much simpler. Go fight it out with the release team. I do not consider cross-grading to be a sensible, or supported operation. There is no support in APT for cross-grading, and scripts to do so are hackish at best. It's certainly not release critical. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Apr 19, 2021 at 06:31:48PM +0200, Julien Cristau wrote: > Can we defer these until after the AllowReleaseInfoChange change is > out, please? Done. I uploaded 1.8.2.3 with that one change as requested, and created a pu bug for it. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Apr 19, 2021 at 06:08:23PM +0200, Julien Cristau wrote: > On Mon, Apr 19, 2021 at 06:01:18PM +0200, Julian Andres Klode wrote: > > I see. Nobody pinged me since then, but it is indeed fixed in the > > 1.8.5 stable update that at least one release team member was > > not exited about. > > > > https://salsa.debian.org/apt-team/apt/-/compare/1.8.2.2...1.8.5 > > > > So it's up to the release team if they want 1.8.5 or whether we'll have > > to cherry-pick a subset of it into a 1.8.2.3. I think my opinion on that > > is clear - I don't want to maintain a 1.8.2.z branch, it's more work > > compared > > to just following the normal stable apt updates, and there's a lot less > > testing going on. > > > Please upload just that fix to buster; I don't care too much about the > version number you pick. Is there a buster point release before bullseye release, or should that be in buster-updates? Given that buster is going to security support only soon anyway, I don't mind where I apply security updates to that much :D But I really do want to cherry-pick at least two other code fixes, and one test suite fix: * https://salsa.debian.org/apt-team/apt/-/commit/cfee71c6f2d1478ce4d4ed74ef690ae1350ea403 https://salsa.debian.org/apt-team/apt/-/commit/75f452c7309d66548c86a6526cbd65fc51a70039 (really just one change, but it was split over two releases, first turned error to warning, next one ignores it completely; because it was in 2 releases in main so I kept it separate :D) too, they'll make immediate configuration errors non-fatal. Currently they are fatal in the sense that they are ignored and the upgrade runs and then it just exits with 1 at the end. So it does not change the outcome, it just makes the error reporting less silly. It is very likely that some upgrades on multi-arch systems fail erronously without them. To be fair, the multi-arch aspect is also fixed by https://salsa.debian.org/apt-team/apt/-/commit/7f65fa3843abc476cbba65c808abc5dd77835815 but that changes ordering results, and is not strictly necessary. * And I want https://salsa.debian.org/apt-team/apt/-/commit/cfc6870e9b8ad119219ce5dc1871531006bb2d71 to avoid people getting packages removed that stuff still depends on because their prerm script failed. This might happen during an upgrade to bullseye, and it's very very likely APT will not be able to recover from it - I've never successfully recovered a distribution upgrade that had a failure in the middle (and fwiw, all of them had, but they were my faults, really). * Also the testsuite-only change in https://salsa.debian.org/apt-team/apt/-/commit/730c5c861c32c9385dc862af8673984b12902343 which makes things work reliably on debci armhf (no regression potential, wheee) -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Mon, Apr 19, 2021 at 05:40:09PM +0200, Christoph Berg wrote: > Re: Julian Andres Klode > > > We're getting close to the release of bullseye and it has been brought > > > to my attention that this bug is still unfixed in buster. Once we > > > release bullseye, this bug is going to run havoc for our buster users. > > > > That's not accurate. This is _only_ a problem for users of testing, > > where the codename changes from time to time. > > This *is* a problem for users of "buster" where the suite will be > changing from "stable" to "oldstable". (Yes, we do release buster > twice, once as stable and then as oldstable.) > > Unless the fix that has closed #931566 is also applied to the apt > version in buster, things will explode horribly. Oh I see. That's tricky. > > Changed-By: Julian Andres Klode > Changes: > apt (2.1.10) unstable; urgency=medium > . >* Default Acquire::AllowReleaseInfoChange::Suite to "true" (Closes: > #931566) > > Notably, that needs to happen well before the bullseye release or else > systems will not be able to "apt-get update" non-interactively to > actually see the updated package. > > > For stable users, this is not a problem at all, more the opposite. Those > > poor souls who have stable in their sources.list won't suddenly get > > upgraded to bullseye. > > Yes, this part of the change is the good one. Pinning suite for > "buster" users is not. > > > > Can we somehow come up with a plan on how to handle this? Can we have a > > > fix in the next point release? Are there faster options than just > > > waiting some time after the next point release before we can release > > > bullseye, e.g. could the SRM allow an update to stable for the change of > > > an apt default to have the change earlier than the next point release? > > > > I have no intention of issuing a stable update. > > On 2020-08-10 you said: > > 17:04 juliank: is #931566 going to be fixed in buster as well? > 17:04 -zwiebelbot- Debian#931566: Don't complain about suite changes > (Acquire::AllowReleaseInfoChange::Suite should be "true") - > https://bugs.debian.org/931566 > 17:04 Myon: yes > 17:04 cool > 17:04 thanks I see. Nobody pinged me since then, but it is indeed fixed in the 1.8.5 stable update that at least one release team member was not exited about. https://salsa.debian.org/apt-team/apt/-/compare/1.8.2.2...1.8.5 So it's up to the release team if they want 1.8.5 or whether we'll have to cherry-pick a subset of it into a 1.8.2.3. I think my opinion on that is clear - I don't want to maintain a 1.8.2.z branch, it's more work compared to just following the normal stable apt updates, and there's a lot less testing going on. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#931566: Don't complain about suite changes (Acquire::AllowReleaseInfoChange::Suite should be "true")
On Sun, Apr 18, 2021 at 10:20:19PM +0200, Paul Gevers wrote: > Hi Julian, David, SRM, > > On Mon, 8 Jul 2019 09:11:48 +0200 Christoph Berg wrote: > > Fwiw, I think this needs fixing in buster, not just in unstable. > > We're getting close to the release of bullseye and it has been brought > to my attention that this bug is still unfixed in buster. Once we > release bullseye, this bug is going to run havoc for our buster users. That's not accurate. This is _only_ a problem for users of testing, where the codename changes from time to time. For stable users, this is not a problem at all, more the opposite. Those poor souls who have stable in their sources.list won't suddenly get upgraded to bullseye. > > Can we somehow come up with a plan on how to handle this? Can we have a > fix in the next point release? Are there faster options than just > waiting some time after the next point release before we can release > bullseye, e.g. could the SRM allow an update to stable for the change of > an apt default to have the change earlier than the next point release? I have no intention of issuing a stable update. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#984966: marked as pending in apt
Control: tag -1 pending Hello, Bug #984966 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/apt/-/commit/c091472587eb743a9137b6375a17e45951554515 Harden test for no new acquires after transaction abort If a transaction is doomed we want to gracefully shutdown our zoo of worker processes. As explained in the referenced commit we do this by stopping the main process from handing out new work and ignoring the replies it gets from the workers, so that they eventually run out of work. We tested this previously by checking if a rred worker was given work items at all, but depending on how lucky the stars of the machine working on this are the worker would have already gotten work before the transaction was aborted – so we tried this 25 times a row (f35601e5d2). No machine can be this lucky, right? Turns out the autopkgtest armhf machine is very lucky. I feel a bit sorry for feeding grep such a long "line" to work with, but it seems to work out. Porterbox amdahl (who is considerably less lucky; had to turn down to 1 try to get it to fail sometimes) is now happily running the test in an endless loop. Of course, I could have broken the test now, but its still a rather generic grep (in some ways more generic even) and the main part of the testcase – the update process finishes and fails – is untouched. References: 38f8704e419ed93f433129e20df5611df6652620 Closes: #984966 (cherry picked from commit 0d25ce3d466ecddea02d171981f011f7dbf95e08) (this message was generated automatically) -- Greetings https://bugs.debian.org/984966
Bug#981717: command-not-found: test 'multi advise debs' broken
Control: tag -1 moreinfo Control: severity -1 normal On Wed, Feb 03, 2021 at 01:44:27PM +0530, Ritesh Raj Sarraf wrote: > Package: command-not-found > Version: 20.10.1-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source > > The package reportedly fails in one of the tests. The failing test log > snippet is below: It builds for me and builds on the buildds, so meh, this is not release critical. Why does reproducible build builders build without main in their sources.list? This does not seem to make a lot of sense. Sure, you can argue that the tests should not depend on main being enabled in your hosts sources.list, but in practice this is not something that should fail. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude
On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote: > reassign 979970 src:glibc,src:libselinux,src:apt,src:openssh > thanks > > On 2021-01-25 11:59, Laurent Bigonville wrote: > > reassign 979970 src:glibc 2.30-1 > > affects 979970 + libselinux1 > > thanks > > > > On Tue, 12 Jan 2021 13:31:19 +0100 Charlemagne Lasse > > wrote: > > > > > Right now, an update from buster to bullseye on amd64 completely > > > bricks the system because libselinux1 is requiring a libc6 which is > > > not yet installed on the system: > > > > > > Preparing to unpack .../0-libselinux1_3.1-2+b2_amd64.deb ... > > > De-configuring libselinux1:i386 (2.8-1+b1) ... > > > Unpacking libselinux1:amd64 (3.1-2+b2) over (2.8-1+b1) ... > > > tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not > > > found (required by /lib/x86_64-linux-gnu/libselinux.so.1) > > > dpkg-deb: error: tar subprocess returned error exit status 1 > > > > > > It is then not possible anymore to recover the system because dpkg > > > (mv, ...) is no longer working. > > > > > > There is most likely some kind dependency missing to let aptitude > > > known that it must first update libc6 before it can update > > > libselinux1. At least on this system, the installed version of libc6 > > > for amd64 and i386 was still 2.28-10 when this happened > > > > After some discussion on IRC it looks like the problem is apparently coming > > from the breaks added to the libc6 package. > > The break hasn't been added randomly, but in response to upstream > release notes and bug #965932. In short the openssh seccomp filters in > buster are too narrow, and do not allow the new 64-bit syscalls needed > for 64-bit time_t compatibility to be used. > > So we definitely can't drop this break. For me this is not a libc6 bug. > Or if it is, it is as much the fault of libc6 (for using new syscalls) > than libselinux1 (for starting using symbol versioning). This is not a question of finding the right solution, but more of the least worst one. Currently, the breaks potentially avoids non-working openssh-server during a partial upgrade at the expense of breaking the system in a full upgrade. We can't have that. The reason this happens is the cycle: New libselinux1 needs new libc6, new libc6 needs newer libselinux1. The right solution would be to deconfigure libselinux1, then unpack libc6, then unpack new libselinux1, but it seems that this is not what's happening, and we can't easily change apt to fix it. An alternative solution, for openssh-server would be to avoid using the new syscalls for 64-bit time_t compatibility I assume (forcing it to link with older symbol versions?), but there are other cycles between libselinux1 and libc6 from what I heard. So well, like hack up libc6 to avoid exposing the new symbol versions and recompile everything against it? If you have alternative suggestions to avoid removing the Breaks, please let me know, but as it stands, I believe that this is the option that causes the least amount of breakage. We've reached the point where we have too many dependencies and conflicts too low in the stack, and it becomes too much for apt to handle. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#970124: software-properties-common: add-apt-repository: missing dependency gpg (gnupg) (Was: Re: Bug#970124: Patch prepared for NMU)
Control: severity -1 normal On Sun, Jan 24, 2021 at 08:28:22AM +0100, Bruno Kleinert wrote: > Hi, > > please find attached a patch. If Julian or nobody else objects or jumps > in, I can NMU in about one week. Did you test it? I don't think this works, this is probably still the old version that actually needs key server functionality (dirmngr and gnupg), and I absolutely do not want to depend on those. I also don't think this is a release critical bug - the script is not the main attraction, it does not produce immediate useful results on Debian anyway if you add a PPA, given that the PPAs do not exist for Debian in the first place, and other uses do not involve that codepath AFAIUI. Anyhow, this email was the first time I heard about this bug, and it did not provide any context (and I can't open attachments on my phone), so I was a bit unhappy, and I did not have a lot of time to dig into it yet. My advise for future NMU emails: Please keep the original bug subject in the subject, and quote the bug report so readers can make sense out of it without having to search for the bug in the BTS. We really ought to update software-properties to the Ubuntu 20.04 version rather than try to ship the 16.04 one - it's 5 years old by now. I have no idea what happened here that we're still on the old version, I did upload the 18.04 one to experimental 2 years ago. This also fixes this bug because it now talks to the keyserver directly, and drops the file into trusted.gpg.d. Generally, please: If I have not answered you for a month, your email was lost, if it's still a problem, please ping me. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#980035: [Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude
On Wed, Jan 13, 2021 at 10:29:17AM +0100, Vincent Lefevre wrote:
> Package: aptitude
> Version: 0.8.13-2+b1
> Severity: grave
> Justification: renders package unusable
> Tags: security
>
> I got a first "segmentation fault" just after updating ('u' in the TUI).
> Now, each time I run aptitude, a segmentation occurs one second after
> starting it.
>
> I suppose that it doesn't like some data that have been fetched.
> Tagging security for this reason.
Smells like 980037? Bug in APT's cache building upon mremap() in new
code path in 2.1.16/17.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#957434: marked as pending in apt
Control: tag -1 pending Hello, Bug #957434 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/libept/-/commit/a1ec2bcb5ec235f5709b720f8cc6778d181d9ee8 Fix FTBFS with GCC 10 Closes: #957434 (this message was generated automatically) -- Greetings https://bugs.debian.org/957434
Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch
On Sun, Dec 27, 2020 at 12:25:37PM +0200, Adrian Bunk wrote: > On Sun, Dec 27, 2020 at 09:58:06AM +0100, Julian Andres Klode wrote: > >... > > or revert that madness > > of forcing all your reverse depends to depend on gnutls28 just because > > there are a few new enum members they _might_ have used - it's doing > > more harm then good, and it's not standard practice. > > This is actually good practice, if in doubt our dependencies should > always err on the safe side. > > Imagine software like apt would have gotten a too low dependency and > then migrated before gnutls to testing. > > Or even worse, due to a too low dependency apt would have been upgraded > during the first step of an oldstable->stable upgrade, but not gnutls. > > In this specific case the higher dependency might not be required for > apt specifically, but really bad practice would be risking breakage > for our users by not setting the dependency strict enough. The tooling is just suboptimal for these cases. I think essentially in most cases raising the depends is wrong - if something used newer features it would build-depend on newer versions, and run-time depends should be max version of (build-depends on dev package, symbols of runtime package) or something like it to make this easier to manage, and avoid something with impact similar to a transition. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#976836: libgnutls30: 3.7.0-3 fails to connect on debian.ethz.ch
On Tue, Dec 08, 2020 at 01:13:20PM +0100, Jonathan Ballet wrote: > Package: libgnutls30 > Version: 3.7.0-3 > Severity: critical > Justification: breaks unrelated software > > Dear Maintainer, > > I updated gnutls to 3.7.0-3 this morning, then apt was unable to connect to > the Debian mirror https://debian.ethz.ch/debian/: > > Reverting to libgnutls30 3.6.15-4 seems to fix the problem. This is a kind reminder that the build-essential freeze is in about two weeks, and that gnutls28 is a dependency of apt and the questionable symbol versioning changes together with this release critical bug prevent it from migrating to testing. Please get the bug fixed, revert the upload, revert the commit that introduces the bug, downgrade the bug severity, or revert that madness of forcing all your reverse depends to depend on gnutls28 just because there are a few new enum members they _might_ have used - it's doing more harm then good, and it's not standard practice. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#977000: marked as pending in python-apt
Control: tag -1 pending Hello, Bug #977000 in python-apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/python-apt/-/commit/e37237d09fd24ed9072aa308bf10edb10ae74711 arfile.cc: Fix segmentation fault when opening fd, track lifetime correctly The lines that created self->Fd and that then made use of it were swapped, causing a segmentation fault. Also the life of the file object was tracked incorrectly, causing the file to be closed if it was a temporary one. Closes: #977000 (cherry picked from commit 3d9af5f196ad6a6c6973ac699a15888d21a9bb52) (this message was generated automatically) -- Greetings https://bugs.debian.org/977000
Bug#977000: marked as pending in python-apt
Control: tag -1 pending Hello, Bug #977000 in python-apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 arfile.cc: Fix segmentation fault when opening fd, track lifetime correctly The lines that created self->Fd and that then made use of it were swapped, causing a segmentation fault. Also the life of the file object was tracked incorrectly, causing the file to be closed if it was a temporary one. Closes: #977000 (this message was generated automatically) -- Greetings https://bugs.debian.org/977000
Bug#972936: libgcc-s1 needs Breaks: libgcc1 (<< 1:10)
Control: subscribe -1 On Tue, Oct 27, 2020 at 03:45:59PM +0200, Adrian Bunk wrote: > Control: severity -1 grave > > On Tue, Oct 27, 2020 at 12:44:44PM +0100, Matthias Klose wrote: > > Control: severity -1 important > > > > On 10/26/20 1:04 PM, Adrian Bunk wrote: > > > Package: libgcc-s1 > > > Version: 10.2.0-15 > > > Severity: grave > > > > > > On a buster system, with unstable pinned to low priority: > > > > Lowering the severity. Feel free to correct me if this specific > > configuration > > deserves RC severity. > > This is pretty exactly the problem described in > https://www.debian.org/doc/debian-policy/ch-relationships.html#id11 > > Losing libgcc1 is extra bad, since so much (including apt) uses it. > > Hard to recover when you hit the problem, and trivial to fix. It's not trivial to fix, if it's fixable at all. Adding the Breaks can cause the library to disappear in the middle of the upgrade, because libgcc1 is upgraded first or temporarily removed, which is the reason it's not there. I thought about hacking a workaround into apt that prevents you from removing libgcc-s1 if libgcc1 is installed, but that's not super helpful as you need a current apt. My suggestion is to set XB-Important: yes and Protected: yes on libgcc-s1 such that people cannot easily remove it after it's installed. We can then remove that bit in bookworm. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#972618: googletest: Breaks apt build
Package: googletest Version: 1.10.0.20201018-1 Severity: serious Control: affects -1 apt The apt build, which has been working fine with the previous version, now fails to build: cd /builds/apt-team/apt/build/test/libapt/gtest/src/gtest-build && /usr/bin/cmake -GNinja /usr/src/googletest/googletest && /usr/bin/cmake -E touch /builds/apt-team/apt/build/test/libapt/gtest/src/gtest-stamp/gtest-configure CMake Warning at CMakeLists.txt:54 (project): VERSION keyword not followed by a value or was followed by a value that expanded to nothing. -- The CXX compiler identification is GNU 10.2.0 -- The C compiler identification is GNU 10.2.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Found PythonInterp: /usr/bin/python3.8 (found version "3.8.6") -- Looking for pthread.h -- Looking for pthread.h - found -- Performing Test CMAKE_HAVE_LIBC_PTHREAD -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE CMake Error at CMakeLists.txt:129 (set_target_properties): set_target_properties called with incorrect number of arguments. CMake Error at CMakeLists.txt:132 (set_target_properties): set_target_properties called with incorrect number of arguments. -- Configuring incomplete, errors occurred! See also "/builds/apt-team/apt/build/test/libapt/g Are we using googletest wrong? I don't know, but it's gotta stop breaking our build every few uploads. -- System Information: Debian Release: bullseye/sid APT prefers groovy APT policy: (500, 'groovy'), (500, 'focal-updates'), (500, 'focal-security') Architecture: amd64 (x86_64) Kernel: Linux 5.9.1-050901-generic (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_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 /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#931566: marked as pending in apt
Control: tag -1 pending Hello, Bug #931566 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/apt/-/commit/64b45e294f0c6931a9b57ae6cc99ecded8f6a2d3 Default Acquire::AllowReleaseInfoChange::Suite to "true" Closes: #931566 (this message was generated automatically) -- Greetings https://bugs.debian.org/931566
Bug#964541: flatpak: Wrong argument order for clone syscall seccomp filter on s390x (Was: make: Regression on s390x, echo EPERM, caused by posix_spawn change)
Control: reassign -1 flatpak
Control: retitle -1 flatpak: Wrong argument order for clone syscall seccomp
filter on s390x
Hello flatpak maintainer!
On Wed, Aug 05, 2020 at 03:19:39PM +0200, Christian Borntraeger wrote:
>
> On 21.07.20 13:24, Julian Andres Klode wrote:
> > On Tue, Jul 21, 2020 at 12:49:59PM +0200, Christian Borntraeger wrote:
> >> On 21.07.20 10:18, Adrian Bunk wrote:
> >>> [ adding debian-s390 to Cc ]
> >>>
> >>> On Wed, Jul 08, 2020 at 01:42:33PM +0200, Julian Andres Klode wrote:
> >>>> Package: make-dfsg
> >>>> Version: 4.3-4
> >>>> Severity: serious
> >>>> Tags: patch
> >>>> User: ubuntu-de...@lists.ubuntu.com
> >>>> Usertags: origin-ubuntu groovy ubuntu-patch
> >>>>
> >>>> In Ubuntu, the attached patch was applied to achieve the following:
> >>>>
> >>>> The autopkgtests for flatpak-builder/s390x where failing with
> >>>>
> >>>> echo Building
> >>>> make: echo: Operation not permitted
> >>>> make: *** [Makefile:2: all] Error 127
> >>
> >> Julian,
> >>
> >> is there a launchpad entry for the Ubuntu bug that was fixed by this
> >> change?
> >
> > Yes, https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1886814, it's
> > also
> > in the IBM bugzilla thingy - you can see Andreas Krebbel is replying to
> > that.
>
> FWIW, Stefan Liebler looked into this and this needs to be fixed in
> flatpak-build.
> See the bug for details.
flatpak has the wrong argument order in the seccomp filter for 390x, the
attached patch should fix it.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Description: Fix argument order of clone() for s390x in seccomp filter
clone() is a mad syscall with about 4 different argument orders. While
most of them agree that argument 0 is flags, s390 and s390x have the
flags argument second - A0 is the child stack pointer there.
Author: Julian Andres Klode
Bug-Debian: https://bugs.debian.org/964541
Bug-Ubuntu: https://launchpad.net/bugs/1886814
Forwarded: no
Last-Update: 2020-08-05
--- flatpak-1.8.1.orig/common/flatpak-run.c
+++ flatpak-1.8.1/common/flatpak-run.c
@@ -2667,7 +2667,11 @@ setup_seccomp (FlatpakBwrap *bwrap,
{SCMP_SYS (unshare)},
{SCMP_SYS (mount)},
{SCMP_SYS (pivot_root)},
+#if defined(__s390__) || defined(__s390x__)
+{SCMP_SYS (clone), &SCMP_A1 (SCMP_CMP_MASKED_EQ, CLONE_NEWUSER, CLONE_NEWUSER)},
+#else
{SCMP_SYS (clone), &SCMP_A0 (SCMP_CMP_MASKED_EQ, CLONE_NEWUSER, CLONE_NEWUSER)},
+#endif
/* Don't allow faking input to the controlling tty (CVE-2017-5226) */
{SCMP_SYS (ioctl), &SCMP_A1 (SCMP_CMP_MASKED_EQ, 0xu, (int) TIOCSTI)},
Bug#964541: make: Regression on s390x, echo EPERM, caused by posix_spawn change
On Tue, Jul 21, 2020 at 12:49:59PM +0200, Christian Borntraeger wrote: > On 21.07.20 10:18, Adrian Bunk wrote: > > [ adding debian-s390 to Cc ] > > > > On Wed, Jul 08, 2020 at 01:42:33PM +0200, Julian Andres Klode wrote: > >> Package: make-dfsg > >> Version: 4.3-4 > >> Severity: serious > >> Tags: patch > >> User: ubuntu-de...@lists.ubuntu.com > >> Usertags: origin-ubuntu groovy ubuntu-patch > >> > >> In Ubuntu, the attached patch was applied to achieve the following: > >> > >> The autopkgtests for flatpak-builder/s390x where failing with > >> > >> echo Building > >> make: echo: Operation not permitted > >> make: *** [Makefile:2: all] Error 127 > > Julian, > > is there a launchpad entry for the Ubuntu bug that was fixed by this change? Yes, https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1886814, it's also in the IBM bugzilla thingy - you can see Andreas Krebbel is replying to that. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#964541: make: Regression on s390x, echo EPERM, caused by posix_spawn change
Package: make-dfsg Version: 4.3-4 Severity: serious Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu groovy ubuntu-patch In Ubuntu, the attached patch was applied to achieve the following: The autopkgtests for flatpak-builder/s390x where failing with echo Building make: echo: Operation not permitted make: *** [Makefile:2: all] Error 127 git bisect lead to commit 749a54d7a458dc6779936138caf40ce600a80052 (refs/bisect/bad) Author: Aron Barath Date: Mon Jul 9 09:05:31 2018 +0200 * job.c (child_execute_job): Prefer posix_spawn() over fork()/exec() and I can confirm that disabling posix_spawn makes the autopkgtest work again. Earlier research also indicated that this is a heisenbug, if I try to print to stderr before printing to stdout, no issue occurs. * Pass --disable-posix-spawn to configure, as use of posix_spawn() causes a regression on s390x, with commands getting EPERM when writing to stdout. Thanks for considering the patch. *** /tmp/tmp79xr4v61/make-dfsg_4.3-4ubuntu1.debdiff diff -u make-dfsg-4.3/debian/rules make-dfsg-4.3/debian/rules --- make-dfsg-4.3/debian/rules +++ make-dfsg-4.3/debian/rules @@ -28,13 +28,13 @@ mkdir -p $(BUILDDIR_GUILE) ac_cv_lib_util_getloadavg=no dh_auto_configure --parallel \ -B$(BUILDDIR_GUILE) -- --prefix=$(PREFIX) $(confflags) \ - --with-guile + --with-guile --disable-posix-spawn endif ifneq (,$(filter make, $(shell dh_listpackages))) mkdir -p $(BUILDDIR_NORMAL) ac_cv_lib_util_getloadavg=no dh_auto_configure --parallel \ -B$(BUILDDIR_NORMAL) -- --prefix=$(PREFIX) $(confflags) \ - --with-guile=no + --with-guile=no --disable-posix-spawn endif override_dh_auto_build: -- System Information: Debian Release: bullseye/sid APT prefers groovy APT policy: (991, 'groovy'), (500, 'groovy'), (500, 'focal-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1018-oem (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /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#962499: keepassxc: Block 2.6.0 beta from migrating
Package: keepassxc Version: 2.6.0~beta1-1 Severity: serious We don't want 2.6.0~beta1-1 to enter testing, and probably want to wait for final 2.6.0. -- System Information: Debian Release: bullseye/sid APT prefers groovy APT policy: (991, 'groovy'), (500, 'groovy'), (500, 'focal-security') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-31-generic (SMP w/8 CPU cores) 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=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages keepassxc depends on: ii libargon2-10~20171227-0.2 ii libc6 2.31-0ubuntu9 ii libgcrypt201.8.5-5ubuntu1 ii libqrencode4 4.0.2-2 ii libqt5concurrent5 5.14.2+dfsg-2ubuntu1 ii libqt5core5a 5.14.2+dfsg-2ubuntu1 ii libqt5dbus55.14.2+dfsg-2ubuntu1 ii libqt5gui5 5.14.2+dfsg-2ubuntu1 ii libqt5network5 5.14.2+dfsg-2ubuntu1 ii libqt5svg5 5.14.2-1 ii libqt5widgets5 5.14.2+dfsg-2ubuntu1 ii libqt5x11extras5 5.14.2-1 ii libreadline5 5.2+dfsg-3build3 ii libsodium231.0.18-1 ii libstdc++6 10.1.0-3ubuntu1 ii libx11-6 2:1.6.9-2ubuntu1 ii libxi6 2:1.7.10-0ubuntu1 ii libxtst6 2:1.2.3-1 ii libykpers-1-1 1.20.0-2 ii libzxcvbn0 2.4+dfsg-2 ii zlib1g 1:1.2.11.dfsg-2ubuntu1 keepassxc recommends no packages. Versions of packages keepassxc suggests: pn webext-keepassxc-browser ii xclip 0.13-1 -- no debconf information -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#937579: marked as pending in python-apt
Control: tag -1 pending Hello, Bug #937579 in python-apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/python-apt/-/commit/5992b7e3daf922034f8cad6dc010ba337e1e3786 Stop building for Python 2 Aside from dropping Python2 support, this also moves the documentation from /usr/share/doc/python-apt to /usr/share/python-apt-doc, which might be unfortunate. The next step, in 2.1.1, will be to actually do code changes to take advantage of Python 3. Closes: #937579 (this message was generated automatically) -- Greetings https://bugs.debian.org/937579
Bug#953562: libcrypt1 should ship file in /usr, breaks is useless
On Tue, Mar 10, 2020 at 05:58:04PM +0100, Marco d'Itri wrote: > On Mar 10, Julian Andres Klode wrote: > > > It likely works out fine in practice in most cases, but > > let's be safe, k? > Do you care enough to test a patch? We're going to roll out the change in Ubuntu shortly, so there'll be a ton of testing going on involving libc6 + libcrypt1 upgrades when the autopkgtests run. But yes, we should also check the other direction in Debian I guess where we already have libc6 + libcrypt1 installed and then change the path, though I'm not sure what could go bad there. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Bug#953562: libcrypt1 should ship file in /usr, breaks is useless
Control: retitle -1 libcrypt1 should ship file in /usr, Replaces is useless sigh, sorry. subject said breaks instead of replaces. On Tue, Mar 10, 2020 at 05:54:13PM +0100, Julian Andres Klode wrote: > Package: libcrypt1 > Severity: serious > > libcrypt1 currently ships the file in /usr/lib, whereas libc6 > shipped it in /lib, meaning that the Replaces relationship to > libc6 is not doing anything on usrmerged systems. > > Please move it back to /lib until after bullseye, so that > the Replaces actually work, and ownership of libcrypt1 is > properly transferred from libc6 to libcrypt1. > > It likely works out fine in practice in most cases, but > let's be safe, k? > > -- System Information: > Debian Release: bullseye/sid > APT prefers focal > APT policy: (991, 'focal'), (500, 'focal') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.4.0-18-generic (SMP w/8 CPU cores) > 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=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libcrypt1 depends on: > ii libc6 2.30-0ubuntu3 > > libcrypt1 recommends no packages. > > libcrypt1 suggests no packages. > > -- no debconf information > > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#953562: libcrypt1 should ship file in /usr, breaks is useless
Package: libcrypt1 Severity: serious libcrypt1 currently ships the file in /usr/lib, whereas libc6 shipped it in /lib, meaning that the Replaces relationship to libc6 is not doing anything on usrmerged systems. Please move it back to /lib until after bullseye, so that the Replaces actually work, and ownership of libcrypt1 is properly transferred from libc6 to libcrypt1. It likely works out fine in practice in most cases, but let's be safe, k? -- System Information: Debian Release: bullseye/sid APT prefers focal APT policy: (991, 'focal'), (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-18-generic (SMP w/8 CPU cores) 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=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libcrypt1 depends on: ii libc6 2.30-0ubuntu3 libcrypt1 recommends no packages. libcrypt1 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#953426: python-apt: Hasjes problem
Control: reassign -1 ftp.debian.org
On Mon, Mar 09, 2020 at 06:12:14PM +0100, Christian Marillat wrote:
> Package: python-apt
> Version: 1.9.10
> Severity: serious
>
> Dear Maintainer,
>
> Probably related that now apt use libgcrypt.
>
> Output come from dak. Bug should be reassigned to ftp.debian.org is needed.
>
>
> dak process-upload -a -p -d
>
> dak_1.0.db122~20200307.git9dac010a-dmo1_amd64.changes
>
> dak (1.0.db122~20200307.git9dac010a-dmo1) unstable; urgency=medium
> .
>* New upstream release.
>
>
>
> Reason:
> Processing raised an exception: 'apt_pkg.Hashes' object has no attribute
> 'md5'.
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/daklib/archive.py", line 1019, in
> check
> chk().check(self)
> File "/usr/lib/python2.7/dist-packages/daklib/checks.py", line 146, in check
> self._check_hashes(upload, changes.filename, changes.files.itervalues())
> File "/usr/lib/python2.7/dist-packages/daklib/checks.py", line 179, in
> _check_hashes
> f.check(upload.directory)
> File "/usr/lib/python2.7/dist-packages/daklib/upload.py", line 174, in check
> self.check_fh(fh)
> File "/usr/lib/python2.7/dist-packages/daklib/upload.py", line 188, in
> check_fh
> if hashes.md5 != self.md5sum:
> AttributeError: 'apt_pkg.Hashes' object has no attribute 'md5'
gotta uses hashes.hashes.find("MD5Sum") now.
API breaks in Python are messed up, given that there's no static
typing that would bring it up during a rebuild.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Bug#953311: synaptic: Port to apt 1.9.11
Package: synaptic Version: 0.84.6ubuntu3 Severity: serious User: de...@lists.debian.org Usertags: apt-1.9.11 Patches for apt 1.9.11 have been submitted as a pull request #49: https://github.com/mvo5/synaptic/pull/49 -- System Information: Debian Release: bullseye/sid APT prefers focal APT policy: (991, 'focal'), (500, 'focal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-17-generic (SMP w/8 CPU cores) 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=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages synaptic depends on: ii hicolor-icon-theme 0.17-2 ii libapt-pkg5.90 1.9.10 ii libc62.30-0ubuntu3 ii libept1.5.90 1.1+nmu3ubuntu1 ii libgcc-s1 [libgcc1] 10-20200304-1ubuntu1 ii libgcc1 1:10-20200304-1ubuntu1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-2 ii libglib2.0-0 2.64.0-1 ii libgtk-3-0 3.24.13-1ubuntu1 ii libpango-1.0-0 1.44.7-1ubuntu3 ii libstdc++6 10-20200304-1ubuntu1 ii libvte-2.91-00.59.91-0ubuntu1 ii libxapian30 1.4.14-2 ii policykit-1 0.105-26ubuntu1 Versions of packages synaptic recommends: ii libgtk3-perl 0.036-1 ii xdg-utils 1.1.3-1ubuntu2 Versions of packages synaptic suggests: pn apt-xapian-index ii deborphan1.7.32 pn dwww ii menu 2.1.47ubuntu3 ii software-properties-gtk 0.98.7 ii tasksel 3.34ubuntu16 -- no debconf information -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
