Processed: tagging 968997
Processing commands for cont...@bugs.debian.org:
> tags 968997 + bullseye
Bug #968997 {Done: Laurent Bigonville } [shim] fwupdmgr:
"Successfully" updates BIOS firmware, no effect on reboot
Bug #990447 {Done: Laurent Bigonville } [shim] fwupdmgr:
Unable to install new updates
Added tag(s) bullseye.
Added tag(s) bullseye.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
968997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968997
990447: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990447
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: fixed 968997 in 15.7-1
Processing commands for cont...@bugs.debian.org:
> fixed 968997 15.7-1
Bug #968997 {Done: Laurent Bigonville } [shim] fwupdmgr:
"Successfully" updates BIOS firmware, no effect on reboot
Bug #990447 {Done: Laurent Bigonville } [shim] fwupdmgr:
Unable to install new updates
There is no source info for the package 'shim' at version '15.7-1' with
architecture ''
Unable to make a source version for version '15.7-1'
Marked as fixed in versions 15.7-1.
Marked as fixed in versions 15.7-1.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
968997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968997
990447: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990447
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: closing 968997, tagging 968997
Processing commands for cont...@bugs.debian.org:
> close 968997
Bug #968997 [shim] fwupdmgr: "Successfully" updates BIOS firmware, no effect on
reboot
Bug #990447 [shim] fwupdmgr: Unable to install new updates
Marked Bug as done
Marked Bug as done
> tags 968997 + sid bookworm
Bug #968997 {Done: Laurent Bigonville } [shim] fwupdmgr:
"Successfully" updates BIOS firmware, no effect on reboot
Bug #990447 {Done: Laurent Bigonville } [shim] fwupdmgr:
Unable to install new updates
Added tag(s) bookworm and sid.
Added tag(s) sid and bookworm.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
968997: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968997
990447: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990447
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1032822: liferea: CVE-2023-1350: RCE vulnerability on feed enrichment
Source: liferea Version: 1.14.0-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for liferea. CVE-2023-1350[0]: | A vulnerability was found in liferea. It has been rated as critical. | Affected by this issue is the function update_job_run of the file | src/update.c of the component Feed Enrichment. The manipulation of the | argument source with the input |date gt;/tmp/bad-item-link.txt | leads to os command injection. The attack may be launched remotely. | The exploit has been disclosed to the public and may be used. The name | of the patch is 8d8b5b963fa64c7a2122d1bbfbb0bed46e813e59. It is | recommended to apply a patch to fix this issue. The identifier of this | vulnerability is VDB-222848. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-1350 https://www.cve.org/CVERecord?id=CVE-2023-1350 [1] https://github.com/lwindolf/liferea/commit/8d8b5b963fa64c7a2122d1bbfbb0bed46e813e59 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#1032706: [pkg-lxc-devel] Bug#1032706: lxc-snapshot cannot restore containers with loop storage backend
Hi Mathias, I submitted an issue on github: https://github.com/lxc/lxc/issues/4289 Step-by-step is explained there. Thank you, Mario On 3/11/23 17:59, Mathias Gibbens wrote: Hi Mario, I'm currently on travel with not-so-great network connectivity, so I haven't been able to reproduce this on my travel laptop, but will attempt to do so when I'm back from my trip. I expect that this issue will have to be forwarded to the lxc developers; if you want to do so you can submit an issue at https://github.com/lxc/lxc/issues, otherwise I'll so after reproducing the issue myself. To help ensure I'll be following exactly what you did, could you share the commands you used to setup the loop storage backend, the creation of the container, snapshoting, and attempted restoration of that snapshot? Thanks, Mathias
Processed: Forwarded upstream
Processing control commands: > tags -1 upstream Bug #1031580 [src:pigx-rnaseq] pigx-rnaseq: FTBFS in testing: E: Build killed with signal TERM after 150 minutes of inactivity Added tag(s) upstream. > forwarded -1 https://github.com/COMBINE-lab/salmon/issues/835 Bug #1031580 [src:pigx-rnaseq] pigx-rnaseq: FTBFS in testing: E: Build killed with signal TERM after 150 minutes of inactivity Set Bug forwarded-to-address to 'https://github.com/COMBINE-lab/salmon/issues/835'. -- 1031580: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031580 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1031580: Forwarded upstream
Control: tags -1 upstream Control: forwarded -1 https://github.com/COMBINE-lab/salmon/issues/835
Bug#1032120: Upload of new upstream version before fix has migrated to testing (Was: Re: Bug#1032120: tiledb: uses atomic operations, but is not linked to libatomic)
Dirk - Ping on this? If you do not have the time, let me know. I'll do a NMU for tiledb to revert to prev version and also file an unblock request. On 3/10/23 20:53, Nilesh Patra wrote: Quoting Andreas Tille: your recent upload of tiledb 2.15.0-1 into unstable is quite unfortunate in freeze policy. You should have waited at least until 2.14.1-2 fixing this bug to migrate to testing. You would need to ask release team for migration of 2.15.0 which will probably be refused The changes between 2.14 and 2.15 are non-trivial and are likely to be rejected by release team at the moment, considering there are no autopkgtests either. even if you would be able to fix the regression in autopkgtest[1]. This is because the version of tiledb-py is not compatible with tiledb 2.15.0. Uploading a new version of tiledb-py would fix this, but: - It'd be useless unless tiledb 2.15.0 migrates. - It seems to need pyarrow for tests, and other functionalities, which is un-packaged. So current situation is: * tiledb 2.14.1-1 in testing (and next stable) is marked for auto-removal. * consequently, tiledb-py is also marked for autoremoval. * tiledb 2.15.0-1 can't migrate because of freeze policy. What a freaking mess! Dirk, we could have avoided all of it if you had quite literally ** waited ** for a few hours to let tiledb migrate on the 8th of March. I'm sad to see such mess-ups happening at this time as I had put quite some efforts on tiledb-py myself too. The solution right now is what Andreas said: My recommendation would be to upload a version 2.15.0-2+really_2.14.1 Dirk, please fix this so tiledb can make a (valid) stable release. [1]: https://tracker.debian.org/pkg/tiledb
Bug#1032655: psi-plus segfaults
On Fri, Mar 10, 2023 at 03:45:38PM +0100, Lee Garrett wrote: > psi-plus currently simply segfaults on a stock bookworm installation: > > $ psi-plus > [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile > (unknown:0, unknown) > [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile > (unknown:0, unknown) > [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile > (unknown:0, unknown) > [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile > (unknown:0, unknown) > Segmentation fault On my bookworm system, I also get libpng warnings, but no segfault. Maybe a backtrace in gdb can help to get more information.
Bug#1032168: marked as done (meson: autopkgtest fills disk completely)
Your message dated Sat, 11 Mar 2023 22:11:09 + with message-id and subject line Bug#1032168: fixed in meson 1.0.1-5 has caused the Debian Bug report #1032168, regarding meson: autopkgtest fills disk completely to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1032168: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032168 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: meson Version: 1.0.1-1 Severity: serious Dear Jussi, With your last upload of meson, we're seeing issues on ci.debian.net. It turns out that the autopkgtest of meson is using so much disk space that the most of our hosts runs out of it when meson is tested. See e.g. the history (look for the tmpfails for 1.0.1-1) of armhf, ppc64el and s390x: https://ci.debian.net/packages/m/meson/testing/armhf/ https://ci.debian.net/packages/m/meson/testing/arm64/ https://ci.debian.net/packages/m/meson/testing/ppc64el/ https://ci.debian.net/packages/m/meson/testing/s390x/ Particularly s390x was bad, as we only have one host, so it took down all capacity. Paul --- End Message --- --- Begin Message --- Source: meson Source-Version: 1.0.1-5 Done: Jussi Pakkanen We believe that the bug you reported is fixed in the latest version of meson, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1032...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Jussi Pakkanen (supplier of updated meson package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 11 Mar 2023 23:06:44 +0200 Source: meson Architecture: source Version: 1.0.1-5 Distribution: unstable Urgency: medium Maintainer: Jussi Pakkanen Changed-By: Jussi Pakkanen Closes: 1032168 Changes: meson (1.0.1-5) unstable; urgency=medium . * Fix incorrect usage of fgetc/fputc. Closes: #1032168. Checksums-Sha1: 05d778bde06c58e6b49a299e0378248e42e9d075 3471 meson_1.0.1-5.dsc 0e952627277fa7e183a5c3cf184f930058d6685f 16704 meson_1.0.1-5.debian.tar.xz 415b3eab9477ba5f7ec55dcfabb32b9d6eaf1d06 35263 meson_1.0.1-5_source.buildinfo Checksums-Sha256: 1fca26f595c67cf10306c66f2d56c909ec2b443cdd8f23cc4c248e0e2a201c34 3471 meson_1.0.1-5.dsc f78e1ebb59e25a7a9497cbc954ae04a11156e369b0559f2392131b1939f1cc48 16704 meson_1.0.1-5.debian.tar.xz 5dcdc6a1501ab85dc59f8f7b552dad37be6e7cb92a4e0f6726919cdeaf5bf8e2 35263 meson_1.0.1-5_source.buildinfo Files: ff17a313b146fa1d798eb7f1ef2bad9f 3471 devel optional meson_1.0.1-5.dsc 85bd2b7d568f44a338139e25aaea92a9 16704 devel optional meson_1.0.1-5.debian.tar.xz cd6c0ef374219c1edd75e821d49f8bc1 35263 devel optional meson_1.0.1-5_source.buildinfo -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEEGeLW2bRtjapiiPh3wk5jG6ux/nAFAmQM7jMTHGpwYWtrYW5l QGdtYWlsLmNvbQAKCRDCTmMbq7H+cGuKD/9v4Q6aOA5FL2HPvtgq8CLPnL04Qt8Z vkQFpimG8LCZIiwuHAK5UB2+s2MK3/8RCf0Ovy5JJ2riuMSSekqvpJz9N670HNI6 UaY70Z8nm55Xxrofadr5Bm+VBJKVscFPfPDO56ZmFsU4FG0pQmqAKoSXFzo0dXtT ymu0SlRHvKkCOkjBhADsOWQ/ml8V5LH2PzOtP+8OGpTioa57HkiPGnlaCvoc2+Nc PPXWA+jJZMOY+WlL+b2e/CrXjES4yqIeE15aznD3JeRLU4iymc7XgkAkyzx5DtVg uh+2mAZpSsy4QhtLhUPD0VVqIjavsKP/lu6BaA16N8MXFt+1bp+OTy6m/JgOL4kP 8rZe6lykpBkzo+Yys78dqPwc4PL7uD8Iy2imXs3hs0Z3H3sBK5j1DzI228o8N7vp sjgbuRnSGZoFA3wgZqbUgPSaFhD8Fdsw8mP28uRENoo4uAc9TlKHhzjj2oW45H9M T2TjUSTsg8GZWQiARrM6h2186Uq7S02YR6gdiXIJvsm2MHiGIR7fQeWKISGXqZKU KIynJgkbxOt5UqbQ6K0lXXSoyuKgel4sTWvOLh+4QB9C8X1chZ5RQ8apev19J/mB 1WgVwIsn2pDXECfP1INua7+TwyPo3i+Nk2NamElh2DExxPqfVbyV61r8eXr/kxv5 l0pmmrv2+hSbqw== =YVmz -END PGP SIGNATURE End Message ---
Bug#1032235: closing 1032235
close 1032235 thanks Closing this now, cryptsetup 2:2.6.1-2 and libargon2 0~20190702-0.1 should be able to enter testing together.
Processed: closing 1032235
Processing commands for cont...@bugs.debian.org: > close 1032235 Bug #1032235 [libargon2-1] cryptsetup: libgcc_s.so.1 must be installed for pthread_exit to work Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 1032235: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032235 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1027954: cppad: binary-all FTBFS
Dear Maintainer, I think debian/libcppad-doc.docs needs to be adjusted to reflect changes in documentation file names: - doc.omh was renamed to doc.xrst [1] which was then renamed tocppad.xrst [2] which was then renamed to user_guide.xrst [3] - omh directory was renamed to xrst [1] Kind Regards [1] https://github.com/coin-or/CppAD/commit/f054e4abb22551dd3685f95e587137f78a5c9504 [2] https://github.com/coin-or/CppAD/commit/278d8dbf63b42130f25acf03d5dbefdf6200a107 [3] https://github.com/coin-or/CppAD/commit/5a139ae40b5ee0bde2474a5fc0c17ead3365effb
Bug#1032734: OOM when unlocking encrypted root in initramfs
Control: tag -1 - moreinfo Control: severity -1 important Control: retitle -1 Argon2 memory cost is not future proof and might OOM on dist-upgrade on memory-constrained systems On Sat, 11 Mar 2023 at 14:53:37 -0500, Jérôme Charaoui wrote: >> Jérôme, what memory cost is the keyslot using? (Paste the output of >> `cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.) > > - 8< - > # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: > PBKDF: argon2i > Time cost: 4 > Memory: 787907 > Threads:1 > - >8 - > […] > So, I think what's happening is that the first VM may have been created with > a different (larger) memory configuration, and was reduced at a later point > in time. I don't have absolute certainty of this, but it would very well > explain the discrepancy in memory cost. I'm very sure it's the case: buster, bullseye, bookworm (and everything in between) never set the memory cost to more than half the physical memory. So it's just not possible to end up with such a high memory cost on a machine with only 1GiB RAM. Memory-hard KDF parameters are non portable and this is a feature not a bug :-) Upon hardware change one needs to run the benchmark again via cryptsetup-luksChangeKey(8) or similar to tune the parameters to the new system; and downgrading hardware needs to be done with care as folks who bootstrap images for RPI-like boards are surely aware. It's a coincidence that you triggered the OOM-killer only after the post dist-upgrade reboot, you were already likely close to memory exhaustion after reducing memory. > I there any way we could make the cryptsetup-initramfs hook aware of this, > and emit a warning if it finds that the encrypted root lacks a keyslot with > appropriate (low-enough) memory cost? I don't think the hook is the place for that: 1/ it might not have access to the header where this information resides, 2/ it doesn't know beforehand which keyslot will be used, and 3/ the issue is not specific to cryptsetup-initramfs. There is an upstream commit on the main branch that adds a warning to libcryptsetup, might cherry-pick that to bookworm instead. Anyway, lowering this to sub-RC now that it's demystified. In your case the root issue (KDF parameter portability) is wontfix/notabug, but I'm hijacking this to point out that KDF parameters are not future proof. (This is what the forwarded upstream bug points to, and what I initially thought you might be experiencing.) Things work fine out of the box on minimal systems (also with <1GiB RAM), but several releases down the road we might ship a kernel or early boot daemons requiring a lot more memory, and the KDF *will* exhaust memory at that point. The upstream fix in !490 (neither in bookworm nor sid yet) improves things a bit but really is only buying time. Milan suggested that systems with little RAM are probably better off using a non-memory-hard KDF. Perhaps upstream could be convinced to have different defaults depending on the amount of physical memory, if not then perhaps it could be done in partman-crypto (I personally wouldn't feel comfortable carrying such a patch in src:cryptsetup or have defaults that are unaligned with upstream or other distros). Won't help with existing keyslots though. -- Guilhem. signature.asc Description: PGP signature
Processed: Re: Bug#1032734: OOM when unlocking encrypted root in initramfs
Processing control commands: > tag -1 - moreinfo Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Removed tag(s) moreinfo. > severity -1 important Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Severity set to 'important' from 'serious' > retitle -1 Argon2 memory cost is not future proof and might OOM on > dist-upgrade on memory-constrained systems Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Changed Bug title to 'Argon2 memory cost is not future proof and might OOM on dist-upgrade on memory-constrained systems' from 'OOM when unlocking encrypted root in initramfs'. -- 1032734: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032734 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1032168: meson: autopkgtest fills disk completely
On Thu, 9 Mar 2023 at 13:54, Paul Gevers wrote: > Of course I expect you can also just use a porterbox which are there for > this reason: https://wiki.debian.org/PorterBoxHowToUse I have requested access to those but nothing has happened as of yet and I have no idea how long that processing is going to take.
Bug#1032734: OOM when unlocking encrypted root in initramfs
Tagging ‘moreinfo’ then. I can definitely see how one can reproduce this theoretically (and possibly in the future when the kernel's memory requirement increase high enough), and mentioned that in the upstream bug, but I'm unable to find a reproducer after dist-upgrading bullseye systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso, and “Encrypted LVM” partition scheme, on VMs with 1024M RAM). Jérôme, what memory cost is the keyslot using? (Paste the output of `cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.) Would also be interested to see by how much the amount of memory available to cryptsetup has changed before and after the uprade. Please edit /usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at the begining of the setup_mapping() function (patch attached). My own findings are as follows (again on a minimal netinst system without changing any default). cryptsetup isn't even close to memory exhaustion. Memory cost: - 8< - # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: PBKDF: argon2i Time cost: 4 Memory: 787907 Threads:1 - >8 - Free memory: - 8< - Loading Linux 6.1.0-5-amd64 ... Loading initial ramdisk ... totalusedfree shared buff/cache available Mem: 993756 74720 725012 60 194024 660412 Swap: 0 0 0 - >8 - I've also tested on another of my virtual machines that has 1GiB of RAM and got another result, closer to what you got in your experimentation: - 8< - # cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: PBKDF: argon2i Time cost: 6 Memory: 499912 Threads:1 - >8 - So, I think what's happening is that the first VM may have been created with a different (larger) memory configuration, and was reduced at a later point in time. I don't have absolute certainty of this, but it would very well explain the discrepancy in memory cost. Also, I think I agree with your assessment that in the memory usage increase of the kernel may be involved: between the two releases, according to your numbers it appears to have increased nearly 25% (!). So it could also explain why it (probably very nearly) worked under bullseye. I there any way we could make the cryptsetup-initramfs hook aware of this, and emit a warning if it finds that the encrypted root lacks a keyslot with appropriate (low-enough) memory cost? Thanks, -- Jérôme
Bug#1032734: OOM when unlocking encrypted root in initramfs
Control: found -1 2:2.1.0-5+deb10u2 Control: tag -1 moreinfo Hi kibi, On Sat, 11 Mar 2023 at 15:16:01 +0100, Cyril Brulebois wrote: > Guilhem Moulin (2023-03-11): >> On Sat, 11 Mar 2023 at 08:26:27 -0500, Jérôme Charaoui wrote: >>> Today I upgraded a small KVM machine with a LUKS2 encrypted root and 1GiB of >>> RAM to bookworm, and was very surprised to be confronted with an OOM >>> immediately upon entering my LUKS password in the initramfs prompt: >>> […] >>> The problem appears to be perhaps related to #924560, but in this instance, >>> the issue causing an unbootable system post-upgrade. >> >> No, this is related to #1028250 and >> https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872 . >> Don't think we can do anything in src:cryptsetup for existing volumes >> unfortunately. You might need to manually lower the parameters of your >> PBKDF. > > Existing systems failing to boot after an upgrade doesn't seem to be > “only” important to me… I fail to see how that's different from an existing resource-constrained system (sarge recommends for 64MiB RAM for desktop i386) being unusable after dist-upgrading to a more recent Debian release. Granted I haven't tried it, but I very much doubt GNOME would still work with that little memory :-) Anyway, while it definitely isn't ideal (not very future proof) that the key slots were created with a memory cost close to the whole available memory, there is actually not that much difference in resident set size before and after the upgrade. The test environment is a VM with 1024M RAM, and initialized with d-i's debian-10.12.0-amd64-netinst.iso and “Encrypted LVM” partition scheme. In my case the PBKDF benchmark chose the following parameters (close to half the amount of physical memory indeed): ~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: PBKDF: argon2i Time cost: 4 Memory: 504962 Threads:2 ## buster (cryptsetup 2:2.1.0-5+deb10u2, linux 4.19+105+deb10u18) ~# command time cryptsetup luksOpen --test-passphrase /dev/vda5 <<> Lowering the severity, because this shouldn't block the transition of -2 >> into bookworm (which fixes an unrelated and arguably much more severe RC >> bug). > > That's not really how RC bugs work: bugs aren't less RC because it makes > sense for a specific version to migrate… > > Either the bug appeared specifically in the version it was filed against, > and it makes sense to block the migration since that's a new RC bug in > that particular version, and the RC-ness stays. > > Or the bug was already there in the version currently in testing, and that > means that's not a regression, and the RC-ness stays. You only need to > record the bug as also being found in the previous version (possibly > plural) to make sure britney knows it's not a regression. Ah cool didn't know that, thanks for the information. Marking this as found all the way back to buster then. I'm indeed able to trigger the OOM-killer on a buster system when I artificially fill the memory so the memory cost exceeds what remains. Furthermore I don't see what can be done about existing keyslots, and that includes everything created since buster. > Sure, we can discuss the severity of the bug I filed. But #1032734 really > can't be “just” important. Tagging ‘moreinfo’ then. I can definitely see how one can reproduce this theoretically (and possibly in the future when the kernel's memory requirement increase high enough), and mentioned that in the upstream bug, but I'm unable to find a reproducer after dist-upgrading bullseye systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso, and “Encrypted LVM” partition scheme, on VMs with 1024M RAM). Jérôme, what memory cost is the keyslot using? (Paste the output of `cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.) Would also be interested to see by how much the amount of memory available to cryptsetup has changed before and after the uprade. Please edit /usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at the begining of the setup_mapping() function (patch attached). My own findings are as follows (again on a minimal netinst system without changing any default). cryptsetup isn't even close to memory exhaustion. ## bullseye (cryptsetup 2:2.3.7-1+deb11u1, linux 5.10.162-1) ~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF: PBKDF: argon2i Time cost: 4 Memory: 499892 Threads:2 ~# systemctl reboot Loading Linux 5.10.0-21-amd64 ... Loading initial ramdisk ... totalusedfree shared buff/cache available Mem: 999776 39276 843280 52 117220 777124 Swap: 0 0 0 Please unlock disk vda5_crypt: 1.90user
Processed: Re: Bug#1032734: OOM when unlocking encrypted root in initramfs
Processing control commands: > found -1 2:2.1.0-5+deb10u2 Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Marked as found in versions cryptsetup/2:2.1.0-5+deb10u2. > tag -1 moreinfo Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Added tag(s) moreinfo. -- 1032734: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032734 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1030205: marked as done (scilab: Could not find Java package '/usr/share/java/batik-all-1.14.jar')
Your message dated Sat, 11 Mar 2023 18:29:20 + with message-id and subject line Bug#1030205: fixed in scilab 6.1.1+dfsg2-5 has caused the Debian Bug report #1030205, regarding scilab: Could not find Java package '/usr/share/java/batik-all-1.14.jar' to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1030205: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030205 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: scilab version: 6.1.1+dfsg2-4 Severity: important I have Debian testing and after installing scilab, it shows that log and does not open: Picked up _JAVA_OPTIONS: -Djava.class.path=/usr/share/java/flexdock.jar:/usr/sha re/java/skinlf.jar:/usr/share/java/looks.jar:/usr/share/java/commons-logging.jar :/usr/share/java/jhall.jar:/usr/share/java/lucene-core-4.10.4.jar:/usr/share/jav a/lucene-analyzers-common-4.10.4.jar:/usr/share/java/lucene-queryparser-4.10.4.j ar:/usr/share/maven-repo/org/freehep/freehep-util/debian/freehep-util-debian.jar :/usr/share/maven-repo/org/freehep/freehep-io/debian/freehep-io-debian.jar:/usr/ share/maven-repo/org/freehep/freehep-graphicsio/debian/freehep-graphicsio-debian .jar:/usr/share/java/freehep-graphicsio-emf.jar:/usr/share/java/freehep-graphics 2d.jar:/usr/share/java/jrosetta-API.jar:/usr/share/java/jrosetta-engine.jar:/usr /share/java/jgraphx.jar:/usr/share/java/jogl2.jar:/usr/share/java/gluegen2-rt.ja r:/usr/share/java/jeuclid-core.jar:/usr/share/java/jlatexmath-fop.jar:/usr/share /java/fop.jar:/usr/share/java/saxon.jar:/usr/share/java/batik.jar:/usr/share/jav a/xml-apis-ext.jar:/usr/share/java/commons-io.jar:/usr/share/java/xmlgraphics-co mmons.jar:/usr/share/java/avalon-framework.jar:/usr/share/java/jlatexmath.jar:/u sr/share/java/ecj.jar:/usr/share/java/javax.activation.jar:/usr/share/java/jaxb- runtime.jar:/usr/share/scilab/modules/xcos/jar/org.scilab.modules.xcos.jar:/usr/ share/scilab/modules/graphic_export/jar/org.scilab.modules.graphic_export.jar:/u sr/share/scilab/modules/completion/jar/org.scilab.modules.completion.jar:/usr/sh are/scilab/modules/action_binding/jar/org.scilab.modules.action_binding.jar:/usr /share/scilab/modules/gui/jar/org.scilab.modules.gui.jar:/usr/share/scilab/modul es/history_browser/jar/org.scilab.modules.history_browser.jar:/usr/share/scilab/ modules/graph/jar/org.scilab.modules.graph.jar:/usr/share/scilab/modules/scirend erer/jar/scirenderer.jar:/usr/share/scilab/modules/scinotes/jar/org.scilab.modul es.scinotes.jar:/usr/share/scilab/modules/history_manager/jar/org.scilab.modules .history_manager.jar:/usr/share/scilab/modules/commons/jar/org.scilab.modules.co mmons.jar:/usr/share/scilab/modules/external_objects_java/jar/org.scilab.modules .external_objects_java.jar:/usr/share/scilab/modules/graphic_objects/jar/org.sci lab.modules.graphic_objects.jar:/usr/share/scilab/modules/jvm/jar/org.scilab.mod ules.jvm.jar:/usr/share/scilab/modules/core/jar/org.scilab.modules.core.jar:/usr /share/scilab/modules/renderer/jar/org.scilab.modules.renderer.jar:/usr/share/sc ilab/modules/ui_data/jar/org.scilab.modules.ui_data.jar:/usr/share/scilab/module s/preferences/jar/org.scilab.modules.preferences.jar:/usr/share/scilab/modules/j avasci/jar/org.scilab.modules.javasci.jar:/usr/share/scilab/modules/console/jar/ org.scilab.modules.console.jar:/usr/share/scilab/modules/localization/jar/org.sc ilab.modules.localization.jar:/usr/share/scilab/modules/types/jar/org.scilab.mod ules.types.jar:/usr/share/scilab/modules/helptools/jar/org.scilab.modules.helpto ols.jar:/usr/share/scilab/modules/helptools/jar/scilab_ru_RU_help.jar:/usr/share /scilab/modules/helptools/jar/scilab_en_US_help.jar:/usr/share/scilab/modules/he lptools/jar/scilab_images.jar: Warning: Could not find Java package '/usr/share/java/batik-all-1.14.jar'. Some problems during the loading of the Java libraries occurred. This could lead to inconsistent behaviours. Please check SCI/etc/classpath.xml. The native library scilocalization does not exist or cannot be found. no scilocalization in java.library.path: java.lang.UnsatisfiedLinkError: no scilocalization in java.library.path: at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2429) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:818) at java.base/java.lang.System.loadLibrary(System.java:1989) at org.scilab.modules.localization.MessagesJNI.(Unknown Source) at org.scilab.modules.localization.Messages.gettext(Unknown Source) at org.scilab.modules.commons.xml.XConfiguration.(Unknown Source ) at
Bug#1012099: marked as done (scilab: FTBFS with OpenJDK 17: no scilocalization in java.library.path)
Your message dated Sat, 11 Mar 2023 18:29:20 + with message-id and subject line Bug#1012099: fixed in scilab 6.1.1+dfsg2-5 has caused the Debian Bug report #1012099, regarding scilab: FTBFS with OpenJDK 17: no scilocalization in java.library.path to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1012099: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012099 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: scilab Version: 6.1.1+dfsg2-3 Severity: important Tags: ftbfs sid bookworm User: debian-j...@lists.debian.org Usertags: default-java17 scilab fails to build with OpenJDK 17: -- Building documentation (en_US) -- LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1 SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true' HOME=/tmp ./bin/scilab-adv-cli - noatomsautoload -nb -l en_US -nouserstartup -e "try xmltojar([],[],'en_US');catch disp(lasterror()); exit(-1);end;exit(0);" Picked up _JAVA_OPTIONS: - Djava.class.path=/usr/share/java/flexdock.jar:/usr/share/java/skinlf.jar:/usr/sh are/java/looks.jar:/usr/share/java/commons- logging.jar:/usr/share/java/jhall.jar:/usr/share/java/lucene-core- 4.10.4.jar:/usr/share/java/lucene-analyzers-common- 4.10.4.jar:/usr/share/java/lucene-queryparser-4.10.4.jar:/usr/share/maven- repo/org/freehep/freehep-util/debian/freehep-util-debian.jar:/usr/share/maven- repo/org/freehep/freehep-io/debian/freehep-io-debian.jar:/usr/share/maven- repo/org/freehep/freehep-graphicsio/debian/freehep-graphicsio- debian.jar:/usr/share/java/freehep-graphicsio-emf.jar:/usr/share/java/freehep- graphics2d.jar:/usr/share/java/jrosetta-API.jar:/usr/share/java/jrosetta- engine.jar:/usr/share/java/jgraphx.jar:/usr/share/java/jogl2.jar:/usr/share/java /gluegen2-rt.jar:/usr/share/java/jeuclid-core.jar:/usr/share/java/jlatexmath- fop.jar:/usr/share/java/fop.jar:/usr/share/java/saxon.jar:/usr/share/java/batik. jar:/usr/share/java/xml-apis-ext.jar:/usr/share/java/commons- io.jar:/usr/share/java/xmlgraphics-commons.jar:/usr/share/java/avalon- framework.jar:/usr/share/java/jlatexmath.jar:/usr/share/java/ecj.jar:/usr/share/ java/javax.activation.jar:/usr/share/java/jaxb- runtime.jar:modules/external_objects_java/jar/org.scilab.modules.external_object s_java.jar:modules/jvm/jar/org.scilab.modules.jvm.jar:modules/scirenderer/jar/sc irenderer.jar:modules/javasci/jar/org.scilab.modules.javasci.jar:modules/history _browser/jar/org.scilab.modules.history_browser.jar:modules/console/jar/org.scil ab.modules.console.jar:modules/action_binding/jar/org.scilab.modules.action_bind ing.jar:modules/completion/jar/org.scilab.modules.completion.jar:modules/graphic _objects/jar/org.scilab.modules.graphic_objects.jar:modules/types/jar/org.scilab .modules.types.jar:modules/commons/jar/org.scilab.modules.commons.jar:modules/hi story_manager/jar/org.scilab.modules.history_manager.jar:modules/graph/jar/org.s cilab.modules.graph.jar:modules/ui_data/jar/org.scilab.modules.ui_data.jar:modul es/scinotes/jar/org.scilab.modules.scinotes.jar:modules/core/jar/org.scilab.modu les.core.jar:modules/graphic_export/jar/org.scilab.modules.graphic_export.jar:mo dules/helptools/jar/org.scilab.modules.helptools.jar:modules/localization/jar/or g.scilab.modules.localization.jar:modules/gui/jar/org.scilab.modules.gui.jar:mod ules/renderer/jar/org.scilab.modules.renderer.jar:modules/xcos/jar/org.scilab.mo dules.xcos.jar:modules/preferences/jar/org.scilab.modules.preferences.jar: - Djava.awt.headless=true The native library scilocalization does not exist or cannot be found. no scilocalization in java.library.path: java.lang.UnsatisfiedLinkError: no scilocalization in java.library.path: at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2429) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:818) at java.base/java.lang.System.loadLibrary(System.java:1989) at org.scilab.modules.localization.MessagesJNI.(Unknown Source) at org.scilab.modules.localization.Messages.gettext(Unknown Source) at org.scilab.modules.commons.xml.XConfiguration.(Unknown Source) at org.scilab.modules.core.Scilab.(Unknown Source) Could not access to the Main Scilab Class: Exception in thread "main" java.lang.UnsatisfiedLinkError: 'java.lang.String org.scilab.modules.localization.MessagesJNI.gettext(java.lang.String)' at org.scilab.modules.localization.MessagesJNI.gettext(Native Method) at
Processed: Merge kded crasher bugs
Processing commands for cont...@bugs.debian.org:
> forcemerge 1026062 1028208
Bug #1026062 {Done: Matthias Klumpp } [libpackagekitqt5-1]
packagekit-qt: use-after-free in PackageKit::Transaction
Bug #1027326 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
Bug #1028083 {Done: Matthias Klumpp } [libpackagekitqt5-1]
plasma-discover: Discover tray app crashes kded5, causing other system tray
icons to vanish
Bug #1030854 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kded5: It keeps on crashing everytime I boot into the system
Bug #1028208 [libpackagekitqt5-1] plasma-discover: Program terminated with
signal SIGSEGV
Set Bug forwarded-to-address to
'https://github.com/PackageKit/PackageKit-Qt/issues/42'.
Severity set to 'serious' from 'normal'
Marked Bug as done
Added indication that 1028208 affects kded5
Marked as fixed in versions packagekit-qt/1.1.1-1.
Added tag(s) fixed-upstream.
Bug #1027326 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
Bug #1028083 {Done: Matthias Klumpp } [libpackagekitqt5-1]
plasma-discover: Discover tray app crashes kded5, causing other system tray
icons to vanish
Bug #1030854 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kded5: It keeps on crashing everytime I boot into the system
Merged 1026062 1027326 1028083 1028208 1030854
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
1026062: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
1027326: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027326
1028083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028083
1028208: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028208
1030854: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1032706: [pkg-lxc-devel] Bug#1032706: lxc-snapshot cannot restore containers with loop storage backend
Hi Mario, I'm currently on travel with not-so-great network connectivity, so I haven't been able to reproduce this on my travel laptop, but will attempt to do so when I'm back from my trip. I expect that this issue will have to be forwarded to the lxc developers; if you want to do so you can submit an issue at https://github.com/lxc/lxc/issues, otherwise I'll so after reproducing the issue myself. To help ensure I'll be following exactly what you did, could you share the commands you used to setup the loop storage backend, the creation of the container, snapshoting, and attempted restoration of that snapshot? Thanks, Mathias signature.asc Description: This is a digitally signed message part
Processed: reassign 1032731 to python3-trezor
Processing commands for cont...@bugs.debian.org: > reassign 1032731 python3-trezor 0.12.4-1 Bug #1032731 [python-trezor] Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback' Bug reassigned from package 'python-trezor' to 'python3-trezor'. No longer marked as found in versions 0.12.4-1. Ignoring request to alter fixed versions of bug #1032731 to the same values previously set Bug #1032731 [python3-trezor] Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback' Marked as found in versions python-trezor/0.12.4-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1032731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Merge kded crasher bugs
Processing commands for cont...@bugs.debian.org:
> forcemerge 1026062 1030854
Bug #1026062 {Done: Matthias Klumpp } [libpackagekitqt5-1]
packagekit-qt: use-after-free in PackageKit::Transaction
Bug #1027326 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
Bug #1028083 {Done: Matthias Klumpp } [libpackagekitqt5-1]
plasma-discover: Discover tray app crashes kded5, causing other system tray
icons to vanish
Bug #1030854 [libpackagekitqt5-1] kded5: It keeps on crashing everytime I boot
into the system
Set Bug forwarded-to-address to
'https://github.com/PackageKit/PackageKit-Qt/issues/42'.
Severity set to 'serious' from 'normal'
Marked Bug as done
Added indication that 1030854 affects kded5
Marked as fixed in versions packagekit-qt/1.1.1-1.
Added tag(s) fixed-upstream.
Bug #1027326 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
Bug #1028083 {Done: Matthias Klumpp } [libpackagekitqt5-1]
plasma-discover: Discover tray app crashes kded5, causing other system tray
icons to vanish
Merged 1026062 1027326 1028083 1030854
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
1026062: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
1027326: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027326
1028083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028083
1030854: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: Merge kded crasher bugs
Processing commands for cont...@bugs.debian.org:
> forcemerge 1026062 1027326
Bug #1026062 {Done: Matthias Klumpp } [libpackagekitqt5-1]
packagekit-qt: use-after-free in PackageKit::Transaction
Bug #1027326 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
Bug #1028083 {Done: Matthias Klumpp } [libpackagekitqt5-1]
plasma-discover: Discover tray app crashes kded5, causing other system tray
icons to vanish
Bug #1027326 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
Bug #1028083 {Done: Matthias Klumpp } [libpackagekitqt5-1]
plasma-discover: Discover tray app crashes kded5, causing other system tray
icons to vanish
Merged 1026062 1027326 1028083
> forcemerge 1026062 1028083
Bug #1026062 {Done: Matthias Klumpp } [libpackagekitqt5-1]
packagekit-qt: use-after-free in PackageKit::Transaction
Bug #1027326 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
Bug #1028083 {Done: Matthias Klumpp } [libpackagekitqt5-1]
plasma-discover: Discover tray app crashes kded5, causing other system tray
icons to vanish
Bug #1027326 {Done: Matthias Klumpp } [libpackagekitqt5-1]
kde-plasma-desktop: Process 1465 (kded5) of user 1000 dumped core.
Bug #1028083 {Done: Matthias Klumpp } [libpackagekitqt5-1]
plasma-discover: Discover tray app crashes kded5, causing other system tray
icons to vanish
Merged 1026062 1027326 1028083
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
1026062: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
1027326: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027326
1028083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028083
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: your mail
Processing commands for cont...@bugs.debian.org:
> severity 1026062 serious
Bug #1026062 {Done: Matthias Klumpp } [libpackagekitqt5-1]
packagekit-qt: use-after-free in PackageKit::Transaction
Severity set to 'serious' from 'normal'
> severity 1027831 serious
Bug #1027831 {Done: Matthias Klumpp } [libpackagekitqt5-1]
libpackagekitqt5-1: Discover does not notify about pending updates
Severity set to 'serious' from 'normal'
> forcemerge 1026062 1027326 1028083
Bug #1026062 {Done: Matthias Klumpp } [libpackagekitqt5-1]
packagekit-qt: use-after-free in PackageKit::Transaction
Bug #1027326 [libpackagekitqt5-1] kde-plasma-desktop: Process 1465 (kded5) of
user 1000 dumped core.
Set Bug forwarded-to-address to
'https://github.com/PackageKit/PackageKit-Qt/issues/42'.
Severity set to 'serious' from 'normal'
Marked Bug as done
Added indication that 1027326 affects kded5
Marked as fixed in versions packagekit-qt/1.1.1-1.
Added tag(s) fixed-upstream.
Bug #1028083 [libpackagekitqt5-1] plasma-discover: Discover tray app crashes
kded5, causing other system tray icons to vanish
Set Bug forwarded-to-address to
'https://github.com/PackageKit/PackageKit-Qt/issues/42'.
Severity set to 'serious' from 'normal'
Marked Bug as done
Added indication that 1028083 affects kded5
Marked as fixed in versions packagekit-qt/1.1.1-1.
Added tag(s) fixed-upstream.
Merged 1026062 1027326 1028083
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
1026062: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026062
1027326: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027326
1027831: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027831
1028083: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028083
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1028780: python-libzim: FTBFS: libzim/libwrapper.h:161:29: error: ‘class zim::Archive’ has no member named ‘getMediaCount’
I have just learned about this ticket and have opened a ticket upstream: https://github.com/openzim/python-libzim/issues/160 Like I said there, this version of python-libzim requires libzim-8.1.0 so: * either there is a problem in getMediaCount() declaration in libzim headers OR * Debian compiles against an older version of the libzim Looking at the package names visible at https://packages.debian.org/search?searchon=sourcenames=zimlib I really wonder if we have libzim-8.1.0 in the most recent dev/testing versions of Debian!? Could someone please confirm the real version of the libzim that python-libzim package tries to build against? -- Kiwix - Wikipedia Offline & more * Web: https://kiwix.org/ * Mastodon: https://mastodon.social/@kiwix * Wiki: https://wiki.kiwix.org/ OpenPGP_signature Description: OpenPGP digital signature
Processed: reassign 1032731 to python-trezor
Processing commands for cont...@bugs.debian.org: > reassign 1032731 python-trezor 0.12.4-1 Bug #1032731 [trezor] Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback' Bug reassigned from package 'trezor' to 'python-trezor'. No longer marked as found in versions python-trezor/0.12.4-1. Ignoring request to alter fixed versions of bug #1032731 to the same values previously set Bug #1032731 [python-trezor] Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback' There is no source info for the package 'python-trezor' at version '0.12.4-1' with architecture '' Unable to make a source version for version '0.12.4-1' Marked as found in versions 0.12.4-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1032731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#919058: its-tools: crashes when freeing xmlDocs
Dear Maintainer, This issue fixed in libxml2 seems to be related [1] Kind Regards [1] https://gitlab.gnome.org/GNOME/libxml2/-/issues/64
Bug#1032544: pylint: FTBFS in testing: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
This may be related, or just a duplicate, to #1032043, fixed in the newer version which is already in testing.
Bug#1032553: magic-wormhole: FTBFS in testing: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13
On Wed, Mar 08, 2023 at 09:30:04PM +0100, Lucas Nussbaum wrote: > > == > > FAIL: test_welcome (wormhole.test.test_wormhole.Wormholes.test_welcome) > > test_welcome > > -- > > Traceback (most recent call last): > > File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line > > 1656, in _inlineCallbacks > > result = current_context.run( > > > > File "/usr/lib/python3/dist-packages/twisted/python/failure.py", line > > 517, in throwExceptionIntoGenerator > > return g.throw(self.type, self.value, self.tb) > >^^^ > > File "/<>/src/wormhole/test/test_wormhole.py", line 508, in > > test_welcome > > yield self.assertFailure(w2.close(), WrongPasswordError) > > File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line > > 857, in _runCallbacks > > current.result = callback( # type: ignore[misc] > > ^^^ > > File "/usr/lib/python3/dist-packages/twisted/trial/_asynctest.py", line > > 76, in _eb > > raise self.failureException(output) > > twisted.trial.unittest.FailTest: > > Expected: (,) > > Got: > > [Failure instance: Traceback (failure with no frames): > 'wormhole.errors.LonelyError'>: > > ] > > > > -- This is mentioned in https://github.com/magic-wormhole/magic-wormhole/issues/458 as likely a "timing issue". Not sure if it's fixed upstream.
Processed (with 1 error): reassign 1032731 to python-trezor/0.12.4-1, affects 1032731, tagging 1032731
Processing commands for cont...@bugs.debian.org: > reassign 1032731 python-trezor/0.12.4-1 Unknown command or malformed arguments to command. > affects 1032731 trezor Bug #1032731 [trezor] Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback' Added indication that 1032731 affects trezor > tags 1032731 + upstream fixed-upstream patch Bug #1032731 [trezor] Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback' Added tag(s) upstream, patch, and fixed-upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 1032731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1032734: OOM when unlocking encrypted root in initramfs
Processing control commands: > severity -1 serious Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Severity set to 'serious' from 'important' -- 1032734: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032734 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1032734: OOM when unlocking encrypted root in initramfs
Control: reassign -1 cryptsetup-bin 2:2.6.1-2 Control: severity -1 important Control: tag -1 upstream Control: forwarded -1 https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872 Hi, On Sat, 11 Mar 2023 at 08:26:27 -0500, Jérôme Charaoui wrote: > Today I upgraded a small KVM machine with a LUKS2 encrypted root and 1GiB of > RAM to bookworm, and was very surprised to be confronted with an OOM > immediately upon entering my LUKS password in the initramfs prompt: > […] > The problem appears to be perhaps related to #924560, but in this instance, > the issue causing an unbootable system post-upgrade. No, this is related to #1028250 and https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872 . Don't think we can do anything in src:cryptsetup for existing volumes unfortunately. You might need to manually lower the parameters of your PBKDF. Lowering the severity, because this shouldn't block the transition of -2 into bookworm (which fixes an unrelated and arguably much more severe RC bug). See also the d-i errata for Bookworm Alpha 2. I'm also not certain that #-1 is RC, after all Debian's memory requirements have consistently increased since the start of the project, so IMHO one has to accept that hardware might need to be dusted up on upgrade. Compare https://www.debian.org/releases/potato/i386/ch-hardware-req.en.html §2.3 with https://www.debian.org/releases/bullseye/amd64/ch03s04.en.html §3.4 Either way the issue definitely needs to be mentioned in Bookworm's release notes. cheers -- Guilhem. signature.asc Description: PGP signature
Processed: Re: Bug#1032734: OOM when unlocking encrypted root in initramfs
Processing control commands: > reassign -1 cryptsetup-bin 2:2.6.1-2 Bug #1032734 [cryptsetup] OOM when unlocking encrypted root in initramfs Bug reassigned from package 'cryptsetup' to 'cryptsetup-bin'. No longer marked as found in versions cryptsetup/2:2.6.1-1. Ignoring request to alter fixed versions of bug #1032734 to the same values previously set Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Marked as found in versions cryptsetup/2:2.6.1-2. > severity -1 important Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Severity set to 'important' from 'critical' > tag -1 upstream Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Added tag(s) upstream. > forwarded -1 > https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872 Bug #1032734 [cryptsetup-bin] OOM when unlocking encrypted root in initramfs Set Bug forwarded-to-address to 'https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872'. -- 1032734: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032734 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit: >Based on what I've learned about this bug, I believe that architecture-specific >behaviour related to stack sizes is inherent in the V8 library vendored by >upstream NodeJS. Yes, but the v8 library’s defaults are targetting a browser, and one whose uses are much wider, e.g. inside Android, than NodeJS’s itself. Which is why I believe that NodeJS very much can and certainly should fix this by setting suitable limits. >long time. Individual codebases such as the affected 'src:dygraphs' package >can also be improved to reduce the likelihood of call stack size overflow. It’s babel7 actually which runs into this. And I believe that, rather to the contrary, further evolution of software-written-in-NodeJS will let this error show up *more* and probably on nōn-arm64 as well(!), so I’d rather have NodeJS set proper limits instead of sticking to v8’s given the latter has a different scope and run-time environment than the former. >Given those, and the absence of any sense that this is a regression, I think we >should lower the priority of this bug to below release-critical. I very much disagree, this breaks arch:all packages on some platforms so it causes issues packagers who don’t themselves use arm64 cannot discover in the first place. We need to at least achieve architecture partity in Debian, pending better upstream fixes. bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Bug#1032734: OOM when unlocking encrypted root in initramfs
Package: cryptsetup Version: 2:2.6.1-1 Severity: critical Dear maintainer, Today I upgraded a small KVM machine with a LUKS2 encrypted root and 1GiB of RAM to bookworm, and was very surprised to be confronted with an OOM immediately upon entering my LUKS password in the initramfs prompt: Loading Linux 6.1.0-5-amd64 ... Loading initial ramdisk ... Please unlock disk vda5_crypt: [7.982435] Out of memory: Killed process 243 (cryptsetup) total-vm:799000kB, anon-rss:678296kB, file-rss:6440kB, shmem-rss:0kB, UID:0 pgtables:1384kB oom_score_adj:0 Killed cryptsetup: ERROR: vda5_crypt: cryptsetup failed, bad password or options? This machine was booting just fine before upgrading, under bullseye. The problem appears to be perhaps related to #924560, but in this instance, the issue causing an unbootable system post-upgrade. Thanks, -- Jérôme
Processed: Re: Bug#1032174: xfishtank does nothing
Processing control commands: > severity 1032174 important Bug #1032174 [xfishtank] xfishtank does nothing Severity set to 'important' from 'grave' > retitle 1032174 xfishtank does not work on modern desktop Bug #1032174 [xfishtank] xfishtank does nothing Changed Bug title to 'xfishtank does not work on modern desktop' from 'xfishtank does nothing'. -- 1032174: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032174 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1032174: xfishtank does nothing
Control: severity 1032174 important Control: retitle 1032174 xfishtank does not work on modern desktop environments Control: tags 1032174 upstream Thanks for your bug report Martin, xfishtank is implemented by drawing on the root window, which does not work on modern desktop environments such as KDE or Xfce. It works fine on XMonad, Openbox, and other traditional window managers, so I'm downgrading the severity to important. The project is abandoned upstream, but I'm aware of one revival attempt[0] which modernizes xfishtank but still draws on the root window, so this bug would not be fixed. Still, I should package the latest version from this revival. I was not aware of Willem Vermin's project. I looked at the gitlab and I don't know that status of this project. There's a single commit, and no releases. [0]: https://ratrabbit.nl/ratrabbit/software/xfishtank/index.html
Bug#1018023: marked as done (eterm: FTBFS with imlib2 1.9.1)
Your message dated Sat, 11 Mar 2023 11:33:58 + with message-id and subject line Bug#1018023: fixed in eterm 0.9.6-7 has caused the Debian Bug report #1018023, regarding eterm: FTBFS with imlib2 1.9.1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1018023: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018023 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: eterm Version: 0.9.6-6.1 Severity: important Tags: ftbfs sid bookwork User: a...@debian.org Usertags: imlib2-1.9.1 X-Debbugs-Cc: a...@debian.org Dear maintainer, your package fails to build from source with imlib2 1.9.1 in experimental. imlib2-config has been dropped by upstream in favor of pkg-config. Please adjust your build system accordingly. Looking closer there may be a different error that causes the FTBFS because of newly introduced symbols. In file included from menus.h:29, from actions.h:31, from actions.c:33: pixmap.h:224:20: error: conflicting types for ‘imlib_strerror’; have ‘const char *(Imlib_Load_Error)’ 224 | extern const char *imlib_strerror(Imlib_Load_Error); |^~ In file included from /usr/include/libast.h:79, from feature.h:100, from actions.c:27: /usr/include/Imlib2.h:2846:21: note: previous declaration of ‘imlib_strerror’ with type ‘const char *(int)’ 2846 | EAPI const char*imlib_strerror(int err); | ^~ I intend to upload imlib2 1.9.1 to unstable in one or two months. Feel free to reply to this bug report if you have any questions. Regards, Markus --- End Message --- --- Begin Message --- Source: eterm Source-Version: 0.9.6-7 Done: José Antonio Jiménez Madrid We believe that the bug you reported is fixed in the latest version of eterm, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1018...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. José Antonio Jiménez Madrid (supplier of updated eterm package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 10 Mar 2023 21:03:30 +0100 Source: eterm Architecture: source Version: 0.9.6-7 Distribution: unstable Urgency: medium Maintainer: José Antonio Jiménez Madrid Changed-By: José Antonio Jiménez Madrid Closes: 1018023 Changes: eterm (0.9.6-7) unstable; urgency=medium . * Fix FTBFS with imlib2 1.9.1. Closes: #1018023. Thanks to Matthew Vernon for pointing me to the patch used by netbsd. Checksums-Sha1: 6b07a448797528bd9f2f999e0a82735c0af4e2fe 2019 eterm_0.9.6-7.dsc 5364d433198e6d8dfdf196d66058a0c2ba0e1c1d 14068 eterm_0.9.6-7.debian.tar.xz Checksums-Sha256: 091df881c40f4ebb4b462722805c55b15643a1b503ef653af593f66b324c54d1 2019 eterm_0.9.6-7.dsc 5611777358b35bdb4178ef33a6e5a1464666fd7276aee5e7b095f6df89792c1e 14068 eterm_0.9.6-7.debian.tar.xz Files: 2555e0127c082c876ef1d0c9bd3276b6 2019 x11 optional eterm_0.9.6-7.dsc 47c4eeaa3f6b2623c3b1d56ea2bd9227 14068 x11 optional eterm_0.9.6-7.debian.tar.xz -BEGIN PGP SIGNATURE- iQJHBAEBCgAxFiEEuk75yE35bTfYoeLUEvTSHI9qY8gFAmQMY2UTHG1hdHRoZXdA ZGViaWFuLm9yZwAKCRAS9NIcj2pjyDp9EACLaLQ6CHzDlJDadPky/9+TZm28lZzu ceqBdiwktc8G7q39PzwP35fTxKAPuS+kaQMRryLgj2WKhovGlLQqRlwlCO0eo4Jt sH3EVGVENhonwxh1SuT2PTEqqwjKIxw3IkDRpAn0A+0HTgWNWQCnb2mwBo0h6SKl Waf51WoFJ4J9Ht/iDnH/LrBSudZbtxMQ5V0ouQYCGcExjSh/RwIQTIXh5b5FQ5hf kd0RFpUj7j9cxrbnPjXYXfp4h1CmckGQD3TTRWctl/IY5JyX9u1Trnao9SgmQCMw fWYZrWvt8+Fz0yp+MsQNxxCPnLr3s0JGY6lmoA0s8o9dFHqZshpLQ0yrfTjN4AhQ Lsfv2mrRREhKeUL3Y9T6GN9tFTOoRM9W24R8uMV+x4J1d0VtAS8XSWhwo9yguTCw 81vRNu6VYDCJcKSnFDQ9YlBY8xq4t7dIXfShROUW4qhNCJ/EjY4T42qZ0kpnvlQA eA5plh5x0iB2rm1EBUS/ZWuo0DzMBcC7FSZGXgv1RFuAk2QLNl1OMjl00qua4vPA +7fu9LUqvo0Ku3aa9qWJRVQgcruTTXs6RZg88wofEVjjFSJD5tFpVo+Qo+fS3Gv1 MW0mN8Iy9pmvg2FATUnz7sixe0ocIwVcgYda4wMhy25QBP3S8o+Ilox6rZJt5Bp+ U3qrDnmUL+Y1Mg== =xiDN -END PGP SIGNATURE End Message ---
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 X-Debbugs-Cc: t...@mirbsd.de On Thu, 02 Feb 2023 01:56:10 +, Thorsten wrote: > I consider this an architecture-specific release-critical bug. Maybe > having a reproducer and access to a porterbox will allow a nodejs > maintainer to track this down. Based on what I've learned about this bug, I believe that architecture-specific behaviour related to stack sizes is inherent in the V8 library vendored by upstream NodeJS. Improvements may be possible and we can continue to track and assist towards those, however there are likely to be runtime differences that remain for a long time. Individual codebases such as the affected 'src:dygraphs' package can also be improved to reduce the likelihood of call stack size overflow. Given those, and the absence of any sense that this is a regression, I think we should lower the priority of this bug to below release-critical.
Bug#1032733: gcc-10-doc should not be shipped in bookworm
Source: gcc-10-doc Version: 10.4.0-1 Severity: serious Control: block -1 by 1023666 Following gcc-10 removal, gcc-10-doc should not be shipped in bookworm release. -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1018023: Update on this bug?
Hi, On 10/03/2023 23:12, Jose Antonio Jimenez Madrid wrote: I have just uploaded to mentors a new version of the package fixing this bug. I will made other improvements after Bookworm is released as we are very close to the full freeze. The new package can be found here: https://mentors.debian.net/package/eterm/ Thanks; I've reviewed these changes and uploaded for you. I expect I'll need to file an unblock request in due course; I'll try and remember to do so. You were right to make the minimal bug-fix changes at this point in the release cycle; once bookworm is out it would be good to look at some of the other packaging issues; I'll be happy to sponsor further uploads if that's helpful. Regards, Matthew
Processed: gcc-10-doc should not be shipped in bookworm
Processing control commands: > block -1 by 1023666 Bug #1032733 [src:gcc-10-doc] gcc-10-doc should not be shipped in bookworm 1032733 was not blocked by any bugs. 1032733 was not blocking any bugs. Added blocking bug(s) of 1032733: 1023666 -- 1032733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032733 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Followup-For: Bug #1030284 X-Debbugs-Cc: t...@debian.org Guidance received from the V8 project (a vendored dependency in the upstream NodeJS codebase) on the v8-dev mailing list is, in summary/interpretation: * It is not yet safe to increase the stack size limit on ARM64 systems. * For a given constant stack size, recursion depth is architecture-dependent, and so the patch to restore the 984K stack size on ARM64 would not provide equal recursion depth on all systems. * Exceeding stack depth limits is generally a sign of an application that would benefit from relevant refactoring (personal note: for example, by reducing the depth of recursion required, or by replacing a recursive algorithm with an equivalent iterative algorithm). Sidenotes: A patch for 32-bit architectures could apparently be acceptable, although may be best offered to NodeJS rather than V8. For what it's worth: NodeJS seems to have a policy of not accepting patches to their vendored dependencies. None of this rules out an rlimit-based approach as suggested by Thorsten.
Bug#1032647: Testing with official Nvidia driver 530.30.02
Good morning, Quick update: in a moment of despair, I tried what felt like the last resort, which was installing the latest driver, from the Nvidia website. (I know, I know) Long story short, I stopped the X server, unloaded Nouveau, and ran the installation wizard ; it almost ran without issues (a weird little issue with DKMS, which I did not set up in the end), and finally ended up with the 530.30.02 installed. After having rebooted, the machine does not exhibit the same black screen flickering (depending on what's being drawn on screen e.g. tilix is set to fullscreen). I cannot be sure after such a short test, but it would seem that the latest version (530.30.02) of the Nvidia driver makes this issue disappear., at least on kernel version 6.1.0.5. Speaking of which, just to keep track of things, when updating to 525.89.02-1, I was on kernel 6.1.0.3 (package version: 6.1.8-1) and updating at the same time to kernel version 6.1.0-5 (package version: 6.1.12-1). Cheers, JB
Bug#1032731: Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'
Package: trezor
Version: 0.12.4-1
Severity: grave
X-Debbugs-Cc: nood...@earth.li
Control: forwarded -1 https://github.com/trezor/trezor-firmware/issues/2199
Installed trezor and tried to run it, got a traceback:
$ trezorctl
Traceback (most recent call last):
File "/usr/bin/trezorctl", line 33, in
sys.exit(load_entry_point('trezor==0.12.4', 'console_scripts',
'trezorctl')())
^^
File "/usr/bin/trezorctl", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/trezorlib/cli/trezorctl.py", line 171,
in
@cli.resultcallback()
^^
AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'. Did
you mean: 'result_callback'?
Looks like this is an issue with the Click usage and was fixed upstream in
0.13.1.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages trezor depends on:
ii python3 3.11.2-1
ii python3-trezor 0.12.4-1
trezor recommends no packages.
trezor suggests no packages.
-- no debconf information
Processed: Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'
Processing control commands: > forwarded -1 https://github.com/trezor/trezor-firmware/issues/2199 Bug #1032731 [trezor] Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback' Set Bug forwarded-to-address to 'https://github.com/trezor/trezor-firmware/issues/2199'. -- 1032731: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware"
Processing control commands: > reassign -1 debian-cd Bug #1005886 [cdimage.debian.org] cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware" Bug reassigned from package 'cdimage.debian.org' to 'debian-cd'. Ignoring request to alter found versions of bug #1005886 to the same values previously set Ignoring request to alter fixed versions of bug #1005886 to the same values previously set > retitle -1 debian-cd: bookworm net-install CD hangs on "Detecting Network > Hardware" Bug #1005886 [debian-cd] cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware" Changed Bug title to 'debian-cd: bookworm net-install CD hangs on "Detecting Network Hardware"' from 'cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware"'. -- 1005886: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005886 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1005886: cdimage.debian.org: bookworm net-install CD hangs on "Detecting Network Hardware"
Followup-For: Bug #1005886 Control: reassign -1 debian-cd Control: retitle -1 debian-cd: bookworm net-install CD hangs on "Detecting Network Hardware"
Bug#1032724: swift-im: should not be shipped with bookworm (RoM)
Source: swift-im Severity: serious Justification: RoM I've packaged swift-im for spectrum2, which has determined to be (currently) not suitable for inclusion to Debian due to a license incompatibilty. Therefore it currently makes no sense to have this huge library in a stable release, which is the purpose of this bug. If there is someone needing swift-im in stable, please reach out to me. -- tobi -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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
Bug#1032706: lxc-snapshot cannot restore containers with loop storage backend
Package: lxc Version: 1:5.0.2-1 Severity: grave Justification: causes data loss Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I tried to generate a snapshot with lxc-snapshot for a test container that is more than 1G of size. Snapshot generation does not show any problems but the restore does only restore 1G so the container is not able to start after restore. * What exactly did you do (or not do) that was effective (or ineffective)? One can create a new loop file with correct size and copy the snapshot contents in here but this renders this command absolute useless when using loop backend * What was the outcome of this action? Container cannot start * What outcome did you expect instead? A container that does start normally after restoring. -- System Information: Debian Release: bookworm/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0]1.5.82 ii dnsmasq-base [dnsmasq-base] 2.89-1 ii iproute2 6.1.0-2 ii iptables 1.8.9-2 ii libapparmor1 3.0.8-3 ii libc62.36-8 ii libcap2 1:2.66-3 ii libgcc-s112.2.0-14 ii liblxc-common1:5.0.2-1 ii liblxc1 1:5.0.2-1 ii libseccomp2 2.5.4-1+b3 ii libselinux1 3.4-1+b5 ii lsb-base 11.6 ii nftables 1.0.6-2 ii sysvinit-utils [lsb-base]3.06-2 Versions of packages lxc recommends: ii apparmor 3.0.8-3 ii debootstrap1.0.128+nmu2 ii dirmngr2.2.40-1 ii gnupg 2.2.40-1 ii libpam-cgfs1:5.0.2-1 ii lxc-templates 3.0.4.48.g4765da8-1 ii lxcfs 5.0.3-1 ii openssl3.0.8-1 ii rsync 3.2.7-1 ii uidmap 1:4.13+dfsg1-1 ii wget 1.21.3-1+b2 Versions of packages lxc suggests: pn btrfs-progs ii lvm2 2.03.16-2 pn python3-lxc -- debconf information: lxc/auto_update_config:
