Re: Next d-i release

[Cyril Brulebois]

Philipp Kern  (2016-10-26):
> On 10/26/2016 08:24 PM, Cyril Brulebois wrote:
> > Samuel Thibault  (2016-10-23):
> >> We have the newer brltty release, 5.4, which provides support for some
> >> more devices, and fixes various issues. It has been tested for some time
> >> in experimental and sid now, so I feel quite safe about it, but it'd be
> >> probably useful to have it for testing in d-i sooner than later.
> > ACK, thanks. It migrated on its own already.
> 
> It'd also be nice if zipl-installer could still make it. #840230 is
> pretty nasty.

Yeah, I noticed already, but thanks for confirming/pointing that out:
| kibi@armor:~$ ssh respighi.debian.org head -6 hints/kibi
| # 2016-10-26
| # d-i Stretch Alpha 8
| unblock-udeb debootstrap/1.0.85
| urgent debootstrap/1.0.85
| unblock-udeb zipl-installer/0.0.35
| urgent zipl-installer/0.0.35


KiBi.


signature.asc
Description: Digital signature

Re: Next d-i release

[Philipp Kern]

On 10/26/2016 08:24 PM, Cyril Brulebois wrote:
> Samuel Thibault  (2016-10-23):
>> We have the newer brltty release, 5.4, which provides support for some
>> more devices, and fixes various issues. It has been tested for some time
>> in experimental and sid now, so I feel quite safe about it, but it'd be
>> probably useful to have it for testing in d-i sooner than later.
> ACK, thanks. It migrated on its own already.

It'd also be nice if zipl-installer could still make it. #840230 is
pretty nasty.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Next d-i release

[Cyril Brulebois]

Samuel Thibault  (2016-10-23):
> We have the newer brltty release, 5.4, which provides support for some
> more devices, and fixes various issues. It has been tested for some time
> in experimental and sid now, so I feel quite safe about it, but it'd be
> probably useful to have it for testing in d-i sooner than later.

ACK, thanks. It migrated on its own already.


KiBi.


signature.asc
Description: Digital signature

Re: Next d-i release

[Christian Seiler]

On 10/19/2016 03:33 PM, Cyril Brulebois wrote:
> Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> a new d-i release soonish. I'll probably freeze udebs in the upcoming
> hours or days, and try to figure out what to do with packages sitting
> in unstable for the time being.

It would be great if you could take a look at #750586. I provided a
patch for that issue a while back:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750586#117

Thanks!

Regards,
Christian

Re: Next d-i release

[Nicholas D Steeves]

On Wed, Oct 19, 2016 at 03:33:03PM +0200, Cyril Brulebois wrote:
> Hi,
> 
> Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> a new d-i release soonish. I'll probably freeze udebs in the upcoming
> hours or days, and try to figure out what to do with packages sitting
> in unstable for the time being.
> 
> Feel free to mention packages you want to see in testing, in case I go
> for a conservative approach (and only hand-pick a few packages); feel
> free to cc me explicitly to make sure I read your replies.
> 
> 
> KiBi.


What is my deadline for adding minimal subvolume support to
partman-btrfs?  If it needs to be done in the next 24h, my plan is to
default to creating a subvolume called @ for each btrfs volume and
silently add subvol=@ to the mount options and fstab entries for these
volumes.  With this change there is a 1-to-1-to-1
partition-to-volume-to-subvolume mapping.

I'd like to start with this, just to make sure the various bootloaders
handle it cleanly; I'm 95% certain the existing grub-install logic
will handle this change without incident, but I'm not sure about other
bootloaders on other architectures.  That might take some time to
shake out...essentially, the bootloader needs to detect that /target
is mounted with -o subvol=@ and add rootflags=subvol=@ to the kernel
command line.

What is my deadline for more complete btrfs support?  What
documentation can I consult when working on this?  I've been spending
time reading everything in partman-lvm, and partman-zfs, but I feel
like I'm going to miss the deadline at this rate.  Specifically my
plan is to:

1. Add a "Configure btrfs volumes" option underneath "Configure
   encrypted volumes":
2. Partitions that are configured to be used as "btrfs journaling
   file system" appear in this menu, just like a raid-configured
   partition appears in "configure software raid"
3. Then it offers two options "configure profile" and "configure
   subvolumes.

3.a - The following "configure profile" menu appears.
  i.   Single (similar to lvm append) data with raid1 (two copies on
   different devices) metadata
  ii.  Raid0 data with raid1 metadata
  iii. Raid1 data and raid1 metadata
  p.s. In the future, when raid5/6 stabilise they can be added as
   option.  I believe the above options strike the balance
   between what is currently most featureful and as safe as
   possible.
p.p.s. If a user wants to live dangerously, he/she can rebalance a
   live system to raid0 metadata for maximum performance, or any
   other possible btrfs profile after installation completes and
   is rebooted
  iv.  The next menu is like the "active devices for the raid1 array"

* default to creating @rootfs, and configure / on @rootfs; then mount
  -o subvolume=@rootfs /target.  In the main "Partition Disks" screen
  there will be a btrfs volume heading which displays this
  configuration.

3.b - Configure subvolume menu; this functions similarly to "Configure
  the Logical Volume Manager" menu, after an PV has been
  designated, and after a VG has been created.
  i.   When the user enters this menu, @rootfs is preconfigured and
   a list of existing subvolumes is shown.
 iii.  The only two options are create and delete subvolume
   (equivalent to LVM create LV and delete LV)

--

3.b.alt Would it be better UI design to skip the branch from 3 -> 3.a
|| 3.b inside of btrfs options, and instead write a new
"Partition disks" mode which appears under an "available btrfs
volumes".  If we use this method instead, then once a btrfs
volume's profile (equivalent to [mdadm +] pv+vg) configured in
3.a it will appear with its "btrfs volume" heading above the
physical partitioning section on the main "partition disks"
screen.  By default, the item "create subvolume" will appear
under the volume heading.  Like the "Partition Disks"
"Partition settings" it allows configuration of Name, Mount
point, but in addition to these only the Remove subvolume and
Done setting up subvolume menu options are provided.  If there
is not something configured to be mounted at /, then the first
time the "create subvolume" screen is invoked Name will be
preconfigured to @rootfs.

Because per-subvolume mount options are unsupported or poorly defined,
by default btrfs volumes will be configure with -o default in
/etc/fstab.  The 3.b or 3.b.alt configuration is what generates the
subvol=@probably_should_be_limited_to_ASCII_name. mount option used in
fstab.

So yeah, with this plan Debian Stretch's installer finally have
equivalent btrfs support to other major distributions :-)

Any advice or reference material would be very much appreciated!
Sincerely,
Nicholas


signature.asc
Description: Digital signature

Re: Next d-i release

[Samuel Thibault]

Hello,

Cyril Brulebois, on Wed 19 Oct 2016 15:33:03 +0200, wrote:
> Feel free to mention packages you want to see in testing,

We have the newer brltty release, 5.4, which provides support for some
more devices, and fixes various issues. It has been tested for some time
in experimental and sid now, so I feel quite safe about it, but it'd be
probably useful to have it for testing in d-i sooner than later.

Samuel

Re: Next d-i release

[Emilio Pozuelo Monfort]

On 20/10/16 13:25, Cyril Brulebois wrote:
> Emilio Pozuelo Monfort  (2016-10-20):
>>> Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
>>> a new d-i release soonish. I'll probably freeze udebs in the upcoming
>>> hours or days, and try to figure out what to do with packages sitting
>>> in unstable for the time being.
>>>
>>> Feel free to mention packages you want to see in testing, in case I go
>>> for a conservative approach (and only hand-pick a few packages); feel
>>> free to cc me explicitly to make sure I read your replies.
>>
>> Since the transition freeze is in a couple of weeks, I don't want to
>> hold from doing any work on that front now. I don't mind if you block
>> stuff from migrating for a few days, but I'm mentioning it since IIRC
>> you build d-i from unstable.
> 
> d-i is built within unstable, but fetches udebs from testing during its
> build; the block-udeb hints are here to control what we're fetching from
> testing during the build.

That makes a lot of sense! Then we should be good for now.

Cheers,
Emilio

Re: Next d-i release

[Cyril Brulebois]

Emilio Pozuelo Monfort  (2016-10-20):
> > Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> > a new d-i release soonish. I'll probably freeze udebs in the upcoming
> > hours or days, and try to figure out what to do with packages sitting
> > in unstable for the time being.
> > 
> > Feel free to mention packages you want to see in testing, in case I go
> > for a conservative approach (and only hand-pick a few packages); feel
> > free to cc me explicitly to make sure I read your replies.
> 
> Since the transition freeze is in a couple of weeks, I don't want to
> hold from doing any work on that front now. I don't mind if you block
> stuff from migrating for a few days, but I'm mentioning it since IIRC
> you build d-i from unstable.

d-i is built within unstable, but fetches udebs from testing during its
build; the block-udeb hints are here to control what we're fetching from
testing during the build.


KiBi.


signature.asc
Description: Digital signature

Re: Next d-i release

[Emilio Pozuelo Monfort]

On 19/10/16 15:33, Cyril Brulebois wrote:
> Hi,
> 
> Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> a new d-i release soonish. I'll probably freeze udebs in the upcoming
> hours or days, and try to figure out what to do with packages sitting
> in unstable for the time being.
> 
> Feel free to mention packages you want to see in testing, in case I go
> for a conservative approach (and only hand-pick a few packages); feel
> free to cc me explicitly to make sure I read your replies.

Since the transition freeze is in a couple of weeks, I don't want to hold from
doing any work on that front now. I don't mind if you block stuff from migrating
for a few days, but I'm mentioning it since IIRC you build d-i from unstable.

Cheers,
Emilio

Re: Next d-i release

[Steve McIntyre]

On Thu, Oct 20, 2016 at 02:05:25AM +0200, Cyril Brulebois wrote:
>Steve McIntyre  (2016-10-20):
>> >Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
>> >a new d-i release soonish. I'll probably freeze udebs in the upcoming
>> >hours or days, and try to figure out what to do with packages sitting
>> >in unstable for the time being.
>> 
>> Cool.
>
>FWIW I'll probably try not to get in the way of linux's reaching testing
>due to the security fix.

OK.

>> >Feel free to mention packages you want to see in testing, in case I go
>> >for a conservative approach (and only hand-pick a few packages); feel
>> >free to cc me explicitly to make sure I read your replies.
>> 
>> We should definitely get a newer debootstrap in before the release.
>> Nothing else really comes to mind right now.
>
>ACK. For merged-/usr support as mentioned in Ansgar's mail I suppose? Or
>do you have other things in mind?

That's the one I'm thinking of. Dunno if there's anything else queued
up, I've been buried for the last week and haven't had a chance to
look.

>> Once this release is done, I'd like to get the jessie update images
>> done. I think I'm there with the changes I need, but it needs:
>> 
>>  * a little more testing
>>  * d-i in backports
>>  * a list of packages to pull from backports
>
>Sure, but as far as I'm concerned: one step at a time…

ACK, just giving an update.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Re: Next d-i release

[Cyril Brulebois]

Steve McIntyre  (2016-10-20):
> >Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> >a new d-i release soonish. I'll probably freeze udebs in the upcoming
> >hours or days, and try to figure out what to do with packages sitting
> >in unstable for the time being.
> 
> Cool.

FWIW I'll probably try not to get in the way of linux's reaching testing
due to the security fix.

> >Feel free to mention packages you want to see in testing, in case I go
> >for a conservative approach (and only hand-pick a few packages); feel
> >free to cc me explicitly to make sure I read your replies.
> 
> We should definitely get a newer debootstrap in before the release.
> Nothing else really comes to mind right now.

ACK. For merged-/usr support as mentioned in Ansgar's mail I suppose? Or
do you have other things in mind?

> Once this release is done, I'd like to get the jessie update images
> done. I think I'm there with the changes I need, but it needs:
> 
>  * a little more testing
>  * d-i in backports
>  * a list of packages to pull from backports

Sure, but as far as I'm concerned: one step at a time…


KiBi.


signature.asc
Description: Digital signature

Re: Next d-i release

[Steve McIntyre]

On Wed, Oct 19, 2016 at 03:33:03PM +0200, Cyril Brulebois wrote:
>Hi,
>
>Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
>a new d-i release soonish. I'll probably freeze udebs in the upcoming
>hours or days, and try to figure out what to do with packages sitting
>in unstable for the time being.

Cool.

>Feel free to mention packages you want to see in testing, in case I go
>for a conservative approach (and only hand-pick a few packages); feel
>free to cc me explicitly to make sure I read your replies.

We should definitely get a newer debootstrap in before the
release. Nothing else really comes to mind right now.

Once this release is done, I'd like to get the jessie update images
done. I think I'm there with the changes I need, but it needs:

 * a little more testing
 * d-i in backports
 * a list of packages to pull from backports

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Re: Next d-i release

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):
> Hi,
> 
> Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
> a new d-i release soonish. I'll probably freeze udebs in the upcoming
> hours or days, and try to figure out what to do with packages sitting
> in unstable for the time being.
> 
> Feel free to mention packages you want to see in testing, in case I go
> for a conservative approach (and only hand-pick a few packages); feel
> free to cc me explicitly to make sure I read your replies.

The only pending changes in git (incl. l10n) are netcfg:

netcfg (1.140) unstable; urgency=medium

  [ Julien Cristau ]
  * Stop writing netmask/network/broadcast lines in /etc/network/interfaces,
just set the prefix length as part of the address (closes: #646860).


I have a ready upload if you're OK with it. It would then be the last
"bubulle automanual builder" upload until the D-I release


-- 





signature.asc
Description: PGP signature

Next d-i release

[Cyril Brulebois]

Hi,

Since linux vs. fat/efi is no longer an issue, I'm tempted to prepare
a new d-i release soonish. I'll probably freeze udebs in the upcoming
hours or days, and try to figure out what to do with packages sitting
in unstable for the time being.

Feel free to mention packages you want to see in testing, in case I go
for a conservative approach (and only hand-pick a few packages); feel
free to cc me explicitly to make sure I read your replies.


KiBi.


signature.asc
Description: Digital signature