Re: Finding a tentative bullseye release date
On 18/07/2021 00:24, Donald Norwood wrote: Hi! On 7/17/21 4:58 PM, Steve McIntyre wrote: On Sat, Jul 17, 2021 at 10:25:17PM +0200, Paul Gevers wrote: Hi all, On 11-07-2021 21:11, Paul Gevers wrote: With less than three weeks to go until the tentative release date, I would love to confirm the date by now, but there is a serious issue with crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what it means for solving the debian-installer blocking issues in time), I'm not aware of other blocking issues, so let's hope the teams involved can recover in time. Albeit there is some progress, we think it better for the people involved to now say that we will *not* release on July 31. Unfortunately, that means that we have to start looking for a new date again. Assuming what we'll learn in the upcoming week or two is good, I propose to already start the list below with two weeks after the previous date. Upcoming time is around DebConf, I can imagine it could even be an advantage, especially as that's on-line, let's see. 14 August (day before DebCamp) Doable. Works for me Works for me for images team 21 August (last day of DebCamp) RT: elbrus Awkward - wife has plans for us that evening. Half of the press team is available this day so it is not ideal. Sorry - away 28 August (DebConf) RT: elbrus Debian UK BBQ, argh away at ^^ 4 September RT: elbrus Labor day weekend in the U.S. Not a good weekend. Works fine for me doable - Isy and I will be unavailable before 1300hrs UTC 11 September: RT: elbrus That's the week of my wedding anniversary, I'll be on VAC. Happy Anniversary! Works for me Could we put forth September 18th? We are good for that day without any issues. Works for me
Re: Finding a tentative bullseye release date
On Sat, Jul 17, 2021 at 10:25:17PM +0200, Paul Gevers wrote: > Hi all, > > On 11-07-2021 21:11, Paul Gevers wrote: > > With less than three weeks to go until the tentative release date, I > > would love to confirm the date by now, but there is a serious issue with > > crucial infrastructure (cdbuilder.d.o). Apart from this issue (and what > > it means for solving the debian-installer blocking issues in time), I'm > > not aware of other blocking issues, so let's hope the teams involved can > > recover in time. > > Albeit there is some progress, we think it better for the people > involved to now say that we will *not* release on July 31. > > Unfortunately, that means that we have to start looking for a new date > again. Assuming what we'll learn in the upcoming week or two is good, I > propose to already start the list below with two weeks after the > previous date. Upcoming time is around DebConf, I can imagine it could > even be an advantage, especially as that's on-line, let's see. > > 14 August (day before DebCamp) > 21 August (last day of DebCamp) > RT: elbrus > 28 August (DebConf) > RT: elbrus > 4 September > RT: elbrus > 11 September: > RT: elbrus > > Paul > Count me for the same as Sledge and Andy Simpkings as far as the 28th goes and I can't do anything without them. If we do have to postpone until Sept. it'll be a shame but, hey, it's summer and stuff happens. All best, as ever, Andy C.
Re: Finding a tentative bullseye release date
On Sat, 2021-07-17 at 22:25 +0200, Paul Gevers wrote: > 14 August (day before DebCamp) > 21 August (last day of DebCamp) > RT: elbrus These both look OK. > 28 August (DebConf) > RT: elbrus That's a holiday weekend in the UK; I'll be visiting family and then the Debian UK BBQ. > 4 September > RT: elbrus > 11 September: > RT: elbrus Either of these work for me. The 18th also does if need be (I will then be away from Monday morning (the 20th) for a few days). Regards, Adam
Re: Finding a tentative bullseye release date
On 16197 March 1977, Paul Gevers wrote: 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. I am away from 7th to 21st August (including both), at a place with very bad internet, so those are out for me. 14 August (day before DebCamp) 21 August (last day of DebCamp) RT: elbrus Not me. 28 August (DebConf) RT: elbrus 4 September RT: elbrus 11 September: RT: elbrus Can do all three. -- bye, Joerg signature.asc Description: PGP signature
Bug#991177: libdebian-installer: reproducible builds: Embeds build path in libdebian-installer-extra.so.*
On 2021-07-16, Cyril Brulebois wrote: > Vagrant Cascadian (2021-07-16): >> The build path is embedded in various places in >> libdebian-installer-extra.so.*: >> >> >> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libdebian-installer.html >> >> ./usr/lib/x86_64-linux-gnu/libdebian-installer-extra.so.4.0.8 >> >> /build/1st/libdebian-installer-0.121/build/src/../../src/list.c:30 >> vs. >> /build/2/libdebian-installer-0.121/2nd/build/src/../../src/list.c:30 >> >> The attached patch fixes this by passing -ffile-prefix-map to CFLAGS in >> debian/rules. >> >> Alternately, with recent versions of dpkg, using dpkg-buildflags to set >> CFLAGS should pass this option by default. >> >> >> Thanks for maintaining libdebian-installer! > > I know we haven't always been stellar when it comes to merging repro > build work, sorry about that. Any chance you could chase^Wremind us > about such issues once Bullseye (r0, and maybe r1) is out the door? Sure, will gently nudge sometime early in the bookworm development cycle... live well, vagrant signature.asc Description: PGP signature
Bug#991262: Missing mdio network module on armhf ASPEED AST2600 system
Package: installation-reports Severity: important Boot method: network Image version: https://d-i.debian.org/daily-images/armhf/daily/device-tree/ 20210719-00:04:35 Date: 2021-07-19 Machine: ASPEED AST2600 EVB Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [ ] Detect media: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: The installer was prepared by creating a FIT to boot from u-boot: mkimage -f auto -A arm -O linux -T kernel -C none \ -a 0x8000 -e 0x8000 -d vmlinuz \ -b aspeed-ast2600-evb.dtb -i initrd.gz \ debian-installer And then tftp booted from the vendor u-boot, using a serial console. The installer starts fine but fails when detecting network. The system uses the ftgmac100 network device, and requires the aspeed_mdio module to be present too. The mdio module is not included in the installer so network detection fails. In the past this could be worked around by booting with an upstream kernel with all the required drivers built in, however now d-i will fail the install when it cannot find the kernel version in the apt archives. Being able to override this behaviour would be useful for installing on systems that don't yet have full kernel support in the Debian archive.
