Re: Last chance for d-i changes in stretch
Cyril Brulebois (2017-06-03): > This looks good to me, I've uploaded it to unstable, and added a note on > my d-i checklist to make sure I don't forget about it before the next > release. Except this doesn't work except for your JBOD use case… Adding [a-z]* at the end of the pattern means we *need* an extra letter (as opposed to regex syntax which means an extra letter would have been optional). I'll switch this to restoring the earlier pattern and adding the same with an extra letter as a second pattern, and double check the results. Sorry for not catching this sooner. KiBi. signature.asc Description: Digital signature
Re: Last chance for d-i changes in stretch
Hi all, Roger Shimizu (2017-06-03): > On Fri, Jun 2, 2017 at 9:58 PM, Hideki Yamane wrote: > > > > On Tue, 30 May 2017 21:52:06 +0900 > > Roger Shimizu wrote: > > > > -/dev/[hsv]d[a-z0-9]| > > > > +/dev/[hsv]d[a-z0-9][a-z]*| > > > > > > And I pushed the fix commit to branch "fix_839894": > > > > > > https://anonscm.debian.org/cgit/d-i/grub-installer.git/commit/?h=fix_839894&id=9927e8c > > > > I've tested it with VBox and works well, see attached screenshot. > > Thanks for your verification! > > So I pushed the commit to branch master. > > > KiBi, if you're fine with it, please kindly help to release/upload. > Hope it still can catch up with r0. This looks good to me, I've uploaded it to unstable, and added a note on my d-i checklist to make sure I don't forget about it before the next release. Thanks! KiBi. signature.asc Description: Digital signature
Re: Last chance for d-i changes in stretch
On Fri, Jun 2, 2017 at 9:58 PM, Hideki Yamane wrote: > > On Tue, 30 May 2017 21:52:06 +0900 > Roger Shimizu wrote: > > > -/dev/[hsv]d[a-z0-9]| > > > +/dev/[hsv]d[a-z0-9][a-z]*| > > > > And I pushed the fix commit to branch "fix_839894": > > > > https://anonscm.debian.org/cgit/d-i/grub-installer.git/commit/?h=fix_839894&id=9927e8c > > I've tested it with VBox and works well, see attached screenshot. Thanks for your verification! So I pushed the commit to branch master. > KiBi, if you're fine with it, please kindly help to release/upload. Hope it still can catch up with r0. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Last chance for d-i changes in stretch
On Tue, May 30, 2017 at 9:38 AM, Roger Shimizu wrote: > On Tue, May 30, 2017 at 4:27 AM, Samuel Thibault wrote: > >> That would also match partitions, might that not pose concerns? Now I think the following is better: > -/dev/[hsv]d[a-z0-9]| > +/dev/[hsv]d[a-z0-9][a-z]*| And I pushed the fix commit to branch "fix_839894": https://anonscm.debian.org/cgit/d-i/grub-installer.git/commit/?h=fix_839894&id=9927e8c Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Last chance for d-i changes in stretch
On Tue, May 30, 2017 at 4:27 AM, Samuel Thibault wrote: > That would also match partitions, might that not pose concerns? So maybe the following? > -/dev/[hsv]d[a-z0-9]| > +/dev/[hsv]d[a-z0-9]|/dev/[hsv]d[a-z][a-z]*| -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: Last chance for d-i changes in stretch
Cyril Brulebois, on lun. 29 mai 2017 21:16:54 +0200, wrote: > And thanks for the ping on that topic. > > Roger Shimizu (2017-05-29): > > Maybe it's too late for r0, but I'm still want to ask whether it's feasible > > to include the patch mentioned here: > > https://bugs.debian.org/839894#30 > > > > henrich provided the patch and he verified it worked well in his virtualbox > > environment. > > I think we want to do this instead: > -/dev/[hsv]d[a-z0-9]| > +/dev/[hsv]d[a-z0-9][a-z0-9]*| That would also match partitions, might that not pose concerns? Samuel
Re: Last chance for d-i changes in stretch
Hi, And thanks for the ping on that topic. Roger Shimizu (2017-05-29): > Maybe it's too late for r0, but I'm still want to ask whether it's feasible > to include the patch mentioned here: > https://bugs.debian.org/839894#30 > > henrich provided the patch and he verified it worked well in his virtualbox > environment. I think we want to do this instead: -/dev/[hsv]d[a-z0-9]| +/dev/[hsv]d[a-z0-9][a-z0-9]*| since the proposed patch would allow hd,sd,vd by making the letter/number entirely optional, instead of mandatory once and optionally present a few other times? EIther way, this looks reasonable for r0, until we scratch this entirely in buster and rely on simpler code for this. KiBi. signature.asc Description: Digital signature
Re: Last chance for d-i changes in stretch
[ Only keep d-boot@ ML ] On Fri, 26 May 2017 19:04:13 +0200 Cyril Brulebois wrote: > Hi, > > You might have noticed final preparations for d-i Stretch RC 4 are > underways. A new debian-installer upload (or a binNMU) will need to > happen before the first stretch release (aka. r0). If there's anything > you want or would like to include in r0, now is the time to mention it. Thanks for your continous work on d-i! Maybe it's too late for r0, but I'm still want to ask whether it's feasible to include the patch mentioned here: https://bugs.debian.org/839894#30 henrich provided the patch and he verified it worked well in his virtualbox environment. If it's really too late for r0, how about stretch p-u or r1? And how? Thanks for your consideration! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpGTgPGEuj2S.pgp Description: PGP signature
Re: Last chance for d-i changes in stretch
Le samedi, 27 mai 2017, 17.17:10 h CEST Didier 'OdyX' Raboud a écrit : > win32-loader should be arch:all-rebuilt (aka uploaded) with a versionned > Build-Depends on the latest debian-archive-keyring. It would therefore > also embed the latest versions of all the other binaries its standalone > version embeds. For all packages with the same version in unstable and testing, it's not an issue (and doesn't need an explicit B-D version); it's the case for all but one of the packages win32-loader has a Built-Using value for: src:gnupg2 is currently in 2.1.18-8 version in unstable and -6 in testing. If I upload win32-loader now, it will embed gpgv-win32 2.1.18-8, no matter which gnupg2 version will be part of stretch. There are three alternatives, in decreasing order of preference: * get gnupg2 in testing, upload win32-loader to unstable, migrate it * upload win32-loader to unstable, upload it _too_ (with a different version?) in testing-proposed-updates to get rid of the version discrepancy * upload win32-loader to unstable, migrate it (and too bad for the version difference) > It also currently uses httpredir.debian.org as only mirror, so we should > decide if it makes sense to consolidate onto deb.debian.org for win32- > loader too. I've staged a change of all mirror references to deb.debian.org. The previously-discussed source compression change away from .bz2 would also be part of that upload. I'm waiting for directions regarding gnupg2 :-) Cheers, OdyX -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Last chance for d-i changes in stretch
On Sat, May 27, 2017 at 17:17:10 +0200, Didier 'OdyX' Raboud wrote: > It also currently uses httpredir.debian.org as only mirror, so we should > decide if it makes sense to consolidate onto deb.debian.org for win32- > loader too. > Yes please. Cheers, Julien
Re: Last chance for d-i changes in stretch
Cyril Brulebois writes: > Didier 'OdyX' Raboud (2017-05-27): >> It also currently uses httpredir.debian.org as only mirror, so we should >> decide if it makes sense to consolidate onto deb.debian.org for win32- >> loader too. > > Unless we're aware of limitations win32-loader might hit on deb.d.o, I'd > go for a transition to this hostname. > > Ditto for d-i-n-i, which I'll check right away. httpredir.d.o seems to be just an alias for deb.d.o these days: I see a "Welcome to deb.debian.org!" page when I open httpredir.d.o in a browser. So changing the mirror from httpredir.d.o to deb.d.o should be very low-risk :-) Ansgar
Re: Last chance for d-i changes in stretch
Cyril Brulebois (2017-05-27): > Ditto for d-i-n-i, which I'll check right away. My bad, I had the jessie branch checked out, which is missing the new mirror selection magic. KiBi. signature.asc Description: Digital signature
Re: Last chance for d-i changes in stretch
Didier 'OdyX' Raboud (2017-05-27): > win32-loader should be arch:all-rebuilt (aka uploaded) with a versionned > Build-Depends on the latest debian-archive-keyring. It would therefore > also embed the latest versions of all the other binaries its standalone > version embeds. OK. Let's do that now then? > It also currently uses httpredir.debian.org as only mirror, so we should > decide if it makes sense to consolidate onto deb.debian.org for win32- > loader too. Unless we're aware of limitations win32-loader might hit on deb.d.o, I'd go for a transition to this hostname. Ditto for d-i-n-i, which I'll check right away. KiBi. signature.asc Description: Digital signature
Re: Last chance for d-i changes in stretch
Le vendredi, 26 mai 2017, 19.04:13 h CEST Cyril Brulebois a écrit : > Hi, > > You might have noticed final preparations for d-i Stretch RC 4 are > underways. A new debian-installer upload (or a binNMU) will need to > happen before the first stretch release (aka. r0). If there's anything > you want or would like to include in r0, now is the time to mention it. > > Right now, the last upload/binNMU will be needed: > - to account for updated keys in debian-archive-keyring; > - to include pending netcfg changes (IPv6 vs. rdnssd); > - to possibly include a last choose-mirror update; win32-loader should be arch:all-rebuilt (aka uploaded) with a versionned Build-Depends on the latest debian-archive-keyring. It would therefore also embed the latest versions of all the other binaries its standalone version embeds. It also currently uses httpredir.debian.org as only mirror, so we should decide if it makes sense to consolidate onto deb.debian.org for win32- loader too. Opinions? Cheers, OdyX
Re: Last chance for d-i changes in stretch
On Fri, 2017-05-26 at 19:04 +0200, Cyril Brulebois wrote: > Hi, > > You might have noticed final preparations for d-i Stretch RC 4 are > underways. A new debian-installer upload (or a binNMU) will need to > happen before the first stretch release (aka. r0). If there's anything > you want or would like to include in r0, now is the time to mention it. [...] I want to apply the change sent as <20170423005601.gp4...@decadent.org.uk>, but still haven't found the time to test it yet. Ben. -- Ben Hutchings Experience is what causes a person to make new mistakes instead of old ones. signature.asc Description: This is a digitally signed message part
Re: Last chance for d-i changes in stretch
On 05/26/2017 09:30 PM, Cyril Brulebois wrote: >> I've looked at that for a bit, and found out that this is my own >> fault: one of the uploads of open-iscsi I did before the freeze >> changed the logic on how the initiatorname was generated within the >> installer, (due to feedback from Ubuntu people IIRC) ensuring that >> /etc/iscsi always contains files, and the check in the finish-install >> script now thinks that iSCSI is used in _all_ installations. (It >> checks for /etc/iscsi/* [1].) For this reason it regenerates the >> initramfs on all installations, which takes a couple of seconds. >> >> The effect here is totally harmless (it just unnecessarily calls >> update-initramfs -k all -u), but it might be annoying. >> >> KiBi: I suspect you don't want to change this so close to the >> release, but in case you do, I'd be happy to upload a targeted fix >> for that. > > I think it would be best to postpone considering such a fix for the > first point release, instead of aiming for r0. Let's look at this once > r0 is out, so as to avoid generating noise for the release team? I've > added an item on my d-i task list so that I don't forget about it. Sure, perfectly fine with me. If I don't open a p-u bug after the release of Stretch myself, feel free to ping me. (Btw. I also just noticed from reading the code that the additional time is not the only side-effect: it will clutter every new installation with a small file in /etc/iscsi. The file is harmless, and won't cause any problems, but I wanted to mention it so you know about it.) Regards, Christian
Re: Last chance for d-i changes in stretch
Christian Seiler (2017-05-26): > Sure, perfectly fine with me. If I don't open a p-u bug after the > release of Stretch myself, feel free to ping me. > > (Btw. I also just noticed from reading the code that the additional > time is not the only side-effect: it will clutter every new > installation with a small file in /etc/iscsi. The file is harmless, > and won't cause any problems, but I wanted to mention it so you know > about it.) Yeah, I gathered that from your first message. :) But thanks for underlining the point just in case. Feel free to start by opening up a bug report against the udeb, which I can then reference as a known bug in errata. KiBi. signature.asc Description: Digital signature
Re: Last chance for d-i changes in stretch
On 05/26/2017 07:04 PM, Cyril Brulebois wrote: > You might have noticed final preparations for d-i Stretch RC 4 are > underways. A new debian-installer upload (or a binNMU) will need to > happen before the first stretch release (aka. r0). If there's anything > you want or would like to include in r0, now is the time to mention it. While installing a Debian 9 system a couple of days ago, I noticed that at the end of the installation it took a couple of seconds for doing finalizing actions related to open-iscsi - even though the system I installed didn't use iSCSI at all. I've looked at that for a bit, and found out that this is my own fault: one of the uploads of open-iscsi I did before the freeze changed the logic on how the initiatorname was generated within the installer, (due to feedback from Ubuntu people IIRC) ensuring that /etc/iscsi always contains files, and the check in the finish-install script now thinks that iSCSI is used in _all_ installations. (It checks for /etc/iscsi/* [1].) For this reason it regenerates the initramfs on all installations, which takes a couple of seconds. The effect here is totally harmless (it just unnecessarily calls update-initramfs -k all -u), but it might be annoying. KiBi: I suspect you don't want to change this so close to the release, but in case you do, I'd be happy to upload a targeted fix for that. Regards, Christian [1] https://sources.debian.net/src/open-iscsi/2.0.874-2/debian/open-iscsi-udeb.finish-install/
Re: Last chance for d-i changes in stretch
Hi, Christian Seiler (2017-05-26): > While installing a Debian 9 system a couple of days ago, I noticed > that at the end of the installation it took a couple of seconds for > doing finalizing actions related to open-iscsi - even though the > system I installed didn't use iSCSI at all. Oh, I had been wondering a bit about this, since timing seemed to have changed a bit with my automated tests; but I ended up bumping the max delay, thinking the initial setting was borderline, instead of investigating. > I've looked at that for a bit, and found out that this is my own > fault: one of the uploads of open-iscsi I did before the freeze > changed the logic on how the initiatorname was generated within the > installer, (due to feedback from Ubuntu people IIRC) ensuring that > /etc/iscsi always contains files, and the check in the finish-install > script now thinks that iSCSI is used in _all_ installations. (It > checks for /etc/iscsi/* [1].) For this reason it regenerates the > initramfs on all installations, which takes a couple of seconds. > > The effect here is totally harmless (it just unnecessarily calls > update-initramfs -k all -u), but it might be annoying. > > KiBi: I suspect you don't want to change this so close to the > release, but in case you do, I'd be happy to upload a targeted fix > for that. I think it would be best to postpone considering such a fix for the first point release, instead of aiming for r0. Let's look at this once r0 is out, so as to avoid generating noise for the release team? I've added an item on my d-i task list so that I don't forget about it. Thanks for your input! KiBi. signature.asc Description: Digital signature