Re: Planning for 12.6/11.10
On Mon, May 27, 2024 at 01:07:17PM +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 Any of those are feasible for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Bug#1070670: bullseye-pu: package shim/15.8-1~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: debian-...@lists.debian.org This is a new upstream version of shim, built for bullseye. This is needed for better handling of SBAT-based revocations, plus a range of security updates from upstream. [ This is very similar to the bookworm update in #1070660 ] See attached debdiff for the changes. They're not minimal, but in the case of shim we need to be as close to upstream as possible for the sake of getting stuff reviewed and signed. The only local patches to the upstream source now are: * to force SBAT updates to revoke older insecure grub binaries * to allow for building on arm64 with older toolchain (retained from previous bullseye builds) There are some minor changes to packaging to help with review. I've tested locally using CI and also by hand on various machines and all looks good here. Obviously, once this is accepted and autobuilt I'll need to submit things for review and signing elsewhere. Then we'll be want shim-signed updting too. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable shim (15.8-1~deb11u1) bullseye; urgency=medium * New upstream release fixing more bugs * Remove previous patches, no longer needed: + Make-sbat_var.S-parse-right-with-buggy-gcc-binutils.patch (now upstream) + Enable-NX.patch (we don't want NX just yet until the whole boot stack is NX-capable) + block-grub-sbat3-debian.patch (not needed now upstream grub SBAT is 4) * Cherry-pick 2 new patches from upstream for grub revocations: + 0001-sbat-Add-grub.peimage-2-to-latest-CVE-2024-2312.patch + 0002-sbat-Also-bump-latest-for-grub-4-and-to-todays-date.patch * Log if the build is nx-compatible or not * Force shim to use the latest revocations by default to block some older grub / peimage issues. This is: "shim,4\ngrub,4\ngrub.peimage,2\n" * Install a copy of the Debian CA certificate into /usr/share/shim. Closes: #1069054 * Clean up better after build. Closes: #1046268 shim_15.8-1~deb11u1.debdiff.gz Description: application/gzip
Bug#1070660: bookworm-pu: package shim/15.8-1~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: debian-...@lists.debian.org This is a new upstream version of shim, built for bookworm. This is needed for better handling of SBAT-based revocations, plus a range of security updates from upstream. See attached debdiff for the changes. They're not minimal, but in the case of shim we need to be as close to upstream as possible for the sake of getting stuff reviewed and signed. The only local patches to the upstream source now are to force SBAT updates to revoke older insecure grub binaries. There are some minor changes to packaging to help with review, and to add some autopkgtest stuff. I've tested locally using CI and also by hand on various machines and all looks good here. Obviously, once this is accepted and autobuilt I'll need to submit things for review and signing elsewhere. Then we'll be want shim-signed updting too. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable shim (15.8-1~deb12u1) bookworm; urgency=medium [ Steve McIntyre ] * Cope with changes in pesign packaging. * New upstream release fixing more bugs * Remove all our previous patches, no longer needed: + Make-sbat_var.S-parse-right-with-buggy-gcc-binutils.patch (now upstream) + Enable-NX.patch (we don't want NX just yet until the whole boot stack is NX-capable) + block-grub-sbat3-debian.patch (not needed now upstream grub SBAT is 4) * Cherry-pick 2 new patches from upstream for grub revocations: + 0001-sbat-Add-grub.peimage-2-to-latest-CVE-2024-2312.patch + 0002-sbat-Also-bump-latest-for-grub-4-and-to-todays-date.patch * Log if the build is nx-compatible or not * Force shim to use the latest revocations by default to block some older grub / peimage issues. This is: "shim,4\ngrub,4\ngrub.peimage,2\n" * Install a copy of the Debian CA certificate into /usr/share/shim. Closes: #1069054 * Clean up better after build. Closes: #1046268 [ Bastien Roucariès ] * Port autopkgtest from ubuntu * Import MR-12: "shim-unsigned:amd64 cannot be installed alongside shim-unsigned:i386", thanks to adrian15 adrian15 (Closes: #936009). * Fix debian/watch and check signature shim_15.8-1~deb12u1.debdiff.gz Description: application/gzip
Bug#1070249: bookworm-pu: package python-jwcrypto/1.1.0-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: steve.mcint...@pexip.com, Timo Aaltonen
Hi,
[ Reason ]
I've backported the upstream fix for CVE-2024-28102 (#1065688) to
bookworm. It's not considered critical as a security fix by the
security team, but would still be good to have in bookworm.
Ready to upload if you're happy.
Timo is happy for me to upload this - see the conversation in
#1065688.
[ Impact ]
Minor security issue.
[ Tests ]
The patch comes from upstream, and includes a unit test.
[ Risks ]
The changes are straightforward, cherry-picked from current upstream
and just massaged to fit the older version in bookworm.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
The debdiff here just contains trivial metadata changes from my
initial debdiff in #1065688
python-jwcrypto (1.1.0-1+deb12u1) bookworm; urgency=medium
* Apply and tweak upstream security fix for CVE-2024-28102
Address potential DoS with high compression ratio
diff -Nru python-jwcrypto-1.1.0/debian/changelog
python-jwcrypto-1.1.0/debian/changelog
--- python-jwcrypto-1.1.0/debian/changelog 2022-03-29 08:33:50.0
+0100
+++ python-jwcrypto-1.1.0/debian/changelog 2024-04-26 17:18:31.0
+0100
@@ -1,3 +1,10 @@
+python-jwcrypto (1.1.0-1+deb12u1) bookworm; urgency=medium
+
+ * Apply and tweak upstream security fix for CVE-2024-28102
+Address potential DoS with high compression ratio
+
+ -- Steve McIntyre <93...@debian.org> Fri, 26 Apr 2024 17:18:31 +0100
+
python-jwcrypto (1.1.0-1) unstable; urgency=medium
* New upstream release.
diff -Nru python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch
python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch
--- python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch 1970-01-01
01:00:00.0 +0100
+++ python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch 2024-04-26
17:18:31.0 +0100
@@ -0,0 +1,72 @@
+commit 90477a3b6e73da69740e00b8161f53fea19b831f
+Author: Simo Sorce
+Date: Tue Mar 5 16:57:17 2024 -0500
+
+Address potential DoS with high compression ratio
+
+Fixes CVE-2024-28102
+
+Signed-off-by: Simo Sorce
+
+Index: os-python-jwcrypto/jwcrypto/jwe.py
+===
+--- os-python-jwcrypto.orig/jwcrypto/jwe.py
os-python-jwcrypto/jwcrypto/jwe.py
+@@ -9,6 +9,9 @@ from jwcrypto.common import base64url_de
+ from jwcrypto.common import json_decode, json_encode
+ from jwcrypto.jwa import JWA
+
++# Limit the amount of data we are willing to decompress by default.
++default_max_compressed_size = 256 * 1024
++
+
+ # RFC 7516 - 4.1
+ # name: (description, supported?)
+@@ -387,6 +390,10 @@ class JWE:
+
+ compress = jh.get('zip', None)
+ if compress == 'DEF':
++if len(data) > default_max_compressed_size:
++raise InvalidJWEData(
++'Compressed data exceeds maximum allowed'
++'size' + f' ({default_max_compressed_size})')
+ self.plaintext = zlib.decompress(data, -zlib.MAX_WBITS)
+ elif compress is None:
+ self.plaintext = data
+Index: os-python-jwcrypto/jwcrypto/tests.py
+===
+--- os-python-jwcrypto.orig/jwcrypto/tests.py
os-python-jwcrypto/jwcrypto/tests.py
+@@ -1716,6 +1716,32 @@ class ConformanceTests(unittest.TestCase
+ check.decrypt(key)
+ self.assertEqual(check.payload, b'plain')
+
++def test_jwe_decompression_max(self):
++key = jwk.JWK(kty='oct', k=base64url_encode(b'A' * (128 // 8)))
++payload = '{"u": "' + "u" * 4 + '", "uu":"' \
+++ "u" * 4 + '"}'
++protected_header = {
++"alg": "A128KW",
++"enc": "A128GCM",
++"typ": "JWE",
++"zip": "DEF",
++}
++enc = jwe.JWE(payload.encode('utf-8'),
++ recipient=key,
++ protected=protected_header).serialize(compact=True)
++with self.assertRaises(jwe.InvalidJWEData):
++check = jwe.JWE()
++check.deserialize(enc)
++check.decrypt(key)
++
++defmax = jwe.default_max_compressed_size
++jwe.default_max_compressed_size = 10
++# ensure we can eraise the limit and decrypt
++check = jwe.JWE()
++check.deserialize(enc)
++check.decrypt(key)
++jwe.default_max_compressed_size = defmax
++
+
+ class JWATests(unittest.TestCase):
+ def test_jwa_crea
Re: Re-planning for 12.6
On Sat, Apr 20, 2024 at 05:41:13PM +0100, Jonathan Wiltshire wrote: >On Thu, Apr 18, 2024 at 10:58:41PM +0100, Steve McIntyre wrote: >> Hiya! >> >> Not wanting to pester *too* much, but where are we up to? >> > >Right now I can still have 27th April on the cards but we're missing FTP and >press. It's next week, we'd have to know this weekend and get frozen. >Mark indicated "maybe" and no answer from press. > >If that date works please reply urgently otherwise we're looking into May >and possibly just skipping to line up with the final bullseye anyway. It works for me, I guess. Dunno about other folks. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Re: Debian
You've written a lot of text here in a few mails, replying to yourself several times. This is not a positive pattern. On Fri, Apr 19, 2024 at 11:58:18AM +0200, José Luis González González wrote: >> There are similar issues with boa and dhttpd, and it seems Apache is going >> that way. > >nvi adds to the subversive ones, with bash, etc. What on earth do you mean by "subversive" here?? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Re-planning for 12.6
Hiya! Not wanting to pester *too* much, but where are we up to? On Tue, Apr 02, 2024 at 10:53:49PM +0100, Steve McIntyre wrote: >On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam Barratt wrote: >>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 > >Works for me. > >>April 20th >>- Doesn't work for me; I'm away from the Tuesday before until late on >>the Friday > >Works for me. > >>April 27th >>- Doesn't work for me; I have a pre-existing appointment which means >>I'll be AFK much of the day > >Works for me. > >>May 4th >>- Apparently doesn't work for me; long weekend in the UK >> > >Works for me. > >>May 11th >>- Should work for me > >Nope, already booked for that Saturday. > >-- >Steve McIntyre, Cambridge, UK.st...@einval.com >"...In the UNIX world, people tend to interpret `non-technical user' > as meaning someone who's only ever written one device driver." -- Daniel Pead -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: Re-planning for 12.6
On Mon, Apr 01, 2024 at 01:07:27PM +0100, Adam Barratt wrote: >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 Works for me. >April 20th >- Doesn't work for me; I'm away from the Tuesday before until late on >the Friday Works for me. >April 27th >- Doesn't work for me; I have a pre-existing appointment which means >I'll be AFK much of the day Works for me. >May 4th >- Apparently doesn't work for me; long weekend in the UK > Works for me. >May 11th >- Should work for me Nope, already booked for that Saturday. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Upcoming stable point release (12.6)
On Fri, Mar 29, 2024 at 10:24:09PM +, Adam Barratt wrote: >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. ACK, thanks for the update -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Re: Planning for 12.6
On Mon, Feb 12, 2024 at 06:04:17PM +, Jonathan Wiltshire wrote: >Hi, > >12.6 should be around 10th April, so please indicate availability for: > >7 April >13 April >20 April Any of those should work for me, assuming (re Adam) that you mean 6 April and not 7 April. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: please, help to get the image write done, due to an error. Thank you!
Moving this to the debian-user list and setting reply-to accordingly... On Fri, Feb 09, 2024 at 12:25:15PM +, guido mezzalana wrote: >Hello > >First of all I wish to thank you all Debian's Team! To still enjoy a free OS:) > >I am running Ubuntu XFCE and I am using the Disk Image Write to get your lates >Debian 12.4.1 XFCE on my USB. Unfortunately after a few try I get always an >error and so I cannot get the job done. I do have a Lenovo X200 which comes >without DVD writer. Ummm. What image exactly are you trying to write, and how? We don't have any images labelled with version 12.4.1. Where did you get this image from? What exact errors is the image writer program reporting? Without that information it's very difficult to help you. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: /usr-move: Do we support upgrades without apt?
On Sat, Dec 23, 2023 at 01:22:48PM +, Richard Lewis wrote: > >Perhaps release-notes should suggest to run dpkg --verify after a >dist-upgrade anyway - i assume it doesnt hurt to do so? That's a really good suggestion, yes! I don't know why nobody hasn't thought of this before. :-) >Happy to suggest and edit text for release notes: i would want to know: > >- how do i know if the system is fine? > > i was assuming that it would output nothing if everything is fine, > but that seems to be far from the case. I get huge amounts of output > that is very hard to interpret, i assume it's showing a 'c' for every > single changed conffile, and 'missing' where i deleted conffiles. > But why are some lines contain question marks? we would need a lot > of explanation here to make this useful for users (unfortunately, the > dpkg man page is very confusing about this option, and doesnt have > any of this, as far as i can understand) > >- if something went wrong: > a) how do i know? would there be an obvious error message? do i need to > check the exit status? > b) what would i do?: reinstall some packages? reinstall the whole system? > >(maybe this should be in a bug against release-notes) Maybe a wrapper script to just report likely problems would be a good plan. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Re: Planning for 12.5/11.9
On Tue, Dec 19, 2023 at 09:25:06PM +, Jonathan Wiltshire wrote: >Hi, > >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 Any of those *should* be OK for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: FTBFS: tests fail in clean environment
On Thu, Nov 23, 2023 at 09:20:37AM -0500, Nicolas Mora wrote: >Hello, > >On Tue, 21 Nov 2023 13:30:31 +0000 Steve McIntyre wrote: >> Source: libssh2 >> Version: 1.9.0-2 >> Severity: serious >> Tags: ftbfs patch >> >> Hi! >> >> Building libssh2 using debuild in a clean local chroot, I get test >> failures and even a core dump! >> >Thanks for reporting the bug, although I have concerns on its scope. > >The package you have found the issue is the bullseye one, and the package >updates for oldstable are allowed mostly for security patches. > >Your bug is related to the test suite, and the patch won't change the binary >files in the package, so I assume the patch isn't going to be allowed for >proposed-updates. > >I've added the release team to ask for their opinion. > >Friends from the release team, do you have a feedback on this? Ah, apologies - that version is bogus, it's just the version on the bullseye machine I ran reportbug from. The tests are failing on current unstable source. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: Planning for 12.3
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? -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Re: Planning for 12.3
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. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Re: 11.8/12.2 planning
Apologies, I don't think I've responded to this yet :-( On Mon, Jul 24, 2023 at 07:25:13PM +0100, Jonathan Wiltshire wrote: >I think I confused matters with my messy thread; let's start again. > >I originally suggested: > >Jonathan Wiltshire (2023-06-28): >> The proper cadence for 11.8 and 12.2 is the weekend of 30th September >> 2023. Please indicate your availability for: >> >> 23 Sep >> 30 Sep (preferred) >> 7 Oct > >Let's say 30 Sep is still preferred, 7th Oct or at a stretch 14th Oct are >options. Please indicate your availability for those three. 23rd and 7th are fine, 30th may be more awkward for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: 11.8/12.2 planning
On Wed, Jun 28, 2023 at 10:09:42AM +0200, Cyril Brulebois wrote: >Jonathan Wiltshire (2023-06-28): >> The proper cadence for 11.8 and 12.2 is the weekend of 30th September >> 2023. Please indicate your availability for: >> >> 23 Sep >> 30 Sep (preferred) >> 7 Oct > >I should be able to make any of those work for the installer team, and >optionally for the images team. 23rd and 7th are fine, 30th may be more awkward for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: 11.8 planning
On Sat, Jun 24, 2023 at 03:17:22PM +0100, Jonathan Wiltshire wrote: >On Tue, Jun 20, 2023 at 06:15:30PM +0100, 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. >> >> 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. >> > >Yes, I had forgotten about the transition to oldstable candece. I was going >to suggest, though, that 11.8 gets pushed back to cadence with 12.2 and we >just do 12.1 on its own first. How does that sound? WFM. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: 11.8 planning
On Mon, Jun 19, 2023 at 10:02:27PM +0100, Jonathan Wiltshire wrote: >Hi, > >I'm sending this separately to a similar mail for 12.1. That's because the >timings are far enough out that they would make sense on separate weekends, >but they could also be stretched[1] and combined. > >Two months from 29th April is around the 1st July, so I propose: > >1st July >8th July >15th July at a push > > >1: a shame that joke hasn't worked for some years now 1st July is out for me, but I can do the others fine. -- Steve McIntyre, Cambridge, UK.st...@einval.com The two hard things in computing: * naming things * cache invalidation * off-by-one errors -- Stig Sandbeck Mathisen
Re: 12.1 planning
On Mon, Jun 19, 2023 at 10:04:06PM +0100, Jonathan Wiltshire wrote: >Hi, > >The promised 4-6 weeks following release for 12.1 looks like: > > 8th July (4) >15th July (5) >22nd July (6) > >The first of them would combine with a very stretched 11.8; SRM might >prefer to get 11.8 done earlier and leave more time for 12.1 to mature. All of those work for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Bug#1036656: unblock: grub2/2.06-13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package grub2 and its derived signed packages. As promised in the -12 ublock request, we now have a lot more translations updated for the changed template questions for os-prober. Also, I've included 1 RC bug fix which fixes up an RC bug which stops machines booting: * When *also* installing to the removable media path, include the relevant mokmanager binary. Closes: #1034409 And a small fix for generating boot menu options on systems dual-booting with Arch and derivatives: * Allow initrd to contain spaces. Closes: #838177, #820838. unblock grub2/2.06-13 unblock grub-efi-amd64-signed/1+2.06+13 unblock grub-efi-arm64-signed/1+2.06+13 unblock grub-efi-ia32-signed/1+2.06+13 debdiff attached, filtering out noise from *.po updates. diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog --- grub2-2.06/debian/changelog 2023-04-21 13:30:26.0 +0100 +++ grub2-2.06/debian/changelog 2023-04-23 20:55:54.0 +0100 @@ -1,3 +1,35 @@ +grub2 (2.06-13) unstable; urgency=medium + + [ Steve McIntyre ] + * When *also* installing to the removable media path, include the +relevant mokmanager binary. Closes: #1034409 + + [ General Chaos ] + * Allow initrd to contain spaces. Closes: #838177, #820838. + + [ Translators ] + * Update lots of translations of debconf templates, thanks to the +following: ++ Welsh (Dafydd Tomos) ++ German (Helge Kreutzmann). Closes: #1034850 ++ Croatian (Tomislav Krznar) ++ Greek (Emmanuel Galatoulas) ++ Esperanto (Felipe Castro) ++ French (Baptiste Jammet). Closes: #1035761 ++ Italian (Luca Monducci). Closes: #1034825 ++ Kazakh (Baurzhan Muftakhidinov) ++ Korean (Changwoo Ryu). Closes: #1034868 ++ Latvian (Rudolfs Mazurs) ++ Dutch (Frans Spiesschaert). Closes: #1035399 ++ Norwegian Bokmål (Petter Reinholdtsen, Sverre Vaabenoe) ++ Brazilian Portuguese (Adriano Rafael Gomes). Closes: #1035905 ++ Romanian (Remus-Gabriel Chelu) ++ Russian (Yuri Kozlov). Closes: #1035294 ++ Turkish (Atila KOÇ). Closes: #1035846 ++ Swedish (Luna Jernberg) + + -- Steve McIntyre <93...@debian.org> Sun, 23 Apr 2023 20:55:54 +0100 + grub2 (2.06-12) unstable; urgency=medium * Fix up arm64 SB patch to fix build failure on 32-bit arm systems diff -Nru grub2-2.06/debian/patches/grub-install-removable-shim.patch grub2-2.06/debian/patches/grub-install-removable-shim.patch --- grub2-2.06/debian/patches/grub-install-removable-shim.patch 2023-02-09 01:32:18.0 + +++ grub2-2.06/debian/patches/grub-install-removable-shim.patch 2023-04-23 20:55:54.0 +0100 @@ -107,7 +107,7 @@ fb_src = grub_util_path_concat (2, "/usr/lib/shim/", fb_signed); -@@ -2154,30 +2152,81 @@ main (int argc, char *argv[]) +@@ -2154,30 +2152,82 @@ main (int argc, char *argv[]) if (!removable) grub_install_copy_file (fb_src, fb_dst, 0); @@ -129,6 +129,7 @@ + also_install_removable (shim_signed, base_efidir, removable_file, 1); + + also_install_removable (efi_signed, base_efidir, chained_base, 1); ++ also_install_removable (mok_src, base_efidir, mok_file, 0); + + /* If we're updating the NVRAM, add fallback too - it + will re-update the NVRAM later if things break */ diff -Nru grub2-2.06/debian/patches/os-prober-Allow-initrd-to-contain-spaces.patch grub2-2.06/debian/patches/os-prober-Allow-initrd-to-contain-spaces.patch --- grub2-2.06/debian/patches/os-prober-Allow-initrd-to-contain-spaces.patch 1970-01-01 01:00:00.0 +0100 +++ grub2-2.06/debian/patches/os-prober-Allow-initrd-to-contain-spaces.patch 2023-04-23 20:55:54.0 +0100 @@ -0,0 +1,50 @@ +From 1f982e2a7c35e14d5a92c76db998afafd1bd9e87 Mon Sep 17 00:00:00 2001 +From: General Chaos +Date: Tue, 12 Apr 2016 22:28:52 + +Subject: [PATCH] os-prober: Allow initrd to contain spaces + +linux-boot-prober produces structured output with newline-terminated rows +representing kernels, each with colon-delimited columns. We translate +this into a sequence of space-separated words representing kernels, +each containing colon-delimited fields where spaces are represented by +carets. + +When we parse each of those words into colon-delimited fields, if the +field could conceivably contain spaces then we need to translate +carets back into spaces. We did this for label and parameters, but not +for the initrd. + +In particular, when CPU microcode is installed on Arch Linux or its +derivatives, they write CPU microcode into one initrd archive and the +rest of early user-space into another, instead of concatenating the +archives into a single file like Debian derivatives do. To boot Arch +s
Bug#1034763: unblock: grub2/2.06-12
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package grub2 We've pulled in some really important fixes for GRUB, that I think are important and should definitely be part of the bookworm release: * Fix an issue where a logical volume rename would lead grub to fail to boot (#987008) * Add a final patch needed to make arm64 Secure Boot work (#1020769) * Backport some upstream patches to fix probing of LUKS2 devices (#1028301), add luks2 to the signed EFI images (#1001248) * Add debconf logic to control os-prober use (#1031594, #1012865, #1025698). This dovetails with an update to grub-installer in d-i. I've also added a small but important change to config_item() in the postinst, which makes things much more robust. Without this, grub-install on systems with Xen installed can fail unexpectedly. And there's a trivial change to not warn about os-prober if it's not installed (#1033657). The os-prober fixes are a major change that I think we need for bookworm. The default has changed in GRUB upstream, and this will cause a lot of user confusion (on new installations particularly) where they're trying to do dual-boot. I'm asking for an unblock *now* for these changes, so that people can review them. The os-prober update includes a new debconf template that we'll want translations for (and hence another/more grub upload(s) before release), but of course they should be ~zero-risk at that point. [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock grub2/2.06-12 unblock grub-efi-amd64-signed/1+2.06+12 unblock grub-efi-arm64-signed/1+2.06+12 unblock grub-efi-ia32-signed/1+2.06+12 debdiff attached, filtering out noise from *.po updates. grub2_2.06-12.debdiff.gz Description: application/gzip
Re: 11.7 planning + bookworm planning
On Sun, Apr 23, 2023 at 09:13:40PM +0200, Paul Gevers wrote: >Hi all, > >Let's book June 10 as the bookworm release date. A more formal announcement >will follow. \o/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: 11.7 planning + bookworm planning
On Thu, Apr 20, 2023 at 08:20:51PM +0200, Paul Gevers wrote: >Hi all, > >TL;DR: ftp & press input for June needed. > >On 20-04-2023 18:29, Adam D. Barratt wrote: >> The 13th does seem a bit close now, without having announced. > >After some consideration today, and the vibe felt in this discussion, let's >not rush this, so let's skip May 13 (also giving Press some time, see below). > >> 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. > >Jonathan (DPL) mentioned earlier: >""" >Press team is in some slight limbo at the moment, I hope to help fix that >after the DPL election is over, in the mean time, it might be a good idea not >to block on them. >""" >If press is "really a requirement", we'll have to wait until this is settled. > >From the CD side we know that with May 13 out, the rest of May is also out. >So we're looking for a date in June. For June, starting with 10, we have: >kibi - 10, 17, 24d-i >Luna - 10, 17, 24CD testing >elbrus- 10, 24release team >adsb - 10, 17, 24release team Sledge - 10, 17, 24images team -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: 11.7 planning + bookworm planning
On Thu, Apr 20, 2023 at 11:32:49AM +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. > >Which leaves finding a date (and me learning what to do :) ). OK... >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. What do >we think? I'm still OK for the 13th. >If we have somebody from CD to do 27 (yes, I remember Sledge can't >do that one), that would be great as it would be my preference; I'll have >lots of Debian people physically around me. As the DPL mentioned, we might >not want to block on press availability, although it would be real great if >we had them. Unfortunately, the other person on the images team who has the knowledge to do a release (Andy) is also away - we're on the same vacation! May 27 and June 3 are both out for that reason. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Re: 11.7 planning + bookworm planning
Hey Paul, Nobody else seems to have replied yet, so... :-) On Thu, Mar 23, 2023 at 01:31:22PM +0100, Paul Gevers wrote: >Hi, > >With the point release scheduled for April 29th, it's probably good to have >at least one weekend in between, or do people not mind doing two weekends in >a row? Definitely *not* two weekends on the run, please! >On 17-03-2023 15:59, Steve McIntyre wrote: >> On Thu, Mar 16, 2023 at 11:26:00AM +0100, Paul Gevers wrote: >> > So, shall we add availability for May too? 6th, 13th, 20th (Ascension >> > weekend), and 27th (coincides with DebianReunionHamburg)? >> >> I could do the 6th and 13th, but I'm away on vacation 20th and 27th >> (and 3rd June). > >If I did the bookkeeping correctly, the missing necessary teams are press and >release team, as I now have: >kibi - 6, 13, 20, 27 d-i >mhy - 6, 13, 20, 27 ftp >Sledge- 6, 13 CD >Luna - 6, 20 CD testing > >I can help 6 (probably), 13 and 27, but I don't have the signing key and I >haven't witnessed all details from our side so I'm not comfortable doing it >alone even if I could get my hands on the key. > >elbrus-13, 27 release team 13th could work. I'll admit I'm a little anxious about the amount of work needed before release, but tbh that's not a new thing here... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: 11.7 planning + bookworm planning
On Thu, Mar 16, 2023 at 11:26:00AM +0100, Paul Gevers wrote: > >From where I'm looking, bookworm is looking pretty good. Obviously we'll have >to follow through on the flurry of unblock requests that came in after the >hard freeze, but that should be manageable in a couple of weeks. kibi just >told me on IRC that asking this question now is not crazy from a d-i point of >view. That hopefully means that around the end of April, also the bookworm >d-i should™ be ready for release (kibi, I'm sure you'll comment on this if I >got you wrong or if you want to provide more details). > >So, shall we add availability for May too? 6th, 13th, 20th (Ascension >weekend), and 27th (coincides with DebianReunionHamburg)? I could do the 6th and 13th, but I'm away on vacation 20th and 27th (and 3rd June). -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
Re: 11.7 planning
On Wed, Mar 15, 2023 at 08:33:47PM +, Jonathan Wiltshire wrote: >Hi, > >We're overdue for 11.7 and need it done with a keyring update included >before bookworm can be released. The wheels are turning on the keyring so >how do dates in April look for everybody? Saturdays are 1st (probably too >soon), 8th, 15th, 22nd and 29th. I think I'm clear for any of: 8th 22nd 29th -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: https://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you.
Bug#1032849: unblock: shim/15.7-1 (etc.)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: debian-...@lists.debian.org Hi! Please unblock our stack of shim and shim-signed packages. We finally have new signed shim binaries and there's a lot of major bugfixes included which cascade down: shim (15.7-1) unstable; urgency=medium * New upstream release fixing more bugs * Add further patches from upstream: + Make sbat_var.S parse right with buggy gcc/binutils + Enable NX support at build time, as required by policy for signing new shim binaries. * Switch to using gcc-12. Closes: #1022180 * Update to Standards-Version 4.6.2 (no changes needed) * Block Debian grub binaries with sbat < 4 (see #1024617) shim-signed (1.39) unstable; urgency=medium * Build against new signed binaries corresponding to 15.7-1 + This syncs up build-deps again. Closes: #1016280 + We now have arm64 signed shims again \o/ Undo the hacky unsigned arm64 build Closes: #1008942, #992073, #991478 Pulls multiple other bugfixes in for the signed version: + Make sbat_var.S parse right with buggy gcc/binutils + Enable NX support at build time, as required by policy for signing new shim binaries. + Fixes argument handling bug with some firmware implementations. Closes: #995940 * Update build-dep on shim-unsigned to use 15.7-1 * Block Debian grub binaries with sbat < 4 (see #1024617) + Update Depends on grub2-common to match. * postinst/postrm: make config_item() more robust * Add pt_BR translation, thanks to Paulo Henrique de Lima Santana. Closes: #1026415 * Tweak dependencies unblock shim/15.7-1 unblock shim-signed/1.39 unblock shim-helpers-amd64-signed/1+15.7+1 unblock shim-helpers-arm64-signed/1+15.7+1 unblock shim-helpers-i386-signed/1+15.7+1
Re: bookworm release date?
On Thu, Mar 09, 2023 at 05:05:28PM +, Adam Barratt wrote: > >Sorry for the delayed reply, apparently I'm further behind than I >realised. :-( :-/ *hugs* >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. :-) :-) I uploaded the latest signed shim last night expressly to have it in the next bullseye point release. Do you want an unblock for that? I'm also looking at some (small!) updates for grub too. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Re: bookworm release date?
Hey folks, Cyril and I are in broad agreement on stuff, just adding a couple of points... On Fri, Feb 17, 2023 at 11:44:47PM +0100, Cyril Brulebois wrote: >Hi Paul, > >Paul Gevers (2023-02-17): >> Yes, I know the debian-installer is not a done deal, so kibi, please >> let us know where you think we stand with d-i (briefly is OK, I know >> you normally report extensively elsewhere) and when you think d-i can >> realistically be in a releasable state. (Saying: "in June" is fine, >> than we can plan accordingly). > >BEGIN VERY WILD GUESS > >With a release going out this week-end, I think the next one with >bugfixes or improvements based on user or developer feedback couldn't >happen before 2 weeks. And I'd expect 2 more releases after that to iron >things out, with at least 1 week between each. > >That'd mean end of March, beginning April at the soonest. > >Depending on what we encounter, and possible changes in other packages >in the archive, we might have various delays, so it's probably best to >add 2-4 extra weeks to that. +1 >I'll let Steve comment on the bootloader aspect (brand new shim just >arrived, not sure how much time / how many iterations we might need to >get it in shape for bookworm; plus we've gotten some fixes in grub but I >think some further changes are planned). Exactly. I'm just doing the packaging updates for shim-signed now, and obviously I'll be doing a lump of testing too. I don't expect any more updates for *shim* itself before bookworm, but there might be a couple of rounds of bugfixing and testing for shim-signed here. Grub could do with a bit more effort. There are a few edge-cases I'd like to pick up on, and (as you know!) quite a few RC bugs yet. Now we have a working arm64 shim, I suspect there will be a little more work needed to validate arm64 SB; I think we might be missing some needed patches there. Maybe 3-4 weeks for grub stuff altogether . -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Bug#1031361: unblock: grub2/2.06-8
On Wed, Feb 15, 2023 at 07:16:18PM +0100, Sebastian Ramacher wrote: >On 2023-02-15 17:16:46 +0000, Steve McIntyre wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Hey folks! >> >> Please unblock package grub2 >> >> We have a slew of bug fixes that we want in bookworm: >> >> * Fix an issue in an f2fs security fix which caused mount >> failures. Closes: #1021846. Thanks to программист некто for helping >> to debug the problem! >> * Switch build-deps from gcc-10 to gcc-12. Closes: #1022184 >> * Include upstream patch to enable EFI zboot support on arm64. >> Closes: #1026092 >> * grub-mkconfig: Restore umask for the grub.cfg. CVE-2021-3981 >> Closes: #1001414 >> * postinst: be more verbose when using grub-install to install onto >> devices. >> * /etc/default/grub: Fix comment about text-mode console. >> Fixes #845683 >> * grub-install: Don't install the shim fallback program when called >> with --removable. Closes: #1016737 >> * grub-install: Don't use our grub CD EFI image for --removable. >> Closes: #1026915. Thanks to Pascal Hambourg for the patch. >> * Ignore some new ext2 flags to stay compatible with latest mke2fs >> defaults. Closes: #1030846 >> >> Several of these are major issues for people affected, particularly >> #1030846. We'd like to get the new version in to work with the next >> d-i release please. Kibi is already aware! > >Thanks for the 3 RC bug fixes. It should migrate in the next migration >run. Thanks, that did! But I wasn't paying enough attention and forgot to also ask for the related: unblock grub-efi-amd64-signed/1+2.06+8 unblock grub-efi-arm64-signed/1+2.06+8 unblock grub-efi-ia32-signed/1+2.06+8 Could you also add those please? -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Bug#1031361: unblock: grub2/2.06-8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hey folks! Please unblock package grub2 We have a slew of bug fixes that we want in bookworm: * Fix an issue in an f2fs security fix which caused mount failures. Closes: #1021846. Thanks to программист некто for helping to debug the problem! * Switch build-deps from gcc-10 to gcc-12. Closes: #1022184 * Include upstream patch to enable EFI zboot support on arm64. Closes: #1026092 * grub-mkconfig: Restore umask for the grub.cfg. CVE-2021-3981 Closes: #1001414 * postinst: be more verbose when using grub-install to install onto devices. * /etc/default/grub: Fix comment about text-mode console. Fixes #845683 * grub-install: Don't install the shim fallback program when called with --removable. Closes: #1016737 * grub-install: Don't use our grub CD EFI image for --removable. Closes: #1026915. Thanks to Pascal Hambourg for the patch. * Ignore some new ext2 flags to stay compatible with latest mke2fs defaults. Closes: #1030846 Several of these are major issues for people affected, particularly #1030846. We'd like to get the new version in to work with the next d-i release please. Kibi is already aware! unblock grub2/2.06-8
Re: Shim and secure boot status, leading up to bookworm
Hi Jeremy, On Wed, Jan 25, 2023 at 12:40:07PM -0700, Jeremy Hall wrote: > >When things get built, will there be a path forward for people who >might need grub modules like serial console for accessibility reasons? The serial module has already been added to the signed grub binary a while back (2.06-4). If you need anything else, please ask or file bugs. In the longer term, some grub upstream developers are working on adding support for signing grub modules individually that might make it possible for people to add more themselves. But that's not going to happen before bookworm. HTH! -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Re: Shim and secure boot status, leading up to bookworm
Hey Antonio, On Wed, Jan 25, 2023 at 04:17:50PM -0300, Antonio Terceiro wrote: >On Wed, Jan 25, 2023 at 06:11:45PM +0000, Steve McIntyre wrote: >> >> The MS and cert issues are now both resolved, and I'm now working on a >> shim *15.7* upload. There's a little more work and testing to do, but >> I'm not far off. Yay? > >Have the issues with arm64 been fixed? Will this release provide a >signed arm64 shim? We should have a signed shim for arm64, yes. I need to test end to end again yet; I think we're still missing some arm64 SB patches for grub. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Rarely is anyone thanked for the work they did to prevent the disaster that didn’t happen.” -- Mikko Hypponen (https://twitter.com/mikko/)
Shim and secure boot status, leading up to bookworm
Hey all! Here's a status update and plans for SB and shim. If any of this is unclear or you have doubts, please say! We currently have *signed* shim *15.4* packages in the archive, for all of buster, bullseye, bookworm and sid. That works OK at the moment, but is getting old (July 2021) and needs updating soonish. I uploaded shim *15.6* in July 2022 and we attempted to get that signed too. Reviews were positive, but due to process problems around Microsoft uploads and then a long delay on getting a needed EV certificate renewed we never managed to get that signed. :-( The MS and cert issues are now both resolved, and I'm now working on a shim *15.7* upload. There's a little more work and testing to do, but I'm not far off. Yay? However, there are a couple of caveats to this... SBAT update --- The new shim build will need to block SB execution of older grub builds (anything with an SBAT level for grub.debian < 4). The oldest builds that will continue to work are: * 2.06-6 (unstable/bookworm) * 2.06-3~deb11u5 (bullseye) * 2.06-3~deb10u3 (buster) This is hopefully not unexpected, but I'm sharing here to be 100% clear. I'm planning on doing shim 15.7 builds for bullseye and buster again, so these all matter here. NX -- At the end of November 2022 (while unable to get anything signed) we passed a deadline; new shims since that point must be built with NX support enabled, and flagged as such. This extra hardening should improve security more, so it's not a bad thing in general. *However*, it does have consequences - once shim is loaded by UEFI firmware and started with NX enabled, all the UEFI binaries downstream of it *also* have to support NX as well. Patches for grub and linux are under discussion at the moment, but AFAIK not yet released; I need to check on the status of fwupd-efi too. What does this mean for us? * Older machines with older firmware will continue to work just fine. * New-enough machines with firmware that enables NX will fail to boot until we get full NX support through our boot chain. :-( There's a mitigating factor here: *such* new machines may already reject our older signed binaries anyway. We're stuck in a bad situation here I'm afraid; I think the only sensible way is forward, applying NX patches as soon as they're ready. Thoughts? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian" signature.asc Description: PGP signature
Re: YA Grub update for bullseye (and buster!)
On Fri, Dec 09, 2022 at 03:22:13PM +0100, Salvatore Bonaccorso wrote: >Hi Steve, > >On Thu, Dec 08, 2022 at 02:47:59PM +0000, Steve McIntyre wrote: >> On Thu, Dec 08, 2022 at 08:36:50AM +0100, Salvatore Bonaccorso wrote: >> >Hi Steve, >> >On Thu, Dec 08, 2022 at 12:15:57AM +, Steve McIntyre wrote: >> >> >> >> * Buster just needs another upload to buster-security, I believe? >> > >> >Yes exactly, let me know if you need help with the DLA release. >> >> I've just uploaded now. Help with the DLA would be nice, thanks! > >Ok will do. We need to wait for the signed packages yet. ACK. >FTP-masters, can you have a look? Let's hope so! There'll be several sets waiting now, I hope. -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: YA Grub update for bullseye (and buster!)
On Thu, Dec 08, 2022 at 05:01:47PM +, Adam Barratt wrote: >On Thu, 2022-12-08 at 14:47 +0000, Steve McIntyre wrote: >> On Thu, Dec 08, 2022 at 08:36:50AM +0100, Salvatore Bonaccorso wrote: >> > Hi Steve, >> > On Thu, Dec 08, 2022 at 12:15:57AM +, Steve McIntyre wrote: >[...] >> > > * What's the preferred way to go for Bullseye, given we're just >> > > about >> > >to do another point release? Should I go down the security >> > > path or >> > >just upload straight to bullseye and go via s-p-u? >> > >> > I think for this one (and give the timeframe for the point >> > release), a >> > stable-proposed-updates is more appropriate. I agree, the >> > functional >> > regression is caused by the security fix, but to me it looks enough >> > that we can go here the point release path (unless a SRM now >> > strongly >> > disagrees). The window is closing this weekend for the uploads. >> >> ACK. I'll give Adam a short while to chime in... > >I was going to say I'd defer to the security team when I read the >initial mail, so... either way works for me, as long as it happens >soonish. ACK, I'll go ahead with the stable-proposed-updates upload now then. Cheers! -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: YA Grub update for bullseye (and buster!)
On Thu, Dec 08, 2022 at 08:36:50AM +0100, Salvatore Bonaccorso wrote: >Hi Steve, >On Thu, Dec 08, 2022 at 12:15:57AM +, Steve McIntyre wrote: >> >> * Buster just needs another upload to buster-security, I believe? > >Yes exactly, let me know if you need help with the DLA release. I've just uploaded now. Help with the DLA would be nice, thanks! >> * What's the preferred way to go for Bullseye, given we're just about >>to do another point release? Should I go down the security path or >>just upload straight to bullseye and go via s-p-u? > >I think for this one (and give the timeframe for the point release), a >stable-proposed-updates is more appropriate. I agree, the functional >regression is caused by the security fix, but to me it looks enough >that we can go here the point release path (unless a SRM now strongly >disagrees). The window is closing this weekend for the uploads. ACK. I'll give Adam a short while to chime in... -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
YA Grub update for bullseye (and buster!)
[ Trying again without typos in addresses! ] Hey folks, As you (might?) have seen, since the most recent set of security patches went into Grub (2.06-3~deb10u2, 2.06-3~deb11u4 and 2.06-5) I've been working on fixing up some of the fallout from the now locked-down font loader. The current state of the art in unstable (2.06-7) works fine AFAICS, with no more bugs complaining about messed-up fonts and graphics. I'm happy with things there for now, although there are likely to be yet be more tweaks before we freeze. Meh, that's pain for another day. :-) So, for Bullseye and Buster: I'm ready to add the new patches in to both to fix up font handling. We also *must* do a new release in both to bump SBAT level due to my unfortunate mistake in the last Buster upload (#1024617). :-( I'm just about ready to do builds and uploads now, so... * Buster just needs another upload to buster-security, I believe? * What's the preferred way to go for Bullseye, given we're just about to do another point release? Should I go down the security path or just upload straight to bullseye and go via s-p-u? -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery signature.asc Description: PGP signature
Re: 11.6 planning
On Thu, Nov 17, 2022 at 09:33:33PM +, Adam Barratt wrote: >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. I'm away on a work trip on the 1st and 2nd, due back home sometime on the 3rd. I could do a release, but I'd be starting later than normal. Maybe Andy could start it and I'd catch up with him when I'm back. I'm busy on the evening of the 10th, but we can work around that if needed. The 17th looks clear and hence would be easiest for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
Bug#1020224: bullseye-pu: package grub2/2.06-3~deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi! It seems that we've broken booting Xen PVH hosts using grub-xen-host - see #1017944. The previous bullseye update (2.06-3~deb11u1) also pulled the same problem into bullseye. :-( The issue was caused by a change in the behaviour of dh_strip, and we missed this in grub packaging. I've just uploaded a fix to unstable for that bug, and here is a targeted fix for bullseye too. I've tested and it works. Please allow this into bullseye-updates too. Here's the trivial debdiff: diff -Nru grub2-2.06/debian/changelog grub2-2.06/debian/changelog --- grub2-2.06/debian/changelog 2022-08-01 20:26:34.0 +0100 +++ grub2-2.06/debian/changelog 2022-09-14 23:40:50.0 +0100 @@ -1,3 +1,11 @@ +grub2 (2.06-3~deb11u2) bullseye; urgency=high + + [ Steve McIntyre ] + * Don't strip Xen binaries so they work again. Closes: #1017944. +Thanks to Valentin Kleibel for the patch. + + -- Steve McIntyre <93...@debian.org> Wed, 14 Sep 2022 23:40:50 +0100 + grub2 (2.06-3~deb11u1) bullseye; urgency=medium [ Steve McIntyre ] diff -Nru grub2-2.06/debian/rules grub2-2.06/debian/rules --- grub2-2.06/debian/rules 2022-08-01 20:26:34.0 +0100 +++ grub2-2.06/debian/rules 2022-09-14 23:39:16.0 +0100 @@ -544,7 +544,7 @@ dh_bugfiles $(patsubst %,-N%,$(filter grub-efi-%-signed-template,$(BUILD_PACKAGES))) -A override_dh_strip: - dh_strip -X/usr/bin/grub-emu + dh_strip -X/usr/bin/grub-emu -X/usr/lib/grub-xen/grub-x86_64-xen.bin -X/usr/lib/grub-xen/grub-i386-xen_pvh.bin -X/usr/lib/grub-xen/grub-i386-xen.bin override_dh_shlibdeps: dh_shlibdeps -X.module
Re: Analysis: mismatched shim* packages vs. debian-installer (opu/pu)
Thanks for the analysis and confirmation! :-) On Thu, Sep 08, 2022 at 04:16:16PM +0200, Cyril Brulebois wrote: >Hi, > >This is just a summary (TL;DR at the bottom) of my findings from the >past few days, while preparing d-i for the upcoming point releases. I >thought I would share in case anyone (e.g. future self) wonders what >might happen again in the future if we get unlucky again. I'll focus on >bullseye but buster is similar. > >I've said a few times to my fellow release team members that packages in >(old-)proposed-updates could be accepted without an explicit ACK from me >since we could side-step buggy packages by feeding our apt calls some >pinning, preferring udebs from (old-)stable over those in (old-)p-u if >we spotted some problems during pre-upload building and testing. > >That doesn't work for packages that we list in Build-Depends, and >buildds have (old-)p-u configured, so we end up pulling packages from >there as long as they're installable. > >For shim* packages, that means the following, mismatched packages when >building the debian-installer package: > >Get: 138 http://deb.debian.org/debian bullseye-proposed-updates/main amd64 > shim-unsigned amd64 15.6-1~deb11u1 [439 kB] >Get: 139 http://deb.debian.org/debian bullseye-proposed-updates/main amd64 > shim-helpers-amd64-signed amd64 1+15.6+1~deb11u1 [301 kB] >Get: 140 http://deb.debian.org/debian bullseye/main amd64 > shim-signed-common all 1.38+15.4-7 [13.6 kB] >Get: 141 http://deb.debian.org/debian bullseye/main amd64 shim-signed > amd64 1.38+15.4-7 [320 kB] > >It's likely affecting all architectures where the d-i build pulls shim >packages (but I didn't check further than amd64): > >shim-signed [amd64 i386 arm64] > >To be extra sure, I've tried putting version restrictions to stick >to bullseye packages, but sbuild/apt bail out with broken packages, >as expected: > >sbuild-build-depends-main-dummy : Depends: shim-unsigned (< > 15.6-1~deb11u1) but 15.6-1~deb11u1 is to be installed > Depends: shim-helpers-amd64-signed (< > 1+15.6+1~deb11u1) but 1+15.6+1~deb11u1 is to be installed > >I've verified two things: > - switching to the non-default aptitude resolver lets sbuild find a > solution, but that could have other side effects (that I didn't > investigate); > - introducing pinning in the chroot configuration lets us stick to > bullseye packages, affecting only shim* packages. > >Of course, both rely on having admins around to tweak the config for >that particular build, which is far from ideal. > > >Let's see what shim packages look like: > > 1. shim-unsigned /usr/lib/shim/BOOTX64.CSV >shim-unsigned /usr/lib/shim/fbx64.efi >shim-unsigned /usr/lib/shim/mmx64.efi >shim-unsigned /usr/lib/shim/shimx64.efi > 2. shim-helpers-amd64-signed /usr/lib/shim/fbx64.efi.signed >shim-helpers-amd64-signed /usr/lib/shim/mmx64.efi.signed > 3. shim-signed/usr/lib/shim/shimx64.efi.signed > 4. shim-signed-common /usr/sbin/update-secureboot-policy > >And the combination above is permitted due to lax version dependencies. >As far as I understand (and `sbverify --list` on each `*.signed` file >seems to agree), (1) gets uploaded, results in (2) getting signatures >from the Debian infrastructure; while (3) and (4) need manual MS >approval and signature. > >In the debian-installer tree, after a build, there are no traces of shim >anywhere, which was a bit surprising at first; but it turns out that >build/util/efi-image is the sole user of shim files, and it concentrates >on /usr/lib/shim/shim.efi.signed, from the shim-signed binary, but >copying it under a different name in the build tree: > > https://salsa.debian.org/installer-team/debian-installer/-/blob/20210731+deb11u5/build/util/efi-image#L147-148 > > https://salsa.debian.org/installer-team/debian-installer/-/blob/20210731+deb11u5/build/util/efi-image#L156-157 > >TL;DR: Everything matches what was already assessed by Steve McIntyre: >mismatched shim* packages shouldn't be an issue from a d-i perspective, >we're “just using the old shim” (sorry, buster…). > > >Cheers, >-- >Cyril Brulebois (k...@debian.org)<https://debamax.com/> >D-I release manager -- Release team member -- Freelance Consultant -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Bug#1016672: bullseye-pu: package grub2/2.06-3~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hey folks, This is the current upstream version of grub2 (2.06), built for bullseye as an upgrade path from 2.04-20. I know we normally don't want to do this kind of thing, but I believe this is genuinely the best way to keep on top of grub2 security issues. Grub2 has had several sets of major security updates in the last couple of years, particularly relevant in Secure Boot terms (BootHole et al). Back before the bullseye release, Colin spent a *lot* of time rebasing security fixes from GRUB 2.04 onto the 2.02 that we were using in buster, and I know he was very worried about breaking some of them and maybe introducing new holes. AFAICS it worked ok that time, but... We're now on to upstream 2.06 in unstable and bookworm, and that's been the target for upstream hardening and patch work that's been needed for the latest round of CVEs. There's also been a lot of code scanning and static analysis done to find more issues before they becoms CVE-worthy, and that's great! There are some backported fixes to go into 2.04 and I've seen people talking about 2.02 as well. *However*, I'm very worried that we don't have the time and skills available to verify all the fixes against three different upstream releases :-(. The debdiff for the changes is way too large to include here. They're obviously not minimal. If you really want to see it, look at [1]. I've tested locally on various machines using both UEFI and BIOS boot, and all looks good here. The existing 2.06-3 package in bookworm that I based on seems stable enough. The only real change I've made to that (beyond usual backport noise) is to revert the change that disables os-prober by default. I don't think that change is suitable for a stable update. [1] https://jack.einval.com/tmp/grub2_2.06-3~deb11u1.debdiff.gz -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1016671: buster-pu: package grub2/2.06-3~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hey folks, This is the current upstream version of grub2 (2.06), built for buster as an upgrade path from 2.02+dfsg1-20+deb10u4. I know we normally don't want to do this kind of thing, but I believe this is genuinely the best way to keep on top of grub2 security issues. Grub2 has had several sets of major security updates in the last couple of years, particularly relevant in Secure Boot terms (BootHole et al). Back before the bullseye release, Colin spent a *lot* of time rebasing security fixes from GRUB 2.04 onto the 2.02 that we were using in buster, and I know he was very worried about breaking some of them and maybe introducing new holes. AFAICS it worked ok that time, but... We're now on to upstream 2.06 in unstable and bookworm, and that's been the target for upstream hardening and patch work that's been needed for the latest round of CVEs. There's also been a lot of code scanning and static analysis done to find more issues before they becoms CVE-worthy, and that's great! There are some backported fixes to go into 2.04 and I've seen people talking about 2.02 as well. *However*, I'm very worried that we don't have the time and skills available to verify all the fixes against three different upstream releases :-(. The debdiff for the changes is way too large to include here. They're obviously not minimal. If you really want to see it, look at [1]. I've tested locally on various machines using both UEFI and BIOS boot, and all looks good here. The existing 2.06-3 package in bookworm that I based on seems stable enough. The only real change I've made to that (beyond usual backport noise) is to revert the change that disables os-prober by default. I don't think that change is suitable for a stable update. [1] https://jack.einval.com/tmp/grub2_2.06-3~deb10u1.debdiff.gz -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: buster EOL (10.13) and 11.5 planning
Hey Adam! On Thu, Jul 28, 2022 at 05:09:52PM +0100, Adam 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 August 20th or September 10th work best for me, with a slight preference for the latter so we have as much time as possible for shim signing in the two releases. I can do September 3rd at a push, but it will be difficult for me to commit to a double release that weekend as I have plans on Sunday 4th. >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. Happy to do a double release on 20/08 or 10/09, or a single release or 03/09. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub) signature.asc Description: PGP signature
Bug#1016179: bullseye-pu: package shim/15.6-1~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu This is a new upstream version of shim, built for bullseye. This is needed for better handling of SBAT-based revocations, plus a range of security updates from upstream. See attached debdiff for the changes. They're not minimal, but in the case of shim we need to be as close to upstream as possible for the sake of getting stuff reviewed and signed. The only local patches now are to revert arm64 build changes so we can still build on bullseye. I've tested locally on various machines and all looks good here. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled shim_15.6-1~deb11u1.debdiff.gz Description: application/gzip
Bug#1016178: buster-pu: package shim/15.6-1~deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu This is a new upstream version of shim, built for buster. This is needed for better handling of SBAT-based revocations, plus a range of security updates from upstream. See attached debdiff for the changes. They're not minimal, but in the case of shim we need to be as close to upstream as possible for the sake of getting stuff reviewed and signed. The only local patches now are to revert arm64 build changes so we can still build on buster. I've tested locally on various machines and all looks good here. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled shim_15.6-1~deb10u1.debdiff.gz Description: application/gzip
Bug#1016176: Acknowledgement (buster-pu: package mokutil/0.3.0+1538710437.fb6250f-1)
Control: retitle -1 buster-pu: package mokutil/0.6.0-2~deb10u1 Gah, forgot to set the version when using reportbug :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Bug#1016177: bullseye-pu: package mokutil/0.6.0-2~deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu This is a new upstream version of mokutil, built for bullseye. We need this new version to add support for managing SBAT, the new way to revoke things with UEFI Secure Boot. This is necessary to match up with the new shim 15.6 release. See attached debdiff for the changes. They're not *strictly* minimal, but I'm not confident about splitting out the changes individually here. It's a small, self-contained utility. I've tested locally on a bullseye machine and all looks good here. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled mokutil_0.6.0-2~deb11u1.debdiff.gz Description: application/gzip
Bug#1016176: buster-pu: package mokutil/0.3.0+1538710437.fb6250f-1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu This is a new upstream version of mokutil, built for buster. We need this new version to add support for managing SBAT, the new way to revoke things with UEFI Secure Boot. This is necessary to match up with the new shim 15.6 release. See attached debdiff for the changes. They're not *strictly* minimal, but I'm not confident about splitting out the changes individually here. It's a small, self-contained utility. I've tested locally on a buster machine and all looks good here. -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.15-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled mokutil_0.6.0-2~deb10u1.debdiff.gz Description: application/gzip
Re: 11.4 planning
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. :-/
* 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.
* 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.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, and wiser people so full of doubts."
-- Bertrand Russell
Re: 11.3 and 10.12 planning
On Sun, Mar 06, 2022 at 09:51:57PM +, Adam Barratt wrote: >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 The 19th is awkward for me (and Andy S!) - prior commitments. The others look OK for me. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr
On Sat, Dec 04, 2021 at 10:42:29PM +, Steve McIntyre wrote: >On Sat, Dec 04, 2021 at 11:37:28PM +0100, Pascal Hambourg wrote: >>Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : >>> >>> >>> c) parse /target/etc/fstab, and attempt to mount other partitions >> >>The rescue system already offers to do it for separate /boot and /boot/efi, >>so why couldn't it do for separate /usr too ? > >That's exactly what I'm about to do. In fact, it needed more work than that - the code chrooted into /target and ran mount there. That didn't work for a separate /usr. But I've refactored the code and made things work more cleanly inside d-i. I'm pondering backporting the same fix for future bullseye and buster point releases. -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: Bug#1000239: Rescue system won't find root partition, but insists on /usr
On Sat, Dec 04, 2021 at 11:37:28PM +0100, Pascal Hambourg wrote: >Le 03/12/2021 à 22:08, Nicholas D Steeves a écrit : >> >> >> c) parse /target/etc/fstab, and attempt to mount other partitions > >The rescue system already offers to do it for separate /boot and /boot/efi, >so why couldn't it do for separate /usr too ? That's exactly what I'm about to do. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Re: 11.2 planning
Hey Adam! On Tue, Nov 23, 2021 at 08:12:11PM +, Adam Barratt wrote: > >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 4th December is a no-go for me, but the 11th and 18th look OK. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Re: Debian 11 images for AWS m6i instances
Hi Giambattista, On Thu, Oct 14, 2021 at 10:32:50AM +0100, Giambattista Piranesi wrote: >I've noticed there are no official Debian 11 (Bullseye) images on AWS >compatible with m6i instances. > >Any chance to generate a m6-ready Debian 11 AMI? What does it depend? The best place to ask about this is the debian-cloud list (in CC). -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: 11.1 and 10.11 planning]
Forwarding to the lists Andy forgot... - Forwarded message from Andy Simpkins - From: Andy Simpkins To: debian...@lists.debian.org Date: Wed, 15 Sep 2021 20:53:41 +0100 Subject: Re: 11.1 and 10.11 planning Message-ID: <717ba215-4bcc-08ab-b087-8f781f15c...@koipond.org.uk> On 14/09/2021 20:14, Steve McIntyre wrote: > On Tue, Sep 14, 2021 at 07:04:11PM +0100, Adam Barratt wrote: > > 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.) > > I'm happy either way, I think Andy was less sure in the case that we > got him to do both? :-) > given that Steve will be around I am happy for both in one day :-) /Andy - End forwarded message - -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: 11.1 and 10.11 planning
On Tue, Sep 14, 2021 at 07:04:11PM +0100, Adam Barratt wrote: >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.) I'm happy either way, I think Andy was less sure in the case that we got him to do both? :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Re: 11.1 and 10.11 planning
On Mon, Sep 06, 2021 at 12:51:07PM +0100, Adam Barratt wrote: >Hi, > >We've ended up being late with planning 10.11 due to the timing of the >bullseye release, and also need to look at getting 11.1 sorted. > >Traditionally, we've combined stable and oldstable point releases (at >2- and 4-month cadences) while both are supported. That would still be >my preference, but I understand that not everyone on the Images side is >so keen on the idea. Open questions in addition to dates are therefore >whether we should do 10.11 and 11.1 on the same day and, if not, how >close together they should be. > >A few suggested dates to get things going: > >September 18th - not great; means freezing this coming weekend >September 25th - not great; I'm away during most of the week >beforehand, so will be unlikely to be able to deal with any issues, >make sure everything's ready, etc. >October 2nd - OK for me >October 9th - OK for me >October 16th - OK for me At this point I'm free for all of those weekends. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)
Bug#991804: unblock: debian-cd/3.1.25
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hi!
Please unblock package debian-cd
Here's the traditional last-minute request for a debian-cd unblock,
such that the version in the archive for our release is up to date
with the software that we use to create it!
Two key changes to see here:
* Add brltty and espeakup to all images from netinst up, for blind
users. Closes: #678065
* Add script to generate firmware metadata from appdata metadata,
and use it when building a media tree. See: #989863
Both are tested and known working already, as we use the version from
git to build our daily and weekly images.
Debdiff attached.
unblock debian-cd/3.1.25
-- System Information:
Debian Release: 10.10
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'),
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru debian-cd-3.1.34/debian/changelog debian-cd-3.1.35/debian/changelog
--- debian-cd-3.1.34/debian/changelog 2021-04-20 00:03:35.0 +0100
+++ debian-cd-3.1.35/debian/changelog 2021-07-26 01:02:03.0 +0100
@@ -1,3 +1,15 @@
+debian-cd (3.1.35) unstable; urgency=medium
+
+ [ Steve McIntyre ]
+ * Add brltty and espeakup to all images from netinst up, for blind
+users. Closes: #678065
+
+ [ Cyril Brulebois ]
+ * Add script to generate firmware metadata from appdata metadata,
+and use it when building a media tree. See: #989863
+
+ -- Steve McIntyre <93...@debian.org> Mon, 26 Jul 2021 01:02:03 +0100
+
debian-cd (3.1.34) unstable; urgency=medium
[ Wolfgang Schweer ]
@@ -10,7 +22,7 @@
* debian/control: Drop Recommends: on netpbm and syslinux-utils. These are no
longer needed now that custom splash images are used unmodified.
- [ Petter Reinholdtse ]
+ [ Petter Reinholdtsen ]
* Include eatmydata deb for d-i to use offline. Closes: #986772
[ Steve McIntyre ]
diff -Nru debian-cd-3.1.34/debian/control debian-cd-3.1.35/debian/control
--- debian-cd-3.1.34/debian/control 2021-03-22 14:20:37.0 +
+++ debian-cd-3.1.35/debian/control 2021-07-25 20:39:31.0 +0100
@@ -15,7 +15,7 @@
Package: debian-cd
Architecture: all
-Depends: ${misc:Depends}, curl, perl, dpkg-dev, cpp, libdigest-md5-perl,
libdigest-sha-perl, tofrodos, apt, make, xorriso | genisoimage, lynx,
grep-dctrl, bc, libcompress-zlib-perl, bzip2, libdpkg-perl, wget
+Depends: ${misc:Depends}, curl, perl, dpkg-dev, cpp, libdigest-md5-perl,
libdigest-sha-perl, tofrodos, apt, make, xorriso | genisoimage, lynx,
grep-dctrl, bc, libcompress-zlib-perl, bzip2, libdpkg-perl, wget,
libfile-slurp-perl, libyaml-libyaml-perl
Recommends: hfsutils, isolinux, syslinux-common, mtools, dosfstools
Description: Tools for building (Official) Debian CD set
Debian-cd is the official tool for building Debian CD set since the potato
diff -Nru debian-cd-3.1.34/tasks/bullseye/forcd1
debian-cd-3.1.35/tasks/bullseye/forcd1
--- debian-cd-3.1.34/tasks/bullseye/forcd1 2021-04-14 09:45:37.0
+0100
+++ debian-cd-3.1.35/tasks/bullseye/forcd1 2021-05-16 15:44:54.0
+0100
@@ -6,11 +6,7 @@
openssh-client
/* could be used by debconf in certain configurations */
libterm-readline-gnu-perl
-/* Accessibility stuff that is installed by base-installer
- * in certain situations, but too large for the netinst. */
-brltty
-espeakup
-alsa-utils
+
/* See rationale in #630805 */
apt-offline
diff -Nru debian-cd-3.1.34/tasks/kali-dev/forcd1
debian-cd-3.1.35/tasks/kali-dev/forcd1
--- debian-cd-3.1.34/tasks/kali-dev/forcd1 2021-04-14 09:45:37.0
+0100
+++ debian-cd-3.1.35/tasks/kali-dev/forcd1 2021-05-16 15:44:54.0
+0100
@@ -6,11 +6,7 @@
openssh-client
/* could be used by debconf in certain configurations */
libterm-readline-gnu-perl
-/* Accessibility stuff that is installed by base-installer
- * in certain situations, but too large for the netinst. */
-brltty
-espeakup
-alsa-utils
+
/* See rationale in #630805 */
apt-offline
diff -Nru debian-cd-3.1.34/tasks/kali-last-snapshot/forcd1
debian-cd-3.1.35/tasks/kali-last-snapshot/forcd1
--- debian-cd-3.1.34/tasks/kali-last-snapshot/forcd12021-04-14
09:45:37.0 +0100
+++ debian-cd-3.1.35/tasks/kali-last-snapshot/forcd12021-05-16
15:44:54.0 +0100
@@ -6,11 +6,7 @@
openssh-client
/* could be used by debconf in certain configurations */
libterm-readline-gnu-perl
-/* Accessibility stuff that is installed by base-installer
- * in certain situations, but too large for the netinst. */
-brltty
-espeakup
-alsa-utils
+
/* See rationale in #630805 *
Re: Finding a tentative bullseye release date
On Sat, Jul 17, 2021 at 10:25:17PM +0200, Paul Gevers wrote: >Hi all, > >On 11-07-2021 21:11, Paul Gevers wrote: >> With less than three weeks to go until the tentative release date, I >> would love to confirm the date by now, but there is a serious issue with >> crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what >> it means for solving the debian-installer blocking issues in time), I'm >> not aware of other blocking issues, so let's hope the teams involved can >> recover in time. > >Albeit there is some progress, we think it better for the people >involved to now say that we will *not* release on July 31. > >Unfortunately, that means that we have to start looking for a new date >again. Assuming what we'll learn in the upcoming week or two is good, I >propose to already start the list below with two weeks after the >previous date. Upcoming time is around DebConf, I can imagine it could >even be an advantage, especially as that's on-line, let's see. > >14 August (day before DebCamp) Works for me for images team >21 August (last day of DebCamp) > RT: elbrus Awkward - wife has plans for us that evening. >28 August (DebConf) > RT: elbrus Debian UK BBQ, argh >4 September > RT: elbrus Works fine for me >11 September: > RT: elbrus That's the week of my wedding anniversary, I'll be on VAC. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#990932: unblock: udpkg/1.20
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package udpkg
I've added locking for the status file, so parallel udpkg invocations
will not break the world. This fixes #987368. We definitely want this
fix for Bullseye. I've CC:ed KiBi too.
See attached debdiff.
unblock udpkg/1.20
-- System Information:
Debian Release: 10.10
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru udpkg-1.19/debian/changelog udpkg-1.20/debian/changelog
--- udpkg-1.19/debian/changelog 2018-09-23 18:16:44.0 +0100
+++ udpkg-1.20/debian/changelog 2021-06-11 02:46:39.0 +0100
@@ -1,3 +1,19 @@
+udpkg (1.20) unstable; urgency=medium
+
+ [ Holger Wansing ]
+ * Remove trailing whitespaces from changelog file, to fix lintian tag.
+
+ [ Cyril Brulebois ]
+ * Remove Christian Perrier from Uploaders, with many thanks for all
+his contributions over the years! (Closes: #927557)
+
+ [ Steve McIntyre ]
+ * Add locking for the status file, so parallel udpkg invocations
+will not break the world. Closes: #987368
+ * Add myself to Uploaders
+
+ -- Steve McIntyre <93...@debian.org> Fri, 11 Jun 2021 02:46:39 +0100
+
udpkg (1.19) unstable; urgency=medium
* Team upload.
@@ -374,7 +390,7 @@
udpkg (0.004) unstable; urgency=low
- * fixes builddeps (closes: #86934)
+ * fixes builddeps (closes: #86934)
-- Randolph Chung Wed, 21 Feb 2001 21:00:45 -0700
@@ -397,5 +413,3 @@
* Non-release.
-- Joey Hess Thu, 26 Oct 2000 12:02:04 -0700
-
-
diff -Nru udpkg-1.19/debian/control udpkg-1.20/debian/control
--- udpkg-1.19/debian/control 2018-08-10 20:25:18.0 +0100
+++ udpkg-1.20/debian/control 2021-06-10 23:04:38.0 +0100
@@ -2,7 +2,7 @@
Section: debian-installer
Priority: standard
Maintainer: Debian Install System Team
-Uploaders: Bastian Blank , Christian Perrier
+Uploaders: Bastian Blank , Steve McIntyre <93...@debian.org>
Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.7.0), libdebian-installer4-dev
(>= 0.41), dh-autoreconf
Vcs-Browser: https://salsa.debian.org/installer-team/udpkg
Vcs-Git: https://salsa.debian.org/installer-team/udpkg.git
diff -Nru udpkg-1.19/status.c udpkg-1.20/status.c
--- udpkg-1.19/status.c 2018-08-10 20:25:18.0 +0100
+++ udpkg-1.20/status.c 2021-06-11 00:45:35.0 +0100
@@ -1,9 +1,11 @@
#include "udpkg.h"
+#include
#include
#include
#include
#include
+#include
#include
/* Status file handling routines
@@ -19,8 +21,15 @@
*control info from (new) packages is merged into the status file,
*replacing any pre-existing entries. when a merge happens, status info
*read using the status_read function is written back to the status file
+ *
+ * There is also a pair of functions to lock and unlock access to the
+ * status, to protect against multiple invocations of udpkg racing
+ * against each other. Callers are responsible for using this locking
+ * around any code that works with the status file.
*/
+static int lock_fd = -1;
+
static const char *statuswords[][10] = {
{ (char *)STATUS_WANTSTART, "unknown", "install", "hold",
"deinstall", "purge", 0 },
@@ -208,6 +217,45 @@
}
}
+void status_lock(void)
+{
+ int error;
+ lock_fd = open(STATUSFILELOCK, O_WRONLY | O_CREAT, 0200);
+ if (lock_fd < 0)
+ {
+ fprintf(stderr, "Unable to open lockfile %s (%d), abort!",
+ STATUSFILELOCK, errno);
+ exit(1);
+ }
+ error = flock(lock_fd, LOCK_EX);
+ if (error < 0)
+ {
+ fprintf(stderr, "Unable to lock lockfile %s (%d), abort!",
+ STATUSFILELOCK, errno);
+ exit(1);
+ }
+}
+
+void status_unlock(void)
+{
+ int error;
+ if (lock_fd < 0)
+ {
+ fprintf(stderr, "Trying to unlock when we don't have the
lockfile %s open!",
+ STATUSFILELOCK);
+ exit(1);
+ }
+ error = flock(lock_fd, LOCK_UN);
+ if (error < 0)
+ {
+ fprintf(stderr, "Unable to unlock lockfile %s (%d), abort!",
+ STATUSFILELOCK, errno);
+ exit(1);
+ }
+ close(lock_fd);
+ lock_fd = -1;
+}
+
void *status_read(void)
{
FILE *f;
diff -Nru udpkg-1.19/udpkg.c udpkg-1.20/udpkg.c
--- udpkg-1.19/udpkg.c 20
Bug#990453: unblock: fwupd/1.5.7-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package fwupd fwupd and the matching signed packages need updating to match the latest SB requirements (new keys, SBAT, etc.) and there are also a couple of patches from the upstream stable branch to fix regressions. debdiff attached unblock fwupd/1.5.7-4 -- System Information: Debian Release: 10.10 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled fwupd_1.5.7-4.debdiff.gz Description: application/gzip
Re: Finding a tentative bullseye release date
On Tue, Jun 08, 2021 at 08:50:55PM +0200, Paul Gevers wrote: > >So, if I did all the booking right (including updates from IRC) we now have: > >26 June > [Ansgar (ftp), Sebastian (release), Adam (release)] >3 July > [Ansgar (ftp), Paul (release), Adam (release)] >10 July > [Steve + Andy (CD), Paul (release), Adam (release), Graham (release)] >17 July > [Steve (CD), press, Ansgar (ftp), Paul (release)] >24 July > [Steve (CD), press, Ansgar (ftp), Sebastian (release), > Graham (release)] >31 July > [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] >7 August > [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] >14 August > [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (release)] > >The first available date is 31 July, so let's shift all my dates another >week. >17 July: Hard Freeze & confirmation of the release date >31 July: ** tentative ** release date Cool, works for me. Pencilled into my calendar now. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: 10.10 planning
On Sun, May 30, 2021 at 05:41:54PM +0100, Adam Barratt wrote: >Hi, > >We're now a little overdue for 10.10, but it looks like we're ready in >terms of shim etc. changes, so we should look at dates. > >Please could you indicate your availability for (and any preferences >amongst) the following: > >Saturday June 12th >Saturday June 19th >Saturday June 26th > >The 12th is doable, but means we have to freeze next weekend; on that >basis I have a personal preference for the 19th, although I realise >that it's further out of cadence. 12th and 19th are fine for me, 26th not so much. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Finding a tentative bullseye release date
On Sun, May 30, 2021 at 09:09:28AM +0200, Paul Gevers wrote: >On 30-05-2021 06:35, Donald Norwood wrote: >> On 5/29/21 9:12 AM, Steve McIntyre wrote: >>> On Fri, May 28, 2021 at 10:17:55PM +0200, Paul Gevers wrote: >>>> Assuming all goes well >>>> with RC2 and RC3, we'd be looking at the following candidate release dates: >>>> >>>> 26 June >>>> 3 July >>>> 10 July >>>> 17 July >>>> 24 July >>>> >>>> Can you let us know which date work for you and which don't? > >[Steve] >>> I can do the >>> 17th and 24th of July just fine. > >Asking a question I think most people know the answer to, but CD without >Steve is no option? Don't get me wrong, I don't want to push otherwise, >but I just want to understand the options. So much in Debian is based on >"rituals", it's not always clear what's needed and what is just (nearly) >always done in a certain way. We've been slowly working up to getting other people able to do image releases, but I don't think we're *quite* there yet. Maybe on the next point release Andy could do it all without me watching and helping, but we want to work that out and I'm not sure a new major release is the right time to try this! Thinking about things some more, the 10th July is more of a "maybe" than a "no" - I'll be driving home from a vacation that day and available later in the day. We could possibly fit things in around that. >[Press] >> Press can do both the 17th and the 24th. Perhaps we add an additional 3 >> dates? > >Yes, let's do that, so the list becomes: > >26 June >3 July >10 July >17 July [Steve (CD), press] >24 July [Steve (CD), press] >31 July [Steve (CD)] >7 August [Steve (CD)] >14 August [Steve (CD)] I'm available for the later 3, no problems. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: Finding a tentative bullseye release date
Hey Paul! On Fri, May 28, 2021 at 10:17:55PM +0200, Paul Gevers wrote: > >On 24-04-2021 00:41, Donald Norwood wrote: >> Indeed, from this and the last few posts in the discussion it reads that >> perhaps June is the better option for the 'timed' ready when ready >> release date. > >The progress of fixing the blocking issues in the debian-installer is >good enough to start thinking again about a tentative bullseye release >date (see for more details in the quote below). Assuming all goes well >with RC2 and RC3, we'd be looking at the following candidate release dates: > >26 June >3 July >10 July >17 July >24 July > >Can you let us know which date work for you and which don't? Apologies - I'm unavailable for the first three of those. I can do the 17th and 24th of July just fine. >> I think it would allow for extra care to be given in the areas needed >> and would as Paul suggested allow the larger community to pull >> together to help resolve some of the issues. > >The installer team needs everybody's help to test the d-i release >candidates, to see if the issues that are being solved now are handled >correctly across as many different machines as possible. If anybody has >better ideas than the wiki page that kibi suggested in his e-mail below, >then let us know. Otherwise I'll probably see if I can set up something >like that shortly. > >Paul -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Re: Finding a tentative bullseye release date
Hey Paul and others! On Fri, Apr 09, 2021 at 08:47:21PM +0200, Paul Gevers wrote: >Dear release team, ftpmasters, press team, cd team, d-i team, > >The Release Team believes that the state of bullseye is pretty good. >Yes, there are some blocking bugs [1] and d-i and shim still need some >love, but the state is much better than we remembered from the same time >in buster. > >Last time in the buster release cycle, it took quite a while to pick a >release date once it was clear that buster could get released. As we >believe that shorter freeze period are better for the spirit of >contributors to Debian, we'd like to avoid such an unnecessary delay >again, and we'd want to pick a tentative release date. We call it >tentative, because it would be the date where we do the bullseye release >assuming that the identified issues are resolved by then and that we >don't find new blocking issues between now and two weeks before that >proposed date. So, the date would not be the set-in-stone release date, >but obviously it would become more solid as we get near it. > >We propose to aim for a release date in May. Would either of the >following work for you and do you have any preference? >- May 1 >- May 8 >- May 15 >- May 22 >- May 29 So far I'm available for all of those weekends, but for selfish reasons I'd prefer not to be busy on the weekend of the 29th. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: 10.9 planning
On Fri, Mar 19, 2021 at 05:18:43PM +0100, Julien Cristau wrote: >On Fri, Mar 19, 2021 at 04:14:31PM +0000, Steve McIntyre wrote: >> In fact, how about: we *could* go ahead with the 10.9 point release as >> already planned, and expect to do a 10.10 a couple of weeks later with >> basically *just* the shim/SB changes? I'm OK to go with that option if >> that's our preferred route as a group. >> >Is there actually a rush to get 10.10 out? Are people eager to push out >revocations? Or can we do it on our normal cadence, some time in May or >thereabouts, without adverse consequences? There's a distinct push to try and get things out ASAP so we can fix the revocation cycles killing EFI storage space. That's worrying a lot of people. I don't have a good idea of the ETA for issuing that last round of revocations, as that's a sore subject. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: 10.9 planning
On Fri, Mar 19, 2021 at 04:07:59PM +, Steve McIntyre wrote: >On Fri, Mar 19, 2021 at 12:24:45PM +, Adam Barratt wrote: >>Hi Steve, >> >>On Fri, 2021-03-19 at 11:42 +, Steve McIntyre wrote: >>> Houston, we have a problem. I know that you've announced the 27th for >>> the point release, but we're not going to have a new shim ready for >>> then. >>> >>> We've been hard at work testing and fixing things for the last couple >>> of weeks, but it's been slow going. We've *just* had a 15.3-rc3 >>> release candidate published last night. Even if that all looks OK and >>> we don't find any more bugs in testing (fingers crossed!), we're not >>> going to have a proper 15.3 release ready to go for >>> review/testing/signing in time for it to make it into a buster point >>> release next weekend. >> >>Thanks for the update. :-( >> >>Do you have a sense of when things _might_ be ready? Depending on >>timings it might be worth us getting the bulk of 10.9 out of the way >>and working out what to do about shim later on. > >At this point, I do not have a lot of confidence to pick a reliable >substitute date. Once we have a 15.3 release *done*, I'm thinking >adding a couple of weeks after that point is probably the most >sensible thing we can do. That's enough notice for the teams, I hope? >And it will be enough time to get stuff reviewed and signed. I'll be >one of the people driving the review process, and the reviews for this >round should be minimal - we'll be using a totally vanilla new release >with no local patches. > >I'll keep you updated as soon as i have any news. In fact, how about: we *could* go ahead with the 10.9 point release as already planned, and expect to do a 10.10 a couple of weeks later with basically *just* the shim/SB changes? I'm OK to go with that option if that's our preferred route as a group. (Obviously, either of these options will be eating into time for fixing things for a Bullseye release.) -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Re: 10.9 planning
On Fri, Mar 19, 2021 at 12:24:45PM +, Adam Barratt wrote: >Hi Steve, > >On Fri, 2021-03-19 at 11:42 +0000, Steve McIntyre wrote: >> Houston, we have a problem. I know that you've announced the 27th for >> the point release, but we're not going to have a new shim ready for >> then. >> >> We've been hard at work testing and fixing things for the last couple >> of weeks, but it's been slow going. We've *just* had a 15.3-rc3 >> release candidate published last night. Even if that all looks OK and >> we don't find any more bugs in testing (fingers crossed!), we're not >> going to have a proper 15.3 release ready to go for >> review/testing/signing in time for it to make it into a buster point >> release next weekend. > >Thanks for the update. :-( > >Do you have a sense of when things _might_ be ready? Depending on >timings it might be worth us getting the bulk of 10.9 out of the way >and working out what to do about shim later on. At this point, I do not have a lot of confidence to pick a reliable substitute date. Once we have a 15.3 release *done*, I'm thinking adding a couple of weeks after that point is probably the most sensible thing we can do. That's enough notice for the teams, I hope? And it will be enough time to get stuff reviewed and signed. I'll be one of the people driving the review process, and the reviews for this round should be minimal - we'll be using a totally vanilla new release with no local patches. I'll keep you updated as soon as i have any news. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: 10.9 planning
Hey folks, On Mon, Mar 15, 2021 at 02:36:47PM +, Steve McIntyre wrote: >On Mon, Mar 15, 2021 at 12:33:15PM +, Adam Barratt wrote: >>Hi, >> >>It's that time again, when we should look at organising the next point >>release. >> >>Please could you confirm your availability, and any preferences, for >>the following: >> >>- March 27th >>- April 3rd >>- April 10th >> >>I'd prefer to avoid April 10th if possible, for slightly selfish >>reasons. :-) > >Any of those are possible, but I'#d much prefer the 27th if >possible. The 3rd is Easter weekend, and I do have tentative plans. AAARGH. Houston, we have a problem. I know that you've announced the 27th for the point release, but we're not going to have a new shim ready for then. We've been hard at work testing and fixing things for the last couple of weeks, but it's been slow going. We've *just* had a 15.3-rc3 release candidate published last night. Even if that all looks OK and we don't find any more bugs in testing (fingers crossed!), we're not going to have a proper 15.3 release ready to go for review/testing/signing in time for it to make it into a buster point release next weekend. Sorry. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: 10.9 planning
On Mon, Mar 15, 2021 at 12:33:15PM +, Adam Barratt wrote: >Hi, > >It's that time again, when we should look at organising the next point >release. > >Please could you confirm your availability, and any preferences, for >the following: > >- March 27th >- April 3rd >- April 10th > >I'd prefer to avoid April 10th if possible, for slightly selfish >reasons. :-) Any of those are possible, but I'#d much prefer the 27th if possible. The 3rd is Easter weekend, and I do have tentative plans. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: referencing cloud images in bullseye release notes
On Mon, Mar 01, 2021 at 05:01:21PM +0200, Faidon Liambotis wrote: > >(I think #720989, #797342 and #819664 are probably broad enough that >capture these concerns as well, but if folks disagree I'd be happy to >file another bug for this.) My hope with #819664 was to *definitely* have some pages talking about the different cloud and container images too. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Bug#981381: nmu: cdebootstrap_0.7.7+b13
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hey folks, I've removed the hardcoded READSIZE limitation in libdebian-installer and uploaded that in version 0.121. To also fix this bug in cdebootstrap-static we'll need to binNMU this too: nmu cdebootstrap_0.7.7 . ANY . unstable . -m "Rebuild against libdebian-installer 0.121; Closes: #979226" The new libdebian-installer is already built and installed for all arches. Cheers, Steve -- System Information: Debian Release: 10.7 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#980458: buster-pu: package debian-installer-utils/1.132+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hey folks, I've fixed an important bug in d-i: missing support for USB UAS devices. With kibi's blessing, I've backported and tested this small change in debian-installer-utils so that we can fix this in buster too (#980455). Please accept this for the next point release. I've tested the changes and verified they work OK. I've uploaded this already to p-u. Here's the debdiff: diff -Nru debian-installer-utils-1.132/debian/changelog debian-installer-utils-1.132+deb10u1/debian/changelog --- debian-installer-utils-1.132/debian/changelog 2019-06-30 16:49:06.0 +0100 +++ debian-installer-utils-1.132+deb10u1/debian/changelog 2021-01-19 08:49:06.0 + @@ -1,3 +1,14 @@ +debian-installer-utils (1.132+deb10u1) buster; urgency=high + + * Team upload + + [ Steve McIntyre ] + * Backport from unstable: +list-devices-linux: Support partitions on USB UAS devices +Closes: #980455 + + -- Steve McIntyre <93...@debian.org> Tue, 19 Jan 2021 08:49:06 + + debian-installer-utils (1.132) unstable; urgency=high * Team upload diff -Nru debian-installer-utils-1.132/list-devices-linux debian-installer-utils-1.132+deb10u1/list-devices-linux --- debian-installer-utils-1.132/list-devices-linux 2018-07-13 01:04:46.0 +0100 +++ debian-installer-utils-1.132+deb10u1/list-devices-linux 2021-01-19 08:49:06.0 + @@ -197,9 +197,14 @@ fi # Disk partitions, but only on USB drives if ! $match && [ "$TYPE" = usb-partition ]; then - if device_info env "$devpath" | grep -q '^ID_BUS=usb' && \ - device_info env "$devpath" | grep -q '^ID_TYPE=disk'; then - match=: + if device_info env "$devpath" | grep -q '^ID_TYPE=disk'; then + if device_info env "$devpath" | grep -q '^ID_BUS=usb'; then + match=: + # USB UAS devices may show up as a different + # bus type here, so also look for "usb" in ID_PATH + elif device_info env "$devpath" | grep -q '^ID_PATH=.*usb'; then + match=: + fi fi fi if $match; then -- System Information: Debian Release: 10.7 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: 10.8 planning
Hey Adam, On Sat, Jan 16, 2021 at 02:38:13PM +, Adam Barratt wrote: >Hi, > >It's that time again, when we should get 10.8 out. > >Please could you confirm your availability, and any preferences, for >the following: > >- January 30th (would mean we would have to freeze next weekend, so a >bit tight) >- February 6th > >My personal preference would be the 6th. Either works for me, with a slight preference for the 30th. -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Bug#975425: buster-pu: package efivar/32-2+deb10u1
Hey Adam, On Tue, Nov 24, 2020 at 08:52:20PM +, Adam Barratt wrote: >Control: tags -1 + confirmed > >Hi, > >On Sun, 2020-11-22 at 02:54 +, Steve McIntyre wrote: >> I'd like to upload a stable update for efivar, with two (sets of) >> fixes backported from upstream. >> >> * Firstly, there's a simple initialisation fix to fix some possible >>crashes. >> >> * Secondly, there's support for newer systems that need extra NVME >>support doing device lookups. (#975417). This is an important >>update for supporting installation and boot on those new >>systems. The reporter of the bug has tested with test packages and >>all looks good. > >The metadata for #975417 implies that it still affects unstable. From >reading the bug log and your mail above I assume it's simply missing a >fixed version. Exactly, yes. >Assuming that's the case, please go ahead but please also fix the >metadata to more accurately reflect the situation. Will do, thanks! -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Bug#975425: buster-pu: package efivar/32-2+deb10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi folks,
I'd like to upload a stable update for efivar, with two (sets of)
fixes backported from upstream.
* Firstly, there's a simple initialisation fix to fix some possible
crashes.
* Secondly, there's support for newer systems that need extra NVME
support doing device lookups. (#975417). This is an important
update for supporting installation and boot on those new
systems. The reporter of the bug has tested with test packages and
all looks good.
Debdiff attached.
-- System Information:
Debian Release: 10.6
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru efivar-37/debian/changelog efivar-37/debian/changelog
--- efivar-37/debian/changelog 2019-03-01 17:55:07.0 +
+++ efivar-37/debian/changelog 2020-11-22 00:03:59.0 +
@@ -1,3 +1,13 @@
+efivar (37-2+deb10u1) buster; urgency=medium
+
+ * Backport important fixes from unstable:
++ fix uninitialized variable in parse_acpi_root, saving possible
+ segfault.
++ Add support for nvme-fabrics and nvme-subsystem devices. Closes:
+ #975417
+
+ -- Steve McIntyre <93...@debian.org> Sun, 22 Nov 2020 00:03:59 +
+
efivar (37-2) unstable; urgency=medium
* Cherry-pick fix from upstream:
diff -Nru
efivar-37/debian/patches/0001-Fix-the-error-path-in-set_disk_and_part_name.patch
efivar-37/debian/patches/0001-Fix-the-error-path-in-set_disk_and_part_name.patch
---
efivar-37/debian/patches/0001-Fix-the-error-path-in-set_disk_and_part_name.patch
1970-01-01 01:00:00.0 +0100
+++
efivar-37/debian/patches/0001-Fix-the-error-path-in-set_disk_and_part_name.patch
2020-11-21 23:57:27.0 +
@@ -0,0 +1,74 @@
+From 22bc0866e941cbfe57de6522db51e9cf2c6b3ff1 Mon Sep 17 00:00:00 2001
+From: Peter Jones
+Date: Wed, 2 Oct 2019 17:01:00 -0400
+Subject: [PATCH] Fix the error path in set_disk_and_part_name()
+
+Signed-off-by: Peter Jones
+
+[ dannf: Context adjustments due to upstream whitespace cleanup;
+ Included to simplify the application of
+ 0003-Try-even-harder-to-find-disk-device-symlinks-in-sysf.patch ]
+
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1891718
+Bug: https://github.com/rhboot/efivar/issues/157
+Origin: upstream,
https://github.com/rhboot/efivar/commit/22bc0866e941cbfe57de6522db51e9cf2c6b3ff1
+Last-Updated: 2020-09-30
+
+Index: efivar-37/src/linux.c
+===
+--- efivar-37.orig/src/linux.c
efivar-37/src/linux.c
+@@ -1,6 +1,6 @@
+ /*
+ * libefiboot - library for the manipulation of EFI boot variables
+- * Copyright 2012-2015 Red Hat, Inc.
++ * Copyright 2012-2019 Red Hat, Inc.
+ * Copyright (C) 2001 Dell Computer Corporation
+ *
+ * This library is free software; you can redistribute it and/or
+@@ -169,6 +169,8 @@ set_disk_name(struct device *dev, const
+ int HIDDEN
+ set_disk_and_part_name(struct device *dev)
+ {
++ int rc = -1;
++
+ /*
+ * results are like such:
+ * maj:min ->
../../devices/pci$PCI_STUFF/$BLOCKDEV_STUFF/block/$DISK/$PART
+@@ -200,6 +202,7 @@ set_disk_and_part_name(struct device *de
+ set_disk_name(dev, "%s", penultimate);
+ set_part_name(dev, "%s", ultimate);
+ debug("disk:%s part:%s", penultimate, ultimate);
++ rc = 0;
+ } else if (ultimate && approximate && !strcmp(approximate, "nvme")) {
+ /*
+ * 259:0 ->
../../devices/pci:00/:00:1d.0/:05:00.0/nvme/nvme0/nvme0n1
+@@ -207,6 +210,7 @@ set_disk_and_part_name(struct device *de
+ set_disk_name(dev, "%s", ultimate);
+ set_part_name(dev, "%sp%d", ultimate, dev->part);
+ debug("disk:%s part:%sp%d", ultimate, ultimate, dev->part);
++ rc = 0;
+ } else if (ultimate && penultimate && !strcmp(penultimate, "block")) {
+ /*
+ * 253:0 -> ../../devices/virtual/block/dm-0 (... I guess)
+@@ -220,15 +224,19 @@ set_disk_and_part_name(struct device *de
+ set_disk_name(dev, "%s", ultimate);
+ set_part_name(dev, "%s%d", ultimate, dev->part);
+ debug("disk:%s part:%s%d", ultimate, ultimate, dev->part);
++ rc = 0;
+ } else if (ultimate &am
Re: 10.7 planning
Hey Adam, On Fri, Oct 30, 2020 at 07:10:20PM +, Adam Barratt wrote: >Hi, > >In an attempt to be slightly more efficient than usual at planning a >point release... it's about a month since 10.6, so let's start looking >at dates for 10.7. > >Please could you confirm your availability, and any preferences, for >the following: > >- November 21st >- November 28th >- December 5th All are workable for me, with a slight pref for *not* the 28th. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Re: 10.6 planning
On Wed, Sep 09, 2020 at 08:28:48PM +0100, Mark Hymers wrote: >On Wed, 09, Sep, 2020 at 07:24:06PM +0100, Adam D. Barratt spoke thus.. >> - September 26/27 >> - October 3/4 > >I can do either of those for ftp-team. I have a slight preference for >Sept 26/27th but it's only slight. Ditto - slight preference for the 26th/27th but I can do either so far. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
10.5.0 images published
Hi folks, I've just pushed the images for the 10.5.0 point release. As already promised, these will be the right images for people to use including fixes for the UEFI SecureBoot bugs described as "BootHole" [1] There are a couple of image issues that I'm highlighting; I don't think they're big enough to warrant a re-spin at this time: 1. The i386 xfce CD has grown too much and no longer fits onto a standard-sized CD. The image built, but didn't include several critical xfce packages. I have *removed* this image to save people from downloading it and reporting errors. Maybe for the next Buster point release we'll be able to make it fit, but I'm not sure. 2. The Gnome live images work fine as live images and support installation using d-i from the boot menus. However, an update for the Calamares live installer has caused a bug that means it will not work on these Gnome images (both amd64 and i386). It works fine for the other live images. [1] https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot/ -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves. signature.asc Description: PGP signature
Re: stretch EOL point release (9.13) and 10.5 planning
On Sat, Jul 18, 2020 at 10:12:41PM +0100, Adam Barratt wrote: >On Sun, 2020-07-12 at 15:35 +0100, Adam D. Barratt wrote: >> Hi Steve, >> >> On Sun, 2020-07-12 at 12:46 +0100, Steve McIntyre wrote: >> > Argh, massive apologies... >> > >> > On Thu, Jun 25, 2020 at 10:38:14AM +0200, Laura Arjona Reina wrote: >> > > El 15/6/20 a las 18:44, Adam D. Barratt escribió: >> > > > - July 18/19 >> > >> > Massive apologies for dropping a spanner in the works, but >> > something major has come up. I won't be able to do *all* of that >> > weekend after all. As Stretch EOL is already a thing, can I suggest >> > that we keep that to plan and push back the Buster 10.5 release a >> > little? >> > >> > Sorry. :-/ >> >> Thanks for letting us know. :-( >> >> I'll drop a note to the lists, and we can look at getting a new date >> organised. > >Now that stretch EoL is (more or less) out of the way, it would be good >to get 10.5 done as soon as we sensibly can, so as not to slip too far >off schedule. > >Next weekend is probably a little too soon - I'd at least like to not >jump straight back into freezing - but how about one of: > >- August 1st/2nd >- August 8th/9th Either is possible for me, with a preference for the first. Let's not delay too long if possible. Cheers, Steve -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Optional Build-Depends
On Thu, Jul 16, 2020 at 07:27:52PM +0200, Julian Andres Klode wrote: ... >Rationales: > > >1. You can start optionally build-depending on stuff available > only on some architectures, without having to use arch restriction > lists. > > Arch restriction lists are tediuous, especially also because in > the case of libraries, they need to be recursively applied: > > libfoo is only available on bar > libbaz depends on libfoo > > results in build-depends: libbaz [bar] > > With optional build-depends, you can just write libbaz? and > not have to update the dep each time libfoo appears on a new > arch. (apply argument to longer recursive chains) Hmmm. What happens if a build-dep is transiently not available? How can you guarantee controllable, predictable behaviour? -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Re: stretch EOL point release (9.13) and 10.5 planning
Argh, massive apologies... On Thu, Jun 25, 2020 at 10:38:14AM +0200, Laura Arjona Reina wrote: >El 15/6/20 a las 18:44, Adam D. Barratt escribió: >> >> - July 18/19 Massive apologies for dropping a spanner in the works, but something major has come up. I won't be able to do *all* of that weekend after all. As Stretch EOL is already a thing, can I suggest that we keep that to plan and push back the Buster 10.5 release a little? Sorry. :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Bug#964589: buster-pu: package fwupd/1.2.5-2
On Thu, Jul 09, 2020 at 12:25:05PM +0100, Adam Barratt wrote: >Control: tags -1 + confirmed > >Thanks. Please go ahead. In incoming now, cheers! -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#964588: stretch-pu: package fwupd/0.7.4-2
On Thu, Jul 09, 2020 at 12:24:05PM +0100, Adam Barratt wrote: >Control: tags -1 + confirmed ... >Thanks. It also confirms that the libebitdo1 dependency gets dropped, >which was one of the things I wanted to check after looking at dak rm. Nod. >Please go ahead. In incoming now. Thanks! -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Bug#964589: buster-pu: package fwupd/1.2.5-2
On Thu, Jul 09, 2020 at 11:04:02AM +0100, Adam Barratt wrote:
>Hi Steve,
>
>On Thu, 2020-07-09 at 10:27 +0100, Steve McIntyre wrote:
>> We'd like to push an update for fwupd in Buster. It's not as far out
>> of date as that in Stretch, but it's starting to show its age and
>> security worries (again CVE-2020-10759).
>>
>> To fix things and to allow us to keep on top of security and other
>> important issues, we'd like to update to the head of the current
>> stable release branch (1.12.x). Mario, the primary maintainer in
>> Debian, is also part of the upstream development team and has been
>> working to maintain that. Apparently Ubuntu and other distros have
>> switched to this already.
>
>ACK.
>
>> This *does* mean that the debdiff is *way* too large to fit in mail,
>> sorry. :-( I've put a copy up at
>>
>> https://www.einval.com/~steve/debian/fwupd_1.2.13-1_amd64.debdiff.gz
>>
>> for reference.
>
>Thanks. As with stretch, could we have a binary debdiff, please? That's
>potentially more interesting to look at right now, particularly with
>the packaging changes.
And attached again.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?
debdiff --from /scratch/mirror/debian/pool/main/f/fwupd/*1.2.5-2*amd64*deb --to
*1.2.13-1*amd64*.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second set of .debs but not in first
-
-rw-r--r-- root/root /etc/fwupd/remotes.d/dell-esrt.conf
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_synaptics_prometheus.so
-rw-r--r-- root/root /usr/share/bash-completion/completions/fwupdagent
-rw-r--r-- root/root /usr/share/fwupd/quirks.d/synaptics-prometheus.quirk
-rw-r--r-- root/root /usr/share/fwupd/remotes.d/dell-esrt/metadata.xml
-rw-r--r-- root/root /usr/share/locale/da/LC_IMAGES/fwupd-1024-768.bmp.gz
-rw-r--r-- root/root /usr/share/locale/da/LC_IMAGES/fwupd-1920-1080.bmp.gz
-rw-r--r-- root/root /usr/share/locale/da/LC_IMAGES/fwupd-3840-2160.bmp.gz
-rw-r--r-- root/root /usr/share/locale/da/LC_IMAGES/fwupd-5120-2880.bmp.gz
-rw-r--r-- root/root /usr/share/locale/da/LC_IMAGES/fwupd-5688-3200.bmp.gz
-rw-r--r-- root/root /usr/share/locale/da/LC_IMAGES/fwupd-640-480.bmp.gz
-rw-r--r-- root/root /usr/share/locale/da/LC_IMAGES/fwupd-7680-4320.bmp.gz
-rw-r--r-- root/root /usr/share/locale/da/LC_IMAGES/fwupd-800-600.bmp.gz
-rw-r--r-- root/root /usr/share/locale/da/LC_MESSAGES/fwupd.mo
-rw-r--r-- root/root /usr/share/locale/lt/LC_IMAGES/fwupd-1024-768.bmp.gz
-rw-r--r-- root/root /usr/share/locale/lt/LC_IMAGES/fwupd-1920-1080.bmp.gz
-rw-r--r-- root/root /usr/share/locale/lt/LC_IMAGES/fwupd-3840-2160.bmp.gz
-rw-r--r-- root/root /usr/share/locale/lt/LC_IMAGES/fwupd-5120-2880.bmp.gz
-rw-r--r-- root/root /usr/share/locale/lt/LC_IMAGES/fwupd-5688-3200.bmp.gz
-rw-r--r-- root/root /usr/share/locale/lt/LC_IMAGES/fwupd-640-480.bmp.gz
-rw-r--r-- root/root /usr/share/locale/lt/LC_IMAGES/fwupd-7680-4320.bmp.gz
-rw-r--r-- root/root /usr/share/locale/lt/LC_IMAGES/fwupd-800-600.bmp.gz
-rw-r--r-- root/root /usr/share/locale/lt/LC_MESSAGES/fwupd.mo
-rwxr-xr-x root/root /lib/systemd/system-shutdown/fwupd.shutdown
-rwxr-xr-x root/root /usr/lib/fwupd/fwupdagent
-rwxr-xr-x root/root /usr/lib/fwupd/fwupdoffline
Files in first set of .debs but not in second
-
-rw-r--r-- root/root /etc/fwupd/remotes.d/fwupd.conf
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-3/libfu_plugin_flashrom.so
-rw-r--r-- root/root /usr/share/fwupd/quirks.d/flashrom.quirk
-rw-r--r-- root/root /usr/share/fwupd/remotes.d/fwupd/metadata.xml
Control files of package fwupd: lines which differ (wdiff format)
-
Depends: libarchive13 (>= 3.0.4), libc6 (>= 2.17), libefiboot1 (>= 37),
libefivar1 (>= 37), libelf1 (>= 0.142), libfwupd2 (>= [-1.2.5),-] {+1.2.9),+}
libgcab-1.0-0 (>= 1.0), libglib2.0-0 (>= 2.53.2), libgnutls30 (>= 3.6.5),
libgpg-error0 (>= 1.14), libgpgme11 (>= 1.2.0), libgudev-1.0-0 (>= 212),
libgusb2 (>= 0.2.10), libjson-glib-1.0-0 (>= [-0.12.0),-] {+1.2.0),+}
libpolkit-gobject-1-0 (>= 0.99), libsmbios-c2, libsoup2.4-1 (>= 2.41.90),
libsqlite3-0 (>= 3.5.9), libxmlb1, shared-mime-info
Installed-Size: [-8398-] {+9339+}
Version: [-1.2.5-2-] {+1.2.13-1+}
Control files of package fwupd-amd64-signed-template: lines which differ (wdiff
format)
---
Installed-Size: [-42-] {+43+}
Version: [-1.2.5-2-] {+1.2.13-1+}
Control files of package fwupd-tests: l
Bug#964588: stretch-pu: package fwupd/0.7.4-2
On Thu, Jul 09, 2020 at 11:03:22AM +0100, Adam Barratt wrote:
>Hi Steve,
>
>On Thu, 2020-07-09 at 10:20 +0100, Steve McIntyre wrote:
>> We'd like to push an update into the last stretch point release for
>> fwupd. The last version in stretch (0.7.4-2) is now considered so old
>> that it's (a) not really functional any more, and (b) no longer
>> supported by upstream. There are also security worries
>> (CVE-2020-10759) with this version. We've discussed this with the
>> security team (in CC) and they're keen to see this addressed, but
>> maybe via the PU process before it hits LTS.
>>
>> To fix all this, we'd like to switch to a supported stable release
>> branch as supported by upstream (0.8.x); Mario, the primary
>> maintainer in Debian, is also part of the upstream development team
>> and has been working to maintain that. Apparently Ubuntu and other
>> distros have switched to this already.
>
>ACK.
>
>> This *does* mean that the debdiff is *way* too large to fit in mail,
>> sorry. :-( I've put a copy up at
>>
>> https://www.einval.com/~steve/debian/fwupd_0.8.3-1_amd64.debdiff.gz
>>
>> for reference.
>
>Could we have a binary debdiff, please? That's potentially more
>interesting to look at right now, particularly with the packaging
>changes.
Sure, no worries. That's much smaller, so attached here.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code
is in use on a military site..." -- Simon Booth
debdiff --from /scratch/mirror/debian/pool/main/f/fwupd/*0.7.4-2*amd64*deb --to
*0.8.3-1*amd64*.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second set of .debs but not in first
-
-rw-r--r-- root/root
/etc/pki/fwupd-metadata/GPG-KEY-Linux-Foundation-Metadata
-rw-r--r-- root/root /etc/pki/fwupd/GPG-KEY-Linux-Foundation-Firmware
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_altos.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_colorhug.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_dell.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_dfu.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_ebitdo.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_raspberrypi.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_steelseries.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_synapticsmst.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_test.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_udev.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_uefi.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_unifying.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_upower.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_usb.so
-rw-r--r-- root/root /usr/share/locale/hi/LC_MESSAGES/fwupd.mo
-rw-r--r-- root/root /usr/share/locale/nl/LC_MESSAGES/fwupd.mo
-rw-r--r-- root/root /usr/share/locale/tr/LC_MESSAGES/fwupd.mo
Files in first set of .debs but not in second
-
-rw-r--r-- root/root /usr/include/ebitdo.h
-rw-r--r-- root/root /usr/include/libebitdo/ebitdo-device.h
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-1/libfu_plugin_steelseries.so
-rw-r--r-- root/root
/usr/lib/x86_64-linux-gnu/fwupd-plugins-1/libfu_plugin_test.so
-rw-r--r-- root/root /usr/lib/x86_64-linux-gnu/libebitdo.so.1.0.1
-rw-r--r-- root/root /usr/lib/x86_64-linux-gnu/pkgconfig/ebitdo.pc
-rw-r--r-- root/root /usr/share/doc/libebitdo-dev/changelog.Debian.gz
-rw-r--r-- root/root /usr/share/doc/libebitdo-dev/copyright
-rw-r--r-- root/root /usr/share/doc/libebitdo1/changelog.Debian.gz
-rw-r--r-- root/root /usr/share/doc/libebitdo1/copyright
-rw-r--r-- root/root /usr/share/locale/hi_IN/LC_MESSAGES/fwupd.mo
-rw-r--r-- root/root /usr/share/locale/nl_NL/LC_MESSAGES/fwupd.mo
-rw-r--r-- root/root /usr/share/locale/tr_TR/LC_MESSAGES/fwupd.mo
lrwxrwxrwx root/root /usr/lib/x86_64-linux-gnu/libebitdo.so ->
libebitdo.so.1.0.1
lrwxrwxrwx root/root /usr/lib/x86_64-linux-gnu/libebitdo.so.1 ->
libebitdo.so.1.0.1
Control files of package fwupd: lines which differ (wdiff format)
-
Depends: libappstream-glib8 (>= [-0.6.1),-] {+0.6.7),+} libarchive13 (&
Bug#964589: buster-pu: package fwupd/1.2.5-2
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Hi folks, Similarly again for Buster... We'd like to push an update for fwupd in Buster. It's not as far out of date as that in Stretch, but it's starting to show its age and security worries (again CVE-2020-10759). To fix things and to allow us to keep on top of security and other important issues, we'd like to update to the head of the current stable release branch (1.12.x). Mario, the primary maintainer in Debian, is also part of the upstream development team and has been working to maintain that. Apparently Ubuntu and other distros have switched to this already. This *does* mean that the debdiff is *way* too large to fit in mail, sorry. :-( I've put a copy up at https://www.einval.com/~steve/debian/fwupd_1.2.13-1_amd64.debdiff.gz for reference. Sorry this is so big and so late... :-( -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.118+ (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#964588: stretch-pu: package fwupd/0.7.4-2
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Hi folks, We'd like to push an update into the last stretch point release for fwupd. The last version in stretch (0.7.4-2) is now considered so old that it's (a) not really functional any more, and (b) no longer supported by upstream. There are also security worries (CVE-2020-10759) with this version. We've discussed this with the security team (in CC) and they're keen to see this addressed, but maybe via the PU process before it hits LTS. To fix all this, we'd like to switch to a supported stable release branch as supported by upstream (0.8.x); Mario, the primary maintainer in Debian, is also part of the upstream development team and has been working to maintain that. Apparently Ubuntu and other distros have switched to this already. This *does* mean that the debdiff is *way* too large to fit in mail, sorry. :-( I've put a copy up at https://www.einval.com/~steve/debian/fwupd_0.8.3-1_amd64.debdiff.gz for reference. Sorry this is so big and so late... :-( -- System Information: Debian Release: 10.4 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.118+ (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: RFC: Clean-up of old kernel ABIs at point releases
On Tue, Jun 30, 2020 at 05:49:08PM +0100, Adam Barratt wrote: >[MFT and Reply-To set to debian-release, to try and avoid spamming too >many people with the discussion] > >Hi, > >When the kernel ABI version has been increased between two point >releases, we currently remove the old versions as part of the point >release, to avoid carrying cruft. > >This has unfortunate side-effects for a number of use cases, including >CI setups which immediately stop working as the packages they attempt >to install no longer exist in the archive. > >If we were instead to change this policy to, for example, remove the >packages after the subsequent point release instead, can anyone see any >problems that this might cause, whether for tooling, tools or anything >else? I don't expect to see any problems directly on the -cd front; IIRC debian-cd will just ignore all but the most recent version of the packages involved. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Bug#962982: buster-pu: package jigdo/0.7.3-5
On Wed, Jun 17, 2020 at 07:15:22AM +0100, Adam Barratt wrote: >Control: tags -1 + confirmed > >On Tue, 2020-06-16 at 22:15 +0100, Steve McIntyre wrote: >> I'd like to push a tiny update into buster for jigdo please. The >> existing version in buster doesn't support https, and this is causing >> issues for users (e.g. #962776). The changes are tiny, backported >> from upstream changes already shipping in sid/bullseye. > >Please go ahead. Thanks! In incoming now. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Bug#962982: buster-pu: package jigdo/0.7.3-5
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi!
I'd like to push a tiny update into buster for jigdo please. The
existing version in buster doesn't support https, and this is causing
issues for users (e.g. #962776). The changes are tiny, backported from
upstream changes already shipping in sid/bullseye.
Here's a debdiff...
diff -Nru jigdo-0.7.3/debian/changelog jigdo-0.7.3/debian/changelog
--- jigdo-0.7.3/debian/changelog2017-12-07 16:38:20.0 +
+++ jigdo-0.7.3/debian/changelog2020-06-16 21:54:52.0 +0100
@@ -1,3 +1,10 @@
+jigdo (0.7.3-5+deb10u1) buster; urgency=medium
+
+ * Backport more upstream changes to make jigdo-lite and jigdo-mirror
+support https. Closes: #962776
+
+ -- Steve McIntyre <93...@debian.org> Tue, 16 Jun 2020 21:54:52 +0100
+
jigdo (0.7.3-5) unstable; urgency=medium
* Switch addresses from atterer.org to atterer.org in various places
diff -Nru jigdo-0.7.3/debian/patches/03.jigdo-lite-https.patch
jigdo-0.7.3/debian/patches/03.jigdo-lite-https.patch
--- jigdo-0.7.3/debian/patches/03.jigdo-lite-https.patch2017-12-07
15:40:56.0 +
+++ jigdo-0.7.3/debian/patches/03.jigdo-lite-https.patch2020-06-16
21:54:52.0 +0100
@@ -17,3 +17,12 @@
*) return 1;
esac
}
+@@ -596,7 +596,7 @@ imageDownload() {
+ for pass in x xx xxx x xx xxx ; do
+ $jigdoFile print-missing-all --image="$image" --jigdo="$jigdoF" \
+ --template="$template" $jigdoOpts $uriOpts \
+- | egrep -i '^(http:|ftp:|$)' >"$list"
++ | egrep -i '^(http:|https:|ftp:|$)' >"$list"
+ missingCount=`egrep '^$' <"$list" | wc -l | sed -e 's/ *//g'`
+ # Accumulate URLs in $@, pass them to fetchAndMerge in batches
+ shift "$#" # Solaris /bin/sh doesn't understand "set --"
diff -Nru jigdo-0.7.3/debian/patches/07.more_https_support.patch
jigdo-0.7.3/debian/patches/07.more_https_support.patch
--- jigdo-0.7.3/debian/patches/07.more_https_support.patch 1970-01-01
01:00:00.0 +0100
+++ jigdo-0.7.3/debian/patches/07.more_https_support.patch 2020-06-16
21:54:52.00000 +0100
@@ -0,0 +1,46 @@
+commit 53abb98c46c9ee2d298b29359f1376aea1891f88
+Author: Steve McIntyre
+Date: Thu Nov 7 18:16:20 2019 +
+
+Make jigdo-mirror believe in https too
+
+diff --git a/scripts/jigdo-mirror b/scripts/jigdo-mirror
+index 1324f11..fb0aa3b 100644
+--- a/scripts/jigdo-mirror
b/scripts/jigdo-mirror
+@@ -105,12 +105,16 @@ userAgent="jigdo-mirror/1.0 (`wget --version 2>/dev/null
| (read ver; echo $ver)
+ #__
+
+ # isURI
+-# Returns 0 (true) if the supplied string is a HTTP/FTP URL, otherwise 1
++# Returns 0 (true) if the supplied string is a HTTP/HTTPS/FTP/FILE
++# URL, otherwise 1
+ isURI() {
+-case "$1" in
+-http:*|ftp:*|HTTP:*|FTP:*|file:*|FILE:*) return 0;;
+-*) return 1;
+-esac
++ case "$1" in
++[hH][tT][tT][pP]:*) return 0;;
++[hH][tT][tT][pP][sS]:*) return 0;;
++[fF][tT][pP]:*) return 0;;
++[fF][iI][lL][eE]:*) return 0;;
++*) return 1;
++ esac
+ }
+ #__
+
+@@ -193,11 +197,11 @@ makeImage() {
+ for pass in x xx xxx x xx xxx ; do
+ if $havePMA; then
+ $jigdoFile print-missing-all $ijtOpts $jigdoOpts $uriOpts \
+-| egrep -i '^(http:|ftp:|$)' >"list"
++| egrep -i '^(https:|http:|ftp:|$)' >"list"
+ else
+ # Quick hack until jigdo-port supports print-missing-all
+ $jigdoFile print-missing $ijtOpts $jigdoOpts $uriOpts \
+-| egrep -i '^(http:|ftp:|$)' \
++| egrep -i '^(https:|http:|ftp:|$)' \
+ | sed -n '/./{p;s/^.*$//;p;}' >"list"
+ fi
+ missingCount=`egrep '^$' <"list" | wc -l | sed -e 's/ *//g'`
diff -Nru jigdo-0.7.3/debian/patches/series jigdo-0.7.3/debian/patches/series
--- jigdo-0.7.3/debian/patches/series 2017-12-07 16:38:20.0 +
+++ jigdo-0.7.3/debian/patches/series 2020-06-16 21:54:52.0 +0100
@@ -5,3 +5,4 @@
04.jigdo-lite-tmpdir.patch
05.jigdo-lite-grep-options.patch
06.jigdo-lite-store-filesPerFetch.patch
+07.more_https_support.patch
-- System Information:
Debian Release: 10.4
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-9-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Re: stretch EOL point release (9.13) and 10.5 planning
Hey Adam, On Mon, Jun 15, 2020 at 05:44:54PM +0100, Adam Barratt wrote: >Hi, > >stretch transitions from oldstable-with-security-support to LTS support >on Saturday July 4th. As usual, we should aim for the final point >release to be soon after that, most likely pulling in any remaining >updates from security.d.o that are still in oldstable-new. > >I think Saturday July 11th makes most sense (so freezing opu during the >transition weekend), but we could potentially stretch (no pun intended) >slightly further if need be. > >We also need to look at the next buster point release in a similar >timeframe. Can anyone see a reason not to do the two at the same time, >as usual? Should be fine for the images team. >To get the ball rolling, please could you confirm your availability >for: > >- July 11/12 >- July 18/19 Either is possible for me, with a slight preference for the second weekend. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: 10.4 planning
Hey Adam, On Mon, Apr 06, 2020 at 12:16:05PM +0100, Adam Barratt wrote: > >I realise things are a little unusual right now, but it's about time >that we started looking at dates for 10.4. > >I guess the biggest impact of current circumstances on the process is >likely to be around image testing, as there won't be a bunch of people >with local access to Steve's mirror. Andy and I can work that out, it might just take a little longer on the day. >I've listed some potential dates below; as usual, please indicate which >you would be available for. > >- April 25th >- May 2nd >- May 9th All of those dates look fine for me, with my busy social calendar atm. The first would have clashed with the Aberdeen miniconf, but well... -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Bug#951146: buster-pu: package rootskel/1.131+10u1
On Thu, Feb 27, 2020 at 08:32:52PM +, Adam Barratt wrote: >Control: tags -1 + confirmed > >On Tue, 2020-02-11 at 16:47 +0000, Steve McIntyre wrote: >> We released buster with a new feature in d-i: support for running d-i >> on multiple consoles. This is very useful on some systems (e.g. arm64 >> machines with both serial console and normal graphical console), but >> had an unexpected side-effect: preseeded installations with more than >> one console defined would end up trying to run the preseeded d-i on >> all the consoles in parallel, with unpredictable behaviour. See >> #940028, #932416. >> >> I've added a workaround/fix for this in unstable already, in rootskel >> 1.132. Here's a debdiff which just cherry-picks that one fix into a >> 1.131+10u1 for a buster upload. We'd like to fix this for the 10.4 >> point release. >> > >Ack, please go ahead. In incomimg now. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast." Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Bug#951146: buster-pu: package rootskel/1.131+10u1
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Hi folks,
We released buster with a new feature in d-i: support for running d-i
on multiple consoles. This is very useful on some systems (e.g. arm64
machines with both serial console and normal graphical console), but
had an unexpected side-effect: preseeded installations with more than
one console defined would end up trying to run the preseeded d-i on
all the consoles in parallel, with unpredictable behaviour. See
#940028, #932416.
I've added a workaround/fix for this in unstable already, in rootskel
1.132. Here's a debdiff which just cherry-picks that one fix into a
1.131+10u1 for a buster upload. We'd like to fix this for the 10.4
point release.
I've already got kibi's ACK for this.
-- System Information:
Debian Release: 10.3
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru rootskel-1.131/debian/changelog rootskel-1.131+10u1/debian/changelog
--- rootskel-1.131/debian/changelog 2019-06-13 20:28:44.0 +0100
+++ rootskel-1.131+10u1/debian/changelog2020-02-11 16:33:42.0
+
@@ -1,3 +1,15 @@
+rootskel (1.131+10u1) buster; urgency=medium
+
+ [ Steve McIntyre ]
+ * Backport fix from unstable:
+Tweak how multiple consoles are used. If we detect that we're
+trying to run using preseeding, do *not* run on multiple consoles
+in parallel as that causes race conditions and weird
+behaviour. Instead, just run on the "preferred" console. Hopefully
+Closes: #940028, #932416
+
+ -- Steve McIntyre <93...@debian.org> Tue, 11 Feb 2020 16:33:54 +
+
rootskel (1.131) unstable; urgency=medium
* Team upload
diff -Nru rootskel-1.131/src/sbin/reopen-console-linux
rootskel-1.131+10u1/src/sbin/reopen-console-linux
--- rootskel-1.131/src/sbin/reopen-console-linux2019-06-02
12:29:14.0 +0100
+++ rootskel-1.131+10u1/src/sbin/reopen-console-linux 2020-02-11
16:28:51.0 +
@@ -16,6 +16,17 @@
LOGGER_UP=0
LOG_FILE=/var/log/reopen-console
+# If we're running with preseeding, we have a problem with running d-i
+# on multiple consoles. We'll end up running each of those d-i
+# instances in parallel with all kinds of hilarious undefined
+# behaviour as they trip over each other! If we detect that we're
+# preseeding (via any of the possible preseed methods), DO NOT run d-i
+# multiple times. Instead, fall back to the older, more simple
+# behaviour and run it once. If the user wants to see or interact with
+# their preseed on a specific console, they get to tell us which one
+# they want to use.
+PRESEEDING=0
+
log() {
# In very early startup we don't have syslog. Log to file that
# we can flush out later so we can at least see what happened
@@ -32,6 +43,20 @@
rm $LOG_FILE
}
+# If we have a preseed.cfg in the initramfs
+if [ -e /preseed.cfg ]; then
+log "Found /preseed.cfg; falling back to simple mode for preseeding"
+PRESEEDING=1
+fi
+
+# Have we been told to do preseeding stuff on the boot command line?
+for WORD in auto url; do
+if (grep -qw "$WORD" /proc/cmdline); then
+ log "Found \"$WORD\" in the command line; falling back to simple mode
for preseeding"
+ PRESEEDING=1
+fi
+done
+
consoles=
preferred=
# Retrieve all enabled consoles from kernel; ignore those
@@ -44,7 +69,7 @@
status=$(echo "$kernelconsoles" | grep $cons | sed -n -r -e 's/(^.*)
*.*\((.*)\).*$/\2/p' )
if [ -e "/dev/$cons" ] && [ $(echo "$status" | grep -o 'E') ]; then
consoles="${consoles:+$consoles$NL}$cons"
- log " Adding $cons to consoles list"
+ log " Adding $cons to possible consoles list"
fi
# 'C' console is 'most prefered'.
if [ $(echo "$status" | grep -o 'C') ]; then
@@ -64,6 +89,13 @@
log "Found no preferred console. Picking $preferred"
fi
+# If we're preseeding, do simple stuff here (see above). We just
+# want one console. Let's pick the preferred one ONLY
+if [ $PRESEEDING = 1 ]; then
+log "Running with preseeding. Picking preferred $preferred ONLY"
+consoles=$preferred
+fi
+
for cons in $consoles
do
echo "/dev/$cons " >> /var/run/console-devices
@@ -88,7 +120,7 @@
flush_logger
# Finally restart init to run debian-installer on discovered consoles
-log "Restarting init to start d-i on the consoles we found"
+log "Restarting init to start d-i on the console(s) we found"
kill -HUP 1
exit 0
