Bug#1061820: (no subject)

[Johannes Schauer Marin Rodrigues]

Hi,

On 2024-01-31 09:15, Ken Sharp wrote:
Do I need to submit the patch somewhere else or is this the correct 
place?


the bts is the correct place but debootstrap is maintained by unpaid 
volunteers like many other open source projects. So getting your patch 
merged depends on somebody finding some time to do so.


I have created a merge request to make application of your patch a bit 
easier for the debootstrap maintainers:


https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/111

Thanks!

cheers, josch

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Quoting Santiago Vila (2023-10-30 21:53:59)
> El 30/10/23 a las 21:16, Johannes Schauer Marin Rodrigues escribió:
> > Quoting Luca Boccassi (2023-10-18 19:17:40)
> >> We can do an upload, but note that it won't have any effect on package
> >> builds, given the buildds use stable/oldstable
> > 
> > actually we forgot something here. The upload *does* have an effect on 
> > buildds
> > right now even before Trixie gets released because riscv buildds (in 
> > contrast
> > to the others) do run debootstrap from unstable, resulting in this recent 
> > build
> > failure of src:siridb-server:
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=siridb-server=riscv64=2.0.48-1%2Bb1=1698686860=0
> > 
> > This was reported already by Santiago as #1027381 last year and Paul Gevers
> > quickly did another upload of src:siridb-server fixing this.
> > 
> > So if riscv keeps being part of the release arches for trixie, then the 
> > FTBFS
> > bugs reported by Santiago will have real effects on buildds building 
> > packages
> > for riscv going forward. So unless that change gets reverted in debootstrap,
> > this class of bugs will likely go away by itself before trixie gets 
> > released.
> 
> So, if I understood correctly, if a package has this bug, and it's already
> reported, and the maintainer does a new upload but they forget to fix the bug,
> then the package will FTBFS on riscv, and as a result, the package will not
> propagate to testing.

this will of course also happen to packages that have the bug even if it's not
reported. Otherwise: yes.

> This is actually a good thing, it means the bugs are "factually RC".

I agree.

> So, while I personally don't see a special hurry to raise the severities of
> the currently reported bugs, maybe it makes sense that we start to report
> *new* bugs like this one as serious.

I think that would make sense, given that this currently blocks package
migration to testing due to factual build failures on riscv buildds.

In #debian-release, aurel32 asked about my opinion on whether those bugs should
now be raised to RC and I agreed that they should.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Luca Boccassi (2023-10-18 19:17:40)
> We can do an upload, but note that it won't have any effect on package
> builds, given the buildds use stable/oldstable

actually we forgot something here. The upload *does* have an effect on buildds
right now even before Trixie gets released because riscv buildds (in contrast
to the others) do run debootstrap from unstable, resulting in this recent build
failure of src:siridb-server:

https://buildd.debian.org/status/fetch.php?pkg=siridb-server=riscv64=2.0.48-1%2Bb1=1698686860=0

This was reported already by Santiago as #1027381 last year and Paul Gevers
quickly did another upload of src:siridb-server fixing this.

So if riscv keeps being part of the release arches for trixie, then the FTBFS
bugs reported by Santiago will have real effects on buildds building packages
for riscv going forward. So unless that change gets reverted in debootstrap,
this class of bugs will likely go away by itself before trixie gets released.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi Luca,

Quoting Luca Boccassi (2023-10-18 19:38:16)
> Thanks - I'll merge and do an upload over the weekend then

thank you for your upload!! :D

I temporarily subscribed to debootstrap via tracker.d.o so that I hopefully
catch any bug report coming in related to this change.

I also re-triggered some autopkgtests that were flaky and where re-running them
now makes all the reverse dependencies work.

Well, not all the reverse dependencies. The autopkgtest of mmdebstrap broke as
expected, which is of course also good because it matches our expectations.

I have the fix for this locally and am currently running the mmdebstrap test
suite with the fix I posted in my last mail. This made me find another change
that was necessary. /usr/share/debootstrap/scripts/debian-common sets up
/etc/localtime if it doesn't exist yet. This code-path was probably not taken
so far because tzdata was always installed? In any case, I think this is
harmless and doesn't require any changes.

Then I worried that we forgot to update the man page after this change.
Luckily, the man page only points out that the buildd profile installs
build-essential and does not talk about priority:required packages, so that
checks out. What could maybe be added is, that the buildd variant installs
build-essential *and* apt which is the remaining exception to the rule.

I will upload mmdebstrap with the required changes after the test suite
finished in about six hours.

Thanks again!

cheers, josch

signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi Luca,

Quoting Luca Boccassi (2023-10-18 19:17:40)
> On Wed, 18 Oct 2023 at 18:04, Johannes Schauer Marin Rodrigues
>  wrote:
> >
> > Hi,
> >
> > Quoting Santiago Vila (2023-10-12 17:56:04)
> > > Johannes has asked the RMs in this thread:
> > >
> > > https://lists.debian.org/debian-release/2023/10/msg00425.html
> > >
> > > if they are ready to consider the bugs as RC. I believe it would be better
> > > if we can make the bugs "factually" RC by uploading the fixed debootstrap 
> > > first.
> >
> > I do not have a strong opinion on what should happen first but in that 
> > thread,
> > Holger and Sam also support the idea to first upload debootstrap.
> 
> We can do an upload, but note that it won't have any effect on package
> builds, given the buildds use stable/oldstable - and this is not
> material for p-u, given the effect. Of course it will affect local
> builds, in case they are done via debootstrap, from testing/unstable
> users.

Yes, I'm aware of that. But I think having this in unstable/testing already
will help because several maintainers replied to the bugs saying they are
unable to reproduce it. Having debootstrap with this change in unstable/testing
will make this a) much easier and b) convince people that they need to include
this change or otherwise their package will really FTBFS on the buildds with
the trixie release.

And this should probably go without saying but just to make sure: if this
change causes any weird bugs, please message me so that I can supply a fix.

Thank you!

cheers, josch

signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Santiago Vila (2023-10-12 17:56:04)
> Johannes has asked the RMs in this thread:
> 
> https://lists.debian.org/debian-release/2023/10/msg00425.html
> 
> if they are ready to consider the bugs as RC. I believe it would be better
> if we can make the bugs "factually" RC by uploading the fixed debootstrap 
> first.

I do not have a strong opinion on what should happen first but in that thread,
Holger and Sam also support the idea to first upload debootstrap.

My thought process behind asking the release team about the bug severity was,
that I found it unlikely for the remaining bugs to go down to zero without the
release team declaring that those bugs are indeed of significant severity.

Paul Gevers suggested that I should NMU to DELAYED/10 without raising the
severity.

There are not many packages remaining, so I'm impartial on how this is moved
forward.

On a different topic: this change in debootstrap will break mmdebstrap because
mmdebstrap compares its own output against the output of debootstrap to verify
that it does the right thing. Here is the patch to mmdebstrap that fixes this
issue:

@@ -2955,15 +2966,15 @@ sub run_install() {
 
 my @pkgs_to_install = (@{ $options->{include} });
 if ($options->{variant} eq 'buildd') {
-push @pkgs_to_install, 'build-essential';
+push @pkgs_to_install, 'build-essential', 'apt';
 }
 if (any { $_ eq $options->{variant} }
-('required', 'important', 'standard', 'buildd')) {
+('required', 'important', 'standard')) {
 # Many of the priority:required packages are also essential:yes. We
 # make sure not to select those here to avoid useless "xxx is already
 # the newest version" messages.
 my $priority;
-if (any { $_ eq $options->{variant} } ('required', 'buildd')) {
+if (any { $_ eq $options->{variant} } ('required')) {
 $priority = '?and(?priority(required),?not(?essential))';
 } elsif ($options->{variant} eq 'important') {
 $priority = '?and(?or(?priority(required),?priority(important)),'

I verified that the patch from the MR indeed ends up doing the same as above
patch to mmdebstrap.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Johannes Schauer Marin Rodrigues]

Hi,

On Wed, 14 Sep 2022 12:29:13 +0200 Pascal Hambourg  
wrote:
> Sorry to insist, but IMO this issue should really be worked out. I once
> suggested the following simple formula :
> 
>  max swap size = min(RAM size, disk space * R)
> 
> with R being a ratio between 0 and 100% to be defined.
> 
> For example with R=5%, the swap size would be limited to either the RAM size
> or 5% of available disk space, whichever is lower.
> 
> Doesn't that sound reasonable for most setups, at least more than the current
> formula ?

the default partitioning scheme now has made hibernation impossible for three
whole stable releases. I have no experience in writing d-i code but just so
that *something* happens I submitted this merge request to partman-auto:

https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/12

This MR keeps the partman-auto/cap-ram setting because it has now been in
partman-auto for so long that likely other users of d-i have started depending
on its existence. Instead, I raised the limit imposed by partman-auto/cap-ram
while at the same time adding a new setting I called partman-auto/perc-ram
which (if I'm reading the code correctly) should cap the swap size at X percent
of the remaining free disk space. This way, d-i should continue to work even in
situations where there is more RAM than disk space for which commit 7966fcd was
designed in the first place.

This is a draft MR because it is untested. Maybe somebody could help and review
and test it.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi Julien,

thank you for your quick reply!

Quoting Julien Cristau (2023-09-28 17:49:51)
> I guess more than mixing two different things I disagree that that is
> debootstrap's responsibility, and so I disagree that that is a valid bug.  In
> my view it's more important for debootstrap to reliably be able to create
> chroots than some sort of philosophical purity about what is included in said
> chroot.  Package priorities are how the archive tells debootstrap which
> packages to install, and so since I don't see your (A) as a bug, I'm saying
> if there's a bug it's (B) and belongs with the archive.

I agree that debootstrap's reliability to create chroots is supremely
important. But do you see a bug with my change that makes it unreliable? It
changes what the chroot includes yes, but it does so in a reliable way unless I
missed something?

I also agree that "philosophical purity" is a bad argument but "package
priorities are how the archive tells debootstrap which packages to install" is
also not a practical argument but an argument of "we've always done it this way
and that's why we will continue to do it that way". This sounds to me like
another argument of "philosophical purity" instead of one motivated by
practical considerations.

So I'd like to take a step back. There was a big thread on d-devel about this
topic and arguments have been exchanged about this forth and back. I'd like to
use this email to rephrase the argument I have already made for this change.

> I also think your argument, even if I went along with it, breaks down when
> the apt package gets included, since apt is clearly not build-essential, so
> by that logic we'd go back to the days where builds used the host system's
> apt instead of including it in the chroot.

If my argument was of "philosophical purity" then it would indeed completely
break down with making apt the exception. But I'm trying to fix a practical
problem here and thus I'm fine with leaving apt the exception for now. Whether
or not to use apt from the outside would be another discussion we could have
but I do not think it is very useful to have the discussion today. The
practical side of the matter is, that the default schroot backend of sbuild is
unable to use apt from the outside and unless official buildds switch to the
unshare backend, apt has to be included in the chroot.

What this change is trying to achieve is to make it harder for source packages
to make it into the archive that have build dependencies missing. This is my
main motivation. This is also why having apt inside the chroot is not much of a
problem because I cannot remember having seen a source package in the archive
that needed apt to build but was missing it in its Build-Depends.

Source packages with missing build dependencies make QA work on the archive
harder. Santiago is not the only one who found these bugs, Helmut filed bugs
for missing B-D on tzdata and obviously I ran into the problem myself where I
wanted to build a source package but it failed to build because it did not
declare the B-D it actually needed. The time we spend on stumbling over these
bugs, filing them and waiting for them to be fixed could be spent doing more
useful things. We would not have these bugs if source packages were build on
the official buildds in an environment that didn't have extra packages
installed.

So I propose to change the debootstrap buildd variant to install fewer
packages: to help catch this sort of bugs early. In the best case, already on
the developer's machine when they try to build the package.

As always this is a trade-off. If this change to debootstrap is not made, these
bugs will continue to keep happening and the time of some of us will continue
to be wasted on this issue. What is the other side of the coin? If this change
is made, what would break? Santiago already analyzed the archive to find source
packages that would fail and filed bugs. So we know what would break and we
informed the maintainers. What else would break? Would anything else break
other than the principle that debootstrap historically just must include the
priority:required packages just because it has always done it like that?

I really do not understand why using the Priority field and only the Priority
field is a thing that just must keep being used by debootstrap. Why is it a
problem to use the Essential field instead?

Right now, debootstrap is the odd-one-out in the archive. To my knowledge there
is no other software (other than mmdebstrap which will mirror what debootstrap
does by design) which considers the Priority field when selecting packages that
need to be installed to satisfy the build-dependencies of a source package.
Sbuild for example is fine with working on chroots that just include
essenital+apt but it will only install build-essential and not
Priority:required packages. When asking apt to satisfy build dependencies, it
will install build-essenital but not Priority:required packages. When asking

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

The remaining bugs are now properly user-tagged and can be found here:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=missing-build-depends-on-not-build-essential

On Sat, 23 Sep 2023 20:13:45 +0200 Johannes Schauer Marin Rodrigues 
 wrote:
> Santiago is in CC as the driver of the mass bug filing for source packages
> that fail to build in a chroot environment with just Essential:yes and
> build-essential installed.
> 
> According to the last MBF from December 2022 and January 2023, there are 13
> source packages that would FTBFS after this change because they are missing
> an explicit build dependency on tzdata or mount.

Let me also correct my last message. As I believe that source packages should
be build with just Essential:yes and build-essential (and their respective
dependencies) installed, I do not consider Santiago's work an MBF but just
another QA bug filing against packages that FTBFS in an environment where they
should be buildable.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer Marin Rodrigues]

Hi all,

On Sun, 25 Jun 2017 06:01:13 +0200 Johannes Schauer  wrote:
> Quoting Cyril Brulebois (2017-06-24 20:23:25)
> > Julien Cristau  (2016-09-12):
> > > This is a transient situation because some Essential packages'
> > > dependencies changed.  I'd consider this a bug in the archive, not in
> > > debootstrap.
> > Any reasons to keep this bug report open then? Seen no objections, so I'm
> > tempted to close it.
> 
> But... the buildd variant still explicitly (and not only implicitly through
> dependencies of essential:yes packages) installs Priority:required packages,
> no?

as we are at the beginning of the trixie development cycle, I have opened a
merge request against debootstrap which avoids installing priority:required
packages with the buildd variant:

https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/106#note_430035

I've put Ansgar and Julien in CC as they were opposed to this change.

I'm putting Luca and Guillem in CC who wrote in favour of this change also in
policy bug #1029831.

Santiago is in CC as the driver of the mass bug filing for source packages that
fail to build in a chroot environment with just Essential:yes and
build-essential installed.

According to the last MBF from December 2022 and January 2023, there are 13
source packages that would FTBFS after this change because they are missing an
explicit build dependency on tzdata or mount.

As part of the thread starting at
9b40f6f2-4942-acfc-2f9c-4668f05d9...@debian.org a number of arguments were made
for and against this change. I still believe that the arguments for this change
weigh stronger than those against it and thus I filed that merge request above.

Luca, as the debootstrap maintainer, what are your thoughts?

Thank you!

cheers, josch

signature.asc
Description: signature

Bug#1050162: debootstrap: fix loong64 usrmerge

[Johannes Schauer Marin Rodrigues]

Hi,

On Mon, 21 Aug 2023 16:09:00 +0800 Han Gao  wrote:
>   Fix loong64 usrmerge recognize.

thank you for your patch but the function you changed is no longer used to
create the merged-/usr symlinks. The new approach creates those symlinks after
unpacking the essential packages and no longer carries an architecture specific
list of directories. With the new approach, things should just work. Can you
try out debootstrap 1.0.130 or later and confirm?

You can find more details about the new merged-/usr approach in this merge
request:

https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/96

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1049898: debootstrap: change /usr-merge implementation to merge after unpack

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Simon McVittie (2023-08-16 17:19:42)
> On Wed, 16 Aug 2023 at 17:07:39 +0200, Helmut Grohne wrote:
> > The other aspect is that we want to ship the
> > aliasing symlinks in a package (base-files probably).
> ...
> > Is there any prerequisite you see missing before we can merge and upload
> > this change? Any aspect to be analyzed? Any situation to be tested? Any
> > conceptual aspect I am missing?
> 
> You probably have, but: have you tried bootstrapping sid with a
> locally-hacked base-files that adds the aliasing symlinks to its data.tar, to
> check that this has the desired effect?

independent of Helmut I have written my own set of patches to the Essential:yes
set which installs to /usr instead of / as well as a patcher which takes
existing *.deb files and moves files around from /usr to /. With the modified
packages and unpatched debootstrap I get:

I: Retrieving util-linux-extra 2.38.1-5
I: Validating util-linux-extra 2.38.1-5
I: Retrieving zlib1g 1:1.2.13.dfsg-1
I: Validating zlib1g 1:1.2.13.dfsg-1
I: Chosen extractor for .deb packages: dpkg-deb
I: Extracting base-files...
E: Tried to extract package, but file already exists. Exit...

With Helmut's patch debootstrap finishes successfully and leaves me with a
chroot that I was able to successfully run a shell in. The symlinks from bin,
lib and sbin into /usr exist.

I have not done very extensive testing yet but it looks like it does what it
should.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1031105: unshared debootstrap fails if auto-apt-proxy is installed

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + patch

Hi,

Quoting Antonio Terceiro (2023-05-16 22:30:02)
> Maybe I am missing something, but debootstrap has no knowledge about
> auto-apt-proxy,

it does:

https://sources.debian.org/src/debootstrap/1.0.128%2Bnmu2/debootstrap/#L457

> why would debootstrap be the one responsible for disabling auto-apt-proxy?
> Shouldn't mmdebstrap setup a reasonable (empty) /tmp since it's the one who
> is setting up the unshared user namespace?

being in an unshared user namespace does not mean you are inside a chroot.
Since we are not inside a chroot, the unshared user sees files in /tmp with
different permissions than the outside user. It is not reasonable to expect
mmdebstrap to hose things in /tmp.

Here is a possible fix:

https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/90

With this change, debootstrap will skip running auto-apt-proxy when the
http_proxy environment variable is set to the empty string.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Isaac True (2023-04-17 10:49:20)
> > Why would you have to run flash-kernel again?
> 
> When it's being initially installed it won't have the additional command line
> flag that forces it to ignore the EFI check, so it won't run and you would
> have to run it manually afterwards with the flag. I agree that an env
> variable/config file would be better here.
> 
> > The name FK_FORCE_EFI=yes seems a bit backwards; it is ignoring 
> 
> the presence of EFI, not forcing it to behave like EFI. FK_FORCE_NO_EFI?
> FK_IGNORE_EFI? Names are hard.
> 
> My intention behind the name was something like "force *despite* EFI", but I
> think FK_IGNORE_EFI does indeed fit a lot better. .
> 
> > I overall like this approach, although the main drawback is having to write
> > to /etc/default/flash-kernel 
> 
> I agree with this - it's a bit more awkward having to create and write a
> file, but I like that it opens the door to allow both methods to work. The
> user can either set the env variable, or it can be set in the file itself.

I've had a private chat with Vagrant yesterday and we agreed that the best way
forward would be to solve this in the same way the environment variable
FK_MACHINE works which can also be set using /etc/flash-kernel/machine and is
essentially and override for /proc/device-tree/model.

So in the same fashion we could have FK_IGNORE_EFI as an environment variable
which can also be set by having /etc/flash-kernel/ignore-efi which is an
override for the existence of /sys/firmware/efi.

Would you like to amend your patch to add support for
/etc/flash-kernel/ignore-efi in addition to FK_IGNORE_EFI? I'd be willing to
test the result in our CI environment. :)

> I'm not sure if it makes sense to add the "! ischroot" check like in that
> merge request though, as I feel like that's a different topic. What do you
> think?

The "! ischroot" is not strictly required for my use-case. I added it because
with it, we get the nice property, that outside of a chroot (i.e. when not
creating a bootable image for another machine) the presence of efi will not get
ignored. This would mean that after creating the bootable image, one would not
have to remove /etc/flash-kernel/ignore-efi to get back to a system that
potentially could support efi in the future. But I do not require this extra
complexity. I think there is value in making FK_IGNORE_EFI behave the same as
FK_MACHINE without any hidden surprises like the "! ischroot" check.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1033737: flash-kernel: Unable to run flash-kernel on EFI-based systems

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + patch

Hi,

On Fri, 31 Mar 2023 13:52:45 + Isaac True  wrote:
> As part of our CI/CD system, we are building images for target devices.  The
> images are set up in virtual machines which boot using EFI, but flash-kernel
> installation always fails as it detects that the system is running in EFI by
> checking for the existence of /sys/firmware/efi.

we have the same problem when building bootable images for the MNT Reform
laptop:

https://source.mnt.re/reform/reform-system-image/

The CI system is a machine that boots with EFI but the final system uses uboot
to boot and not EFI.

> Being able to setup the image on these VMs is an important part of our
> testing and validation workflow, so it would be very helpful to have an
> option to skip this check and proceed regardless of whether the system is
> currently running in EFI mode or not.

This used to work in the past but was broken by this commit:

https://salsa.debian.org/installer-team/flash-kernel/-/commit/8a81a537995a2b98386aea883729ce9960a825bf

> I've added a debdiff for a proposal for a new parameter --force-efi which can
> be set to skip this check.

The problem with implementing this using a command line flag or an environment
variable is, that then you will have to run flash-kernel again manually after
initially installing it.

What do you think about instead using an option in /etc/default/flash-kernel
which allows ignoring /sys/firmware/efi if inside a chroot as I implemented
here:

https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/33

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1031222: mounting /proc silently fails and thus systemd-tmpfiles is skipped with unshared mount namespace on privileged docker (like salsaci)

[Johannes Schauer Marin Rodrigues]

Package: debootstrap
Version: 1.0.128+nmu2
Severity: normal
Tags: patch
Control: affects -1 + mmdebstrap

Hi,

steps to reproduce:

runuser -u debci -- mmdebstrap --variant=custom --mode=unshare 
--setup-hook='container=lxc debootstrap unstable "$1"' - chroot.tar

Run this inside a privileged docker container (like in a salsaci autopkgtest)
and observe how the following files are missing from chroot.tar:

/etc/mtab
/root/.ssh
/run/lock/subsys
/var/cache/private
/var/lib/private
/var/lib/systemd/coredump
/var/lib/systemd/pstore
/var/log/README
/var/log/private

All of these would be created by systemd-tmpfiles. They are not created because
(after setting SYSTEMD_LOG_LEVEL=debug):

/proc/ is not mounted, but required for successful operation of 
systemd-tmpfiles. Please mount /proc/. Alternatively, consider using the 
--root= or --image= switches.

This is because debootstrap runs "mount -t proc proc /proc". This does not work
inside an unshared mount namespace inside privileged docker (like salsaci). See
this other bug for a handy table about how to mount /proc:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030625#16

As shown in that table, this can be resolved by falling back to bind-mounting
/proc if mounting it normally didn't work. I implemented that in this merge 
request:

https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/91

Thanks!

cheers, josch

Bug#1031105: unshared debootstrap fails if auto-apt-proxy is installed

[Johannes Schauer Marin Rodrigues]

Package: debootstrap
Version: 1.0.128+nmu2
Severity: normal
X-Debbugs-Cc: terce...@debian.org
Control: affects -1 auto-apt-proxy mmdebstrap

Hi,

currently the mmdebstrap autopkgtest in experimental fails because debootstrap
cannot be run with the user namespace unshared if auto-apt-proxy is installed
and /tmp/.auto-apt-proxy-0 exists. Steps to reproduce:

$ mmdebstrap --variant=custom --mode=unshare --setup-hook='env container=lxc 
debootstrap unstable "$1" http://127.0.0.1/debian' /dev/null

The error message is:

E: insecure cache dir /tmp/.auto-apt-proxy-0. Must be owned by UID 0 and have 
permissions 700

The reason for this error is, that debootstrap will run auto-apt-proxy which
will find that /tmp/.auto-apt-proxy-0 exists but since the user namespace of
the process is unshared, it will be owned by user "nobody" from its
perspective.

Please provide a way to allow disabling running auto-apt-proxy when running
debootstrap.

Thanks!

cheers, josch

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Johannes Schauer Marin Rodrigues]

Hi,

On Sun, 5 Sep 2021 10:37:13 +0200 Pascal Hambourg  
wrote:
> On Sun, 25 Apr 2021 17:33:28 + Martin  wrote:
> > Also I assume, that desktop PCs are more oftenly installed
> > relying on d-i defaults, while servers are typically installed
> > by experienced admins.
> 
> I agree and am afraid that the new swap size will bite many users who 
> want hibernation on desktop or laptop PCs and use guided partitioning. 
> Besides, I cannot even imagine anyone using guided partitioning on a server.
> 
> > I'ld prefer the solution suggested in #780208, because it helps
> > in other cases, too.
> 
> Guided partitioning using LVM allows to reserve some free space in the 
> volume group, which can be used later to extend logical volumes.

if, like me, you have found this bug after wondering about the 1 GB small swap
partition on your brand-new Debian installation, here is a workaround that lets
the guided partitioner select a swap size roughly equal to your RAM size.

In the installer menu, press "e" to edit the default installation option. In
the line that says "linux /install.amd/vmlinuz" add the following separated by
a space after vmlinuz:

partman-auto/cap-ram=n

Then press Ctrl-x or F10 to boot debian-installer with your changes. This will
result in uncapped swap size which should be fine for normal laptops and
desktops. If instead you want to set a fixed cap at a certain number of MB, you
can instead add:

partman-auto/cap-ram=1024

This will cap the swap size to 1024 MB. This is currently the default. Increase
this value to get a larger swap partition (size is given in MB) or replace it
by a arbitrary string like the "n" above to not have swap size capped at all.
Here is the description of cap-rm from partman-auto.templates in the
partman-auto source package:

Description: for internal use; can be preseeded
 Cap RAM size to specified size in MB, when calculating the swap
 partition size. Defaults to 1024, meaning 1GB, and since swap is
 maximum 200% of RAM in the default recipes, it results in swap
 partitions to be capped at 2GB. To revert to previous behaviour of
 uncapped swap size with respect to available ram, preseed this key to
 any string, e.g. partman-auto/cap-ram=false

Maybe this helps somebody. Thanks to pham from the #debian-boot IRC channel for
this tip!

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu

[Johannes Schauer Marin Rodrigues]

Hi Phil,

Quoting Philip Hands (2022-05-13 11:52:05)
> Johannes Schauer Marin Rodrigues  writes:
> > I'm confused. Shouldn't preseed_fetch try to obtain the setup-testbed
> > relative to the preseed file it just obtained?
> 
> preseed_fetch gets things relative to the place the previous
> preseed_fetch got things from, which is one step later than you are
> expecting because it has not really been setup while you're in the
> context of the initial preseed.cfg.
> 
> See:  
> https://salsa.debian.org/installer-team/preseed/-/blob/master/README.preseed_fetch
> 
> The point is that you need to have done a preseed/include or a
> preseed/run (which can be relative paths) in order to have populated the
> previous download path, whereas I think you are trying to run the
> preseed_fetch while we're still on the first time through the code, in
> the loop above this line:
> 
>   
> https://salsa.debian.org/installer-team/preseed/-/blob/master/preseed.sh#L120
> 
> I guess there should be some documentation that's easier to find than
> the above README, to say that you should not use relative paths for
> preseed_fetch from the early_command (and possibly the late_command?) in
> preseed.cfg itself, but only from within files that were grabbed via at
> least one preseed/run or preseed/include -- or something like that.

I found and read README.preseed_fetch just fine, so I don't think it's a
problem of find-ability of the docs. But the README should maybe contain the
things you said above and maybe even an example as you reference below. From my
reading of README.preseed_fetch I did not understand this limitation.

> Here's another example that may be instructive:
> 
>   https://hands.com/d-i/bug/846002/
> 
>   (which is referred to here: https://bugs.debian.org/846002#304 )

Ah yes, that worked! I documented the solution in my reply to #678694 and will
keep using that. It feels a bit odd to download a one-line script which does
nothing else than downloading yet another script but since it's automated I
guess I don't care. :)

> I seem to have learnt to avoid doing anything interesting in preseed.cfg
> itself -- assuming that's not already mentioned somewhere, if you have a
> suggestion for where that tip could have been placed to have been helpful to
> you, please report a bug against the relevant documentation.

I think README.preseed_fetch is fine as I was able to find it via searching for
preseed_fetch via codesearch.debian.net. I think it just needs the bits that
you explained to me above copypasted into it.

Thanks again!

cheers, josch

signature.asc
Description: signature

Bug#678694: preseed_fetch fails with relative url

[Johannes Schauer Marin Rodrigues]

Hi Diederik,

thank you for notifying me of this bug report over at #1010878.

On Sat, 19 Oct 2019 15:53:22 +0200 Jonathan Leroy - Inikup 
 wrote:
> This bug is still present in Buster.
> Very simple workaround:
> 
> d-i preseed/early_command string echo "$(debconf-get preseed/url)" >
> /var/run/preseed.last_location

You probably already saw Phils reply to #1010878 but if anybody else is reading
this I also wanted to quickly record what I did to avoid the problem.

So, I'm running d-i in qemu with preseed/url=http://10.0.2.2:8000 and serve my
current directory with "python3 -m http.server". Then in
d-i/bullseye/preseed.cfg I have:

d-i preseed/run string fetch.sh
d-i preseed/late_command string sh /tmp/setup-testbed /target

My d-i/bullseye/fetch.sh then runs preseed_fetch:

#!/bin/sh
preseed_fetch setup-testbed /tmp/setup-testbed

And that will download d-i/bullseye/setup-testbed into /tmp/setup-testbed to
make it available for my preseed/late_command.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu

[Johannes Schauer Marin Rodrigues]

Hi Phil,

Quoting Philip Hands (2022-05-12 13:40:51)
> BTW I somehow failed to notice that you were pointing preseed/url at the
> example-preseed.cfg when I ran that locally.
> 
> Given that you're already relying on a network preseed, you should just
> put a copy of that somewhere you control, and make all the changes that
> you are trying to put on the command line into your preseed.cfg instead,
> and it should work fine.
> 
> Also, you can save some more command line characters by using aliases:
> 
>   https://d-i.debian.org/manual/en.amd64/apbs02.html#preseed-aliases
> 
> If you wanted to make your preseed setup clever enough to handle
> different arch's differently, from the same preseed files, then there
> are some examples of scripting here that may provide inspiration:
> 
>   https://hands.com/d-i/
> 
> (it's not got arch specific stuff, but it does demonstrate that you go
> wild with scripting, if you want to)

thank you, that's a great resource! I don't think I need full-blown framework
but reading the code made me learn about more things I can do with d-i. I'm
running into a problem though and maybe I can pick your brain a bit:

So I want to download a script (I'm running my own HTTP server) and execute it
at the end of the installation. I'm currently having this in my
d-i/bullseye/preseed.cfg:

d-i preseed/early_command string preseed_fetch setup-testbed /tmp/setup-testbed
d-i preseed/late_command string /tmp/setup-testbed /target

If I understand the docs of preseed_fetch correctly, then this should fetch the
setup-testbed script from a path relative to where it got the preseed file
from. Thanks to https://hands.com/d-i/ I now am just using

preseed/url=http://10.0.2.2:8000

Unfortunately (and thanks for pointing me to the keyboard shortcuts to access
the log) this results in the following:

May 13 07:26:28 preseed: successfully loaded preseed file from 
http://10.0.2.2:8000/d-i/bullseye/./pres
May 13 07:26:28 preseed: running preseed command preseed/early_command: 
preseed_fetch setup-testbed /tm
May 13 07:26:28 log-output: /bin/fetch-url: .: line 35: can't open 
'/usr/lib/fetch-url//setup-testbed':

I'm confused. Shouldn't preseed_fetch try to obtain the setup-testbed relative
to the preseed file it just obtained?

Thanks again!

cheers, josch

signature.asc
Description: signature

Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Philip Hands (2022-05-12 10:14:46)
> > So for some reason passwd/root-password-again is ignored. Above recipe
> > works fine for other architectures and for some reason stops with above
> > prompt on mips64el. Why?
> 
> It seems that you are hitting a limit on the length of the command line.
> 
> If you flip to one of the shells (Ctrl-A Ctrl-A 2) and do:
> 
>   cat /proc/cmdline

Ah thank you! I probably missed that in the docs (this is probably screen
running?). This is very helpful. :)

> you'll see that most of your kernel commandline is missing.  I'd guess
> that's a limitation of mips64el.  Probably best to specify a preseed
> file in order to get round this limitation, either by url, or you could
> try this:
> 
>   
> https://wiki.debian.org/DebianInstaller/Preseed/EditIso#Adding_a_Preseed_File_to_the_Initrd

Ouch... that's a very unexpected architecture specific limitation. Thanks a lot
for your very quick help!

I wasn't sure where to direct my d-i "bug" reports to. Context is, that I'm
running d-i inside qemu to create bootable disk images that can then be used
with autopkgtest-virt-qemu. So far amd64, i386, ppc64el and arm64 work well.
I'm running into problems with the network interface on s390x but I'm maybe
just driving QEMU wrongly.

I assume that somebody is already running d-i in QEMU for multiple
architectures somewhere as part of some d-i CI infrastructure? If that already
exists, I'd welcome a pointer because I'm probably re-inventing the wheel here.
:)

Otherwise, feel free to close this bug report.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1010878: installation-reports: preseeding passwords doesn't work on mips64el under qemu

[Johannes Schauer Marin Rodrigues]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: jo...@debian.org

Hi,

steps to reproduce:

qemu-img create -f qcow2 disk.qcow 4G
curl 
https://deb.debian.org/debian/dists/bullseye/main/installer-mips64el/current/images/malta/netboot/initrd.gz
 > initrd.gz
curl 
https://deb.debian.org/debian/dists/bullseye/main/installer-mips64el/current/images/malta/netboot/vmlinuz-5.10.0-13-5kc-malta
 > linux
/usr/bin/time -v qemu-system-mips64el -M malta -cpu 5KEc -nographic -no-reboot 
-m 1G -initrd initrd.gz -kernel linux -append 'auto-install/enable=true 
debconf/priority=critical 
preseed/url=http://www.debian.org/releases/stable/example-preseed.txt 
netcfg/get_hostname=hostname netcfg/get_domain=domain 
passwd/root-password=r00tme passwd/root-password-again=r00tme 
passwd/user-fullname=user passwd/username=user passwd/user-password=insecure 
passwd/user-password-again=insecure pkgsel/run_tasksel=false 
popularity-contest:popularity-contest/participate=false 
grub-installer/bootdev=/dev/sda --- console=ttyS0' -hda disk.qcow

This stops at the following screen:

[(1*installer)  2 shell  3 shell  4- log   ][ May 12  6:27 ]



 ┌┤ [!!] Set up users and passwords ├─┐ 
 ││ 
 │ Please enter the same root password again to verify that you have  │ 
 │ typed it correctly.│ 
 ││ 
 │ Re-enter password to verify:   │ 
 ││ 
 │ __ │ 
 ││ 
 │ [ ] Show Password in Clear │ 
 ││ 
 │ │ 
 ││ 
 └┘ 





 moves;  selects;  activates buttons 


So for some reason passwd/root-password-again is ignored. Above recipe
works fine for other architectures and for some reason stops with above
prompt on mips64el. Why?

Thanks!

cheers, josch

Bug#998867: debootstrap: --no-merged-usr became a no-op

[Johannes Schauer Marin Rodrigues]

Hi,

the last maintainer action to this bug was 13 days ago, Adam Borowski points
out how this breaks buildds, Julien Cristau explains how this change has
undesired consequences elsewhere and it breaks my own package mmdebstrap. I saw
no changes related to this bug in the development git repository of
debootstrap. Devref 5.11.1. states:

> Upload fixing only release-critical bugs older than 7 days, with no
> maintainer activity on the bug for 7 days and no indication that a fix is in
> progress: 0 days

I just directly uploaded a NMU of debootstrap with the attached debdiff.

Thanks!

cheers, joschdiff -Nru debootstrap-1.0.126/debian/changelog debootstrap-1.0.126+nmu1/debian/changelog
--- debootstrap-1.0.126/debian/changelog	2021-11-08 15:40:06.0 +0100
+++ debootstrap-1.0.126+nmu1/debian/changelog	2021-11-28 12:38:15.0 +0100
@@ -1,3 +1,10 @@
+debootstrap (1.0.126+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Undo the changes of the last upload. (Closes: #998867)
+
+ -- Johannes Schauer Marin Rodrigues   Sun, 28 Nov 2021 12:38:15 +0100
+
 debootstrap (1.0.126) unstable; urgency=low
 
   * Ensure bookworm+ suites are set up with merged-usr. (Closes: #978636)
diff -Nru debootstrap-1.0.126/debootstrap.8 debootstrap-1.0.126+nmu1/debootstrap.8
--- debootstrap-1.0.126/debootstrap.8	2021-11-08 15:39:56.0 +0100
+++ debootstrap-1.0.126+nmu1/debootstrap.8	2021-11-28 12:38:11.0 +0100
@@ -93,7 +93,7 @@
 .IP
 .IP "\fB\-\-no-merged-usr\fP"
 Do not create /{bin,sbin,lib}/ symlinks pointing to their counterparts in /usr/.
-(Default for the buildd variant on suites older than bookworm.)
+(Default for the buildd variant.)
 .IP
 .IP "\fB\-\-keyring=KEYRING\fP"
 Override the default keyring for the distribution being bootstrapped,
diff -Nru debootstrap-1.0.126/scripts/debian-common debootstrap-1.0.126+nmu1/scripts/debian-common
--- debootstrap-1.0.126/scripts/debian-common	2021-11-08 15:39:56.0 +0100
+++ debootstrap-1.0.126+nmu1/scripts/debian-common	2021-11-28 12:38:11.0 +0100
@@ -43,9 +43,10 @@
 }
 
 first_stage_install () {
-	# Set up correct EXTRACT_DEB_TAR_OPTIONS
 	case "$CODENAME" in
+		# "merged-usr" blacklist for past releases
 		etch*|lenny|squeeze|wheezy|jessie*)
+			[ -z "$MERGED_USR" ] && MERGED_USR="no"
 			;;
 		*)
 			# see https://bugs.debian.org/838388
@@ -53,17 +54,10 @@
 			;;
 	esac
 
-	case "$CODENAME" in
-		# If not specified, default to split-usr on older releases
-		etch*|lenny|squeeze|wheezy|jessie*|stretch|ascii|buster|beowulf|bullseye)
-			[ -z "$MERGED_USR" ] && MERGED_USR="no"
-			;;
-		# Always use merged-usr on bookworm+ and its derivatives
-		*)
-			MERGED_USR="yes"
-			;;
-	esac
-
+	if [ "$CODENAME" = "stretch" ] && [ -z "$MERGED_USR" ]; then
+		MERGED_USR="no"
+	fi
+		
 	setup_merged_usr
 	extract $required
 


signature.asc
Description: signature

Bug#998867: debootstrap: --no-merged-usr became a no-op

[Johannes Schauer Marin Rodrigues]

Control: affects -1 mmdebstrap

Hi,

Quoting Dimitri John Ledkov (2021-11-15 14:54:36)
> > Please point out what you plan to do about this change in debootstrap so
> > that I can adapt the mmdebstrap autopkgtest accordingly.
> 
> I did notice the mmdebstrap autopkgtest regression. [...]

this bug has now been open and RC for 10 days. Those are 10 days in which I
will not notice any other possible regression in mmdebstrap because its
autopkgtest fails early. Until I know how you plan to address this bug I cannot
fix the problem in mmdebstrap because any possible fix would only be able to
migrate after debootstrap with whatever solution is chosen to this bug
migrates. So please either:

 a) decide that this bug is not RC and thus let debootstrap with its current
 behaviour migrate to testing or

 b) tell me what other solution you see in the bug -- i can even contribute a
 patch if you tell me how you want this bug solved

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#998867: debootstrap: --no-merged-usr became a no-op

[Johannes Schauer Marin Rodrigues]

Quoting Julien Cristau (2021-11-09 09:33:14)
> On Tue, Nov 09, 2021 at 07:49:03AM +0100, Johannes Schauer Marin Rodrigues 
> wrote:
> > since 1.0.126 the --no-merged-usr option became a no-op if for any code
> > name but
> > etch*|lenny|squeeze|wheezy|jessie*|stretch|ascii|buster|beowulf|bullseye
> > 
> > This means that I cannot create a Debian chroot from Debian unstable
> > from 10 years ago from snapshot.debian.org without merged-/usr and thus
> > my chroot will behave differently as it did back then.
> > 
> > Please re-enable --no-merged-usr so that I can re-create old chroots
> > from snapshot.d.o again.
> > 
> Also, build chroots must still be created without merged-usr for
> sid/bookworm, until something's been done to migrate user systems.

Furthermore, you see a regression in the mmdebstrap autopkgtest due to this
version: https://tracker.debian.org/pkg/debootstrap

That regression is to this change of --no-merged-usr. Please point out what you
plan to do about this change in debootstrap so that I can adapt the mmdebstrap
autopkgtest accordingly.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#998867: debootstrap: --no-merged-usr became a no-op

[Johannes Schauer Marin Rodrigues]

Package: debootstrap
Version: 1.0.126
Severity: important

Hi,

since 1.0.126 the --no-merged-usr option became a no-op if for any code
name but
etch*|lenny|squeeze|wheezy|jessie*|stretch|ascii|buster|beowulf|bullseye

This means that I cannot create a Debian chroot from Debian unstable
from 10 years ago from snapshot.debian.org without merged-/usr and thus
my chroot will behave differently as it did back then.

Please re-enable --no-merged-usr so that I can re-create old chroots
from snapshot.d.o again.

Thanks!

cheers, josch

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Holger Levsen (2021-04-09 10:34:53)
> On Fri, Apr 09, 2021 at 08:20:42AM +0300, ValdikSS wrote:
> > 1. To speed up base system install (the first installation step),
> > debootstrap should be improved to use libeatmydata for internal dpkg call. 
> > [...]
> 
> or maybe mmdebstrap could be used instead? AFAIK it doesn't use libeatmydata
> but achieves the same by other means.
> 
> I don't know how feasable creating an udeb for it (and it depends/recommends)
> is, cc:ing the author for input.

the problem is, that mmdebstrap by its nature requires Perl and apt and neither
have a udeb as of today. There is a bug about this wishlist feature:

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

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#953759: debootstrap: mandatory security support breaks too many things

[Johannes Schauer]

Hi,

Quoting Tianon Gravi (2020-03-13 08:05:11)
> On Thu, 12 Mar 2020 at 18:27, Cyril Brulebois  wrote:
> > The latest batch of bug reports filed by Johannes 'josch' Schauer seems
> > to confirm my initial assessment: this will break (too) many use cases
> > (#953404, #953588, #953593, #953594, #953617).
> +1, thanks (to you both) for doing this -- my first thought seeing these
> changes was that this would have a pretty strong negative effect on the
> debian-installer (especially folks using the larger CDs to avoid the
> internet).
> 
> I wonder if we could reasonably hook up josch's mmdebstrap tests via Salsa's
> CI for MRs and commits to debootstrap?  That seems like it would help avoid
> these types of regressions for adding new features like this in a safer
> manner.

better write a more comprehensive autopkgtest suite for debootstrap and test
for the things that you are actually interested in. To find the problems this
commit introduced, it would've been enough to add simple smoke tests for each
of the debootstrap options (mmdebstrap only tests few of them) and then run
debootstrap for unstable, testing, stable and oldstable -- verifying that they
give a non-zero exit code.

The plan for mmdebstrap is to go away once there is the "apt-get bootstrap"
command at some point in the future.  Also, mmdebstrap's test can break for a
multitude of other reasons unrelated to debootstrap, so this is not a good
idea.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#953404: debootstrapping testing and stable results in exit 100

[Johannes Schauer]

Hi,

Quoting Cyril Brulebois (2020-03-09 06:47:49)
> Johannes 'josch' Schauer  (2020-03-09):
> > Package: debootstrap
> > Version: 1.0.120
> > Severity: grave
> > Justification: renders package unusable
> > 
> > Hi,
> > 
> > steps to reproduce:
> > 
> > $ sudo debootstrap --variant=minbase stable debian-stable
> > [...]
> > $ echo $?
> > 100
> > 
> > It works for unstable though.
> 
> Thanks for filing the RC bug, I was just wondering whether to do that on
> my own. See review just sent to debian-boot@:
>   https://lists.debian.org/20200309054441.2i32ierzl5b6k...@mraw.org

Thank you for that! I agree with your analysis. Here some further comments:

> Finally, looking at CI, runtime indeed doesn't look too good:
> [...]
> from 
> 

That problem is easily fixed by fixing the sed call in enable_pockets() here:

https://sources.debian.org/src/unattended-upgrades/1.17/debian/tests/common-functions/

More worrysome I found the problem of the autopkgtest failure of debuerreotype
which fails because the release file is expired. There is nothing the
debuerreotype autopkgtest can do about this other than patching
/usr/sbin/debootstrap before running the test. I reported the problem here:

https://bugs.debian.org/953617

My package mmdebstrap has a similar problem. During my autopkgtest I am setting
up a mirror that does not include translations (because they are not needed for
the tests so why download unnecessary data) and the "apt-get update" will fail
because it cannot find the translations. Again there is no way to override this
(the APT_CONFIG environment variable is ignored) and I resorted to running:

$ sed -i 's/apt-get update/apt-get -o Acquire::Languages=none update/' 
/usr/sbin/debootstrap

Before running debootstrap in mmdebstrap's autopkgtest. This is not optimal and
should not be necessary. I filed a bug here:

https://bugs.debian.org/953588

Furthermore it is no longer possible to create a Debian chroot from
snapshot.debian.org because the "apt-get upgrade" call will always attempt
installing current packages and thus pollute the snapshot with newer packages:

https://bugs.debian.org/95359

And the --no-check-gpg and --keyring options do not work anymore because even
if they are passed to debootstrap, they are not passed onwards to apt:

https://bugs.debian.org/953593

Some of these problems can be solved by allowing to pass custom options to apt
but the snapshot.debian.org usecase cannot be made working again without a new
option that allows to disable running "apt-get upgrade" at the end. I think it
is important to be able to create a chroot from snapshot.debian.org so I think
the only way to achieve this is to either revert this change completely or to
add a new option allowing to disable this "feature".

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#953588: debootstrap: fails for mirrors without translations

[Johannes Schauer]

Control: block 953592 by -1

On Tue, 10 Mar 2020 23:04:03 +0100 Johannes 'josch' Schauer  
wrote:
> recent debootstrap fails silently if the given mirror does not contain
> translations.

this breaks the autopkgtest of mmdebstrap, thus adding the blocking bug.

It seems that even creating an APT_CONFIG with ' Acquire::Languages "none";' in
it gets ignored. Maybe the environment is somehow cleaned before debootstrap
calls apt-get?

signature.asc
Description: signature

Bug#953404: debootstrapping testing and stable results in exit 100

[Johannes Schauer]

Hi,

Quoting Cyril Brulebois (2020-03-09 06:47:49)
> Johannes 'josch' Schauer  (2020-03-09):
> > Package: debootstrap
> > Version: 1.0.120
> > Severity: grave
> > Justification: renders package unusable
> > 
> > Hi,
> > 
> > steps to reproduce:
> > 
> > $ sudo debootstrap --variant=minbase stable debian-stable
> > [...]
> > $ echo $?
> > 100
> > 
> > It works for unstable though.
> 
> Thanks for filing the RC bug, I was just wondering whether to do that on
> my own. See review just sent to debian-boot@:
>   https://lists.debian.org/20200309054441.2i32ierzl5b6k...@mraw.org
> 

that doesn't seem to be online yet.

>From the debootstrap.log:

+ chroot /home/josch/debian-stable /usr/bin/apt-get update
Hit:1 http://deb.debian.org/debian stable InRelease
Ign:2 http://security-cdn.debian.org/debian-security stable-security InRelease
Err:3 http://security-cdn.debian.org/debian-security stable-security Release
  404  Not Found [IP: 151.101.112.204 80]
Get:4 http://deb.debian.org/debian stable/main Translation-en [5970 kB]
Reading package lists...
E: The repository 'http://security.debian.org/debian-security stable-security 
Release' does not have a Release file.


Using stable-security is wrong, at least for all releases before bullseye. See
this announcement:

https://lists.debian.org/debian-devel-announce/2019/07/msg4.html

So for everything before bullseye it should be stable/updates and not
stable-security.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#934713: os-prober: missing dependency on mount

[Johannes Schauer]

Hi,

Quoting Cyril Brulebois (2019-08-15 16:44:05)
> > Version 2.29.2-3 was released more than two years ago. It was brought up on
> > debian-devel here:
> > 
> > https://lists.debian.org/20170726081846.ga22...@fatal.se
> 
> Well, debian-devel@ isn't where one files bug reports against packages that
> suddenly need a dependency?

I was not trying to justify or excuse the omission of the src:util-linux
maintainers. I can only imagine that os-prober somehow slipped through the
cracks when the src:util-linux maintainers filed bugs against all packages that
need the mount utilities during the buster release cycle.

I agree that the situation now is unfortunate but I only reported this problem
once I stumbled across it. I was not involved in the decision two years ago.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#934713: os-prober: missing dependency on mount

[Johannes Schauer]

Quoting Cyril Brulebois (2019-08-15 15:50:03)
> > The script /usr/lib/os-probes/50mounted-tests calls the `umount` utility
> > which resides in the mount package. But os-prober does not depend on mount
> > and thus one might get this error message:
> > 
> > Generating grub configuration file ...
> > Found linux image: /boot/vmlinuz-5.2.0-2-amd64
> > Found initrd image: /boot/initrd.img-5.2.0-2-amd64
> > /usr/lib/os-probes/50mounted-tests: 10: umount: not found
> > rmdir: failed to remove '/var/lib/os-prober/mount': Device or resource busy
> > 
> > 
> > The mount package used to be Essential:yes. Since version 2.29.2-3 it is
> > not essential anymore and os-prober should depend on it.
> 
> How come packages drop their Essential: yes bit all of a sudden?

Version 2.29.2-3 was released more than two years ago. It was brought up on
debian-devel here:

https://lists.debian.org/20170726081846.ga22...@fatal.se

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#930428: debootstrap should ensure matching _apt uid

[Johannes Schauer]

Hi all,

Quoting Philipp Kern (2019-06-23 15:14:34)
> On 2019-06-21 07:51, Trek wrote:
> >> If _apt deserves a special solution, I would suggest assigning the
> >> _apt user a static uid instead of patching debootstrap.
> > it seems to me the simplest approach, from a technical point of view,
> > and it's the one I'm using since _apt user was introduced (making sure
> > uids match)
> Adding deity@l.d.o. APT maintainers, please see the context in the bug. 
> Do you think there should be logic in debootstrap to handle the case of 
> trying to have the same UID within a chroot and outside, or could you 
> apply for a static UID assignment? I would also prefer the latter, but I 
> honestly don't know how messy the migration would be...

with my mmdebstrap-maintainer hat on, I wanted to quickly chime in and express
my support for the _apt user having a reproducible user id. The status quo is,
that the apt user id depends on the order in which the maintainer scripts are
executed. Because of this I had to disable some mmdebstrap tests where I
compare the mmdebstrap chroot against the debootstrap chroot because the _apt
uid would be different. One of the goals of mmdebstrap is to be a
proof-of-concept of moving more and more of the mechanics that are currently
hardcoded in debootstrap into apt and dpkg. So from my perspective, fixing the
_apt uid is one piece of the puzzle that would make the life of debootstrap
alternatives like mmdebstrap easier.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#829134: debootstrap: Changes needed to support unprivileged userns debootstrap

[Johannes Schauer]

Hi,

On Thu, 08 Sep 2016 15:39:57 +0200 Johannes Schauer  wrote:
> On Thu, 30 Jun 2016 13:12:16 -0700 Ben Longbons  wrote:
> > Now that the kernel supports user_namespaces(7), it should be possible to
> > debootstrap in them. Some small changes are needed.
> > 
> > Configuration needed:
> > * Kernel 3.8 or later (3.11 recommended)
> > * Set the sysctl kernel.unprivileged_userns_clone to 1
> > (Debian-specific "temporary" patch from years ago).
> > * Install the `uidmap` package and add yourself to /etc/sub[ug]id
> > * Install the `lxc` package (for one helper binary only)
> > * Make sure the current directory is searchable by other.
> > 
> > I have attached the necessary changes as a wrapper script,
> 
> I find your script highly interesting!
> 
> A year ago I tried to write a tool that combined the powers of
> lxc-usernsexec(1) and unshare(1) because I was unable to combine them in a way
> that would give me both: correct mapping of user and group ids as well as
> unsharing the user namespace and others. I blogged about it here:
> 
> https://blog.mister-muffin.de/2015/10/25/unshare-without-superuser-privileges/
> 
> and the code is here:
> 
> https://gitlab.mister-muffin.de/josch/user-unshare/blob/master/user-unshare
> 
> I do not know whether what you demonstrated now in shell already worked one
> year ago (in particular I was not aware of the lxc-unshare tool) but your
> script works fine for me. I'm happy that it seems that I don't have to further
> dabble with the perl code I came up with because lxc-usernsexec and 
> lxc-unshare
> seem to be able to do the major grunt work while the rest can be done in 
> simple
> POSIX shell. Thank you!

The disadvantage of the lxc-usernsexec and lxc-unshare tools is, that they are
part of the lxc package. See bug #847491.

> I wonder though: why would this feature be useful for debootstrap? The
> resulting directory would have all the wrong ownership information. The
> directory would only be useful if its user knows exactly how to map the user
> ids between the host and the unshared user namespace.
> 
> So my practical question:
> 
> How do you use the chroots that you create in this fashion? Which commands do
> you use to work with them?

To answer my own question: by packing up the chroot into a tarball. The files
stored inside the tarball will have the correct permission.

I combined the insights from your tool with the Perl script I wrote and cited
above and added support to sbuild-createchroot to run debootstrap without
needing sudo but using Linux user namespaces.

Since debootstrap does not yet offer this functionality itself, I will carry
the code as part of sbuild. See the following two commits for details:

https://salsa.debian.org/debian/sbuild/commit/f21d63cca448a5fc90338319e2ea507623293060?expanded=1
https://salsa.debian.org/debian/sbuild/commit/53e250cdeb0035663833fa0c8ce80adf96d31c03?expanded=1

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer]

Hi,

Quoting Cyril Brulebois (2017-06-24 20:23:25)
> Julien Cristau  (2016-09-12):
> > This is a transient situation because some Essential packages'
> > dependencies changed.  I'd consider this a bug in the archive, not in
> > debootstrap.
> Any reasons to keep this bug report open then? Seen no objections, so I'm
> tempted to close it.

But... the buildd variant still explicitly (and not only implicitly through
dependencies of essential:yes packages) installs Priority:required packages,
no?

cheers, josch


signature.asc
Description: signature

Bug#849168: pbuilder: Expect programe reported "no more ptys" and failed in rebuilding gcc with normal (non-root) user

[Johannes Schauer]

Hi James,

Quoting James Clarke (2016-12-23 16:27:02)
> Josch, I'm curious as to why you tagged the corresponding sbuild bug report
> (Cc'd) as unreproducible; are you using debootstrap from stable?

I did not anticipate that I would have to first re-create my existing Stretch
chroot to be able to reproduce the bug. Thus, I used my existing chroot which
was created in the past with an older version of debootstrap.

> Anyway, I suggest you also merge the build bug with the debootstrap one.

Can you be more precise of what you want me to merge?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer]

Hi,

On Thu, 08 Sep 2016 19:40:15 +0200 Sven Joachim  wrote:
> Looking at the code in scripts/sid, it is "x_core_install mawk" which
> fails here.  The reason is that mawk has not been downloaded,
> debootstrap's limited dependency resolver cannot resolve base-files'
> pre-dependency on awk.
>
> The good news is that with "--include=mawk" added to the commandline,
> debootstrap succeeds and does not include tzdata or lsb-base in the
> chroot. :-)
>
> So changing base-files to Pre-depend on mawk | awk seems to be the only
> blocker here.  Would you like to file a blocking bug on base-files?

I don't see why this is a bug in base-files. As far as I can see, base-files
properly declares its pre-dependency on the virtual package awk. That
debootstrap is unable to understand basic Debian dependency constructs (we are
not even talking multiarch here) is a bug in debootstrap.

This is also the point where I wonder how much sense it makes to have yet
another resolver of Debian's complex dependency mechanism around. It's one of
the reasons why I often use multistrap instead of debootstrap because the
former uses apt which already implements all the required dependency logic.

If debootstrap wants to depend on its own resolver, then it has to make sure
that it is up to the task of dealing with Debian's dependency system. So in
summary, I think this is a bug in debootstrap and not in base-files.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#829134: debootstrap: Changes needed to support unprivileged userns debootstrap

[Johannes Schauer]

Hi Ben,

On Thu, 30 Jun 2016 13:12:16 -0700 Ben Longbons  wrote:
> Now that the kernel supports user_namespaces(7), it should be possible to
> debootstrap in them. Some small changes are needed.
> 
> Configuration needed:
> * Kernel 3.8 or later (3.11 recommended)
> * Set the sysctl kernel.unprivileged_userns_clone to 1
> (Debian-specific "temporary" patch from years ago).
> * Install the `uidmap` package and add yourself to /etc/sub[ug]id
> * Install the `lxc` package (for one helper binary only)
> * Make sure the current directory is searchable by other.
> 
> I have attached the necessary changes as a wrapper script,

I find your script highly interesting!

A year ago I tried to write a tool that combined the powers of
lxc-usernsexec(1) and unshare(1) because I was unable to combine them in a way
that would give me both: correct mapping of user and group ids as well as
unsharing the user namespace and others. I blogged about it here:

https://blog.mister-muffin.de/2015/10/25/unshare-without-superuser-privileges/

and the code is here:

https://gitlab.mister-muffin.de/josch/user-unshare/blob/master/user-unshare

I do not know whether what you demonstrated now in shell already worked one
year ago (in particular I was not aware of the lxc-unshare tool) but your
script works fine for me. I'm happy that it seems that I don't have to further
dabble with the perl code I came up with because lxc-usernsexec and lxc-unshare
seem to be able to do the major grunt work while the rest can be done in simple
POSIX shell. Thank you!

I wonder though: why would this feature be useful for debootstrap? The
resulting directory would have all the wrong ownership information. The
directory would only be useful if its user knows exactly how to map the user
ids between the host and the unshared user namespace.

So my practical question:

How do you use the chroots that you create in this fashion? Which commands do
you use to work with them?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#837060: debootstrap: Do not install packages of Priority:required for buildd variant

[Johannes Schauer]

Package: debootstrap
Version: 1.0.81
Severity: normal

Hi,

in Debian, every binary package implicitly depends on all binary
packages marked as Essential:yes and every source package implicitly
build-depends on the binary package build-essential. Policy §4.2 says:

 | it must be possible to build the package and produce working binaries
 | on a system with only essential and build-essential packages installed
 | and also those required to satisfy the build-time relationships
 | (including any implied relationships).

Currently, programs in Debian that facilitate building source packages
in "clean" environments like sbuild and pbuilder use debootstrap to
create this "minimal" environment. Specifically, they use the buildd
variant provided by debootstrap.

Unfortunately it seems that in addition to installing the minimum
required packages (all Essential:yes, build-essential and (unfortunately
necessarily) apt), debootstrap also installs all packages marked as
Priority:required (and their transitive dependencies).

Thus, it can easily happen that source packages in Debian do not
correctly declare their build dependencies on packages that are
Priority:required because they happen to always be installed in
virtually any environment that the source package will probably ever be
built in (because they were all created by debootstrap).

I think this is a bug in the package list installed by the buildd
variant. Since the buildd variant is meant to provide a clean and
minimal environment to build source packages, it should try hard not to
install any extra packages which would then make it impossible to test
whether a source package is policy compliant in the build dependencies
it declares.

Thank you!

cheers, josch

Bug#833525: debootstrap: Deleted my entire /home partition using "mostly harmless" debootstrap --print-debs option

[Johannes Schauer]

Control: tag -1 + patch

On Fri, 05 Aug 2016 13:55:14 +0100 Brian Drummond  
wrote:
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 0) Okay, this will be embarrassing...
> 1) Occasional need to work on i386 software on an x86-64 machine.
> 2) Previous experiment led to a marginally usable "minimal"  /chroot/i386 
> partition (without internet connection)
> 3) Desire to add internet connection to same, start by listing packages which 
> would be installed by "debootstrap --print-debs"
> 4) Failure to understand that "debootstrap --print-debs" operated by 
> performing the entire debootstrap operation, 
> listing packages, then deleting the created directory, despite a note in the 
> manfile to that effect.
> 5) Further failure to note that such deletion would apply recursively to any 
> automounted partitions in said created directory. 
> 6) Previous experiment involved automounting /proc, /sys, /var/tp, and /home 
> into said /chroot/i386 partition.
> 7) Re-using the /chroot/i386 directory name in the "debootstrap 
> --print-files" command. Without the --keep-bootstrop-dir option, since I was 
> about to replace it.
> 8) I said this was embarassing...
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Sadly, I no longer have my exact notes, as will become clear. But 
> approximately, the command was (possibly with sudo, or after su):
> debootstrap --print-debs /chroot/i386
> 
>* What was the outcome of this action?
> Well I briefly saw the list of packages flash past, before debootstrap got to 
> the "The TARGET directory will be deleted" part.
> At which point various strange things started happening, until it gradually 
> dawned on me that /home and /var/tmp were slowly disappearing before my 
> eyes...
> 
>* What outcome did you expect instead?
> 
> Somehow I expected to be left with a list of .deb packages and a functioning 
> computer. I now understand my expectations were unrealistic.
> 
> Perhaps I have been punished enough ... and perhaps it would be a good idea 
> to modify the bit of debootstrap that implements 
> "The TARGET directory will be deleted" and convince it to stop at 
> automounted partitions in /etc/fstab (and/or mtab)?
> 
> It is too late for me, but it might be very pleasing to some future unwary 
> operators to be left with their /home partition intact... 
> 
> (NB the packages/versions listed below apply to a reinstall, not the exact 
> formerly-running system, for reasons that are hopefully clear)

if I understand correctly, the problem is two-fold:

 - debootstrap removes everything in a directory even if there was stuff in it
   beforehand (this should not happen)

 - debootstrap removes recursively across filesystem boundaries (how was this
   not noticed earlier?)

The following patch should fix this:


@@ -409,6 +409,11 @@
fi
 fi
 
+TARGET_EMPTY=true
+if [ "$(ls -A "$TARGET")" ]; then
+   TARGET_EMPTY=false
+fi
+
 ###
 
 if in_path dpkg && \
@@ -698,8 +703,8 @@
 fi
 
 if am_doing_phase kill_target; then
-   if [ "$KEEP_DEBOOTSTRAP_DIR" != true ]; then
+   if [ "$KEEP_DEBOOTSTRAP_DIR" != true && "$TARGET_EMPTY" == true ]; then
info KILLTARGET "Deleting target directory"
-   rm -rf "$TARGET"
+   rm -rf --one-file-system "$TARGET"
fi
 fi


Thanks!

cheers, josch


signature.asc
Description: signature

Bug#807312: src:debian-installer: please provide binary package for use by debian-installer-netboot-images

[Johannes Schauer]

Hi,

On Mon, 07 Dec 2015 10:20:32 +0100 Ansgar Burchardt  wrote:
> Jonas Smedegaard  writes:
> > debian-installer-netboot-images currently violates Debian Policy by
> > fetching debian-installer images over the network during install - see
> > bug#807168.
> >
> > I believe¹ that debian-installer produces those pieces needed by
> > debian-installer-netboot-images, and suspect that providing in a binary
> > package the pieces needed for debian-installer-netboot-images could (at
> > least partially) solve bug#807168.
> >
> > This bug marked important (not wishlist) as bug#807168 is RC.
> 
> I don't think its so easy: d-i-n-i are arch:all packages, but need
> binaries for all architectures.  To get these as build-dependencies we
> would need cross-arch build-deps which we don't have so far.

what do you mean by that? Source packages like cross-gcc-4.9-armhf *do* have
cross-arch build-deps. Were you talking about missing support in britney to
properly transition source packages with cross-arch build-deps? Is there a bug
about this open somewhere?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#698347: debootstrap: New variant based on PRoot

[Johannes Schauer]

Hi,

On Thu, 17 Jan 2013 13:20:14 +0100 =?utf-8?q?R=C3=A9mi_Duraffort?= 
 wrote:
> For this reason, I patched debootstrap so it can create a rootfs using PRoot.
> This rootfs is then used for validating software in debian environment. Be
> careful that this new rootfs will not have the normal rights (root:root for
> /bin for instance) and should only be used for testing (with chroot or
> PRoot).

I would like to propose to add this feature in a different way. Instead of
adding a new --variant=proot option, add options that lets users run
debootstrap in a mode that does not set up /dev and /proc or otherwise does
stuff that strictly requires superuser privileges.

Doing it that way round would have a two advantages:

 - it would not further clutter the --variant option which is already
   overloaded with setting meaning "install these packages" (minbase, buildd)
   as well as "execute debootstrap in this mode" (fakeroot, scratchbox). There
   is no easy way to activate both fakeroot and minbase, for example even
   though there should.

 - it would magically also fix bug #731802 (debootstrap fails under LXC because
   mknod fails)

If more things that debootstrap does could be influenced via command line in a
more fine-grained way than the --variant option allows to, debootstrap could
run in a number of non-root setups like proot, fakeroot or lxc instead of
adding yet more --variant options for each new use case as they come up.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#731802: debootstrap: Doesn't work in LXC containers

[Johannes Schauer]

Hi,

On Mon, 09 Dec 2013 21:41:23 + MegaBrutal  wrote:
> I thought to build a Debian chroot in an LXC container, but it fails. From
> the debootstrap.log it turns out, debootstrap tries to create devices with
> MAKEDEV, but it fails with "Operation not permitted". I run debootstrap under
> root within an LXC container, seems LXC doesn't support the creation of
> devices. It would be nice to work around this problem, e.g. by adding a
> --variant option which is compatible with LXC. Now I can choose another way
> to build a custom Debian installation, still it would be useful to be able to
> build chroots even within containers.

this might be related to #698347 in that the changes made to debootstrap in
that bug would most likely also fix this bug.

So maybe instead of adding a --variant=proot option as explained in #698347 it
would make sense to add switches which allow to turn off some things
debootstrap does so that it works with proot as well as under lxc.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#787044: libdebian-installer: please make new Build-Depends: check optional via build profiles

[Johannes Schauer]

Hi,

On Fri, 29 May 2015 00:34:18 +0200 Cyril Brulebois k...@debian.org wrote:
 Helmut Grohne hel...@subdivi.de (2015-05-28):
  You may be aware that libdebian-installer is considered transitively
  build-essential.
 
 I wasn't.

If one wants to build build-essential from scratch without relying on packages
from the archive (bootstrap scenario) then one has to recursively build its
build dependencies, the build dependencies of these, and so on and so forth.
The set of source package one then ends up with is currently at least 818
source packages big for Debian unstable amd64. I say at least because A|B
type dependencies and Provides: relationships allow different selections to
satisfy dependencies. The maximum number is 1135 source packages.

src:libdebian-installer is in the smaller set. So it is *not* optional by
choosing a different alternative or Provides. It is also required whether or
not one relies on existing Architecture:all packages or not. You can see a list
of all source packages in the transitively build-essential set here:

http://bootstrap.debian.net/essential.html

That page does not yet provide an explanation which dependency path makes them
being included because I didn't yet have the time to generate this information.
But for src:libdebian-installer, the reason is, that it is in the strong
dependency set of src:cdebconf which in turn is needed by build-essential
because of libdebconfclient0 which is needed by base-passwd.

  [1] https://wiki.debian.org/BuildProfileSpec
 
 How stable is this spec,

the syntax itself was set in stone (in the wiki page) at 2014-08-31 (which was
during the bootstrap sprint in paris) together with guillem who encoded this in
dpkg. All changes you see to that spec after this date are either

 - rewording to make hard to understand parts easier to read

 - add examples

 - expand the table of software that implements the syntax

 - adding new ideas of scenarios build profiles can be used in

As the main author of the spec I'd say that the only things that could possibly
be changed during this release cycle are the amount of permissible build
profile names (if the need for a new one comes up). This would not affect the
patch submitted by Helmut in this bug because the nocheck build profile name
was always needed and part of the spec.

The spec staying stable in its core (the syntax and fields) is furthermore
enforced by the fact that if something were to change now, then it would delay
the possibility of uploading packages with build profiles again until after the
release of Stretch in ~2 years. And we really don't want that :)

So there is no plan to touch this thing in any other way than making things
more clear in places where it was not.

The syntax is not policy yet (bug #757760) but I'd compare this situation to
Multi-Arch which is also not policy yet but also has always only existed as a
wiki page and still is widely used in the archive. I plan to help getting build
profiles into policy during this release cycle.

 and how much is that syntax supported by Debian's tools

You can see an overview of tool support for the build profile syntax in the
table at the top of the spec:

https://wiki.debian.org/BuildProfileSpec

Most notably, build profile support is missing in pbuilder until somebody
applies the latest patch which fixes that situation in bug #740577. Until then
one should either build without a chroot or use sbuild.

/infra?

It's hard to test our infrastructure before things get deployed but luckily
another package using the build profile syntax in its Build-Depends has been
uploaded recently: gem2deb.  That helped us spot some remaining bits which did
not support the new syntax (#786400 and #787093) but as you can see, the former
is fixed and the latter has a working patch and since I'm in contact with
Antonio I think it will be applied quickly.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#731859: debootstrap: variant=fakechroot fails

[Johannes Schauer]

Package: debootstrap
Version: 1.0.55
Severity: normal

Running debootstrap under Debian Sid yields:

$ fakeroot fakechroot debootstrap --verbose --variant=fakechroot sid debian-sid
[...]
I: Installing core packages...
W: Failure trying to run: chroot /home/josch/debian-sid dpkg --force-depends 
--install /var/cache/apt/archives/base-files_7.2_amd64.deb 
/var/cache/apt/archives/base-passwd_3.5.28_amd64.deb
W: See /home/josch/debian-sid/debootstrap/debootstrap.log for details (possibly 
the package archive is at fault)

And the last lines of the log say:

dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing description
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg':
 missing architecture
dpkg: regarding .../base-files_7.2_amd64.deb containing base-files, 
pre-dependency problem:
 base-files pre-depends on awk
  awk is not installed.

dpkg: warning: ignoring pre-dependency problem!
Selecting previously unselected package base-files.
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack .../base-files_7.2_amd64.deb ...
Unpacking base-files (7.2) ...
rm: cannot remove '/var/lib/dpkg/tmp.ci': Directory not empty
dpkg: error while cleaning up:
 subprocess rm cleanup returned error exit status 1
rm: cannot remove '/var/lib/dpkg/tmp.ci': Directory not empty
dpkg: error processing archive 
/var/cache/apt/archives/base-passwd_3.5.28_amd64.deb (--install):
 subprocess rm cleanup returned error exit status 1
dpkg: base-files: dependency problems, but configuring anyway as you requested:
 base-files depends on awk; however:
  Package awk is not installed.

chown: invalid user: 'root:root'
dpkg: error processing package base-files (--install):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/base-passwd_3.5.28_amd64.deb
 base-files
Setting up base-files (7.2) ...


cheers, josch


-- 
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/20131210144833.27986.22338.reportbug@hoothoot

Bug#648781: debian-installer: unattended installation using preseed is interrupted by installer main menu popping up

[Johannes Schauer]

Package: debian-installer
Version: 20110106+squeeze3+b1
Severity: normal
Tags: sid

When using this preseed file:

http://mister-muffin.de/debian/preseed.txt

after the Install the base system step this appears and interrupts the
installation, prompting for user input:

http://mister-muffin.de/p/Ai7F.png

Also notice the wrong menu entries.

The same error happens with more minimal preseed files.

It turns out that the problem only occurs when having:

d-i mirror/suite string sid
d-i mirror/udeb/suite string sid

When choosing wheezy instead, everything is fine.

I gathered debug output with the DEBCONF_DEBUG=developer option and with
this preseed file:

http://mister-muffin.de/debian/preseed2.txt

(which will produce the following interrupting main menu:
http://mister-muffin.de/p/qlbd.png)

Here is the syslog from the point where the menu appeared:

http://mister-muffin.de/p/a1nJ.txt

And here a tarball of the directory, which is created after hitting
save debug logs in the main menu:

http://mister-muffin.de/p/sS_r



-- 
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/2015003910.8612.72116.reportbug@hoothoot

Bug#621077: keyboard-configuration: postinst script needs initscripts to be installed

[Johannes Schauer]

Package: keyboard-configuration
Version: 1.68
Severity: normal


hi,

when installing keyboard-configuration on a system without the initscripts 
package
installed I get the following error:

Setting up keyboard-configuration (1.72) ...
insserv: Service mountkernfs has to be enabled to start service keyboard-setup
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing keyboard-configuration (--configure):
 subprocess installed post-installation script returned error exit status 1

mountkernfs is provided by the initscripts package so keyboard-configuration 
should
either depend on initscripts or not fail without it, right?



-- 
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/20110406104135.9886.22817.reportbug@hoothoot