Re: Keeping choose-mirror updated
Hi, On Thu, 2024-08-22 at 21:39 +0100, Adam D. Barratt wrote: > I've also prepared 2.111+deb11u1, but not yet uploaded it as the > debdiff ends up as: > > Mirrors.masterlist | > + > - > -- > debian/changelog | 7 > 2 files changed, 1394 insertions(+), 3057 deletions(-) > > The diff doesn't obviously look crazy, but it is clear that the > current package in bullseye is from before the masterlist repository > served as an input for the mirror-status system, which then produces > the published version of Mirrors.masterlist. That accounts for a > chunk of the diff, together with 3 years worth of data changes. Indeed, the changelog for 2.111 makes it clear that the switch was imminent. I've now uploaded the bullseye package, so that it's available. If you're not comfortable with it then please feel free to apply the relevant pinning for the d-i build. Regards, Adam
Re: Keeping choose-mirror updated
Hi, On Wed, 2024-08-14 at 22:15 +0200, Cyril Brulebois wrote: > Hi Adam, > > Adam D. Barratt (2024-08-14): > [...] > > I'd like to suggest that we get in the habit of updating the > > choose-mirror package more often, in order to provide a more > > current mirror list to d-i users. Most changes to the package > > consist of updates to the mirror list, or to translations of the > > included Debconf templates. [...] > I'm not sure which version to start from (current version in stable > or an initial backport from unstable — unless there's a compelling > reason for the latter, I'd rather go for the former, having had 0 > looks at all at this point), but it seems to me we could just > increment the version in stable, independently from what's happening > (or not) in unstable? Thanks for the reply. I've so far prepared and uploaded 2.126 (unstable) and 2.123+deb12u1 (bookworm). I've also prepared 2.111+deb11u1, but not yet uploaded it as the debdiff ends up as: Mirrors.masterlist | +--- debian/changelog |7 2 files changed, 1394 insertions(+), 3057 deletions(-) The diff doesn't obviously look crazy, but it is clear that the current package in bullseye is from before the masterlist repository served as an input for the mirror-status system, which then produces the published version of Mirrors.masterlist. That accounts for a chunk of the diff, together with 3 years worth of data changes. Regards, Adam
Re: Bug#1076831: bookworm-pu: package glibc/2.36-9+deb12u8
Control: tags -1 + confirmed On Tue, 2024-07-23 at 22:50 +0200, Aurelien Jarno wrote: > [ Reason ] > The upstream glibc stable branch got a fixes since the last stable > updates. This hasn't been missed in the last point release, so the > number of fixes is slightly higher than usual. Please go ahead. Regards, Adam
Keeping choose-mirror updated
Hi, choose-mirror is the d-i component responsible for presenting users with a list of available mirrors from which packages can be installed. The list it provides is periodically updated based on the "masterlist" maintained by the Mirrors Team. I'd like to suggest that we get in the habit of updating the choose- mirror package more often, in order to provide a more current mirror list to d-i users. Most changes to the package consist of updates to the mirror list, or to translations of the included Debconf templates. Assuming that people are happy with the idea, a few questions on how we go about it: - Would it be preferred that updates follow the usual path of an upload to unstable followed by backports to stable and (when supported) oldstable? I've presumed that d-i won't have any issues with ~debXuY versions for udeb packages. - From the Release Team side, would people want p-u bugs filing each time, or could choose-mirror be considered to have a semi-permanent exception? For reference, the delta between the stable and unstable packages is currently the mirror list and a single translation update. The package ns oldstable is rather older, and the other changes from that version to unstable are: Makefile |5 debian/choose-mirror-bin.templates.http-in |1 debian/gbp.conf|2 debian/salsa-ci.yml|6 intltool-merge | 1369 --- mirrorlist | 39 - mktemplates|2 This is largely: + * debian/choose-mirror-bin.templates.http-in: Enable partial translation for +country list. + * mktemplates: Do not use our own intltool-merge. + * intltool-merge: Drop. [...] + * Sort deb.debian.org first, then ftp*.*.debian.org, then others. Opinions / objections / octopuses welcome. Regards, Adam
Re: Regression for 11.10 (was: d-i for 12.6 and 11.10)
On Mon, 2024-06-24 at 21:55 +0200, Cyril Brulebois wrote: > Cyril Brulebois (2024-06-24): > > I'm not seeing this with netboot's mini.iso, so usual suspects > > would > > be the GTK stack, the X stack, and the kernel. > > Instead: Have you tried turning kibi off and on again? > > Sorry for the PEBCAK and the heightened blood pressure. Are there more bugs that we can fix by rebooting kibis? Thanks for the update and the quick turnaround. Regards, Adam
Re: Regression for 11.10 (was: d-i for 12.6 and 11.10)
Hi, On Mon, 2024-06-24 at 19:30 +0200, Cyril Brulebois wrote: > I'm afraid I have bad news regarding the graphical installer for > bullseye: once past ISOLINUX in BIOS mode, the screen goes black, and > stays black. Pressing any key makes the language selection screen pop > up out of the shadows anyway, but what a terrible user experience… we > *might* be able to accept (and document) the regression, but I would > prefer *not* to do that… Bah. :-( > Adam, what timeframe are you comfortable with, to give me some time > to figure that out? (i.e. d-i/bullseye must be uploaded before ___?) I think we could stretch to Wednesday evening if need be, but much beyond that would start to get difficult with having to go through the dini cycle as well and get the prep work out the way. Thanks for letting us know and for your work on this so far. Regards, Adam
Re: Planning for 12.7/11.11
On Thu, 2024-06-20 at 22:35 +0100, Jonathan Wiltshire wrote: > - Saturday 17th August: this would mean freezing on the 10th, before > security support ends, so the security team's cooperation in > keeping non-critical DSAs off the table during the freeze period > would be required > > - Saturday 31st August: it's later than ideal, leaving a gap before > LTS starts work, but that may be unavoidable. Either of these should work for me. Regards, Adam
Re: Bug#1070155: bullseye-pu: package wpa/2.9.0-21+deb11u1
Control: severity -1 normal Control: tags -1 + confirmed On Tue, 2024-04-30 at 23:31 +, Bastien Roucariès wrote: > [ Reason ] > CVE-2023-52160 security bug Please go ahead. Regards, Adam
Re: Bug#1070151: bookworm-pu: package wpa/2:2.10-12
Control: severity -1 normal On Tue, 2024-04-30 at 23:03 +, Bastien Roucariès wrote: > Package: release.debian.org > Severity: important > p-u requests are always "normal"; fixed. > [ Reason ] > CVE-2023-52160 security bug Please go ahead. Regards, Adam
Re: Planning for 12.6/11.10
press@ - please could you comment on the dates proposed below Thanks, Adam On Mon, 2024-05-27 at 13:07 +0100, Jonathan Wiltshire wrote: > Hi, > > The final bullseye point release 11.10 (and therefore also 12.6 for > versioning) should be soon after 10th June, when security team > support > will end. > > Please indicate availability for: > > Saturday 15th June > Saturday 22nd June > Saturday 29th June > > Thanks, >
Re: Planning for 12.6/11.10
On Mon, 2024-05-27 at 13:07 +0100, Jonathan Wiltshire wrote: > The final bullseye point release 11.10 (and therefore also 12.6 for > versioning) should be soon after 10th June, when security team > support > will end. > > Please indicate availability for: > > Saturday 15th June > Saturday 22nd June > Saturday 29th June Any of these should work for me currently, but I would prefer either the 22nd or 29th. Regards, Adam
Re-planning for 12.6
Hi, As we had to postpone 12.6, let's look at alternative dates. April 13th - Not great for me for personal reasons, mhy previously said no. I could probably do if need be April 20th - Doesn't work for me; I'm away from the Tuesday before until late on the Friday April 27th - Doesn't work for me; I have a pre-existing appointment which means I'll be AFK much of the day May 4th - Apparently doesn't work for me; long weekend in the UK May 11th - Should work for me Regards, Adam
Re: Upcoming stable point release (12.6)
On Fri, 2024-02-16 at 17:35 +, Jonathan Wiltshire wrote: > The next point release for "bookworm" (12.6) is scheduled for > Saturday, April 6th. Processing of new uploads into bookworm- > proposed-updates will be frozen during the preceeding weekend. Due to recent events, the point release has been postponed. A new date will be announced when possible. Regards, Adam
Re: Planning for 12.6
On Mon, 2024-02-12 at 18:04 +, Jonathan Wiltshire wrote: > 12.6 should be around 10th April, so please indicate availability > for: > > 7 April I assume you mean the 6th here. That should be doable. > 13 April Could work, but I would prefer not to for personal reasons. > 20 April I'll be returning from time abroad probably late the day before, so no from me. Regards, Adam
Upcoming oldstable point release (11.9)
Hi, The next point release for "bullseye" (11.9) is scheduled for Saturday, February 10th. Processing of new uploads into bullseye-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Upcoming stable point release (12.5)
Hi, The next point release for "bookworm" (12.5) is scheduled for Saturday, February 10th. Processing of new uploads into bookworm-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: Planning for 12.5/11.9
On Tue, 2023-12-19 at 21:25 +, Jonathan Wiltshire wrote: > It's time to set a date for 12.5 (taking account of the emergency .4) > and 11.9. I expect this to be the penultimate update for bullseye > before LTS. > > Please indicate availability for: > > Saturday 3rd February (preferred for cadence) > Saturday 10th February > Saturday 17th February It looks like any of those should work for me ATM. I'd slightly prefer not to go for the 3rd. Regards, Adam
[rt.debian.org #9382] Upgrade dillon to bullseye
Hi, The upgrade is now done. Please let DSA know (preferably either on IRC in #debian-admin or via a new ticket) if you spot any issues. Regards, Adam
[rt.debian.org #9382] Upgrade dillon to bullseye
On Sun Nov 19 07:53:22 2023, hwans...@mailbox.org wrote: > Hi, > > Am 19. November 2023 02:05:46 MEZ schrieb Cyril Brulebois > : > > Hi Adam, > > > > Adam D. Barratt via RT (2023-11-18): [...] > >> The d-i.debian.org metapackage fails to install on bullseye, because > >> it depends on ko.tex-base, which no longer exists in bullseye. The > >> removal notice suggests that its replacement is texlive-lang-korean, > >> which the metapackage already depends on for a few years now, so > >> hopefully dropping ko.tex-base shouldn't be an issue. > > > > That was an installation-guide dependency, removed in 2017, first > > released in 20180603: > > https://salsa.debian.org/installer-team/installation-guide/- > > /commit/3aa082a832ed636874995bf9e7bd25d0910c3365 > > > > Some more cleanup might be possible in there, but if you can build a > > package that's installable again right away, let's do that. Thanks, I've updated the metapackage to remove that dependency. > >> Do you see any issues with the upgrade from a d-i perspective? Are > >> there any particularly good times to do the upgrade, or that you'd > >> prefer to avoid? > > > > I'm less used to keeping an eye on the l10n machinery than Holger > > does, > > so you might want to wait for an explicit ACK there, but the rest I > > can > > probably check and fix/adjust as needed once the upgrade happens. > > > > No particular constraints on my side, thanks for asking. > > Yes, please go ahead at your own schedule Great, thanks both. Regards, Adam
Re: Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3
On Sat, 2023-11-18 at 16:21 +0100, Cyril Brulebois wrote: > Scott Talbert (2023-11-16): > > > Scott Talbert (2023-11-13): > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: binnmu > > > > X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org > > > > Control: affects -1 + src:libalien-wxwidgets-perl > > > > > > > > nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . - > > > > m "Rebuild for wxwidgets3.2 (3.2.4+dfsg-1)" > > > > > > This looks like a redux of #1054146, with libwx-perl also needing > > > a > > > binNMU (after the libalien-wxwidgets-perl one)? > > > > Yeah, I did at least file both at the same time this round though > > :) > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055908 > > I was trying to suggest filing both in the same request, to have them > scheduled in one go. Yes, please. #1055908 also doesn't mention the dependency between the binNMUs. > In any case, actually binNMUing both packages would be nice, as we've > been lacking d-i daily builds for some days already. Done. Regards, Adam
[rt.debian.org #9382] Upgrade dillon to bullseye
Hi kibi, -boot, I'd like to look at upgrading dillon to bullseye in the not-too-distant future. The d-i.debian.org metapackage fails to install on bullseye, because it depends on ko.tex-base, which no longer exists in bullseye. The removal notice suggests that its replacement is texlive-lang-korean, which the metapackage already depends on for a few years now, so hopefully dropping ko.tex-base shouldn't be an issue. Do you see any issues with the upgrade from a d-i perspective? Are there any particularly good times to do the upgrade, or that you'd prefer to avoid? Regards, Adam
Upcoming stable point release (12.3)
Hi, The next point release for "bookworm" (12.3) is scheduled for Saturday, December 9th. Processing of new uploads into bookworm-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: Planning for 12.3
On Thu, 2023-11-09 at 14:55 +, Steve McIntyre wrote: > On Fri, Oct 27, 2023 at 11:28:21AM +0100, Steve McIntyre wrote: > > Argh, forgot to respond to this. :-( > > > > On Sat, Oct 07, 2023 at 06:59:03PM +0100, Jonathan Wiltshire wrote: > > > Hi, > > > > > > The next point release for bookworm should be around the end of > > > November > > > 2023. We're about a week behind cadence anyway, but I already > > > know the 28th > > > November will be unsuitable (Cambridge mini-debconf) and the > > > weekend > > > following is probably recovery time for a lot of people. > > > > > > Much after that we get into holidays and well off cadence. > > > > > > How about: > > > 4th December (better for cadence) > > > 11th December (more likely suitable in practice) > > > > Both of those currently look feasible for me. > > Do we have a decision being made yet please? Assuming everyone's still OK with their previous responses, it looks like we're going for December 9th. (Not the 11th, as Jonathan apparently fails at using a calendar.) If anyone's not happy with that, please yell *soon*. Regards, Adam
Re: Planning for 12.3
On Sat, 2023-10-07 at 21:59 +0100, Jonathan Wiltshire wrote: > On Sat, Oct 07, 2023 at 06:59:03PM +0100, Jonathan Wiltshire wrote: > > How about: > > 4th December (better for cadence) > > 11th December (more likely suitable in practice) > > Erm, astute readers will realise the 4th and 11th are Saturdays in > November, not December. The correct proposals should be: > > 2nd December (better for candence, no-go for me) > 9th December (more likely suitable in practice) > Sorry for not replying sooner. I'd prefer not the 2nd, because that means handling the freeze while at miniconf. The 9th should be OK. Regards, Adam
Re: Bug#1051884: bullseye-pu: package openssl/1.1.1w-0~deb11u1
On Wed, 2023-09-13 at 22:48 +0200, Sebastian Andrzej Siewior wrote: > OpenSSL upstream released 1.1.1w which the last stable update to the > 1.1.1 series because it is EOL since last Monday. > The update is fairly small and contains a few fixes for memory leaks. > The mentioned CVE affects only Windows. > Unfortunately, the version format change from -0+deb11uX to -0~deb11uX has broken the installer. The udebs end up with dependencies of the form ">= 1.1.1w", which 1.1.1w-0~deb11u1 doesn't fulfil. Assuming I'm not missing anything, could we have an upload that uses the -0+ style of versioning ASAP, please? Regards, Adam
Re: Bug#1053130: bookworm-pu: package glibc/2.36-9+deb12u2
Control: tags -1 confirmed On Wed, 2023-09-27 at 23:47 +0200, Aurelien Jarno wrote: > The upstream glibc stable branch got a few fixes since the latest > point > released, including two security fixes. > Please go ahead. Regards, Adam
Bug#784811: d-i.debian.org: rmadison on dillon fails because of certificate checks
On Sat, 2015-05-09 at 05:02 +0200, Cyril Brulebois wrote: > Cyril Brulebois (2015-05-09): > > I've crafted a patch and I'll block this bug report with it; I > > might set > > up some workaround until this is resolved in a proper way. > > That's #784812. > > Local changes in dillon include: > - mailing kibi@d.o instead of debian-boot@, because debugging and > other >annoyances listed as d-i.debian.org bug reports; I don't want more >junk to be sent to the list. > - hardcoded paths in an additional $ua->ssl_opts(…) call, because >rmadison isn't the only one which needs to be told about the CA > path. > - calling ./rmadison instead of /usr/bin/rmadison, so that #784812 >isn't a blocker. > For the record, #784812 was resolved a couple of months after the above. All debian.org hosts should also now be able to run tools such as rmadison without needing any special configuration. I'm not closing the bug, as it's not clear to me from the above whether there are changes which might want to be reverted on the d-i.d.o side. Regards, Adam
Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
Package: debootstrap Version: 1.0.128+nmu3 Severity: grave bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the aliased-dirs scheme. While it's currently the default scheme for non-buildd systems, it is both not supported by dpkg (with no solution in sight), but is also likely to produce packages that are explicitely forbidden by a recent CTTE ruling that disallows moving files between directories aliased by the current usrmerge scheme. Quoting the still unsolving issues is pointless (you can read about them in massive threads in a number of places) as bluca seems to be ignoring them completely. But, what matters here is the CTTE ruling in #1035831 -- for the time being, packages must not move files between locations affected by the aliasing. Packages built in an usrmerged chroot place such files under /usr while built without usrmerge into whatever place they were installed to -- which is a direct breach of the ruling. Thus, that change needs to be reverted for now, and all packages built with 1.0.128+nmu3 need to be either rebuilt or at least checked for such a violation (as most are unaffected). Meow! -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debootstrap depends on: ii wget 1.21.3-1+b2 Versions of packages debootstrap recommends: ii arch-test 0.21-1 ii debian-archive-keyring 2023.3 ii gnupg 2.2.40-1.1 Versions of packages debootstrap suggests: ii binutils 2.40.90.20230705-1 pn squid-deb-proxy-client ii ubuntu-archive-keyring 2020.06.17.1-1 ii ubuntu-keyring [ubuntu-archive-keyring] 2020.06.17.1-1 ii xz-utils 5.4.1-0.2 ii zstd 1.5.5+dfsg2-1 -- no debconf information
Re: Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1
On Thu, 2023-07-13 at 17:51 +0100, Simon McVittie wrote: > On Thu, 13 Jul 2023 at 16:58:54 +0100, Adam D. Barratt wrote: > > On Wed, 2023-07-12 at 12:34 +0100, Simon McVittie wrote: > > > On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote: > > > > [ Reason ] > > > > https://bugs.debian.org/1040790 > > > > Please go ahead, bearing in mind that the window for 12.1 closes > > over > > the coming weekend. > > I uploaded it already, it's in > <https://release.debian.org/proposed-updates/stable.html>;. The > corresponding unstable update should reach testing tomorrow. > Heh, that'll teach me to catch up on e-mail before reviewing the queue. > I'm sorry for the timing. I fixed it as fast as I was able, as soon > as I was aware of the issue (I know both should have happened > quicker). > FTAOD, it absolutely wasn't a complaint, rather just making sure you were aware of the date. Regards, Adam
Re: Bug#1040868: bookworm-pu: package glibc/2.36-9+deb12u1
Control: tags -1 + confirmed On Tue, 2023-07-11 at 20:51 +0200, Aurelien Jarno wrote: > The upstream stable branch got a few fixes during the bookworm freeze > period, and this update pulls them into the debian package. In short: > - Fix a buffer overflow and memory corruption in the gmon >functionality. > - Fix a deadlock in getaddrinfo() and system() functions > - Fix y2038 support in strftime on 32-bit architectures. > - Fix possible segmentation fault in applications using sgetsgent() >when /etc/gshadow contains very long lines > - Fix support for old C90 compilers. > > In addition this include a Slovak translation update fixing typos, > that > Please go ahead, bearing in mind that the window for 12.1 closes over the coming weekend. Regards, Adam
Re: Bug#1040915: bookworm-pu: package dbus/1.14.8-2~deb12u1
Control: tags -1 + confirmed On Wed, 2023-07-12 at 12:34 +0100, Simon McVittie wrote: > On Wed, 12 Jul 2023 at 12:12:47 +0100, Simon McVittie wrote: > > [ Reason ] > > https://bugs.debian.org/1040790 > > [ Changes ] > > All changes are part of resolving or testing #1040790. > > Debdiff attached. > > > [ Tests ] > > I should also have mentioned that I'm running the proposed package on > a bookworm desktop system and it works normally. > Please go ahead, bearing in mind that the window for 12.1 closes over the coming weekend. Regards, Adam
Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer
On Sun, May 21, 2023 at 07:35:36AM +0200, Cyril Brulebois wrote: > Adam Borowski (2023-05-20): > > The JFS filesystem is deprecated in the kernel: on life support since 2009 > > and with talks of removal altogether. Thus, we really shouldn't offer to > > format new setups with it. There are people who kind-of remember JFS being > > the fastest back in the day, and it's irresponsible to set them for failed > > upgrades past Bookworm. > > > > Thus: please remove JFS from the installer. > > It doesn't seem reasonable to do that weeks away from the release, without > any kind of heads-up. That can be done during the Trixie release cycle, > e.g. in Alpha 1. Aye, sorry for having distracted you during the most busy time. I filed the bug when I learned about plans of giving JFS the axe. > Feel free to ping this bug report a few weeks/months into the next release > cycle So... it might be a better time now. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Ash nazg durbatulûk, ⣾⠁⢠⠒⠀⣿⡁ ash nazg gimbatul, ⢿⡄⠘⠷⠚⠋⠀ ash nazg thrakatulûk ⠈⠳⣄ agh burzum-ishi krimpatul.
Re: 11.8 planning
Hi Donald, On Wed, 2023-06-21 at 06:33 -0400, Donald Norwood wrote: > Hi, > > On 6/20/23 13:15, Adam D. Barratt wrote: > > The traditional cadence for oldstable point releases is four > > months, > > rather than two. That technically means that 11.8 would be due > > somewhere in late August to mid-September. So we could either punt > > 11.8 > > so it aligns with 12.2 rather than 12.1, or do 11.8 together with > > 12.1 > > and then align 11.9 with 12.3. > > ... > > The 1st would mean freezing this coming weekend, which is very > > tight. > > > > As per the 12.1 mail, either the 8th or 15th would work for me, > > with a > > preference for the latter. Given the explanation above though, I > > think > > the 22nd would be fine for 11.8 as well. > > I think pushing everything forward at this time would be advisable > as several people have indicated that they need a breather. A slight > delay may be ideal. I'm assuming you mean what at least in en_GB is normally referred to as "pushing things back" - i.e. making things later than suggested. Did you just mean that we should opt for the later of the dates suggested (July 22nd), or did you have something else in mind? Regards, Adam
Re: 11.8 planning
On Mon, 2023-06-19 at 22:02 +0100, Jonathan Wiltshire wrote: > 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: > As we discussed on IRC, when we have both stable and oldstable point releases to do, they should happen on the same day. Otherwise, version skew from packages such as browsers and OpenJDK causes us more work (e.g. openjdk-17 is already at opu > stable). Not that it's directly relevant to this discussion, but the stable point release should also always be first - both because it resolves the version skew more neatly, and because it means the images team can get started on handling stable while the rest of us deal with oldstable. The traditional cadence for oldstable point releases is four months, rather than two. That technically means that 11.8 would be due somewhere in late August to mid-September. So we could either punt 11.8 so it aligns with 12.2 rather than 12.1, or do 11.8 together with 12.1 and then align 11.9 with 12.3. I think I'd prefer the latter option, i.e. we do 11.8+12.1 in July, 12.2 probably September, then 11.9+12.3 Novemberish. > 1st July > 8th July > 15th July at a push The 1st would mean freezing this coming weekend, which is very tight. As per the 12.1 mail, either the 8th or 15th would work for me, with a preference for the latter. Given the explanation above though, I think the 22nd would be fine for 11.8 as well. Regards, Adam
Re: 12.1 planning
On Mon, 2023-06-19 at 22:04 +0100, Jonathan Wiltshire wrote: > The promised 4-6 weeks following release for 12.1 looks like: > > 8th July (4) > 15th July (5) > 22nd July (6) > Any of those should work for me. I'd prefer one of the latter two. > 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. That's not entirely accurate, but I'll expand in the 11.8 thread. Regards, Adam
Bug#1036400: partman-jfs: JFS is on its way out, please remove from the installer
Package: partman-jfs Severity: important Hi! The JFS filesystem is deprecated in the kernel: on life support since 2009 and with talks of removal altogether. Thus, we really shouldn't offer to format new setups with it. There are people who kind-of remember JFS being the fastest back in the day, and it's irresponsible to set them for failed upgrades past Bookworm. Thus: please remove JFS from the installer. Meow!
Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP
I used "Guided - use entire disk and set up encrypted LVM" On April 25, 2023 12:55:27 PM CDT, Pascal Hambourg wrote: >Hello, > >On 25/04/2023 at 01:29, Adam wrote: >> >> I installed from a thumb drive, to another thumb drive, on a computer >> that had an nvme drive that should not have been touched. The installer >> overwrote data on the nvme drive despite the target being /dev/sda. I >> manually mounted the installed system (the target thumb drive) on another >> computer, figured out what happened (ESP was empty) and fixed it so I could >> submit a bug report from the thumb drive that failed to install properly. >> >> This is similar to the other UEFI installation problems, but it did >> not install to the MBR, and it did not install any files on the correct >> ESP, thus is is a separate issue. >> >> The smoking gun for understanding what went wrong was in /etc/fstab, where >> there were two comments: >> >> # /boot was on /dev/sda2 during installation >> # /boot/efi was on /dev/nvme0n1p1 during installation > >From the partition layout I assume you used guided partitioning with LVM >(without encryption). Guided partitioning is supposed to not use any >partitions outside the selected disk by calling clean_method() defined in >partman-auto/lib/recipes.sh. This is what I observe with non-LVM schemes, but >the two LVM schemes have issues. Here is a summary of my observations: > >Guided - use the largest continuous free space > calls clean_method() in partman-auto/autopartition > does not run partman-efi/init.d/efi > does not use existing EFI or swap partitions on other disks (good) > >Guided - use entire disk > calls clean_method() in partman-auto/autopartition > does not run partman-efi/init.d/efi > does not use existing EFI or swap partitions on other disks (good) > >Guided - use entire disk and set up LVM > does not call clean_method() > runs partman-efi/init.d/efi > uses existing EFI and swap partitions on other disks (bad) > >Guided - use entire disk and set up encrypted LVM > calls clean_method() in partman-auto-crypto/autopartition-crypto > runs partman-efi/init.d/efi > uses existing EFI partitions on other disks (bad) > does not use existing swap partitions on other disks (good) > >partman-efi/init.d/efi detects possible EFI partitions and sets method "efi" >on them. > >As you can see, the issue also affects swap partitions (and they will be >reformatted with new UUIDs, which can be harmful if they are used by another >system). > >Note: partman-auto-lvm used to call clean_method() in lib/auto-lvm.sh but it >was removed by commit cfc6797f6f561b87069160ba7c375c5b487b7c1e with code >factoring. > >Suggested fix is two-fold: > >1) Call clean_method() at the beginning of partman-auto-lvm/autopartition-lvm, >as is done in partman-auto/autopartition and >partman-auto-crypto/autopartition-crypto. This should solve the issue for swap >partitions but is not enough for ESPs. > >2) In partman-efi/init.d/efi, set method "efi" only once, as is done with swap >partitions in partman-basicfilesystems/init.d/autouse_swap. >I already submitted two patch versions for #1034208 "Partman may reset user's >choice for ESP partitions use" as a follow-up to Steve's latest fixes for >#834373 and #1033913. > >Caveat: I don't know if these changes could have any negative impact on >preseeded automatic partitioning. -- Sent from my iPod. Please excuse my brevity.
Bug#1034812: installation-reports: Unbootable after install: UEFI installed to wrong ESP
Package: installation-reports Severity: normal X-Debbugs-Cc: a...@hax0rbana.org (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: USB Image version: Bullseye Date: 04/23/2023 Machine: Home built PC Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on udevdevtmpfs 39688200 3968820 0% /dev tmpfs tmpfs 799096 1360797736 1% /run /dev/mapper/thumbdrive--vg-root ext4 116178928 28347284 81883844 26% / tmpfs tmpfs 39954720 3995472 0% /dev/shm tmpfs tmpfs 51204 5116 1% /run/lock /dev/sda2 ext2481642 118611338046 26% /boot /dev/sda1 vfat52324436784486460 8% /boot/efi tmpfs tmpfs 799092 76799016 1% /run/user/1000 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [O] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[E] Comments/Problems: I installed from a thumb drive, to another thumb drive, on a computer that had an nvme drive that should not have been touched. The installer overwrote data on the nvme drive despite the target being /dev/sda. I manually mounted the installed system (the target thumb drive) on another computer, figured out what happened (ESP was empty) and fixed it so I could submit a bug report from the thumb drive that failed to install properly. This is similar to the other UEFI installation problems, but it did not install to the MBR, and it did not install any files on the correct ESP, thus is is a separate issue. The smoking gun for understanding what went wrong was in /etc/fstab, where there were two comments: # /boot was on /dev/sda2 during installation # /boot/efi was on /dev/nvme0n1p1 during installation This matches the fact that it left my nvme drive unbootable unless I manually go into the boot menu and select the nvme drive every time. Failing to do so results in a grub failure. I have also repeated this on another computer (mac mini 2019) and was able to reproduce these results, so I can confirm that it is not an issue unique to my BIOS. That left a second computer unbootable short of manually going into the boot menu and selecting the desired device on every boot. I marked this as "normal" because installing onto a thumb drive and having another disk in the computer which has an ESP is not a common use case. It may be reasonable to increase the severity considering it overwrites a disk that should not have been touched, leaving two systems unbootable (in my case: the nvme drive and the USB drive). -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u7+b1" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux thumbdrive 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU [1022:1481] lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] lspci -knn: 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] lspci -knn: 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] lspci -knn: 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] lspci -knn: Kernel dr
Bug#1034750:
I know this is the wrong way to do it, but d-i pkgsel/run_tasksel boolean false in my preseed.cfg was the easiest way for me to fix it. Just the d-i netcfg/choose_interface select auto problem to go now. This is possibly the wrong thread for it, IMO there needs to be a simple way to copy the SSH key/s provided by d-i network-console/authorized_keys_url to any/all created user accounts during installation, especially if I have d-i passwd/root-login boolean false set.
Bug#1034750: installation-reports: Automated install worked, but installed full desktop environment
Package: installation-reports Severity: minor X-Debbugs-Cc: deb...@voltagex.org (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: USB Image version: debian-bookworm-DI-rc1-amd64-netinst.iso + custom grub.cfg Date: 2023-04-23 Machine: Beelink U59 Pro Partitions: Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs 8038444 0 8038444 0% /dev tmpfs tmpfs 16147241604 1613120 1% /run /dev/sda2 ext4 489634808 4980640 459708660 2% / tmpfs tmpfs 8073612 0 8073612 0% /dev/shm tmpfs tmpfs 5120 12 5108 1% /run/lock /dev/sda1 vfat5232445948517296 2% /boot/efi tmpfs tmpfs 1614720 64 1614656 1% /run/user/113 tmpfs tmpfs 1614720 52 1614668 1% /run/user/1000 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[OE] Configure network: [OE] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[OE] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: The installer says it tries to automatically select the network card with an active link, but I am not sure this worked correctly. The machine has 2 Ethernet ports plus wifi, all were detected correctly but the installer selected the wireless interface as the default. (and d-i netcfg/choose_interface select auto didn't seem to work). A full desktop environment was installed without prompting but I think this is a side effect of using priority=critical as a boot parameter. Please make sure that any installation logs that you think would be useful are attached to this report. (You can find them in the installer system in /var/log/ and later on the installed system under /var/log/installer.) Please compress large files using gzip. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="12 (bookworm) - installer build 20230401" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux BeeMovie 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-1 (2023-03-19) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4e24] lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation JasperLake [UHD Graphics] [8086:4e61] (rev 01) lspci -knn: DeviceName: Onboard - Video lspci -knn: Subsystem: Intel Corporation Device [8086:2212] lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Dynamic Tuning service [8086:4e03] lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:4ded] (rev 01) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Device [8086:4def] (rev 01) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:15.0 Serial bus controller [0c80]: Intel Corporation Serial IO I2C Host Controller [8086:4de8] (rev 01) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:15.1 Serial bus controller [0c80]: Intel Corporation Serial IO I2C Host Controller [8086:4de9] (rev 01) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:15.2 Serial bus controller [0c80]: Intel Corporation Device [8086:4dea] (rev 01) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:15.3 Serial bus controller [0c80]: Intel Corporation Device [8086:4deb] (rev 01) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Management Engine Interface [8086:4de0] (rev 01) lspci -knn: DeviceName: Onboard - Other lspci -knn: Subsystem: Intel Corporation Device [8086:7270] lspci -knn: 00:17.0 SATA controller [0106]: Intel Corpo
Re: 11.7 planning + bookworm planning
Hi, Sorry for taking so long to get back to the dates question. I hope to also have a useful reply to your other mail by the end of this weekend. On Thu, 2023-04-20 at 11:32 +0200, Paul Gevers wrote: > On 13-04-2023 11:29, Paul Gevers wrote: > > For me to do the release, I'd need to get my hands on the key. > > I'm in contact with Jonathan and we're convinced we'll be able to > get the key to me in time. > As mentioned previously, there'll need to be signatures from each of the bookworm, bullseye and buster keys on the day. > Which leaves finding a date (and me learning what to do :) ). > > We have (if earlier mentioned dates still work for those involved): > May | June > > kibi - 13, 20, 27 d-i > > 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. The 13th does seem a bit close now, without having announced. I could do it if that's the decision, although I will be away the week before (returning home some time on the 12th). I'm afraid I don't really have a feel for how "ready" things would be by then. It looks like I could currently do any Saturday from May 13th onwards, until the end of June. I have a slight preference for avoiding the weekend of June 3rd if possible. One other thing of note is that, unless I've missed some mail, there's no press / publicity team member confirmed as available, which is really a requirement. Regards, Adam
Bug#1034562: installation-reports: "Works", graphical corruption & flashing once in Gnome
On Wed, 19 Apr 2023, at 05:58, Roland Clobus wrote: > Hello Adam, > > I've seen some issues on openQA which run on AMD hardware, but I > personally only have Intel processors, so I cannot reproduce such > issues. [1] > > Can you confirm that the microcode is active? > sudo journalctl --boot | grep microcode > It was, but I forgot to capture this output. > Could you try uninstalling the package 'amd-microcode'? > sudo apt-get remove amd-microcode > sudo update-initramfs -u > > Does that fix your graphical issues? No, but installing the non-free nvidia-driver did. It's a pity, as I don't need anything nouveau couldn't theoretically provide. Thanks anyway. --Adam
Re: 11.7 planning + bookworm planning
On Thu, 2023-04-20 at 11:32 +0200, Paul Gevers wrote: > Dear all, > > Progress \o/. > > On 13-04-2023 11:29, Paul Gevers wrote: > > For me to do the release, I'd need to get my hands on the key. > > I'm in contact with Jonathan and we're convinced we'll be able to > get the key to me in time. > I'm aware this still needs much more input from me :-/ but as a quick note, for the record it's key*s*. The Release files contain both codenames and suite designations, so the moves of stable to oldstable and oldstable to oldoldstable mean that buster and bullseye's Release files will also need re-signing. Regards, Adam
Re: Bug#1034548: bullseye-pu: package glibc/2.31-13+deb11u6
Control: tags -1 + confirmed d-i On Tue, 2023-04-18 at 00:06 +0200, Aurelien Jarno wrote: > There are multiple fixes in this upload, all coming from the upstream > stable branch: > - Multiple crashes or memory leak in printf-family functions > - Overflow fix in the AVX2 implementation of wcsnlen > Please go ahead. Regards, Adam
Re: Bug#1026845: bullseye-pu: package systemd/247.3-7+deb11u2
Control: tags -1 + confirmed d-i On Thu, 2022-12-22 at 12:13 +, Luca Boccassi wrote: > We'd like to upload several bug fixes, including security fixes, for > systemd to bullseye. > The fixes come from the upstream stable branches which are covered by > CI and confirmed by reporters. > Please go ahead; sorry for the delay. Regards, Adam
Upcoming stable point release (11.7)
Hi, The next point release for "bullseye" (11.7) is scheduled for Saturday, April 29th. Processing of new uploads into bullseye-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: 11.7 planning
On Wed, 2023-03-15 at 20:33 +, Jonathan Wiltshire wrote: > 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. A quick reply in the interests of expediency: 1st - could work, but could be a bit tight as things stand 8th - Easter weekend, so possible people are away / busy. Could work for me although I have slightly selfish personal reasons for it not being my favourite. :-) 15th - fine 22nd - doesn't work for me 29th - fine Regards, Adam
Re: bookworm release date?
Hi, Sorry for the delayed reply, apparently I'm further behind than I realised. :-( On Fri, 2023-02-17 at 21:56 +0100, Paul Gevers wrote: [...] > What do people think of the idea > to start picking a release date already? > [...] > Adam, I think we'd also want to do a point release before that time, > e.g. to include a fix for bug #1029803. What do you think about it? > Yes. We also really want to get a debian-archive-keyring update into bullseye before the release, or we can't use the new keys to sign the bookworm release files. But first we need to get it into unstable. I'm aware that we're very late here, sorry. :-( ftp-master have now published their bookworm keys, so we can get those incorporated. For the SRM side, you probably saw that we've been considering moving to an EC key. From the very limited responses to the discussion I started on debian-release, I'm still not entirely sure if that's feasible / a good idea. It would also be good to finally get the shim updates into bullseye at the same time, unless Steve tells me that's a bad plan. :-) Regards, Adam
Bug#1032416:
I have retried with https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso and hit the same issue. Image was written with dd and definitely contains firmware-iwlwifi_20230210-1_all.deb I'd also like to note https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031696, from the creator of Rufus.
Bug#1032416:
IRC has let me know that d-i needs the symlinks in the original ISO are needed, rufus breaks these and I missed it on https://wiki.debian.org/DebianInstall. Thanks anyway, I guess.
Re: Bug#1028313: bullseye-pu: package isc-dhcp/4.4.1-2.3+deb11u2
Control: tags -1 + confirmed d-i On Mon, 2023-01-09 at 14:04 +0100, Bastian Blank wrote: > Under not completely understood conditions, dhclient completely > removes > IPv6 addresses from use and is unable to restore them. This problem > was > fixed in the separate script upstream maintains some years ago. > Please go ahead; sorry for the delay. Regards, Adam
Re: Bug#1025323: bullseye-pu: package nano/5.4-2+deb11u2
Control: tags -1 + confirmed d-i On Fri, 2022-12-02 at 15:42 +0100, Jordi Mallach wrote: > I'm requesting the acceptance of a new nano update for stable, > with 3 additional upstream patches that fix two crash conditions > and a data-loss condition. > Please go ahead. Regards, Adam
Upcoming stable point release (11.6)
Hi, The next point release for "bullseye" (11.6) is scheduled for Saturday, December 17th. Processing of new uploads into bullseye-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: 11.6 planning
On Thu, 2022-11-17 at 21:33 +, Adam D. Barratt wrote: > 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. > Thanks for all of the replies. It looks like the 17th is probably the best of the options, although I'm sure sysadmins everywhere will be delighted at us releasing the week before Christmas. :-) I'll get things announced properly in the next day or so. Thanks, Adam
11.6 planning
Hi, 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. Thanks, Adam
Re: Bug#1016786: bullseye-pu: package systemd/247.3-7+deb11u1
Control: tags -1 + confirmed d-i On Sun, 2022-08-07 at 15:31 +0200, Michael Biebl wrote: > I'd like to make a stable upload for systemd fixing two issues in > systemd-detect-virt > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013342 > systemd - Please backport support for Hyper-V on arm64 to stable > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016157 > systemd-detect-virt fails to detect Openstack on arm64 > > All changes are cherry-picks from upstream Git and are already in > unstable/testing. > > > While at it, I also pulled a patch to fix build failures when systemd > is > built against newer kernel headers (>= 5.14). > Please go ahead; thanks. Regards, Adam
Upcoming oldstable point release (10.13)
Hi, The next - and final - point release for "buster" (10.13) is scheduled for Saturday, September 10th. Processing of new uploads into buster- proposed-updates will be frozen during the weekend of August 27th. Regards, Adam
Upcoming stable point release (11.5)
Hi, The next point release for "bullseye" (11.5) is scheduled for Saturday, September 10th. Processing of new uploads into bullseye-proposed- updates will be frozen during the preceding weekend. Regards, Adam
Re: buster EOL (10.13) and 11.5 planning
Hi, On Thu, 2022-07-28 at 17:09 +0100, Adam D. Barratt wrote: > 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 [...] > 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. > Thanks for the replies. We're not ready to freeze this weekend, so I'm planning on going for September 10th for both 10.13 and 11.5. I'll likely freeze 10.13 around the weekend of the 27th / early the following week to give us a little more time than the usual week to make sure we've got everything sorted. Regards, Adam
buster EOL (10.13) and 11.5 planning
Hi, 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. Thanks, Adam
Bug#1014790: installation-reports: Pinebook Pro: first partition overwrites u-boot, lacks bootable flag
Package: installation-reports Severity: normal X-Debbugs-Cc: kilob...@angband.pl Boot method: µSD Image version: daily, pinebookpro + partition.img Machine: Pinebook Pro Partitions: Model: MMC DA4128 (sd/mmc) Disk /dev/mmcblk2: 122138624kiB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system NameFlags 1 1024kiB 16384kiB 15360kiB u-boot 2 16384kiB 515072kiB 498688kiB ext4bootboot, legacy_boot, esp 3 515072kiB 117702656kiB 117187584kiB btrfs 4 117702656kiB 122137600kiB 4434944kiBlinux-swap(v1) swap Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[ ] Missing firmware for the network card; it was not present anywhere among suggested places, only later I learned it's package "raspi-firmware" (which doesn't play well with any non-raspi because of /boot/firmware). I've succeeded the installation using a dock that included ethernet, further d-i boots used usb tethering. The main problem was in the partitioner: it starts the first partition at 1MB, which overwrites u-boot. On Rockchip boxen, the loader wants u-boot starting at sector 16384 (ie, 8MB). Rounding up to an aligned value, I'd recommend starting the first partition at 16MB. Some doc on teh Interwebs suggests creating a dummy partition so nothing tries to write there -- I've done so. The other problem is the boot partition not flagged as bootable; this results in u-boot config not being found. The kernel's boot hanged in an unobvious place long before trying to mount disks (despite the same version but different build working for d-i); upon seeing that 5.19-rc4 from experimental works fine I didn't bother debugging 5.18 as we'll upgrade once Linus releases 5.19. After all this long fighting, it appears that the Pinebook Pro works fine. I invite you to gawp at it at the DebConf :) Meow! -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="12 (bookworm) - installer build 20220628-02:02:00" X_INSTALLATION_MEDIUM=netboot-gtk == Installer hardware-summary: == uname -a: Linux khazad-dum 5.18.0-2-arm64 #1 SMP Debian 5.18.5-1 (2022-06-16) aarch64 GNU/Linux usb-list: usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Manufacturer: Linux 5.18.0-2-arm64 xhci-hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 01: xHCI Host Controller [1d6b:0003] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 03 usb-list:Manufacturer: Linux 5.18.0-2-arm64 xhci-hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 03 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 5.18.0-2-arm64 ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 03 Device 02: USB2.0 Hub [05e3:0608] usb-list:Level 01 Parent 01 Port 00 Class 09(hub ) Subclass 00 Protocol 01 usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 03 Device 03: USB OPTICAL MOUSE [18f8:0f97] usb-list:Level 02 Parent 02 Port 00 Class 00(>ifc ) Subclass 00 Protocol 00 usb-list:Interface 00: Class 03(HID ) Subclass 01 Protocol 02 Driver usbhid usb-list:Interface 01: Class 03(HID ) Subclass 00 Protocol 01 Driver usbhid usb-list: usb-list: Bus 03 Device 04: USB Camera [0c45:6321] usb-list:Level 02 Parent 02 Port 01 Class ef(misc ) Subclass 02 Protocol 01 usb-list:Manufacturer: Sonix Technology Co., Ltd. usb-list:Interface 00: Class 0e(video) Subclass 01 Protocol 00 Driver usb-list:Interface 01: Class 0e(video) Subclass 02 Protocol 00 Driver usb-list: usb-list: Bus 04 Device 01: Generic Platform OHCI controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 5.18.0-2-arm64 ohci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-li
Re: Bug#1007714: bullseye-pu: package openssh/1:8.4p1-5+deb11u1
Hi Colin, On Fri, 2022-03-18 at 08:43 +0100, Cyril Brulebois wrote: > Adam D. Barratt (2022-03-17): > > As openssh builds a udeb, I'm CCing KiBi and tagging the bug > > accordingly. > > Making sure upgrades have a chance to work properly seems more > important > than any possible regressions at install time, for those deploying > over > SSH, so no objections at all. Just a quick reminder on this, as the window for getting changes into 11.4 closes over the coming weekend. Regards, Adam
Upcoming stable point release (11.4)
Hi, The next point release for "bullseye" (11.4) is scheduled for Saturday, July 9th. Processing of new uploads into bullseye-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: 11.4 planning
Hi Steve,
On Sun, 2022-06-19 at 18:04 +0100, Steve McIntyre wrote:
> Hey Adam!
>
> On Fri, Jun 17, 2022 at 08:31:23PM +0100, Adam Barratt wrote:
> > We're (again) running behind in getting the next point release for
> > bullseye sorted, and I know we're about to run into the
> > Deb{Camp,Conf}
> > period. I think the possible dates that make sense are:
> >
> > - July 2nd (means freezing next weekend, but so be it)
> > - July 9th
> >
> > I think there's already a couple of things pending on KiBi's review
> > list; I'll try and flag up any others as soon as I can.
>
> Argh. I've got a few pertinent issues here:
>
> * I'm *really* busy over the next few weeks (work and debconf) which
>make things awkward for me to fit stuff in. :-/
>
ACK. Debconf, and people being away for it again this year, rather
snuck up on me. TBH, June rather snuck up on me. :-(
> * IIRC this should also be another buster point release, possibly
> the
>last before it's dropped / passed over to LTS? Or are we thinking
>another one in August for Buster? Checking last year's dates, we
>released on Aug 14 so I'm thinking maybe we could/should push back
>that last point release into August. In that case, I'd be happier
>to do a bullseye-only point release in July. Neither of the dates
>you suggest are ideal for me (see above!), but under time pressure
>it's easier to cope with a single release rather than two.
>
stretch's LTS finishes at the end of June, and there's been some
initial discussion about how/when to handle the switchover for buster,
but it's not been concluded yet.
I'm not sure I have the bandwidth to be organising two point releases
over the next couple of weeks either, if I'm completely honest.
> * We have some secure-boot related updates that have not yet
> filtered
>through for buster and bullseye. We're working on stuff for
> bullseye
>now, but buster may take a little bit longer yet. I'd prefer the
>9th if possible.
>
ACK, thanks for the note / reminder.
Regards,
Adam
11.4 planning
Hi,
We're (again) running behind in getting the next point release for
bullseye sorted, and I know we're about to run into the Deb{Camp,Conf}
period. I think the possible dates that make sense are:
- July 2nd (means freezing next weekend, but so be it)
- July 9th
I think there's already a couple of things pending on KiBi's review
list; I'll try and flag up any others as soon as I can.
Thanks,
Adam
Re: Bug#1009250: bullseye-pu: fribidi/1.0.8-2+deb11u1
Control: tags -1 + confirmed d-i On Sat, 2022-04-09 at 23:04 +, Thorsten Alteholz wrote: > > The attached debdiff for fribidi fixes CVE-2022-25308, CVE-2022-25309 > and > CVE-2022-25310 in Bullseye. These CVEs have been marked as no-dsa by > the > security team. This looks OK to me, thanks, but will need a KiBi-ack as fribidi produces a udeb; CCing and tagging accordingly. Regards, Adam
Re: Bug#1010304: bullseye-pu: package freetype/2.10.4+dfsg-1+deb11u1
Control: tags -1 + confirmed d-i On Thu, 2022-04-28 at 22:21 +1000, Hugh McMaster wrote: > This update fixes three security vulnerabilities in FreeType > 2.10.4+dfsg-1. > > - CVE-2022-27404: heap buffer overflow via invalid integer decrement > in > sfnt_init_face() and woff2_open_font(). > - CVE-2022-27405: segmentation violation via ft_open_face_internal() > when > attempting to read the value of FT_LONG face_index. > - CVE-2022-27406: segmentation violation via FT_Request_Size() when > attempting > to read the value of an unguarded face size handle. > > It would be ideal to get these fixes into Bullseye. This looks OK to me, but as freetype builds a udeb it will want a KiBi- ack; CCed and tagging accordingly. Regards, Adam
Re: Bug#1000355: bullseye-pu: package nano/5.4-2+deb11u1
Control: tags -1 + d-i The changes are probably beneficial to the use of nano-udeb as well, but in any case tagging and CCing for inforamation. On Fri, 2022-03-18 at 18:15 +0100, Julien Cristau wrote: > Control: tag -1 confirmed > > On Mon, Nov 22, 2021 at 01:29:56AM +0100, Jordi Mallach wrote: > > Package: release.debian.org > > Severity: normal > > Tags: bullseye > > User: release.debian@packages.debian.org > > Usertags: pu > > > > [ Reason ] > > > > As we did early during the freeze, nano's upstream Benno > > Schulenberg has > > been maintaining a series of patches against nano 5.4, which > > backport > > crashes fixes and other big impact fixes for Debian's version of > > nano. > > > > [ Impact ] > > > > We will miss several crash (and general bugs) fixes in different > > situations and scenarios. > > > > [ Tests ] > > > > Patches have been tested individually against 5.4, and have had a > > wider > > testing in the newer nano versions in which the fixes were > > introduced. > > > > [ Risks ] > > > > There is a big amount of patches, but most of them are one or > > two-liners. Of course, the risk of any of them introducing new bugs > > is > > real, but given Benno's knowledge of the codebase, it is unlikely. > > > > [ Checklist ] > > [X] *all* changes are documented in the d/changelog > > - I've only mentioned the addition of a bundle of patches, > > not > > each one of them in detail. I can add a list of patches > > like in > > the changes section below, if that's preferred. > > [X] I reviewed all changes and I approve them > > [X] attach debdiff against the package in (old)stable > > [X] the issue is verified as fixed in unstable > > > Go ahead, thanks. > > Cheers, > Julien > >
Re: Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1
On Fri, 2022-03-18 at 14:12 +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-18 09:21:50 [+], Adam D. Barratt wrote: > > Apologies if the status here got confused - based on the above, I > > was > > assuming that in the absence of a negative response you would > > proceed > > with the 1.1.1n-0+deb11u1 plan. For complete clarity, please feel > > free > > to do so, bearing in mind that the window for the 11.3 point > > release > > closes over this weekend. > > No need to apologies. I did plan to do it on WED but got busy with > other > things, got sick on THU and couldn't anything so the plan is indeed > today. > Boo. Hope you're doing better. > I would also do the upload for Buster, would that work? I remember > that > the packages, that broken, were already uploaded a few cycles ago. Also as 1.1.1n? I assume there haven't been any regressions reported with l/m/n in the meantime. Regards, Adm
Re: Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1
On Wed, 2022-03-09 at 08:45 +0100, Sebastian Andrzej Siewior wrote: > On 2022-02-19 17:57:25 [+], Adam D. Barratt wrote: > > Feel free to upload; we'll wait for the d-i ack before accepting > > the > > package into p-u. > > There will be the release of 1.1.1n on Tuesday 15th March 2022 > including > a security fix. Therefore I will: > - prepare a security release against 1.1.1k-1+deb11u1 which will be > released via d-security. > - respond to this bug with a debdiff against 1.1.1m-0+deb11u1 > - upload 1.1.1n-0+deb11u1. > Apologies if the status here got confused - based on the above, I was assuming that in the absence of a negative response you would proceed with the 1.1.1n-0+deb11u1 plan. For complete clarity, please feel free to do so, bearing in mind that the window for the 11.3 point release closes over this weekend. Regards, Adam
Re: Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1
On Thu, 2022-03-17 at 19:29 -0400, Daniel Kahn Gillmor wrote: > On Thu 2022-03-17 17:49:04 +0000, Adam D. Barratt wrote: > > On Sat, 2022-02-19 at 22:24 -0500, Daniel Kahn Gillmor wrote: > > > On Sat 2022-02-19 17:09:21 +, Adam D. Barratt wrote: > > > > Control: tags -1 + confirmed d-i > > > > > > [...] > > > > That looks fine to me, but will need a d-i ack as the package > > > > builds a > > > > udeb; tagging and CCing accordingly. > > > > > > Understood -- i'll wait for a d-i ack before uploading. > > > > As we're getting very close to the window for 11.3 closing, please > > feel > > free to upload. > > I've just uploaded gnupg2/2.2.27-2+deb11u1 to bullseye now. Please > let > me know if there are any problems. Unfortunately it looks like the upload failed: gnupg2_2.2.27-2+deb11u1.dsc: Refers to non-existing file 'gnupg2_2.2.27.orig.tar.bz2.asc' Regards, Adam
Re: Bug#1007714: bullseye-pu: package openssh/1:8.4p1-5+deb11u1
Control: tags -1 + confirmed d-i On Tue, 2022-03-15 at 15:20 +, Colin Watson wrote: > OpenSSH in stable breaks on 32-bit architectures (at least armhf, > reportedly also i386) after upgrading libc6 to the version in > bookworm, > due to changes in its system call interface that affect OpenSSH's > seccomp sandbox. See https://bugs.debian.org/1004427. > > [ Impact ] > Without this change, I'm concerned that sshd may be unavailable > during > part of an upgrade from bullseye to bookworm (or even make the > machine > inaccessible, if it's headless and the upgrade fails). Getting the > sandbox tweak into bullseye at this stage would reduce that risk. > Please go ahead. As openssh builds a udeb, I'm CCing KiBi and tagging the bug accordingly. Regards, Adam
Re: Bug#1007746: buster-pu: package glibc/2.28-10+deb10u1
Control: tags -1 + confirmed d-i On Wed, 2022-03-16 at 00:50 +0100, Aurelien Jarno wrote: > A big part of the changes have been in the buster git branch for many > months, but I failed to submit the package for a point release up to > now. What triggered me to look at it again is breakage in the preinst > script when running on kernel x.y.z with z > 255. > > In other changes are just an (old) pull from the stable branch, > fixing > a few important bugs. Please go ahead, thanks. As glibc produces a udeb, I'm tagging the bug and CCing accordingly. Regards, Adam
Re: Bug#1005949: bullseye-pu: package glibc/2.31-13+deb11u3
On Tue, 2022-03-15 at 20:33 +, Adam D. Barratt wrote: > Control: tags -1 + confirmed d-i > > On Thu, 2022-02-17 at 23:15 +0100, Aurelien Jarno wrote: > > There are multiple fixes in this upload: > > - 4 security bugs > > - a fix to avoid preinst script failure when running on kernel > > x.y.z > > with z > 255. > > - a fix to avoid changes to /etc/nsswitch.conf to be reverted on > > upgrade > > > > [ Impact ] > > Installation will be left vulnerable to security issues and upgrade > > from buster will fail when running recent upstream stable kernels. > > > > This looks OK to me, thanks. > > As glibc produces a udeb, this will want a KiBi-ack; CCing and > tagging > accordingly. As we're getting very close to the window for 11.3 closing, please feel free to upload. Regards, Adam
Re: Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1
On Sat, 2022-02-19 at 22:24 -0500, Daniel Kahn Gillmor wrote: > On Sat 2022-02-19 17:09:21 +0000, Adam D. Barratt wrote: > > Control: tags -1 + confirmed d-i > > [...] > > That looks fine to me, but will need a d-i ack as the package > > builds a > > udeb; tagging and CCing accordingly. > > Understood -- i'll wait for a d-i ack before uploading. As we're getting very close to the window for 11.3 closing, please feel free to upload. Regards, Adam
Re: Bug#1005949: bullseye-pu: package glibc/2.31-13+deb11u3
Control: tags -1 + confirmed d-i On Thu, 2022-02-17 at 23:15 +0100, Aurelien Jarno wrote: > There are multiple fixes in this upload: > - 4 security bugs > - a fix to avoid preinst script failure when running on kernel x.y.z > with z > 255. > - a fix to avoid changes to /etc/nsswitch.conf to be reverted on > upgrade > > [ Impact ] > Installation will be left vulnerable to security issues and upgrade > from buster will fail when running recent upstream stable kernels. > This looks OK to me, thanks. As glibc produces a udeb, this will want a KiBi-ack; CCing and tagging accordingly. Regards, Adam
Upcoming oldstable point release (10.12)
Hi, The next point release for "buster" (10.12) is scheduled for Saturday, March 26th. Processing of new uploads into buster-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Upcoming stable point release (11.3)
Hi, The next point release for "bullseye" (11.3) is scheduled for Saturday, March 26th. Processing of new uploads into bullseye-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: Bug#1006165: bullseye-pu: package tasksel/3.68+deb11u1
Control: tags -1 + confirmed d-i
On Sun, 2022-02-20 at 11:01 +0100, Holger Wansing wrote:
> I would like to do a little update to tasksel, to make tasksel
> install
> CUPS for all desktop tasks.
> In the past (buster and before), it was like this as well, via a
> different
> approach: there was a "task-print-service" task for this, which has
> been
> removed for bullseye.
That seems reasonable enough, but for completeness I'd appreciate a
KiBi-ack ("don't be silly, Holger knows what they're doing" counts ;-)
)
Regards,
Adam
Re: Bug#1006192: bullseye-pu: package espeak-ng/1.50+dfsg-7+deb11u1
Control: tags -1 + confirmed d-i On Mon, 2022-02-21 at 00:07 +0100, Samuel Thibault wrote: > People have reported that when they work on the linux console with > the > espeakup screen reader, if they e.g. cat a long file, and the reader > starts speaking it, and the user presses some key to interrupt the > read, > the screen reader remains silent for several seconds before it speaks > anything again. That is because the speaking events for all the file > reading have still been queued and the speak cancellation just makes > them processed very quickly to flush the queue. Unfortunately there > is a > little usleep(50ms) that is performed on each event processing. This > is > a very old trick that was probably browntape-fixing some erroneous > condition. We tried to remove that sleep and it didn't seem to have > any > nasty side effect. Upstream did commit the change and users are > really > happy with the change that completely fixes the delay. > Does this have any impact on the udeb? Regards, Adam
Re: Bug#1006187: bullseye-pu: package espeakup/0.80-20+deb11u1
Control: tags -1 + confirmed d-i On Sun, 2022-02-20 at 21:35 +0100, Samuel Thibault wrote: > Users have reported that when they are building large packages in > parallel, or generally loading the system a bit, the espeakup screen > reader becomes very laggy. This is because espeakup gets scheduled > only along other the parallel processes. Worse, if the system goes > OOM, espeakup might get killed by the OOM killer. > > This is not a regression with respect to previous releases. > > In the case of the brltty screen reader, we fixed this by making > brltty niced to -10 and its OOM score set to -900. > Does this have any impact on the udeb? Regards, Adam
11.3 and 10.12 planning
Hi, 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 (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. Thanks, Adam
Re: Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1
On Sat, 2022-02-19 at 18:52 +0100, Sebastian Andrzej Siewior wrote: > On 2022-02-19 17:04:16 [+], Adam D. Barratt wrote: > > Control: tags -1 + confirmed d-i > … > > Thanks. Assuming the above is still accurate, then this looks good > > to > > me. > > > > As the package builds a udeb, it will need a d-i ack; tagging and > > CCing > > accordingly. > > I'm confused. May I upload or do I wait for the d-i ack? > Sorry for the confusion. Feel free to upload; we'll wait for the d-i ack before accepting the package into p-u. Regards, Adam
Re: Bug#1005694: bullseye-pu: package gtk+3.0/3.24.24-4+deb11u1
Control: tags -1 + confirmed d-i On Sun, 2022-02-13 at 13:44 +, Simon McVittie wrote: > Typeahead search in the file chooser (File -> Save As... dialog) > doesn't > work on networked filesystems (NFS/CIFS) under some circumstances. > (Having Tracker installed might accidentally avoid the bug, it's > unclear.) > Thanks. That looks OK to me, but will need a d-i ack as gtk+3.0 builds a udeb; tagging and CCing accordingly. > We have also had requests to resolve #982925 in bullseye, but there > are > two options for how to resolve that bug, and it's awkward to test; so > I > wanted to get this request in separately, to stop it from blocking > #976334. > I will do a separate +deb11u2 request for #982925 when I have a > better idea > of which solution is better, if that's OK for the release team? That sounds like a good plan, indeed. Regards, Adam
Re: Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1
Control: tags -1 + confirmed d-i On Thu, 2022-01-27 at 17:02 -0500, Daniel Kahn Gillmor wrote: > Please consider an update to GnuPG in debian bullseye, from version > 2.2.27-2 to 2.2.27-2+deb11u1. > The version mentioned above is correct, but the proposed changelog is not: +gnupg2 (2.2.27-2+deb11+1) bullseye; urgency=medium (it should be "deb11u1", not "deb11+1"). > The fixes, by Christoph Biedel and Raphaël Hertzog, are narrowly > targeted and fix real, significant issues that a subset of users > have. > They have been in debian unstable and testing for a while now without > issue: > > -- > [ Raphaël Hertzog ] > * Avoid network interaction in generator. Closes: #993578 > > [ Christoph Biedl ] > * Backport "Scd: Fix CCID driver for SCM SPR332/SPR532". Closes: > #982546 > -- > > The debdiff from the version in bullseye (2.2.27-2) is attached. Thanks. That looks fine to me, but will need a d-i ack as the package builds a udeb; tagging and CCing accordingly. Regards, Adam
Re: Bug#1003484: bullseye-pu: package openssl/1.1.1m-0+deb11u1
Control: tags -1 + confirmed d-i On Tue, 2022-01-11 at 00:00 +0100, Sebastian Andrzej Siewior wrote: > This is an update to the latest stable update of the openssl package > provided by upstream. It contains fixes for bugs which were not > identified as security critical but still worth fixing. > > The m release is in unstable the 24th December with no regression > reports so far. I haven't seen any fixes for regression in the stable > branch as of now. The testsuite passed for Bullseye during package > build and I deployed on a VM for testing (with nginx and openvpn > instance). Thanks. Assuming the above is still accurate, then this looks good to me. As the package builds a udeb, it will need a d-i ack; tagging and CCing accordingly. Regards, Adam
Re: Bug#1000458: bullseye-pu: package wget/1.21-1+deb11u1
Control: tags -1 + confirmed d-i On Tue, 2021-11-23 at 15:43 +, plugwash wrote: > When downloading a file greater than 2GB on a 32-bit system wget on > bullseye > will truncate it to 2GB. No error is reported, the length of the file > is simply > reported as less than it's true length. This was reported to me by > raspberry pi > staff, but I can reproduce it in a Debian i386 environment, so it's > not > raspberry pi, raspbian or arm specific. +wget (1.21-1+deb11u1) bullseye-staging; urgency=medium The distribution should simply by "bullseye". This looks OK to me, but will need a di-ack, as wget builds a udeb. Tagging and CCing appropriately. Regards, Adam
Upcoming stable point release (11.2)
Hi, The next point release for "bullseye" (11.2) is scheduled for Saturday, December 18th. Processing of new uploads into bullseye-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian
> The installation manual provides all this information. OK, this is fair, I wasn't thinking about the manual as I've installed Debian quite a few times and know how the installation goes. Perhaps the text could include a reminder to check the manual for more info on firmware loading, or even a QR code to take me to the correct place? >> I ended up grabbing >> https://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/firmware/testing/20211122/firmware.zip >> and extracting the firmware files from firmware-iwlwifi_20210818-1_all.deb >> Would the installer have coped if I'd just dropped that single deb file? > > Yes, as stated in the installation manual. > >> Maybe it'd be worth having an option to allow a user to tether a mobile >> phone via USB to grab the firmware online. > > This is automatic if the phone emulates a USB-ethernet adapter. > Perhaps the prompt should say "We can download the firmware automatically if you are able to use an alternative connection, such as mobile tethering", although I wonder how this would work for non-free firmware. >> Also, a cdrom: entry was added to sources.list even though I installed from >> USB. > > Because both contain the same ISO image so have the same data structure. But Debian was looking for these files at /media/cdrom - would the installation USB be re-mounted at this location? --Adam
Bug#1000743: installation-reports: bootx64.efi didn't seem to get installed and no UEFI boot entry was created for Debian
Package: installation-reports Severity: important Tags: d-i X-Debbugs-Cc: deb...@voltagex.org (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: USB Image version: https://ftp.acc.umu.se/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso 2021-11-22 05:56, SHA256 dc763772fb490b89262591186810bbd4030ee3015ddcbc21d328cc64830dc04c Date: Machine: Dell XPS 9350 Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[OE] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[O] Comments/Problems: Once the installer had finished and prompted me to reboot, the system came back up in Dell's hardware check mode and some investigation revealed there was no UEFI boot entry for Debian. /boot/efi └── EFI ├── debian │ ├── BOOTX64.CSV │ ├── fbx64.efi │ ├── grub.cfg │ ├── grubx64.efi │ ├── mmx64.efi │ └── shimx64.efi └── Dell └── logs ├── diags_current.xml └── diags_previous.xml Shouldn't there normally be EFI/boot/bootx64.efi? Additional issues: This laptop has an upgraded AX201 wifi card - the installer detected that I needed non-free firmware and I was able to load it from USB successfully. The message could be improved a bit with better instructions of where to get the firmware and what structure is needed on the external drive. I ended up grabbing https://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/firmware/testing/20211122/firmware.zip and extracting the firmware files from firmware-iwlwifi_20210818-1_all.deb Would the installer have coped if I'd just dropped that single deb file? Maybe it'd be worth having an option to allow a user to tether a mobile phone via USB to grab the firmware online. Also, a cdrom: entry was added to sources.list even though I installed from USB. Please make sure that any installation logs that you think would be useful are attached to this report. Please compress large files using gzip. I have the logs, but I am using the Debian provided SMTP server and reportbug currently has me in nano, so I'm not sure how to do this. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="12 (bookworm) - installer build 20211122-00:01:32" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux ninethreeshifty 5.15.0-1-amd64 #1 SMP Debian 5.15.3-1 (2021-11-18) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers [8086:1904] (rev 09) lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Graphics 540 [8086:1926] (rev 0a) lspci -knn: DeviceName: Onboard IGD lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903] (rev 09) lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f] (rev 21) lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21) lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21) lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21) lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-LP CSME HECI #1 [8086:9d3a] (rev 21) lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] [8086:9d03] (rev 21) lspci -knn: Subsystem: Dell Device [1028:0704] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci lspci -k
11.2 planning
Hi, 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 Thanks, Adam
Bug#998867: bumping severity
Control: severity -1 critical The current severity, "grave", is a serious understatement. As all buildd chroots that are created with buggy debootstrap are tainted, any packages built recently may assume merged usr, and thus needs to be rebuilt. Do we have a patch? If not, let's revert, today or tomorrow at the latest. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A white dwarf seeks a red giant for a binary relationship. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: Bug#995848: bullseye-pu: package brltty/6.3+dfsg-1+deb11u1
Control: tags -1 + confirmed d-i Apologies for somehow not processing this upload for so long. On Thu, 2021-10-07 at 00:34 +0200, Samuel Thibault wrote: > Bug#994729 was noticed only recently: when installing Debian with > sysvinit rather than systemd, Braille output wouldn't work in the X > session. This was probably already happening in the Stretch & Buster > releases. This is not a problem for systemd-based systems that > already have a fix since october 2016. > > [ Impact ] > Blind users that use sysvinit-based Debian systems cannot use Braille > within X. > While I don't believe this should affect the installer in any way, as brltty produces a udeb it should really have a KiBi-ack; CCing and tagging accordingly. Regards, Adam
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
On Mon, 2021-09-27 at 12:38 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
>
To confirm some IRC conversations - given the closeness of the freeze
for 11.1, please feel free to upload and kibi can review the package
from stable-new.
Regards,
Adam
> Control: fixed 994042 2.32-3
>
> Hi,
>
> On Sun, 2021-09-26 at 22:16 +0200, Aurelien Jarno wrote:
> > Hi,
> >
> > On 2021-09-26 20:46, Adam D. Barratt wrote:
> > > On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote:
> > > [...]
> > > > In the meantime another issue that would need to be fixed in
> > > > sid
> > > > > > came
> > > > as
> > > > bug#994042.
> > > >
> > > > This time the issue is in the preinst. To summarize, in the
> > > > case
> > > > debconf is not usable to prompt the user about the upgrade, the
> > > > preinst switches to text prompt. However as the debconf module
> > > > has
> > > > been loaded got control of the tty, which prevent any input
> > > > from
> > > > the
> > > > user. For skilled users it still possible to kill the upgrade
> > > > from
> > > > another, but other users will probably try other actions that
> > > > might
> > > > have damaging effects (like rebooting the system).
> > > >
> > > > The fix is to get the debconf configuration without using the
> > > > debconf
> > > > module, as suggested by Colin Watson.
> > > >
> > >
> > > Thanks. That looks OK to me, particularly with Colin's review.
> >
> > Thanks for the review. I guess that now it just needs a kibi-ack.
>
> Yep; re-tagging accordingly.
>
> > > Is there an ETA for getting the fix into unstable?
> >
> > Upgrades from buster to bookworm are not supported, so it means
> > upgrade
> > to bookworm starts from bullseye, which has a fixed debconf (the
> > issue
> > has been fixed in version 1.5.76). Therefore the fix in unstable
> > has
> > been done in glibc 2.32-3 by just dropping all the workaround:
> >
> > https://salsa.debian.org/glibc-team/glibc/-/commit/66359576b1aa793ae6c79618b188738287cf8789
>
> Aha, thanks for connecting the dots. I was misled / confused slightly
> by the lack of fixed versions on #994042, where the version tracking
> implies that unstable is still affected, and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994042;msg=33 not
> indicating which branch the fix was on (I realise I {c,sh}ould have
> checked). I've added a fixed version based on your explanation above;
> hopefully that makes the status clearer.
>
> Regards,
>
> Adam
>
>
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
Control: tags -1 + confirmed d-i
Control: fixed 994042 2.32-3
Hi,
On Sun, 2021-09-26 at 22:16 +0200, Aurelien Jarno wrote:
> Hi,
>
> On 2021-09-26 20:46, Adam D. Barratt wrote:
> > On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote:
> > [...]
> > > In the meantime another issue that would need to be fixed in sid
> > > > > came
> > > as
> > > bug#994042.
> > >
> > > This time the issue is in the preinst. To summarize, in the case
> > > debconf is not usable to prompt the user about the upgrade, the
> > > preinst switches to text prompt. However as the debconf module
> > > has
> > > been loaded got control of the tty, which prevent any input from
> > > the
> > > user. For skilled users it still possible to kill the upgrade
> > > from
> > > another, but other users will probably try other actions that
> > > might
> > > have damaging effects (like rebooting the system).
> > >
> > > The fix is to get the debconf configuration without using the
> > > debconf
> > > module, as suggested by Colin Watson.
> > >
> >
> > Thanks. That looks OK to me, particularly with Colin's review.
>
> Thanks for the review. I guess that now it just needs a kibi-ack.
Yep; re-tagging accordingly.
> > Is there an ETA for getting the fix into unstable?
>
> Upgrades from buster to bookworm are not supported, so it means
> upgrade
> to bookworm starts from bullseye, which has a fixed debconf (the
> issue
> has been fixed in version 1.5.76). Therefore the fix in unstable has
> been done in glibc 2.32-3 by just dropping all the workaround:
>
> https://salsa.debian.org/glibc-team/glibc/-/commit/66359576b1aa793ae6c79618b188738287cf8789
Aha, thanks for connecting the dots. I was misled / confused slightly
by the lack of fixed versions on #994042, where the version tracking
implies that unstable is still affected, and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994042;msg=33 not
indicating which branch the fix was on (I realise I {c,sh}ould have
checked). I've added a fixed version based on your explanation above;
hopefully that makes the status clearer.
Regards,
Adam
Re: Bug#992693: bullseye-pu: package glibc/2.31-13+deb11u1
On Tue, 2021-09-21 at 23:47 +0200, Aurelien Jarno wrote: [...] > In the meantime another issue that would need to be fixed in sid > > > came > as > bug#994042. > > This time the issue is in the preinst. To summarize, in the case > debconf is not usable to prompt the user about the upgrade, the > preinst switches to text prompt. However as the debconf module has > been loaded got control of the tty, which prevent any input from the > user. For skilled users it still possible to kill the upgrade from > another, but other users will probably try other actions that might > have damaging effects (like rebooting the system). > > The fix is to get the debconf configuration without using the debconf > module, as suggested by Colin Watson. > Thanks. That looks OK to me, particularly with Colin's review. Is there an ETA for getting the fix into unstable? Regards, Adam
Re: Bug#994023: buster-pu: package espeak-ng/1.49.2+dfsg-8+deb10u1
Control: tags -1 + confirmed d-i On Fri, 2021-09-10 at 02:17 +0200, Samuel Thibault wrote: > [ Reason ] > Espeak-ng cannot drive the mbrola-fr4 speech synthesis voice if the > mbrola-fr1 package is not installed. This is because some of the mb- > fr4 > espeak rules refer to the fr1 voice while they should be referring to > the fr4 voice. This was fixed some time ago in the newer espeak-ng > package, but the fix was not backported yet to buster. This looks OK to me, but will need a KiBi-ack as espeak-ng produces a udeb; tagging and CCing appropriately. Regards, Adam
Upcoming stable point release (11.1)`
Hi, The first point release for "bullseye" (11.1) is scheduled for Saturday, October 9th. Processing of new uploads into bullseye- proposed-updates will be frozen during the preceding weekend. Regards, Adam
Upcoming oldstable point release (10.11)
Hi, The next point release for "buster" (10.11) is scheduled for Saturday, October 9th. Processing of new uploads into buster-proposed-updates will be frozen during the preceding weekend. Regards, Adam
Re: 11.1 and 10.11 planning
Hi, Thanks for the responses everyone. Mark indicated on IRC that he'd be happy to be ftpmaster-du-jour on any of the dates. On Mon, 2021-09-06 at 12:51 +0100, Adam D. Barratt wrote: > 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. [...] > 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 The conclusion seems to be that if we want to have all of the Images Team available then we're looking at: > October 9th - OK for me > October 16th - OK for me Images Team, what was the conclusion in terms of timing for the two point releases? Are you happy for the archive side for both to happen on the same day, with image testing for buster possibly being delayed, or would you prefer to try and separate the whole process? (In which case we would need all teams available for multiple dates.) Regards, Adam
