Bug#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

[Raphael Hertzog]

On Wed, 14 Feb 2024, Raphael Hertzog wrote:
> i.e. is the the file-loss triggered only by the bad path in the
> dpkg-divert call or is it triggered by the upgrade of dpkg between
> both dpkg-divert calls?
> 
> I thought it was the latter... and that would explain why OpenQA is not
> affected, it likely generates images against the release that it is
> testing.

I have confirmed this. The bad path is not problematic in itself,
dpkg-divert will move the file away and put it back as expected.

I believe it's because dpkg is removing /sbin/start-stop-daemon in favor
of /usr/sbin/start-stop-daemon that we are losing the diverted .REAL file.

Even though this file loss scenario is rare because you need to have
two specific dpkg version in bootstrap-base and pkgsel, it's still worth
fixing because the ineffective diversions means that any dpkg
upgrade in pkgsel will happily overwrite d-i's version of start-stop-daemon
and thus we might start seeing daemons running in the debian-installer
environment.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

[Raphael Hertzog]

(Adding Colin as one of the debian-installer-utils comaintainers)

Hi,

On Tue, 13 Feb 2024, Helmut Grohne wrote:
> I also see that https://openqa.debian.net/ has recent successes. dpkg
> migrated to trixie about two weeks ago. I would have expected that this
> breaks an d-i. Do you have an explanation for why jobs still pass?

FTR, in the Kali bug the case is really special:
1/ a dpkg with /sbin/start-stop-daemon is installed by debootstrap
   (bootstrap-base step)
2/ a dpkg with /usr/sbin/start-stop-daemon is installed (upgraded)
   during the pkgsel step

Could it be possible that if you have the same dpkg version in the
image and in the network repository, then you would not be bitten by
the bug?

i.e. is the the file-loss triggered only by the bad path in the
dpkg-divert call or is it triggered by the upgrade of dpkg between
both dpkg-divert calls?

I thought it was the latter... and that would explain why OpenQA is not
affected, it likely generates images against the release that it is
testing.

> Raphael, can you link this bug to the Kali bug?

Done.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Time to drop win32-loader ?

[Raphael Hertzog]

Hello,

On Tue, 19 Jul 2022, Didier 'OdyX' Raboud wrote:
> I haven't checked (as I don't have access to Windows machines...), but I'm 
> quite confident that the Windows Bootloader fiddling is quite unlikely to 
> work 
> on modern (Secure Boot ?) machines.

I think I had read some report that it was indeed not working... it was in
the context of Kali but there are no specific changes that might justify
that the breakage would be specific to Kali.

It's also one part of the ISO that still contains Debian references
by default and where it's not trivial to replace it (it's embedded in
the executable IIRC).

> That brings two sides of the question:
> * should it still be shipped on amd64 netinsts, CD's, other images?
> * should it still be offered on the mirrors ?
>   on https://deb.debian.org/debian/tools/win32-loader/stable/
>   (where it lands via dak's byhand handling upon uploads; but is manually 
>   moved by ftp-master on migrations and release days)

I think it was a cool feature (even though I never used it myself) but if
we don't have the manpower to maintain it properly, we'd better ditch it.

Also with EFI, the setup screens tend to be more graphical and more user
friendly, and the benefit of the "Boot from Windows" feature is more
limited IMO.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0

[Raphael Hertzog]

Control: tags -1 + patch
Control: user de...@kali.org
Control: usertags -1 + kali-patch

On Sun, 17 Jul 2022 05:50:20 +0200 Cyril Brulebois  wrote:
> I suppose the journal bits could be patched out for the udeb build (right
> now, configure ends up defining SYSTEMD_JOURNAL_SUPPORT to 1 there), but
> I'm not sure what consequences disabling APP_MACHINEID_SUPPORT in the udeb
> could have for arrays built at installation time (the function call itself
> is already guarded within an #ifdef/#endif block, so it seems somewhat
> optional already).

I confirm that a build with this patch gets rid of the libsystemd0
dependency in the udeb:

diff --git a/debian/rules b/debian/rules
index f1a9df9bd..bef9b2df3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -71,6 +71,8 @@ define CONFARGS.udeb
--with-pool=none
--disable-readline
--disable-selinux
+   --disable-app-machineid
+   --disable-systemd-journal
 endef
 
 BUILDS :=

I looked up the impact of --disable-app-machineid and I concluded that it
should be safe to use it even if the non-udeb build has it enabled.

The option only adds a supplementary source (named "appmachineid") for lvm
to get a "system_id". The DEFAULT_SYSTEM_ID_SOURCE is "none" and it's not
overriden by what we ship as Debian configuration files. Given that it was
non-existent up-to-now, we can be pretty sure that d-i is not overriding
the lvm configuration to set global/system_id_source to "appmachineid".

man lvmsystemid has some explanation about the feature related to
"systemid" and from a quick check on my system, it looks like that
VG created by d-i do not set any system id.

Bastian, do you agree with the above assessment? If yes, can you upload
a fixed package please?

Cheers,
-- 
Raphaël Hertzog

Bug#985696: debian-installer: Speech synthesis and Intel SOF firmware

[Raphael Hertzog]

On Mon, 22 Mar 2021, Samuel Thibault wrote:
> Hello,
> 
> Arnaud Rebillout, le lun. 22 mars 2021 17:30:30 +0700, a ecrit:
> > some recent Intel sound cards require a firmware to work.
> 
> Ah. So these should be getting supported by the firmware-enabled image
> of Debian:
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/

I don't think so. This was initially reproduced in Kali and our image
is firmware-enabled in the same way AFAIK.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#984846: netcfg: Default hostname hardcoded in netcfg-common

[Raphael Hertzog]

Hi,

Le mardi 09 mars 2021, Cyril Brulebois a écrit :
> My first reaction was “we could make that configurable on a per-vendor
> fashion” (e.g. via debian/rules) but reading you are already patching
> debian/netcfg-common.templates, why aren't you patching the two harcoded
> locations in the first place?

We are patching it because there's no other clean way to change the
default hostname for a derivative, see #719101 for another kali report
related to this.

But it would be really nice if we didn't have to patch any this udeb
(even though it's really not hardwork).

Le mardi 09 mars 2021, Arnaud Rebillout a écrit :
> It would be nice if instead it would default to the value that is set in
> 'netcfg/get_hostname'. However I'm nost sure how to achieve that, as
> I'm not familiar with the netcfg code at all, and it's not clear if we
> can still get this value at this moment in the code, or if it has been
> overwritten by the user's input.

Actually in #719101 I suggested to use a dedicated debconf variable to
control the default value... that value could be used in both places.

Cheers,
-- 
Raphaël Hertzog

Re: pkgsel: ok for new upload to unstable?

[Raphael Hertzog]

Hi,

On Tue, 28 Jan 2020, Holger Wansing wrote:
> Hi Raphael,
> 
> I would like to upload pkgsel to unstable soon.
> 
> There are commits where you were involved:
> 
>   * Ensure tasksel is installed 
>   * Add preseedable pkgsel/run_tasksel debconf template
> 
> Any objections on me uploading this?

No objections, no. Go ahead.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Avoiding low-memory warning in preseed mode

[Raphael Hertzog]

On Tue, 01 Oct 2019, Fred Boiteux wrote:
> console. I've digged on Internet, and tried following preseed paragraph,
> without success :
> 
> d-i lowmem/low note
> 
> Does someone can tell me which sentence is supposed to be used in preseed
> file to skip this manual validation ?

Where did you put that preseed entry? Did you try to put it on the kernel
command line?

I guess the preseed file downloaded from the net or embedded in the boot
media is loaded too late. (You would need to put that in the preseed file
embedded in the initrd if you really want to put it in a file and not in
the kernel command line)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Installer image for HP mv2120 fails to build with Linux 5.2

[Raphael Hertzog]

Hello,

FYI in Kali we tried to build the installer images with Linux 5.2 but the
build fails on armel due to the image for HP Media Vault mv2120 going
over some limit:

> # Set machine id 1693 (0x069d)
> devio > ./tmp/orion5x_network-console/mv2120/kernel 'wl 0xe3a01c06,4' 'wl 
> 0xe381109d,4'
> cat ./tmp/orion5x_network-console/vmlinuz-5.2.0-kali2-marvell >>
> ./tmp/orion5x_network-console/mv2120/kernel
> mkimage -A arm -O linux -T kernel -C none -e 0x0160 -a 0x0160 -n 
> "Debian kernel" -d
> ./tmp/orion5x_network-console/mv2120/kernel 
> ./tmp/orion5x_network-console/mv2120/kernel.uboot
> Image Name:   Debian kernel
> Created:  Tue Aug 20 07:44:47 2019
> Image Type:   ARM Linux Kernel Image (uncompressed)
> Data Size:2158416 Bytes = 2107.83 KiB = 2.06 MiB
> Load Address: 0160
> Entry Point:  0160
> util/pad ./tmp/orion5x_network-console/mv2120/kernel.uboot 2097152 # 2 MB
> File size 2158480 is larger than total, padded size 2097152.
> make[7]: *** [config/armel/orion5x/network-console.cfg:75: mv2120] Error 1
> make[6]: *** [Makefile:298: _build] Error 2
> make[5]: *** [Makefile:194: flavour_build] Error 2
> make[4]: *** [Makefile:190: medium_build] Error 2
> make[3]: *** [Makefile:186: subarch_build] Error 2
> make[2]: *** [Makefile:182: all_build] Error 2
> make[2]: Leaving directory 
> '/<>/debian-installer-20190820+kali1/build'
> make[1]: *** [debian/rules:66: build-images] Error 2
> make[1]: Leaving directory '/<>/debian-installer-20190820+kali1'
> make: *** [debian/rules:90: install] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
> returned exit status 2

We disabled that image for the time being because we have no idea how to handle
that failure. I just wanted to give you a heads up because it most likely 
affects Debian
too...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#782287: PR updated

[Raphael Hertzog]

Hi,

On Wed, 05 Sep 2018, Christian Ehrhardt wrote:
> FYI - updated the salsa PR with a further simplification according to the
> feedback of Scott Moser.

I'm wondering if there's a way to tell d-i to also install
openvm-tools-desktop if the user opts to install a graphical desktop
afterwards...

Otherwise I believe that this MR should be merged (and we should do the
same for other virtualization technologies).

I might take a stab at this...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#929322: partman-auto: Should increase size of / in multi and home recipes

[Raphael Hertzog]

Package: partman-auto
Version: 148
Severity: wishlist
Tags: patch
User: de...@kali.org
Usertags: origin-kali

The size of the root partition has not been reevaluated since 2014 but the
size of typical installations has grown in the mean time. When you install
a Debian system with many packages (such as in many live images) and when
you select a recipe with multiple partitions, you might find that / is too
small to contain all the applications/data.

We have this problem in Kali where our standard installation is about
8Gb. And nowadays a typical desktop dist-upgrade will require 2 Gb in
/var too.

Thus I'm suggesting to increase the size both of the root partition and of
the /var partition.

Please find attached a suggested patch which increases / to 12Gb in all
recipes and /var to 2.5Gb in the multi recipe.

The net result is that the multi and home recipes will not be proposed
when you have disks smaller than 18Gb roughly which sounds about right.
Anyone who wants multiple partitions on disks smaller than that should do
it manually based on their own analysis.

Let me know if you are happy with this change and I can commit it (after
the buster release I assume). This patch is in use in Kali.

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
--- a/recipes-amd64-efi/home
+++ b/recipes-amd64-efi/home
@@ -14,7 +14,7 @@ partman-auto/text/home_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-1500 6000 3 $default_filesystem
+12000 6000 3 $default_filesystem
$lvmok{ }
method{ format }
format{ }
diff --git a/recipes-amd64-efi/multi b/recipes-amd64-efi/multi
index 78639ed..3b74b0a 100644
--- a/recipes-amd64-efi/multi
+++ b/recipes-amd64-efi/multi
@@ -14,7 +14,7 @@ partman-auto/text/multi_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-2000 3500 25000 $default_filesystem
+12000 3500 25000 $default_filesystem
$lvmok{ }
method{ format }
format{ }
@@ -22,7 +22,7 @@ partman-auto/text/multi_scheme ::
$default_filesystem{ }
mountpoint{ / } .
 
-1000 1500 1 $default_filesystem
+2500 1500 1 $default_filesystem
$lvmok{ }
method{ format }
format{ }
diff --git a/recipes-armhf/home b/recipes-armhf/home
index 9362612..9a69ff2 100644
--- a/recipes-armhf/home
+++ b/recipes-armhf/home
@@ -9,7 +9,7 @@ partman-auto/text/home_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-1500 6000 2 $default_filesystem
+12000 6000 2 $default_filesystem
$lvmok{ }
$primary{ }
method{ format }
diff --git a/recipes-armhf/multi b/recipes-armhf/multi
index 690676a..9f58371 100644
--- a/recipes-armhf/multi
+++ b/recipes-armhf/multi
@@ -9,7 +9,7 @@ partman-auto/text/multi_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-2000 3500 25000 $default_filesystem
+12000 3500 25000 $default_filesystem
$lvmok{ }
$primary{ }
method{ format }
@@ -18,7 +18,7 @@ partman-auto/text/multi_scheme ::
$default_filesystem{ }
mountpoint{ / } .
 
-1000 1500 1 $default_filesystem
+2500 1500 1 $default_filesystem
$lvmok{ }
method{ format }
format{ }
diff --git a/recipes/home b/recipes/home
index 6abd95f..2603759 100644
--- a/recipes/home
+++ b/recipes/home
@@ -13,7 +13,7 @@ partman-auto/text/home_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-1500 6000 3 $default_filesystem
+12000 6000 3 $default_filesystem
$lvmok{ }
method{ format }
format{ }
diff --git a/recipes/multi b/recipes/multi
index b7b7f55..5e2ea3c 100644
--- a/recipes/multi
+++ b/recipes/multi
@@ -13,7 +13,7 @@ partman-auto/text/multi_scheme ::
filesystem{ ext2 }
mountpoint{ /boot } .
 
-2000 3500 25000 $default_filesystem
+12000 3500 25000 $default_filesystem
$lvmok{ }
method{ format }
format{ }
@@ -21,7 +21,7 @@ partman-auto/text/multi_scheme ::
$default_filesystem{ }
mountpoint{ / } .
 
-1000 1500 1 $default_filesystem
+2500 1500 1 $default_filesystem
$lvmok{ }
method{ format }
format{ }

Re: Permission to join

[Raphael Hertzog]

On Thu, 17 Jan 2019, Jonathan Carter wrote:
> I would like to help maintain live-installer
> (https://salsa.debian.org/installer-team/live-installer) and fix some
> issues that affect me (initially, make some things that hard hard-coded
> configurable).
> 
> Raphael and Christian, are you ok that I add myself to uploader of
> live-installer?

Fine for me. As long as you don't break what's working ;-)

OOC, what do you want to make configurable?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: tracker.d.o integration?

[Raphael Hertzog]

Hi,

On Sat, 15 Dec 2018, Holger Wansing wrote:
> would it make sense to add a d-i team to 
> tracker.debian.org/teams?

Certainly. And it should be easy to setup since you can use
debian-boot@l.d.o as maintainer email to automatically add all the
relevant packages.

> And let Salsa sent commit or push (?) notices there?

FWIW you don't send commit notices to a team. You send them to
dispatch@tracker.d.o and the package tracker forwards the
mails to all subscribers for the given package (either direct subscribers
or people subscribed through the team).

FTR, devscripts now has a "salsa" tool that lets you easily configure the
required integrations to send the commit notices and IRC bot, etc.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#893713: debootstrap-udeb: containts too many scripts files (most of them are symlink but...)

[Raphael Hertzog]

Hello Hideki,

On Sat, 25 Aug 2018, Hideki Yamane wrote:
> > So you saved a few kilobytes and made the life harder for others.
> > IMO it was the wrong decision.
> 
>  It was my mistake, of course, but I DON'T WANT TO MAKE SOMEONE'S LIFE
>  ANY HARDER, IT IS NOT INTENDED. People who made wrong decision should
>  be blamed as fool? If so, please revert debootstrap before I started 
>  to commit to it.

Sorry if you found my message a bit rude, I appreciate the work you are
doing and I even encouraged you to try it out because clearly nobody
was assuming the task. But honestly there have been way too many uploads
with regressions, you should spend more time thinking about the
consequences of each change and you should really add some automated test
to catch the regressions.

I understand the "release early, release often" mantra, but here we are
speaking of an important tool that we really to keep working at any time.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#893713: debootstrap-udeb: containts too many scripts files (most of them are symlink but...)

[Raphael Hertzog]

Hi,

On Tue, 21 Aug 2018, Cyril Brulebois wrote:
> Right. Feel free to fix/revert this at your earliest convenience.

Did this in 1b4bb92db9812db76c71ee8743f232d0d2d8f8b2.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#893713: debootstrap-udeb: containts too many scripts files (most of them are symlink but...)

[Raphael Hertzog]

Hi,

On Fri, 23 Mar 2018, Hideki Yamane wrote:
>  It's not a problem, but we can improve it, IMO (so severity is low).

So you tried to fix a non-problem... and while doing so you introduced
a real problem.

While cleaning up the list of scripts to keep, you decided to drop the
scripts for all derivatives making it impossible to use the udeb built
for Debian on any derivative (Kali bug report here:
https://bugs.kali.org/view.php?id=4921)

So you saved a few kilobytes and made the life harder for others.
IMO it was the wrong decision.

The other bug that you fixed at the same time asked to add more scripts,
it did not ask to remove any.

If you really want to do anything at this level, you should just have
a list of obsolete release and automatically drop the corresponding
scripts. But IMO this is not worth the effort. We should just keep all
scripts.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hi,

On Wed, 27 Jun 2018, Justin B Rye wrote:
> _Description: Updates management on this system:
>  Applying updates on a frequent basis is an important part of keeping the
>  system secure.
>  .
>  By default, security updates are not automatically installed, as security
>  advisories should be reviewed before manual installation of the updates
>  using standard package management tools.
>  .
>  Alternatively the unattended-upgrades package can be installed, which will
>  install security updates automatically. Note however that automatic
>  installation of updates may occasionally cause unexpected downtime of
>  services provided by this machine in the rare cases where the update is
>  not fully backward-compatible, or where the security advisory requires the
>  administrator to perform some other manual operation.

Thanks for the review. I updated the string in git. I will not upload the
package right away, maybe later once translators had a chance to catchup
(or maybe someone else will decide to upload before me).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hi,

On Tue, 26 Jun 2018, Wouter Verhelst wrote:
> I think it makes sense to explain in a bit more detail why that may not
> be a good idea:

Ok.

On Tue, 26 Jun 2018, Cyril Brulebois wrote:
> I think it really should get reviewed through the usual channel
> (debian-l10n-english@ if memory serves, but don't trust me on this), so
> that we avoid common errors.

Ok.

I'm ccing debian-l10n-engl...@lists.debian.org to have their review.
Here's the updated string that I'm now proposing based on the early
feedback:

_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are not automatically installed as security
 advisories should be reviewed before installation of the updates using
 standard package management tools.
 .
 Alternatively the unattended-upgrades package can be installed, it will
 install security updates automatically. Note however that automatic
 installation of updates may occasionally cause unexpected downtime of
 services provided by this machine in the rare cases where the update is
 not fully backwards compatible or when the security advisory requires the
 administrator to perform some other manual operation.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hello,

On Mon, 28 May 2018, Cyril Brulebois wrote:
> debian-boot@: the requested revert looks fine to me, bonus points if it
> comes with a (short) summary of these reasons in changelog, so that they
> can be emphasized in the release announcement. :)

I reverted the change in git:
https://salsa.debian.org/installer-team/pkgsel/commit/2b9b594855a409fa6d03f259ccca4b1a1bd4727b

I haven't uploaded the package yet. I had to reword the debconf template.
Is the modified template fine?

_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are not automatically installed as you
 have to review the security advisories before installing the updates
 using standard package management tools. Alternatively you can install
 the unattended-upgrades package which will install security updates
 automatically.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Processed: Bug #551838 in debootstrap marked as pending

[Raphael Hertzog]

Control: tag -1 - pending
Control: tag -1 + patch

Please stop marking bugs as pending as long as they are not merged. The
existence of a merge request is similar to the existence of a patch, it
does not mean that the it has been applied to the git repository.

I told you so twice now, please pay attention to this.


On Mon, 04 Jun 2018, Hideki Yamane wrote:
>  I've prepared MergeRequest as
>  https://salsa.debian.org/installer-team/debootstrap/merge_requests/8

I left some comments. That said I'm not very familiar with --make-tarball
and --unpack-tarball and I'm not sure if your changes are sane. In
particular, I would have expected to not have to modify all scripts

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Enabled tracker.debian.org integration and tag_pending webhook

[Raphael Hertzog]

Hello,

I just enabled two things for all our repositories:

- "Emails on push" integration with tracker.debian.org so that
  one can receive git commit notifications through the vcs keyword
  with usual package subscription on the package tracker

- the "tagpending" webhook which marks bugs as "pending" when you
  push/merge commits that contain "Closes: #xxx" in their description

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#742672: allow debootstrap to take a bare codename as the script parameter

[Raphael Hertzog]

Control: tags -1 = patch

On Sun, 27 May 2018, Hideki Yamane wrote:
> control: tags -1 +pending

Please don't mark the bug as pending when you submit a merge request. It
means that the bug has a patch but not that the fix has been committed to
git.

BTW, I enabled a webhook that will do this automatically when commits
are pushed to master and when they contain a "Closes: #xxx" in the commit
message.

>  I've created Merge Request as 
>  https://salsa.debian.org/installer-team/debootstrap/merge_requests/2
> 
>  Please someone review it.

Done. It's not the same as suggested in the bug.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#839046: [PATCH] Enable merged-/usr by default again now that dpkg-shlibdeps is fixed (Closes: #839046)

[Raphael Hertzog]

Hi,

On Sun, 27 May 2018, Hideki Yamane wrote:
> On Tue, 22 May 2018 16:21:01 +0200
> Raphael Hertzog <hert...@debian.org> wrote:
> > I don't understand your question. The required fixes are in the version of
> > dpkg that is in stretch.
> 
>  I mean, if we try to create new stretch chroot with merged-usr,
>  it becomes to be NOT equal to stretch environment since its /lib*,
>  /bin and /sbin are merged to /usr. We should not apply it for pre-buster,
>  IMHO.

The same will hold true even for buster+1 given that stretch will
still be supported at that time.

If anything your argument would mean that we should have different default
for the --merged-usr flag for different release. This might indeed be
important if we want to make sure that recent debootstrap do not introduce
unexpected problems when building chroot for very old releases.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#839046: [PATCH] Enable merged-/usr by default again now that dpkg-shlibdeps is fixed (Closes: #839046)

[Raphael Hertzog]

On Sat, 19 May 2018, Hideki Yamane wrote:
> On Thu, 17 May 2018 11:37:32 +0200
> Laurent Bigonville  wrote:
> > +  * Enable merged-/usr by default again now that dpkg-shlibdeps is fixed
> 
>  Is it applied to from buster to sid?
>  It maybe break the enviroment until stretch release.

I don't understand your question. The required fixes are in the version of
dpkg that is in stretch.

See #843073 for details (fixes applied in dpkg 1.18.17).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: debootstrap: [idea] force review before commit to master

[Raphael Hertzog]

Hi,

On Wed, 16 May 2018, Philipp Kern wrote:
> I think what would be useful is coming up with a bunch of test cases and
> adding them to Gitlab's CI feature.

We have a few tests (probably need to be expanded) in debian/tests/ and
they should be hooked with Gitlab CI, yes.

> Personally I think that for changes you are not sure about, you propose the
> merge request and assign it to a reviewer. This might or might not require
> some liberal adding of reviewers to the project, though. I know Debian
> doesn't usually roll on code reviews, but of course I don't disagree that
> they would be useful. But I don't think the solution is "allow to push" ->
> "no one". Gitlab doesn't stop you from doing the reviews anyway even if
> that's not set.

Agreed, we should not forbid direct push (we have plenty of trivial
changes that don't require any merge request). But we should encourage the
use of reviews for new features or significant changes or changes where
one is unsure.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#690210: debootstrap : debian-ports support

[Raphael Hertzog]

Hi,

On Sat, 28 Apr 2018, jhcha54008 wrote:
> I am afraid debootstrap already depends on perl (it
> doesn't show up in the control file as perl-base
> is Essential) : it ships a perl function 'pkg_details'
> inline (see file /usr/share/debootstrap/functions line 1323
> in debootstrap version 1.0.97)

Ok, I missed this. Still I'm pretty sure that it's not a good
trend to continue.

> Should the perl code depends on libdpkg-perl or is it bearable
> to inline the needed functions ? The former avoids code duplication
> with benefits in size and maintainability, the latter keeps the
> dependencies to a minimum (wget, perl-base).
> 
> As far as I know, there are three main use cases of debootstrap :
> 1. create a debian chroot on a host running debian (or similar)
> 2. in debian-installer (base-installer step)
> 3. "to install Debian GNU/Linux from a Unix/Linux system"
> (https://www.debian.org/releases/stable/amd64/apds03.html.en)
> 
> Depending on libdpkg-perl is beneficial to the first use case,
> and inlining the functions to the third.

A dependency on libdpkg-perl is not a good idea either. This is why I'm
really questioning the need to for this code to be inside debootstrap
at all.

> > IMO the special casing for ports.debian.org architectures should be
> > handled in a dedicated wrapper. And maybe debootstrap needs new features
> > to make this wrapper possible.
> 
> May I ask what for new features you have in mind ?

Possibly passing a pre-built "Packages" file directly. It would be the
result of the merge that you are doing between UNRELEASED and the normal
suite.

> Is the hope of a debian-ports support in debootstrap still
> (not too un)reasonable ?

Why aren't you creating a proper suite merging the required bits on the
server side in ports.debian.org?

Maybe the tools you are using do not make it easy to implement but it's really
something that is not hard with most of the tools (e.g. reprepro).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#840372: debootstrap: second-stage fails within systemd-nspawn: proc already mounted

[Raphael Hertzog]

On Tue, 24 Apr 2018, Hideki Yamane wrote:
> On Mon, 23 Apr 2018 15:59:31 +0200
> Raphael Hertzog <hert...@debian.org> wrote:
> > I'm saying this because the following lines are left untouched and are
> > called in all cases:
> > umount_on_exit /proc
> > umount_on_exit /proc/bus/usb
> > 
> > (They are in the context of your unified diff)
> > 
> > They should only be called if debootstrap is mounting /proc by itself.
> 
>  Okay, I want to treat it as separate issue (this code is not touched
>  until now), deal with it after next upload.

I don't think that it makes sense to fix one problem to introduce another
one at the same place. debootstrap was broken because the wrapper did
already mount /proc. Now the wrapper will be broken because debootstrap
has already umounted /proc and the wrapper will fail to be able to umount
it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#896071: debootstrap fails to retrive Release file over https

[Raphael Hertzog]

On Mon, 23 Apr 2018, Hideki Yamane wrote:
> Hi,
> 
> On Sun, 22 Apr 2018 09:40:54 +1000
> David Margerison  wrote:
> > >  "$@" is extracted as '' and wget tries to fetch it and fails,
> > >  then returns 1.
> > 
> > Regarding the proposed fix, in general using $@ without quotes is fragile.
> 
>  Most of the case, quotes is better. But in this case, "$@" is extracted like
> >> wget '' '' '' https://deb.debian.org/debian/dist/unstable/InRelease
>  Then, it outputs
> >>http://: Invalid host name.
> >>http://: Invalid host name.
> >>http://: Invalid host name.
>  and returns 1.

I agree with David that using $@ without quotes is not a good idea.
What you want is to not pass empty arguments to wgetprogress. So you should
likely drop the quotes around the first 3 parameters on this line:
if wgetprogress "$CHECKCERTIF" "$CERTIFICATE" "$PRIVATEKEY" -O 
"$dest" "$from"; then

I'm suggesting only the first 3 since those are the variables that can be
empty. And we want to keep the quote on "$dest" to be able to use path
containing spaces (which you likely lost with your fix).

But even here it's not perfect since we loose the possibility to handle
arguments containing spaces in the first 3 parameters. A complete fix would
involve setting up the argument list manually:

set -- -O "$dest" "$from"
if [ -n "$PRIVATEKEY" ]; then
set -- "$PRIVATEKEY" "$@"
fi
if [ -n "$CERTIFICATE" ]; then
set -- "$CERTIFICATE" "$@"
fi
if [ -n "$CHECKCERTIF" ]; then
set -- "$CHECKCERTIF" "$@"
fi
if wgetprogress "$@"; then
[...]

Here we should be safe even if those 3 variables do contain spaces.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#896071: debootstrap fails to retrive Release file over https

[Raphael Hertzog]

Hi,

On Tue, 24 Apr 2018, Hideki Yamane wrote:
>  I'll revert below your commit since this regression fix also solve it.
> 
> > commit c1c20ed48e83fe9d4f3512c524f7734d4e1469ac
> > Author: Raphaël Hertzog 
> > Date:   Thu Apr 12 12:18:29 2018 +0200
> > 
> > Do not use HTTPS for Kali bootstrap script
> 
>  Please let me know if you don't want it.

Honestly, I'd prefer not to diverge from Debian and use plain http as well
so that we limit the risk of regression related to https support.

In particular since our main http.kali.org host redirects to many other
mirrors whose certificates are not under our control. We are not monitoring
that all the certificates are valid.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#840372: debootstrap: second-stage fails within systemd-nspawn: proc already mounted

[Raphael Hertzog]

On Mon, 23 Apr 2018, Hideki Yamane wrote:
> On Thu, 19 Apr 2018 10:06:49 +0200
> Raphael Hertzog <hert...@debian.org> wrote:
> > Your patch will try to umount /proc even if it has not been mounted by
> > debootstrap. That's wrong. If you detect that /proc was handled outside of
> > debootstrap, then you should also not umount it.
> 
> +   if [ ! -n "$(ls -A /proc)" ]; then
> +   in_target mount -t proc proc /proc
> 
>  is when there's no file under /proc, then try to mount /proc - not try
>  to umount it.

I'm saying this because the following lines are left untouched and are
called in all cases:
umount_on_exit /proc
umount_on_exit /proc/bus/usb

(They are in the context of your unified diff)

They should only be called if debootstrap is mounting /proc by itself.

> > And the handling of /sys should be entirely separate from /proc. Even if
> > /proc was already mounted, you want debootstrap to ensure that /sys is
> > mounted too.
> 
>  Okay, it should be that.

Yes, if and only if multiple mounts on /sys do not cause the same problem than 
multiple
mounts on /proc. Otherwise you want to protect the mount call with a check 
ensuring that
/sys is not yet mounted.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#690210: Bug 690210 : debootstrap : debian-ports support

[Raphael Hertzog]

On Wed, 18 Apr 2018, Hideki Yamane wrote:
> control: tags -1 +pending

It's not "pending" because it's not yet pushed to the official git
repository. I don't know if you just forgot to push or if willingly kept
it out for now...

But please can you avoid committing intrusive changes before seeking
reviews ?

I know that I encouraged you to work on debootstrap but now I feel
responsible to double check all your work because I found out (an
non-negligible rate) of simple mistakes and discutable design decisions
in what you submitted so far.

>  Adjust it to current git code, could you check it, please?

I feel really uncomfortable with this patch. It's really intrusive
and adds tons of perl code in a codebase that was not depending
on perl. The comment even suggests that we would need an alternative
C implementation in case perl is not available (and that C implementation
is not provided here). And the perl code is actually duplicating
code from libdpkg-perl.

IMO the special casing for ports.debian.org architectures should be
handled in a dedicated wrapper. And maybe debootstrap needs new features
to make this wrapper possible.

But I ask you to not commit this unless you get other reviews explaining
that this change is OK despite the above comments.

Alternatively, some sort of middle ground would be to provide a script
dedicated to stuff hosted ports.debian.org, the main script would be
unmodified and the hackish code would be hidden in a script that the user
would have to request explicitly.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#840372: debootstrap: second-stage fails within systemd-nspawn: proc already mounted

[Raphael Hertzog]

On Tue, 17 Apr 2018, Hideki Yamane wrote:
> > So it looks like systemd-nspawn already took care of mounting /proc and
> > debootstrap fails when trying to do the same? Maybe debootstrap could
> > just skip mounting /proc if this mount is already present?
> 
>  Here's a proposed patch.

Your patch will try to umount /proc even if it has not been mounted by
debootstrap. That's wrong. If you detect that /proc was handled outside of
debootstrap, then you should also not umount it.

And the handling of /sys should be entirely separate from /proc. Even if
/proc was already mounted, you want debootstrap to ensure that /sys is
mounted too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#741964: debootstrap: --variant=fakechroot and --foreign

[Raphael Hertzog]

Hello Hideki,

it seems to me that you should test and review your commits more often.

On Tue, 17 Apr 2018, Hideki Yamane wrote:
> -   if doing_variant fakechroot; then
> -   setup_proc_fakechroot
> -   else
> +   if doing_variant ! fakechroot; then

This is not doing what you want. You probably want:
  if ! doing_variant fakechroot; then

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: debootstrap and using /var/cache/apt/archives as --cache-dir

[Raphael Hertzog]

On Tue, 17 Apr 2018, Hideki Yamane wrote:
> > For all those reasons, I'm really sure that it is not a good idea
> > to enable that directory as default --cache-dir.
> 
>  Thanks, 1 is rare, but 2 and 3 sound reasonable.
>  Then, can we make any directories for cache option by default?

You could create /var/cache/debootstrap for this purpose but I'm not
convinced that this is needed because if someone really cares about the
performance of debootstrap runs, it will likely already have optimized
the download of .deb files by using a package proxy or a local mirror.

And you already made it easier to reuse proxy settings from APT.

And again debootstrap is made to work with multiple Debian derivatives
so a single cache directory does not make a sensible default... my point
3 still holds even if it's /var/cache/debootstrap. In theory you want a
cache directory per "vendor" (debian, ubuntu, kali, etc.).

All in all I believe that it's not worth the effort.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

debootstrap and using /var/cache/apt/archives as --cache-dir

[Raphael Hertzog]

Hi,

moving to debian-boot as this is unrelated to this bug.

On Thu, 12 Apr 2018, Hideki Yamane wrote:
> > Drop default value for --cache-dir parameter
> > 
> > It is not at all appropriate for debootstrap to start putting files
> > in APT's cache of .deb files (it could possibly use it in a read-only
> > way, but writing to it is not desirable). Furthermore the code was not
> > working as expected, the default value was only put in place if the
> > --cache-dir option was passed and it would require an explicit value
> > anyway.
> 
>  It's not so wrong to put files under /var/cache/apt/archives, IMO.
>  Users can get benefit without any notices with --cache-dir option.
>  And I want to know the situation this doesn't work, so could you
>  give me more explanation, please?

Yes, this is a private directory used by APT. This has many implications:

1/ You will put files there but what happens if "apt-get clean" is run in
a cron job while you are running debootstrap ?

2/ APT stores files there with a naming policy of its own (for instance
it adds the epoch to the version) and you are not respecting that policy
and you can run into trouble due to this. APT is able to clean up files
it puts there, but it might not be able to clean up files put there by
others in particular when their name is not consistent with what it uses.

3/ debootstrap ought to be usable on any machine to bootstrap any
distribution, what happens if /var/cache/apt/archives contains ubuntu
packages (same name, same version, recompiled for ubuntu) and you want to
bootstrap debian and not ubuntu ? You will remove the pre-existing file
and put there a Debian package, breaking APT's cache.

For all those reasons, I'm really sure that it is not a good idea
to enable that directory as default --cache-dir.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#895466: debootstrap 1.0.96 fails due to missing apt-config

[Raphael Hertzog]

Hi,

On Wed, 11 Apr 2018, Olliver Schinagl wrote:
> While running debootstrap on a non-native debian system, debootstrap keeps
> failing with
> 
> debootstrap: line 55: apt-config: command not found

Duh... this change has even been discussed on the mailing list. I think
it's partly fixed already in git but still there's a big misunderstanding.

Hideki, when Ben Hutchings suggested to use "command -v" it means "command
-v apt-config" and not "apt-config -v".

But really the code that went into 1.0.96 is completely wrong. Basically
you tested whether "apt-config -v >/dev/null" is a non-empty string. And
yes it's a non-empty string. :-)

I pushed a proper fix to git.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: debootstrap 1.0.93+nmu5

[Raphael Hertzog]

On Tue, 03 Apr 2018, Hideki Yamane wrote:
> +if [ -e /usr/bin/apt-config ]; then

In case like this, you usually use "-x" to ensure it's also executable.

> +eval $(apt-config shell AUTOPROXY Acquire::http::ProxyAutoDetect)
> +if [ -z "$http_proxy" ] && [ -x "$AUTOPROXY" ]; then
> +http_proxy="$($AUTOPROXY)"
> +if [ -n "$http_proxy" ]; then
> +echo "Using auto-detected proxy: $http_proxy"
> +export http_proxy
> +fi
>  fi
>  fi
> -
> 

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: debootstrap 1.0.93+nmu5

[Raphael Hertzog]

On Fri, 30 Mar 2018, Hideki Yamane wrote:
> On Fri, 30 Mar 2018 14:24:27 +0200
> Raphael Hertzog <hert...@debian.org> wrote:
> > debootstrap can be run on a non-Debian system and should not assume that
> > apt-config is available. I would suggest to protect this code with
> > a check of the existence of apt-config.
> 
>  You're right. Then, how about this?
> 
> if (which apt-config > /dev/null); then

In most postinst snippets, it is used like this:

if which apt-config >/dev/null 2>&1; then

I don't see the need for a sub-shell.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: debootstrap 1.0.93+nmu5

[Raphael Hertzog]

Hi,

On Wed, 28 Mar 2018, Hideki Yamane wrote:
> From: Michael Vogt 
> Date: Thu, 19 Dec 2013 15:36:58 +0100
> Subject: [PATCH 09/13] try to auto-detect proxy if available
> 
> --- a/debootstrap
> +++ b/debootstrap
> @@ -49,6 +49,17 @@ PRIVATEKEY=""
>  DEF_MIRROR="http://deb.debian.org/debian;
>  DEF_HTTPS_MIRROR="https://deb.debian.org/debian;
>  
> +# do auto proxy discovery
> +AUTOPROXY=""
> +eval $(apt-config shell AUTOPROXY Acquire::http::ProxyAutoDetect)

debootstrap can be run on a non-Debian system and should not assume that
apt-config is available. I would suggest to protect this code with
a check of the existence of apt-config.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#866401: Please print proper error message when download fails

[Raphael Hertzog]

Hi,

On Wed, 21 Mar 2018, Hideki Yamane wrote:
> On Wed, 21 Mar 2018 18:15:06 +0900 Hideki Yamane  
> wrote:
> >  Then, how about to change it to "-nv" (no-verbose) option?
> 
>  Here's a proposed patch.

busybox's wget does not fail with this option but it also does not change
its behaviour. And we already have the verbose option to enable verbose
logging so this is really not necessary.

I think that your whole interpretation of this bug report is flawed. The bug
reporter complains of this error message:

E: Couldn't download dists/jessie/main/binary-armhf/Packages

And fixing it to include the full URL is not hard:

--- a/functions
+++ b/functions
@@ -675,7 +675,7 @@ download_release_indices () {
if get "$m/$path" "$pkgdest" $ext; then break; fi
done
if [ ! -f "$pkgdest" ]; then
-   error 1 COULDNTDL "Couldn't download %s" "$path"
+   error 1 COULDNTDL "Couldn't download %s" "$m/$path"
fi
donepkgs="$(($donepkgs + ${i#* }))"
progress $donepkgs $totalpkgs DOWNPKGS "Downloading Packages 
files"
@@ -722,7 +722,7 @@ download_debs () {
echo >>$TARGET/debootstrap/deburis "$p 
$ver $m/$fil"
echo >>$TARGET/debootstrap/debpaths "$p 
$debdest"
else
-   warning COULDNTDL "Couldn't download 
package %s (ver %s arch %s)" "$p" "$ver" "$arc"
+   warning COULDNTDL "Couldn't download 
package %s (ver %s arch %s) at %s" "$p" "$ver" "$arc" "$m/$fil"
leftover="$leftover $p"
fi
fi

I fixed another similar error message at the same time.

And this error message does not seem to be generated by debootstrap

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#861343: debootstrap: hardcodes mawk as awk provider

[Raphael Hertzog]

Hi Hideki,

On Mon, 19 Mar 2018, Hideki Yamane wrote:
>  However, in scripts/*, there's unnecessary mawk hardcode line and
>  we can remove it safely as attached patch.
[...]
> - ln -sf mawk "$TARGET/usr/bin/awk"
> + ln -sf awk "$TARGET/usr/bin/awk"

Huh? This doesn't make any sense. You are creating a symlink named "awk" that
points to itself. And you will have broken everything.

The problem is the lack of /usr/bin/awk because that file is handled by
update-alternatives which can't be run in the early steps. So it's
manually created and it needs to point to the awk alternative that
has been unpacked earlier.

At best you can try to match /usr/bin/*awk to try to guess how the
awk executable is named and use that to look up the package name
(for the x_core_install call that also hardcodes the mawk name)
and create the appropriate symlink (which will get replaced by
the update-alternatives managed one).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#798564: debootstrap: Add scripts for kali releases

[Raphael Hertzog]

Hi,

On Tue, 13 Mar 2018, Hideki Yamane wrote:
> On Sat, 24 Feb 2018 21:15:47 +0100 Raphael Hertzog <hert...@debian.org> wrote:
> > We only need kali-rolling, kali-dev and kali-last-snapshot.
> 
>  Okay, I'll update it after NMU.
>  And, is default_mirror better to use https://http.kali.org/kali,
>  not http?

Both are supported on our server side. I don't know if https is imposing
any further cost on debootstrap.

If https works fine in debootstrap, then you can use https I guess.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Clean up bug report for debootstrap

[Raphael Hertzog]

Hello Hideki,

On Sun, 25 Feb 2018, Hideki Yamane wrote:
>  What can I do for it? Who should I talk to for review?

Why not applying the patches yourself and becoming the maintainer
of debootstrap for a while? I think it doesn't have any obvious
regular maintainer and it could benefit from a bit of sustained attention
to deal with the backlog of bugs.

I'm ccing the 4 uploaders of debootstrap, maybe they can give you
more guidance.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#798564: debootstrap: Add scripts for kali releases

[Raphael Hertzog]

On Sat, 24 Feb 2018, Hideki Yamane wrote:
> On Thu, 10 Sep 2015 16:45:20 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
>  wrote:
> > I'd like debootstrap to have native support of the various kali releases.
> 
>  Patch attached, based on Bug#798562.

Thanks, but in the mean time our set of releases has evolved:
http://git.kali.org/gitweb/?p=packages/debootstrap.git;a=tree;f=scripts;h=efa42caf1253542f3b3af4731f0923fd3e420fa9;hb=refs/heads/kali/master

>  scripts/kali/kali | 9 +
>  scripts/kali/kali-current | 1 +
>  scripts/kali/kali-dev | 1 +
>  scripts/kali/kali-next| 1 +
>  scripts/kali/kali-rolling | 1 +
>  scripts/kali/moto | 1 +
>  scripts/kali/sana | 1 +

We only need kali-rolling, kali-dev and kali-last-snapshot.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#798562: debootstrap: Support "scripts" sharing code with Debian but with different default_mirror and keyring

[Raphael Hertzog]

Hi,

On Sat, 24 Feb 2018, Hideki Yamane wrote:
> On Thu, 10 Sep 2015 16:22:25 +0200 =?utf-8?q?Rapha=C3=ABl_Hertzog?= 
>  wrote:
> > It might be possible to just move the code out in some separate
> > files that can be sourced from all the "script" files?
> 
>  I've made a PoC patch for this issue
>  - relocate scripts files to each distro directroy

I think this is not a good idea. The location of the scripts file is part
of the public interface since debootstrap takes a script file
as 4th parameter.

Or maybe it's a good idea because we are going to have collisions one day
between codenames of the various distributions but then you have to keep
the current files for a little longer and you probably should consider
further changes so that we can pass "debian/sid" or "kali/kali-rolling"
as 1st parameter (suite).

But this is also not required to implement this:

>  - split code from scripts/debian/sid

This part looks fine from a cursory review.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#839046: debootstrap: enable --merged-usr by default

[Raphael Hertzog]

On Tue, 13 Feb 2018, Julien Cristau wrote:
> On 02/13/2018 04:29 PM, Raphael Hertzog wrote:
> > I believe that we have had quite some testing already last time and I
> > would be surprised if we got many more RC bugs on dpkg that had to be fixed
> > on a short timeframe. I guess nobody can give you any assurance but
> > I'm sure that you can downgrade those bugs pointing to this discussion
> > and showing that this was part of the deal.
> 
> If we break user systems we don't get to downgrade bugs on the basis
> that "we knew we were doing a half assed job with this transition".
> That's not part of the deal we're making with our users.

Granted, but RC bugs against dpkg does not translate into "break user
systems". I would be very surprised if we found out a tool using dpkg
--search that would break the system on which it is running because
it did not get an answer to a specific dpkg --search query.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#839046: debootstrap: enable --merged-usr by default

[Raphael Hertzog]

On Mon, 12 Feb 2018, Ansgar Burchardt wrote:
> Guillem Jover writes:
> > In any case, I looked the other day into implementing the
> > --map-pathname option for dpkg-query, and I've got most of the code
> > ready. The problem is that this requires adding support for config
> > files and config fragments to dpkg-query, which has the additional
> > problem of making it possible to mess with the --showformat option
> > and breaking the expectations from maintscripts, for example. The
> > other problem is with the search behavior changing depending on the
> > packages providing those mappings being installed (because dpkg would
> > certainly not provide them).
> 
> So who should provide them?  debootstrap?  base-files?

It certainly makes sense for debootstrap to create those files given it
creates the symlinks in the first place.

An alternative solution could be to reuse the usrmerge package and let
debootstrap install this package if it exists. That way the usrmerge
package would exist until Debian switched entirely to put everything into
/usr/bin.

> The correct long-term fix is probably for packages to eventually install
> to the location in /usr anyway.  That doesn't work without some
> transition period of 1-2 releases though.

Ack.

On Mon, 12 Feb 2018, Guillem Jover wrote about usrmerge:
> This seems like a nice PoV for people to play with it, in the same way
> local admins can use, to some extent, symlinks to redirect subtrees to
> other mount points, but I don't see how this can be seen as a
> production-ready solution shipped by default, TBH.

Note that the change in debootstrap does not install usrmerge currently.
It only creates the required symlinks.


But this is enough to confuse "dpkg -S". This used to break dpkg-shlibdeps
and was the main reason for the initial revert. Fortunately dpkg-shlibdeps has
been fixed to try multiple paths until it can find the package owning the
library.


It might be that we will find other tools confused by "dpkg -S" non-answer
on some /lib/* or /usr/lib/* paths and some end users will definitely be 
surprised by
this.

Obviously we can document the problem in release notes but it would be
better to have a clean solution like suggested by Guillem:

> In any case, I looked the other day into implementing the
> --map-pathname option for dpkg-query, and I've got most of the code
> ready.

If this is forthcoming in the buster timeframe, it seems reasonable to
go ahead and re-enable the merged-usr by default. However to be able to
ship the new configuration files once their format is known, it would be
better for debootstrap to install a package whose role will be to provide
those configuration files ASAP after dpkg starts to support them.

> The problem is that this requires adding support for config
> files and config fragments to dpkg-query, which has the additional
> problem of making it possible to mess with the --showformat option
> and breaking the expectations from maintscripts, for example.

Forbid those options there? Do not parse those files if you detect
an environment variable DPKG_RUNNING_VERSION?

> The other problem is with the search behavior changing depending on the
> packages providing those mappings being installed (because dpkg would
> certainly not provide them).

That's the whole point of it so I would not consider this a problem.

> So I'll eventually try to find a solution for the dpkg-query issue,
> because it's a long-standing paper-cut in dpkg for local admins. But
> I'd not be very amused if this hack is enabled by default again and
> suddenly RC bugs start popping up in dpkg again, and people start
> pressuring with RCness to get those fixed again because well, it's
> obviously breaking people's systems…

Are you considering both "usrmerge" and "debootstrap creating symlinks" as
hacks even once they would provide mapping data for dpkg --search?

I believe that we have had quite some testing already last time and I
would be surprised if we got many more RC bugs on dpkg that had to be fixed
on a short timeframe. I guess nobody can give you any assurance but
I'm sure that you can downgrade those bugs pointing to this discussion
and showing that this was part of the deal.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: busybox sh broken on i386 with glibc 2.26, leads to kernel panic

[Raphael Hertzog]

Hello,

On Wed, 17 Jan 2018, Aurelien Jarno wrote:
> busybox is compiled with -mpreferred-stack-boundary=2 on i386 which has
> the same effect of reducing the default stack alignment from 16 bytes to
> 2 bytes. This comes from arch/i386/Makefile:
> 
> |  # -mpreferred-stack-boundary=2 is essential in preventing gcc 4.2.x
> |  # from aligning stack to 16 bytes. (Which is gcc's way of supporting SSE).
> |  CFLAGS += $(call cc-option,-march=i386 -mpreferred-stack-boundary=2,)
> 
> I don't really get why it is essential to prevent gcc from aligning
> stack to 16 bytes, anyway this is a bad idea. Removing this option just
> fixes the issue.

I confirm that rebuilding busybox with this option dropped fixed the issue
for me. I uploaded a fixed busybox to Kali. I'm happy to do the same for
Debian if it can help the current maintainers.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

busybox sh broken on i386 with glibc 2.26, leads to kernel panic

[Raphael Hertzog]

Control: reassign -1 src:glibc 2.26-1
Control: retitle -1 busybox sh broken on i386 with glibc 2.26, leads to kernel 
panic
Control: severity -1 serious
Control: affects -1 + busybox src:linux

Hello,

on i386 with glibc 2.26-4, busybox sh is broken:

$ busybox sh
[...]
BusyBox v1.27.2 (Debian 1:1.27.2-2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Segmentation fault

In the kernel messages, you see this:
[1097712.640730] traps: busybox[3288] general protection ip:f7e9a51d 
sp:ff8da68c error:0 in libc-2.26.so[f7d48000+1cd000]

There's a work-around (the same as the one described in
#887169):

$ GLIBC_TUNABLES=glibc.tune.hwcaps=-SSE4_2 busybox sh
[...]
BusyBox v1.27.2 (Debian 1:1.27.2-2) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $

Given that busybox's sh is used in the initrd and that the init
command is a shell script, this will lead to the kernel panic
shown earlier in this bug report.

Possible work-arounds in the mean time:
- disable busybox in the initrd by setting BUSYBOX=n in
  /etc/initramfs-tools/initramfs.conf (but this is not
  possible if you use cryptsetup)
- you can add the "GLIBC_TUNABLES=glibc.tune.hwcaps=-SSE4_2" to the kernel
  command line so that it's set in the environment of the init script
  (this will at least let you boot once to fix it permanently)
- install busybox-static instead of busybox (since it was built with
  an earlier version of glibc) and rebuild your initrd.

Aurélien Jaron commented on IRC that this was strange that busybox
was affected by this bug since the analysis made in #887169 lead to
believe that only binaries compiled with -mstack-align=4 would be
affected.

I see that busybox uses things like this:

include/platform.h:# define ALIGN1 __attribute__((aligned(1)))
include/platform.h:# define ALIGN2 __attribute__((aligned(2)))
include/platform.h:# define ALIGN4 __attribute__((aligned(4)))

Could those attributes have a similar effect than -mstack-align=4 ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

On Tue, 02 Jan 2018, Moritz Mühlenhoff wrote:
> Even more reason not to enable it if desktops are already catered for.

There's more than GNOME in Debian.

> > Right, there are cases where a service restart is required. There are also
> > many cases where it's not at all required because the library is only used
> > by short-lived processes. And there are security updates of applications
> > too. In all those cases, there are security benefits.
> 
> But it also provides a completely false sense of security as in "Debian takes
> care of this by default, no need to bother".

I think we can document the limitations of our current update procedure.

> > Or we could have a way to tag such breaking upgrades and teach
> > unattended-upgrades to skip them? And the unattended upgrades would notify
> > the admin about the need to manually upgrade?
> 
> Possibly, yes.

Can you file a wishlist bug suggesting this so that a more concrete
proposal can be hashed out with the unattended-upgrades maintainers ?

> > In any case, I'm not convinced that not installing updates and keeping a
> > running vulnerable service is better than breaking the service and letting
> > the admin fix it. If the admin is really concerned with the occasional
> > breakage then he will use another process and deinstall
> > unattended-upgrades.
> 
> unattended-upgrades is a crude hack at best, it's _not_ suitable for a default
> installation. There might be scenarios where it's fine to apply (e.g.
> in some test/staging environment or a desktop where breakage is acceptable and
> where people can install unattended-upgrades), but not for Debian 
> installations
> per se.

Besides service reloading, and a way to skip breaking upgrades, what else
would be needed so that you don't call it a "crude hack"?

> It also totally changes the dynamics from "Debian releases updates and it's
> my responsibility to test and deploy them within the parameters of my setup"
> to "updates are installed by default and the inevitable random regression 
> broke our systems, it's Debian's fault".

I don't see the relationship. This is really a question of documentation
and of setting the expectations straight.

> Providing security support for the biggest distro on a volunteer basis
> is complex enough, no need for unattended-upgrades to interfere further.

We certainly don't want to make it more complex for you, we just want more
people to benefit from your work, all those that are not paying attention
at all on the cloud servers that they brought up and then forgot about
when they were doing what they were supposed to do.

> > Because it was largely discussed on debian-devel already and I was not
> > aware that the security team had any reservation about this. I would
> > rather that we keep going and improve where needed instead of reverting
> > the change.
> 
> Random mailing discussions are not a useful consensus building mechanism,
> most of us don't follow them on a timely basis. This primarily affects the
> Security Team and such changes need to be brought to the attention of
> t...@security.debian.org

OK, putting team@security in copy now. I would like to hear the opinion of
other team members. Do you all agree with what Moritz said? Do you expect
more work for the security team just because we enable unattended-upgrades
by default? What kind of problems do you foresee?

At this point, if you all agree that this needs to be reverted, then you
will have to open a new bug report making your case. It would be even
better if you filed bugs against unattended-upgrades so that there is a
chance that the tool grows the missing features.

For the actual decision of reverting this default value, IMO we should
wait until later in the buster cycle, just to see if your concerns about
unattended-upgrades are fixed and to see how this works out in practice
(although the lack of security updates for testing makes it a bit
pointless as an experiment).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hi,

On Sun, 17 Dec 2017, Moritz Mühlenhoff wrote:
> unattended-upgrades are not an appropriate default. It's okay for a desktop
> system which gets powered down daily, so you can add it to tasksel lists for
> desktop roles, but not enable it by default for servers.

I think it's not really useful for GNOME since it already has the required
plumbing to install updates when you shut down.

> - It does not handle restarts. If you upgrade OpenSSL (or any library) with
> it, all your services will be left vulnerable until restarted. It will
> give people a warm fuzzy feeling, but not any actual security benefit.

Right, there are cases where a service restart is required. There are also
many cases where it's not at all required because the library is only used
by short-lived processes. And there are security updates of applications
too. In all those cases, there are security benefits.

> - We do need to make the occasional breaking change where people have to
> modify configuration settings or perform additional manual steps. With
> unattended-upgrades people don't have a chance to intervene. And if their
> setups break, we're the ones who get blamed.

If this is a real concern, we can maybe have some environment variable
indicating that the upgrade is automatic without any human watching it and
have the preinst fail?

Or we could have a way to tag such breaking upgrades and teach
unattended-upgrades to skip them? And the unattended upgrades would notify
the admin about the need to manually upgrade?

In any case, I'm not convinced that not installing updates and keeping a
running vulnerable service is better than breaking the service and letting
the admin fix it. If the admin is really concerned with the occasional
breakage then he will use another process and deinstall
unattended-upgrades.

> Why was this change made without contacting t...@security.debian.org (as
> the ones who are affected the most)?

Because it was largely discussed on debian-devel already and I was not
aware that the security team had any reservation about this. I would
rather that we keep going and improve where needed instead of reverting
the change.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Epochs in git tags

[Raphael Hertzog]

Hi,

On Fri, 08 Dec 2017, Christian PERRIER wrote:
> It seems that debcommit changed its way to tags releases with an
> epoch: up to recently, the epoch was just dropped, but now it is used,
> but ":" is replaced by "%"
> 
> That indeed explains why I "suddenly" changed my tagging method
> without even knowing.

Note that this is in conformance with DEP-14:
http://dep.debian.net/deps/dep14/ (version mangling section)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Hello,

On Mon, 11 Dec 2017, Raymond Burkholder wrote:
> I think I got thrown off by the title 'unattended upgrades'.  If this is
> limited to security updates, I am more for it, but still scared of it.

Maybe you should document yourself before commenting and sharing such a
strongly worded opinion. Have a look at the unattended-upgrades package
and what it does.

> But my experience has mostly been with regular package updates.  I haven't
> focused much on security updates.  Can security updates be applied with out
> generating dependency chains and their updates?

Yes. I am seriously doubting that you ever applied any security update on
a server running Debian stable by yourself. That's the point of security
updates on stable releases, they fix only the security vulnerabilities but
do not introduce functional changes and have a limited risk of breakage.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#883711: pkgsel: should running updatedb really be the default?

[Raphael Hertzog]

On Wed, 06 Dec 2017, Cyril Brulebois wrote:
> This commit looks like something that should be been discussed, rather than
> something I get to discover while preparing the release announcement:

Most of the time when I hear from you, it's for a complaint. You might not
realize, but your mails are very often passive aggressive and (from
first-hand comments I got) they are driving away some contributors. It
would be so much better if you could just start by thanking people for the
work they put into Debian.  Something like this:

« Thanks for your contribution, but I would like to have some discussion
about this feature that you committed. I'm not convinced that ...
because  What do people think ? »

You tend to write mails that bring to our attention how we did annoy you
in some way. While you might be really annoyed, none of us are doing
anything to annoy you voluntarily.

[ Sorry for this small digression, I don't know if you ever heard such a
complaint but I found it important to let you know my feelings. I hope
it can help you become a better d-i release manager. If not, sorry to have
annoyed you even more. ]

> If you're concerned about users expecting to be able to run *locate without
> waiting for the cron.daily entry, I think it'd be better to have
> implementations mention that the DB is empty and how to initialize it
> instead.

That's certainly a possible improvement. Not one I'm going to pursue
though. I was working on pkgsel and took the opportunity to review
and merge useful Ubuntu changes. This one looked like fine... in
particular because I remembered to have been hit by this in the past.

> I might flip the default to false for the next release, as I don't see why
> every user should pay this price for no obvious gain.

All locate implementations that we have are optional, so they are not
installed by default. They are also not part of any standard desktop task.

Thus it's not a price that every user will pay. Only those that install
those packages.

IMO changing the default value means the entire feature is useless, you might
as well revert the commit in that case. I will not be offended by such a
revert.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Replace discover by isenkram in d-i, better integration with virtualizations/clouds

[Raphael Hertzog]

Hi,

On Mon, 04 Dec 2017, Thomas Goirand wrote:
> On 12/03/2017 05:30 PM, Raphael Hertzog wrote:
> > In the last years, Petter Rheinholdtsen worked on isenkram[2] with a
> > similar but a bit broader goal. I noticed it has better support
> > of clouds and that it will install some virtualization/cloud-related
> > packages automatically whereas discover does not. It also makes it easier
> > to install the appropriate firmware packages.
> 
> Raphael,
> 
> Could you give examples of packages that gets installed this way?

open-vm-tools, xserver-xorg-video-vmware, xserver-xorg-input-vmmouse on VMWare 
VM

xserver-xorg-video-qxl on VM with such video driver (qxl is not true
hardware)

> Also, how is d-i related to cloud? The images aren't generated using d-i
> anyway, so I don't see how the cloud images would be affected.

The official images arent't. That doesn't mean that no users are using
it in VM that they are deploying in clouds.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Replace discover by isenkram in d-i, better integration with virtualizations/clouds

[Raphael Hertzog]

Hi,

On Sun, 03 Dec 2017, Cyril Brulebois wrote:
> > I see mainly benefits to such a move. The only downside is that it
> > would pull python by default. This entirely depends on whether we want
> > to keep it installed or not. We could install it just to do a single
> > scan and install pass during installation and then get rid of it (this
> > would then likely be made configurable with a debconf preseed).
> 
> Well, I'm not sure it's really a good idea to put more packages in the
> default installation loop; we've been going the opposite direction for
> quite a while, and that seems like the right thing to do.

I think we want to be have a smaller minbase for use cases where it
matters but I don't think that we necessarily want less packages in
the default installation. In particular not when they add value,
which isenkram clearly does.

> Quick digression: As for virtualization and cloud support, it seems the
> cloud team has been working on standardizing a tool that fits most virt-
> & cloud- related needs (at least that's what I gathered from Steve's
> presentation during mini-DebConf in Cambridge), so I'm not entirely
> convinced by the net gain on the d-i side for this specific use case (if
> users are using something else entirely anyway…).

I'm not sure what tool you are referring to. In any case, I appreciate
that isenkram installs the correct packages for virtualbox,
vmware, etc.

While our official VM/cloud images are usually not built with
debian-installer, I stronly believe that d-i should have a nice behaviour
in VM and install the appropriate packages for the virtualization
technology in use.

If isenkram is not the solution to this, then we need something else.

> I have no idea about the isenkram architecture, but reusing the “data
> files mapping hardware to packages” part is probaby a good idea.

What do you mean by this?

Reusing the mapping database maintained in isenkram in the context of d-i?

I would like Petter to give a broader comparison of discover vs isenkram.
But I believe that isenkram is a bit smarter in that it doesn't only
handles devices ID discovered in PCI/USB/whatever buses but it also relies
on data from the system (dmidecode and stuff like that) to infer more
packages to install.

So it might not be trivially reusable in the context of discover for
example.

> Petter mentioned we could strip bits and pieces and only use something
> that wouldn't depend on the whole lot, but I lost count. (That was
> likely back when we had to deal with hw-detect and firmware support.)

Petter, do you have more details about your former discussions?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Replace discover by isenkram in d-i, better integration with virtualizations/clouds

[Raphael Hertzog]

[ Please respect reply-to, let's have this discussion on debian-boot ]

Hello everybody,

debian-installer is using discover[1] to install some packages based on the
hardware it discovers. Unfortunately, discover is dead upstream (Debian is
the upstream really) and the hardware->package database is not maintained
at all.

In the last years, Petter Rheinholdtsen worked on isenkram[2] with a
similar but a bit broader goal. I noticed it has better support
of clouds and that it will install some virtualization/cloud-related
packages automatically whereas discover does not. It also makes it easier
to install the appropriate firmware packages.

I would thus suggest that we consider replacing discover by isenkram-cli.

Last time I discussed this with Petter, he was willing to do the ground
work on the debian-installer side but he did not want to lead this
discussion. I'm thus starting the discussion myself.

I see mainly benefits to such a move. The only downside is that it would
pull python by default. This entirely depends on whether we want to keep
it installed or not. We could install it just to do a single scan and install
pass during installation and then get rid of it (this would then likely
be made configurable with a debconf preseed).

Cheers,

[1] https://tracker.debian.org/pkg/discover
[2] https://tracker.debian.org/pkg/isenkram
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#868900: iso-scan: should be able to copy the ISO into RAM before mount

[Raphael Hertzog]

Hi,

On Wed, 29 Nov 2017, Miguel Figueiredo wrote:
> > Let me know if there's anything to improve before it's ready to be merged
> > (notably on the debconf template, etc.).
> 
> [...]
> 
> Installation guide update ?

Done: https://anonscm.debian.org/viewvc/d-i?view=revision=70938

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Permission to commit and upload?

[Raphael Hertzog]

Hi,

On Sun, 29 Oct 2017, Colin Watson wrote:
> > Colin, could you review the patches I sent in the above bug reports and
> > let me know if you think they are suitable to be committed ? You made
> > similar changes to mine in debian-installer-utils and you have a broad
> > knowledge of debian-installer.
> 
> I've left a few UX and code review comments in #868848, #868859, and
> #868900.  Without having tried actually running them or anything, they
> seem reasonable to me otherwise.
> 
> I don't see anything wrong with #868852, but I haven't done much with
> image building for some years so I don't know if there are any size
> concerns or whatever.  If that's not an issue then it's probably fine.

I believe that I have addressed all concerns of Colin. I have pushed
the resulting work in the various git repositories. The following source
packages thus have unreleased changes right now:
- iso-scan (the bulk of the work)
- debian-installer-utils (changes to list-devices)
- rescue (avoid duplicate entries with updated list-devices)
- partman-lvm (avoid problem when you try to auto-partition the drive
  containing the LV containing the ISO used by the installer)
- debian-installer (adding the required kernel modules in the hd-media
  images)

Don't hesite to ping me if you have any problem related to one of my
changes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#868900: iso-scan: should be able to copy the ISO into RAM before mount

[Raphael Hertzog]

Control: tag -1 + pending

On Sun, 29 Oct 2017, Colin Watson wrote:
> diff --git a/debian/iso-scan.postinst b/debian/iso-scan.postinst
> index e34f329..1109ba5 100755
> --- a/debian/iso-scan.postinst
> +++ b/debian/iso-scan.postinst
[...]
> The directory-changing here is messy, and left me wondering whether
> analyze_cd might depend on the current directory, which is now different
> depending on which option you select.  I don't think it does, but I had
> to read that function to make sure.  I'd suggest simplifying this
> section of code by mounting or copying by absolute path, i.e.
> "/hd-media/$iso_to_try", rather than relying on it being in the current
> directory; you then won't need either "cd /hd-media" or "cd /" in this
> function.

Done:
https://anonscm.debian.org/cgit/d-i/iso-scan.git/commit/?id=6a22df6676bfbba6b2a49c512499a189768c3475

>  * Would it be worth doing an explicit check of how much free memory is
>available and either warning the user or just refusing outright to do
>the copy-to-RAM operation if they don't have enough (size of image
>plus fudge factor)?

Done. If the user doesn't have enough RAM, we don't offer the possibility
to copy the ISO to RAM. The template is thus rewritten accordingly.

>  * We should warn the user that, if they opt to copy the image into RAM,
>then they mustn't reboot between partitioning and the end of the
>installation as their installation media may be made unusable.
>(Wordsmithing this into something comprehensible is left as an
>exercise for the reader.)

You can find the updated templates in the commit I pushed:
https://anonscm.debian.org/cgit/d-i/iso-scan.git/commit/?id=1728471d573c8f5ddc7909a2472a4ae82ad8b8cf

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#868859: iso-scan: should also scan LVM logical volumes

[Raphael Hertzog]

Control: tag -1 + pending

On Sun, 29 Oct 2017, Colin Watson wrote:
> > Obviously this has implications on the rest of the installation process.
> > The logical volume will be in use and the partitioning step will have
> > to preserve the logical volume and its parent volume group.
> > 
> > But partman is perfectly able to cope with the logical volumes being
> > already activated so it should be fine to do this here.
> 
> I agree that it ought to work, but what testing have you done of this?
> Have you confirmed that the LV is marked as locked in partman and can't
> be changed using manual partitioning operations?  What happens with
> automatic partitioning?

I just did some further tests. In manual partitioning, it was correctly
refusing to remove the logical volume that was in use. It was also not
letting me change anything on the partition used as physical volume.

However in automatic partitioning, it would propose to wipe the LV, VG and
PV. You can accept it and you get not failure. However you get a failure
later on when you ask the kernel to reload the newly created partition
table... but at this point it's too late already.

I thus pushed a fix to partman-lvm:
https://anonscm.debian.org/cgit/d-i/partman-lvm.git/commit/?id=b628ca59695e549e5672b26919ba3aa9c3c371f0

With this fixed partman-lvm, it will still offer to wipe everything
but you get an instant failure and the partitioner is still in a
consistent state.

> > +   if type vgchange >/dev/null; then
> 
> Nit: it's worth ">/dev/null 2>&1" here, as "type" writes to stderr if
> the command isn't available, and that's probably just noise in the logs.

Done. I pushed my updated patch.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Busybox 1.27 breaks kernel cmdline preseeding

[Raphael Hertzog]

On Mon, 27 Nov 2017, Philip Hands wrote:
> I'm not sure its important, but when testing a similar script I came up
> with something that seems to give better results on the (perhaps
> demented) test case I was playing with.  Here's mine:
> 
>   's/\([^= ]\+\|\([^= ]*=\("[^"]*"\|'"'[^']*'"'\|[^"'"'"' ][^ ]*\)\)\)\( 
> \|$\)/\1\n/g'
> 
> The sed is not as nice to look at though.  I attach my test script.

Yeah, it works. I updated my pu/kernel-cmdline-preseed to use this except
that I dropped one set of useless parenthesis (the one in the middle of
the stack).

And I added a comment explaining the regular expression as this:
# read this as 
(single-word|var-name=("value"|'value'|unquoted-value))(space|EOL)

> BTW Should we actually be outputting the bits that contain no '=' for this?
> If not, we could just pipe into:
> 
>   grep =

I added this as well, although the shell code afterwards already skips
over if the value is determined to be empty.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Busybox 1.27 breaks kernel cmdline preseeding

[Raphael Hertzog]

Hi,

On Mon, 27 Nov 2017, Mathieu Trudel-Lapierre wrote:
> On Mon, Nov 27, 2017 at 3:08 PM, Raphael Hertzog <hert...@debian.org> wrote:
> [...]
> > I pushed a pu/kernel-cmdline-preseed branch implementing the preseeding
> > out of /proc/cmdline. It's more elaborate than Mathieu's patch
> > (https://paste.ubuntu.com/26034695/) in that it is able to handle
> > multi-word values.
> >
> > I tested it locally and it fixes the rescue mode for me. For
> > consistency, I renamed the command and the udeb, but the only place
> > where it matters is in "debian-installer" itself where we have to update
> > the package name.
> 
> That will work on most arches, but not on kfreebsd/*. That said, the
> easy fix would be to look at both environment and /proc/cmdline.

We wants to stop using the environment because busybox hides it from us...
I don't see the point of continuing to use it.

Can you elaborate on what's wrong with /proc/cmdline on kfreebsd? We know
that it exists. Are you saying that it doesn't contain the actual
parameters passed on the kernel command line at boot time?

I put debian-...@lists.debian.org in copy to have their feedback/advice.
Is there any other way to get the parameters passed on the kernel
command line?

> I *think* you only really need -e 's/\([^ =]*=[^ "]\)/\n\1/g'  -e
> "s/\([^ =]*=[^ ']\)/\n\1/g" to multiline the entries and appropriately
> handle any multiword. With my limited testing it seemed to work well,
> and would be less complex than your solution ;)
> 
> Did I miss some important corner-case?

At least it does not cope well with parameters without any "=". Try adding
words like "quiet" in the middle of your parameter list. They do not end
up on a line of their own.

I freely admit that my solution is complex but I was not able to find a
simpler one that works well enough with my test case:
language=fr_FR long?='1 2 3' rescue/enable="true" my/description="un message" 
--- quiet

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#868848: debian-installer-utils: "list-devices partition" should report LVM logical volumes too

[Raphael Hertzog]

Control: tag -1 + pending

Hi,

On Sun, 29 Oct 2017, Colin Watson wrote:
> I think this is basically a reasonable thing to do, but it seems to me
> that it's going to cause rescue-mode to list LVs twice (see the
> choose_root function).  Could you fix that?  A sensible approach would
> probably be to exclude entries from LVMPARTS that are already in
> PARTITIONS, and we can simplify that later once the new list-devices is
> in place.

I fixed that by simply deduplicating the entries (with sort -u) after
having collated all entries to display.

See 
https://anonscm.debian.org/cgit/d-i/rescue.git/commit/?id=cfcb7296b519f462395bcf7a63c1ed7da897b5d7

> > and I'm not convinced that it's really required either (it's not a
> > requirement for iso-scan at least). I'm ccing Colin, he might have
> > some insight to share on this.
> 
> I could go either way on this, but I think it would probably make most
> sense to exclude partitions already in use by VGs.  "list-devices
> partition" is generally used to offer menus of partitions to find
> various files on, for which in-use PVs aren't going to be eligible; and
> the LVM assembly code uses its own code to find partitions.

Done. I pushed my changes.

https://anonscm.debian.org/cgit/d-i/debian-installer-utils.git/commit/?id=7e7e7905fb9805244274b93ae5280354d642125b
https://anonscm.debian.org/cgit/d-i/debian-installer-utils.git/commit/?id=3b2e9de85580f384e234aa787ae8a9e0b677f62e

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Busybox 1.27 breaks kernel cmdline preseeding

[Raphael Hertzog]

On Fri, 24 Nov 2017, Raphael Hertzog wrote:
> Apparently, kfreebsd has a working /proc/cmdline (thanks to linprocfs mounted
> by default) so we might want to switch to that.

I pushed a pu/kernel-cmdline-preseed branch implementing the preseeding
out of /proc/cmdline. It's more elaborate than Mathieu's patch
(https://paste.ubuntu.com/26034695/) in that it is able to handle
multi-word values.

I tested it locally and it fixes the rescue mode for me. For
consistency, I renamed the command and the udeb, but the only place
where it matters is in "debian-installer" itself where we have to update
the package name.

https://anonscm.debian.org/cgit/d-i/preseed.git/log/?h=pu/kernel-cmdline-preseed

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Busybox 1.27 breaks kernel cmdline preseeding

[Raphael Hertzog]

Hello,

On Fri, 24 Nov 2017, Cyril Brulebois wrote:
> > Now, how should we go about fixing this? Adam pointed out we could always
> > just parse /proc/cmdline, but this does not just work on kfreebsd. It's
> > also possible to consider both /proc/cmdline and the environment; or just
> > revert the particular change in busybox.
> > 
> > I don't feel strongly either way, but I want to make the solution available
> > in Debian as well... Anybody have a preference?
> 
> Right now (thinking of a release soon-ish), I think I'd be happy with a
> specific revert for the time being; then get people to figure out what to
> do next (I have no clue about such things at the moment).

It looks like it has been partially reverted upstream:
https://bugs.busybox.net/show_bug.cgi?id=10231
https://git.busybox.net/busybox/commit/?id=9c143ce52da11ec3d21a3491c3749841d3dc10f0

However this doesn't work for us either because the changes to "showvars"
also affect the output of "set" which we are using to retrieve the
environment variables in env2debconf.

Apparently, kfreebsd has a working /proc/cmdline (thanks to linprocfs mounted
by default) so we might want to switch to that. I don't know about the
hurd though.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#868852: debian-installer: hd-media images should have LVM support to find ISO in logical volumes

[Raphael Hertzog]

Hi,

On Thu, 23 Nov 2017, Cyril Brulebois wrote:
> You mentioned on IRC you were looking into several patches/packages.
> I'll probably release d-i over the next few days, so I'm not sure I'll
> pick all updates for the next alpha. I'll likely only pick what's
> needed, and we'll finish merging things after the release.

Fine for me.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#868852: debian-installer: hd-media images should have LVM support to find ISO in logical volumes

[Raphael Hertzog]

Hi Cyril,

On Thu, 23 Nov 2017, Cyril Brulebois wrote:
> So this seems to have just been committed. Can you expand on the arch
> selection? It seems strange.

It's basically the release architectures that have an hd-media
configuration file.

Do you want me to do the same change to non-release Linux architectures
that have an hd-media configuration file (aka powerpc and m68k)?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Towards Debian Buster Alpha 2

[Raphael Hertzog]

On Tue, 31 Oct 2017, Christian PERRIER wrote:
> I'll also build/upload pkgsel with Raphael's changes

Hum, I uploaded 0.46 after having committed my changes (and it's in
testing already apparently).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Permission to commit and upload?

[Raphael Hertzog]

[ Colin, there's a review request for you in there ]

Hello Cyril,

On Thu, 12 Oct 2017, Cyril Brulebois wrote:
> Raphael Hertzog <hert...@debian.org> (2017-10-09):
> > (feel free to cc me so that I see your answer sooner)
> > 
> > Hello everybody,
> > 
> > I have a few pending patches that I'd like to commit and upload... but
> > since I'm only an occasional d-i contributor, I would like to double
> > check that nobody has any objection.
> > 
> > My current list is:
> > - #868848: debian-installer-utils
> > - #868852: debian-installer: hd-media images
> > - #868859: iso-scan and LVM
> > - #868900: iso-scan: should be able to copy the ISO into RAM before mount
> > - #875858: integrate unattended-upgrades in pkgsel
> > 
> > The first four bugs are closely related (the first two are dependencies of
> > the third) as they allow hd-media images to find an ISO image to use
> > within a logical volume.
> 
> I really want someone who's worked with the ISO/hd-media codepath in the
> past to double check these. Earlier attempts at forcing these features
> onto us weren't convincing, to say the least.

So I pushed and uploaded pkgsel 0.46 for #875858. For the remaining four
bugs, I have nothing against a review but I hope it does not end up
being stalled because nobody wants to review those changes. It's not clear
to me who is that person. In the iso-scan changelog, you are the last
non-translation committer and before that it was Otavio Salvador/Colin
Watson in 2012... in the hd-media image definition, many people committed
fixes for changes to udeb but I see no clear owner of that image either.

Colin, could you review the patches I sent in the above bug reports and
let me know if you think they are suitable to be committed ? You made
similar changes to mine in debian-installer-utils and you have a broad
knowledge of debian-installer.

Thank you in advance.

PS: Cyril, can you point me to the earlier attempts for these features?
Maybe I can double check that I did not fall in the problems that were
spotted earlier...
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Permission to commit and upload?

[Raphael Hertzog]

(feel free to cc me so that I see your answer sooner)

Hello everybody,

I have a few pending patches that I'd like to commit and upload... but
since I'm only an occasional d-i contributor, I would like to double
check that nobody has any objection.

My current list is:
- #868848: debian-installer-utils
- #868852: debian-installer: hd-media images
- #868859: iso-scan and LVM
- #868900: iso-scan: should be able to copy the ISO into RAM before mount
- #875858: integrate unattended-upgrades in pkgsel

The first four bugs are closely related (the first two are dependencies of
the third) as they allow hd-media images to find an ISO image to use
within a logical volume.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#852323: debian-installer: grub-installer not convert root= entry to UUID

[Raphael Hertzog]

On Mon, 09 Oct 2017, Michael Stone wrote:
> > I'd still expect the installer to DTRT with UUIDs in that case, though.
> > I'm more thinking of a non-standard bootup / custom kernel or similar...
> 
> Maybe I'm missing something here? Fire up a current debian netinst 9.2 iso
> in a kvm session (no special image or unusual hardware), go through an
> install. On reboot, look at the defult boot entry in grub, note that on the
> kernel command line root=/dev/sda1 (or somesuch) not UUID=X. This is very
> reproducible. In practice this results in an unbootable system for a
> non-expert user if they install from a USB stick that comes up as sda (so
> the grub entry is sdb) and they pull the USB stick out to boot into debian.
> If the kernel command line is manually fixed up, running update-grub after
> boot will create the expected root=UUID=X kernel command line.
> 
> This is a regression from jessie, for which the exact same sequence of
> commands would result in a grub kernel command line with root=UUID=X

This smells similar to the problem I have seen here when update-grub
is run in a chroot:
https://bugs.debian.org/872999

Unfortunately, the root cause is not clear. It looks like a behaviour
change at the kernel level...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raphael Hertzog]

Control: tag -1 + patch

On Fri, 15 Sep 2017, Steve McIntyre wrote:
> >For Debian, I don't think that making such a difference makes sense.
> >We should:
> >- either always show the question with its default value of "none"
> >  (thus making sure that they have a chance to opt-in to this feature)
> >- or not show the question (priority "medium") but make it default
> >  to install unattended-upgrades so that they get updates by default but
> >  have a chance to disable that with preseeding
> >
> >Given the last discussion on -devel
> >(https://lists.debian.org/debian-devel/2016/11/threads.html#00117) I think
> >we should make a bold choice and do the latter.
> >
> >I'm going to submit a tested patch later on.
> 
> Sounds reasonable, yes.

Ok, so here's my set of patches. Relevant to this bug are the first and
the last one. The other commits are other random improvements that I merged
from Ubuntu that looked like useful.

I tested the attached patches on modified mini.iso where I force-injected
pkgsel and bootstrap-base (because I could not manage to get anna to
reload the modified templates if I installed the new pkgsel manually once
the installer was started up to the configure network step).

Reviews are welcome.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From 07855172bf545b6c6e632b4f3c6e267b056d5862 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 15 Sep 2017 11:29:00 +0200
Subject: [PATCH 1/7] Merge pkgsel/update-policy preseed from Ubuntu to offer
 to install unattended-upgrades.

---
 debian/changelog |  7 +++
 debian/pkgsel.templates  | 13 +
 pre-pkgsel.d/20update-policy | 41 +
 3 files changed, 61 insertions(+)
 create mode 100755 pre-pkgsel.d/20update-policy

diff --git a/debian/changelog b/debian/changelog
index d9934a7..5dd6dc7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pkgsel (0.46) UNRELEASED; urgency=medium
+
+  * Merge pkgsel/update-policy preseed from Ubuntu to offer to install
+unattended-upgrades.
+
+ -- Raphaël Hertzog   Fri, 15 Sep 2017 11:26:14 +0200
+
 pkgsel (0.45) unstable; urgency=medium
 
   * Export DEBIAN_TASKS_ONLY=1 when running tasksel in target, to make
diff --git a/debian/pkgsel.templates b/debian/pkgsel.templates
index 6ce4290..0b8fd54 100644
--- a/debian/pkgsel.templates
+++ b/debian/pkgsel.templates
@@ -48,3 +48,16 @@ Description: for internal use; can be preseeded
 Template: pkgsel/progress/fallback
 Type: text
 _Description: Running ${SCRIPT}...
+
+Template: pkgsel/update-policy
+Type: select
+Default: none
+Choices-C: none, unattended-upgrades
+__Choices: No automatic updates, Install security updates automatically
+_Description: How do you want to manage upgrades on this system?
+ Applying updates on a frequent basis is an important part of keeping your
+ system secure.
+ .
+ By default, updates need to be applied manually using package management
+ tools. Alternatively, you can choose to have this system automatically
+ download and install security updates.
diff --git a/pre-pkgsel.d/20update-policy b/pre-pkgsel.d/20update-policy
new file mode 100755
index 000..c3588da
--- /dev/null
+++ b/pre-pkgsel.d/20update-policy
@@ -0,0 +1,41 @@
+#!/bin/sh
+
+set -e
+. /usr/share/debconf/confmodule
+
+DISTRIB_ID=$(. /target/etc/os-release; echo $ID)
+DISTRIB_ID_LIKE=$(. /target/etc/os-release; echo $ID_LIKE)
+
+if [ "$DISTRIB_ID" = "ubuntu" ] || [ "$DISTRIB_ID_LIKE" = "ubuntu" ]; then
+	# Ubuntu hack to ask this at high priority on server or netboot
+	# installations, medium otherwise
+	if [ ! -d /cdrom/.disk ] || grep -iq server /cdrom/.disk/info; then
+		update_priority=high
+	else
+		update_priority=medium
+	fi
+else
+	# In Debian, we always ask the question
+	update_priority=high
+fi
+
+db_input "$update_priority" pkgsel/update-policy || true
+db_go || true
+db_get pkgsel/update-policy
+if [ "$RET" = none ]; then
+	# We might pull in unattended-upgrades, which defaults to doing security
+	# updates automatically. Seed it to have auto updates disabled so that if
+	# we *do* pull it in, it won't break stuff.
+	echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean false' | \
+		log-output -t pkgsel chroot /target debconf-set-selections || \
+		true
+elif [ "$RET" = unattended-upgrades ]; then
+	# unattended-upgrades defaults to true on installation if otherwise untouched.
+	apt-install unattended-upgrades || true
+elif [ "$RET" = landscape ]; then
+	# This is Ubuntu-specific but does no harm here
+	echo 'landscape-client landscape-client/register_system boolean true' | \
+		log-output -t pkgsel chroot /target debconf-set-selections || \
+		true
+	apt-install landscape-client || true
+fi
-- 
2.14.1

>From 391eb9457ec44eaa8d2a4603fcbf6c9c2a581821 Mon 

Re: Bug#872598: udev-udeb: no input in graphical installer

[Raphael Hertzog]

Hi,

On Thu, 24 Aug 2017, Cyril Brulebois wrote:
> > The attached patch seems to do the trick, will upload after a full build
> > inside sbuild, then open a bug report as you suggested on IRC, so that
> > you think about reverting this when the gcc-7 bug is fixed.
> 
> I initially meant to add g++ and CXX and should have, but it seemed
> not to be needed… until it failed on buildds since there are checks
> building in c++ mode; which I didn't catch locally because the wrong
> chroot has been used while build testing… Sorry for that.

I had a similar problem for shiboken and Adrian Bunk pointed out on
#debian-mips that this also works around the failure:
DEB_CXXFLAGS_MAINT_APPEND = -mno-lra
DEB_CFLAGS_MAINT_APPEND = -mno-lra

Apparently that's the broken feature in gcc-7 on mips64el.

For the record, when updating systemd, I also had other tests failures on
armel in Kali due to test-hash failing... but that test is skipped in
Debian due to the kernel not supporting the feature apparently. But with a
kernel provided by my hosting provider (scaleway.com), it did fail. I
built my package somewhere else to work around this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#868900: iso-scan: should be able to copy the ISO into RAM before mount

[Raphael Hertzog]

Source: iso-scan
Version: 1.57
Severity: wishlist
Tags: patch

When you use an ISO image stored on a disk, it makes it impossible to
re-use that disk in the installation process (e.g. for automatic
partitioning).

In order to avoid this limitation, I would like iso-scan to be able
to copy the ISO image into RAM and to mount it from there. The attached
patch implements precisely when the debconf question "iso-scan/copy_iso_to_ram"
returns true.

It would be nice to see this merged (the patch applies cleanly on top
of the one in #868859, but you can also merge it separately if you drop
the changelog entry).

Let me know if there's anything to improve before it's ready to be merged
(notably on the debconf template, etc.).

Cheers,

-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From f036be16012d1004053fa977258c842b1d9eed47 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Wed, 19 Jul 2017 16:20:38 +0200
Subject: [PATCH] Offer possibility to copy ISO to RAM before mount

The iso-scan/copy_iso_to_ram debconf question controls this new
feature. It defaults to false for backwards compatibility and also
because it can only be safely enabled when the amount of RAM is
sufficient to host a full copy of the image.
---
 debian/changelog  |  3 +++
 debian/iso-scan.postinst  | 19 ++-
 debian/iso-scan.templates | 14 ++
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 6abd1db..18c47c8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,9 @@ iso-scan (1.58) UNRELEASED; urgency=medium
 
   * Detect LVM logical volumes so that they can be used to find the ISO image
 that we are looking for.
+  * Copy the ISO image into RAM before mounting it when debconf question
+iso-scan/copy_iso_to_ram is true. This makes it possible to use the disk
+that provided the ISO image for (automatic) partitioning.
 
  -- Raphaël Hertzog   Tue, 18 Jul 2017 16:58:13 +0200
 
diff --git a/debian/iso-scan.postinst b/debian/iso-scan.postinst
index e34f329..1109ba5 100755
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -203,9 +203,26 @@ use_this_iso () {
 	local iso_device=$2
 	local RET
 
+	db_input low iso-scan/copy_iso_to_ram || true
+	db_go
+	db_get iso-scan/copy_iso_to_ram
+
 	mount -t auto -o ro $iso_device /hd-media 2>/dev/null
 	cd /hd-media
-	mount -t iso9660 -o loop,ro,exec $iso_to_try /cdrom 2>/dev/null
+
+	if [ "$RET" = false ]; then
+		# Direct mount
+		log "Mounting /hd-media/$iso_to_try on /cdrom"
+		mount -t iso9660 -o loop,ro,exec $iso_to_try /cdrom 2>/dev/null
+	else
+		# We copy the ISO to RAM before mounting it
+		log "Copying /hd-media/$iso_to_try to /installer.iso"
+		cp $iso_to_try /installer.iso
+		log "Mounting /installer.iso on /cdrom"
+		mount -t iso9660 -o loop,ro,exec /installer.iso /cdrom 2>/dev/null
+		cd /
+		umount /hd-media
+	fi
 
 	analyze_cd
 
diff --git a/debian/iso-scan.templates b/debian/iso-scan.templates
index e3a23d1..76ba00a 100644
--- a/debian/iso-scan.templates
+++ b/debian/iso-scan.templates
@@ -126,3 +126,17 @@ _Description: Is ISO file ${FILENAME} the correct image for installation?
  .
  If multiple ISO files exist on the same installer drive,
  you may select which one you want to use.
+
+Template: iso-scan/copy_iso_to_ram
+Type: boolean
+Default: false
+# :sl3:
+_Description: Copy the ISO image into RAM before mounting it?
+ If you don't copy the ISO image into RAM, then the disk hosting
+ the ISO image cannot be partitioned as the installer will be
+ actively using it.
+ .
+ However copying the ISO into RAM might not be possible if the ISO image
+ is larger than the amount of RAM available. If the amount of RAM
+ remaining after copy is too low, it might cause other unexpected failures
+ later in the installation process.
-- 
2.13.3

Bug#868859: iso-scan: should also scan LVM logical volumes

[Raphael Hertzog]

Source: iso-scan
Version: 1.57
Severity: normal
Tags: patch
User: de...@kali.org
Usertags: origin-kali kali-patch
Control: block -1 by 868848 868852

With this patch, I ensure that we activate LVM logical volumes so that
they are visible by "list-devices" and so that they can be scanned too.

That way we are also able to identify ISO images stored within LVM
logical volumes.

Obviously this has implications on the rest of the installation process.
The logical volume will be in use and the partitioning step will have
to preserve the logical volume and its parent volume group.

But partman is perfectly able to cope with the logical volumes being
already activated so it should be fine to do this here.

For this patch to work, we need some changes in:
- debian-installer-utils: https://bugs.debian.org/868848
- debian-installer hd-media image: https://bugs.debian.org/868852

Please find my suggested (and tested) patch attached.

-- System Information:
Debian Release: buster/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From d4914795492c2a4b85bbe1e3a8a7de7f9aa571a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Tue, 18 Jul 2017 16:59:32 +0200
Subject: [PATCH] Detect and scan LVM logical volumes too

That way we are also able to identify ISO images stored within LVM
logical volumes.

Obviously this has implications on the rest of the installation process.
The logical volume will be in use and the partitioning step will have
to preserve the logical volume and its parent volume group.

But partman is perfectly able to cope with the logical volumes being
already activated so it should be fine to do this here.

For this patch to work, we need some changes in:
- debian-installer-utils: https://bugs.debian.org/868848
- debian-installer hd-media image: https://bugs.debian.org/868852
---
 debian/changelog | 7 +++
 debian/iso-scan.postinst | 6 ++
 2 files changed, 13 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 4345d57..6abd1db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+iso-scan (1.58) UNRELEASED; urgency=medium
+
+  * Detect LVM logical volumes so that they can be used to find the ISO image
+that we are looking for.
+
+ -- Raphaël Hertzog   Tue, 18 Jul 2017 16:58:13 +0200
+
 iso-scan (1.57) unstable; urgency=medium
 
   [ Updated translations ]
diff --git a/debian/iso-scan.postinst b/debian/iso-scan.postinst
index a21ed85..e34f329 100755
--- a/debian/iso-scan.postinst
+++ b/debian/iso-scan.postinst
@@ -271,6 +271,12 @@ while :; do
 		done
 		modprobe loop >/dev/null || true
 
+		# Detect LVM logical volumes if possible
+		modprobe dm_mod >/dev/null || true
+		if type vgchange >/dev/null; then
+			vgchange -a y >/dev/null || true
+		fi
+
 		mkdir /cdrom 2>/dev/null || true
 		mkdir /hd-media 2>/dev/null || true
 
-- 
2.13.3

Bug#868852: debian-installer: hd-media images should have LVM support to find ISO in logical volumes

[Raphael Hertzog]

Source: debian-installer
Version: 20170615
Severity: wishlist
Tags: patch
User: de...@kali.org
Usertags: origin-kali kali-patch

I would like the hd-media images to include the "md-modules" and
"lvm2-udeb" udebs so that we can find the ISO image on LVM logical volumes
too.

The attached patch implements this. Does anybody have an objection or can
I commit this ?

The cost on the initrd.gz seems to be about 1.24Mb (the above udebs have
dependencies): my rebuilt initrd.gz is 17169667 bytes while the current
one on the daily-build seems to be 15862910 bytes.

Cheers,
 Raphaël.

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From 2b6285718813fc191befc46c2640f1766122c718 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Tue, 18 Jul 2017 17:05:04 +0200
Subject: [PATCH] Include udebs for LVM support in hd-media images

Update the hd-media image to include udebs required to detect
LVM logical volumes too (so that we can find the ISO in logical
volumes too).

lvm2-udeb is linux specific so we add the required udebs only in
the configuration files for linux architectures.
---
 build/pkg-lists/hd-media/amd64.cfg | 4 
 build/pkg-lists/hd-media/armhf.cfg | 4 
 build/pkg-lists/hd-media/i386.cfg  | 4 
 debian/changelog   | 5 +
 4 files changed, 17 insertions(+)

diff --git a/build/pkg-lists/hd-media/amd64.cfg b/build/pkg-lists/hd-media/amd64.cfg
index f020155a6..c33684b96 100644
--- a/build/pkg-lists/hd-media/amd64.cfg
+++ b/build/pkg-lists/hd-media/amd64.cfg
@@ -26,6 +26,10 @@ cdrom-core-modules-${kernel:Version}
 fat-modules-${kernel:Version}
 ext4-modules-${kernel:Version}
 
+# We want to be able to find the iso in a LVM logical volume too
+md-modules-${kernel:Version}
+lvm2-udeb
+
 # the iso is loop-mounted
 loop-modules-${kernel:Version}
 
diff --git a/build/pkg-lists/hd-media/armhf.cfg b/build/pkg-lists/hd-media/armhf.cfg
index 638bea2dd..be08feff6 100644
--- a/build/pkg-lists/hd-media/armhf.cfg
+++ b/build/pkg-lists/hd-media/armhf.cfg
@@ -21,6 +21,10 @@ scsi-core-modules-${kernel:Version}
 scsi-modules-${kernel:Version}
 virtio-modules-${kernel:Version}
 
+# We want to be able to find the iso in a LVM logical volume too
+md-modules-${kernel:Version}
+lvm2-udeb
+
 loop-modules-${kernel:Version}
 
 input-modules-${kernel:Version} ?
diff --git a/build/pkg-lists/hd-media/i386.cfg b/build/pkg-lists/hd-media/i386.cfg
index f020155a6..c33684b96 100644
--- a/build/pkg-lists/hd-media/i386.cfg
+++ b/build/pkg-lists/hd-media/i386.cfg
@@ -26,6 +26,10 @@ cdrom-core-modules-${kernel:Version}
 fat-modules-${kernel:Version}
 ext4-modules-${kernel:Version}
 
+# We want to be able to find the iso in a LVM logical volume too
+md-modules-${kernel:Version}
+lvm2-udeb
+
 # the iso is loop-mounted
 loop-modules-${kernel:Version}
 
diff --git a/debian/changelog b/debian/changelog
index 9f5a86bfe..967ab9684 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,11 @@ debian-installer (201707XX) UNRELEASED; urgency=medium
   [ Martin Michlmayr ]
   * Drop orion5x-qnap image.
 
+  [ Raphaël Hertzog ]
+  * Update the hd-media image to include udebs required to detect
+LVM logical volumes too (so that we can find the ISO in logical
+volumes too).
+
  -- Cyril Brulebois   Thu, 22 Jun 2017 06:48:30 +0200
 
 debian-installer (20170615) unstable; urgency=medium
-- 
2.13.3

Bug#868848: debian-installer-utils: "list-devices partition" should report LVM logical volumes too

[Raphael Hertzog]

Source: debian-installer-utils
Version: 1.119
Severity: normal
Tags: patch
User: de...@kali.org
Usertags: origin-kali kali-patch

Just like "list-devices partition" reports back RAID partitions, it should
also report LVM logical volumes. The attached patch does this.

My goal is to extend the "hd-media" image to be able to find the ISO image
within an LVM logical volume too. This is a preliminary step in this
project.

Currently, I'm not hiding the partitions used by the various volume
groups. This is unlike what has been done for RAID partitions. But
I don't know all the places where list-devices is used and I'm not
convinced that it's really required either (it's not a requirement
for iso-scan at least). I'm ccing Colin, he might have some insight to
share on this.

Let me know if anybody has any objection against this patch.

Raphaël.

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From 6a3ece02614a1d729c5438f4192aed8a399e27cc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Tue, 18 Jul 2017 16:41:46 +0200
Subject: [PATCH] Fix "list-devices partition" to also report LVM logical
 volumes

---
 debian/changelog   |  6 ++
 list-devices-linux | 20 ++--
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 8026b68..9181908 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+debian-installer-utils (1.120) UNRELEASED; urgency=medium
+
+  * Fix "list-devices partition" to also report LVM logical volumes.
+
+ -- Raphaël Hertzog   Tue, 18 Jul 2017 16:39:00 +0200
+
 debian-installer-utils (1.119) unstable; urgency=medium
 
   * fix: propagate dot-containing options to target kernel cmdline
diff --git a/list-devices-linux b/list-devices-linux
index 9eb3c71..fa9596c 100755
--- a/list-devices-linux
+++ b/list-devices-linux
@@ -38,6 +38,10 @@ device_name () {
 	echo "/dev/$name"
 }
 
+is_lvm() {
+	grep -qs ^LVM- "$1/dm/uuid"
+}
+
 is_sataraid () {
 	grep -qs ^DMRAID- "$1/dm/uuid"
 }
@@ -79,7 +83,13 @@ case $TYPE in
 	done
 	for x in /sys/block/dm-*; do
 		[ -d "$x" ] || continue
-		(is_sataraid "$x" && is_sataraid_partition "$x") || continue
+		if is_lvm "$x"; then
+			: # Keep LVM logical volumes
+		elif is_sataraid "$x" && is_sataraid_partition "$x"; then
+			: # Keep dmraid partitions
+		else
+			continue  # Skip unknown entries
+		fi
 		syspaths="${syspaths:+$syspaths }$x"
 	done
 	TYPE=disk
@@ -100,6 +110,9 @@ case $TYPE in
 			if is_sataraid "$x" && is_sataraid_partition "$x"; then
 continue
 			fi
+			if is_lvm "$x"; then
+continue
+			fi
 			;;
 		*)
 			name="$(device_name "$x")"
@@ -141,10 +154,13 @@ for x in $syspaths; do
 			match=:
 			;;
 		/block/dm-*)
-			# for now, we only understand dmraid
+			# for now, we only understand dmraid and LVM
 			if is_sataraid "/sys$devpath"; then
 match=:
 			fi
+			if is_lvm "/sys$devpath"; then
+match=:
+			fi
 			;;
 		esac
 	fi
-- 
2.13.3

Bug#841072: installation-report: failure to mount the EFI partition: IO charset ascii not found

[Raphael Hertzog]

Package: installation-reports
Version: 2.62
Severity: important

-- Package-specific info:

Boot method: USB key
Image version: 
http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
 build of 2016-10-03
Date: 2016-10-17

Machine: Lenovo Thinkpad X260

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [X]
Detect network card:[X]
Configure network:  [X]
Detect CD:  [X]
Load installer modules: [X]
Clock/timezone setup:   [X]
User/password setup:[X]
Detect hard drives: [X]
Partition hard drives:  [E]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

I have booted the installer in UEFI mode and in the partitioning step, the
installer fails to mount the EFI partition that it created:
Oct 17 19:27:31 kernel: [  325.233318] FAT-fs (sda1): IO charset ascii not found
Oct 17 19:27:46 main-menu[406]: (process:6083): mount: mounting /dev/sda1 on 
/target/boot/efi failed: Invalid argument
Oct 17 19:27:46 main-menu[406]: WARNING **: Configuring 'partman-base' failed 
with error code 2
Oct 17 19:27:46 main-menu[406]: WARNING **: Menu item 'partman-base' failed.

In fact, I'm not even sure that it did format the partition that it created.
I don't see anything like this in the syslog file. And looking in the partman
log file it rather seems like that the EFI partition is created as ext2!

I'm attaching the full log files of the installation attempt.

Cheers,

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


install-x260.tar.gz
Description: application/gzip

Bug#795537: Duplicate of 796096

[Raphael Hertzog]

Control: reassign -1 src:linux
Control: forcemerge 796096 -1

The detailed explanations are in #796096.

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#805291: preseed: Offer a way to override initrd-level preseeding with kernel command line preseeding

[Raphael Hertzog]

Hi Philip,

On Sun, 10 Jan 2016, Philip Hands wrote:
> BTW would you happen to know if the example for checksums on CDs is
> relevant any more?
> 
>   - if you're booting a remastered CD:
> preseed/file=/cdrom/preseed.cfg
> preseed/file/checksum=5da499872becccfeda2c4872f9171c3d
> 
> which is supposedly an example where one might specify the checksum for
> the CD's preseed.cfg -- it strikes me that a) this is a bit pointless
> (although it would catch corruption of the media), and b) it presumably
> doesn't work any more, because that file will already have been used by
> the time we get to the kernel parameters.

I believe you mix up file preseeding and initrd preseeding. This file
based preseeding happens after initrd preseeding and kernel parameter
preseeding.

So the above debconf entries are defined early in the process via
"env-preseed" but they are only used later by "file-preseed".

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#805291: preseed: Offer a way to override initrd-level preseeding with kernel command line preseeding

[Raphael Hertzog]

Hi,

On Tue, 17 Nov 2015, Raphael Hertzog wrote:
> On Tue, 17 Nov 2015, Philip Hands wrote:
> > It seems like it ought to be mostly harmless, and probably ought to have
> > been like that all along (it certainly makes sense to me to have the
> > harder-to-set preseeds over-ridden by the easier-to-set ones).
> > 
> > You should probably give it a try and see if anything breaks. :-)
> 
> Thanks, doing it right now on Kali as a testbed. I double checked the
> installation manual to see if it had anything to say about the precedence
> of the respective preseeding methods but I did not find anything relevant.

So I did that and you can have a try on that ISO image for example:
http://archive.kali.org/kali-daily-images/kali-linux-light-rolling-amd64.iso

(it's a live image so uses live-installer too)

It seems to work fine (no other regression detected in normal install) and
I confirm that I can override the configuration set in the initrd with the
kernel command line.

Here's the .dsc of preseed:
http://http.kali.org/pool/main/p/preseed/preseed_1.68+kali1.dsc

I just swapped the order of S30env-preseed and S35initrd-preseed.

Is there anything in particular that I should test before committing
the change?

In Debian we don't use initrd preseeding AFAIK so it can't break anything
directly. But it should probably be documented somewhere so that
(downstream) users are aware of the change. I propose to commit this
in the d-i manual at the same time:

Index: en/appendix/preseed.xml
===
--- en/appendix/preseed.xml (révision 70088)
+++ en/appendix/preseed.xml (copie de travail)
@@ -119,9 +119,12 @@
 An important difference between the preseeding methods is the point at which
 the preconfiguration file is loaded and processed. For initrd preseeding
 this is right at the start of the installation, before the first question is
-even asked. For file preseeding this is after the CD or CD image has been
-loaded. For network preseeding it is only after the network has been
-configured.
+even asked. Preseeding from the kernel command line happens just after. It is
+thus possible to override configuration set in the initrd by editing the kernel
+command line (either in the bootloader configuration or manually at boot time
+for bootloaders that allow it). For file preseeding this is after the CD
+or CD image has been loaded. For network preseeding it is only after the
+network has been configured.
 
 


Can I go ahead ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#647405: please allow pre-seeding for deb-src line

[Raphael Hertzog]

Control: tag -1 + patch

Hello,

On Wed, 02 Nov 2011, Marc Haber wrote:
> Please consider allowing this, for example by a pre-seeding option
> d-i mirror/http/source boolean

I'm working on this feature as I would like to use it in Kali. I choose to
name the option "apt-setup/enable-source-repositories" but I can rename it
to something else if needed.

Please find attached a suggested patch. I'm currently testing it and
barring any objection I will likely commit it in a few days (assuming
my tests are succesful).

In the mean time, any review is welcome.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/
>From 36c087a93529311a8dd5a38fdc4eba7c49b06d8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Tue, 17 Nov 2015 17:43:48 +0100
Subject: [PATCH] Add a new apt-setup/enable-source-repositories question

This lets the user disable "deb-src" entries for network repositories that
are listed in /etc/apt/sources.list.

This work has been loosely based on the initial patch of Anthony F.
McInerney.

Closes: #647405
---
 debian/apt-setup-udeb.templates | 10 +
 debian/changelog|  8 +++
 generators/50mirror | 11 +-
 generators/50mirror.ubuntu  | 47 +++--
 generators/91security   |  8 ++-
 generators/92updates|  8 ++-
 generators/93backports  |  8 ++-
 7 files changed, 80 insertions(+), 20 deletions(-)

diff --git a/debian/apt-setup-udeb.templates b/debian/apt-setup-udeb.templates
index b106bf2..11a62af 100644
--- a/debian/apt-setup-udeb.templates
+++ b/debian/apt-setup-udeb.templates
@@ -105,6 +105,16 @@ _Description: Services to use:
  here does not cause any of them to be installed by default; it only
  allows you to manually select backports to use.
 
+Template: apt-setup/enable-source-repositories
+Type: boolean
+Default: true
+# :sl2:
+_Description: Enable source repositories in APT?
+ By default source repositories are listed in /etc/apt/sources.list (with
+ appropriate "deb-src" lines) so that "apt-get source" works. However, if
+ you don't need this feature, you can disable those entries and save some
+ bandwith during "apt-get update" operations.
+
 Template: apt-setup/multiarch
 Type: string
 Default: @MULTIARCH@
diff --git a/debian/changelog b/debian/changelog
index bd2df23..f24a5ee 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+apt-setup (1:0.103) UNRELEASED; urgency=medium
+
+  * Add a new apt-setup/enable-source-repositories question to let the
+user disable "deb-src" entries for network repositories that
+are listed in /etc/apt/sources.list. Closes: #647405
+
+ -- Raphaël Hertzog   Tue, 17 Nov 2015 17:36:33 +0100
+
 apt-setup (1:0.102) unstable; urgency=medium
 
   [ Raphaël Hertzog ]
diff --git a/generators/50mirror b/generators/50mirror
index 4cb6bc4..05e9941 100755
--- a/generators/50mirror
+++ b/generators/50mirror
@@ -186,6 +186,9 @@ while true; do
 			fi
 		fi
 		;;
+	3)
+		db_input low apt-setup/enable-source-repositories || true
+		;;
 	*)
 		break
 		;;
@@ -252,4 +255,10 @@ while [ ! "$done" ]; do
 	fi
 done
 
-echo "deb-src $protocol://$hostname$directory $codename $dists" >> $file
+deb_src="deb-src"
+db_get apt-setup/enable-source-repositories
+if [ "$RET" = false ]; then
+	deb_src="# deb-src"
+fi
+
+echo "$deb_src $protocol://$hostname$directory $codename $dists" >> $file
diff --git a/generators/50mirror.ubuntu b/generators/50mirror.ubuntu
index 2f7c643..e029764 100755
--- a/generators/50mirror.ubuntu
+++ b/generators/50mirror.ubuntu
@@ -66,6 +66,9 @@ while :; do
 db_input low apt-setup/partner || true
 			fi
 		;;
+		6)
+			db_input low apt-setup/enable-source-repositories || true
+		;;
 		*)
 			break
 		;;
@@ -96,6 +99,12 @@ hostname="$RET"
 db_get mirror/$protocol/directory
 directory="/${RET#/}"
 
+deb_src="deb-src"
+db_get apt-setup/enable-source-repositories
+if [ "$RET" = false ]; then
+	deb_src="# deb-src"
+fi
+
 # Awful hack. Source for ports architectures is only available on
 # archive.ubuntu.com, not ports.ubuntu.com.
 if [ "$hostname" = ports.ubuntu.com ]; then
@@ -123,32 +132,34 @@ PROPOSED="$RET"
 
 cat >> $file <> $file <> $file
 if db_get apt-setup/universe && [ "$RET" = true ]; then
-	COMMENT=
+	DEB='deb'
+	DEB_SRC="$deb_src"
 else
 	cat >> $file <> $file <> $file <> $file
 if db_get apt-setup/backports && [ "$RET" = true ]; then
-	COMMENT=
+	DEB='deb'
+	DEB_SRC="$deb_src"
 else
 	cat >> $file <> $file <> $file <> $file
 	if db_get apt-setup/partner && [ "$RET" = true ]; then
-		COMMENT=
+		DEB='deb'
+		DEB_SRC="$deb_src"
 	else
 		cat >> $file <> $file 

Bug#805291: preseed: Offer a way to override initrd-level preseeding with kernel command line preseeding

[Raphael Hertzog]

On Tue, 17 Nov 2015, Philip Hands wrote:
> It seems like it ought to be mostly harmless, and probably ought to have
> been like that all along (it certainly makes sense to me to have the
> harder-to-set preseeds over-ridden by the easier-to-set ones).
> 
> You should probably give it a try and see if anything breaks. :-)

Thanks, doing it right now on Kali as a testbed. I double checked the
installation manual to see if it had anything to say about the precedence
of the respective preseeding methods but I did not find anything relevant.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#647405: please allow pre-seeding for deb-src line

[Raphael Hertzog]

On Tue, 17 Nov 2015, Christian PERRIER wrote:
> As the question is not asked during default installs (use of "low"
> prio for debconf), I'd suggest using sublevel 3 for the newly
> introduced templates --> s/:sl2:/:sl3:

OK, fixed locally, as well as a small typo (bandwith -> bandwidth).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#652987: the cdrom path is not disabled in sources.list

[Raphael Hertzog]

Control: tag -1 pending

On Thu, 22 Dec 2011, prathib...@cdac.in wrote:
> While installing debian using the live-installer package, the cdrom path
> in the sources.list exists after the completion of the installation in
> sources.list. While reloading the synaptic package manager, it shows the
> error: "Failed to load cdrom..."
> 
> A patch for resolving this issue is attached.

After having discussed the issue with the live-build maintainers (on IRC)
I have just committed a fix that does something similar to your patch.

It will thus be fixed in apt-setup 0.102 once it's released.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#702257: apt-setup: new preseed option to disable CDROM entries at the end of the install

[Raphael Hertzog]

Control: tag -1 + pending

On Wed, 29 Jul 2015, Federico Bruni wrote:
> Can you please advise about the status of this bug?

I have just committed the patch to git. It should be in the
next release (0.102).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#764030: d-i.debian.org: update url from packages.qa.debian.org to tracker.debian.org in scripts

[Raphael Hertzog]

Hi,

On Fri, 10 Jul 2015, Cyril Brulebois wrote:
 A single occurrence of packages.qa.debian.org remains, but that's a mail
 address. I'm not sure there's a corresponding one on the tracker side:
   debian-installer_...@packages.qa.debian.org
 
 I've added Raphaël to Cc to query his opinion.

That's fine. Most people are still subscribed via the old tracker
and the mail setup forwards from one to the other.

When we move subscriptions over, it will be widely announced (d-d-a).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150710075219.gb12...@home.ouaza.com

Bug#785069: jessie live-installer can't install grub when booted via usb drive without internet

[Raphael Hertzog]

On Fri, 29 May 2015, Pirate Praveen wrote:
 On Friday 29 May 2015 02:46 PM, Cyril Brulebois wrote:
  It might be useful to provide a log so that we understand what's
  happening here.
 
 Just tested with Graphical Install from boot menu and grub install is
 working. So we can mention it as a work around. I will now try live
 install again and provide logs.

What do you mean with live install? running the installer from
the graphical interface of the live system once started?

If the bug is only reproducible there, then it's not necessarily a bug
in live-installer but in debian-installer-launcher... and in the way it
interacts with the current desktop.

Cyril, don't count on me to look into this issue, I won't have the
time to handle this, sorry.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150529120621.ga26...@home.ouaza.com

Bug#774811: debian-installer: debian-testing-powerpc-netinst.iso 2015-01-05 08:58 278M doesn't boot

[Raphael Hertzog]

Hi,

Since this problem is powerpc specific, I'm putting
debian-powe...@lists.debian.org in copy and since it concerns the
bootability of an ISO image, I also add debian...@lists.debian.org.

On Wed, 07 Jan 2015, intervenant0 wrote:
 I have downloaded debian-testing-powerpc-netinst.iso 2015-01-05
 and I have burned a CD-R disk with the previous named iso.
 Then, I put the CD on my PowerMac G4 Gigabit
 Ethernet and hold on the keyboard key named Option for booting on it.
 The CD doesn't appear on boot screen. I make this twice, first with a
 CD-R from imation, then with a CD-R from maxell, same results. Then I
 have checked my CD-DVD drive by booting on my previous install CD :
 debian-7.4.0-powerpc-netinst.iso and I succeed to boot.

[ in another mail ]
 Dear Maintainer, I have continued and tried an other iso :
 debian-jessie-DI-b2-powerpc-netinst.iso
[...]
 Then, I put the
 CD on my PowerMac G4 Gigabit Ethernet and hold on the keyboard key named
 Option for booting on it. The CD doesn't appear on boot, so I have chose
 Linux logo and clicked on it. So then, I have seen displayed :
 
 First Stage Debian GNU/Linux Bootstrap
 
 Press l for GNU/Linux,
   x for MacOSX,
   c for CDROM
 
 Stage 1 Boot:
 
 End of display
 I have typed c and then the screen display following what was already
 displayed :
 
 Booting CDROM...
 DEFAULT CATCH!, code=fff6 at%SRR0:
 
 
 End of display

Does anyone have any idea why jessie ISO images would not be bootable
on an old G4 ?

Regards,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150121112111.ga1...@home.ouaza.com

Re: Bug#740998: rdnssd: merge-hook overwrites /etc/resolv.conf when /sbin/resolvconf is not installed

[Raphael Hertzog]

Control: clone -1 -2
Control: retitle -1 NetworkManager and rdnssd do not play well together
Control: retitle -2 rdnssd drops non-nameserver settings from /etc/resolv.conf 
when overwriting it
Control: severity -2 important

[ Ccing debian-boot, and in particular Colin Watson and Philipp Kern
  due to their involvment in netcfg ]

On Mon, 27 Oct 2014, Rémi Denis-Courmont wrote:
  Right now, this package got installed by default on a Jessie GNOME
  desktop and it really interacts badly with NetworkManager which
  was handling the file perfectly fine (i.e. it included already the
  IPv6 DNS servers identified by rdnsd).
 
 That *is* a problem. Indeed NetworkManager has gained support for RDNSS for a 
 long time already, and thus made completely rdnssd redundant if not counter-
 productive on a system with NetworkManager.
 
 But as far as I know, whatever caused this default is not rdnssd itself.

Yeah, I was wondering how the package got installed, but I found no
obvious explanation (no reference in tasksel, the package is not
priority = standard, no reverse dep in any other package). So I'm
assuming that it's debian-installer that decided to install this package
because it detected IPv6 connectivity.

A quick grep seems to confirm this:
netcfg-1.122/autoconfig.c:  di_exec_shell_log(apt-install 
rdnssd);

  I believe that it should do something saner instead of overwriting.
 
 I must disagree. If resolvconf is absent, overwriting is the most sane, or 
 least insane thing to do. There just is not a lot that can be done without 
 mediation for writing the resolver configuration.

Maybe the presence of NetworkManager should be considered enough of a hint
that rdnssd should do nothing ?

Or maybe you want to check that it's running with service network-manager 
status ?

Without such safeguards, assuming that you're entitled to manage
/etc/resolv.conf is not really acceptable as a default. The other alternative is
to use a low priority debconf questions Shall I manage /etc/resolv.conf? with
a default of no.

  It should verify if the file contains the DNS servers it detected
  and add them if they are missing. But it should definitely not blindly
  overwrite the file...
 
 There are currently no ways to know which entries were inserted by rdnssd 
 (possibly by a previous incantation of it) and which by other tools. 

You could store the former list of nameservers returned by rdnssd if you wanted,
and make a comparision.

 Furthermore, I doubt we can safely assume that all resolv.conf tools remove 
 their entries when uninstalled. I think this suggestion is worse than the bug 
 from a reliability perspective.

What other tools are you referring to?

I know of three sane cases:
- the admin manages /etc/resolv.conf manually
- a full-featured network manager tool handles the file alone
- specialised tools update the file by way of resolvconf

Having each specialised tool handle the file alone is not really a good option.

 Really, any pair of two tools writing resolv.conf will screw stuff up without 
 resolvconf present and supported by both tools. That problem affects ppp, 
 dhcp-
 client3, network-manager, wicd, connman, systemd(-networkd) just to name a 
 few. And I don´t dare mention most if not all VPN clients.

connman/network-manager/wicd are in conflict with each other to avoid this 
problem.

For the other tools, they are not daemons that are started automatically without
any intervention of the administrator. If they screw up /etc/resolv.conf
when you start them, you have a clear idea of what happened. Here I was rather
annoyed by the fact that the file was correct after NetworkManager started my 
connection
but that the file went bad a bit later without any clear indication of what 
happened
(thus a comment line saying that rdnssd generated the file is a good
idea too).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141028091628.gb9...@home.ouaza.com

Re: Debian installer and CD BoF: my views for jessie

[Raphael Hertzog]

Hi,

On Tue, 26 Aug 2014, Cyril Brulebois wrote:
 I might be misremembering of course but I think d-i on linux archs has
 been working more or less during the whole release cycle. (The parted

I can confirm this as I imported d-i snapshots from git into Kali to cope
with new upstream kernels that we imported too. Sometimes subsequent fix to
kernel udebs were required but apart from that, it's been working well for
us.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140827092640.gf23...@x230-buxy.home.ouaza.com

Bug#656710: partman-crypto: Preseeding the passphrase

[Raphael Hertzog]

Hi,

On Sat, 21 Jan 2012, Christian PERRIER wrote:
 Thanks for your proposal and the care you took in building a proper patch.
 
 We generally leave it up to Colin Watson to decide what Ubuntu change
 is well suited for being included in Debian, when it comes at D-I. So
 let's get his input about this.

I have been using this patch in Kali (on top of wheezy's partman-crypto),
it would be nice to have this patch merged in time for Jessie.

Dimitrijs, Max or Christian? (You ar listed in Uploaders)

Or should I just go ahead and commit it?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140730092328.ga19...@x230-buxy.home.ouaza.com

Bug#719101: netcfg: provide a clean way to change default hostname (for derivatives)

[Raphael Hertzog]

On Thu, 08 Aug 2013, Cyril Brulebois wrote:
  Unfortunately this has bad side-effects such as the impossibility to
  actually automate a PXE install because the seen flag is always reset
  to false (even if we pass hostname=kali on the kernel command line).
 
 Use hostname?=kali on the kernel command line instead?

That goes in the opposite direction. This ensures that the seen flag stays
at false. I really want seen=true so that the question is not
displayed but since the initrd contains seen=false, the seen=true set
by the early preseed from the kernel command line is reverted...

At least that's my understanding of the problem I have been experiencing.

Another solution would be to have a two-step parsing of kernel command
line preseeds, we could add !hostname=kali or something like that would
be only parsed after the initrd preseed and would thus override those set
there.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130808154233.ga17...@x230-buxy.home.ouaza.com

Bug#705599: finish-install: 07speakup needs to be updated for Wheezy and GNOME 3

[Raphael Hertzog]

Hi,

On Fri, 19 Apr 2013, Samuel Thibault wrote:
 Raphael Hertzog, le Thu 18 Apr 2013 08:27:01 +0200, a écrit :
  1/ you're setting up dbus within d-i instead of letting it happen during
 the first boot like on other installation scenarios
 
 ? I don't undesrstand this: it only sets up a temporary session just for
 setting the value.

During my tries I got this error:

error: Cannot spawn a message bus without a machine-id: Unable to load 
/var/lib/dbus/machine-id or /etc/machine-id: Failed to open file 
'/var/lib/dbus/machine-id': No such file or directory

Now you're calling dbus-launch and I expect that a side-effect of this
is to create /var/lib/dbus/machine-id.

So I'm saying that on normal install this would be created on first boot
while in install with speech synthesis it's now created within d-i.

(it might not be a big deal, but it's the kind of side effect that I prefer to 
avoid)

  3/ you change directly the user configuration instead of adjusting
 the defaults (this one is debatable since supplementary users might
 not want a11y enabled by default but this is a minor inconvenience)
 
 Yes, thus Cc-ing debian-accessibility.  I'm not sure what we really
 want.  Most often, users (other than the person who installed the system
 with braille or speech) will not want accessibility being enabled.

Yeah, but how common is the multiple users per machine scenario ?
And whatever happens, all users will have gdm with a11y enabled.

 On the other hand, just changing the default could be less surprising
 than having a configured user.
 
 But on the other hand again, having a file in
 /usr/share/glib-2.0/schemas outside of dpkg's knowledge is not a good
 thing either, and people will wonder how this script ended up there, and
 not coming from a package.

That's why I have put a clear comment on the top of the file that says
what created this file. I agree it's not perfect but the same goes for having
one user pre-configured and not the others...

I would not expect to have files in my home directory that do not come from
/etc/skel/ (except standard directories from xdg-user-dirs).

The other positive point of changing the default is that you don't have
to special case and hardcode the knowledge of the gdm user.

  4/ if the system is reconfigured so that gsettings uses something else
 than dconf as backend,
 
 Urgl, so gsettings might be storing parameters another way, depending on
 the system preference?  That, however is really a problem indeed.

Yes. That said I don't know anyone who has done it in production. The only
supported databases so far are dconf and gconf.

 Would it be possible to store a schema file somewhere in the user home?

Not that I know. I tried to look up alternative places to put the schema
override files (in /var, in /etc, etc.) but didn't find any (except if
you're ready to change XDG_DATA_DIRS system-wide).

See man glib-compile-schemas.

 Now, an issue is that while finish-install can be updated with a new
 patch without rebuilding debian-installer, brltty can not, and rc2,
 supposed to be used for 7.0.0, is already on its way.  Ideally we'd use
 the same strategy for both the speakup and the brltty installations...

Yes, I agree. That said it doesn't break anything to mix up the strategies.
Thus we can always sync for 7.0.1.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130419064858.gf6...@x230-buxy.home.ouaza.com

Bug#705599: finish-install: 07speakup needs to be updated for Wheezy and GNOME 3

[Raphael Hertzog]

On Thu, 18 Apr 2013, Samuel Thibault wrote:
 So in the end, it would rather be the attached patch, which also enables
 the screen reader.

Honestly, I prefer my patch over yours:

1/ you're setting up dbus within d-i instead of letting it happen during
   the first boot like on other installation scenarios

2/ the multiple dbus-launch means that you start multiple dbus that are
   left around during the installation (this goes against policy-rc.d
   which disables daemons on purpose)

3/ you change directly the user configuration instead of adjusting
   the defaults (this one is debatable since supplementary users might
   not want a11y enabled by default but this is a minor inconvenience)

4/ if the system is reconfigured so that gsettings uses something else
   than dconf as backend, your configuration work is useless whereas
   with my approach it's not since it's handled in a higer layer (at the
   gsettings level)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130418062701.ga23...@x230-buxy.home.ouaza.com

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Raphael Hertzog]

Hi,

On Wed, 06 Feb 2013, Bdale Garbee wrote:
 two at a time.  Holding d-i's build dependencies static in unstable for
 more than half a year is just nuts to me!  Sure seems like d-i is
 something we should build using the components of the release it will be
 contained in and not unstable... but I haven't tried to think hard about
 what that might imply that's problematic. And I certainly don't think
 this is something we should even consider changing at this late date in
 for wheezy release cycle!

Technically d-i point release updates are built in
stable-proposed-updates and build dependencies are satisfied in stable
(+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy
in testing-proposed-updates right now (and have build-deps satisfied in
wheezy). t-p-u is frowned upon for normal packages because the release
team like the testing packages get in unstable, but in the case of d-i the
only thing that needs to be tested are the installer images which end up
on the mirror and not in the package repository (the installer directories
are shared between wheezy and sid).

That said this was never done yet and we're not sure what dak
would do with the by-hand archive containing the installer images. Maybe
some ftpmasters could answer on this point?

I discussed this with Cyril and Julien and they were (rightfully IMO) not keen
on trying this at this point of the release.

That said this whole discussion is interesting and might even help up
in the long term but the real problem is that Daniel is just actively
working against the release team wishes and this is unacceptable to me.
We all know the limitations of our processes, any help to improve them
is welcome, but working against them is not acceptable.

But judging the social behaviour of a developer is not really in the realm
of the tech-ctte and the best technical outcome might not be in line with
the release team's plans.

Thus I would subject to word a resolution along the line of The tech-ctte
suggests the release team to try out this because bar, but if the release 
team
doesn't wish to try it out, then the release team has the right to upload
an older version of syslinux to unstable (given that the maintainer
deliberately ignored recommendations of the release team)..

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130207083122.ga11...@x230-buxy.home.ouaza.com

Re: Bug#699808: tech-ctte: syslinux vs the wheezy release

[Raphael Hertzog]

On Thu, 07 Feb 2013, Raphael Hertzog wrote:
 on the mirror and not in the package repository (the installer directories
 are shared between wheezy and sid).

Cyril pointed out to me that this specific point is wrong, while
wheezy/main/installer-* and unstable/main/installer-* have the same
content right now, they are not the same (and thus not shared). There's a
dak copy-installer involved to copy the installer from unstable to
wheezy.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130207092243.ga12...@x230-buxy.home.ouaza.com

live-installer important bugfix for Italian support

[Raphael Hertzog]

(Keep me on CC, I'm not on debian-boot)

Hello,

I just debugged an issue where live-installer would not work when
you opted for an Italian installation. The commit below has my explanation
of the problem and a tested fix. That said I'm not very familiar with
the internals of main-menu and this interpretation comes from my reading
of the source code, not from direct experience (main-menu's interesting
logs are commented out and since it's embedded in the initrd I couldn't
easily replace it on the live ISO used for the tests). Thus I would
appreciate a review by someone more familiar with main menu.

In particular, given my explanation of the problem, I would have expected
the problem to not be solved without changing the Italian translation but
keeping the duplicate Italian translation and reducing Installer-Menu-Item
to 6490 was enough to fix the problem.

I still fixed the Italian translation because it was the right thing to do
anyway. (Note that I fixed it in packages/po/sublevel3/it.po too...)

I believe that this fix should go into wheezy. If you want me to upload it
by myself, let me know. Otherwise I'll happily let Christian upload it.

Here's my commit:

commit 85fb0ea0b6147a62a53ec8f5c0940c8276b59145
Author: Raphaël Hertzog hert...@debian.org
Date:   Wed Feb 6 15:06:41 2013 +0100

Reduce Installer-Menu-Item to 6490 and fix Italian translation

The goal is to ensure that the udeb takes precedence over bootstrap-base.
This fixes installation from a live media in Italian. TTBOMK the
explanation is the following:

bootstrap-base and live-installer are pulled in the menu via the
installed-base virtual package that they provide. Thus the following
comment of main-menu applies:

/* Compile a list of providing package. The default choice will be the
 * package with highest priority. If we have ties, menu items are
 * preferred. If we still have ties, the default choice is arbitrary */

bootstrap-base is of priority required while live-installer is of priority
optional, but udpkg doesn't store the Priority in /var/lib/dpkg/status
thus both packages are of equal priority when main-menu compares them.
Since both packages also have Installer-Menu-Item 6500, the default choice
is supposed to be arbitrary. But even if arbitrary, the choice always
ended up selecting live-installer (as wanted) in a somewhat consistent way
across all languages, except for Italian.

As far I could understand, the reason why Italian behaves differently is
that the translation of the menu items for bootstrap-base and
live-installer are the same string Installare il sistema base and this
is thus confusing the debian-installer/missing-provide debconf prompt
which lets the user choose between both. Other translations have different
strings (and the underlying English strings are also different Install
the base system vs Install the system).

diff --git a/debian/changelog b/debian/changelog
index 4562746..7af70a6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+live-installer (40) UNRELEASED; urgency=low
+
+  * Reduce Installer-Menu-Item to 6490 to take precedence over
+bootstrap-base in the ordering computed by d-i's main-menu.
+  * Change Italian translation of Install the system to something
+else than base-installer's Italian translation of Install the base
+system (“Installare il sistema base” → “Installare il sistema”) to
+avoid confusing debconf with a list of two identical entries.
+
+ -- Raphaël Hertzog hert...@debian.org  Tue, 05 Feb 2013 18:35:23 +0100
+
 live-installer (39) unstable; urgency=low
 
   [ Raphaël Hertzog ]
diff --git a/debian/control b/debian/control
index d29aacf..9854c50 100644
--- a/debian/control
+++ b/debian/control
@@ -17,5 +17,5 @@ Depends:
  ${shlibs:Depends}, archdetect, base-installer (= 1.105),
  busybox-udeb (= 1:1.13.3), cdebconf-udeb, created-fstab, mounted-partitions
 Provides: installed-base, kernel-installer
-XB-Installer-Menu-Item: 6500
+XB-Installer-Menu-Item: 6490
 Description: Install the system
diff --git a/debian/po/it.po b/debian/po/it.po
index c228831..b9edced 100644
--- a/debian/po/it.po
+++ b/debian/po/it.po
@@ -53,14 +53,14 @@ msgstr 
 #. :sl3:
 #: ../live-installer.templates:1001
 msgid Install the system
-msgstr Installare il sistema base
+msgstr Installare il sistema
 
 #. Type: text
 #. Description
 #. :sl3:
 #: ../live-installer.templates:2001
 msgid Installing the system...
-msgstr Installazione del sistema base...
+msgstr Installazione del sistema...
 
 #. Type: text
 #. Description
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 

Bug#673328: live-installer does not preserve /var/log; breaks freeradius

[Raphael Hertzog]

retitle 673328 fix live-installer to properly detect errors during tar 
extraction
thanks

On Thu, 06 Dec 2012, Raphael Hertzog wrote:
 I had a similar problem and it's probably the same as #652946.

So instead of reassigning it and merging it, we will repurpose
this bug to track the problem that live-installer sometimes
doesn't detect the underlying tar failure and lets the installation
proceed while in fact not all files have been copied.

The problem lies somewhere in this bit of code:

exec 40
tar c . | \
(chdir /target  tar xv) | \
(
while read line; do
COUNT=$(($COUNT + 1))
CURRENT=$(($COUNT * 100 / $STEPS))

[ x$CURRENT = x$LAST_UPDATE ]  continue

LAST_UPDATE=$CURRENT
db_progress STEP 1 4
done
)
exec 04

The exit code of the pipeline is the one of the last command, i.e. the big
parenthese. So maybe we could add a check after the loop to verify that
$COUNT = $STEPS and exit with an error code otherwise ?

[ $COUNT -ge $STEPS ] || exit 1

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121207102720.ga9...@x230-buxy.home.ouaza.com