Re: Progress on t64 transition -> building the installer in sid
Philip Hands (2024-04-15): > On the other hand, it's taken over a month so far. Rather than living in > hope for another month, I thought it might be worth removing this as a > blocker (I've had to tell a couple of people that they'll need to wait > before they can do their salsa-CI tests :-/ ) I'm not suggesting living in hope, I'm suggesting to get the ball rolling. The commit lists #1066070, which was a duplicate (because -ECOFFEE) of #1066069, which got fixed rather quickly. So what we would need are rebuilds of the reverse dependencies (which I haven't checked right now would be sufficient to get them fixed), which one could request on the release team side. Regarding #1066071, that needs a fix in the package first. Looking at tracker, it's not migrating any time soon as far as I can see (due to regressions on 32-bit arms), and I'm not sure how fixing the udeb would interfere there. So one could start with an upload. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Progress on t64 transition -> building the installer in sid
Philip Hands (2024-04-14): > I realised that there might be a way to kludge around the current D-I > build failures, so I gave it a try and it seems to work: > > https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/45 > > That creates dummy udebs with the missing names, where each depends upon > the matching udeb that actually exists. Dropping them into localudebs. > > That's enough to get D-I to build in salsa pipelines, such that one gets > a mini-ISO to test. > > It may be enough to get D-I and debian-cd back to the point where we can > produce daily images etc. but I'm not completely sure about that bit > (perhaps the use of localudebs is enough to make debian-cd grumpy?) > > Anyway, it's currently broken anyway, so perhaps it's worth giving it a > go, and then reverting the commit once the proper fixes become > available. > > What do you think? I'd rather see actual progress in getting packages fixed. So far I haven't been chasing because I thought people would be busy rebuilding the world, in the right order, and patching things along, but I had hoped to get *some* kind of feedback after filing those bug reports and putting people driving changes in the loop. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Re-planning for 12.6
Hi, Adam D. Barratt (2024-04-01): > As we had to postpone 12.6, let's look at alternative dates. I should be able to make anything work. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#902668: Draft for rewrite of https://www.debian.org/CD/verify
Hi, Tassia Camoes Araujo (2024-03-25): > I've reviewed the proposed patch, and I think it should be applied as > soon as possible. > > It seems Laura was waiting for a final review before applying this patch > (long overdue!), which IMHO would bring much more clarity to the image > verification process (usually, a big struggle to new users). > > We should make a decision about the long key IDs request (points 1 and 2 > from #851541), and once those changes go online, I think both bugs could > be closed (#902668 and #851541). > > Thanks for all who have invested energy to clarify this process, and I > hope we can benefit from your work very soon! > > Cheers, > > Tassia. Cc += debian-cd@ for information. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: problems with amd64 testing images
Hi, Jogi Hofmüller (2024-03-24): > I just failed to install debian testing using the latest > debian-testing-amd64-netinst.iso. for amd64 this has two problems: > > 1) it misses at least libaio.so so pvcreate does not run and I cannot set up > the disk as planned > 2) it is more than 2 weeks old (2024-03-09) and there are no newer images > for amd64 Some pointers: - https://lists.debian.org/debian-devel-announce/2024/02/msg5.html - https://lists.debian.org/debian-cd/2024/03/msg00013.html > Please CC when replying since I am not on the list Done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)
Hi, Cyril Brulebois (2024-03-21): > I'm a bit conflicted about what to do here. At the moment, libaio1-udeb > is the only udeb with t64 (at least according to the output of > `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies > would be sufficient (and might happen at some point anyway). > > For the sake of consistency, I think I'm tempted to suggest a revert of > the udeb part (it wasn't renamed so there's a contents vs. package name > mismatch anyway). Checking libaio's changelog (last mail got sent a little too fast, sorry) is enlightening: this library required special attention and wasn't just about getting rebuilt with a different package name. https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/ Guillem is absolutely right regarding avoiding the roundtrip to NEW and d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd) would have been welcome. It'd be nice if the Debian LVM Team (hello waldi) could pick it up from here and see whether requesting a binNMU is what makes most sense here, or if there other plans on the t64 front. A local, cowbuilder-powered rebuild of unstable's lvm2 results in udebs referencing libaio.so.1t64 as expected (i.e. libaio1t64's shlibs). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Progress on t64 transition -> building the installer in sid
Hi, Roland Clobus (2024-03-21): > On 21/03/2024 15:58, Cyril Brulebois wrote: […] > The diagram shows nicely that the t64-transition is affecting the > installer, with currently 1 major bottleneck, libpng16-16t64-udeb: > https://d-i.debian.org/dose/graph-unstable-amd64.png Glad you like it, those have been quite useful a very long while back; it's been a while since the last time we had such a huge archive-wide transition… > > Do you have more details? That thing doesn't exist, but libaio.so.1 > > does (different suffix order). > > My bad, I reversed the order when typing. No worries, thanks for confirming. > I've done some basic triaging in the openQA comment: > https://openqa.debian.net/tests/244163#comments > > The installer fails here: > https://openqa.debian.net/tests/244163#step/grub/3 > > Some details are here (/var/log/syslog): > https://openqa.debian.net/tests/244163#step/grub/35 Thanks, that's pvs from lvm2-udeb; for some reason libaio1-udeb got t64-transitioned, and without an lvm2 rebuild, its tools will want the non-t64 version. I'm a bit conflicted about what to do here. At the moment, libaio1-udeb is the only udeb with t64 (at least according to the output of `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies would be sufficient (and might happen at some point anyway). For the sake of consistency, I think I'm tempted to suggest a revert of the udeb part (it wasn't renamed so there's a contents vs. package name mismatch anyway). > > In any case, there are no reasons to complicate the t64 transition with > > transitioning udebs, so I wouldn't be surprised if “images” (whatever > > they are) built against old udebs would break if newer udebs are pulled > > from the network. > > The images I've spoken of are the daily-built Debian live ISO-images based > on sid. They are built by Jenkins https://jenkins.debian.net/view/live/ OK, but what I meant to say is that the failure mode I was alluding to isn't specific to d-i daily builds, or debian-cd builds, or live builds; that's something that can happen, and might do until things stabilize. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Progress on t64 transition -> building the installer in sid
Roland Clobus (2024-03-19): > For the other images, the installer is currently failing to build from > source, as some dependencies (in the udebs) are still missing (due to > the t64-transition). > > The latest message (from my local build_cdrom_gtk.log) is: > > The following packages have unmet dependencies: > libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not > installable > libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not > installable > libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it > is not installable > libinput10-udeb : Depends: libmtdev1t64 but it is not installable https://lists.debian.org/debian-boot/2024/03/msg00102.html > On openQA I've additionally seen that for Debian Edu, the installer fails > with the message that libaio.1.so is missing, so some udeb is probably also > requiring an update. Do you have more details? That thing doesn't exist, but libaio.so.1 does (different suffix order). In any case, there are no reasons to complicate the t64 transition with transitioning udebs, so I wouldn't be surprised if “images” (whatever they are) built against old udebs would break if newer udebs are pulled from the network. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning for 12.6
Jonathan Wiltshire (2024-02-12): > 12.6 should be around 10th April, so please indicate availability for: > > 6 April > 13 April > 20 April Any of those should work. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning for 12.5/11.9
Steve McIntyre (2023-12-26): > Any of those *should* be OK for me. Ditto. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning for 12.3
Jonathan Wiltshire (2023-10-07): > How about: > 4th December (better for cadence) > 11th December (more likely suitable in practice) The later the better. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Daily d-i images for i386 not being built?
Holger Wansing (2023-08-27): > So no more netinst images, And any other sections about CD, DVD, etc. must go. > but the "Other images" section will stay (netboot images, hd-media > ...)? Right, only that one stays. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Daily d-i images for i386 not being built?
Holger Wansing (2023-08-27): > Am 27. August 2023 10:12:09 MESZ schrieb Holger Wansing > : > >Hi, > > > >Am 27. August 2023 08:48:20 MESZ schrieb Holger Wansing > >: > >Ah, sorry. > >By accident I found a bug against release-notes, which documents that > >i386 d-i images will be dropped for trixie. > ><https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036358> > > > >So, sorry for the noise. > > > >OTOH I would then remove the i386 link from > ><https://www.debian.org/devel/debian-installer/index.en.html> > >now? > > I searched for a confirmation, that this was dropped from debian-cd, > but found nothing. > > Should I just remove the link nevertheless? d-i daily builds will keep i386, so don't drop that link. Links to debian-cd locations can go away. The lack of symmetry might require tweaking some wml logic/definitions. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.8/12.2 planning
Jonathan Wiltshire (2023-06-28): > The proper cadence for 11.8 and 12.2 is the weekend of 30th September > 2023. Please indicate your availability for: > > 23 Sep > 30 Sep (preferred) > 7 Oct I should be able to make any of those work for the installer team, and optionally for the images team. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 12.1 planning
Hi, Jonathan Wiltshire (2023-06-19): > The promised 4-6 weeks following release for 12.1 looks like: > > 8th July (4) > 15th July (5) > 22nd July (6) > > The first of them would combine with a very stretched 11.8; SRM might > prefer to get 11.8 done earlier and leave more time for 12.1 to mature. I can push the d-i buttons for any dates; I think I'd rather avoid having to do debian-cd bits if others are available (it'd be a chance to finalize my streamlining work, but the past few months have been absolutely exhausting; I'd like to take a breather, or ten). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.8 planning
Hi, Jonathan Wiltshire (2023-06-19): > I'm sending this separately to a similar mail for 12.1. That's because the > timings are far enough out that they would make sense on separate weekends, > but they could also be stretched[1] and combined. > > Two months from 29th April is around the 1st July, so I propose: > > 1st July > 8th July > 15th July at a push I can push the d-i buttons for any dates; I think I'd rather avoid having to do debian-cd bits if others are available (it'd be a chance to finalize my streamlining work, but the past few months have been absolutely exhausting; I'd like to take a breather, or ten). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1038440: debian-cd: debian-12.0.0-amd64-netinst.iso is too big for a CD
Claude Heiland-Allen (2023-06-18): > I'm not sure if I will actually need a CD, > (refurbishing someone's old laptop, > I don't know yet if it will boot from USB stick or not), > but if it can only boot from CD I will have to > install Bullseye (whose netinst does fit on a CD) > and then upgrade, which is not ideal. https://salsa.debian.org/installer-team/debian-installer/-/issues/3 has: > Revisit firmware packages included in the netinst (amd64 is 738M for > 12.0.0): at least nvidia stuff wasn't planned in the beginning, and > could be removed. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?
Control: tag -1 patch pending Cyril Brulebois (2023-05-27): > For the record, those archives end up being published in locations like > the following, and I definitely expected those to match the firmware > packages getting shipped into the images, not be some kind of snapshot of > what's in unstable at the time the release is built! > > https://cdimage.debian.org/cdimage/firmware/bookworm/bookworm_di_rc3/ > > We should definitely clarify the situation, and get to the bottom of that > double firmware build. > > From the log lines quoted above, if both bookworm and sid builds end up > shipping files in the same destination directory, the last build wins and > overrides the first one entirely? I'm considering the following change for the upcoming (pseudo) RC 5 release: https://salsa.debian.org/images-team/setup/-/commit/9a77631 This means nothing changes for weekly builds, which are detected as being built with DEBVERSION set to “testing” (please note that I didn't investigate what happens to firmware directories in this case). Meanwhile, actual releases get that sid job skipped (since the release specific config file, e.g. CONF.sh.bookworm_di_rc4, sets DEBVERSION to “bookworm-DI-rc4” instead of sticking to the default “testing” value). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Upcoming D-I Bookworm RC 4 and pseudo-RC 5
Hi, Here's a quick update about my current plans regarding the installer and regarding debian-cd dry runs. (Trimming recipients; also, I'm using 12.0.0 below as I'm referring to the version identifier on the debian-cd side, but that's hopefully synonymous with Debian 12.0, i.e. the initial Bookworm release.) Cyril Brulebois (2023-05-24): > I might pick a last minute tasksel change as well (for lxqt); I think > it would help, could break, but that would be trivially revertable > (and there would be room to do so, see below). I did that, didn't hear bad things about it, be it from users or maintainers. > Checked with Salvatore: still no upload planned before the release. I've asked Salvatore to update me on this one, but I haven't heard of any changes in that area at the moment. > I think I'll go for this one, aiming for May 25 or May 26 unless some > issues pop up. Details disagreed so that ended up being May 27 instead, but close enough. > We know we have at least the apt vs. adduser issue that's going to get > resolved, and I'd prefer not to wait for it, and also not to rush the > update into testing… That migrated after the release, and will be part of pseudo-RC 5 and more importantly 12.0.0. > Also, we might have other packages that directly (because they produce > udebs) or indirectly (because they're installed on every system, like > apt) affect the installer or the installation process… migrate to > testing later on. Last packages that migrated (that I know of) are openssl (CVE fixes) and libselinux (+b6 to minimize ESO). I'd be happy to be kept explicitly in the loop for any further updates to udeb-producing packages (it appears unblock-udeb does the job, including for binNMUs…), or things that the release team would identify as being part of a standard installation, so that we keep as many eyes open as possible… > Let's consider a last debian-installer(-netboot-images) upload once > Bookworm is definitely frozen, maybe a few days before the release to > minimize the chances of having to consider a last-minute critical > bugfix. Once it's in testing, we could even build images like we would > for “D-I Bookworm RC 5”, just to be on the extra safe side. Those could > be fetched by testers, but wouldn't be signed or announced (keeping them > in the “usual dot directory”, deleting them a few days later). That > would give us some extra peace of mind for the actual 12.0.0 images > build that will happen on release day. I plan to work on that mid-week, sometime on Wednesday (ideally, unless we know more packages need migrating…) or Thursday (as a fallback). I'll check with other debian-cd members, but I might even try and see how a full build would work, so that we have some kind of advance knowledge regarding the following week-end. At the moment I've spotted three uploads: - apt-setup (1:0.183), for ports architectures. - preseed (1.118), for Hurd, even if the changelog is not quite verbose about that part… - vte2.91 (0.70.5-1): new upstream (bugfix) release with no particular bugfixes identified. Unless specifically requested, I don't plan on including the first two before Bookworm because we don't need it for release architectures. I /think/ hurd-i386 gets somewhat released from unstable, so that shouldn't matter… not sure about ports architectures. Those /could/ be considered but truth be told, my default setting is: only change what is absolutely required before Bookworm. vte2.19 seems quite vague, and ignoring it entirely should be fine. Since there was good progress on the arm64 console thing (#1036952), and considering the current results of the investigation as to where vt102 comes from, and why arm64 isn't quite the deciding factor (a busybox limitation instead), I'd be happy to consider getting an updated rootskel for migration before pseudo-RC 5 and 12.0.0. Such an upload would need to happen quickly though… (ema bcc'd, as possible uploader, no obligations though!). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1036828: debian-cd: wrong firmware archives built and published for D-I releases?
Package: debian-cd Severity: serious Hi, During a previous release, I spotted we had two firmware builds, but let the topic go once I was reassured that was to be expected. For RC 4: 1/43: Starting firmware_bookworm build at 2023-05-27:09:03:53 […] 9/43: Starting firmware_sid build at 2023-05-27:09:04:01 […] firmware_bookworm finished successfully (started at 2023-05-27:09:03:53, ended at 2023-05-27:09:06:31, took 0h02m38s) […] firmware_sid finished successfully (started at 2023-05-27:09:04:01, ended at 2023-05-27:09:07:07, took 0h03m06s) Now, waiting to see if someone would join the testing efforts, I diffed firmware lists between rc3 and rc4, and spotted those differences: -./firmware-sof-signed_2.2.4-1_all.deb -./intel-microcode_3.20230214.1_amd64.deb -./intel-microcode_3.20230214.1_i386.deb +./firmware-sof-signed_2.2.5-1_all.deb +./intel-microcode_3.20230512.1_amd64.deb +./intel-microcode_3.20230512.1_i386.deb The intel-microcode bits are OK: intel-microcode | 3.20230512.1 | testing/non-free-firmware | source, amd64, i386 intel-microcode | 3.20230512.1 | unstable/non-free-firmware | source, amd64, i386 The firmware-sof-signed, not so much: firmware-sof-signed | 2.2.4-1 | testing/non-free-firmware | all firmware-sof-signed | 2.2.5-1 | unstable/non-free-firmware | all It's a relatively new upload, and it's of course blocked at the moment: [2023-05-15] Accepted firmware-sof 2.2.5-1 (all source) into unstable (Mark Pearson) (signed by: Vincent Bernat) For the record, those archives end up being published in locations like the following, and I definitely expected those to match the firmware packages getting shipped into the images, not be some kind of snapshot of what's in unstable at the time the release is built! https://cdimage.debian.org/cdimage/firmware/bookworm/bookworm_di_rc3/ We should definitely clarify the situation, and get to the bottom of that double firmware build. From the log lines quoted above, if both bookworm and sid builds end up shipping files in the same destination directory, the last build wins and overrides the first one entirely? See also the “rsync noise” that seemed somewhat OK to ignore. Not sure whether that's directly related though… ISTR it was probably about some timestamp discrepancy due to the underlying filesystem. For RC 4: file has vanished: "/home/debian-cd/publish/.bookworm_di_rc4/firmware/firmware.zip" rsync: stat "/dsa/cdimage/.incoming/.bookworm_di_rc4/firmware/.firmware.tar.gz.VQGfUC" failed: No such file or directory (2) rsync: rename "/dsa/cdimage/.incoming/.bookworm_di_rc4/firmware/.firmware.tar.gz.VQGfUC" -> "firmware.tar.gz": No such file or directory (2) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Re: Daily build status update
Hi Ondrej, Ondrej K. (2023-05-26): > as Debian Bookworm is heading to its final stage, I like to test daily > builds from https://cdimage.debian.org/cdimage/daily-builds/ time to > time. Those might make sense when there's a long period before the first Alpha release (at the beginning of a development cycle), or between two releases (Alpha or RC). With the release getting closer and closer, testing actual D-I RCs is more valuable to us (at least with my D-I release manager hat). FWIW: RC 4 should happen shortly. https://lists.debian.org/debian-release/2023/05/msg01075.html > But recently I found out that the "Daily build status" on the page > says - Status last updated: 29th January 2016. > > Could you check it out please and tell me whether you are aware of it? That seems to be the last update of the header, and that looks fine to me. If there were some big bad bugs, we would mention them, and bump the date. Then remove them as they get fixed, also bumping the date. If anything, the daily-trace file is outdated and should go away (and/or the machinery being it should get fixed so that it gets refreshed again). I'll leave that to another debian-cd person to figure out. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Upcoming D-I Bookworm RC 4 and pseudo-RC 5
Hi all, Cyril Brulebois (2023-05-21): > Dates that have been announced[1] so far: > - 2023-05-24: full freeze [x] ← You are here! > - 2023-05-28: last moment to file unblock requests > - 2023-06-03: bookworm totally frozen >(per “last week prior to the release”) > > 1. https://lists.debian.org/debian-devel-announce/2023/04/msg7.html > > On the d-i side, we'll have a round of translation updates, along > with some last tweaks, before RC 4. We should be all done in a few hours. I might pick a last minute tasksel change as well (for lxqt); I think it would help, could break, but that would be trivially revertable (and there would be room to do so, see below). > As far as I understand, at least at the moment, we aren't expecting a > new linux upload before the release. But if the need arises, we should > be able to deal with it. Checked with Salvatore: still no upload planned before the release. > I'm not sure what the best timeline would be for RC 4. Let's consider > two options: > - [Soon] Example: May 25. > - [Later] Window: May 28 - June 3. No preferences have been expressed by the release team during today's meeting. > In the first case, we would have a little more time to sort incoming > installation reports, and to react if needed. We might need a final > upload of debian-installer(-netboot-images). I think I'll go for this one, aiming for May 25 or May 26 unless some issues pop up. We know we have at least the apt vs. adduser issue that's going to get resolved, and I'd prefer not to wait for it, and also not to rush the update into testing… Also, we might have other packages that directly (because they produce udebs) or indirectly (because they're installed on every system, like apt) affect the installer or the installation process… migrate to testing later on. Let's consider a last debian-installer(-netboot-images) upload once Bookworm is definitely frozen, maybe a few days before the release to minimize the chances of having to consider a last-minute critical bugfix. Once it's in testing, we could even build images like we would for “D-I Bookworm RC 5”, just to be on the extra safe side. Those could be fetched by testers, but wouldn't be signed or announced (keeping them in the “usual dot directory”, deleting them a few days later). That would give us some extra peace of mind for the actual 12.0.0 images build that will happen on release day. It looks to me this would combine the best of two worlds: - Not wait too much before RC 4, leaving us some more days to deal with incoming reports; - Minimize risks of merging final changes in Bookworm, by having this “canary” RC 5 release. Notes: - This would be different from what we did for Bullseye, where we had an RC 3 built using debian-installer 20210731, which was then reused as is for the 11.0.0 images build. - This would be different from what we did for Buster, where we had an RC 3 built using debian-installer 20190702, which was then reused as is for the 10.0.0 images build. - Given each D-I release is “lighter” than a full release build (be it for an initial release or a point release), it seems to me going for RC 4 plus pseudo-RC 5 is cheap enough to buy us peace of mind than delaying RC 4 until we think (but still aren't sure) nothing is going to change in Bookworm. - Release early, release often! (even if late in the release cycle…) - I'm doing most of the work anyway… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Upcoming D-I Bookworm RC 3 and RC 4
Hi all, Cyril Brulebois (2023-05-06): > I think it'd make sense to have at least 2 releases: > - 1 around mid-May; > - 1 around end of May. > > The first one would bundle a bunch of the fixes or improvements being > worked on these days, making sure everything works as intended. This part has happened as planned. > The second one would be an “everything is frozen, we upload d-i one > last time” release, which could include a few last-minute fixes or > improvements if required or desired. And that part I'd like to plan a little more. > I'm happy to touch base with the release team again when we approach > end of May, to see what would be considered best for the (hopefully) > final d-i upload (and d-i-n-i, at least a dinstall afterward). It > might make sense not to wait too much before doing so, in case we end > up having to fix a package or two, and re-upload… Dates that have been announced[1] so far: - 2023-05-24: full freeze - 2023-05-28: last moment to file unblock requests - 2023-06-03: bookworm totally frozen (per “last week prior to the release”) 1. https://lists.debian.org/debian-devel-announce/2023/04/msg7.html On the d-i side, we'll have a round of translation updates[2], along with some last tweaks, before RC 4. As far as I understand, at least at the moment, we aren't expecting a new linux upload before the release. But if the need arises, we should be able to deal with it. 2. https://lists.debian.org/debian-boot/2023/05/msg00250.html I'm not sure what the best timeline would be for RC 4. Let's consider two options: - After the full freeze is in effect: we would have RC 3 and RC 4 roughly two weeks apart, which matches what I had in mind initially, but we might have a few more changes coming in via late unblock requests, that could impact the installer. Example: May 25. - After a green light from the release team, i.e. once all unblock requests have been considered, and once it's expected there should be no changes in the archive. Window: May 28 - June 3. In the first case, we would have a little more time to sort incoming installation reports, and to react if needed. We might need a final upload of debian-installer(-netboot-images). In the second case, we would have a little less time, but the message in the release announcement could be a clear “there are no more pending changes for bookworm, this is the closest thing to the release, please test extensively” (better wording welcome). We would probably not need a final upload of debian-installer(-netboot-images), with debian-cd picking up the exact same files that were used for RC 4, for the final release. Both options seem equally reasonable to me, please let me know whether you have a preference. I don't need an answer right away, that can be discussed during the upcoming release team meeting. (If we go for “d-i/d-i-n-i are the last packages changing in bookworm”, please keep in mind we need at least 1 britney run and 1 dinstall run between the d-i upload and the d-i-n-i one.) > Regarding the final release, I'm happy to perform a final d-i upload > if some packages needed an update since RC 4… but hopefully the last > build can be reused without any changes. No changes there, I'll be on stand-by for anything d-i related until the (tentative) release date. > Interactions with other teams > = > > [ kibi does dak copy-installer ] That was confirmed to be working fine while preparing RC 3. > [ kibi does debian-cd ] That was also confirmed to be working fine while preparing RC 3. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1036371: debian-installer: Blu-ray double-level iso is too large to burn to DLBD disk
loop += debian-cd Bud Heal (2023-05-20): > Package: debian-installer > Version: 20210731+deb11u8 > Severity: important > Tags: d-i > X-Debbugs-Cc: budheal...@gmail.com > > Dear Maintainer, > >* What led up to the situation? > Since the DLBD .iso install neither sets up sources.list with a mirror to > download from nor requests more disks to complete the set, a test of the > DLBD install when using actual Blu-ray disks were in order. >* What exactly did you do (or not do) that was effective (or > ineffective)? > RC3, packaged at 61-62GB per volume, can not be burned into DLBD media. >* What was the outcome of this action? > The test could not even be started. >* What outcome did you expect instead? > The DLBD volumes should be configured at 48-48.5GB. At 61GB, apt still > asks for new packages in /media/cdrom, which cannot possible be > satisfied. See bug#1035476 - editing sources.list as a workaround is, as > apt reminds each time, insecure. > All the packages d-i needs fit in the 25GB set, if not the 16GB one. > Then, the following volumes allow someone with a slow connection (like > mine) to complete an installation from media - if the volumes fit on the > media. Otherwise, the rest of the volumes are not easy to use as a > complete download of the distribution. > > -- System Information: > Debian Release: (inserted) 12 RC3 -- Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)
Hi, Andrew M.A. Cater (2023-05-19): > I'd honestly suggest *just* publishing DVD1 for i386. > > Netinst requires internet access: DVD1 can be used to install a basic > system without this. Scrap *everything else* for i386 installation media. I'm not sure how dropping one netinst ISO is going to change anything in debian-cd: that's a very fast build, that's a small, single ISO, and not having to download several GBs seems quite appealing to me. Having DVD1 only would really not seem acceptable to me. I'm also very much *not* in favour of dropping images just *days* before the release, without any kind of heads-up. If the point is to limit the amount of testing done before publishing, it would seem acceptable to me to limit i386 testing, and to only be “reacting” to user reports about things that might not be working for them (instead of proactively checking various combinations). Cc-ing debian-boot@ and debian-cd@ for information, seeing such an idea mentioned only on debian-devel@ feels weird. > Update media for i386 - no, really, don't bother. One DVD per point > release and have done with it. The utility for i386 was questioned by > me (amongst others) late in Bookworm planning and it was suggested > that it should be decided for Trixie immediately bookworm is released. No opinion on that. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Upcoming D-I Bookworm RC 3 and RC 4
though; I'm more than happy to be told what is important (so that it can be tracked via the Salsa issue mentioned above, or one of the “point release variations”, see issues 2 and 3). I'm usually sharing progress towards a d-i release on IRC on #debian-boot, before moving to #debian-cd. I know at least Jonathan is present in both channels so we should be good; I'm happy to consider alternatives if needed though. Back to d-i, we have the release announcements going to dda@ and to the website, and I'm autonomous on both counts as usual. For the final release, I'll step back (even if d-i gets a final upload), and let you folks organize the Bookworm announcement. Conclusion == I'm happy to answer any questions you might have, and to amend my plans if you'd like some things to be done differently. Thanks for your time and attention, that's quite a long mail… With the release approaching, I thought it'd make sense to be as explicit as possible to make sure everyone is on the same page. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Labels for the netinst iso images
Hello, Roland Clobus (2023-05-05): > While replying to #1035381, I noticed that the label of the ISO netinst > images is quite different for each of the variants: > > 11-released: Debian 11.7.0 amd64 n [1] > daily: Debian testing amd64 n [2] > RC2: Debian bookworm-DI-rc2 amd64 n [3] > > This complicates the detection in e.g. osinfo-db and other sources for > running virtual images, which 'autodetect' the ISO image type. > > Could/Should the labels be changed to have a more consistent structure? > e.g. Debian 12(.\d+.\d+|rc\d+|daily) amd64 n That doesn't seem appropriate to me. A *D-I* Alpha can be published just a few months after the freeze is first lifted, and that's *definitely* not I would label “Debian n+1 $anything”. Using either testing or its $codename seems far better. (We already have people confuse D-I Bookworm RC n with “Debian has a release candidate”, which isn't something that exists.) That being said, to avoid having to know each codename in advance (even if they tend to be chosen and announced some time in advance), it should be possible to spot official stable releases (AFAICT dot-separate numbers for many releases now, exceptions include 6.0.1a and 6.0.2.1), and d-i dailies/releases with a single pattern? /^Debian (testing|\w+-DI-.*) [other stuff]/ And if you need to be more precise for the after-“-DI-” part, I think we're only going to use /(a|rc)\d+/ there. That being said, I'm happy to let debian-cd people decide whether to update, and what with, they're responsible for those choices, and know about label size constraints, etc. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1029843: brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems
Hi, Diederik de Haas (2023-05-04): > Assuming the '55' stands for max 55 chars, that could be an issue? That's not how format strings work. :) That happily overflows: $ printf "%-10s and the rest of the line\n" kibi kibi and the rest of the line $ printf "%-10s and the rest of the line\n" "Diederik de Haas" Diederik de Haas and the rest of the line > It turns out that spaces (and or backslashes to escape them) seems to > be an issue for the Debian scripts used to make the Debian > firmware-nonfree packages too. See https://bugs.debian.org/1035505 for > details. Once that is fixed, I can submit my MR to add those missing > symlinks. Oh, d-i isn't the only one expecting non-crazy paths! :) > Seems doable. I'm not going to spend time trying to make that though. > I know virtually nothing about d-i/hw-detect internals, so it seems > very unwise for me to even try it. > Given the (specific) subject at hand, you won't be surprised that > there's also a motivational issue ;-) I was merely writing it out so that it could be sanity-checked, I wasn't suggesting you would be the one to implement that. (Instead, I was implicitly volunteering myself…) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1029843: brcmfmac: requested firmware filename inconsistent with linux-firmware.git on non-devicetree systems
Hi, Diederik de Haas (2023-05-04): > On Thursday, 4 May 2023 00:21:25 CEST James Addison wrote: > > I added a note[1] on the rpi4-uefi.dev GitHub repository, and from > > one of your fellow contributors' responses, it seems that in fact > > the filename-with-spaces format _is_ referenced from > > linux-firmware.git, in a 'WHENCE' file that is used to create > > symlinks (I hadn't been aware of that previously). > > And that makes it a firmware-brcm80211 issue and now it all does make > sense as it now all does tie together :-) Great, that's what it looked like to me but I was afraid I could have misunderstood the situation and I didn't want to digress in a wrong direction… > So while upstream does define the link from what I earlier called > 'weird' name to brcmfmac43455-sdio.raspberrypi,4-model-b.txt, the Debian > firmware-brcm80211 package does not define that link and is therefor > missing. Adding the links will at least make those paths shows up in the Contents-firmware indices generated by debian-cd. Those contain 3 “columns”: path, package, component (the current format string is "%-55s %s %s\n"). Even if hw-detect didn't misbehave because of spaces in filenames (i.e. the way the list of missing files is constructed, which I've been assuming is one of the main issue here, but I didn't dive into it because that's not getting rewritten for Bookworm anyway)… it wouldn't be able to perform the required lookup, given how it extracts those “columns” from those indices. (Looking at regular Contents file again, I see there's nothing done specifically — like some kind of escaping — for paths like “/etc/testssl/DST Root CA X3.txt” in the testssl.sh package; so I guess it wouldn't be crazy to just change nothing in debian-cd, and have hw-detect deal with spotting package and component at the end of the line, reading the whole beginning as a path; of course, if someone goes as far as including spaces at the end of some firmware filename, we'll have to just change the format… Cc-ing debian-cd@ for information.) Anyway, you know how stupidly pragmatic I can be… For Bookworm, given we expect the firmware package to be adjusted to include those symlinks, what if hw-detect had some little cheatsheet, turning the space-powered filenames into their normal counterparts right off the bat (while going through the dmesg lines), so that hw-detect would: - not split those into smaller parts, therefore building a list of paths correctly; - additionally succeed in performing the firmware file to firmware package (and component) lookup; - deploy the relevant firmware package; … while the linux kernel would ultimately request the space-powered filenames again, this time finding the symlinks that the updated package would ship, being happy, no longer complaining, and hw-detect would give a green light and carry on. Embedding a little symlinks → files mapping for one single package, that's really not expected to change too much this close to the release… looks like (1) a very ugly kludge, granted; but also (2) a very small price to pay to get immediate support for that particular way of booting Pi devices, without waiting on any major, post-release rewrite. If that looks fine to you, feel free to clone this against hw-detect with the symlinks → files mapping. Cc-ing debian-boot@ for information as well. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1035360: bookworm RC2 installation leaves luks encrypted system in unbootable state
[ Reordering slightly ] Cyril Brulebois (2023-05-02): > Paul Seelig (2023-05-02): > > Attached installation logs should be sufficiently verbose about what > > actually happened underneath. > > Either it was forgotten or dropped by the BTS; please use reply-all, > and attach it compressed (to avoid hitting size limits on either the > BTS side or on the debian-boot ML side). For reference: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035360#10 - https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=1035360;filename=installer-logs.tar.xz;msg=10 > > Apparently, the required cryptsetup-initramfs packages were removed > > from the system during the last instalation stages, rendering the > > resulting system unbootable. That's not quite what happened. Instead, the cryptsetup-initramfs wasn't available to start with: Apr 30 16:11:44 in-target: Package cryptsetup-initramfs is not available, but is referred to by another package. Apr 30 16:11:44 in-target: E: Package 'cryptsetup-initramfs' has no installation candidate Later on, cryptsetup got removed along with a bunch of live packages. Presumably, if cryptsetup-initramfs had been successfully installed, it would have kept cryptsetup around. Again, I'm not familiar with the live environment, it'd be great if some with some knowledge about the way it operates and/or the way it's built could comment on this. Adding debian-live@ for now, but might be debian-cd@ territory… Very wild guess: Could cryptsetup-initramfs be missing from live-setup? https://salsa.debian.org/images-team/live-setup.git Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1035309: unblock: debian-cd/3.2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-cd@lists.debian.org Hi, [ Reason ] [ Impact ] While not absolutely needed to have in bookworm, it looks like a good idea to ship the tooling that's making the release possible. [ Tests ] We appear to have built D-I Bookworm RC 1 with the proposed changes minus the last one (zstd), and D-I Bookworm RC 2 with the proposed changes, and I think it worked OK! :) [ Risks ] We're mostly removing references to old tools, and pulling an extra package on installation images (that was being pulled later on during the installation process so that's not a huge change anyway). The remaining one (symlinks vs. hardlinks) could have been worrying. The aim is to support people doing weird things with the images we produce, and it could possibly regress for people who don't. Needless to say, firmware support is getting extensively tested with various machines, including laptops pulling up to 5 firmware packages, and there were no regressions spotted there. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Thanks for all your hard work. unblock debian-cd/3.2.1 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant diff -Nru debian-cd-3.2.0/debian/changelog debian-cd-3.2.1/debian/changelog --- debian-cd-3.2.0/debian/changelog2023-02-24 17:04:14.0 +0100 +++ debian-cd-3.2.1/debian/changelog2023-04-30 18:11:17.0 +0200 @@ -1,3 +1,20 @@ +debian-cd (3.2.1) unstable; urgency=medium + + [ James Addison ] + * firmware: use hard links rather than symlinks. Closes: #1031696 + + [ Steve McIntyre ] + * Kill loadlin, nobody has DOS any more. Also Stop copying the +/tools directory from the mirror, as that's all that's left there +now. + + [ Cyril Brulebois ] + * tools/generate_di+k_list: Add zstd alongside initramfs-tools and +busybox, since it's now getting installed by base-installer (starting +with 1.212). + + -- Cyril Brulebois Sun, 30 Apr 2023 18:11:17 +0200 + debian-cd (3.2.0) unstable; urgency=medium [ Cyril Brulebois — high-level summary ] diff -Nru debian-cd-3.2.0/docs/makefile.html debian-cd-3.2.1/docs/makefile.html --- debian-cd-3.2.0/docs/makefile.html 2021-04-23 04:39:28.0 +0200 +++ debian-cd-3.2.1/docs/makefile.html 2023-04-01 00:15:03.0 +0200 @@ -38,10 +38,6 @@ ok: Simple sanity checking. -$(MIRROR)/doc:, $(MIRROR)/tools: and -need-complete-mirror -Ensure that we have all the needed pieces of the archive. - General initialisation and cleanup init: diff -Nru debian-cd-3.2.0/tools/boot/bookworm/boot-x86 debian-cd-3.2.1/tools/boot/bookworm/boot-x86 --- debian-cd-3.2.0/tools/boot/bookworm/boot-x862023-02-24 17:01:54.0 +0100 +++ debian-cd-3.2.1/tools/boot/bookworm/boot-x862023-04-01 00:15:03.0 +0200 @@ -157,15 +157,6 @@ cp -lf $disk $CDDIR/$INSTALLDIR/$dir fi done - -if [ -e "$MIRROR/tools" ] && \ - [ ! -e $CDDIR/tools ] && \ - [ "$OMIT_DOC_TOOLS" != "1" ] ; then -echo "Adding tools to CD1" -$BASEDIR/tools/add_files $CDDIR $MIRROR tools -# Remove the win32-loader/ subdirectory from tools, as d-i already installs setup.exe -rm -Rf $CDDIR/tools/win32-loader -fi fi case "$DESKTOP" in @@ -187,9 +178,6 @@ mkdir -p $CDDIR/$INSTALLDIR cp -lf cdrom/vmlinuz $CDDIR/$INSTALLDIR/ cp -lf cdrom/initrd.gz $CDDIR/$INSTALLDIR/ -if [ -e $CDDIR/tools/loadlin.exe ]; then -echo "\\tools\\loadlin.exe vmlinuz initrd=initrd.gz" | todos > $CDDIR/$INSTALLDIR/install.bat -fi # In case of a multi-arch CD the script will be called two times. The # first time the isolinux dir gets set up for single arch; if it is diff -Nru debian-cd-3.2.0/tools/boot/kali-dev/boot-x86 debian-cd-3.2.1/tools/boot/kali-dev/boot-x86 --- debian-cd-3.2.0/tools/boot/kali-dev/boot-x862023-02-24 17:01:54.0 +0100 +++ debian-cd-3.2.1/tools/boot/kali-dev/boot-x862023-04-01 00:15:03.0 +0200 @@ -157,15 +157,6 @@ cp -lf $disk $CDDIR/$INSTALLDIR/$dir fi done - -if [ -e "$MIRROR/tools" ] && \ - [ ! -e $CDDIR/tools ] && \ - [ "$OMIT_DOC_TOOLS" != "1" ] ; then -echo "Adding tools to CD1" -$BASEDIR/tools/add_files $CDDIR $MIRROR tools -# Remove the win32-loader/ subdirectory from tools, as d-i already installs setup.exe -rm -Rf
Re: 11.7 planning + bookworm planning
Steve McIntyre (2023-04-20): > On Thu, Apr 20, 2023 at 11:32:49AM +0200, Paul Gevers wrote: > >We have (if earlier mentioned dates still work for those involved): > > May | June > > > kibi - 13, 20, 27 d-i I'm also fine with any dates in June, not sure if I failed to answer properly earlier… > > > mhy - 13, 20, 27 ftp > > > Sledge- 13 CD > > > Luna - 20 CD testing > > > elbrus- 13 27, (3), 10, 24 release team > > > > It seems a tiny bit late for 13 already, but still, would be > > awesome. What do we think? I share your feelings regarding the “tiny bit late” part but I suppose that should be workable. (It feels a little weird to go from “we don't have a date yet” to “pick the very first one, just 3 weeks away all of a sudden”, but…) > > If we have somebody from CD to do 27 (yes, I remember Sledge can't > > do that one), that would be great as it would be my preference; I'll > > have lots of Debian people physically around me. As the DPL > > mentioned, we might not want to block on press availability, > > although it would be real great if we had them. > > Unfortunately, the other person on the images team who has the > knowledge to do a release (Andy) is also away - we're on the same > vacation! May 27 and June 3 are both out for that reason. We were thinking about the next d-i release before the end of April, so maybe I'll know how to spin builds after that… which would put May 27 on the table, which would feel a little less “tomorrow-ish” than May 13. But again, if we go for May 13, I'll make that work… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: debian-live-testing download errors
Hi Luigi, Luigi Provencher (2023-04-11): > I haven't been able to download debian using zsync. I keep on getting > the same error message. What am I doing wrong? See this message from just a few days ago: https://lists.debian.org/debian-cd/2023/04/msg5.html Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Streamlining d-i releases
(Dropping -cd@ and -release@ — and letting them know via bcc —, that's
probably less interesting for them at this point.)
Joerg Jaspert (2023-04-10):
> I prepared a little script. Now need a SSH key to allow.
Attached.
> Usage is simple, you MUST supply a version, you CAN supply a source and
> a dest suite. Space seperated. It checks amd64s installer in that suite,
> and if the version directory exists, it calls dak copy-installer on it.
LGTM, thanks!
Out of curiosity, what happens if there's one or more missing builds at
some point? Can copy-installer be called several times? A quick glance
at dak/copy_installer.py suggests that check_architecture() does the
right thing (i.e. detect and skip things that exist already).
It seems what matters is the existence of the relevant directories on the
filesystem, which is likely to have happened by the time buildd.debian.org
shows an Installed state (via scripts/debian/byhand-di, called from
daklib/archive.py) but I haven't seen any logs to about auto-byhand so I'm
not entirely sure about the timings.
(In passing The error message has “${SOURCE}s dir” which could get an
apostrophe or lose an s.)
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
id_rsa.pub
Description: application/vnd.exstream-package
signature.asc
Description: PGP signature
Re: live-installer update for Bookworm?
Roland Clobus (2023-04-10): > Aside from Janitor, modernisation and lintian corrections, my change was the > only functionality change in four years (as seen by diffoscope, see below). Maybe, but one shouldn't have to resort to diffoscope to figure this out at this stage of the release cycle. > There is no autopkgtest, but the openQA run for sid shows that the change > has its intended effect. > > If I had known that I would need to file an unblock request, I would have > done so, but the timing (patch, merge, release) was rather unfortunate. OK. > It is certainly not a release critical issue, but I personally find it quite > annoying to have to wait about 30 minutes for the installation, and then to > read 'Installation is complete, so it is time to boot into your new system', > press a key and then wait another 2-3 minutes before the reboot is actually > performed, while the additional waiting time could have been incorporated > into the longer non-interactive phase. Looks like unacceptable/silly delay to me, esp. if a fix is already available and has been confirmed to have the right effects. Please get in touch with the release team to get that fixed in Bookworm. (This reminds me of avoiding one update-initramfs call for each firmware package installation, meaning 1+ minutes instead of 10-15 seconds): I didn't file a bug report for it, so I'm not sure whether I would have called that serious or important or something else, but that's definitely something that's annoying enough and easy to fix that I'm happy to fix even if it doesn't exactly follow the letter of the freeze policy. But several minutes? Even stronger feeling towards getting the fix merged.) Disclaimer: I haven't looked at the diff. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: live-installer update for Bookworm?
Hi Roland, Roland Clobus (2023-04-10): > It turns out that the package 'live-installer' (which is a udeb-only > package) in Bookworm still is at version 57 [2], while the fix was > released at version 58. > > Could the package be unblocked? (And/Or will there be an installer > RC2?) (Yes to RC2, maybe even RC3.) > The new version of live-installer is working correctly, as can be seen > by a sid build of the live image on openQA [4]. I asked Jonathan on IRC while preparing RC1 (slightly edited): [ kibi] highvoltage: I don't think you answered my live-installer question? [ highvoltage] kibi: I didn't think it warranted an unblock [ highvoltage] kibi: but if it did for roland's changes then he could file one [ kibi] highvoltage: ok, ta Besides the obviously missing `dch -r` call (“Mon, 15 Apr 2019” was quite surprising for something uploaded in March 2023), there are lots of changes that are nowhere suitable at this stage of the release process. That plus Jonathan's answer triggered my deciding against unblocking the package on my own (with my d-i release manager hat). That being said, if the release team is willing to unblock the package as is, that'd be fine with me. I suppose it'll be suggested to cherry-pick the desired change(s) and to upload 57+deb12u1 via tpu, or to back out the undesired changes and proceed with 59 via unstable. (Both are fine from a d-i point of view, as long as the package reaches testing in the end.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Streamlining d-i releases
Joerg Jaspert (2023-04-09): > > I realize that getting a sudo line on fasolo would mean increasing the > > security risks quite a bunch for a limited gain. Since we already have > > a mechanism to trigger changes in the archive via release team access, > > that is /srv/release.debian.org/www/proposed-updates/*_comments (which > > we can edit from coccia); maybe something similar could be done to > > trigger dak copy-installer? > > I put SSH trigger into the room, instead of sudo. You supply the version > on the ssh cmdline, and if that exists in unstable, a copy-installer is > run with that version. That looks very good to me, thanks! > Could even be extended to have source and target suite selectable too. I think we only released the installer via tpu once, at least that I could confirm by checking my sent box: dak copy-installer 20220917 -s bookworm-proposed-updates but it could indeed be nice to be able to specify at least the source suite, just in case we encounter some blocking bug in unstable again in the future. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Streamlining d-i releases
Hi ftp team, As you know, publishing a Debian Installer release involves a bunch of steps across various parts of the infrastructure, spanning across many teams: - debian-boot (many udebs + src:debian-installer upload) - ftpmaster (dak copy-installer) - debian-release (udebs + src:debian-installer migration) - debian-cd (image builds) - debian-www (debian.org/devel/debian-installer) I'm able to prepare website updates via the webwml repository and to trigger a partial rebuild of the website to publish the announce (via an update-part sudo entry on wolkenstein). Via debian-release I'm also able to hint (via unblock, unblock-udeb, and urgent) udeb packages into testing, then block the migration of udeb-producing packages for a few hours or days, which lets me upload src:debian-installer on my own timing. I'm also able to hint it into testing once it's built everywhere. Since we have many moving parts, and since regressions or worries can come up at any time, I don't think we would be able to come up with some kind of schedule to coordinate with the ftp team, and I'm left with having to poke you folks without advance warning. I really don't like doing that, and depending on your availability, that might mean several hours (all fine) or sometimes several days until the dak copy-installer step happens. Once one factors in the other delays (britney runs for package migration, dinstall runs to make changes visible on mirrors, prior to the debian-installer upload, or after the dak copy-installer step), this means the release process takes a very while, including (sometimes very) long pauses… I'd like to see if we could shorten it by getting some extra autonomy, to shorten the udeb freeze (it affects a bunch of packages that aren't under the installer team's umbrella, and outside freeze stages it has already upset people enough to trigger an argument during what was supposed to be a nice evening at DebConf…) and to keep the release energy and motivation as high as possible. I realize that getting a sudo line on fasolo would mean increasing the security risks quite a bunch for a limited gain. Since we already have a mechanism to trigger changes in the archive via release team access, that is /srv/release.debian.org/www/proposed-updates/*_comments (which we can edit from coccia); maybe something similar could be done to trigger dak copy-installer? (The other side I usually entirely delegate is building images, and I sync/resync with Steve along the way, based on whether d-i looks good or whether I encounter and fix/workaround roadblocks, but I plan on learning that on my own as well to avoid putting pressure on Steve all the time — got the gid already, lacking know-how at the moment, and possibly access to secrets for the ultimate signing.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1005886: debian-cd: bookworm net-install CD hangs on "Detecting Network Hardware"
Control: severity -1 important James Addison (2023-03-22): > Followup-For: Bug #1005886 > X-Debbugs-Cc: powe...@gmail.com > Control: reassign -1 cdimage.debian.org > Control: retitle -1 cdimage.debian.org: bookworm net-install CD hangs on > "Detecting Network Hardware" > > Sorry (both to you Tony, and also the Debian CD team) for confusion and > wasting > time - I mistakenly reassigned this previously. I've checked the list of > bug-tracking pseudo-packages[1] and I do think that cdimage.debian.org is the > correct package for this bug to be assigned to. Hi Tony, Please attach /var/log/syslog (compressed). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Starting the weekly live images for Bookworm building again
Hi, Steve McIntyre (2023-03-19): > So, after some delay from me and some further delays from various > Debian machines committing suicide [1], I've got bookworm live builds > running again. \o/ Great news. > 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 shouldn't be a surprise as I've been focussing on debian-installer topics rather than trying to also do debian-live stuff… but just for the avoidance of doubt: While I have been behind most of non-free-firmware related work[1], I don't plan on touching anything on the debian-live side. I'm happy to try and answer any n-f-f related questions though. 1. https://debamax.com/blog/2023/02/27/debian-versus-non-free-firmware/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.7 planning + bookworm planning
Hi, Paul Gevers (2023-03-16): > From where I'm looking, bookworm is looking pretty good. Obviously > we'll have to follow through on the flurry of unblock requests that > came in after the hard freeze, but that should be manageable in a > couple of weeks. kibi just told me on IRC that asking this question > now is not crazy from a d-i point of view. Asking questions is never crazy. :) > That hopefully means that around the end of April, also the bookworm > d-i should™ be ready for release (kibi, I'm sure you'll comment on > this if I got you wrong or if you want to provide more details). At this stage, I'd still like to have at least two releases out. The first few weeks after the Alpha 2 release were awfully quiet feedback-wise, that's much better now, and we've got a few fixes and improvements queued up. There's also a brand new set of shim* packages, which should definitely end up in some release at some point. Without having checked with Steve yet, I certainly expect us to be able to publish at least a release in March and another before say mid-April… > So, shall we add availability for May too? 6th, 13th, 20th (Ascension > weekend), and 27th (coincides with DebianReunionHamburg)? … which should be all good for a tentative release in May, we would still have time for a few extra tweaks with a final debian-installer upload, should they be needed at that stage (rather than wait until 12.1). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.7 planning
Jonathan Wiltshire (2023-03-15): > We're overdue for 11.7 and need it done with a keyring update included > before bookworm can be released. The wheels are turning on the keyring so > how do dates in April look for everybody? Saturdays are 1st (probably too > soon), 8th, 15th, 22nd and 29th. I should be able to accommodate any dates for the installer side. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Starting the weekly live images for Bookworm building again
Luna Jernberg (2023-03-15): > And now they have not built for 2 days any specific reason? casulana broke; please refrain from hijacking threads and cross-posting to so many lists. debian-cd would have done just fine… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031696: Also affects bookworm
Pete Batard (2023-03-11): > In other words, the minute you add a package to the standard ISO, that > may be required for installation, it is my opinion that that package > should be accessible for both 'dd' and FST modes of creating Debian > installation media. If this isn't the case, then I will count that as > a regression (of which, we can of course debate the severity level, > but regression nonetheless). In other words, there are no functional changes compared to Bullseye: it's not harder for people to install a system than it used to be. > I am also concerned about your view that nobody outside of a few users > would want to create Debian installation media using their native OS > utilities, which is very reductive in my opinion, especially, again, > considering that Windows does not come with any 'dd' equivalent. This > is even more concerning as Debian is one of the few distros out there > that dropped some elements, like reliance on a specific media label to > locate the installation media, to make that process easier for users. You seem to be putting words in my mouth, and also repeating the same things over and over again, so I'll just walk away. -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031696: Also affects bookworm
Hi, Pete Batard (2023-03-11): > The regression, in my opinion, is that the standard release of bullseye > made sure that all the packages that may be required for a successful > installation would be available for users who did not create their media > using 'dd', whereas bookworm doesn't. The standard release of Bullseye doesn't include all the packages that may be required for a successful installation! That's exactly why we've had this vote on non-free-firmware and all those changes! > Whereas one could use file system transposition with bullseyes to create a > working installation media for a UEFI system, the same is not true for > bookworm, as we now have .deb packages that are symbolically linked and that > will not be found unless the user takes care of manually duplicating those, > or copies the ISO through a utility that does. As far as I can tell, there are no functional changes here. > Again, I will point out that the goal is for users of any OS to be able to > bypass the need to use any external utility (and I'll remind everyone that > Windows does not come with a native 'dd' equivalent for instance) and just > use the native tools that come with the OS to create a Debian installation > UEFI bootable media . This appears to be *your* goal. > With bullseye, and to continue with the example of Windows, this was > possible by simply formatting a USB drive to FAT32 (which can be easily > achieved by right clicking on the drive or through the native disk utility) > then mounting the ISO in File Explorer (again right click, for any version > of Windows starting with Windows 8 included) and copying the files to the > USB drive. You've been repeating that a lot. But those Bullseye images are nowhere more usable! > With bookworm, doing the above no longer guarantees that the media will > result in an installable Debian, because if the user happens to require a > firmware, the relevant .deb package will be missing from /firmware due to > the use of symbolic links. That. is. not. a. change. from. Bullseye. Example: My laptop requires iwlwifi firmware. Please explain to me how it gets installed during the Bullseye installation process. > I hope that clarifies it. Not at all. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031696: Also affects bookworm
Pete Batard (2023-03-09): > In short, if this issue is left unaddressed, bookworm will be introducing a > *regression* compared to bullseye, in that it will no longer be possible to > perform a Debian installation on a UEFI system through file system > transposition, and everyone will be forced to either use DD or use a utility > (like Rufus 3.22) that includes a *custom workaround* for Debian, in order > to duplicate the symbolically linked firmware files. I don't follow. Bullseye doesn't have firmware packages. Bookworm will have firmware packages. They won't be exploitable for people doing weird things. Where's the regression? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1031923: d-i.debian.org: testing (bookworm): Unable to boot due to unsupported FEATURE_C12 in e2fsck
Cyril Brulebois (2023-02-27): > Unfortunately, I wasn't aware of those instructions, and that looks utterly > buggy. How can we claim to publish “official images” that are snapshots, built > using debian-installer daily builds, that can be broken by random packages in > unstable, and left unfixed for weeks?! > > We already have specific instructions on the d-i page[1] regarding > *actual* official releases (as soon as testing gets an Alpha 1), plus > snapshots. My first instinct would be to entirely scrap testing-related > things from the page you started from[2], and just redirect to [1] > instead. > > 1. https://www.debian.org/devel/debian-installer/ > 2. https://www.debian.org/CD/http-ftp/ Just pushed: https://salsa.debian.org/webmaster-team/webwml/-/commit/3b306bd46ff504f215e2758f81199d663bc27d0a https://salsa.debian.org/webmaster-team/webwml/-/commit/eadc4392f9f84dc7a3ce1881472a18a42a52d748 https://salsa.debian.org/webmaster-team/webwml/-/commit/554e4e9521a3d022ea052a28fdc6a215cc1f3c5b Note the website is built every few hours, and those updates will need to be picked up by translators. > That link should be updated too… http://debian-cd.debian.net/ No idea whether that's still useful/maintained, but switched to https:// along with other external links getting adjusted: https://salsa.debian.org/webmaster-team/webwml/-/commit/3d70cb0d8821c3f8ec922ac96298ad77e041fc7e At least right now, it's reporting 11.5.0 as been the latest, which is obviously wrong… Closing this bug report I've been using to track buggy claims on the website. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1031923: d-i.debian.org: testing (bookworm): Unable to boot due to unsupported FEATURE_C12 in e2fsck
Hi, Cesar Enrique Garcia Dabo (2023-02-27): > Thank you for the answer. Good to know that it is a known issue and is being > taken care of. > > Regarding why I took that image. I just followed the official Debian > webpages: > > https://www.debian.org/CD/http-ftp/index.en.html Many thanks for the follow-up… > From there I clicked on "Official CD/DVD images of the "testing" > distribution (/regenerated weekly/) > <https://cdimage.debian.org/cdimage/weekly-builds/>" > > https://cdimage.debian.org/cdimage/weekly-builds/ -> amd64 -> iso-cd -> > https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso > > So from my perspective I wasn't using a "random" image, but rather an > official one, as the web pages indicate. … now I understand what you went through. Unfortunately, I wasn't aware of those instructions, and that looks utterly buggy. How can we claim to publish “official images” that are snapshots, built using debian-installer daily builds, that can be broken by random packages in unstable, and left unfixed for weeks?! We already have specific instructions on the d-i page[1] regarding *actual* official releases (as soon as testing gets an Alpha 1), plus snapshots. My first instinct would be to entirely scrap testing-related things from the page you started from[2], and just redirect to [1] instead. 1. https://www.debian.org/devel/debian-installer/ 2. https://www.debian.org/CD/http-ftp/ That link should be updated too… http://debian-cd.debian.net/ Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck
Simon McVittie (2023-02-24): > If I understand the situation correctly, that means the regression here is > indeed caused by the mke2fs in e2fsprogs/unstable defaulting to creating > a filesystem that cannot be fsck'd by the e2fsck in e2fsprogs/testing, > because orphan_file is a "compat" feature which can be ignored without > error by older kernels and other filesystem consumers like grub, but > due to the nature of a fsck tool, e2fsck is unwilling to tolerate "compat" > features that it doesn't understand? Just to be clear: mke2fs from e2fsprogs-udeb/unstable (the “installer is based on Debian unstable” part) creating a file system that fsck from e2fsprogs/testing (the “install Debian testing” part) doesn't understand. (e2fsprogs/unstable as a binary package wasn't involved in your scenario.) > If that's the case, then I think because of the way our d-i/debian-cd > daily and weekly builds are done, filesystem maintainers need to make > sure that their filesystem-creation tools don't enable a new feature > by default until that feature is (at least minimally) supported by the > corresponding fsck tool *in testing*, and immediately enabling a new > feature as soon as the fsck tool in unstable supports it is too soon. That would seem sensible to me. > In that case this report should probably be reassigned to e2fsprogs, > as a request to stop enabling orphan_file by default until at least the > time that e2fsprogs (>= 1.47.0) has reached testing (but perhaps lower > risk to delay enabling it by default until post-bookworm). The immediate issue should go away for Bookworm anyway: https://bugs.debian.org/1031325#202 And once the feature is turned off, the package might migrate, and everything should be all set for when the feature is turned on again. But feel free to reassign this bug report to keep track of it, there's nothing to be done on the debian-boot/debian-cd side. > Cyril, sorry if I've been saying "d-i" too often here: I don't know > which bits of this are a d-i responsibility and which are a debian-cd > responsibility. That's fine, debian-cd has been Steve mostly, even if I've been getting more involved over the last two release cycles; bugs reports generate the same “bug ownership” feeling when they pop up in either side. Both debian-installer and debian-cd (as in debian-cd.git and setup.git) are inherently intertwined anyway. (Except when I'm utterly confused by a longstanding documentation vs. reality mismatch) I tend to have a vague idea of what's going on in both areas to figure things out… > I reported this to installation-reports because I didn't know which > component was causing this, only that an installation that I thought > was intended to be a supported use-case had failed. Everything you did was very fine. I just didn't realize we were actually publishing images where we ship known bugs… :( Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck
Hi Simon, Cyril Brulebois (2023-02-19): > Simon McVittie (2023-02-19): > > Are d-i alphas and weekly builds built differently? Is it perhaps the > > case that alphas are built from testing udebs, while weeklies are built > > from unstable udebs? > > Let's quote <https://www.debian.org/devel/debian-installer/index.en>: > - Or install the current weekly snapshot of Debian testing which uses >the same version of the installer as the last release: >> Current weekly snapshots > - If you prefer to use the latest and greatest, either to help us test >a future release of the installer or because of hardware problems or >other issues, try one of these daily built images which contain the >latest available version of installer components. >> Current daily snapshots > > We're in the first case: > https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/ > > > I don't know how to list the versions of the installed udebs and > > mke2fs doesn't seem to have a --version option > > You can check /var/lib/dpkg/status (or look at the MANIFEST.udebs file > in the d-i tree if you know where udebs came from). > > Here, e2fsprogs-udeb is at 1.47.0-1, which explains the problem. But the > installer is clearly not “the same versions of the installer as the last > release” since it features linux 6.1.8-1… > > Cc-ing debian-cd@ for input; quoting the rest of your reply in full. Having focussed my attention on d-i releases for so many years whenever debian-cd was involved, it appears I totally missed a big change that happened before I drew short straw for “who's doing d-i now?”, and that was never documented on the website, so we've been lying for 12 years… Weekly build setup change: https://salsa.debian.org/images-team/setup/-/commit/6dcb58e3259036b56925ef277010ce85037b7abd Tentative fix in: https://salsa.debian.org/webmaster-team/webwml/-/commit/a22870164df5007ae4f4e356dfe54983be0f1e9e Already visible on: https://www.debian.org/devel/debian-installer/index.en Sorry for the confusion… and thanks for insisting after my initial and too hasty “it's a known bug, everything's fine” half-assessment… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1031622: d-i regression in weekly builds: FEATURE_C12 unsupported by the installed e2fsck
Simon McVittie (2023-02-19): > Are d-i alphas and weekly builds built differently? Is it perhaps the > case that alphas are built from testing udebs, while weeklies are built > from unstable udebs? Let's quote <https://www.debian.org/devel/debian-installer/index.en>: - Or install the current weekly snapshot of Debian testing which uses the same version of the installer as the last release: > Current weekly snapshots - If you prefer to use the latest and greatest, either to help us test a future release of the installer or because of hardware problems or other issues, try one of these daily built images which contain the latest available version of installer components. > Current daily snapshots We're in the first case: https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/ > I don't know how to list the versions of the installed udebs and > mke2fs doesn't seem to have a --version option You can check /var/lib/dpkg/status (or look at the MANIFEST.udebs file in the d-i tree if you know where udebs came from). Here, e2fsprogs-udeb is at 1.47.0-1, which explains the problem. But the installer is clearly not “the same versions of the installer as the last release” since it features linux 6.1.8-1… Cc-ing debian-cd@ for input; quoting the rest of your reply in full. > I had expected that weekly builds are expected to be able to install > testing. If that expectation is correct, then that means weekly builds > need to be built from udebs that will create a filesystem that is > considered acceptable by testing user-space (and bootloaders and kernels, > but this bug report is about user-space). > > > Closing this bug report as it's not a practical issue with the version > > just released, and since it shouldn't be an issue with later releases > > given grub2 in testing should cope just fine. > > Note that my bug report is not about whether grub2 in testing copes > with the filesystem created by d-i: when I installed from the 2023-02-09 > weekly build, grub successfully loaded my kernel and initramfs, so that > part at least seems fine. The issue I was having is that the *initramfs* > from the testing system I installed did not cope. > > If I'm right about weeklies being built from unstable udebs, then I > think this will continue to be a problem *for weekly builds* until either: > a version of e2fsprogs that can fsck filesystems with metadata_csum_seed > and orphan_file migrates to testing; or e2fsprogs stops enabling those > features on at least the filesystems created in d-i (optionally all new > filesystems, but this particular bug report is about d-i only). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031598: debian-cd: missing Contents-firmware in firmware archives (tar, zip, cpio)
Control: tag -1 patch pending Cyril Brulebois (2023-02-19): > As mentioned earlier on #debian-cd: the firmware archives generated by > make-firmare-image contain the dep11/ directory but are missing the > Contents-firmware index that was added to make hw-detect's easier (and > slightly faster). Fixed in: https://salsa.debian.org/images-team/debian-cd/-/commit/7eea34f26fd61035e443d67bff8f08e5e66196df Only tagging for the time being… Steve, please respin the firmware “images” (tar, zip, cpio) when you get a chance. Nowhere critical, but still nice to have. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1031598: debian-cd: missing Contents-firmware in firmware archives (tar, zip, cpio)
Package: debian-cd Severity: normal As mentioned earlier on #debian-cd: the firmware archives generated by make-firmare-image contain the dep11/ directory but are missing the Contents-firmware index that was added to make hw-detect's easier (and slightly faster). Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
Re: Bug#1030009: www.debian.org: addition of non-free-firmware for bookworm and higher
cc += debian-cd Holger Wansing (2023-02-11): > I have already updated several of files you listed (those which changings > were most likely non-debatable), but now I would like to discuss, what to > do with files like > > releases/bullseye/debian-installer/index.wml > releases/bullseye/errata.wml > releases/buster/debian-installer/index.wml > releases/buster/errata.wml > > Those old release pages have a warning hint like > > If any of the hardware in your system requires non-free firmware to be > loaded with the device driver, you can use one of the tarballs of common > firmware packages or download an unofficial image including these non-free > firmwares. Instructions how to use the tarballs and general information > about loading firmware during an installation can be found in the > Installation Guide. > > unofficial images with firmware included - daily builds > > unofficial images with firmware included - weekly builds > > > First I thought we can leave this completely untouched, since these > "images with firmware included" are still there and they are also still > useful (for some hardware at least), if one wants to install those old > releases. > But now I would like to propose, we change the "unofficial images with > firmware included" phrase, since they are no longer *unofficial* according > to the non-free-firmware GR. > Thus I propose to change this into "special images with firmware included" > for those old releases. > > Comments? I don't think we should change anything for buster and bullseye. We aren't going to produce official images with main and non-free-firmware, and I don't think the current implementation of those unofficial builds (using non-free) would match the spirit of the GR. Maybe people feel differently, but the guiding principle behind all the changes I've driven so far is: the official status is for bookworm and later (same story as for packages in non-free-firmware, even if that component popped up in earlier suites in the archive). Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Heads-up: debian-cd changes
Cyril Brulebois (2023-02-08): > Until a proper debian/changelog for debian-cd is written, I hope both > README and comments in CONF.sh are sufficient. Here we go: https://salsa.debian.org/images-team/debian-cd/-/commit/d7796845f47493a327d74cb6a211e5cadadb7fb0 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Heads-up: debian-cd changes
Hi, I'm contacting you a little in advance of an upcoming debian-cd upload, as the only debian-cd rev-dep. There were many changes lately, to add non-free-firmware support, which might have side-effects. I haven't documented them yet (debian/changelog), and we haven't performed a real review of those changes, or full image builds, but that's coming up soon for the upcoming d-i release. One big change is a heavy reorganization regarding LOCAL/LOCALDEBS support, clarifying the expected layout, etc. I think this might break some existing setups, but it should be much clearer, apt should be happier, etc. It's very likely to have been broken for a while (apt becoming stricter over time), but maybe some old setups were still working by accident… Anyway, it seems like simple-cdd started using that feature back in 2005 (the only match is a debian/changelog entry from that time), but that was dropped in 2015, via: https://salsa.debian.org/debian/simple-cdd/-/commit/b9b48e2c437bbdac3990be1a4a8ebde4b0189f35 I thought I'd drop you a note anyway. Another change that might have side effects is making sure dep11 metadata files are present, so that we can generate metadata for hw-detect to use, helping it detect which firmware packages are needed. Without this change, we might have missed that some metadata was lacking in the archive… but maybe this is going to make simple-cdd users' life harder… That being said, this should happen when FORCE_FIRMWARE is set, so… Finally, the big one: we have NONFREE and NONFREE_COMPONENTS now, with NONFREE_COMPONENTS initially set to "non-free non-free-firmware", and with firmware packages moving to n-f-f, it only lists the latter now. Until a proper debian/changelog for debian-cd is written, I hope both README and comments in CONF.sh are sufficient. Sorry I didn't think of simple-cdd sooner. Lots of moving pieces… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Weekly testing is same as a week ago, it seems
Hi, Daniel Lewart (2023-02-07): > Confirmed. And the 2023-02-06 builds failed too. E.g.: > https://cdimage.debian.org/cdimage/weekly-builds/amd64/ > > All six failed build logfiles end (prematurely) with: > read_file '.disk/base_components' - open: No such file or > directory at /home/debian-cd/build.bookworm/debian-cd/tools/make_disc_trees.pl > line 904. > make[1]: *** [Makefile:487: image-trees] Error 2 > make[1]: Leaving directory > '/srv/cdbuilder.debian.org/git/setup/bookworm/debian-cd' > > These errors were generated by debian-cd's tools/make_disc_trees.pl: > 903 my $base_components = ".disk/base_components"; > 904 my @components = read_file($base_components); > > Many fixes and improvements were made to the debian-cd package in Jan 2023. Sorry for the breakage, and thanks for prodding. I've indeed worked a lot on the netinst, and it looks like I might have broken other kinds of images in the process, my apologies. It's probably as easy as making that “else” part conditional (only tweaking that file if it exists), but since I'm not familiar with other kinds of images, I'll let Steve comment on whether that's (1) expected and (2) the best way to fix this issue. I wouldn't want to paper over a possible bug… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: DEP-11 metadata for non-free-firmware?
Cyril Brulebois (2023-01-19): > At the moment, we have 3 packages there, with no appstream metadata at > all. Questions: > > - Would that explain that no files are generated on mekeel, and >therefore nothing is synced into the archive? > - Or should we have empty indices produced on mekeel anyway, which >should then get synced by dak? Sorry for the noise. I missed there were several rsync calls on the dak side, and at least dak needs patching… https://salsa.debian.org/ftp-team/dak/-/merge_requests/267 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
DEP-11 metadata for non-free-firmware?
Hallo Matthias, I'm contacting you since you're apparently responsible for appstream.debian.org (hosted on mekeel), where dak syncs dep11 stuff from. I'm seeing no dep11 directory for non-free-firmware in the archive at the moment, yet [1] suggests that this new archive area is seen just fine. 1. https://appstream.debian.org/sid/non-free-firmware/index.html At the moment, we have 3 packages there, with no appstream metadata at all. Questions: - Would that explain that no files are generated on mekeel, and therefore nothing is synced into the archive? - Or should we have empty indices produced on mekeel anyway, which should then get synced by dak? If the former, there's probably nothing to fix (and things should go better once things like src:firmware-nonfree is moved); if the latter, I should dive a little more into dak to figure out what's happening there. At the moment, having no dep11 indices for non-free-firmware breaks debian-cd builds against unstable (which is how I'm testing support for non-free-firmware in various components of the installer plus debian-cd). Thanks for your help! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#1029175: generate_firmware_patterns: automate extracting @sof_aliases from most recent linux-image
Package: debian-cd Severity: normal Hi, tools/generate_firmware_patterns has a workaround for the firmware-sof-signed package that doesn't ship appstream/dep-11 metadata. There, we list a bunch of IDs manually extracted from linux-image--amd64, and that list can become outdated over time. It might be best to get the latest kernel at build time and generate e a fresh list for each build. Failing that, we really should update the list at least once for each major Debian release. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Re: 11.6 planning
Adam D. Barratt (2022-11-17): > We've managed to slip behind on getting a bullseye point release > sorted, again. :-( I realise we're heading towards the holidays at a > surprising rate of knots, but hopefully we can find a generally > agreeable date. > > Please could you indicate your availability and preferences between: > > - December 3rd > - December 10th > - December 17th > > At this point, the 10th is probably my preference, as I'm likely to be > busy with work stuff at the tail end of November. I should be able to make any of those work for d-i. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#1021919: virtionet device not found in debian testing netinst ISO 20221017
Hi Laurent, Laurent GUERBY (2022-10-17): > Trying to install the testing netinst ISO in a VM (in proxmox): > > https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-te > sting-amd64-netinst.iso > > The issue is that the installer fails to find an ethernet card which is > there in lspci (virtio ethernet from proxmox). > > Note : same VM under proxmox (just changing the ISO) finds the ethernet > card with officiel debian 11 netinst ISO. I'm seeing BFP issues, similar to those reported here: https://bugs.debian.org/1003210 except for the virtio_net module. Checking /var/lib/dpkg/status, it looks like we have kernel-image from 5.19.11-1 and nic-modules from 5.19.11-1+b1, which would mean kernel and modules from a different build, which was flagged in #1003210 as possibly problematic. Looping in kernel maintainers to get some input, and debian-cd for information given the way testing images are built… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: sha512sum-error at debian-live-11.5.0-amd64-gnome.iso
Hallo Gerd,
Please set something like LC_ALL=C, not everybody understands German. :)
Gerd Mühlenbruch (2022-10-03):
> Today I downloaded the present debian-live-11.5.0-amd64-gnome.iso via my
> prepared script
> *
> Optionen="-c -nv --show-progress --limit-rate=800k -a Ziele.log"
> Pfad="https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid;
> wget $Optionen $Pfad/debian-live-11.5.0-amd64-gnome.iso
> wget $Optionen $Pfad/debian-live-11.5.0-amd64-gnome.log
> wget $Optionen $Pfad/debian-live-11.5.0-amd64-gnome.packages
> rm SHA512SUMS
> rm SHA512SUMS.sign
> wget $Optionen $Pfad/SHA512SUMS
> wget $Optionen $Pfad/SHA512SUMS.sign
> *
>
> The final check
> sha512sum --ignore-missing -c SHA512SUMS
> resulted into
> debian-live-11.5.0-amd64-gnome.iso: FEHLSCHLAG
> debian-live-11.5.0-amd64-gnome.log: OK
> debian-live-11.5.0-amd64-gnome.packages: OK
> sha512sum: WARNUNG: 1 berechnete Prüfsumme passte NICHT
> It was my first failed check.
I downloaded the same ISO, and SHA{256,512}SUMS with Firefox, and both
validate.
For the record, that's what I'm seeing:
3efed2698da7fab0218a505eb504410d4cd9c7bc09478483bdbb3c593013b371
debian-live-11.5.0-amd64-gnome.iso
450d09f1f1556effce4bc072ad395e45652aa40ed035b8ab35616c54fbef0c6edf803acb483ac25737b12bbae858277c1aa261eee36c4edf505a85c915d73c67
debian-live-11.5.0-amd64-gnome.iso
> Already since some years, the check
> gpg --keyserver keyring.debian.org --verify SHA512SUMS.sign SHA512SUMS
> reports that the key doesn't have a trusted signature
> gpg: Signatur vom So 11 Sep 2022 01:00:38 CEST
> gpg: mittels RSA-Schlüssel
> DF9B9C49EAA9298432589D76DA87E80D6294BE9B
> gpg: Korrekte Signatur von "Debian CD signing key
> " [unbekannt]
> gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
> gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem
> vorgeblichen Besitzer gehört.
> Haupt-Fingerabdruck = DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294
> BE9B
> This may be my own problem, because I haven't got a book to learn gpg.
The English version:
$ gpg --keyserver keyring.debian.org --verify SHA512SUMS.sign SHA512SUMS
gpg: Signature made Sun 11 Sep 2022 01:00:38 CEST
gpg:using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Good signature from "Debian CD signing key
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258 9D76 DA87 E80D 6294 BE9B
The important part is that the signature is correct. The warning is
about your not having set a level of trust for the signing key. That's
not a problem.
Cheers,
--
Cyril Brulebois (k...@debian.org)<https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
Re: debian-installer 20220917 via tpu
Hi, Ansgar (2022-09-20): > Cyril Brulebois writes: > > FTP Masters, please sync the installer from *tpu* to testing, once it's > > available there. > > > > dak copy-installer 20220917 -s bookworm-proposed-updates > > Done: > > +--- > | $ dak copy-installer 20220917 -s bookworm-proposed-updates > | > | Will copy installer version 20220917 from suite bookworm-proposed-updates to > | testing. > | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, > arm64, mips64el > | Architectures to skip: > | Installer has been copied successfully. > +--- Thanks! That's now available on mirrors, and debian-installer was accepted into testing from tpu (and prop-up'd to unstable automatically). debian-cd: burn baby, burn! Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Time to drop win32-loader ?
Salut OdyX, Didier 'OdyX' Raboud (2022-07-19): > That brings two sides of the question: > * should it still be shipped on amd64 netinsts, CD's, other images? > * should it still be offered on the mirrors ? > on https://deb.debian.org/debian/tools/win32-loader/stable/ > (where it lands via dak's byhand handling upon uploads; but is manually > moved by ftp-master on migrations and release days) > > (I orphaned win32-loader back in September, and it still doesn't have an > official maintainer; but I'd be happy to work towards ditching it away :-P) As you know, I've been perfectly happy with staying away from having to know too much about it… (and I'm sorry to have left it on your shoulders). While I have no idea about its relevance versus current Windows versions (I don't have any such systems, and with Secure Boot being supported by Debian, booting Debian directly shouldn't be a huge issue…), or about whether it works there, I'll just mention that it's been useful to salvage at least two computers at my LLUG during the last year: - one wouldn't boot from anything else than its hard drive (a very buggy BIOS was suspected, but the machine was 500+ km away); - one would know how to boot from a CD but nobody had the external CD drive (and cable!) that would make that work. That being said, those are only anecdotes, and for such 10+y, 15+y systems, I wouldn't find it crazy to suggest users to maybe give up on them, or if they insist, use an installation image or the executable from a previous Debian release? (A quick look at http://ftp.debian.org/debian/tools/win32-loader/ suggests it goes back at least to triple-old stable… and given the size of each directory, the cost of keeping some old ones shouldn't be a huge issue.) On the usability side, salvaging old systems like this isn't quite easy anyway, as antique browsers (IE we meet again), libraries (TLS 1.3 anyone), certificate truststores (Let's Encrypt who are you), and similar challenges made it hard to just get to the Debian website, documentation, and actual download. TL;DR: No objections either way. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: buster EOL (10.13) and 11.5 planning
Hi, Adam D. Barratt (2022-07-28): > Use of buster-security will pass from the Security Team to LTS in a few > days time, so we should get the EOL point release organised. We need at > least a couple of weeks to get things sorted, so as some suggestions: > > - August 20 > - [August 27 doesn't work for at least me and the Images Team, so nope] > - September 3rd > - September 10th > > We're currently only 3 weeks past the 11.4 bullseye point release, but > that was also about 6 weeks late. It's therefore worth considering > whether we want to try and get 11.5 out sooner and get back onto the > previous track, or delay it a little more and aim for every two months > from 11.4's release date. > > tl;dr - please indicate your availability / preferences for the above > dates (for both 10.13 and 11.5) and any opinions on whether we should > do them at the same time or separately. Leaving aside the debootstrap's pu/opu requests that I would be happy not to have to be involved with (trusting Luca's assessment instead), I'm happy to try and accommodate any dates that might be picked up for 10.13 and 11.5, for all other installer-related tasks. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: New Ukrainian Mirror
Cyril Brulebois (2022-06-25): > Thanks for reaching out to us, but according to [1], you should be using > a form [2] instead. > > 1. https://www.debian.org/mirror/ftpmirror#submit > 2. https://www.debian.org/mirror/submit Sorry, I failed to notice you were requesting the addition of a regular debian mirror along with the addition of a debian-cd mirror. Hopefully someone with more knowledge will pick it up from here… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: New Ukrainian Mirror
Hi Ivan, s...@ukr.net (2022-06-07): > Please add a new Debian CD mirror. > > Name: FastMirror > Site: https://fastmirror.pp.ua/ > Repo link: (http|https|rsync)://fastmirror.pp.ua/debian > <http://fastmirror.pp.ua/debian> and > (http|https|rsync)://fastmirror.pp.ua/debian-cd > <http://fastmirror.pp.ua/debian-cd> > Admin Name: Ivan Barabash > Admin Email: s...@ukr.net <mailto:s...@ukr.net> > Speed: 1GBps > IPv4: 93.126.105.202 > IPv6: 2001:470:6224::6829:17ff:fe25:da0c > Location: Ukraine, Kyiv > Mirrored architectures: amd64 arm64 armel armhf i386 mips mips64el mipsel > ppc64el s390x Thanks for reaching out to us, but according to [1], you should be using a form [2] instead. 1. https://www.debian.org/mirror/ftpmirror#submit 2. https://www.debian.org/mirror/submit Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: bullseye CD/DVD for arm64
Hi, Wilhelm MOSER (2022-06-18): > Ja, das ist mir schon klar nur wenn debina das release macht dann muss doch > zumindest das notwendigste funktionieren. > Wenn in der LXDe dann bei XY die Maus nicht geht ist das eben ein bug wenn > ich das ding sber nich mal installieren kann dann setzt es aus. Und ich hab > null bock das Ding am Herzen zu operieren. Ich bin user und kein > OS-Entwickler. Und ich denke es muss doch schon mal sein dass man die > bekifften kinder ordentlich anscheisst. Oder nimmst du ein Auto wo du erst > mal den Vergaser zerlegen mußt damit du das neue Ding überhaupt fahren > kannst? So kostenlos kann das Klumpert gar nicht sein dass jemand seine > Lebenszeit für von anderen bewußt gelegte Eier opfert. Unless otherwise specified, English is supposed to be used on Debian mailing lists… https://lists.debian.org/debian-user-german/ might be more appropriate. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.4 planning
Adam D. Barratt (2022-06-17): > - July 2nd (means freezing next weekend, but so be it) > - July 9th Both would be fine d-i wise. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.3 and 10.12 planning
Hi, Adam D. Barratt (2022-03-06): > As you may have noticed, we're a bit overdue now for both 11.3 and the > penultimate buster point release, 10.12. > > Some potential dates: > > - March 19th (means freezing next weekend, so not ideal) > - March 26th > - April 2nd > - April 9th I should be able to make any of those work. > (For personal reasons, I'd rather avoid that last weekend, and probably > won't be available on the Sunday, but could do the Saturday if need > be.) > > I know there's already a few things pending on KiBi's review list; > I'll try and flag up any others as soon as I can. Things are getting less crazy on my side, so I should be able to get on those shortly. Once a deadline is set, I usually pick them up quicker anyway. ;) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#992699: debian-installer: Firmwares required for some sound cards
Hi, Samuel Thibault (2022-02-13): > Cyril, could you try on the actual hardware the resulting image: > https://people.debian.org/~sthibault/tmp/debian-sid-amd64-NETINST-1.iso Please don't block on me, I'm *very* low on free time, and I don't see that improving until March or so. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.2 planning
Adam D. Barratt (2021-11-23): > It's (a little past) time that we organised the next point release. As > an "every other" release, this time will only be for stable. > > Any of the first three weekends of December would work for me, although > the 4th is my least preferred as it means freezing over the coming > weekend and I'm not sure if I'll have time to do a fair job of dealing > with things before that. > > tl;dr, suggested dates: > > December 4th [least preferable for me] > December 11th > December 18th Any of those would work for me. (I'm over-* anyway, so I'll make myself available for whatever you choose.) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.1 and 10.11 planning
Hi, Andy Simpkins (2021-09-15): > given that Steve will be around I am happy for both in one day :-) If that was meant as a reply to everyone rather than an internal confirmation on debian-cd@, maybe send the same mail via reply-all? :) Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 11.1 and 10.11 planning
Hi Adam, Adam D. Barratt (2021-09-06): > We've ended up being late with planning 10.11 due to the timing of the > bullseye release, and also need to look at getting 11.1 sorted. > > Traditionally, we've combined stable and oldstable point releases (at > 2- and 4-month cadences) while both are supported. That would still be > my preference, but I understand that not everyone on the Images side > is so keen on the idea. Open questions in addition to dates are > therefore whether we should do 10.11 and 11.1 on the same day and, if > not, how close together they should be. > > A few suggested dates to get things going: > > September 18th - not great; means freezing this coming weekend > September 25th - not great; I'm away during most of the week > beforehand, so will be unlikely to be able to deal with any issues, > make sure everything's ready, etc. > October 2nd - OK for me > October 9th - OK for me > October 16th - OK for me Regarding d-i preps, I should be able to accomodate anything that gets picked up. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Bug#992699: debian-installer: Firmwares required for some sound cards
Samuel Thibault (2021-08-22): > As mentioned in the Bullseye errata, there seems to be a number of > sound cards that require loading a firmware to be able to emit sound > (e.g. Intel SOF). Unfortunately currently the installer loads firmware > after loading the ISO image, while speech synthesis is needed at the > very first interaction with the user, which is usually before that. We'd > thus want (for the firmware-enabled image) to include firmware in the > initrd somehow. For context, that's sof I was fighting with: https://tracker.debian.org/news/1245087/accepted-hw-detect-1147-source-into-unstable/ > We discussed a bit on IRC, possibly we could just, at debian-cd step, > catenate the cpio archives, or unpack/assemble/repack, or ship several > initrds. Let's clarify a little: - Shipping several initrds would probably mean having an empty, placeholder-like “extrastuff.gz” set by the debian-installer build, that we would replace with some firmware-containing initrd for some builds in debian-cd; that would mean that src:debian-installer would still be responsible for setting up the relevant bootloader config, instead of having part of it in debian-installer, and another part in debian-cd. - But I don't think that's required, adjusting the initrd in debian-cd should be far easier. I thought about the “combine archives” part and smcv confirmed we should just be able to cat (compressed) CPIO archives together. I've tried the following with a netboot-gtk build (easier than trying to edit a firmware-enabled ISO :D), keeping in mind my cpio-speak is rusty: dpkg -x firmware-sof-signed_1.7-1_all.deb tmp (cd tmp; find lib | cpio -Hnewc -o) | gzip -9 > ~/debian-installer/installer/build/firmware-sof-signed.cpio.gz cd ~/debian-installer/installer patch -p1 < ~/0001-Talk-to-me.patch # attached this time… make -C build/ rebuild_netboot-gtk USE_UDEBS_FROM=bullseye I have *not* conducted extended testing, but that still boots successfully within qemu with -soundhw all, and speaks when using the 's' shortcut for speech synthesis. And once booted on my sof-enabled laptop, it starts speaking, so I suppose that's a successful PoC; next step is to confirm whether tweaking debian-cd to do the cat dance looks good to Steve as well. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant From 0aa52e10af3b5b99950073156a5d2dd0063ca9b0 Mon Sep 17 00:00:00 2001 From: Cyril Brulebois Date: Sun, 22 Aug 2021 15:52:23 +0200 Subject: [PATCH] Talk to me. --- build/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/build/Makefile b/build/Makefile index 3a54a8bcd..9b6a9732b 100644 --- a/build/Makefile +++ b/build/Makefile @@ -724,6 +724,7 @@ endif initramfs) \ $(mkinitramfs) $(TEMP)/initrd; \ $(gzip) -v9f $(TEMP)/initrd; \ + zcat firmware-sof-signed.cpio.gz >> $(TEMP)/initrd.gz; \ ;; \ jffs2) \ $(mkjffs2) $(TEMP_INITRD); \ -- 2.30.2 signature.asc Description: PGP signature
Re: Bug#992699: debian-installer: Firmwares required for some sound cards
Samuel Thibault (2021-08-22): > As mentioned in the Bullseye errata, there seems to be a number of > sound cards that require loading a firmware to be able to emit sound > (e.g. Intel SOF). Unfortunately currently the installer loads firmware > after loading the ISO image, while speech synthesis is needed at the > very first interaction with the user, which is usually before that. We'd > thus want (for the firmware-enabled image) to include firmware in the > initrd somehow. For context, that's sof I was fighting with: https://tracker.debian.org/news/1245087/accepted-hw-detect-1147-source-into-unstable/ > We discussed a bit on IRC, possibly we could just, at debian-cd step, > catenate the cpio archives, or unpack/assemble/repack, or ship several > initrds. Let's clarify a little: - Shipping several initrds would probably mean having an empty, placeholder-like “extrastuff.gz” set by the debian-installer build, that we would replace with some firmware-containing initrd for some builds in debian-cd; that would mean that src:debian-installer would still be responsible for setting up the relevant bootloader config, instead of having part of it in debian-installer, and another part in debian-cd. - But I don't think that's required, adjusting the initrd in debian-cd should be far easier. I thought about the “combine archives” part and smcv confirmed we should just be able to cat (compressed) CPIO archives together. I've tried the following with a netboot-gtk build (easier than trying to edit a firmware-enabled ISO :D), keeping in mind my cpio-speak is rusty: dpkg -x firmware-sof-signed_1.7-1_all.deb tmp (cd tmp; find lib | cpio -Hnewc -o) | gzip -9 > ~/debian-installer/installer/build/firmware-sof-signed.cpio.gz cd ~/debian-installer/installer patch -p1 < ~/0001-Talk-to-me.patch make -C build/ rebuild_netboot-gtk USE_UDEBS_FROM=bullseye I have *not* conducted extended testing, but that still boots successfully within qemu with -soundhw all, and speaks when using the 's' shortcut for speech synthesis. And once booted on my sof-enabled laptop, it starts speaking, so I suppose that's a successful PoC; next step is to confirm whether tweaking debian-cd to do the cat dance looks good to Steve as well. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Recommend Balena Etcher for creating bootable disks
Pirate Praveen (2021-08-17): > At https://www.debian.org/CD/faq/#write-usb I think Balena Etcher [1] should > be recommended either replacing win32diskmanager or in addition to it. This > is very easy to use and also works on Mac OS. > > [1] https://www.balena.io/etcher/ If it helps decide whether it's trustworthy enough to recommend deploying Debian images with, Etcher has been the recommended way to deploy Tails from Windows and macOS for a while: https://tails.boum.org/install/win/usb/ https://tails.boum.org/install/mac/usb/ (That being said, I have never used it myself.) > Note: please cc me on replies Done. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#992280: cdrom: Debian 11 installer fails to produce usable display
Hi Mike, Mike Perrin (2021-08-16): > Dear Maintainer, > > Attempted to install Debian 11.0.0 on AMD Ryzen 3 2200G ASRock > A320M-HDV motherboard with VGA connected NEC EA231WU 1920x1200 > monitor. Both the netinstall and DVD-1 images booted but each produced > a shredded raster display for both the graphic and text install > options. Please check the installation guide, we'd be happy to have some feedback regarding the proposed workarounds: https://www.debian.org/releases/bullseye/amd64/ch02s02 https://www.debian.org/releases/bullseye/amd64/ch06s04#completing-installed-system Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#991771: debian-installer: firmware support: review/update “6.4.1. Preparing a medium” procedure
Package: debian-installer Severity: normal X-Debbugs-Cc: debian-cd@lists.debian.org A lot of work has happened in the firmware support department for Bullseye, as documented in #989863. In passing, Steve mentioned the “download archives of firmware packages” use case that we document in 6.4.1: https://www.debian.org/releases/bullseye/amd64/ch06s04.en The code changes implemented to widen firmware detection rely on supplemental information extracted from DEP-11 metadata, and ship alongside the included firmware packages, on the debian-cd side, only when building (unofficial) firmware-enabled images. To make sure we wouldn't disrupt anything on (official) main-only images, we shipped those `*.patterns` files in a `dep11` subdir of the `firmware` directory (again, only for firmware-enabled images). If we want to make it possible for people to complete their main-only installation image with files they would download separately, we would need those files to be shipped somewhere on the installation image, and/or to update those instructions. This would likely require code changes in any cases, since hw-detect prompts for extra storage devices from check-missing-firmware (in case firmware files were spotted as missing in dmesg), while the extra looking at `.patterns` files was implemented in the post-base-installer 50install-firmware hook. This didn't seem to be very high priority, and I didn't make it a blocker for 11.0; we can brainstorm what use cases we want to support and how, implement changes in D-I Bookworm Alpha releases, and maybe cherry-pick results in 11.n. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Re: Bug#991587: hw-detect: check-missing-firmware can be a tad aggressive
Control: clone -1 -2 Control: reassign -1 cdrom-detect Control: retitle -1 cdrom-detect: ask hw-detect to skip missing firmware detection Control: reassign -2 iso-scan Control: retitle -2 iso-scan: maybe ask hw-detect to skip missing firmware detection Cyril Brulebois (2021-07-28): > While I'm not entirely certain about use-cases around iso-scan, I would > think cdrom-detect should be one of the very few first things to happen > on a system, and that raising errors because of missing firmware files > at this stage wouldn't help: even a firmware-enabled image wouldn't be > mounted and firmware packages wouldn't be available (later, they show up > at /cdrom/firmware). > > Therefore, I'm proposing: > > 1. Implement support for an environment variable in hw-detect, that > would disable the check-missing-firmware call. Done, but only tested manually (be re-typing the patch live). > 2. Set this variable for both hw-detect calls in cdrom-detect's > postinst. [This should fix the problem I'm seeing.] Done, will be tracked by -1 (same proviso as above). > 3. Set this variable for the hw-detect call in iso-scan's postinst. > [Optional, I'm not sure what people are doing before iso-scan kicks > in; maybe some firmware-holding block devices could be available at > this stage, so letting the missing firmware detection in place might > make sense in this case.] Not done, we'll keep track of it via -2 and see if people hit the issue, mention their use case, and if we can draw any conclusions as to whether we should go the same route as with cdrom-detect. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Bug#991587: hw-detect: check-missing-firmware can be a tad aggressive
Package: hw-detect Version: 1.146 Severity: important X-Debbugs-Cc: debian-cd@lists.debian.org I hadn't seen the following when test-installing in loops, since I was using a netboot-gtk image, but this can be seen with a regular netinst image produced by debian-cd, since the d-i image used there is slightly different. I fear this is going to be a rather common annoyance, so I'd like to get that fixed before the Bullseye release (either in D-I Bullseye RC3 or in the final D-I release). On this Dell G3, right after selecting locale settings, cdrom-detect kicks in and tries to find the installation image to load. Doing so, it calls hw-detect with this (two occurrences): hw-detect cdrom-detect/detect_progress_title || true which iso-scan can also do (one occurrence): hw-detect iso-scan/detect_progress_title || true At the bottom of hw-detect, there's a check-missing-firmware call, which can trigger errors and prompts about irrelevant firmware files, e.g.: intel/sof/sof-cml.ri (which is about sound support, see firmware-sof-signed.) While I'm not entirely certain about use-cases around iso-scan, I would think cdrom-detect should be one of the very few first things to happen on a system, and that raising errors because of missing firmware files at this stage wouldn't help: even a firmware-enabled image wouldn't be mounted and firmware packages wouldn't be available (later, they show up at /cdrom/firmware). Therefore, I'm proposing: 1. Implement support for an environment variable in hw-detect, that would disable the check-missing-firmware call. 2. Set this variable for both hw-detect calls in cdrom-detect's postinst. [This should fix the problem I'm seeing.] 3. Set this variable for the hw-detect call in iso-scan's postinst. [Optional, I'm not sure what people are doing before iso-scan kicks in; maybe some firmware-holding block devices could be available at this stage, so letting the missing firmware detection in place might make sense in this case.] For the avoidance of doubt, hw-detect is called in many places, later for networking devices and for disks; those are much more likely to require some firmware files to be available… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Re: 10.10 planning
Adam D. Barratt (2021-05-30): > We're now a little overdue for 10.10, but it looks like we're ready in > terms of shim etc. changes, so we should look at dates. > > Please could you indicate your availability for (and any preferences > amongst) the following: > > Saturday June 12th > Saturday June 19th > Saturday June 26th > > The 12th is doable, but means we have to freeze next weekend; on that > basis I have a personal preference for the 19th, although I realise > that it's further out of cadence. I should be able to do anything of these work. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Speed up installation: increase priority of eatmydata-udeb to standard
Hi, ValdikSS (2021-04-28): > eatmydata-udeb package is designed to speed up the installation process. > However, it's not used by default and could be activated only with preseed > file or kernel cmdline argument. > > Please consider increasing eatmydata-udeb priority to standard in > debian-installer overrides, for it to be used by default. This will speed up > installation by an order on slower HDDs. > > It will be perfect to include this change before final Bullseye ISO release. > > For more information, read the post in debian-boot: > https://lists.debian.org/debian-boot/2021/03/msg00121.html We already have a lot of serious problems to solve in the installer; I wouldn't want to see possible extra perturbations due to a syscall interceptor. The best would be to have that kind of change happen right at the beginning of a release cycle, rather than in the last few weeks before a release… A compromise might be thinking about backporting the change to bullseye once it's been tested with some D-I Bookworm Alpha 1 (but that would also be a rather important change to backport to a stable release…). Happy to hear other opinions. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Trivial? arm64 weekly distro request to save us hassles:
Hello Dave, Yahoo pugh_ca (2021-04-27): > I am one of those Raspberry Pi 4 users who is vanilla-installing your > weekly Bullseye testing netinst.iso's.The one problem we always have > is that we must jump thru hoops to get the applicable .ko to use for > bcmgenet (Broadcom gigabit ethernet).I was not successful finding a > 'mdio-bcm-unimac.ko' for the April 26 weekly release, actually. > > Can you ensure that the kernel module that implements bcmgenet is > included in the distro so that out network detection portion of the > netinst.iso install always succeeds? > > That would be fantastic for us Raspberry Pi 4 users eagerly keeping up > with the weekly testing arm64 netinst.iso's. This in tracked on the linux kernel side in: https://bugs.debian.org/985956 Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Tentative summary of the AMD/ATI/NVidia issue (was: Finding a tentative bullseye release date)
[ cc+=-x@ ] Hi Lucas, Thanks for your summary, I'm not sure about every single detail, but it seems to be a good basis for discussion. I might point to it from our errata page (I didn't have a specific bug report when I wrote the most recent entries): https://www.debian.org/devel/debian-installer/errata Lucas Nussbaum (2021-04-24): > Disclaimer: I read the "[AMD/ATI graphics] Missing firmware not declared > / kernel modules not included in initrd" thread. While my understanding > of the issue is not complete, I'm trying to summarize what I undertood > so far in the hope that others can jump in and fill in the blanks or > correct me. > > > There are graphic cards whose in-kernel drivers require non-free > firmwares. Typically AMD/ATI cards that require firmware-amd-graphics[1] > to work with the radeon, amdgpu and r128 drivers; or NVIDIA cards that > require firmware-misc-nonfree to work with the nouveau driver. > > [1] https://packages.debian.org/unstable/firmware-amd-graphics > > > With Debian 10, the behaviour was that the installation succeeded > without installing firmware-* packages, and then, and the first boot, X > would start in a "degraded" mode (using, for example, the vesa driver). > The user would generally then install the firmware package (or, in the > case of NVidia, switch to the proprietary drivers). > > With Debian 11, the installation also succeeds, but then at first boot, > X fails to work correctly. What happens here is unclear: reports vary > between "black screen" (but does the system works if the user switches to > console mode?), "garbled screen", "system crash" (but maybe the user did > not notice that the system works in console mode). What I briefly alluded to on IRC (#debian-boot) was something that would be an A)+B) approach. C) doesn't seem reasonable to me. > It looks like the three open paths for resolution are: > > A) understand and restore the behaviour from Debian 10, that is, get X > to work in a degraded mode after installation. How it worked with Debian > 10 (and why it doesn't with Debian 11) is unknown. Without checking with X people beforehand, what I imagined we could do when running an installer that doesn't have non-free enabled could be adding some X conf snippet to force a generic driver (a while ago, that would have been fbdev/vesa, not sure about the current state, depending on whether modesetting kicked in, etc.), to ensure one isn't left with a black screen. This might involve setting kernel parameters instead or in addition to that… It could be accompanied by an information note in the installer (to make sure the user knows about this degraded mode, and about ways to improve the situation post-installation) and/or in the installation guide and/or in the wiki. https://xorg-team.pages.debian.net/xorg/ doesn't seem like it has had many updates lately, but it might not be the worst place to have a “how to undo the snippet things and get the real deal once firmwares are installed”, or maybe “how to deal with firmwares” in general… that d-i and the installation guide could point to. (x.debian.net still exists and redirects there, so that's not a complicated URL to remember/type if it gets displayed in a note.) That being said, if an information note gets added in d-i, its content needs to be checked with the X team, reviewed by the team whose name has escaped me, and then translated into as many languages as possible. It could be possible to cheat the translation status to alleviate this requirement, and contemplate updating the relevant package in 11.1, but I'm not sure we've ever done that. On the other hand, docs on x.debian.net aren't translated, so maybe the installation guide would be a better place in the end… > B) In the installer, detect that firmware-amd-graphics or > firmware-misc-nonfree should be installed, and either install it (?), > or redirect the user to the unofficial installer that includes them. That could be achieved for an installer that has non-free enabled, provided the proposal by Ben gets implemented, then consumed on the d-i side. > C) Do nothing and document this in the release notes As said above, I strongly recommend against this. > The main blocking factor for progress seems to be that not enough > people have both hardware that is not supported (laptops/desktops with > AMD or NVidia graphic cards), and the knowledge and time to > investigate this. For the avoidance of doubt: I'm fine with working on these topics (and getting my hands on relevant hardware is in progress), along with other issues that seem to be potential blockers for the release. I just don't expect everyone to agree on a (possibly dual) solution immediately, and the relevant contributions (code, doc, translations) to be available in the very next few days. Hence my
Re: Finding a tentative bullseye release date
Hi Paul, Paul Gevers (2021-04-23): > I hear you. So, I fear that we're getting into a situation where > everything except the installer is more or less ready for the bullseye > release. (Well assuming the shim is signed any time soon). > > > D-I Bullseye RC 1 was published a few hours ago. And at the risk of > > sounding like a broken record: I have *absolutely no guarantee* to > > have a fix or workaround for the amdgpu issue in less than a month, > > that would be tested somewhat. > > > > Can we please *not* release with black screens for AMD users? > > Indeed, let's not. But can't we get the full Debian community on board > to search for good solution? I have the feeling there's much interest > to release sooner rather than late, so maybe there's brains we can use > to help the installer forward? I'm going to draft a bits shortly, is > there a bug number or mail thread we can point at? I've just put out a new release, and I've tried to assemble stuff into errata, can I *please* just have some time to look at our bugs, triage them, and see what needs be fixed before the bullseye is out?! amdgpu is the biggest issue I could think of, for this thread, and for errata, but we have other showstoppers apparently. We need *time* to stabilize the installer. What really worked last times was iterating over as many releases as needed. I tried to convey this earlier, but seemed to have failed, so I'll just repeat myself: Over the last few release cycles, we've had a *predictable* timing, with no sense of urgency and due date, and I've felt trusted to do the right thing all the way. It's been a few weeks since I've started to feel like this is getting taken away from me. That's not a particular joyful experience, and that's also a pretty huge motivation killer. > Also, I recognize that the debian-installer is largely handled by you > alone. I estimate that it's not going to help you on the short term if > people volunteer to help with the coding as you would be spending time > on on-boarding them. So, how can we, the Debian Community, help you > getting the installer in releasable shape? I'd advise releasing the time pressure, but it seems my pleading for exactly that over the last few weeks/months hasn't achieved anything. > I can think of testing RC1, but what else? Do you have the right > hardware available for the amdgpu issue? Can people try out solutions > for you? Tell us, or tell us how to find out. No, I don't have any amdgpu hardware at the moment; but yes, I have leader@'s checklist handy for when I can allocate some time to plan for this. > That said, I still think it's good to keep May 22 in the agenda as an > option to do the release, with the remark that we'll not release when > we're not ready (as Debian always does). Getting mixed signals after the initial “I hear you”… Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Finding a tentative bullseye release date
Hi, Paul Gevers (2021-04-21): > > We propose to aim for a release date in May. Would either of the > > following work for you and do you have any preference? > > - May 1 > > - May 8 > > - May 15 > > - May 22 > > - May 29 > > I've seen replies from Steve for CD, from Donald for Press and Cyril > for d-i. Can you please let us know if/when you're available? > May 1 CD, Press > May 8 CD, Press > May 15 CD > May 22 CD, Press > May 29 (CD) > > [d-i: the later the better] My answer wasn't quite meant to state “May is fine”… > Seems like our current best option is May 22 if you can make it. That's definitely not what I would call “best option” from an installer point of view. D-I Bullseye RC 1 was published a few hours ago. And at the risk of sounding like a broken record: I have *absolutely no guarantee* to have a fix or workaround for the amdgpu issue in less than a month, that would be tested somewhat. Can we please *not* release with black screens for AMD users? Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Finding a tentative bullseye release date
Hi, Paul Gevers (2021-04-09): > The Release Team believes that the state of bullseye is pretty good. > Yes, there are some blocking bugs [1] and d-i and shim still need some > love, but the state is much better than we remembered from the same > time in buster. As already explained, trying to release in April/May wasn't quite anticipated, and there's still ground to cover on the d-i side. > Last time in the buster release cycle, it took quite a while to pick a > release date once it was clear that buster could get released. As we > believe that shorter freeze period are better for the spirit of > contributors to Debian, we'd like to avoid such an unnecessary delay > again, and we'd want to pick a tentative release date. We call it > tentative, because it would be the date where we do the bullseye > release assuming that the identified issues are resolved by then and > that we don't find new blocking issues between now and two weeks > before that proposed date. So, the date would not be the set-in-stone > release date, but obviously it would become more solid as we get near > it. > > We propose to aim for a release date in May. Would either of the > following work for you and do you have any preference? > - May 1 > - May 8 > - May 15 > - May 22 > - May 29 As it stands, the later the better. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 10.9 planning
Adam D. Barratt (2021-03-15): > - March 27th > - April 3rd > - April 10th All of the above. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 10.8 planning
Adam D. Barratt (2021-01-16): > Please could you confirm your availability, and any preferences, for > the following: > > - January 30th (would mean we would have to freeze next weekend, so > a bit tight) > - February 6th > > My personal preference would be the 6th. Me too. But I can do both if needs be. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 10.7 planning
Hi, Adam D. Barratt (2020-10-30): > In an attempt to be slightly more efficient than usual at planning a > point release... it's about a month since 10.6, so let's start looking > at dates for 10.7. > > Please could you confirm your availability, and any preferences, for > the following: > > - November 21st > - November 28th > - December 5th I should be able to accomodate any date you pick. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 10.6 planning
Hi, Adam D. Barratt (2020-09-09): > We're slightly off our previous schedule because of delaying 10.5, but > we should really get on with arranging 10.6. > > Please could you confirm your availability, and any preferences, for > the following: > > - September 26/27 > - October 3/4 I should be able to accomodate whatever date gets picked. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: stretch EOL point release (9.13) and 10.5 planning
Adam D. Barratt (2020-07-18): > Now that stretch EoL is (more or less) out of the way, it would be good > to get 10.5 done as soon as we sensibly can, so as not to slip too far > off schedule. > > Next weekend is probably a little too soon - I'd at least like to not > jump straight back into freezing - but how about one of: > > - August 1st/2nd > - August 8th/9th Both should work equally for me regarding the installer. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: stretch EOL point release (9.13) and 10.5 planning
Hi, Adam D. Barratt (2020-06-15): > stretch transitions from oldstable-with-security-support to LTS support > on Saturday July 4th. As usual, we should aim for the final point > release to be soon after that, most likely pulling in any remaining > updates from security.d.o that are still in oldstable-new. > > I think Saturday July 11th makes most sense (so freezing opu during the > transition weekend), but we could potentially stretch (no pun intended) > slightly further if need be. > > We also need to look at the next buster point release in a similar > timeframe. Can anyone see a reason not to do the two at the same time, > as usual? > > To get the ball rolling, please could you confirm your availability > for: > > - July 11/12 > - July 18/19 Haven't looked at stretch in a while from a d-i point of view, but I don't think we have any bugfixes pending? I'll have to check what's happening on the buster front, if anything. Anyway, I should be available, whatever date(s) get picked. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Default security sources are slow very much.
Hi, ykla (2020-02-05): > OK, the install cd ask me to change mirrors to download somethings but not > changes security sources. Default source is http://security.debian.org/ > that is slow very much, about 1kb/s on my area. Please change security > sources when os changes main source or ban security while installing > system. You can disable the security sources by using the expert install. You can also set apt-setup/security_host to something else if needed. You can also tweak apt-setup/services-select to exclude security if needed. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Weekly Builds should be more robust
Hi Daniel, Daniel Lewart (2019-11-18): > Debian CD [sic] Group, > > Weekly builds haven't run successfully recently: > * Nov 4 Daily Failed > * Nov 11 Daily Failed > * Nov 18 Building 10.2 > > These failures are too common and affect those of us who are trying to > use Testing from USB flash drives. > > Could the weekly live cron job be changed to a daily one that builds > things either: > * Mon > * Tue-Sun only if there has been no success since Mon > > This would greatly improve things when problems arise, > without any manual intervention. Or you could just use alpha releases of the Debian Installer. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Flawless Accessible Installation onto Old Thinkpad (X60 I think)
Hi Sam, Thanks for your report; forwarding to debian-accessibility@ and debian-boot@ for their information. Sam Hartman (2019-12-20): > This is written as a thank you, and there are no actionable bits. > So mail not a bug report to installation-reports. > > I had an old laptop and I needed to be able to give someone a computer > to use to do office work. So I booted a 10.2.0 amd64 firmware netinst. > I needed help selecting the boot device, but that's not Debian's > problem. > I pressed s at the installation prompt and got speech as expected. > > Everything worked fine, and I got an accessible system after the > reboot. > > I realize a lot of effort goes into makeing that happen, and it is > greatly appreciated. > > I was even able to install over an encrypted wifi connection. > > > Thanks so much. > > --Sam Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: 10.4 planning
Adam D. Barratt (2020-04-06): > I realise things are a little unusual right now, but it's about time > that we started looking at dates for 10.4. > > I guess the biggest impact of current circumstances on the process is > likely to be around image testing, as there won't be a bunch of people > with local access to Steve's mirror. > > I've listed some potential dates below; as usual, please indicate which > you would be available for. > > - April 25th > - May 2nd > - May 9th All those should be just fine for me, thanks for asking. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
Re: Planning 10.3 and 9.12
Adam D. Barratt (2020-01-06): > It's (really past) time to consider a date for the next point releases > for buster and stretch. > > I've listed some suggested dates below; please indicate which you would > be available for. > > - January 25th > - February 1st > - February 8th > - February 15th Any time should be fine by me. Cheers, -- Cyril Brulebois (k...@debian.org)<https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant signature.asc Description: PGP signature
