Re: Last chance for d-i changes in stretch

2017-06-03 Thread Cyril Brulebois 
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

2017-06-03 Thread Cyril Brulebois 
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=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

2017-06-02 Thread Roger Shimizu 
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=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

Bug#839894: Last chance for d-i changes in stretch

2017-06-02 Thread Hideki Yamane 
Hi,

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=9927e8c

 I've tested it with VBox and works well, see attached screenshot.
 

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Re: [pkg-gnupg-maint] Last chance for d-i changes in stretch

2017-05-30 Thread Didier 'OdyX' Raboud 
Le mardi, 30 mai 2017, 12.56:29 h CEST Daniel Kahn Gillmor a écrit :
> I've just filed unblock request #863734, which will hopefully achieve
> this result.

Ah great. Will keep an eye and upload as soon that's granted :-)

-- 
OdyX

Re: [pkg-gnupg-maint] Last chance for d-i changes in stretch

2017-05-30 Thread Daniel Kahn Gillmor 
On Mon 2017-05-29 08:16:11 +0200, Didier 'OdyX' Raboud wrote:
> 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

I've just filed unblock request #863734, which will hopefully achieve
this result.

 --dkg


signature.asc
Description: PGP signature

Re: Last chance for d-i changes in stretch

2017-05-30 Thread Roger Shimizu 
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=9927e8c

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: Last chance for d-i changes in stretch

2017-05-29 Thread Roger Shimizu 
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

2017-05-29 Thread Samuel Thibault 
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

2017-05-29 Thread Cyril Brulebois 
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

2017-05-29 Thread Roger Shimizu 
[ 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

2017-05-29 Thread Didier 'OdyX' Raboud 
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

2017-05-28 Thread Julien Cristau 
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

2017-05-28 Thread Ansgar Burchardt 
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

2017-05-27 Thread Cyril Brulebois 
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

2017-05-27 Thread Cyril Brulebois 
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

2017-05-27 Thread Didier 'OdyX' Raboud 
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

2017-05-26 Thread Ben Hutchings 
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

2017-05-26 Thread Christian Seiler 
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

2017-05-26 Thread Cyril Brulebois 
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

2017-05-26 Thread Christian Seiler 
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

2017-05-26 Thread Cyril Brulebois 
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

Last chance for d-i changes in stretch

2017-05-26 Thread Cyril Brulebois 
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;

Independently of the debian-installer upload/binNMU, installation-guide
can also be uploaded again if there are any new changes. In which case:
sooner is better than later.

Reminder: It was confirmed in the last release team meeting that we're
again going for a full week with absolutely no changes except for
critical fixes. installation-guide doesn't qualify; and d-i should get
its last update before we enter that no-changes week.

Thanks for your attention.


KiBi.


signature.asc
Description: Digital signature