Re: Backport fix for #789600?

[Cyril Brulebois]

Steve McIntyre  (2015-11-27):
> Yup, makes sense. I'll double-check the latest daily later on when I'm
> home.

Except daily builds are missing; investigating.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Backport fix for #789600?

[Cyril Brulebois]

Steve McIntyre  (2015-11-27):
> AFAICS it should just work (TM) - the existing code there is just
> listing on the grub-mkimage command line the modules that we want
> built-in. As we're already clearly using part_msdos, part_gpt is built
> at the same level so should get picked up in the same way.

OK. Would still love to see a confirmation that it's actually working
before pushing this to the jessie branch.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Backport fix for #789600?

[Steve McIntyre]

On Fri, Nov 27, 2015 at 01:57:28AM +0100, Cyril Brulebois wrote:
>Steve McIntyre  (2015-11-26):
>> I've pushed a trivial fix for this today, so new unstable/testing
>> d-i builds should be more useful for folks on GPT media. What do you
>> think about adding this for new Jessie builds? (And how's the best way
>> to do that?)
>
>Ah, I initially looked at debian-cd, but that's just debian-installer.
>Apart from a missing changelog entry, I'm happy to cherry-pick the said
>commit into the jessie branch for a later upload for a point release:
>| commit c9e26e4e97b72fefd6c1ea894aba33750fdded53
>| Author: Steve McIntyre 
>| Date:   Thu Nov 26 16:20:37 2015 +
>| 
>| Add the part_gpt module into the core grub image
>| 
>| Make it easier for users doing slightly different things with our
>| images; include support for GPT partition tables as well as msdos
>| Closes: #789600
>| 
>
>I'm not familiar with this area. Is it sufficient to add it to some
>search command to make it available? I mean: will the grub module be
>where it's expected, or is some pre-existing copy step needed for that
>to work? (I see it's available in various grub-* packages, and a
>suitable grub-* package will likely be installed at this point, so I
>suppose the addition to the search command might be sufficient, but
>let's be sure.)

AFAICS it should just work (TM) - the existing code there is just
listing on the grub-mkimage command line the modules that we want
built-in. As we're already clearly using part_msdos, part_gpt is built
at the same level so should get picked up in the same way.

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

Processing of base-installer_1.158_i386.changes

[Debian FTP Masters]

base-installer_1.158_i386.changes uploaded successfully to localhost
along with the files:
  base-installer_1.158.dsc
  base-installer_1.158.tar.xz
  base-installer_1.158_all.udeb
  bootstrap-base_1.158_i386.udeb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)

Processing of base-installer_1.158_i386.changes

[Debian FTP Masters]

base-installer_1.158_i386.changes uploaded successfully to ftp-master.debian.org
along with the files:
  base-installer_1.158.dsc
  base-installer_1.158.tar.xz
  base-installer_1.158_all.udeb
  bootstrap-base_1.158_i386.udeb

Greetings,

Your Debian queue daemon (running on host coccia.debian.org)

Bug#806443: disk-detect/multipath: default path selector is not loaded

[Hendrik Brueckner]

On Fri, Nov 27, 2015 at 03:33:39PM +, Ben Hutchings wrote:
> On Fri, 2015-11-27 at 15:39 +0100, Hendrik Brueckner wrote:
> [...]
> > --- a/disk-detect.sh
> > +++ b/disk-detect.sh
> > @@ -202,7 +202,7 @@ fi
> >  db_get disk-detect/multipath/enable
> >  if [ "$RET" = true ]; then
> >  >  > if anna-install multipath-udeb; then
> > ->  >   > MODULES="dm-mod dm-multipath dm-round-robin dm-emc"
> > +>  >   > MODULES="dm-mod dm-multipath dm-service-time dm-round-robin 
> > dm-emc"
> >  >  >   > # We need some dm modules...
> >  >  >   > depmod -a >/dev/null 2>&1 || true
> >  >  >   > for MODULE in $MODULES; do
> 
> At least dm-service-time and dm-round-robin will be automatically
> loaded by the kernel when needed.  I'm not sure about the others.

Just tried it out... the dm-multipath must be loaded manually, otherwise:

~ # multipath
Nov 27 16:42:37 | DM multipath kernel driver not loaded

~ # modprobe dm-multipath
~ # multipath
create: 36005076307ffc5e382db undef IBM,2107900
size=20G features='0' hwhandler='0' wp=undef
`-+- policy='round-robin 0' prio=1 status=undef
  |- 0:0:0:1088110722 sda 8:0   undef ready running
  `- 1:0:0:1088110722 sde 8:64  undef ready running

Loading the module and running multipath automatically loads the other
kernel modules:

~ # lsmod
Module  Size  Used by
dm_round_robin 16384  4
dm_multipath   32768  5 dm_round_robin
scsi_dh20480  1 dm_multipath
dm_mod139264  5 dm_multipath
sd_mod 49152  8
qeth_l245056  1
fuse  122880  0
qeth  122880  1 qeth_l2
ccwgroup   20480  1 qeth
zfcp  122880  8
scsi_transport_fc  69632  1 zfcp
scsi_mod  241664  4 zfcp,scsi_transport_fc,scsi_dh,sd_mod
dasd_eckd_mod 110592  0
dasd_mod   98304  1 dasd_eckd_mod

multipath automatically tries to load its default path selector module.  In
the example, I modified the multipath.conf to use round-robin.

So strictly this patch is not necessary but at least consistent regarding
the manual loading of the other modules.  I leave the change up to the
maintainer of the hw-detect/disk-detect package.

Thanks for your help.

Kind regards,
  Hendrik


pgpo4MzMgypJ0.pgp
Description: PGP signature

Re: Backport fix for #789600?

[Steve McIntyre]

On Fri, Nov 27, 2015 at 05:34:58PM +0100, Cyril Brulebois wrote:
>Steve McIntyre  (2015-11-27):
>> AFAICS it should just work (TM) - the existing code there is just
>> listing on the grub-mkimage command line the modules that we want
>> built-in. As we're already clearly using part_msdos, part_gpt is built
>> at the same level so should get picked up in the same way.
>
>OK. Would still love to see a confirmation that it's actually working
>before pushing this to the jessie branch.

Yup, makes sense. I'll double-check the latest daily later on when I'm
home.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

base-installer_1.158_i386.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 27 Nov 2015 07:13:36 +0100
Source: base-installer
Binary: base-installer bootstrap-base
Architecture: source all i386
Version: 1.158
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Christian Perrier 
Description:
 base-installer - base system installation framework (udeb)
 bootstrap-base - Install the base system (udeb)
Closes: 806218
Changes:
 base-installer (1.158) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Use -arch variant for both dh_install and dh_installdebconf overrides,
 fixing FTBFS with -A (Closes: #806218).
Checksums-Sha1:
 f03888bc8c0199f0a37ecbd96e2e7189419d7057 1897 base-installer_1.158.dsc
 9120105587e85fdf7e3ad673145f9738a8967d6e 254496 base-installer_1.158.tar.xz
 c070dbe68dfdc4a87022fce275e13556dffe49cd 47536 base-installer_1.158_all.udeb
 d338f93a704366e8321f51335560e2ed2ca4faca 195350 bootstrap-base_1.158_i386.udeb
Checksums-Sha256:
 1ca3da6d20aacdfa7bb487750857f7b80ef8517f21008075c0c80d4a71dd6258 1897 
base-installer_1.158.dsc
 86336225965c5f95f74ed3c1fe2d11a43e310be3f789fa7b75a155e011ee174a 254496 
base-installer_1.158.tar.xz
 905e90aff1cfd09c630807affd4026b78bc9b6e0c9aa73f9c7c7e0455934f6e9 47536 
base-installer_1.158_all.udeb
 84cebf3f814eb9720655b495a41d81a2e9f63d9b514f3866cf7787899a611cd5 195350 
bootstrap-base_1.158_i386.udeb
Files:
 f4841ec80a8b9e43196536b03c5c5854 1897 debian-installer required 
base-installer_1.158.dsc
 d2213d12674613c24e0d69773ba592c9 254496 debian-installer required 
base-installer_1.158.tar.xz
 11ad097bd66a6aac6fcac4f2756b538a 47536 debian-installer required 
base-installer_1.158_all.udeb
 6fbb2d61eab44ecda13f96323a35760e 195350 debian-installer required 
bootstrap-base_1.158_i386.udeb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWWIrIAAoJEIcvcCxNbiWoTYAP/2DZI/GPqp0vBK2OYw7TTgTi
pipLaLQkMChOk+MIA3Dx3UtAFmg3SLUUcLDYKxWhjNUP33IyTAkgEqueUa3GcOMi
VmwvrlGZPP3migM9QN3T7ffd6tChBlqDpJ7s/sBgugz/6TApWsJYFilxKesaRBEK
XMJqjFDE7GtY7ltEU4LozjSc2eI4ndgnoX3qjR4hyS/k8niHbE44lCqmdDSypj/K
tEbh72FvJjMc7JKAb0Hw7kOzFUS8UM5GoGfytYUF7CNrVuu3X/+srvxYD8YJuGkM
Y46vEPm0rUJ1DMfM/7KpcRwfCKE9MZFg4dMsDkY+XlOreplrUx0pAWMHxINOJilC
x2uXd4P+MhpQ5PqGyMhIch9mJa0Q2IKGEyFGyBivZxFvnRR+ReIlSFqnvSsyk6iU
9At48GzQsXRHzN+hRgZxx9PLU5C7ocNRBJtpPP7uGVLg4UxxIX4rre/SMyVQu9mj
x+H5HoRvKx0GX165o7VKXbIbik6csTNOv4oPyxuGuvaluvQGDndL7AoDPSc5FZoC
jz8LX0PRci2yvwZSQYh2apQVKnu6TJmnrWbs1d26thEvuI0AtXzmfsIcK5UmH/s1
ZC9hTNLNCM+j1QUXA/h8GAZJKwVN6QQUmji7qjHYAb/rYxendAVaJCdfXBz9DL4s
+vHCFVJI4xOvPd1vm6wT
=Lvx9
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Bug#806218: marked as done (base-installer: FTBFS when built with dpkg-buildpackage -A (Directory nonexistent))

[Debian Bug Tracking System]

Your message dated Fri, 27 Nov 2015 17:04:00 +
with message-id 
and subject line Bug#806218: fixed in base-installer 1.158
has caused the Debian Bug report #806218,
regarding base-installer: FTBFS when built with dpkg-buildpackage -A (Directory 
nonexistent)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
806218: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806218
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:base-installer
Version: 1.157
User: sanv...@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:


[...]
 debian/rules build-indep
dh build-indep
   dh_testdir -i
   dh_auto_configure -i
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
debian/templates-build.pl amd64 < debian/templates-arch > debian/templates.gen
# give the new templates file the same mtime as the input file, so
# that po2debconf doesn't decide that it needs to run
# debconf-updatepo
touch -mr debian/templates-arch debian/templates.gen
/usr/bin/make small 

[... snipped ...]

armeb: 6 passes, 0 failures.
armel: 92 passes, 0 failures.
armhf: 104 passes, 0 failures.
hppa: 36 passes, 0 failures.
i386: 314 passes, 0 failures.
ia64: 22 passes, 0 failures.
m68k: 14 passes, 0 failures.
mips: 97 passes, 0 failures.
mipsel: 85 passes, 0 failures.
powerpc: 134 passes, 0 failures.
ppc64el: 16 passes, 0 failures.
s390x: 7 passes, 0 failures.
sh4: 20 passes, 0 failures.
sparc: 36 passes, 0 failures.
kfreebsd-amd64: 16 passes, 0 failures.
kfreebsd-i386: 32 passes, 0 failures.
make[2]: Leaving directory '/<>/kernel'
make[1]: Leaving directory '/<>'
 fakeroot debian/rules binary-indep
dh binary-indep
   dh_testroot -i
   dh_prep -i
   dh_auto_install -i
   debian/rules override_dh_install
make[1]: Entering directory '/<>'
dh_install
if [ -e "kernel/amd64.sh" ]; then \
install -D -m644 "kernel/amd64.sh" \
 
debian/bootstrap-base/usr/lib/base-installer/kernel.sh; \
fi
make[1]: Leaving directory '/<>'
   dh_installdocs -i
   dh_installchangelogs -i
   debian/rules override_dh_installdebconf
make[1]: Entering directory '/<>'
dh_installdebconf
(echo ; cat debian/templates.gen) >> debian/bootstrap-base/DEBIAN/templates
/bin/sh: 1: cannot create debian/bootstrap-base/DEBIAN/templates: Directory 
nonexistent
debian/rules:40: recipe for target 'override_dh_installdebconf' failed
make[1]: *** [override_dh_installdebconf] Error 2
make[1]: Leaving directory '/<>'
debian/rules:3: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit 
status 2


Sorry not to have a fix, as I am reporting many bugs similar to
this one.

In this case, I see that you are using "dh", which allow
(independently) optional targets override_dh_foo-arch and
override_dh_foo-indep (for several values of "foo").

Maybe using them this problem could be fixed.

Once that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, the package would be suitable to be uploaded in source-only
form if you wish.

Thanks.
--- End Message ---
--- Begin Message ---
Source: base-installer
Source-Version: 1.158

We believe that the bug you reported is fixed in the latest version of
base-installer, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 806...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Christian Perrier  (supplier of updated base-installer 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 27 Nov 2015 07:13:36 +0100
Source: base-installer
Binary: base-installer bootstrap-base
Architecture: source all i386
Version: 1.158
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: 

Bug#806443: disk-detect/multipath: default path selector is not loaded

[Hendrik Brueckner]

Package: disk-detect
Version: 1.114
Severity: normal
Tags: d-i patch

Dear Maintainers,

I am about to configure and install on multipath devices.
The multipath program can create mappings but fails to load
the mappings into the kernel.  The problem is that the mulitpath
program included in multipath-udeb_0.5.0+git1.656f8865 uses the
service-time as default path selector for some time.
See also git commit:

https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/libmultipath/defaults.h?id=1bcf07988d7dc026099242a2a787178fdd27f8d1

The attached patch updates the disk-detect.sh script to the
dm-service-time.ko kernel module.  Note that I have already
opened the below Debian bug to include the dm-service-time.ko
module into the multipath-module package:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806131

So this bug report slightly depends on the above.

A possible workaround is to create the multipath.conf file with
round-robin as default path selector.  This might be a good choice
for a jessie backport if it is required.

Thanks and kind regards,
  Hendrik

-- 
Hendrik Brueckner
brueck...@linux.vnet.ibm.com  | IBM Deutschland Research & Development GmbH
Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen
>From aab885128205ce9a29741e3c8578d4b79e9d3d88 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner 
Date: Fri, 27 Nov 2015 11:28:05 +0100
Subject: [PATCH] disk-detect/multipath: load service-time path selector module

Load the dm-service-time.ko kernel module to make the service-time path
selector available.  Note that service-time is the default path selector
for some years.

See also
https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/libmultipath/defaults.h?id=1bcf07988d7dc026099242a2a787178fdd27f8d1

Depends on Debian Bug #806131

Signed-off-by: Hendrik Brueckner 
---
 disk-detect.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/disk-detect.sh b/disk-detect.sh
index 8498f4f..88f67c6 100755
--- a/disk-detect.sh
+++ b/disk-detect.sh
@@ -202,7 +202,7 @@ fi
 db_get disk-detect/multipath/enable
 if [ "$RET" = true ]; then
if anna-install multipath-udeb; then
-   MODULES="dm-mod dm-multipath dm-round-robin dm-emc"
+   MODULES="dm-mod dm-multipath dm-service-time dm-round-robin 
dm-emc"
# We need some dm modules...
depmod -a >/dev/null 2>&1 || true
for MODULE in $MODULES; do
-- 
2.6.2

Re: More cdebconf improvements

[Regis Boudin]

Hi again,

On 17/11/15 00:07, Cyril Brulebois wrote:
> Regis Boudin  (2015-11-16):
>> That's a different patch indeed, which I won't push without a minimum of
>> coordination as it changes the API/ABI of the plugin inteface. Also the
>> patch is more intrusive, and I would probably need to review it again
>> before pushing it.
> 
> OK, thanks for confirming/clarifying. Feel free to push to a
> pu/$something branch once you have polished it for review and
> coordination.

So, I've split the patchinto several bits, which I pushed under
pu/qflags. The most critical commit is
2cebed019dde395db6432ed1232db144da3c004b, which converts question.flags
from uint to a linked list of strings. The reason being that there is no
limit in the spec to which flags might or might not exist, nor is there
such limitation in the perl implementation. This is what caused #666530.
As we discussed at Debconf, the main issue with this patch is that it
changes the API/ABI for the plugins. Fortunately, the plugins
(cdebconf-terminal and cdebconf-entropy) don't use this parameter in the
structure, so a simple binNMU would be enough.

It also breaks the text db format ; but I don't believe this one is
actually used anyway, as it's only build for non-d-i, is not the one
used by default, and I doubt anyone has bothered changing it.

Besides the missing debconf-apt-progress, this is the only remaining
difference with the perl implementation I'm aware of.

For curious people, I've attached my patch to debootstrap, which checks
for the DEBOOTSTRAP_USE_CDEBCONF environment veriable to run cdebconf
instead of debconf from the beginning.

I think that's enough rambling for now. As usual, any comments/feedback
is very welcome. And don't worry too much if I'm not very responsive, as
I'll be moving a lot over the next month.

Regis
From ea2b242f48749e42f373ed46b4afbcbea9b90299 Mon Sep 17 00:00:00 2001
From: Regis Boudin 
Date: Thu, 26 Apr 2012 20:52:50 +0200
Subject: [PATCH] Check environment variable to force use of cdebconf

If DEBOOTSTRAP_USE_CDEBCONF is set, force cdebconf as part of the required
packages, and set DEBCONF_USE_CDEBCONF during bootstrap
---
 scripts/sid | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/scripts/sid b/scripts/sid
index bf3404f..3509e61 100644
--- a/scripts/sid
+++ b/scripts/sid
@@ -18,6 +18,10 @@ esac
 work_out_debs () {
 	required="$(get_debs Priority: required)"
 
+	if [ "$DEBOOTSTRAP_USE_CDEBCONF" ]; then
+		required="$required cdebconf"
+	fi
+
 	if doing_variant - || doing_variant fakechroot; then
 		#required="$required $(get_debs Priority: important)"
 		#  ^^ should be getting debconf here somehow maybe
@@ -96,6 +100,13 @@ second_stage_install () {
 	DEBCONF_NONINTERACTIVE_SEEN=true
 	export DEBIAN_FRONTEND DEBCONF_NONINTERACTIVE_SEEN
 
+	if [ "$DEBOOTSTRAP_USE_CDEBCONF" ]; then
+		DEBCONF_USE_CDEBCONF=1
+		export DEBCONF_USE_CDEBCONF
+	else
+		unset DEBCONF_USE_CDEBCONF
+	fi
+
 	baseprog=0
 	bases=7
 
@@ -199,6 +210,10 @@ echo \"Warning: Fake start-stop-daemon called, doing nothing\"" > "$TARGET/sbin/
 	mv "$TARGET/sbin/start-stop-daemon.REAL" "$TARGET/sbin/start-stop-daemon"
 	rm -f "$TARGET/usr/sbin/policy-rc.d"
 
+	if [ "$DEBOOTSTRAP_USE_CDEBCONF" ]; then
+		echo "DEBCONF_USE_CDEBCONF=1" > "$TARGET/etc/profile.d/use_cdebconf.sh"
+	fi
+
 	progress $bases $bases CONFBASE "Configuring base system"
 	info BASESUCCESS "Base system installed successfully."
 }
-- 
2.6.2

Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?

[David Kalnischkies]

On Sat, Nov 28, 2015 at 12:30:52AM +0100, Cyril Brulebois wrote:
> Now if I log out of the schroot session, remove my user 'kibi' from the
> cdrom group and re-enter a schroot session, I'm now getting a failure on
> the next group:
> | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build 
> build_netboot-gtk USE_UDEBS_FROM=sid 
> | make: Entering directory '/home/kibi/debian-installer/installer/build'
> | Using generated sources.list.udeb:
> |deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ 
> localudebs/
> |deb http://localhost/debian sid main/debian-installer
> | make[2]: 'sources.list.udeb' is up to date.
> | Reading package lists... Done
> | E: Method gave invalid 400 URI Failure message: Could not switch group, 
> user _apt is still in group 25
> | E: Method gave invalid 400 URI Failure message: Could not switch group, 
> user _apt is still in group 25
> | E: Method copy has died unexpectedly!
> | E: Sub-process copy returned an error code (112)
> | 
> | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ getent group floppy
> | floppy:x:25:kibi
> | 
> | (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ groups
> | kibi floppy audio dip video plugdev sbuild kvm libvirt
> 
> Iterating again, I'm now failing because of the audio group…

Mhh. apt is run as root (as we don't reach this codepath with uid !=
0), but it has all the groups of kibi and a setgroups is silently
ignored… wtf…

The code is if someone wants to look:
https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc#n2264
I will go to bed now, maybe I have an epiphany tomorrow.
(or manage to reproduce this for a start)


> While I've been experimenting with adding/removing myself from the said
> groups, I'm noticed this a few times, without being able to figure out
> what exactly causes this…
> | W: No sandbox user '_apt' on the system, can not drop privileges
> 
> In which case, going back to apt.git and "sudo debi -u" to reinstall all
> packages I've built seems to fix the issue.

As mentioned briefly schroot copies users & groups from your host
system, so if your host system has no _apt user, the _apt user in your
schroot will "disappear" next time it is copied over.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?

[Cyril Brulebois]

David Kalnischkies  (2015-11-28):
> Mhh. apt is run as root (as we don't reach this codepath with uid !=
> 0), but it has all the groups of kibi and a setgroups is silently
> ignored… wtf…

Hmmm, there's fakeroot in the middle!

| ifneq ($(shell id -u),0)
|   ROOTCMD ?= fakeroot
| endif
| 
| # Useful command sequences
| define submake
|   $(ROOTCMD) $(MAKE) --no-print-directory -j1
| endef

which probably explains why copying/pasting the command line worked,
as opposed to running make and submakes, the last ones being under
fakeroot?

> The code is if someone wants to look:
> https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/contrib/fileutl.cc#n2264
> I will go to bed now, maybe I have an epiphany tomorrow.
> (or manage to reproduce this for a start)
> 
> 
> > While I've been experimenting with adding/removing myself from the said
> > groups, I'm noticed this a few times, without being able to figure out
> > what exactly causes this…
> > | W: No sandbox user '_apt' on the system, can not drop privileges
> > 
> > In which case, going back to apt.git and "sudo debi -u" to reinstall all
> > packages I've built seems to fix the issue.
> 
> As mentioned briefly schroot copies users & groups from your host
> system, so if your host system has no _apt user, the _apt user in your
> schroot will "disappear" next time it is copied over.

Ah, right. That explains why running adduser/deluser from within/outside
the chroot made little difference, given the culprit was my leaving and
re-entering the chroot session… I'm not sure how buildds are set up, and
whether _apt will stick there (not really a reasonable hour to go look it
up though); there are different flavours/profiles in the sbuild and
schroot worlds anyway, so hopefully that's going to “just work”.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Broken EFI grub.cfg on stretch images

[Cyril Brulebois]

Samuel Thibault  (2015-11-27):
> That looks like the trigger, yes, because it restores spk.cfg.  I
> hadn't noticed that ./util/syslinux-cfgs lists *all* .cfg files when
> used for cdrom targets.  I have now blacklisted spk.cfg there.  I
> agree that this is less than ideal, but this is a consequence of the
> choice of putting the initrd of gtk-only netboot images at the root
> instead of gtk/ Perhaps that could be changed?

Are we talking about possibly moving stuff from:
 - build/tmp/netboot-gtk/ to build/tmp/netboot/gtk?
 - build/tmp/netboot-gtk/ to build/tmp/netboot-gtk/gtk?

where stuff means initrd.gz (only)?

I'm not too fond of moving files around, especially since serving the
right files from the right places is sometimes hard/long to set up; so
I don't think you're “less than ideal” commit as you call it is too bad.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#805321: [Reproducible-builds] Bug#805321: debian-installer: builds unreproducible netboot images

[Steven Chamberlain]

Hi,

Cyril Brulebois wrote:
> I've cherry-picked 3 patches from there onto master locally and I'm
> currently running diffoscope to see how that goes (and it's taking
> ages…):

I'm guessing the initrd would differ if the Linux tool to generate it
stores timestamps.  If its compressed size varies much due to those
differences, the .iso block numbers may vary as a result.

> FWIW, I'm not exactly entirely convinced by the exporting of the
> SOURCE_DATE_EPOCH variable from debian/rules; all other variables have
> been passed without exporting so I'm wondering if we shouldn't adapt
> this to behave like other variables, reducing possible surprise for
> users.

Just to explain that -- if it's defined in the environment, it requires
no special handling and doesn't need to be (re-)exported.  I think this
is maybe the case now for dpkg-buildpackage in sid?

If the dpkg-buildpackage environment doesn't have SOURCE_DATE_EPOCH
(e.g. jessie), debian/rules sets it to the correct value, and so must
export that.

Or (for jessie or sid), in case build/Makefile is used directly, outside
of a package build, we set SOURCE_DATE_EPOCH to a dummy value ("now") if
undefined (since ../debian/changelog may not exist), which we need
when calling makefs from within that Makefile.  We export it for use by
gen-tarball to avoid duplication there.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?

[Cyril Brulebois]

David Kalnischkies  (2015-11-27):
> On Fri, Nov 27, 2015 at 09:08:35PM +0100, Cyril Brulebois wrote:
> > | E: Method gave invalid 400 URI Failure message: Could not get new groups 
> > - getgroups (22: Invalid argument)
> > | E: Method copy has died unexpectedly!
> > | E: Sub-process copy returned an error code (112)

[ BTW, for completeness, the bug report I had in mind was filed against
sbuild rather than schroot: https://bugs.debian.org/728422 ]

> So, getgroups gets called there to verify that we really lost all groups
> (beside the one _apt is in: nogroup). A few lines above we set the list
> of (supplementary) groups containing only this group, then we switch uid
> and gid (the later isn't enough for group switching aka we would be
> still in root without the setgroups before).
> 
> So, us calling getgroups should really only return one group. Getting an
> EINVAL suggests we get more than one… that is probably bad, but I have
> a slight glimmer of hope that its just two times the same group – even
> if that makes no sense… anyway, I can't reproduce this at the moment, so
> it would be nice if someone could try the attached patch which could at
> least tell us in which groups we remain (or it just works if we really
> see duplicated groups here). Everything is possible I guess.

ACK, will test in a few moments.

> Given that schroot is involved mentioning if your host has an _apt user
> or not might also help. As I learned today schroot is copying users and
> groups into the schroot which makes all of this kinda strange… (#565613)
> [two years of testing and you are still surprised on release…]
> 
> btw: To not block anyone: You can use the config option
> Debug::NoDropPrivs to true to disable privilege dropping for the moment.

Thanks, I'll try that and maybe temporarily switch debian-installer to
using it so that we get our daily builds back until the apt side is
figured out.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?

[Cyril Brulebois]

Cyril Brulebois  (2015-11-27):
> ACK, will test in a few moments.

Results:
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build 
build_netboot-gtk USE_UDEBS_FROM=sid 
| make: Entering directory '/home/kibi/debian-installer/installer/build'
| Using generated sources.list.udeb:
|deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ 
localudebs/
|deb http://localhost/debian sid main/debian-installer
| make[2]: 'sources.list.udeb' is up to date.
| Reading package lists... Done
| E: Method gave invalid 400 URI Failure message: Could not switch group, user 
_apt is still in group 24
| E: Method gave invalid 400 URI Failure message: Could not switch group, user 
_apt is still in group 24
| E: Method copy has died unexpectedly!
| E: Sub-process copy returned an error code (112)
| E: Method http has died unexpectedly!
| E: Sub-process http returned an error code (112)
| 
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ getent group cdrom
| cdrom:x:24:kibi
| 
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ groups
| kibi cdrom floppy audio dip video plugdev sbuild kvm libvirt

so this seems to be failing with the first non-primary group?

Now if I log out of the schroot session, remove my user 'kibi' from the
cdrom group and re-enter a schroot session, I'm now getting a failure on
the next group:
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build 
build_netboot-gtk USE_UDEBS_FROM=sid 
| make: Entering directory '/home/kibi/debian-installer/installer/build'
| Using generated sources.list.udeb:
|deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ 
localudebs/
|deb http://localhost/debian sid main/debian-installer
| make[2]: 'sources.list.udeb' is up to date.
| Reading package lists... Done
| E: Method gave invalid 400 URI Failure message: Could not switch group, user 
_apt is still in group 25
| E: Method gave invalid 400 URI Failure message: Could not switch group, user 
_apt is still in group 25
| E: Method copy has died unexpectedly!
| E: Sub-process copy returned an error code (112)
| 
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ getent group floppy
| floppy:x:25:kibi
| 
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ groups
| kibi floppy audio dip video plugdev sbuild kvm libvirt

Iterating again, I'm now failing because of the audio group…



While I've been experimenting with adding/removing myself from the said
groups, I'm noticed this a few times, without being able to figure out
what exactly causes this…
| W: No sandbox user '_apt' on the system, can not drop privileges

In which case, going back to apt.git and "sudo debi -u" to reinstall all
packages I've built seems to fix the issue.

> > Given that schroot is involved mentioning if your host has an _apt user
> > or not might also help. As I learned today schroot is copying users and
> > groups into the schroot which makes all of this kinda strange… (#565613)
> > [two years of testing and you are still surprised on release…]
> > 
> > btw: To not block anyone: You can use the config option
> > Debug::NoDropPrivs to true to disable privilege dropping for the moment.
> 
> Thanks, I'll try that and maybe temporarily switch debian-installer to
> using it so that we get our daily builds back until the apt side is
> figured out.

This seems to work fine as a last resort option, thanks.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Broken EFI grub.cfg on stretch images

[Samuel Thibault]

Hello,

Cyril Brulebois, on Thu 26 Nov 2015 01:31:19 +0100, wrote:
> Steve McIntyre  (2015-11-26):
> > KiBi/Didier: I've now noticed the there's a slight issue with the
> > menus we have at the moment. Not sure if it's an artifact of the
> > multi-arch setup or not, but in the menus we're now getting two
> > different versions of the installer with speech both veing shown with
> > the exact same label text and the same shortcut:
> > 
> > label installspk
> > menu label Install with ^speech synthesis
> > kernel /install.amd/vmlinuz
> > append vga=788 initrd=/install.amd/initrd.gz speakup.synth=soft --- 
> > quiet 
> > 
> > label installspk
> > menu label Install with ^speech synthesis
> > kernel /install.amd/vmlinuz
> > append vga=788 initrd=/install.amd/gtk/initrd.gz speakup.synth=soft 
> > --- quiet 
> > 
> > and this is showing up in the grub menus I'm generating too. We should
> > probably just pick one that we want?
> 
> Wild guess, side effect of the following commit (src:debian-installer)?
> | commit d14db6ad4079b3e4d996f67ffd36292b18e6b15b
> | Author: Samuel Thibault 
> | Date:   Tue Sep 15 01:31:14 2015 +0200
> | 
> | Restore actually-used non-gtk speech synthesis entries
> | 
> | - Otherwise netboot/gtk/mini.iso (which is gtk only) does not 
> contain the
> |   speech entry.
> | - Avoid including them on non-gtk netboot image, though.
> 
> https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?id=d14db6ad4079b3e4d996f67ffd36292b18e6b15b
> 
> (Adding youpi to the loop accordingly.)

Thanks for the Cc.  That looks like the trigger, yes, because it
restores spk.cfg.  I hadn't noticed that ./util/syslinux-cfgs lists
*all* .cfg files when used for cdrom targets.  I have now blacklisted
spk.cfg there.  I agree that this is less than ideal, but this is a
consequence of the choice of putting the initrd of gtk-only netboot
images at the root instead of gtk/ Perhaps that could be changed?

Samuel

Re: Broken EFI grub.cfg on stretch images

[Samuel Thibault]

Cyril Brulebois, on Fri 27 Nov 2015 23:32:03 +0100, wrote:
> Samuel Thibault  (2015-11-27):
> > That looks like the trigger, yes, because it restores spk.cfg.  I
> > hadn't noticed that ./util/syslinux-cfgs lists *all* .cfg files when
> > used for cdrom targets.  I have now blacklisted spk.cfg there.  I
> > agree that this is less than ideal, but this is a consequence of the
> > choice of putting the initrd of gtk-only netboot images at the root
> > instead of gtk/ Perhaps that could be changed?
> 
> Are we talking about possibly moving stuff from:
>  - build/tmp/netboot-gtk/ to build/tmp/netboot/gtk?
>  - build/tmp/netboot-gtk/ to build/tmp/netboot-gtk/gtk?
> 
> where stuff means initrd.gz (only)?

Yes. Honestly, I don't understand why they are not in gtk/, that only
brings confusion as to whether the image is gtk-ish or not.

> I'm not too fond of moving files around, especially since serving the
> right files from the right places is sometimes hard/long to set up; so
> I don't think you're “less than ideal” commit as you call it is too bad.

I'm fine with keeping this special-casing, I just feel that simply
keeping gtk files in gtk/ would lead to less special-casing overall.

Samuel

Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?

[Cyril Brulebois]

Cyril Brulebois  (2015-11-27):
> We're currently missing d-i daily builds, apparently because apt-get is
> stuck. Trying to replicate the issue in one of my devel schroots, it
> seems to be trying to call select with strange parameters:
> | 9996  select(1, [], [], NULL, {0, 498491}) = 0 (Timeout)
> | 9996  rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
> | 9996  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> | 9996  write(1, "\r0% [Working]", 13)= 13
> | 9996  select(1, [], [], NULL, {0, 50}) = 0 (Timeout)
> | 9996  rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
> | 9996  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> | 9996  write(1, "\r0% [Working]", 13)= 13
> | 9996  select(1, [], [], NULL, {0, 50}) = 0 (Timeout)
> | 9996  rt_sigprocmask(SIG_BLOCK, [WINCH], [], 8) = 0
> | 9996  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
> | 9996  write(1, "\r0% [Working]", 13)= 13
> | 9996  select(1, [], [], NULL, {0, 50}) = 0 (Timeout)

This part seems to be fixed with:
|  apt (1.1.1) unstable; urgency=medium
|  .
|[ Michael Vogt ]
|* Deal with killed acquire methods properly instead of hanging
|  (Closes: #806406)

that I grabbed from incoming.

I'm now getting this with an http://localhost/debian deb line in my
sources.list (which gets used to determine what to put in the local
sources.list.udeb used in d-i's build system):
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build 
build_netboot-gtk USE_UDEBS_FROM=sid 
| make: Entering directory '/home/kibi/debian-installer/installer/build'
| Using generated sources.list.udeb:
|deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ 
localudebs/
|deb http://localhost/debian sid main/debian-installer
| make[2]: 'sources.list.udeb' is up to date.
| Running APT_GET (else)
| Reading package lists... Done
| E: Method gave invalid 400 URI Failure message: Could not get new groups - 
getgroups (22: Invalid argument)
| E: Method gave invalid 400 URI Failure message: Could not get new groups - 
getgroups (22: Invalid argument)
| E: Method copy has died unexpectedly!
| E: Sub-process copy returned an error code (112)

and slightly differently with a file:///srv/mirrors/debian deb line:
| (sid-amd64-devel)kibi@wodi:~/debian-installer/installer$ make -C build 
build_netboot-gtk USE_UDEBS_FROM=sid 
| make: Entering directory '/home/kibi/debian-installer/installer/build'
| Using generated sources.list.udeb:
|deb [trusted=yes] copy:/home/kibi/debian-installer/installer/build/ 
localudebs/
|deb copy:///srv/mirrors/debian sid main/debian-installer
| make[2]: 'sources.list.udeb' is up to date.
| Running APT_GET (else)
| Reading package lists... Done
| E: Method gave invalid 400 URI Failure message: Could not get new groups - 
getgroups (22: Invalid argument)
| E: Method copy has died unexpectedly!
| E: Sub-process copy returned an error code (112)

Coming to think of it, I vaguely remember groups-related issues below
schroot from the early systemd days (I kept sysvinit for a while because
of this), but that disappeared a long while ago.


Mraw,
KiBi.


signature.asc
Description: Digital signature

[PATCH:di-autobuild] buildscript: Detect running sessions to avoid spawning a new one

[Cyril Brulebois]

An apt hang was spotted during d-i's build (through daily build crontab
entries), and even if the immediate issue is going away (I killed all
schroot sessions manually, and apt now returns an issue instead of
hanging forever), it might be nice to try and detect when a session
already exists, to avoid starting too many of them. The following patch,
tested on barriere, seems to do the trick.

---
 buildscript | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/buildscript b/buildscript
index f787db4..8166bb3 100755
--- a/buildscript
+++ b/buildscript
@@ -87,6 +87,12 @@ cleanup () {
 }
 
 create_session() {
+  echo "INFO: checking for running sessions"
+  if schroot-list-sessions | grep "^sid_${ARCH}-dchroot"; then
+echo "ERROR: Existing sessions found, aborting"
+exit 1
+  fi
+
   echo "INFO: creating schroot"
   SID="$(schroot -b -c chroot:sid_${ARCH}-dchroot)"
   echo "INFO: session $SID created"
-- 
2.1.4

Re: Bug#806475: apt: Breaks debian-installer build, select with no read/write fds?

[David Kalnischkies]

On Fri, Nov 27, 2015 at 09:08:35PM +0100, Cyril Brulebois wrote:
> | E: Method gave invalid 400 URI Failure message: Could not get new groups - 
> getgroups (22: Invalid argument)
> | E: Method copy has died unexpectedly!
> | E: Sub-process copy returned an error code (112)

So, getgroups gets called there to verify that we really lost all groups
(beside the one _apt is in: nogroup). A few lines above we set the list
of (supplementary) groups containing only this group, then we switch uid
and gid (the later isn't enough for group switching aka we would be
still in root without the setgroups before).

So, us calling getgroups should really only return one group. Getting an
EINVAL suggests we get more than one… that is probably bad, but I have
a slight glimmer of hope that its just two times the same group – even
if that makes no sense… anyway, I can't reproduce this at the moment, so
it would be nice if someone could try the attached patch which could at
least tell us in which groups we remain (or it just works if we really
see duplicated groups here). Everything is possible I guess.

Given that schroot is involved mentioning if your host has an _apt user
or not might also help. As I learned today schroot is copying users and
groups into the schroot which makes all of this kinda strange… (#565613)
[two years of testing and you are still surprised on release…]

btw: To not block anyone: You can use the config option
Debug::NoDropPrivs to true to disable privilege dropping for the moment.


Best regards

David Kalnischkies
diff --git a/apt-pkg/contrib/fileutl.cc b/apt-pkg/contrib/fileutl.cc
index 46de634..f754b31 100644
--- a/apt-pkg/contrib/fileutl.cc
+++ b/apt-pkg/contrib/fileutl.cc
@@ -2322,12 +2322,17 @@ bool DropPrivileges()			/*{{{*/
   return _error->Errno("seteuid", "Failed to seteuid");
 #endif
 
-   // Verify that the user has only a single group, and the correct one
-   gid_t groups[1];
-   if (getgroups(1, groups) != 1)
-  return _error->Errno("getgroups", "Could not get new groups");
-   if (groups[0] != pw->pw_gid)
-  return _error->Error("Could not switch group");
+   // Verify that the user isn't still in any supplementary groups
+   long const ngroups_max = sysconf(_SC_NGROUPS_MAX);
+   std::unique_ptr gidlist(new gid_t[ngroups_max]);
+   if (unlikely(gidlist == NULL))
+  return _error->Error("Allocation of a list of size %lu for getgroups failed", ngroups_max);
+   ssize_t gidlist_nr;
+   if ((gidlist_nr = getgroups(ngroups_max, gidlist.get())) < 0)
+  return _error->Errno("getgroups", "Could not get new groups (%lu)", ngroups_max);
+   for (ssize_t i = 0; i < gidlist_nr; ++i)
+  if (gidlist[i] != pw->pw_gid)
+	 return _error->Error("Could not switch group, user %s is still in group %d", toUser.c_str(), gidlist[i]);
 
// Verify that gid, egid, uid, and euid changed
if (getgid() != pw->pw_gid)


signature.asc
Description: PGP signature

Bug#806447: win32-loader: ftbfs, convert: command not found

[Holger Levsen]

source: win32-loader
version: 0.7.10
severity: serious

Hi,

win32-loader fails to build from source like this:

[...]
# Build the cdrom version
OUTFILE_NAME=win32-loader.exe \
BUILD_DATE="Wed, 29 Apr 2015 09:25:43 +0200" \
dh_auto_build
make -j1
make[2]: Entering directory 
'/var/lib/jenkins/jobs/d-i_build_win32-loader/workspace'
convert templates/gtk_orig.png -resize 107x80 BMP3:templates/gtk.bmp
bash: convert: command not found
Makefile:122: recipe for target 'templates/gtk.bmp' failed
make[2]: *** [templates/gtk.bmp] Error 127
make[2]: Leaving directory 
'/var/lib/jenkins/jobs/d-i_build_win32-loader/workspace'
dh_auto_build: make -j1 returned exit code 2
debian/rules:42: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory 
'/var/lib/jenkins/jobs/d-i_build_win32-loader/workspace'
debian/rules:38: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


full log available at 
https://jenkins.debian.net/job/d-i_build_win32-loader/25/consoleFull


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Bug#806443: disk-detect/multipath: default path selector is not loaded

[Ben Hutchings]

On Fri, 2015-11-27 at 15:39 +0100, Hendrik Brueckner wrote:
[...]
> --- a/disk-detect.sh
> +++ b/disk-detect.sh
> @@ -202,7 +202,7 @@ fi
>  db_get disk-detect/multipath/enable
>  if [ "$RET" = true ]; then
>  >> if anna-install multipath-udeb; then
> ->>   > MODULES="dm-mod dm-multipath dm-round-robin dm-emc"
> +>>   > MODULES="dm-mod dm-multipath dm-service-time dm-round-robin 
> dm-emc"
>  >>   > # We need some dm modules...
>  >>   > depmod -a >/dev/null 2>&1 || true
>  >>   > for MODULE in $MODULES; do

At least dm-service-time and dm-round-robin will be automatically
loaded by the kernel when needed.  I'm not sure about the others.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy 1981-1987


signature.asc
Description: This is a digitally signed message part

Re: Broken EFI grub.cfg on stretch images

[Cyril Brulebois]

Samuel Thibault  (2015-11-27):
> Cyril Brulebois, on Fri 27 Nov 2015 23:32:03 +0100, wrote:
> > Are we talking about possibly moving stuff from:
> >  - build/tmp/netboot-gtk/ to build/tmp/netboot/gtk?
> >  - build/tmp/netboot-gtk/ to build/tmp/netboot-gtk/gtk?
> > 
> > where stuff means initrd.gz (only)?
> 
> Yes. Honestly, I don't understand why they are not in gtk/, that only
> brings confusion as to whether the image is gtk-ish or not.
> 
> > I'm not too fond of moving files around, especially since serving the
> > right files from the right places is sometimes hard/long to set up; so
> > I don't think you're “less than ideal” commit as you call it is too bad.
> 
> I'm fine with keeping this special-casing, I just feel that simply
> keeping gtk files in gtk/ would lead to less special-casing overall.

I meant to mention I don't feel strongly one way or the other. Having
stuff where they make sense is of course a good idea. Especially so if
that means fewer hacks/easier maintenance.

Just wanted to emphasize that moving user-facing files/locations around
has a cost, for users.

Mraw,
KiBi.


signature.asc
Description: Digital signature