Re: Bug#1070706: gtk4 udeb has unsatisfiable dependencies
Hi, On 07-05-2024 7:49 p.m., Simon McVittie wrote: The version in testing, 4.12.5+ds-3, has the same dependencies, so this is not a regression. Is it? It seems that the version in unstable depends on libpng16-16t64-udeb where the version in testing depends on libpng16-16-udeb. The later exists, the former not. Is this requirement newly enforced by britney? No. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1016957: remove kbd-chooser from the archive?
Hi On 04-05-2024 3:36 p.m., Holger Wansing wrote: I think Bastian's approach is, to remove kbd-chooser from the archive, since it was stated (see below) that it's no longer in use. It might be that udd assumes all packages that build a udeb are used. d-i has switched away from it to console-setup 12 years ago with https://salsa.debian.org/installer-team/debian-installer/-/commit/2575a669e91252a6253430020137154c995c9b38 I did check the d-i repository and there are still references to kbd-chooser, so I *assumed* it was still used. Are there any ports maybe, that still use it somehow? Or what about derivatives? It's an udeb-only package, so the use in the installer is the only imaginable scenario... If you're sure it's not used, I can work around udd and have it at least removed from testing. I think a bug retitle (or separate bug) would have been better. The current bug isn't RC. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1016957: kbd-chooser: please add support for riscv64
Hi Bastian, On Sat, 9 Sep 2023 19:03:07 +0200 Bastian Germann wrote: Control: severity -1 serious Can you please elaborate? I'm not seeing anything serious in this bug report. On Wed, 10 Aug 2022 21:42:34 +0200 Holger Wansing wrote: > kbd-chooser is no longer in use, I think. > Or am I missing something? I am raising severity to serious then so that it can be autoremoved from testing. This package is a key package (because of debian-installer), so it can't be autoremoved. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: What to do with d-i on armel?
Hi, On 03-03-2024 9:01 p.m., Cyril Brulebois wrote: Maybe have it marked Not-For-Us on armel, also requesting the binary to be dropped there? And maybe poke the ftp team to have installer-armel/ cleaned up? Those actions sound appropriate to me, but I don't know the inner details well enough to see if there are traps set out. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#619328: console-setup-freebsd: Uninstallable on Linux hosts
Hi, On Mon, 24 Jul 2023 17:17:54 +0200 Paul Gevers wrote: On Wed, 23 Mar 2011 10:49:42 +0100 Julien Cristau wrote: > On Wed, Mar 23, 2011 at 11:36:00 +0200, Anton Zinoviev wrote: > > Does this mean the > > architectures are not equal in rights - an 'all' package is allowed to > > be uninsallable on kFreeBSD but not on Linux? > > > No, it's fine. While I totally stand behind this, with the kfreebsd's removed now even from the ports [1], maybe it's time to stop building console-setup-freebsd? And now, due to changes in our migration software, this issue has caused console-setup to be blocked for 34 days already [1]: uninstallable on arch amd64, not running autopkgtest there I'll hint it through now, but it would be nicer if console-setup-freebsd would be dropped next time (as it would ensure src:console-setup gets the normal autopkgtest treatment). Paul [1] https://qa.debian.org/excuses.php?package=console-setup OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#619328: console-setup-freebsd: Uninstallable on Linux hosts
Hi, On Wed, 23 Mar 2011 10:49:42 +0100 Julien Cristau wrote: On Wed, Mar 23, 2011 at 11:36:00 +0200, Anton Zinoviev wrote: > Does this mean the > architectures are not equal in rights - an 'all' package is allowed to > be uninsallable on kFreeBSD but not on Linux? > No, it's fine. While I totally stand behind this, with the kfreebsd's removed now even from the ports [1], maybe it's time to stop building console-setup-freebsd? Paul [1] https://www.ports.debian.org/ 2023-07-14 OpenPGP_signature Description: OpenPGP digital signature
Re: 11.7 planning + bookworm planning
Hi all, Let's book June 10 as the bookworm release date. A more formal announcement will follow. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: 11.7 planning + bookworm planning
Hi, Any FTP master for 10 or 17 June? kibi - 10, 17, 24 d-i Luna - 10, 17, 24 CD testing elbrus - 10, 17, 24 release team adsb - 10, 17, 24 release team Sledge - 10, 17, 24 images team donald- 10, 17press Paul OpenPGP_signature Description: OpenPGP digital signature
Re: 11.7 planning + bookworm planning
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 Paul OpenPGP_signature Description: OpenPGP digital signature
Re: 11.7 planning + bookworm planning
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 :) ). 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? 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. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: 11.7 planning + bookworm planning
Hi all, On 26-03-2023 19:55, Steve McIntyre wrote: Nobody else seems to have replied yet, so... :-) Two weeks have gone by since the last mail in this thread. 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 elbrus-13, 27 release team The 13th is in a month from today. We're still missing press and a cooked solution for the release team. That means I'm going to have two part in this e-mail: 1) question in public what the options are for me handling the release day 2) extend with possible dates into June (because finding a date seems to be a major bottle neck for the bookworm release) Re 1) I'll be at the Debian Reunion Hamburg on the 27, so that feels like a good day (albeit probably missing talks) to do the release if I were to handle it without the experienced team members. We would still be missing CD & press too for that day. For me to do the release, I'd need to get my hands on the key, but I don't see me traveling to Jonathan any time soon (and I don't expect the reverse to happen either). Are there *established* secure ways of handing over keys without real-life meetings? I think that most of the required actions for the Release Team during a release are documented on the Wiki [1]. I think I can handle those (albeit some are documented a bit dense). Are there known items missing? Re 2) Let's see when people are available for May 13, 20, 27 June 3, 10, 17, 24 In June, I can do 10 and 24 and if needed I can arrange 3. Paul [1] https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/BookwormCheckList [While Releasing] PS: quoting stappers: Silence is hard to parse OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1033674: unblock: linux/6.1.20-1
Hi, On 29-03-2023 23:38, Cyril Brulebois wrote: unblock linux/6.1.20-1 ACK on the unblock/age-days 10 request for the d-i team, happy to build the installer against it. :) Done. In the passing I also took along the signed versions. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: 11.7 planning + bookworm planning
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? 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 Paul OpenPGP_signature Description: OpenPGP digital signature
Re: 11.7 planning + bookworm planning
Dear all, On 15-03-2023 21:33, Jonathan Wiltshire wrote: We're overdue for 11.7 and need it done with a keyring update included before bookworm can be released. The wheels are turning on the keyring so how do dates in April look for everybody? Saturdays are 1st (probably too soon), 8th, 15th, 22nd and 29th. I know some people will call me crazy, but can and should we combine this with finding a release date for bookworm? 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)? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: bookworm release date?
Hi all, On 18-02-2023 00:57, Steve McIntyre wrote: On Fri, Feb 17, 2023 at 11:44:47PM +0100, Cyril Brulebois wrote: That'd mean end of March, beginning April at the soonest. it's probably best to add 2-4 extra weeks to that. +1 Thanks kibi and Sledge for the feedback. With such a time line I propose we delay the discussion of a release date by at least a month. In my experience, we're able to find a date approximately 6 weeks ahead, so with ~end April at the earliest, we'll have some time. That will also enables us to judge better if that's (still) feasible from all the other angles too. Paul OpenPGP_signature Description: OpenPGP digital signature
bookworm release date?
Dear Release Team colleagues, dear Boot team colleagues, I just sent out a bits from the RT where I'm claiming that bookworm is in a good state. And now I'm going to be extremely bold now: aim for the shortest freeze in Debian history. What do people think of the idea to start picking a release date already? 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). 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? I'm not aware of difficult blockers, did I miss a bug here or there? It would be good to point us directly at it. Paul /me crosses his fingers. OpenPGP_signature Description: OpenPGP digital signature
Re: Status of Debian Installer Bookworm Alpha 1: 2 blockers
Hi kibi, On 17-09-2022 01:41, Cyril Brulebois wrote: A few questions I can think of: - Is that a good idea in the first place? I think so, sidestepping temporary issues in unstable looks like a valid usecase? AFAIK that *is* the most common use of tpu these days (getting things into testing that are blocked from natural migration from unstable due to non-migrating packages). So if you think it works, it's fine to do so from my point of view. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1010488: win32-loader: please annotate the wine Build-Depends with
Source: win32-loader Version: 0.10.4 Severity: normal Tags: patch X-Debbugs-Cc: Thomas Gaugler Dear maintainers, As part of my Release Team member checks, I have been investigating why the RC buggy src:vkd3d is part of the key package set. It turns out that vkd3d is part of the current key package set because it's needed to build and run wine and wine is needed because it's a Build-Depends of win32-loader. I checked the source code of win32-loader and I got the impression wine is only used during testing (on i386). After I mentioned this on IRC, kibi confirmed that the content of the package didn't change without wine installed during the build, confirming my idea. If our analysis wasn't flawed, can you please annotate the wine Build-Depends with the profile to indicate it's only needed during testing? (If there are other Build-Depends also only needed, please mark those too.) It would make my live as a Release Team member a tiny bit easier. Paul
Bug#998353: wi32-loader migration [was: Re: Bug#998353: Bug#1007707: Update Indonesian translation]
Hold your horses. On 23-03-2022 07:44, Paul Gevers wrote: Last time [1], I just CC'ed ftpmaster and the magic happened, so dear ftpmasters, can you do "that" again? win32-loader is blocked behind grub2 now. I'm not aware of progress with bug #1001057 (in CC). Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#998353: wi32-loader migration [was: Re: Bug#998353: Bug#1007707: Update Indonesian translation]
Control: fixed 982838 0.10.6 Control: found 982838 0.10.7 Dear Holger, ftpmasters, On 22-03-2022 23:31, Holger Wansing wrote: I'm not aware of the exactly needed process, that needs to happen now for migration to testing (I guess, this is what you called "the ftp-master dance"). Is this "documented" somewhere? I don't know. I *think* the term is "BYHAND". Could you take care of this? Last time [1], I just CC'ed ftpmaster and the magic happened, so dear ftpmasters, can you do "that" again? Paul [1] https://bugs.debian.org/967048 OpenPGP_signature Description: OpenPGP digital signature
Bug#1007707: Update Indonesian translation
Hi Holger, On Fri, 18 Mar 2022 21:38:11 +0100 Holger Wansing wrote: Andika Triwidada wrote (Tue, 15 Mar 2022 11:26:40 +): > > Attached is update to Indonesian translation. Just applied to GIT. Thanks Shall we have an upload of this soon and do the ftp-master dance with this package to have it finally migrate to testing (#998353)? Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1007929: netcfg: FTBFS on s390x
Source: netcfg Version: 1.177 Severity: serious Tags: ftbfs Dear maintainer, Your package failed to migrate for 60 days, hence I spotted it. It fails to build from source on s390x. I hit the giveback button once because looking at the failing test result I suspected it is "just" a flaky test. However, that didn't work. The same issue happened on powerpc, ppc64 and sparc64 but those are not release architectures. Paul https://buildd.debian.org/status/fetch.php?pkg=netcfg=s390x=1.177=1642282014=0 Running suite(s): inet_mton inet_ptom netcfg_parse_cidr_address netcfg_network_address netcfg_gateway_reachable nc_v6_interface_configured 95%: Checks: 24, Failures: 1, Errors: 0 test/test_netcfg_gateway_reachable.c:94:F:netcfg_gateway_reachable:test_netcfg_gateway_reachable_v6_fe80:0: Gateway erroneously unreachable make[1]: *** [test/tests.mk:19: test] Error 1 make[1]: Leaving directory '/<>' dh_auto_test: error: make -j1 test returned exit code 2 make: *** [debian/rules:6: build-arch] Error 25
Re: Bug# 983357: Why is it not mentioned in bullseye release notes / installation guide?
Hi Chuck, On 10-02-2022 01:34, Chuck Zmudzinski wrote: The problem as I see it is that the debian installer team is already aware of the problem and has been aware of it for over six months because #983357 is marked as affecting d-i. So I do not understand why #983357 is not included on the d-i bullseye errata page. Please assume good faith. I would go for the most obvious possibility, that while being aware of this issue, they just didn't think at the same time of the installation guide. Do I need to file another bug in addition to #983357 to get this problem listed on the bullseye (and also RC versions) d-i errata pages? This is the most establish process, so yes, I suggest you just go and follow that route, even without a reply here. Than it's documented in the right place [1]. Paul [1] unless I'm much mistaken, that would be against the installation-guide package, but it can be reassigned if I'm wrong. OpenPGP_signature Description: OpenPGP digital signature
Re: Bug# 983357: Why is it not mentioned in bullseye release notes / installation guide?
Hi, Subject: 983357: Why is it not mentioned in bullseye release notes / installation guide? For at least the release notes, because nobody asked the editors to include it. On 09-02-2022 21:04, Chuck Zmudzinski wrote: However, this is a well-known problem, but neither the Bullseye release notes nor the Bullseye installation guide mentions this known problem that has not yet been fixed. Is this issue also present after an upgrade? Then, if you have a proposal for the text to include, we can update the release notes. If this is *only* influencing the installation the installation guide might be a better place. Either way, I read the bug, but I don't have any knowledge on xen, so I feel uncomfortable proposing a text. If it should go into the release notes, please file a bug against the release-notes package. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#998353: src:win32-loader: fails to migrate to testing for too long
Dear Debian-boot, On Tue, 2 Nov 2021 20:55:11 +0100 Paul Gevers wrote: Can somebody please judge if win32-loader should migrate in the current state and take appropriate actions if so: contact ftp to process the package on their side and update bug 982838 (I wouldn't close it, but reuse it after migration) with the right meta info such that the bug doesn't block migration? If help is needed, please reach out to the Release Team. I didn't see any follow-up on this request. I had a look at the changelog, it seems trivial. Is it worth doing the ftp-master dance? win32-loader (0.10.5) unstable; urgency=medium . [ Valentin Vidic ] * Update Croatian translation . [ Didier Raboud ] * Run wrap-and-sort -baskt * Remove myself from Uploaders Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#998353: src:win32-loader: fails to migrate to testing for too long
Source: win32-loader Version: 0.10.4 Severity: serious Control: close -1 0.10.5 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The following template feels a bit weird for the somewhat special package that win32-loader is, but I leave it in this report nevertheless for some background. Can somebody please judge if win32-loader should migrate in the current state and take appropriate actions if so: contact ftp to process the package on their side and update bug 982838 (I wouldn't close it, but reuse it after migration) with the right meta info such that the bug doesn't block migration? If help is needed, please reach out to the Release Team. Template = The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:win32-loader has been trying to migrate for 62 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=win32-loader OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#991969: D-I: news for Bullseye: help with firmware installation
Hi, On 06-08-2021 21:52, Holger Wansing wrote: > I would like to add a paragraph to the release-notes, describing a bit the > new "install-firmware" mechanism via modalias, with a link to the new doc > in the installation-guide, for those who experience problems. > > Please find a patch attached. > (Additionally, I updated some links to D-I alpha and RC releases for Bullseye, > just for completeness. Better than keeping the old ones for Buster in this > file.) > > > @debian-boot: > since there was no more comment, I'm turning this into a bugreport now. > We are already late before release date, and translators need time too... > > @release: > sorry for being late I've reordered it a bit, as the template was for a list of changes. As we now only have one section, let's call it a section. I have further fixed two wrongly ordered tags, used bullseye in the links and fixed a weird sentence in the next section. Before pushing, I hope to see comments from Justin. Paul From 4c744fe5e3206521ceb3174eb34b5d6ea69c2eab Mon Sep 17 00:00:00 2001 From: Holger Wansing Date: Sat, 7 Aug 2021 07:31:28 +0200 Subject: [PATCH] installing.dbk: add d-i firmware note Closes: #991969 --- en/installing.dbk | 43 ++- 1 file changed, 34 insertions(+), 9 deletions(-) diff --git a/en/installing.dbk b/en/installing.dbk index 7a7e0674..10396c60 100644 --- a/en/installing.dbk +++ b/en/installing.dbk @@ -44,21 +44,46 @@ for the beta and RC releases available from the Debian Installer's news history. - + +Help with installation of firmware + + More and more, peripheral devices require firmware to be loaded as + part of the hardware initialization. To help deal with this problem, + the installer has been improved. Based on a hardware ID to firmware + file mapping, if some of the installed hardware requires firmware + files to be installed, the code installs them automatically. + + + Please note, that this new functionality is restricted to the + unofficial installer images with firmware included (see #firmware_nonfree). + The firmware is usually not DFSG compliant, so it is not possible to + distribute it in Debian's main repository. + + + If you experience problems related to (missing) firmware, you might + want to read https://www.debian.org/releases/bullseye/amd64/ch06s04.en.html#completing-installed-system;>the + dedicated chapter of the installation-guide. + + -https://www.debian.org/devel/debian-installer/ -Sources (for buster): +Sources (for bullseye): -https://www.debian.org/devel/debian-installer/News/2017/20170903 -https://www.debian.org/devel/debian-installer/News/2017/20171206 -https://www.debian.org/devel/debian-installer/News/2018/20180619 -https://www.debian.org/devel/debian-installer/News/2018/20181215 -https://www.debian.org/devel/debian-installer/News/2019/20190202 +https://www.debian.org/devel/debian-installer/News/2019/20191205 +https://www.debian.org/devel/debian-installer/News/2020/20200316 +https://www.debian.org/devel/debian-installer/News/2020/20201206 +https://www.debian.org/devel/debian-installer/News/2021/20210423 +https://www.debian.org/devel/debian-installer/News/2021/20210614 +https://www.debian.org/devel/debian-installer/News/2021/20210802 - -> Automated installation -Some changes mentioned in the previous section also imply changes in +Some changes also imply changes in the support in the installer for automated installation using preconfiguration files. This means that if you have existing preconfiguration files that worked with the installer, you cannot expect these to work with the new -- 2.30.2 OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#991878: [armel] no longer supported devices
Hi On 04-08-2021 21:36, Holger Wansing wrote: > Martin Michlmayr wrote (Wed, 4 Aug 2021 17:03:05 +0800): >> * Holger Wansing [2021-08-04 10:57]: >>> Moreover, couldn't this be simplified then, into something like >>> >>> "Support for all QNAP Turbo Station devices (TS-xxx) was dropped?" >> >> There are also non-ARM Turbo Station devices (i.e. x86 based devices >> that will run regular Debian). But since this is in the armel release >> notes, I think your wording is fine. >> >> Support for all QNAP Turbo Station devices based on Marvell chips was >> dropped, but that might just make it more confusing. > > A patch based on this is attached (it makes the section only appear in > the armel release-notes - currently the paragraph is visible in all archs - > and changes the model numbers to "TS-xxx"). Thanks all. I pushed the change. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#989863: debian-installer: Firmware problems in bullseye
Hi Cyril, On 24-07-2021 09:05, Cyril Brulebois wrote: > @RT: I'd be happy to have some feedback from your regarding this > approach; telling people to enable contrib/non-free so that they > can install firmware packages is definitely *not* something I take > lightly, but I'd be happy to have some kind of review there to see > if that looks reasonable at all. I'm not sure there are many > options these days anyway… It's only my opinion, but as it's my understanding too that a lot of hardware just doesn't work great without the contrib/non-free drivers, I think it's sensible to help users with instructions on how to get those. You're not installing them and you're not enabling contrib/non-free, so decent warnings can be given (spirit of free software vs hardware that works well). I understand it's hard to get, but having the confirmation that `nomodeset` actually works for the (or most) black screen issues would obviously be great. Side note: apart from the installation guide, do we think that this warrants a note in the release notes too? > @RT: This would be my preferred approach, and based on cdbuilder coming > back up, plus my recent verifications in a d-i context, I think > this should be manageable in time for the announced release date. > Ideally we would be able to release an RC3 a week from now, letting > us fix any boo-boo in time before mid-August. I assume your ugly backup plan is (near) ready (or really trivial), so can be dropped in at the last moment in case there's set backs? > Thanks for your attention! I've had plenty on my mind, and some > braindump was in order. Sorry it's been *that* long a read. I even read in more than once to get the details right. Paul OpenPGP_signature Description: OpenPGP digital signature
Releasing bullseye on 14 August 2021 [Was Re: Finding a tentative bullseye release date]
Hi all, Thanks to the reply from Ansgar, we now have a release date for bullseye: 14 August. For the avoidance of doubt, this is *not* a tentative date anymore. I'll do a proper announcement later today or tomorrow evening. 14 August (day before DebCamp) RT: Adam Image: Steve, Andy Press: Donald FTP: Ansgar Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#990897: unblock: linux/5.10.46-1
Hi Salvatore, On 20-07-2021 20:05, Salvatore Bonaccorso wrote: > We do not have yet the signed packages that said, but once present > ideally the package get's aged as well to have fixes asap in bullseye. As asked on IRC: IIUC it's best to wait until all binaries are in and migrate the set right? So including the linux-signed-(amd64|arm64|i386) binaries. I've added the unblocks and urgents for linux-signed-* and all *but* the urgent for linux. If the answer is: let's migrate as they get in, please, any RT member, urgent linux. If the set arrives before I'm back on line, please, urgent linux. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, Current overview to check if I got things right and to hopefully trigger more replies. We currently don't have any day yet with all involved teams comfortably present, the one coming closest is 4 September. Somebody from ftp available on 14 august? 14 August (day before DebCamp) RT: Adam Image: Steve, Andy Press: Donald FTP: 21 August (last day of DebCamp) RT: Adam, elbrus Image: Press: 1/2 (not ideal) FTP: 28 August (DebConf) RT: elbrus Image: Press: FTP: Joerg 4 September RT: Adam, elbrus Image: Steve, Andy Press: FTP: Joerg 11 September: RT: Adam, elbrus, Sebastian Image: Andy Press: FTP: Joerg 18 September: RT: Adam, elbrus Image: Andy Press: Donald FTP: Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
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) 21 August (last day of DebCamp) RT: elbrus 28 August (DebConf) RT: elbrus 4 September RT: elbrus 11 September: RT: elbrus Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#990897: unblock: linux/5.10.46-1
Control: tags -1 d-i Hi, On 10-07-2021 22:15, Salvatore Bonaccorso wrote: > Hi release team, hi Cyril (specifically for d-i) So, let's add him (via d-boot) in. > Please unblock package linux > > It contained a rebase of the 5.10.y series to 5.10.46 upstream and > included the following changes relevant to add additional HW support > and bugfxes. The upstream import to 5.10.46 contained fixes for > various CVEs. Ack. > I guess at this point we want to delay any further 5.10.y imports to > the first bullseye point release, but let me know your toughts on > this. If the tentative release date becomes solid, I think that's a good plan. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#990932: unblock: udpkg/1.20
Control: tags -1 confirmed d-i Hi Steve, On 11-07-2021 12:21, Steve McIntyre wrote: > Please unblock package udpkg unblocked > 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. ...but waiting for ack from kibi. (Didn't see the CC, so adding d-boot). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 08-06-2021 21:30, Steve McIntyre wrote: > On Tue, Jun 08, 2021 at 08:50:55PM +0200, Paul Gevers wrote: >> 31 July: ** tentative ** release date > > Cool, works for me. Pencilled into my calendar now. :-) 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. We'll keep you posted as we learn more. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#990630: unblock: fuse3/3.10.3-2
Control: tags -1 d-i Hi On 03-07-2021 07:17, László Böszörményi (GCS) wrote: > [ Other info ] > Builds an udeb and needs a d-i hint as well. So, let's make kibi aware of this too (via boot). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#990531: unblock: grub2/2.04-19
Control: tags -1 confirmed d-i Hi, On 01-07-2021 14:02, Colin Watson wrote: > Please unblock grub2 2.04-19. This fixes unbootability problems after > certain kinds of grub-install failure, which I think constituted an > important-severity bug at the very least. I did this by resyncing the > grub-install backup/restore patches with what actually landed upstream; > we'd previously had early versions of these that hadn't been entirely > bug-fixed. > > I know that there may be more RC things to be fixed in grub2, but we > might as well get this in. I had a look at this the other day and if my memory recalls correctly, I'm fine with it. But as there's a block-udeb, we need an ACK from kibi (in CC via boot). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988830: [pre-approval] unblock e2fsprogs
Hi kibi, On 20-05-2021 17:55, Cyril Brulebois wrote: > If that's fine for the release team, I'd be happy to have the package in > unstable so that can be tested via daily builds of the installer (they > pull udebs from unstable). I'm not sure how much testing those daily > builds get from people running arm* systems, but it would be better to > have the fix at least exposed to some testing than just ponder looking > at the source debdiff (I know alignment issues are not my forte…). I'm following up on two bugs reported against the version in unstable, but assuming they're no regressions, how long do you want us to wait until unblocking it? Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all again, On 07-06-2021 23:08, Adam D. Barratt wrote: > On Mon, 2021-06-07 at 20:38 +0200, Paul Gevers wrote: >> Nevermind 10 July. Steve, you can stop contemplating about it. We'll >> go for 24 July as the *tentative* release date. > > Unfortunately I've just discovered that I was given the wrong date for > a family event, so I'm actually going to be AFK for most of the 24th. > :-( > > Apologies for sticking a slight spanner in the works at this stage. Those things happen. It's the price we pay for our bus factors (which we should fix/are fixing). 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 Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 06-06-2021 20:03, Paul Gevers wrote: > With the availability of Adam now known (and some off-list info), we have: > > 26 June > [Ansgar (ftp), Sebastian (release), Adam (release)] > 3 July > [Ansgar (ftp), Paul (release), Adam (release)] > 10 July > [Steve (CD) MAYBE , Ansgar (ftp), Paul (release), Adam (release), >Graham (release)] > 17 July > [Steve (CD), press, Ansgar (ftp), Paul (release)] > 24 July > [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (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)] > > So, what to pick? We still believe that shorter freezes are better for > the Debian community as a whole, so Steve can you look at turning your > maybe on 10 July into a "lets go for this"? If the answer is no, than > lets pick 24 July as the *tentative* release date. Nevermind 10 July. Steve, you can stop contemplating about it. We'll go for 24 July as the *tentative* release date. > Regardless of which of the two we pick, I propose we decide two weeks > before if it's going to be final. So, we'll decide around 10 July. > And, relevant for every maintainer of non-key packages without passing > autopkgtests, the full freeze will start two weeks before the > *tentative* release. The means that, with traditionally the last week > being totally frozen, the last week that packages can migrate *all* > packages need manual unblocks by the release team. And the Full Freeze will start on 10 July too. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 04-06-2021 06:49, Paul Gevers wrote: > 26 June [Ansgar (ftp)] > 3 July[Ansgar (ftp), Sebastian (release), Paul (release)] > 10 July [Steve (CD) MAYBE , Ansgar (ftp), Paul (release)] > 17 July [Steve (CD), press, Ansgar (ftp), Paul (release)] > 24 July [Steve (CD), press, Ansgar (ftp), Sebastian (release)] > 31 July [Steve (CD), press, Ansgar (ftp), Sebastian (release)] > 7 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)] > 14 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)] With the availability of Adam now known (and some off-list info), we have: 26 June [Ansgar (ftp), Sebastian (release), Adam (release)] 3 July [Ansgar (ftp), Paul (release), Adam (release)] 10 July [Steve (CD) MAYBE , Ansgar (ftp), Paul (release), Adam (release), Graham (release)] 17 July [Steve (CD), press, Ansgar (ftp), Paul (release)] 24 July [Steve (CD), press, Ansgar (ftp), Sebastian (release), Adam (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)] So, what to pick? We still believe that shorter freezes are better for the Debian community as a whole, so Steve can you look at turning your maybe on 10 July into a "lets go for this"? If the answer is no, than lets pick 24 July as the *tentative* release date. Regardless of which of the two we pick, I propose we decide two weeks before if it's going to be final. And, relevant for every maintainer of non-key packages without passing autopkgtests, the full freeze will start two weeks before the *tentative* release. The means that, with traditionally the last week being totally frozen, the last week that packages can migrate *all* packages need manual unblocks by the release team. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, On 30-05-2021 09:09, Paul Gevers wrote: > 26 June > 3 July > 10 July > 17 July [Steve (CD), press] > 24 July [Steve (CD), press] > 31 July > 7 August > 14 August This can now be updated to: 26 June [Ansgar (ftp)] 3 July[Ansgar (ftp), Sebastian (release), Paul (release)] 10 July [Steve (CD) MAYBE , Ansgar (ftp), Paul (release)] 17 July [Steve (CD), press, Ansgar (ftp), Paul (release)] 24 July [Steve (CD), press, Ansgar (ftp), Sebastian (release)] 31 July [Steve (CD), press, Ansgar (ftp), Sebastian (release)] 7 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)] 14 August [Steve (CD), press, Ansgar (ftp), Sebastian (release)] For those following along on IRC, we still have to figure out who from the release team that has access to the keys can join (if only for the signing). I hope we can update you on that shortly. On 30-05-2021 18:48, Steve McIntyre wrote: > 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! Again, without wanting to push, as we now have a point release before any of the mentioned dates, would any of the earlier dates be still a possibility from CD point of view? Andy, are you available? Donald, did you look at the earlier days and is press not available, or didn't you bother because of Steve's availability? Paul PS: I'm starting to realize I may feel uncomfortably direct for some people/cultures. The Dutch are known for it (some call it rude). Probably because I was raised like that, I don't want to read peoples mind, I rather hear what they mean. OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]
Control: tags -1 = confirmed d-i Hi Theodore, Sorry it took so long. On 20-05-2021 19:40, Theodore Y. Ts'o wrote: > That patch is rather long, but it's all mostly of the form: > > - tail = (struct ext4_fc_tail *)ext4_fc_tag_val(tl); > + memcpy(, ext4_fc_tag_val(tl), sizeof(tail)); > > So the risks are very low. As I can't judge this myself, I'll take your word for it. If the upload can happen in the next couple of days, let's have this in unstable and if nothing is reported, have it in bullseye. Let's leave out the rest. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988442: unblock: linux/5.10.40-1
Hi, On 01-06-2021 08:06, Salvatore Bonaccorso wrote: > The version is not 4 days in unstable, looks good to me to let it > migrate to testing (unless Cyril spotted issues in recent d-i tests). I'm still good to go. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi, 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. [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 7 August 14 August Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi all, 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? > 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 Forwarded Message Date: Fri, 28 May 2021 02:10:14 +0200 From: Cyril Brulebois [...] Right, I think I have a better grasp on where we stand. I haven't dug into each and every mail from debian-boot@, but it feels like people are generally happy with the installer in RC1 *provided* they don't run into the graphical installer hangs or issues at reboot time (due to firmware stuff). I have a few other topics that we may want to fix (serial console on s390x, problems on PowerPC, support for HTTPS, etc.) but that could be fixed in 11.1 or 11.n… Hangs in the graphical installer should be under control, even if it took quite some time and iterations and testing to figure that out for real. Firmware stuff is the next big item on my list. I've floated the idea of an RC2 in the next few days so that people could test the installer without fearing the hangs (and hopefully without finding new ones) but was waiting on linux to migrate, but some security issues came up and Salvatore would like to get 5.10.40 into testing instead, so it might be ready by next week-end (June 5-6)? I should be able to work on firmware stuff while waiting on the kernel to be ready. I'm mainly worried about the many hardware setups out there and having something that works for some machines locally might not be representative of what users are going to face. Provided I get a PoC ready in the right timing, and debian-cd people are available, we might be able to have something like the following: - RC2: June 5-6 (fixing hangs in graphical installer in particular) - RC3: June 12-13 (firmware PoC) The RC2 announcement (and maybe some help from publicity team) could be the right place to let people know we expect problems with firmware, and ask them to keep an eye on the RC3 that should feature an attempt at fixing it. Maybe setting up some wikipage where people could register their hardware and what they experience with the “stock” RC2, and where they could follow up with their experience with the “patched” RC3. There might be better tools for that, but I'm more used to pinging a submitter (or two or three) on a bug report than to collecting info from lots of people… If feedback from RC3 is good enough, we might call that RC sufficient to be the installer for 11.0, and think about a release by the end of June. We could refine it further still, e.g. by merging translation updates as what I have in mind would involve presenting users some information, which would require translation, but that's just a matter of uploading the right package with new/updated po files (the hard part is getting the actual translations, but we could think of merging those again in 11.1, 11.2, etc.). All that is rather optimistic (which I can try to be sometimes…), and I fear we might need to iterate a little, and I'm not sure how quickly we would get actionable feedback from users… If we were to hit real difficulties, maybe shift that “end of June” a few weeks, and call that “mid-July”? [...] OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988442: unblock: linux/5.10.37-1 (pre-approval checking)
Control: tags -1 confirmed d-i @boot: needs d-i ACK. As I believe you are aware of, the upload has already happened. @kibi: feel free to age it if/when you see fit Paul On 19-05-2021 17:27, Salvatore Bonaccorso wrote: > Control: retitle -1 unblock: linux/5.10.38-1 (pre-approval checking) > > On Thu, May 13, 2021 at 09:30:29AM +0200, Salvatore Bonaccorso wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> X-Debbugs-Cc: car...@debian.org >> >> Dear release team, >> >> As you know we follow the respective stable series as well in a stable >> release, and usually this is then done in point releases >> (exceptionally as well via a DSA). Now I know the time for bullseye is >> tight, but I would still like to followup with a stable series import >> in unstable, but wanted to double check with you in aprticular if >> there are ny timing issues with d-i. >> >> I would plan to upload based ideally on 5.10.37 because it will cover >> a big amount of bufixes but particularly recent CVEs which are >> important to have covered in bullseye already soon. Currently already >> covered in the imports done in git and in the packaging pending are >> CVE-2020-25670, CVE-2020-25671, CVE-2020-25672, CVE-2021-3489, >> CVE-2021-3490, CVE-2021-3491, CVE-2021-3493, CVE-2021-3501, >> CVE-2021-3506, CVE-2021-23133, CVE-2021-23134, CVE-2021-29155, >> CVE-2021-31829, but I would want do cover as well the recent >> FragAttack fixes (not yet worked on). >> >> In the packaging itself there will be additional changes pending >> currently they are: >> >>[ Vincent Blut ] >>* [x86] sound/soc/intel: Enable SND_SOC_INTEL_CATPT as module >> (Closes: #986822) >>* [x86] sound/soc/intel/boards: Enable SND_SOC_INTEL_BDW_RT5650_MACH as >> module >>* drivers/input/rmi4: Enable RMI4_F3A (Closes: #986848) >>* [armhf] drivers/gpio: Enable GPIO_MXC as module (Closes: #987019) >>* [x86] drivers/misc/mei: Enable INTEL_MEI_TXE, INTEL_MEI_HDCP as modules >> (Closes: #987281) >> >> All of those are for better hardware support. >> >>[ Uwe Kleine-König ] >>* [arm64] Enable more options for NXP's i.MX8 (Closes: #985862) >> >> Samewise. >> >>[ Salvatore Bonaccorso ] >>* vfs: move cap_convert_nscap() call into vfs_setxattr() (CVE-2021-3493) >>* Refresh "Makefile: Do not check for libelf when building OOT module" >>* [rt] Drop "xfrm: Use sequence counter with associated spinlock" >>* Bump ABI to 7 >>* Refresh "tools/include/uapi: Fix " >>* Revert "net/sctp: fix race condition in sctp_destroy_sock" >>* sctp: delay auto_asconf init until binding the first addr >> (CVE-2021-23133) >>* net/nfc: fix use-after-free llcp_sock_bind/connect (CVE-2021-23134) >>* bpf, ringbuf: Deny reserve of buffers larger than ringbuf >> (CVE-2021-3489) >>* bpf: Prevent writable memory-mapping of read-only ringbuf pages >>* bpf: Fix alu32 const subreg bound tracking on bitwise operations >> (CVE-2021-3490) >>* io_uring: truncate lengths larger than MAX_RW_COUNT on provide buffers >> (CVE-2021-3491) >> >> Various CVE fixes (which will though go as well partially in 5.10.37 >> directly), >> the FragAttack CVEs are not yet included. >> >> The RT patch which can be dropped after checking with Sebastian >> Andrzej Siewior. An ABI bump included, note that the changes are quite >> massive up to 5.10.37, (5.10.37 will contain approximately 530 >> upstream commits, 5.10.36 was as well with 300 a bigger one). I >> realize this might scary, but in the end this is the stragegy we >> necessarily need to follow to keep up with upstream stable releases. >> >>[ Vagrant Cascadian ] >>* [arm64] Disable USB type-C DisplayPort in pinebook pro device-tree. >>* [arm64] Enable TYPEC_FUSB302, SND_SOC_ES8316, TYPEC and TYPEC_TCPM as >> modules. (Closes: #987638) >> >>[ Michal Simek ] >>* [arm64] Enable clock driver for Xilinx ZynqMP SoC >> >> Additional support for hardware in the arm64 area. >> >>[ Valentin Vidic ] >>* [s390x] udeb: Include standard scsi-modules containing the virtio_blk >> module (Closes: #988005) >> >> "Acked"/wished by KiBi, to align s390x installer support to the other >> architectures. >> >> The current state is at https://salsa.debian.org/kernel-team/linux/-/tree/sid >> >> Let me know what you think of it, I would in any case send the usual >> "Upload announcement" to the various involved teams before the upload >> summarizing again the changes. > > For the record, this will be 5.10.38 based. I delayed on purpose given > the size which was forseen. > > If anybody has concern on the upload, please raise a flag. > > Regards, > Salvatore > OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988472: install-mbr doesnt create a partition
Control: reassign -1 installation-guide On 13-05-2021 18:32, Justin B Rye wrote: > Marc Haber wrote: >> Package: release-notes >> Severity: minor >> >> Hi, >> >> Chapter 4.3.3.1 of the release notes suggest using install-mbr /dev/sdX >> followed by mkdosfs /dev/sdX1. On a really blank medium, this doesn't >> work since install-mbr does NOT create a partition. > > You mean the Installation Guide, not the Release Notes. > > > "https://www.debian.org/releases/stable/amd64/ch04s03.en.html#usb-copy-flexible; > | Since most USB sticks come pre-configured with a single FAT16 > | partition, you probably won't have to repartition or reformat the > | stick. If you have to do that anyway, use cfdisk or any other > | partitioning tool to create a FAT16 partition[3], install an MBR using: > | > | # install-mbr /dev/sdX > | > > It looks to me as if this needs "(and) then" before "install", among > other fixes. For instance, footnote 3 is: > > | [3] Don't forget to set the "bootable" bootable flag. > > which is probably trying to say: > > [3] Don't forget to activate the "bootable" flag. OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988814: unblock: gtk+2.0/2.24.33-2
Hi, On 25-05-2021 01:01, Cyril Brulebois wrote: > I'm happy to have gtk+2.0 migrate to testing as soon as seems reasonable > from the release team point of view. Ditto for cdebconf, but I can file > a separate request for that, as is customary for unblock requests. unblocked both gtk+2.0 and cdebconf, both aged too, gtk+2.0 should migrate on the next run. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988740: unblock: glibc/2.31-12
Hi kibi, On 24-05-2021 06:30, Cyril Brulebois wrote: > Nothing dramatic, we'll be more explicit next time and pick an option > for real instead of considering both options and letting one pick a > favorite. :) Let's agree on that indeed. It's a shame that we get into these annoyances, while all we try to do is help each other. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988832: unblock: libx11/2:1.7.1-1
Control: tags -1 d-i confirmed Hi, On 20-05-2021 10:26, Emilio Pozuelo Monfort wrote: > Please unblock package libx11 This needs also an ack from d-i, boot CC-ed. > This fixes CVE-2021-31535, a bug in libX11 which could lead to the > execution of additional X requests due to insufficient buffer checks. > > I have done some manual tests (run an X server with various applications) > > The risks are minor as the changes are pretty much limited to the security > fix, with minor changes aside of that. > > [ Checklist ] > [x] all changes are documented in the d/changelog > [x] I reviewed all changes and I approve them > [x] attach debdiff against the package in testing > > The debdiff is a little large due to the autotools version the tarball > was generated with. I'm attaching a debdiff filtered with > > filterdiff -x '*/Makefile.in' -x '*.man' -x '*/aclocal.m4' -x '*/configure' > > (the *.man changes are actual manpage syntax fixes, but make it harder to > review > the actually important code fixes in this update, so I filtered them). Funny how some copyrights go backward in time in this release. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988585: unblock: grub2/2.04-18
Control: tags -1 d-i confirmed
Hi,
This needs an ACK from d-boot as well.
On 16-05-2021 12:05, Colin Watson wrote:
> Please unblock grub2 2.04-18. This is mostly fixes from Steve to sort
> out UEFI Secure Boot on i386. The upstream patch to fix section size
> calculation *seems* to only fix a problem on ia64 right now, which of
> course wouldn't be release-critical by itself, but having
> potentially-incorrect section sizes gives me the shivers so I thought it
> best to include this as well.
>
> You may need to manually unblock grub-efi-{amd64,arm64,ia32}-signed as
> well to match, since these four source packages must all have matching
> versions - I'm not sure exactly how the tools work from your end.
>
> diff -Nru grub2-2.04/debian/.git-dpm grub2-2.04/debian/.git-dpm
> --- grub2-2.04/debian/.git-dpm2021-03-19 10:41:41.0 +
> +++ grub2-2.04/debian/.git-dpm2021-04-25 16:20:17.0 +0100
> @@ -1,6 +1,6 @@
> # see git-dpm(1) from git-dpm package
> -3d246c561a2c6aa18b78eae69e5100a2347dc7aa
> -3d246c561a2c6aa18b78eae69e5100a2347dc7aa
> +0eae44daa60c3f0ce8fdb349ba71b869a6738efd
> +0eae44daa60c3f0ce8fdb349ba71b869a6738efd
> 578bb115fbd47e1c464696f1f8d6183e5443975d
> 578bb115fbd47e1c464696f1f8d6183e5443975d
> grub2_2.04.orig.tar.xz
> diff -Nru grub2-2.04/debian/build-efi-images
> grub2-2.04/debian/build-efi-images
> --- grub2-2.04/debian/build-efi-images2021-03-19 10:41:41.0
> +
> +++ grub2-2.04/debian/build-efi-images2021-04-25 16:20:17.0
> +0100
> @@ -150,12 +150,6 @@
> cpuid
> linuxefi
> play
> - "
> - ;;
> -esac
> -case $platform in
> -x86_64-efi)
> - CD_MODULES="$CD_MODULES
> tpm
> "
> ;;
> @@ -197,6 +191,7 @@
> "
>
> # CD boot image
> +echo "Including modules $CD_MODULES in $outdir/gcd$efi_name.efi"
> "$grub_mkimage" -O "$platform" -o "$outdir/gcd$efi_name.efi" \
> -d "$grub_core" \
> -c "$workdir/grub-bootstrap.cfg" -m "$workdir/memdisk.fat" \
> @@ -205,12 +200,14 @@
> $CD_MODULES
>
> # Normal disk boot image
> +echo "Including modules $GRUB_MODULES in $outdir/grub$efi_name.efi"
> "$grub_mkimage" -O "$platform" -o "$outdir/grub$efi_name.efi" \
> -d "$grub_core" -p "/EFI/$efi_vendor" \
> --sbat "$sbat_csv" \
> $GRUB_MODULES
>
> # Normal network boot image
> +echo "Including modules $NET_MODULES in $outdir/grubnet$efi_name.efi"
> "$grub_mkimage" -O "$platform" -o "$outdir/grubnet$efi_name.efi" \
> -d "$grub_core" -c "$workdir/grub-bootstrap.cfg" \
> -m "$workdir/memdisk-netboot.fat" \
> @@ -221,6 +218,7 @@
> # Special network boot image for d-i to use. Just the same as the
> # normal network boot image, but with a different value baked in for
> # the prefix setting
> +echo "Including modules $NET_MODULES in
> $outdir/grubnet$efi_name-installer.efi"
> "$grub_mkimage" -O "$platform" -o "$outdir/grubnet$efi_name-installer.efi" \
> -d "$grub_core" -c "$workdir/grub-bootstrap.cfg" \
> -m "$workdir/memdisk-netboot.fat" \
> diff -Nru grub2-2.04/debian/changelog grub2-2.04/debian/changelog
> --- grub2-2.04/debian/changelog 2021-03-19 10:41:41.0 +
> +++ grub2-2.04/debian/changelog 2021-04-25 16:20:17.0 +0100
> @@ -1,3 +1,18 @@
> +grub2 (2.04-18) unstable; urgency=medium
> +
> + [ Steve McIntyre ]
> + * Enable the shim_lock and tpm modules for i386-efi too. Ensure that
> +tpm is included in our EFI images.
> + * List the modules we include the EFI images - make it easier to
> +debug things.
> + * Add debug to display what's going on with verifiers
> +
> + [ Colin Watson ]
> + * util/mkimage: Some fixes to PE binaries section size calculation
> +(closes: #987103).
> +
> + -- Colin Watson Sun, 25 Apr 2021 16:20:17 +0100
> +
> grub2 (2.04-17) unstable; urgency=medium
>
>* Pass --sbat when building the d-i netboot image as well.
> diff -Nru grub2-2.04/debian/patches/debug_verifiers.patch
> grub2-2.04/debian/patches/debug_verifiers.patch
> --- grub2-2.04/debian/patches/debug_verifiers.patch 1970-01-01
> 01:00:00.0 +0100
> +++ grub2-2.04/debian/patches/debug_verifiers.patch 2021-04-25
> 16:20:17.0 +0100
> @@ -0,0 +1,28 @@
> +From bb6fe7f81818b8d102ca92b174d79aebb62469a0 Mon Sep 17 00:00:00 2001
> +From: Steve McIntyre <93...@debian.org>
> +Date: Sat, 17 Apr 2021 22:05:47 +0100
> +Subject: Add debug to display what's going on with verifiers
> +
> +Patch-Name: debug_verifiers.patch
> +---
> + grub-core/kern/verifiers.c | 2 ++
> + 1 file changed, 2 insertions(+)
> +
> +diff --git a/grub-core/kern/verifiers.c b/grub-core/kern/verifiers.c
> +index 58dbe152a..ff984c8d8 100644
> +--- a/grub-core/kern/verifiers.c
> b/grub-core/kern/verifiers.c
> +@@ -100,11 +100,13 @@ grub_verifiers_open (grub_file_t io, enum
> grub_file_type type)
> + FOR_LIST_ELEMENTS(ver, grub_file_verifiers)
> + {
> + enum grub_verify_flags flags =
Re: Bug#988814: unblock: gtk+2.0/2.24.33-2
Control: tags -1 confirmed d-i On 19-05-2021 21:54, Simon McVittie wrote: > Please unblock package gtk+2.0 Ok from my side. As this upload is to fix the d-i issue I'm pretty sure that debian-boot is also fine, but I promised kibi this morning that I'll follow the process and wait for an explicit ACK from their side. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#988740: unblock: glibc/2.31-12
Hi Cyril
On 20-05-2021 08:23, Cyril Brulebois wrote:
> Having udeb-producing packages change under our feet when we're in
> the middle of unentangling the rendering mess isn't exactly nice…
I'm terribly sorry, but I thought we discussed migrating udeb generating
packages recently on IRC #d-release. I now realize that's a bit longer
ago than I though. To quote you:
[00:00:00] - {Day changed to Monday, 26 April 2021}
[22:06:17] looks to me we have enough to fix and/or to debug on
our plate that we won't be issuing another RC in a week or so, so
freezing everyone (keeping everyone frozen) will only generate more
requests for acks; at this stage, it's likely easier to let stuff
migrate and deal with consequences afterward
I interpreted that as you are sort of fine at this moment if we migrated
the packages if they are otherwise fine. We should have agreed on a
schedule and it was on my TODO list to ask you today.
Additional note: glibc is on the list of build-essentials [1], so,
according to our freeze policy [2] it would have needed a pre-approval
already.
Paul
[1] https://release.debian.org/bullseye/essential-and-build-essential.txt
[2] https://release.debian.org/bullseye/freeze_policy.html#transition
OpenPGP_signature
Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi Cyril, On 23-04-2021 15:13, Cyril Brulebois wrote: >> Seems like our current best option is May 22 if you can make it. > > That's definitely not what I would call “best option” from an > installer point of view. I hear you. So, I fear that we're getting into a situation where everything except the installer is more or less ready for the bullseye release. (Well assuming the shim is signed any time soon). > D-I Bullseye RC 1 was published a few hours ago. And at the risk of > sounding like a broken record: I have *absolutely no guarantee* to > have a fix or workaround for the amdgpu issue in less than a month, > that would be tested somewhat. > > Can we please *not* release with black screens for AMD users? Indeed, let's not. But can't we get the full Debian community on board to search for good solution? I have the feeling there's much interest to release sooner rather than late, so maybe there's brains we can use to help the installer forward? I'm going to draft a bits shortly, is there a bug number or mail thread we can point at? Also, I recognize that the debian-installer is largely handled by you alone. I estimate that it's not going to help you on the short term if people volunteer to help with the coding as you would be spending time on on-boarding them. So, how can we, the Debian Community, help you getting the installer in releasable shape? I can think of testing RC1, but what else? Do you have the right hardware available for the amdgpu issue? Can people try out solutions for you? Tell us, or tell us how to find out. That said, I still think it's good to keep May 22 in the agenda as an option to do the release, with the remark that we'll not release when we're not ready (as Debian always does). Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi ftpmasters, Adam, On 09-04-2021 20:47, Paul Gevers wrote: > Dear release team, ftpmasters, press team, cd team, d-i team, [...] > We propose to aim for a release date in May. Would either of the > following work for you and do you have any preference? > - May 1 > - May 8 > - May 15 > - May 22 > - May 29 I've seen replies from Steve for CD, from Donald for Press and Cyril for d-i. Can you please let us know if/when you're available? May 1 CD, Press May 8 CD, Press May 15 CD May 22 CD, Press May 29 (CD) [d-i: the later the better] Seems like our current best option is May 22 if you can make it. Paul OpenPGP_signature Description: OpenPGP digital signature
inquiring for input to the release notes
Hi boot team, As is custom in the final phases of the release, I'm asking you to think about issues that are worth mentioning in the release notes for bullseye from the perspective of the installer. Feel free to reply to this e-mail, or, even better, to bts against the release-notes package if there's anything that comes to your mind. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi Holger, On 10-04-2021 18:14, Holger Wansing wrote: >>> 2. A problem came up during freeze regarding input methods for several >>>languages: >>>Starting with bullseye, GNOME depends on ibus, which is not fully >>>compatible with the view of some language teams, who would like to >>>prefer fcitx. >>>The best way to get this situation fixed would require some new >>>binary packages to be added to Bullseye (would only be tasks packages, >>>so no new code/functions to be added!). >>>A thread regarding this started at >>> https://lists.debian.org/debian-boot/2021/03/msg00058.html >>>and the release-team was also added to the loop at some point. >>>Maybe release-team could look into this too, and try to make a >>>decision? >> >> Did you conclude in that thread what the optimal option would be from >> your side? And what's the preferred option without new packages? > > That's not just my opinion, but sort of consensus of the involved people. > Going through the above mentioned thread shows that. > There are also alternatives mentioned, but they all have their disadvantages, > that's why the consensus. We had a bit of discussion on this and if you think with these addition (meta) packages we can fix this problem, let's have them. Please prepare and upload. We'll notify ftp-masters that this upload to NEW is meant for bullseye. Ideally of course, you'd be able to test in unstable that the solution actually works before we accept them in testing. Is that feasible? Side note, on our check list [1], there's also a note on asking you if the install guide is up-to-date. Can you confirm that? Paul [1] https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/BullseyeCheckList OpenPGP_signature Description: OpenPGP digital signature
Re: Finding a tentative bullseye release date
Hi Holger, On 10-04-2021 12:59, Holger Wansing wrote: > Maybe the release-team could look into the pending unblock issues for d-i > in the meantime? Were unblock requests filed? If so, can you point me at them as I don't know which unblock requests you're talking about? If not, they don't appear magically on our radar, the best course of action is to file unblock reports (with the right meta info, so please use reportbug) for packages that need to migrate but are blocked. > Most of them should be quite unproblematic, since they only contain > translation > updates. > > A bit more of an issue would be tasksel. > 1. Currently there is 3.65 in sid, which needs to migrate to bullseye. This one was missing an unblock request. I have just unblocked it. > 2. A problem came up during freeze regarding input methods for several >languages: >Starting with bullseye, GNOME depends on ibus, which is not fully >compatible with the view of some language teams, who would like to >prefer fcitx. >The best way to get this situation fixed would require some new >binary packages to be added to Bullseye (would only be tasks packages, >so no new code/functions to be added!). >A thread regarding this started at > https://lists.debian.org/debian-boot/2021/03/msg00058.html >and the release-team was also added to the loop at some point. >Maybe release-team could look into this too, and try to make a >decision? Did you conclude in that thread what the optimal option would be from your side? And what's the preferred option without new packages? Paul OpenPGP_signature Description: OpenPGP digital signature
Finding a tentative bullseye release date
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 Paul [1]
Bug#982838: RoM: win32-loader must not migrate automatically
Hi Didier, On Mon, 15 Feb 2021 08:45:26 +0100 Didier 'OdyX' Raboud wrote: > It'll be updated to be marked "found" in the latest version, and "notfound" > in any version allowed to migrate. I think it's a tiny bit better to use "fixed" for the version that's allowed to migrate. "notfound" is just to remove "found" and with the current "found" not in the archive, the bts thinks that all versions are effected by this bug. And if I understand correctly, this bug can also be tagged "sid". Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#971019: accidental chaining of debconf commands
Hi, Excuse me if I totally got this wrong, but to an outsider this looks like a typo... On Sat, 26 Sep 2020 12:17:13 +0200 Wilco Baan Hofman wrote: > debconf: --> FGET clock-setup/utc seen ^ hyphen > debconf: <-- 0 true > debconf: --> SET clock-setup/utc true INPUT low clock-setup/utc > ^ hyphen ^ hyphen > debconf: <-- 0 value set > debconf: --> GO > debconf: <-- 0 ok > debconf: --> GET clock/setup/utc ^ slash > debconf: <-- 0 true INPUT low clock-setup/utc ^ hyphen > debconf: --> GET clock-setup/system-time-changed > debconf: <-- 0 false > For reproducing the error if that's required: > This is a preseeded Debian Buster install on VMWare ESXi, relevant > preseed config: > > ### Clock and timezone setup > # Controls whether or not the hardware clock is set to UTC. > d-i clock-setup/utc boolean true ^ hyphen Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#982035: tasksel depends on man-pages-it which has been removed
Package: tasksel Version: 3.63 Severity: serious Justification: not installable Hi, man-pages-it has been removed from unstable. Don't ask me how that is possible as your package still depends on it, but it happened. Please drop the dependency. The RM bug #979034 suggests the data now lives elsewhere, albeit I don't know where. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#960056: src:tasksel: fails to migrate to testing for too long
Hi Holger, On 10-05-2020 19:55, Paul Gevers wrote: >> I fail to see what's the reason for this. > > I'll have a more careful look. The britney output [1] shows that tasksel isn't migrating because it would make task-pkgs-are-installable-faux non-installable in testing: skipped: tasksel (0, 56, 48) got: 22+0: a-1:a-0:a-0:a-0:i-19:m-0:m-1:p-0:s-1 * mipsel: task-pkgs-are-installable-faux task-pkgs-are-installable-faux isn't a real package, but a package created by the release team in the britney code [2] to prevent non-installability of tasksel in testing. However, that requires that package to be up-to-date with the real tasksel package. In the latest upload task-printer-server was dropped, so migrating tasksel to testing would make the faux package non-installable, hence it was blocked. I have updated the faux package. >> We have some pending changings in git. >> Should I do another upload, to try to get this fixed? > > That won't hurt after we figure out what's wrong, but I believe it would > be coincidental if it would fix the issue. So indeed. You would have to reinstate the task-printer-server for the migration to work. Please wait with uploading the changes until tasksel migrates. Paul [1] https://release.debian.org/britney/update_output.txt [2] https://salsa.debian.org/release-team/britney1/-/blob/master/input/constraints signature.asc Description: OpenPGP digital signature
Bug#960056: src:tasksel: fails to migrate to testing for too long
Hi Holger, On 10-05-2020 19:38, Holger Wansing wrote: > This has already been noted on debian-boot some days ago. Ack. > I fail to see what's the reason for this. I'll have a more careful look. > We have some pending changings in git. > Should I do another upload, to try to get this fixed? That won't hurt after we figure out what's wrong, but I believe it would be coincidental if it would fix the issue. Paul signature.asc Description: OpenPGP digital signature
Bug#960056: src:tasksel: fails to migrate to testing for too long
Source: tasksel Version: 3.58 Severity: serious Control: close -1 3.59 Tags: sid bullseye User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), kibi, As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:tasksel in its current version in unstable has been trying to migrate for 60 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=tasksel signature.asc Description: OpenPGP digital signature
Bug#953783: src:installation-guide: fails to migrate to testing for too long
Source: installation-guide Version: 20190622 Severity: serious Control: fixed -1 20191229 Tags: sid bullseye pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:installation-guide in its current version in unstable has been trying to migrate for 74 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have marked the version in unstable as fixing this bug, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bullseye, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=installation-guide signature.asc Description: OpenPGP digital signature
Bug#945772: kernel-wedge: autopkgtest failure: +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation)
Source: kernel-wedge Version: 2.100 X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: regression Dear maintainers, With a recent upload of kernel-wedge you introduced an autopkgtest in your package. However the test fails. I copied some of the output at the bottom of this report. Are you missing a test dependency? Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=kernel-wedge https://ci.debian.net/data/autopkgtest/testing/amd64/k/kernel-wedge/3378125/log.gz autopkgtest [04:27:25]: test preprocess: [--- I: Testing preprocess case builtin Files /dev/null and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/builtin.err differ --- /dev/null 2019-11-10 04:27:02.357733355 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/builtin.err 2019-11-10 04:27:26.013635941 + @@ -0,0 +1 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) E: rc=0 I: Testing preprocess case excludemissing Files /dev/null and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/excludemissing.err differ --- /dev/null 2019-11-10 04:27:02.357733355 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/excludemissing.err 2019-11-10 04:27:26.057635759 + @@ -0,0 +1 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) E: rc=0 I: Testing preprocess case hyphen Files /dev/null and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/hyphen.err differ --- /dev/null 2019-11-10 04:27:02.357733355 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/hyphen.err 2019-11-10 04:27:26.101635578 + @@ -0,0 +1 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) E: rc=0 I: Testing preprocess case include Files /dev/null and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/include.err differ --- /dev/null 2019-11-10 04:27:02.357733355 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/include.err 2019-11-10 04:27:26.145635397 + @@ -0,0 +1 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) E: rc=0 I: Testing preprocess case missing Files debian/tests/preprocess-data/missing.err and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/missing.err differ --- debian/tests/preprocess-data/missing.err2019-02-12 19:30:33.0 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/missing.err 2019-11-10 04:27:26.185635232 + @@ -1,2 +1,3 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) missing module does-not-exist Died at SOMEWHERE. E: rc=255 I: Testing preprocess case missingdir Files debian/tests/preprocess-data/missingdir.err and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/missingdir.err differ --- debian/tests/preprocess-data/missingdir.err 2019-02-12 19:29:24.0 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/missingdir.err 2019-11-10 04:27:26.229635051 + @@ -1 +1,2 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) pattern missing/dir/* refers to nonexistent subdirectory at SOMEWHERE, <$fh> line 1. E: rc=2 I: Testing preprocess case simple Files /dev/null and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/simple.err differ --- /dev/null 2019-11-10 04:27:02.357733355 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/simple.err 2019-11-10 04:27:26.273634869 + @@ -0,0 +1 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) E: rc=0 I: Testing preprocess case underscore Files /dev/null and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/underscore.err differ --- /dev/null 2019-11-10 04:27:02.357733355 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/underscore.err 2019-11-10 04:27:26.313634705 + @@ -0,0 +1 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) E: rc=0 I: Testing preprocess case wilddoublestar Files /dev/null and /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/wilddoublestar.err differ --- /dev/null 2019-11-10 04:27:02.357733355 + +++ /tmp/autopkgtest-lxc.r3lmallz/downtmp/autopkgtest_tmp/wilddoublestar.err 2019-11-10 04:27:26.357634524 + @@ -0,0 +1 @@ +dpkg-architecture: warning: cannot determine CC system type, falling back to default (native compilation) E: rc=0 I: Testing preprocess case wildstar Files /dev/null and
Re: Bug#933829: win32-loader: Checksums need to be updated for new stable release, download fails to validate Release file.
clone 933829 -2 reassign -2 release.debian.org retitle -2 buster-pu: package win32-loader/0.9.3+deb10u1 user release.debian@packages.debian.org usertags pu thanks Let's hope I got that right. On 16-08-2019 08:55, Didier 'OdyX' Raboud wrote: > debian-boot@ / debian-release@: can I upload src:win32-loader in source only > with the following diff? Mail like this tends to get processed late on our side. I cloned this question as a bug, such that it shows up in the right place, hopefully. Paul signature.asc Description: OpenPGP digital signature
Bug#924657: release-notes? Was: Re: kbdnames are generated with incorrect translations
Hi all, On Fri, 15 Mar 2019 14:38:07 + Iain Lane wrote: > Package: keyboard-configuration > Version: 1.188 > Severity: serious > Tags: patch [...] > The generated names in keyboard-configuration.config are translated > incorrectly: > > laney@raleigh> dpkg --ctrl-tarfile keyboard-configuration_1.188_all.deb | > tar xO- ./config | grep "en_GB\*model\*sun_type6_jp" > en_GB*model*sun_type6_jp*Sun Type 6 (Japonesa) > en_GB*model*sun_type6_jp_usb*Sun Type 6 USB (Japonesa) > > That should be "(Japanese)". Very many other entries are also affected. > I've provided a patch on the referenced salsa URL. This apparently wasn't uploaded, so it's to late for the initial buster release. Does it make any sense to mention this in the release notes? I tend to say it doesn't, but will do it nevertheless when others think it does. Paul signature.asc Description: OpenPGP digital signature
Re: Same issue as already reported, and partially fixed
severity 55 grave merge 929172 904699 thanks Hi Diederik, On 31-05-2019 21:16, Diederik de Haas wrote: > Control: severity -1 serious Please don't use this if you CC multiple bugs that aren't all of the same severity. > The fix has actually been made. But the problem is that it needs an unblock > ack > from the d-i team (https://bugs.debian.org/928908), but after 2 weeks there > is > still no reply. Please have patience. D-I is busy. > When that is done, (afaik) a rebuild of the package to pick up the change in > libdebian-installer is needed (at least for cdebootstrap-static? which I'm > using). Please file a binNMU bug already than (I didn't check if that is the correct course of action, but better discuss that there). Paul signature.asc Description: OpenPGP digital signature
Re: Bug#925971: release-notes: should mention secure boot in d-i
Hi Ben, Holger, On 22-04-2019 00:25, Ben Hutchings wrote: > On Fri, 2019-03-29 at 16:45 +0100, Paul Gevers wrote: >> Package: release-notes >> X-Debbugs-CC: debian-boot@lists.debian.org >> >> As now discussion on the RT sprint, the release notes should probably >> say something about the work on secure boot. >> >> I wouldn't know what to put in, so proposals are welcome. Until that >> time, I file this bug to not forget. > > I don't have a complete proposed text, but I think the key points to > include are: > > * Secure Boot is a feature enabled on most PCs that prevents loading > unsigned code, protecting against some kinds of bootkit and rootkit. > > * Debian can now be installed and run on most PCs with Secure Boot > enabled. > > * It is possible to enable Secure Boot on a system that has an existing > Debian installation, if it already boots using UEFI. Before doing > this, it's necessary to install shim-signed, grub-efi-amd64-signed or > grub-efi-ia32-signed, and a Linux kernel package from buster. > > * Some features of GRUB and Linux are restricted in Secure Boot mode, > to prevent modifications to their code. > > * More information can be found on the Debian wiki at > <https://wiki.debian.org/SecureBoot>. For now (I do expect improvements after review, but didn't want to wait), I have basically committed the text above: https://salsa.debian.org/ddp-team/release-notes/commit/90a9a34 as well as applied more or less the update proposed by Holger: https://salsa.debian.org/ddp-team/release-notes/commit/f112557 Thanks Paul signature.asc Description: OpenPGP digital signature
Re: [buster] query about status of installation-guide and d-i release notes
Hi Holger, On 25-04-2019 08:11, Holger Wansing wrote: > Paul Gevers wrote: > First, I wonder why you ask personally me for this. Because the task was originally self-assigned to kibi and was documented on the wiki [1] as "ask Holger". > Why not ask the debian-boot team? See above. I didn't intent at all to keep this away from them. > Second: now that you have asked, the installation-guide should be mostly > release-ready; one can consider an exception here, which is Secure Boot. > This functionality has been added in a last minute rush into the installer, > and thus is not properly documented in the installation-guide. > However, the guide is still release-ready despite this, if you ask me. Good to know. Thanks. > When it comes to the release-notes, I mailed a short proposal for this to > debian-boot weeks ago, but got no answer. > And I already pointed you to this mail some days ago. Ack. I noted the reply and thanks for that as well. Paul signature.asc Description: OpenPGP digital signature
Re: Bug#925971: release-notes: should mention secure boot in d-i
Hi Debian-boot, Friendly ping. On Sat, 30 Mar 2019 07:44:30 + Steve McIntyre wrote: > On Fri, Mar 29, 2019 at 04:45:20PM +0100, Paul Gevers wrote: > >As now discussion on the RT sprint, the release notes should probably > >say something about the work on secure boot. > > > >I wouldn't know what to put in, so proposals are welcome. Until that > >time, I file this bug to not forget. > > ACK. We'll have some text to add. :-) Paul signature.asc Description: OpenPGP digital signature
Bug#925971: release-notes: should mention secure boot in d-i
Package: release-notes X-Debbugs-CC: debian-boot@lists.debian.org As now discussion on the RT sprint, the release notes should probably say something about the work on secure boot. I wouldn't know what to put in, so proposals are welcome. Until that time, I file this bug to not forget. Paul signature.asc Description: OpenPGP digital signature
Re: release-notes: please document unattended-upgrades
Hi On 23-03-2019 12:47, Cyril Brulebois wrote: > This was backed out at the request of the security team: > > https://tracker.debian.org/news/974578/accepted-pkgsel-057-source-into-unstable/ > > so I guess this makes this bug report moot? So let's close the bug. Paul signature.asc Description: OpenPGP digital signature
Bug#925368: di-netboot-assistant: autopkgtest needs update archiving of wheezy
Source: di-netboot-assistant Version: 0.60 Severity: important X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: issue Control: affects -1 src:grub2 Dear maintainers, With a recent upload of grub2 the autopkgtest of di-netboot-assistant fails in testing when that autopkgtest is run with the binary packages of grub2 from unstable. It turns out that this has nothing to do with grub2, but is due to the archiving of wheezy. I copied some of the output at the bottom of this report. Can you please fix the autopkgtest? It seems adding a allow-stderr restriction is enough for, which is eligible for an unblock exception, however, I think and hope a better fix can be found (possibly after buster). Paul https://ci.debian.net/data/autopkgtest/testing/amd64/d/di-netboot-assistant/2147585/log.gz autopkgtest [16:13:48]: test std-run: - - - - - - - - - - results - - - - - - - - - - std-run FAIL stderr: E: Can't download 'wheezy' for 'amd64' (https://deb.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/SHA256SUMS). signature.asc Description: OpenPGP digital signature
Re: release-notes: please document unattended-upgrades
Control: tags -1 moreinfo Hi all, On Wed, 06 Dec 2017 19:39:08 +0100 Cyril Brulebois wrote: > [Please keep debian-boot@ and hert...@debian.org in copy of your answers.] done. > Raphaël Hertzog enabled unattended-upgrades support by default in pkgsel, > which is first shipped with the D-I Buster Alpha 2 release (#875858). > > It would be nice to document this change in the release notes, along with > possible configuration changes users might want to perform, if only how to > opt out in case one doesn't wish to use this feature (I figure removing the > package entirely is the easiest, but it could be pulled through recommends, > so advice on configuration variables might be valuable). I also think this would suite the release-notes. As I am totally unfamiliar with the configuration of unattended-upgrades, I don't want to write this myself. Can somebody propose a text (ideally via a MR against https://salsa.debian.org/ddp-team/release-notes/) Paul signature.asc Description: OpenPGP digital signature
Re: debootstrap/1.0.102 appears to break debuerreotype autopkgtest
Hi Tianon, On 14-06-18 10:19, Ansgar Burchardt wrote: > The patch for #839046 also disabled --merged-usr for stretch as stretch > was added to the blacklist in first_stage_install(). > > debootstrap should default to non-merged-usr for stretch, but it should > be possible to enable merged-usr via the command-line parameter to avoid > the regression in debuerreotype. It would be nice if you responded to this idea of Ansgar, as the regression in debuerreotype is currently delaying the migration of debootstrap. Is the new behavior of debootstrap really bad for debuerreotype or is it just resulting in a different image which is fine otherwise for your package? In the former case, you should file an RC bug in that case to block debootstrap from migrating until debuerreotype is ready. In the latter case, you can unblock the migration of debootstrap by adapting debuerreotype and/or its autopkgtest (and please let me know). Or, e.g. because you are lacking time, you can tell me that you are fine with the current regression and I can instruct the migration software to ignore it (less preferred). Just to be absolutely clear, if nothing happens, debootstrap will migrate in 10 days to testing and the new behavior will be the baseline for autopkgtesting. Paul signature.asc Description: OpenPGP digital signature
debootstrap/1.0.102 appears to break debuerreotype autopkgtest
Dear maintainers, With a recent upload of debootstrap the autopkgtest of debuerreotype version 0.6-1 started to fail. See: https://ci.debian.net/packages/d/debuerreotype/ and https://qa.debian.org/excuses.php?package=debootstrap I looked at the test¹ and it compares the result of the current run of debuerreotype with a stored hash. Luckily debuerreotype use diffoscope to investigate the delta. It seems that debuerreotype is hit by this change in debootstrap: * Enable merged-/usr by default (Closes: #839046) This is applied for buster and later. I am not sure if this should NOT have let to a change in debuerreotype, as I believe that is testing stretch. On top of that, I wonder if this test is sensitive to changes in the security archive. Currently this regression is delaying the migration of debootstrap to testing by 13 days. Could we please discuss together what the best way forward is for this regression in testing? (Just so you know, I am empowered to have the migration software ignore the results of this specific test if we all agree this isn't a regression that should block debootstrap). More information about this email and the reason of it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul ¹ https://github.com/debuerreotype/debian-debuerreotype/blob/master/debian/tests/stretch signature.asc Description: OpenPGP digital signature
Re: debootstrap/1.0.98 breaks debomatic/0.23-1 autopkgtest in testing
Hi Luca, On 16-05-18 13:33, Luca Falavigna wrote: > 2018-05-16 10:05 GMT+02:00 Paul Gevers <elb...@debian.org>: >> The autopkgtest of debomatic in testing is apparently already broken¹ >> without the new debootstrap for reasons unclear to me. As a result it >> isn't blocking migration anymore². > > This is due to #898738. Thanks for picking this up, but why then didn't it fail with debootstrap 1.0.97¹ as the bug suggests that version had the same issue. Paul ¹ https://ci.debian.net/data/autopkgtest/testing/amd64/d/debomatic/225422/log.gz signature.asc Description: OpenPGP digital signature
Re: debootstrap/1.0.98 breaks debomatic/0.23-1 autopkgtest in testing
Hi all, On 15-05-18 15:11, Paul Gevers wrote: > tl;dr: debootstrap/1.0.98 breaks debomatic/0.23-1 autopkgtest in testing > see: https://ci.debian.net/packages/d/debomatic/testing/amd64/ The autopkgtest of debomatic in testing is apparently already broken¹ without the new debootstrap for reasons unclear to me. As a result it isn't blocking migration anymore². From ¹: Uploading hello_2.10-1_source.changes INFO: Processing /tmp/autopkgtest-lxc.gq_4yw6e/downtmp/autopkgtest_tmp/incoming/hello_2.10-1_source.changes INFO: Waiting for threads to complete... INFO: Waiting for threads to complete... ERROR: Failed creating unstable-amd64-debomatic cat: /tmp/autopkgtest-lxc.gq_4yw6e/downtmp/autopkgtest_tmp/incoming/unstable/pool/hello_2.10-1/hello_2.10-1.buildlog: No such file or directory autopkgtest [15:02:04]: test build: ---] Paul ¹ https://ci.debian.net/data/autopkgtest/testing/amd64/d/debomatic/305421/log.gz ² https://qa.debian.org/excuses.php?package=debootstrap signature.asc Description: OpenPGP digital signature
Bug#688685: installation-reports: wheezy installation successful on HP Pavilion dm1
Package: installation-reports Severity: normal Tags: d-i -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Package-specific info: Boot method: usb Image version: http://cdimage.debian.org/cdimage/wheezy_di_beta2/amd64/iso-cd/debian-wheezy-DI-b2-amd64-netinst.iso Date: 23 September 2012 Machine: HP Pavilion dm1 Partitions: paul@wollumbin:~$ df -Tl Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs14597132 4463648 9401120 33% / udev devtmpfs 10240 0 10240 0% /dev tmpfs tmpfs 283032 776282256 1% /run /dev/disk/by-uuid/1318fc21-083c-48b7-bd8f-ffe9fc917029 ext4 14597132 4463648 9401120 33% / tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 1659880 80 1659800 1% /run/shm /dev/sda5 ext4 277469084 4230668 259348216 2% /media/home Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [E] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Apart from the fact that it was not clear to me how to get the firmware for my wireless card loaded during the installation (I finally had it manually copied with a second usb to the /lib/firmware during the installion), I could not get the wireless network to start during the installation. The error was ieee80211 phy0: changing basic rates failed: -22 which happend all the time. Unfortunately I don't have the logs anymore as I finally installed without this firmware. After the installation, I could just install firmware-brcm80211, reboot, and everything was fine. As the most obvious problem was a wrongly typed wpa2 key, I check it twice, but it must have been right. - -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=7.0 (wheezy) - installer build 20120828 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux wollumbin 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS880 Host Bridge [1022:9601] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:148b] lspci -knn: 00:01.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (int gfx) [1022:9602] lspci -knn: 00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:148b] lspci -knn: Kernel driver in use: ahci lspci -knn: 00:12.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:148b] lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: 00:12.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:148b] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:13.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:148b] lspci -knn: Kernel driver in use: ohci_hcd lspci -knn: 00:13.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:148b] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller [1002:4385] (rev 41) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:148b] lspci -knn: 00:14.2 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) [1002:4383] (rev 40) lspci -knn: Subsystem:
