Archive signature for sid broken?
Hello developers, is the signature for sid broken? When I do 'apt-get update', it complains about an invalid key, but that key mentions bullseye, not sid. A similar error shows for 'debootstrap sid sid' With kind regards, Roland Clobus --- Get:4 http://deb.debian.org/debian unstable InRelease [198 kB] Err:4 http://deb.debian.org/debian unstable InRelease The following signatures were invalid: BADSIG 0E98404D386FA1D9 Debian Archive Automatic Signing Key (11/bullseye) Reading package lists... Done W: 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 unstable InRelease: The following signatures were invalid: BADSIG 0E98404D386FA1D9 Debian Archive Automatic Signing Key (11/bullseye) W: Failed to fetch http://deb.debian.org/debian/dists/unstable/InRelease The following signatures were invalid: BADSIG 0E98404D386FA1D9 Debian Archive Automatic Signing Key (11/bullseye) W: Some index files failed to download. They have been ignored, or old ones used instead. --- OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Archive signature for sid broken?
Hello Jérémy, On 25/06/2024 13:00, Jérémy Lal wrote: Le mar. 25 juin 2024 à 10:11, Roland Clobus <mailto:rclo...@rclobus.nl>> a écrit : Hello developers, is the signature for sid broken? When I do 'apt-get update', it complains about an invalid key, but that key mentions bullseye, not sid. A similar error shows for 'debootstrap sid sid' If you use a apt-cacher-ng, it's https://bugs.debian.org/1003865 <https://bugs.debian.org/1003865> Thanks. I'm indeed using apt-cacher-ng, but I think I tried to run it without the proxy as well, but anyway... it works now. With kind regards, Roland -- For the record: I've done many things: * systemctl restart apt-cacher-ng.service * rm -fr /var/lib/apt/lists;mkdir -p var/lib/apt/lists/partial * I've removed from ../debrep/dists/sid the InRelease* and Release* files
Re: How to create a custom Debian ISO
+debian-live Hello Aditya, On 11/05/2024 10:21, Aditya Garg wrote: I wanted to create a custom ISO of Debian, with the following customisations: 1. I want to add a custom kernel that supports my Hardware. 2. I want to add my own Apt repo which hosts various software packages to support my hardware. I am not able to get any good documentation for the same. Please help. Let me chime in on this thread as well. I had a quick peek at the scripts you use [1]. It appears to me that you want to create a custom Debian Live ISO (not a netinst image). If so, you can take a look at live-build, which is used for the Debian live images. Steps describing how to build a live ISO image are at [2] and a generic manual for live-build is at [3]. You can then build an ISO image from their packages, without the need for repacking (and automagically all checksums will match) With kind regards, Roland Clobus Co-maintainer of live-build [1] https://github.com/t2linux/T2-Ubuntu/tree/LTS [2] https://wiki.debian.org/ReproducibleInstalls/LiveImages [3] https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Embedded buildpath via rpath using cmake
On 04/02/2022 11:58, Simon McVittie wrote: For packages where the RPATH or RUNPATH is temporarily set during build (to be able to run unit tests without setting LD_LIBRARY_PATH) but then removed before installation with `chrpath -d` or equivalent code in CMake, I don't think this is going to be detectable statically, because the only traces left in the final binary are: - the build-ID will be different, because the RPATH/RUNPATH was part of the data that gets hashed to create the build-ID - if the length of the build directory changes, then the block of zero bytes that previously contained the RPATH/RUNPATH (before it was overwritten) will have a different length I've written a detection for this build-ID mismatch in diffoscope some time ago. [1] It does not require two builds to detect a mismatched NT_GNU_BUILD_ID, so perhaps it make sense to migrate this code to lintian (in addition to the already mentioned 'custom-library-search-path'. [2] With kind regards, Roland Clobus [1] https://sources.debian.org/src/diffoscope/202/diffoscope/comparators/elf.py/?hl=646#L646 [2] https://lintian.debian.org/tags/custom-library-search-path OpenPGP_signature Description: OpenPGP digital signature
'The' timestamp of a snapshot of deb.debian.org
Hello Debian developers, I'm looking for 'the' timestamp of the Debian Archive, which will allow me to virtually travel through time to re-generate a specific state of Debian. I've looked at the following places: * http://ftp.debian.org/debian/dists/bullseye/InRelease File timestamp: 2022-09-10 10:27 Content: Sat, 10 Sep 2022 10:18:01 UTC * https://deb.debian.org/debian/dists/bookworm/InRelease File timestamp: 2022-09-18 02:14 Content: Sun, 18 Sep 2022 02:12:23 UTC * https://deb.debian.org/debian/dists/sid/InRelease File timestamp: 2022-09-18 02:14 Content: Sun, 18 Sep 2022 02:12:23 UTC * https://deb.debian.org/debian/dists/sid/Release File timestamp: 2022-09-18 02:13 Content: Sun, 18 Sep 2022 02:12:23 UTC * https://deb.debian.org/debian/project/trace/ftp-master.debian.org File timestamp: 2022-09-18 08:22 Content: Sun Sep 18 02:23:16 UTC 2022 * https://snapshot.debian.org/archive/debian/20220918T030507Z/dists/sid/InRelease URL timestamp: 2022-09-18T03:05:07Z File timestamp: 2016-05-18 23:01:23 symlinked to 2022-09-18 03:05:07 Content: Sun, 18 Sep 2022 02:12:23 UTC * https://snapshot.debian.org/archive/debian/20220918T030507Z/project/trace/ftp-master.debian.org URL timestamp: 2022-09-18T03:05:07Z File timestamp: 2022-09-18 03:05:07 Content: Sun Sep 18 02:23:16 UTC 2022 * Did I miss another file? All of these timestamps (for sid) are close to each other, but not identical. I would guess that the earliest timestamp is the 'real' timestamp, but it is accessible (on snapshot.d.o) only with a later timestamp. Is there a mechanism that prevents additional updates from being (partly) included while the dak synchronisation takes place? With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: 'The' timestamp of a snapshot of deb.debian.org
Hello all, Thank you all for your replies so far. On 19/09/2022 16:41, Mattia Rizzolo wrote: On Sun, Sep 18, 2022 at 10:58:37AM +0200, Roland Clobus wrote: All of these timestamps (for sid) are close to each other, but not identical. I would guess that the earliest timestamp is the 'real' timestamp, but it is accessible (on snapshot.d.o) only with a later timestamp. Consider that the archive "freezes" when it starts working on an update. Once it finishes its job it generates the Release files, and puts the current timestamp *inside* the file. But then that file gets copied around, signed, etc and that will change the timestamp. So if the archive is frozen when it starts to work on an update, that moment sounds to me as 'the' timestamp of the archive. Change Request: Could that timestamp be preserved and used for the timestamp inside the (In)Release file, instead of using 'now' (which is slightly later) when generating the (In)Release file? Also, for example, I just spotted a line on IRC saying that this time around copying the archive from the live one to archive.debian.org also reset the mtimes... In the live-build scripts, I reset the mtime of such generated files to have them match their content. So I really wouldn't trust mtimes in any way, only what's inside the Release file. Ack. What's in the trace file is IIRC the time when the archive kicks the mirrors off, which also happens after the generation of the indexes, and really has no business in this discussion as it's only a tool mirrors use to coordinate and see if they are too much out of sync. The trace file is currently used in the live-build scripts, but I'll change that to use (In)Release instead. As you noticed snapshots indexes by time of the archive run, which is… honestly I don't particularly consider it a good idea myself but that's how the design decision went I guess. The timestamps of snapshot.d.o are the only timestamps that I currently know that allow me to re-generate older images. Change Request: Could the use the timestamp from (In)Release instead of 'now' as well? As to the origin of my question: The snapshot-mirror has been offline for a while, and I've used deb.debian.org to generate my test images (for the reproducible live-build-based live-ISO images). I've compared the timestamps of the InRelease file at deb.d.o with the timestamp in the URL available on snapshot.d.o and I've noticed a difference. That means that all images that I've generated using deb.d.o cannot be verified at any later moment than within the same dak-round (which last for 6 hours). Now that the snapshot-mirror is online again, I'll use that timestamp again, and thus I'll be able to generate the same image from any required timestamp. So effectively 'the' timestamp is found in the URL of snapshot.d.o, but I would like to have that one identical to the timestamp of InRelease. With kind regards, Roland Clobus PS: Regarding these change requests: I could write some patches, but I'm still busy getting the reproducible live-images onto the automated testing platform and after confirmation of their proper functioning on the official Debian download pages (so it will take some time, before I can work on that. If anyone would be faster than I would be: thanks in advance) OpenPGP_signature Description: OpenPGP digital signature
Starting the weekly live images building again
Hello lists, It is now at least a year after the weekly live images have not been generated and distributed from official Debian hardware [1]. However, in the mean time a lot has happened, and a lot has not (yet) happened. First: what has happened: * Live-images are generated on a regular schedule by Jenkins [2] (daily for Sid, weekly for Bookworm, monthly for Bullseye) * These images are based on the tool 'live-build', as was the case until Jessie * The live-build tool has seen maintenance and works well * The images are verified to be reproducible [3] * Only after the verification passes, the images are pushed onto openQA [4] * The images are verified to boot on BIOS, non-secure UEFI and secure-boot UEFI for both CD-ROM and USB devices (a 3x2 matrix test) * All regular desktop environments (GNOME, KDE, XFCE, LXQT, LXDE, Mate, Cinnamon) (for amd64) are verified to be bootable and to have a working Firefox and CUPS PDF-printing * For some desktop environments the default applications are tested whether they start or not * All boot menu entries are checked, to see whether they are able to proceed to the first stable screen * The d-i installer is run and the installed hard disk image is booted * Overall: The live images are in good shape Thankfully, I had lots of help for the bottlenecks that I encountered. Second: what has not happened (yet): * The images are not generated and distributed by official Debian hardware (by adjusting the existing scripts in the live-setup repo) * The boot menu in the live-build based images has not been adjusted to look more like the live-wrapper based images (e.g. the localisation submenu with the lots of languages) * The Calamares installer is not tested automatically by openQA * The firmware repository is not included * The content of the live images is not totally reviewed (but there are also some rough edges on the live-wrapper based images) * The d-i installer cannot be run totally off-line yet (which the live-wrapper image is capable of) I'm currently quite happy with the state of the automated testing, which I see as a major precondition before publishing the images. Third: what needs to happen (soon): * Given that the release of Bookworm is getting closer and closer, the next step will be to start generating the images officially again (since the current images are not on servers that are designed for such high traffic) * More maintainers/testers are needed, supporting so many variants needs to be done by a team * The news that Debian will have/does have live images again needs to be spread With kind regards, Roland Clobus [1] https://lists.debian.org/debian-cd/2021/10/msg8.html [2] https://jenkins.debian.net/view/live/ [3] https://hamburg-2022.mini.debconf.org/talks/11-reproducible-builds-as-applied-to-non-compiler-output/ [4] https://openqa.debian.net/group_overview/14 OpenPGP_signature Description: OpenPGP digital signature
Re: [DEVEL] Enable support for Renesas platform (section: live images)
On 19/11/2022 09:56, Paul Wise wrote: On Fri, 2022-11-18 at 15:20 +0700, Huỳnh Thành Hưng wrote: I’m from Renesas Electronics Corporation, My group is developing to support running Debian OS on our devices, also for getting ARM System Ready IR certificate. ... Can you help me to enable those configs, also support the official release version of Debian Live Installer ISO which support Renesas platform? Debian does not yet support the ARM architecture at all with our live images, please contact the Debian Live Team about that. Currently the live images for the future Debian bookworm release are not being built, but that may change before the final release. https://wiki.debian.org/Teams/Live I posted a summary about the current status of the live images a few minutes ago: https://lists.debian.org/debian-devel/2022/11/msg00221.html Given that Debian Stable (hence its name) is stable and will receive bug fixes, but not typically additional features, I would recommend you to target Bookworm (the next release). If you want to create live images, I recommend you to take a look at the online manual at https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html The scripts can be highly customised, e.g. to contain custom kernels (see 8.2.10) With kind regards, Roland Clobus OpenPGP_signature Description: OpenPGP digital signature
Re: Starting the weekly live images for Bookworm building again
Hello lists (sorry for cross-posting to so many lists), This is a follow-up of my mail from 2022-11-21 [A1]. I've made progress in the last two months, but would like to have some merge requests approved, to get more traction and to allow others to jump aboard and make the live images for Bookworm possible. As you can see, this affects many teams: * live-setup: a MR to generate all live images for Bookworm [A2] * localechooser: A minor fix [A3] * live-installer: A better user experience after the installer is finished [A4] * live-build: Various installer improvements, including off-line installation [A5] With kind regards, Roland Clobus [A1] https://lists.debian.org/debian-devel/2022/11/msg00221.html [A2] https://salsa.debian.org/images-team/live-setup/-/merge_requests/2 [A3] https://salsa.debian.org/installer-team/localechooser/-/merge_requests/7 [A4] https://salsa.debian.org/installer-team/live-installer/-/merge_requests/3 [A5] https://salsa.debian.org/live-team/live-build/-/merge_requests/297 OpenPGP_signature Description: OpenPGP digital signature
Re: Starting the weekly live images for Bookworm building again
My last cross-post. Follow-up please on debian-live Hello Steve and lists, On 19/03/2023 16:13, Steve McIntyre wrote: So, after some delay from me and some further delays from various Debian machines committing suicide, I've got bookworm live builds running again. \o/ Thanks for merging the changes. I've taken Roland's updated patches and tweaked a little more in the setup.git and live-setup.git repos, and we now have live builds integrated. Changes I've added: * turned on source tarball generation using LB_SOURCE=true, and disable the external source build that we did for the older live-wrapper builds That's a good way to enable the source tarballs. I haven't looked at that part of live-build for a while, so the source tarball might need some love. * when building on casulana, warn about archive updates rather than restarting builds * don't attempt to build i386 live images any more, they're not useful * tweaked logging And an additional change to use the installer images from the repository instead of rebuilding them from git [1]. That change is now causing the missing kernel modules for d-i. I've rebuilding the installer images from git, after the discussion in #1006800 [2], to save the d-i team from doing an upload for every single kernel bump, while bookworm was not yet in freeze. (That is a recurring issue for every release [3]) So, *builds* work fine but I've not *yet* tested actually booting/using one of these images in any way. I've just triggered a full build of "testing" live images now, please help test if you can once they're in place at [2] in a couple of hours from now. > [2] https://get.debian.org/images/weekly-live-builds/ In openQA [4] the live images that were generated by Jenkins [5] have been tested for a while now. Now we can switch and use these new images instead of the images from Jenkins. Since both images are generated by the same script, I wouldn't expect many issues. I don't yet know how close we are to having full non-free-firmware integration with the live images; I expect there might be some more work needed there yet, but I'd love to be proven wrong. :-) This weekend I've written the missing parts, non-free-firmware images are now generated by default by live-build, and the ISO images are still bit-for-bit reproducible. With kind regards, Roland Clobus [1] 3cef309a5cfa4758ba33480b170734133b7104b5 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006800 [3] #986506, https://lists.debian.org/debian-boot/2021/03/msg00166.html [4] https://openqa.debian.net/group_overview/14 [5] https://jenkins.debian.net/view/live/ OpenPGP_signature Description: OpenPGP digital signature
Re: Should l10n packages be Recommends or Suggests?
On 05/12/2024 16:43, Theodore Ts'o wrote: Currently e2fsprogs recommends e2fsprogs-l10n. In Debian Policy, it states: This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. It seems to me that po translation files are borderline considering it a "strong dependency". Is it really "the most unusual installations"? I wouldn't think so, but I acknowledge my privilege coming from a native English speaker. Given recent discussions about depends vs recommends vs suggests inflation, I'm thinking about down-prioritizing e2fsprogs-l10n from recommends to suggests. Thoughts, comments? How about adding the translations to the main package e2fsprogs, and let the package 'localepurge' remove them? For people who care about installed size, that package helps to remove undesired translation files. (Although all translations will then be downloaded while installing e2fsprogs) With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Theme for Trixie: Ceratopsian in the installer
Hello Debian-cd, Now that the theme for Trixie is known: https://bits.debian.org/2024/12/ceratopsian-will-be-the-default-theme-for-debian-13.html I've been synchronising the images for live-build. And some questions arose: * Does the Ceratopsian theme also require a new plymouth screen? * I'm missing the '13' or any other version indication in the GRUB screen. Could/Should that be added? The alpha1 image uses a text element to indicate the version. Live-build could do that too, instead of a number in the image. * The d-i alpha1 image uses the old GRUB image (but modified to remove the '12'), will that be updated for alphaX? You can see a GNOME live image booting at: isolinux boot: https://openqa.debian.net/tests/344974/video?filename=video.ogv GRUB boot: https://openqa.debian.net/tests/345084/video?filename=video.ogv The d-i alpha1 image uses a different GRUB image: https://openqa.debian.net/tests/340567/video?filename=video.ogv With kind regards, Roland Clobus OpenPGP_signature.asc Description: OpenPGP digital signature
Building live images without non-free-firmware (Was: Re: Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion)
Hello Simon, On 10/03/2025 10:57, Simon Josefsson wrote: Philip Hands writes: Simon Josefsson writes: While this may be fine to you it is not fine to me, and it is fine to disagree on that. If there were a method of building images that did not touch the non-free components, I presume that would satisfy you. That sounds good! ... Thanks Phil for adding this suggestion to the discussion. I'm one of the active developers of the tool 'live-build', which is used to generate the live images. I can help you that get started. There is a single script in the repository that is used to build all 9 ISO images for amd64 [1] If you remove the access to 'non-free-firmware' (lines 237-244), you will generate ISO files where the non-free firmware has not been included at all. I guess that this will fulfil your requirement of having a live image that hasn't seen any non-free firmware. As noted elsewhere in this long thread on debian-devel (I was offline during the weekend IRL), the generation of the live images themselves is not a lot of effort. The generation is be fully automated and additional images require just a few minutes to set it up. However, it is the quality assurance and the user support part that is most of the work. We have nearly reached the level of quality assurance, that it would be possible to reverse the order the images are handled. At this moment the images are 1) generated, 2) published, 3) tested. In some (nearish) future, the order would be 1) generated, 2) tested, 3) published. Even though openQA [2] helps in automating some tests, there is a lot of test coverage missing (and computing power as well). Before the coverage has been extended, I would really be hesitant to generate another set of images for download, as they would have no guarantee of correct functionality. But then, as noted in the blog post by Thomas Lange from 2025-02-19 [3], Debian currently releases an enormous amount of ISO images for download, and that is rather confusing for many users. To improve the user experience, work is also under way [4]. As noted in the thread before, the largest bottleneck in providing the non-free-firmware-less images is manpower. Volunteers are welcome, but please use the 'debian-live' mailing list for that. With kind regards, Roland Clobus [1] https://salsa.debian.org/live-team/live-build/-/blob/master/test/rebuild.sh?ref_type=heads [2] https://openqa.debian.net [3] https://blog.fai-project.org/posts/cdimages-maze/ [4] https://dev.to/0xfaker/re-styling-debians-download-page-3lmm OpenPGP_signature.asc Description: OpenPGP digital signature
