Bug#930428: debootstrap should ensure matching _apt uid

[Ansgar Burchardt]

Philipp Kern writes:
> 20/06/2019 20:22, Ansgar Burchardt wrote:
>> You look up which uid the _apt user inside the chroot has and use that.
>
> Yeah, but that scales poorly if you have a centralized firewall
> policy. It means that you need to maintain dynamic rules. I know it's
> possible and you can dedicate a chain to it. At the same time I think
> this problem is actually common enough that it deserves a solution.

If _apt deserves a special solution, I would suggest assigning the _apt
user a static uid instead of patching debootstrap.

Ansgar

Bug#930428: debootstrap should ensure matching _apt uid

[Ansgar Burchardt]

Trek writes:
> Ansgar Burchardt wrote:
>> For limiting network access, I would recommend instead using network
>> namespaces (to only provide limited network access for all processes)
>> and/or user namespaces (if filtering for single UIDs is really
>> needed). These do not require any uids to match between in- and
>> outside.
>
> filtering out the root user is a pretty common security practice and
> setting an iptables rule on uids is simple for system administrators

So you don't run sshd (requires root with network access)?  That seems
rather uncommon to me.

> using namespaces, how can you block any user but not the _apt user if it
> is not already created?

You look up which uid the _apt user inside the chroot has and use that.

> P.S.: the patch seems ok to me, I don't like hard-conding the _apt user
> line in /etc/passwd, as apt postinst uses adduser, but it's not clear
> to me when adduser is installed during debootstrap

You cannot use `adduser` as debootstrap might install binaries you
cannot execute (in the first stage).

But the effects of the patch are different from calling adduser, for
example the _apt user it creates has no entry in /etc/shadow.  Such
inconsistencies are not good.

Ansgar

Bug#930788: creating /var/lib/dpkg/cmethopt

[Ansgar Burchardt]

Package: apt,dselect
Severity: normal

Hi,

  [ X-Debbugs-Cc'ed -boot@ for debootstrap ]

today I learned that debootstrap as special code to create the file
/var/lib/dpkg/cmethopt (contents: "apt apt"); this is the function
setup_dselect_method in functions.  It seems wrong that debootstrap
has to know about such a particular detail.

Alternatives to debootstrap might also not create the file at all.

So I wonder if this could be created somewhere else.  An APT developer
said this is used by dselect and suggested to file a bug against
apt,dselect; he also had the idea that the file might be created in
dselect's postinst.

Ansgar

Bug#930428: debootstrap should ensure matching _apt uid

[Ansgar Burchardt]

Ansgar Burchardt writes:
> (I don't maintain debootstrap.)
>
> I don't think it is a good idea to require debootstrap to know about
> such details.
>
> For limiting network access, I would recommend instead using network
> namespaces (to only provide limited network access for all processes)
> and/or user namespaces (if filtering for single UIDs is really needed).
> These do not require any uids to match between in- and outside.

And sadly the submitter's address bounced my mail as the mail provider
the submitter uses cannot parse RFC-5321 mail addresses correctly.

Ansgar

Bug#930428: debootstrap should ensure matching _apt uid

[Ansgar Burchardt]

Michael Schaller writes:
> At the end of the 'apt' package installation the '_apt' user will be
> created without specifying a fixed uid. This typically results in a
> differing '_apt' uid between the host system and the bootstrapped
> system. The differing '_apt' uid is problematic in case the host
> system has firewall rules specific to the '_apt' user and that
> typically leads to Apt downloads failing inside a chroot.
>
> For more details see:
> * https://lists.debian.org/debian-devel/2019/04/msg00259.html
> * https://robots.org.uk/PbuilderFirewallSetup
>
> Unfortunately this issue isn't easy to detect/troubleshoot,
> particularly firewall rules on the '_apt' uid and that there is an uid
> mismatch inside a chroot. This could be improved a lot if debootstrap
> could avoid this issue if it would ensure that the '_apt' user in the
> bootstrapped system has the same uid as on the host system.

(I don't maintain debootstrap.)

I don't think it is a good idea to require debootstrap to know about
such details.

For limiting network access, I would recommend instead using network
namespaces (to only provide limited network access for all processes)
and/or user namespaces (if filtering for single UIDs is really needed).
These do not require any uids to match between in- and outside.

Ansgar

Re: Please dak copy-installer 20190118

[Ansgar Burchardt]

Cyril Brulebois writes:
> Joerg Jaspert  (2019-01-19):
>> On 15287 March 1977, Cyril Brulebois wrote:
>> > FTPmasters, please sync the installer from sid to testing:
>> > 
>> >   dak copy-installer 20190118
>> 
>> [ ] dak@fasolo:~$ dak copy-installer 20190118
>> 
>> Will copy installer version 20190118 from suite unstable to
>> testing.
>> Architectures to copy: i386, amd64, mipsel, ppc64el, mips, armel, armhf,
>> arm64, mips64el, hurd-i386
>> Architectures to skip:
>> Installer has been copied successfully.
>
> Thanks!
>
> I'm afraid I failed to misread the buildd status page before requesting
> this “dak copy-installer” round, as s390x buildds were lagging behind
> (zandonai had no daemon running); that's fixed now and debian-installer
> is currently marked as Uploaded on the buildd side, and I don't remember
> exactly when you can do the dak copy-installer dance. As soon as it's
> marked Installed on the buildd.d.o status page?

Done that now:

+---
| [ ] dak@fasolo:~$ dak copy-installer 20190118
|
| Will copy installer version 20190118 from suite unstable to
| testing.
| Architectures to copy: s390x, kfreebsd-i386
| Architectures to skip: i386, amd64, mipsel, ppc64el, mips, armel, armhf, 
arm64, mips64el, hurd-i386
| Installer has been copied successfully.
+---

Copying kfreebsd-* looks like a bug.  copy-installer should probably be
patched to only copy architectures that exist in testing.

Ansgar

Re: Please dak copy-installer 20181206

[Ansgar Burchardt]

Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20181206

Done.

Thanks for your work on d-i :-)

Ansgar

Re: Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Hi,

Hideki Yamane writes:
> On Sun, 2 Dec 2018 15:15:21 +
> Simon McVittie  wrote:
>> >   - What is the problem? (broken build for which packages? Just R?)
>> 
>> The problem we're aware of is:
>> 
>> Some packages auto-detect the absolute path to an executable (for example
>> bash or perl) and hard-code it into their output (for example the #! line
>> of the bash scripts in quilt).
>
>  Can we check and track this behavior in our packages?

The Reproducible Builds project was so kind to help and now runs one
build in a non-merged-/usr and a second build in a merged-/usr
environment.  Packages that hardcode the path to utilities, but would
pick up the wrong one in a merged-/usr environment will result in a
difference between the two builds and can thus be found.

See [1] for an overview of issues found this way; as the entire archive
was already rebuilt in this setup, there shouldn't be many more issues
of this type that we don't know about[2].

Not all of these differences even cause issues as in a few packages the
utility with the hardcoded path is not even used at all.

Bug reports were already submitted for over half the packages, often
including a simple patch (usually something like adding BASH=/bin/bash
to dh_auto_configure).

So we look to be on a good track to address the remaining issues.

I don't think that the debootstrap default has to be reverted
temporarily again to deal with this: there are only very few packages
causing problems and these should have a patch soon.

In addition one has to actually built one of the very few packages in a
merged-/usr environment and then install them in a non-merged-/usr
environment to actually trigger the problem and debootstrap already
defaults to non-merged-usr for buildd chroots for now.

Ansgar

  [1] 
https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
  [2] https://bugs.debian.org/914897#81

Re: Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

Ansgar Burchardt writes:
> There were discussions about enabling this by default years ago, I
> don't think minor issues should be a reason to delay this change.
>
> Note that it has been delayed for after the stretch release as there
> were major issues back then (it was enabled by default for a short time
> in stretch).  It took >5 months for someone to find a problem this time
> which is pretty good for any change.

So, I went through all reproducible build failures in unstable without
notes and added notes for differences caused by building in merged-/usr
vs non-merged-/usr packages.  Together with what other people tagged,
about 60 problems were found.  (The oldest rebuild result for unstable
is 17 days old, the merged-/usr variation was deployed before that[1].)

  [1] https://bugs.debian.org/901473#43

There might be some more that as diffoscope had problems or the diff was
too large for some packages (but I'll assume that in this case
merged-/usr is not the only problem the package had).

This should cover all packages that had no other problems and were
reproducible before, that is about 80% of the archive.

Assuming the rate is similar for packages which have other reproducible
build problems, I would expect 60 / 80*20 = 15 more problems.

I haven't looked at build failures, but I would expect these to be
usually not caused by merged-/usr.

So an estimated ~80 packages which might need adjustments for building
correctly in both merged-/usr and non-merged-/usr.  I guess less than
for the average new release of GCC ;-)

The problems are usually easy to fix by passing an explicit path the the
package's configure script at build time; of course there might be some
package where it is more complicated.

Ansgar

Re: Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default

[Ansgar Burchardt]

On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote:
> Dear Hideki, dear src:debootstrap maintainers,
> 
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by 
> default now, or are you OK letting the TC decide on this subject?

There were discussions about enabling this by default years ago, I
don't think minor issues should be a reason to delay this change.

Note that it has been delayed for after the stretch release as there
were major issues back then (it was enabled by default for a short time
in stretch).  It took >5 months for someone to find a problem this time
which is pretty good for any change.

Ansgar

Re: Scheduling 9.6

[Ansgar Burchardt]

Hi,

"Adam D. Barratt" writes:
> - November 10th

This would work if needed, though I don't mind someone else doing the
archive side (still have some things to sort out *sigh*).

Ansgar

Re: Scheduling 9.5

[Ansgar Burchardt]

Hi,

On Sat, 2018-06-23 at 17:30 +0100, Adam D. Barratt wrote:
> On Tue, 2018-06-12 at 12:44 +0100, Adam D. Barratt wrote:
> [...]
> > Given all of the above, I think the sanest option is to concentrate
> > on getting 8.11 done and jessie off our radar and then get 9.5
> > sorted.
> > 
> > For suggested dates for 9.5, we know that June 30th is a no-go,
> > Debcamp starts on July 21st and then Debconf on the 28th. So that
> > leaves us with:
> > 
> > - July 7th
> > - July 14th
> > 
> > Are people available for either or both of those dates?
> 
> The 7th is looking like the favourite so far (although would mean
> freezing next weekend), but we still need an ftp-master (N)ACK on
> either / both date.

I still have time on either weekend.

Ansgar

Re: debootstrap/1.0.102 appears to break debuerreotype autopkgtest

[Ansgar Burchardt]

Hideki Yamane writes:

> Hi,
>
> On Tue, 19 Jun 2018 08:09:17 +0200
> Ansgar Burchardt  wrote:
>> The `-k` option doesn't work for older releases (some packages do
>> replace files there).  It should always be used for newer releases (>=
>> stretch) to have less differences between --merged-usr and
>> --no-merged-usr.
>
>  >= stretch ? If it's >= buster (not include stretch), it's
>  easy to apply changes.

I'm not sure why >= stretch should be more complicated?  Something like
[1] (untested) should work?

  [1] 
<https://salsa.debian.org/ansgar/debootstrap/commits/allow-merged-usr-for-stretch-again>

Ansgar

Re: debootstrap/1.0.102 appears to break debuerreotype autopkgtest

[Ansgar Burchardt]

Hideki Yamane writes:
> On Thu, 14 Jun 2018 10:15:51 -0700
> Tianon Gravi  wrote:
>> > Instead of stretch simply defaulting to non-merged-usr, it's now
>> > _blacklisted_ from merged-usr, even if I explicitly specify
>> > "--merged-usr", right?  Is that the intended implementation here?
>
>  Yes, since releases until stretch was already shipped without merged-usr,
>  so it should be. But loose restriction for test purpose is okay, IMO.
>
>  Question with 'EXTRACT_DEB_TAR_OPTIONS="$EXTRACT_DEB_TAR_OPTIONS -k"'
>  It was introduced https://bugs.debian.org/838388 , so it should not be
>  applied to all releases. However, I'm not sure which "older" release
>  for it, especially whether it equals to merged-usr.

The `-k` option doesn't work for older releases (some packages do
replace files there).  It should always be used for newer releases (>=
stretch) to have less differences between --merged-usr and
--no-merged-usr.

(As it should always be applied it shouldn't be set in
`setup_merged_usr` as that is misleading.)

Ansgar

Re: debootstrap/1.0.102 appears to break debuerreotype autopkgtest

[Ansgar Burchardt]

Hi,

Paul Gevers writes:
> I looked at the test¹ and it compares the result of the current run of
> debuerreotype with a stored hash. Luckily debuerreotype use diffoscope
> to investigate the delta. It seems that debuerreotype is hit by this
> change in debootstrap:
>
>   * Enable merged-/usr by default (Closes: #839046)
> This is applied for buster and later.
>
> I am not sure if this should NOT have let to a change in debuerreotype,
> as I believe that is testing stretch.

>From the test log:

│ -lrwxrwxrwx   0000 2017-01-01 00:00:00.00 bin -> 
usr/bin
│ +drwxr-xr-x   0000 2017-01-01 00:00:00.00 bin/
│ +-rwxr-xr-x   000  1099016 2016-11-15 18:49:00.00 bin/bash

The patch for #839046 also disabled --merged-usr for stretch as stretch
was added to the blacklist in first_stage_install().

debootstrap should default to non-merged-usr for stretch, but it should
be possible to enable merged-usr via the command-line parameter to avoid
the regression in debuerreotype.

Ansgar

Re: Please dak copy-installer 20180610

[Ansgar Burchardt]

Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20180610

Done.

Thanks for maintaining d-i,
Ansgar

Re: Scheduling 9.5

[Ansgar Burchardt]

On Fri, 2018-06-08 at 18:51 +0100, Adam D. Barratt wrote:
> We can either accept the packages and put up with the situation for a
> short while, or do 9.5 before 8.11. In practical terms, that would
> likely mean both 9.5 and 8.11 on June 23rd, freezing both next
> weekend.

Should be fine with me; Joerg wanted to do the 8.11 one, but if he has
time restrictions on June 23rd and doing 8.11 after 9.5 would be too
late for him, I could probably also do both.

(If Joerg wants to do both, that's also fine with me.)

Ansgar

Bug#893873: reportbug: CC debian-boot@ for bugs against ftp.d.o asking for priority change

[Ansgar Burchardt]

Package: reportbug
Version: 7.1.10
Severity: wishlist

[ Cc'ed -boot@ to ack this suggestion. ]

Hi,

the d-i team wants to be informed of priority changes affecting the
default install.  With Priority: extra gone, these are now all changes
to the Priority.

Please consider adding X-Debbugs-Cc: debian-boot@ by default for bugs
filed against the ftp.debian.org pseudo-package that request an
override change which changes the priority of packages.

Override changes that only affect the section should not be Cc'ed to
debian-boot@.

Ansgar

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

[Ansgar Burchardt]

Hideki Yamane  writes:
>  Unfortunately, this patch would break behavior of --make-tarball option,
>  after creating tarball it cleans $TARGET but this patch prevent it even if
>  $TARGET doesn't exist before command runs.
>
>  Here's revised patch attached.

> +if [  -e "$TARGET"/* ]; then

That doesn't work:

+---
| $ dash -c '[ -e /bin/* ]'
| dash: 1: [: /bin/2to3-2.7: unexpected operator
+---

Ansgar

Re: Scheduling 9.4

[Ansgar Burchardt]

On Sat, 2018-02-10 at 12:27 +0100, Julien Cristau wrote:
> we shipped 9.3 a couple of months ago, so we're overdue for 9.4.
> 
> Can you please let us know your availability on the following:
> - March 3
> - March 10

These don't work for me.

> - March 17
> - March 24
> - March 31

These might work.

Given Steve doesn't have time on the later dates, it might be better to
have another ftpmaster handle the point release on March 3 or 10.

Ansgar

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

[Ansgar Burchardt]

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

So who should provide them?  debootstrap?  base-files?

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

Ansgar

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

[Ansgar Burchardt]

Ian Jackson writes:
> Also, I fear that unless we provide a straightforward way to retain
> separate /usr, including an appropriate d-i command line option, we
> will get further pushback and anger from traditionalists.  We risk
> reopening old wounds (see some of the less temperate responses earlier
> in the thread Ansgar links to as [1]).

There were 11 mails in the thread I linked as [1] in my initial mail.
None were really negative, just one person wondering if this means /
and /usr on separate filesystems is no longer supported (even though I
explicitly said it is in my initial mail).

Also, switching to merged-/usr, but still supporting non-merged-/usr
beyond a transition period means one uses one of the benefits for
maintainers no longer having to care where to install libraries or
programs (or worse: having to move them between / and /usr because
someone would like to use some additional program in early boot or a new
upstream release has support for some new feature requiring a library in
/usr).

I assume the less temperate responses are ones as [no argument]?  I
don't believe that one shouldn't base any decisions on less temperate
responses someone makes on the internet.  That way no change ever could
be implemented.  (What happens when I write less temperate responses to
the less temperate responses calling a proposal shit without any
argument?  Do I invalidate their less temperate response too or is that
reserved to the initial less temperate response?)

I strongly prefer technical reasons instead, such as the issue with
`dpkg -S` that was mentioned by Guillem.

  [no argument]: https://lists.debian.org/debian-devel/2016/01/msg5.html

[...]
> Finally, I have to say that I think that this summary from Ansgar
> is not really accurate:

I think that your summary is far less accurate than mine ;-)

>> As mentioned earlier, I would like to see --merged-usr enabled by
>> default for Debian Stretch.  The last discussion on -devel@[1] was
>> quite positive; I had some additional positive feedback on IRC.
> ...
>> [1] 
>
> That is a link to a message from Russ which mostly explains why
> mounting /usr early (ie in the initramfs, by default) is a good idea.
> That has now been implemented and has caused very little push-back.

No, that's a link to a message by me.

> But this bug report requests something entirely different: it is about
> actually moving the contents of /bin into /usr/bin, etc.

That is also what the linked mail is about.

> It is also not fair to say that the discussion was "quite positive".
> There was a good deal of opposition of various kinds, much of it
> quite heated.

Why not?  None of the 11 mails was really negative.

Ansgar

Re: Scheduling 9.3

[Ansgar Burchardt]

On Thu, 2017-11-16 at 08:02 +, Adam D. Barratt wrote:
> I believe we still need ftp-master and press confirmation, but I've
> been failing at poking.

Either of 2017-12-02 or 2017-12-09 should be fine for me.

Ansgar

Re: Scheduling 9.2

[Ansgar Burchardt]

Jonathan Wiltshire writes:
> Ok, does 7th October work any better?  I'm keen not to get too far adrift
> from the interval though.

Should be okay if no other ftpmaster volunteers.

Ansgar

Re: Please dak copy-installer 20170828, please force it into testing

[Ansgar Burchardt]

Cyril Brulebois  writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20170828

Done.

Ansgar

Bug#872948: debootstrap: Debootstrap does not explain what is calls a Debian base system

[Ansgar Burchardt]

Emmanuel Kasper  writes:
> The default base system installed by debootstrap includes all packages 
> with Pritority essential and
> important, but this was not yet documented.

There is no "essential" priority.  There is only "required" (and its
dependencies).

Ansgar

Bug#872577: debootstrap: Handle existing /dev

[Ansgar Burchardt]

Dan Nicholson writes:
> On Fri, Aug 18, 2017 at 2:48 PM, Henrique de Moraes Holschuh
>  wrote:
>> Wouldn't it be more straigthforward to "test -e || mknod" ?
>
> I definitely considered that, but it seemed more noisy to the code to
> add a conditional for every call. But I'd be fine reworking to that
> approach if that's more acceptable, though.

You can always introduce a `mknod_if_not_exists` function or so.  Though
I'm not sure this is worth here (the name is so long the `test -e` is
almost shorter).

Ansgar

Re: Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Ansgar Burchardt]

Hi,

Russ Allbery writes:
> Ansgar Burchardt <ans...@debian.org> writes:
>> I discussed this a bit on IRC with the other ftp-masters and we came to
>> this summary:
[...]
>> 2) We wonder if the 'standard' priority can also be dropped: as far as
>>we know, it is used only by the "standard" task and it might make
>>sense to treat it the same as other tasks.
>>(Depending on what works better for the installer team.)
>
> Given KiBi's reply, I'll leave 2 out for now.

Sure.

> Given the necessary wording changes, I don't think we can separate 0 and 1
> very easily, so I'll just propose wording for both (even though we forked
> the Policy bugs into two).  Here's a wording proposal based on Adam
> Borowski's wording with a bit of (hopefully correct) tightening.
>
> Note that this also says that no two packages that both have a priority of
> standard or higher may conflict.  I think that's a logical consequence of
> the use of priorities, and didn't want to lose that completely when that
> requirement was dropped from optional.

I agree.  Tools like debootstrap have no useful way to decide how to
resolve such conflicts and must work non-interactively.

> diff --git a/policy.xml b/policy.xml
> index ace6a3b..be458cd 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -837,11 +837,33 @@
>Priorities
>  
>
> -Each package should have a priority value,
> -which is included in the package's control
> -record (see ).  This
> -information is used by the Debian package management tools to
> -separate high-priority packages from less-important packages.
> +Each package must have a priority value,
> +which is set in the metadata for the Debian archive and is also
> +included in the package's control files (see  +linkend="s-f-Priority"/>).  This information is used to control
> +which packages are included in standard or minimal Debian
> +installations.
> +  
> +  
> +Most Debian packages will have a priority of
> +optional.  Priority levels other than
> +optional are only used for packages that should
> +be included by default in a standard installation of Debian.
> +  
> +  
> +The priority of a package is determined solely by the
> +functionality it provides directly to the user.  The priority of a
> +package should not be increased merely because another
> +higher-priority package depends on it; instead, the tools used to
> +construct Debian installations will correctly handle package
> +dependencies.  In particular, this means that C-like libraries
> +will almost never have a priority above
> +optional, since they do not provide
> +functionality directly to users.  However, as an exception, the
> +maintainers of Debian installers may request an increase of the
> +priority of a package to resolve installation issues and ensure
> +that the correct set of packages is included in a standard or
> +minimal install.
>
>
>  The following priority levels are recognized
> @@ -896,19 +922,22 @@
>installed by default if the user doesn't select anything
>else.  It doesn't include many large applications.
>  
> +
> +  No two packages that both have a priority of
> +  standard or higher may conflict with each
> +  other.
> +
>
>  
>  
>optional
>
>  
> -  (In a sense everything that isn't required is optional, but
> -  that's not what is meant here.) This is all the software
> -  that you might reasonably want to install if you didn't know
> -  what it was and don't have specialized requirements.  This
> -  is a much larger system and includes the X Window System, a
> -  full TeX distribution, and many applications.  Note that
> -  optional packages should not conflict with each other.
> +  This is the default priority for the majority of the
> +  archive.  Unless a package should be installed by default on
> +  standard Debian systems, it should have a priority of
> +  optional.  Packages with a priority of
> +  optional may conflict with each other.
>  
>
>  
> @@ -916,22 +945,21 @@
>extra
>
>  
> -  This co

Re: Bug#758234: debian-policy: allow packages to depend on packages of lower priority

[Ansgar Burchardt]

Hi,

Russ Allbery writes:
> ftp-master folks, we're discussing eliminating the requirement that
> packages only depend on other packages with the same or higher priority
> (so important packages would be able to depend on optional packages), and
> deprecating the extra priority entirely (so everything at extra priority
> would end up being optional over time).  This also means eliminating the
> requirement that no two packages at optional priority conflict with each
> other.

I discussed this a bit on IRC with the other ftp-masters and we came to
this summary:

0) We would like to drop the requirement for packages to not depend on
   packages of lower priority: it is better to declare only what we
   actually want included in the installation (that is at priority >=
   standard) rather than also the dependency closure.

1) We agree that the 'extra' priority can be dropped.

2) We wonder if the 'standard' priority can also be dropped: as far as
   we know, it is used only by the "standard" task and it might make
   sense to treat it the same as other tasks.
   (Depending on what works better for the installer team.)

I've Cc'ed -boot@ as this policy change affects them (I don't think they
have to read all of the way too long bug history though).

Ansgar

Re: Please dak copy-installer 20170615

[Ansgar Burchardt]

Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20170615

Done.

> Also, there was no recent clean-up in the sid directory; I think we
> could remove everything from 2015. Maybe also everything from 2016,
> but I'm tempted to give debian-boot@ people a chance to react in case
> images from 2016 should stay a bit longer. Of course this can wait
> post-release, no urgency from my point of view.

Not done yet, but we should probably also do the clean-up for stretch.

Ansgar

Re: Please dak copy-installer 20170608

[Ansgar Burchardt]

Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20170608

Done. Also removed dists/testing/main/installer-* for non-release
architectures.

Ansgar

Re: Last chance for d-i changes in stretch

[Ansgar Burchardt]

Cyril Brulebois writes:
> Didier 'OdyX' Raboud (2017-05-27):
>> It also currently uses httpredir.debian.org as only mirror, so we should 
>> decide if it makes sense to consolidate onto deb.debian.org for win32-
>> loader too.
>
> Unless we're aware of limitations win32-loader might hit on deb.d.o, I'd
> go for a transition to this hostname.
>
> Ditto for d-i-n-i, which I'll check right away.

httpredir.d.o seems to be just an alias for deb.d.o these days: I see a
"Welcome to deb.debian.org!" page when I open httpredir.d.o in a
browser.

So changing the mirror from httpredir.d.o to deb.d.o should be very
low-risk :-)

Ansgar

Re: Please get ready for copy-installer 20170525

[Ansgar Burchardt]

Cyril Brulebois writes:
> FTPmasters, I've just uploaded d-i 20170525 to the archive, and need to
> leave for the day, so it would be nice if you could please sync the
> installer from sid to testing when all builds are ready:
>
>   dak copy-installer 20170525

Done.

Ansgar

Re: 8.8 planning

[Ansgar Burchardt]

On Tue, 2017-03-14 at 12:00 +0100, Julien Cristau wrote:
> It's time to start thinking about our next stable point
> release.  Here
> are some dates, please let us know which ones would work.
> 
> * April 8-9

Not ideal, but should work.

> * April 15-16

Only on 16th.

> * April 22-23
> * April 29-30
> * May 6-7

These should all be okay.

Ansgar

Bug#852002: override: libncurses5:libs/important

[Ansgar Burchardt]

Control: retitle -1 override: libncurses5:libs/optional

Andreas Henriksson writes:
> On Fri, Jan 20, 2017 at 06:05:15PM +0100, Sven Joachim wrote:
> [...]
>> Please downgrade the priority so that libncurses5 does not get installed
>> in minimal chroots anymore and can be autoremoved in existing chroots by
>> apt.
>
> Subject says "override: libncurses5:libs/important" but please
> consider downgrading it to even lower than important!
>
> The important priority will pull it into a regular debootstrap.
> It's a library, why now have dependencies just pull it in if needed?!
>
> (Yes, sure there might be some important package depending on it
> and policy says yada, yada... but sooner or later policy
> will get fixed -> #758234 )

I agree that we should try to downgrade libraries to Priority: optional
if possible.

I would still like an ACK from the d-i team (X-Debbugs-Cc'ed).

Ansgar

Bug#855151: tasksel: should not be Priority: important

[Ansgar Burchardt]

Package: tasksel
Version: 3.39

tasksel is currently at Priority: important and thus installed in every
installation, including chroots installed via debootstrap.  It doesn't
seem a useful package to install in chroots though.

It would be nice if d-i would install tasksel (and maybe remove it at
the end of the installation again?) so the priority of the tasksel and
tasksel-data packages could be downgraded.

Ansgar

Bug#855150: override: blends-tasks: misc/optional

[Ansgar Burchardt]

Package: ftp.debian.org

blends-tasks is not used by d-i currently so there is no need to have it
included in the default install.

See also the discussion in #846002.

Ansgar

Re: Please dak copy-installer 20170127

[Ansgar Burchardt]

Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20170127

Done.

Ansgar

Bug#836525: debootstrap: doesn't support arch-qualified dependencies

[Ansgar Burchardt]

Hi,

there is a second implementation of pkgdetails in C (part of the base-
installer source package).  I assume that would also need to be patched
to ignore architecture qualifications?

Ansgar

Re: Bug#841935: pbuilder: incorrect permissions on /dev/ptmx breaks openpty()

[Ansgar Burchardt]

Thorsten Glaser writes:
> … whereas all “new” chroots look like…
>
> ls: cannot access 'base.cow-xenial-amd64/dev/pts/ptmx': No such file or 
> directory
> lrwxrwxrwx 1 root root 8 Mai 10 14:10 base.cow-xenial-amd64/dev/ptmx -> 
> pts/ptmx
>
> … so I assume that something in debootstrap changed so that
> there is now a symlink created instead of a proper device node.
>
> Maybe the debootstrap maintainers can comment on this?

That looks like the same issue as I reported in sbuild in #817236 (which
severity maybe should be raised if this is an issue for more packages):
there needs to be a mount for /dev/pts to accommodate for the changes in
debootstrap (and optionally a bind mount for /dev/ptmx if there are
still old chroots around).

Ansgar

Re: Please dak copy-installer 20161031

[Ansgar Burchardt]

Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20161031

Done.

Ansgar

Re: Please dak copy-installer 20161027

[Ansgar Burchardt]

Cyril Brulebois writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20161027

Done.  Can we remove older version from testing and unstable?

Ansgar

Re: Next d-i release

[Ansgar Burchardt]

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

I would like to see the new debootstrap (not yet uploaded) included.

My staged changes include enabling merged-/usr by default which I would
rather like to get more exposure sooner than later.  The merged-/usr
support in debootstrap already got some testing via the official Docker
images for Debian testing/unstable in the last weeks.

Ansgar

Bug#841181: debootstrap: Debootstrap fails to create new Ubuntu environment (Xenial, Yakety)

[Ansgar Burchardt]

Etienne Loks writes:
>* What led up to the situation?
>
> Installing an Ubuntu container fails with:

What is the command you run?  As you mention lxc below, is it
debootstrap or some lxc command?

> Aucune version du paquet lxcguest n'est disponible, mais il existe dans la
> base de données. Cela signifie en général que le paquet est manquant, qu'il
> est devenu obsolète ou qu'il n'est disponible que sur une autre source
>
> E: Le paquet « lxcguest » n'a pas de version susceptible d'être installée
> lxc_container: container creation template for osm failed
> lxc_container: Error creating container osm

Please use `export LC_ALL=C.UTF-8` when reporting bugs so error messages
are in English.

>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> After commenting the line installing the package lxcguest in
> /usr/share/lxc/templates/lxc-ubuntu the install is successful.

Ansgar

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

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.83

As mentioned earlier, I would like to see --merged-usr enabled by
default for Debian Stretch.  The last discussion on -devel@[1] was quite
positive; I had some additional positive feedback on IRC.

I'm not aware of any regressions so far, except for having forgotten to
add "jessie-kfreebsd" to the blacklist (a list of older releases that
don't support merged-/usr) and debootstrap 1.0.83 failing to bootstrap
squeeze[2].  Both are fixed in my changes targeted at 1.0.84[3].

So I would like to switch the default in debootstrap sooner rather than
later to give time to find some more bugs.  With this change, the
currently known bugs[4] should also be raised to "serious", but I don't
think any of them should be a blocker.

Ansgar

  [1] 
  [2] 
  [3] 
  [4] 

Bug#837649: debootstrap: Add support for Packages.xz

[Ansgar Burchardt]

Ansgar Burchardt writes:
> debootstrap should support archives that only provide Packages.xz.
>
> I'll try to take a look at implementing this soon.  From a quick glance
> it shouldn't be too difficult given several compression formats are
> already supported (bz2, gz, uncompressed).

I've prepared a patch for this[1].  It worked for me with both a
Packages.xz suite (stretch) and one only providing Package.bz2, but not
.xz (squeeze).

Ansgar

  [1] 
https://github.com/aburch/debootstrap/commit/1689d645aacb0bc3f9edb86526f67e776469942a

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Ansgar Burchardt]

tag 838388 + patch
thanks

Ansgar Burchardt writes:
> Ah, I'm to blame for that.  [1] added `-k` to the options passed to tar
> in order to avoid replacing the new symlinks from / to /usr with real
> directories.  However it looks like tar returns an error when there are
> actual file conflicts (as opposed to just symlink vs. directory).
>
> Only adding -k for newer distributions (i.e. the ones that merged-/usr
> supports) should work around the problem.

I pushed a patch implementing this to my debootstrap repository[2].  It
worked for Squeeze (w/o merged-/usr) and Stretch (w/ merged-/usr).

Ansgar

  [2] 
https://github.com/aburch/debootstrap/commit/5bb1da69596828821fe43b3ee63f733e4b8672e7

Bug#838388: debootstrap: Fails to strap squeeze since 1.0.83

[Ansgar Burchardt]

Stephan Sürken writes:
> On Di, 2016-09-20 at 21:09 +0200, Julien Cristau wrote:
>> > It always exits here with exit code 2, without any further error
>> > message (not even when using --verbose).
>> >
>> There should be a log inside the target directory.
>
> ah, sure ;).
>
> debootstrap/debootstrap.log says:
>
> ---
> gpgv: Signature made Sat Apr 25 13:01:30 2015 CEST
> gpgv:using RSA key AED4B06F473041FA
> gpgv: Good signature from "Debian Archive Automatic Signing Key (6.0/squeeze) 
> "
> gpgv: Signature made Sat Apr 25 13:05:42 2015 CEST
> gpgv:using RSA key 64481591B98321F9
> gpgv: Good signature from "Squeeze Stable Release Key 
> "
> tar: ./usr/share/man/man1/sh.1.gz: Cannot create symlink to 'dash.1.gz': File 
> exists
> tar: ./bin/sh: Cannot create symlink to 'dash': File exists
> tar: Exiting with failure status due to previous errors

Ah, I'm to blame for that.  [1] added `-k` to the options passed to tar
in order to avoid replacing the new symlinks from / to /usr with real
directories.  However it looks like tar returns an error when there are
actual file conflicts (as opposed to just symlink vs. directory).

Only adding -k for newer distributions (i.e. the ones that merged-/usr
supports) should work around the problem.

Just --keep-directory-symlink would of course be ideal, but I doubt it
is supported everywhere (being a long option to start with).

Ansgar

  [1] 
https://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=6b79352a205a96cee441ae0c6247c4616097a517

Support for merged-/usr now in debootstrap; default for stretch?

[Ansgar Burchardt]

Hi,

debootstrap in unstable can now install with merged-/usr, that is with
/bin, /sbin, /lib* being symlinks to their counterpart in /usr.  Run

  debootstrap --merged-usr testing .../testing http://deb.debian.org/debian

to give it a try.

It has been previously suggested to make this the default for (at least)
new installations.  I think Russ' earlier mail[1] explains quite well
why the "split" between / and /usr doesn't really work out for Debian
these days and that trying to maintain it for some configurations (which
are not documented) is mostly busy-work.  There is also a nice article
on LWN[2] summarizing earlier discussions.

I found these arguments convincing enough and would like to see the
default switched to merged-/usr for Stretch and later.  Possibly also
switching systems on upgrade to the new scheme (not necessarily already
in the Stretch release cycle).

Please remember that this still allows / and /usr to reside on different
filesystems: in this case the initramfs has to make sure /usr is mounted
as well.  This is already required for various reasons (again, see [1]).

Ansgar

  [1] https://lists.debian.org/debian-devel/2016/01/msg00081.html
  [2] https://lwn.net/Articles/670071/

Bug#837649: debootstrap: Add support for Packages.xz

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.82
Owner: Ansgar Burchardt <ans...@debian.org>
Control: block 818463 by -1

debootstrap should support archives that only provide Packages.xz.

I'll try to take a look at implementing this soon.  From a quick glance
it shouldn't be too difficult given several compression formats are
already supported (bz2, gz, uncompressed).

Ansgar

Bug#837185: debootstrap: fails with `dpkg-deb` and busybox' `tar`

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.82
Severity: minor

While testing other changes, I noticed that debootstrap fails when
using `dpkg-deb` together with busybox' `tar` implementation as
`dpkg-deb -f` passes additional options to `tar`.

I'm not sure if this happens in the real world (i.e. anyone has
`dpkg-deb` available, but busybox' tar instead of GNU's tar), but the
attached patch avoids the problem by calling the installed `dpkg-deb`
in the second stage.

(The patch should go in after the ones from #810301.)

Ansgar

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages debootstrap depends on:
ii  wget  1.18-2+b1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   2.1.14-5

debootstrap suggests no packages.

-- no debconf information
>From 316ba08b931e6f226b25c396b45b6add58b578e2 Mon Sep 17 00:00:00 2001
From: Ansgar Burchardt <ans...@debian.org>
Date: Fri, 9 Sep 2016 23:03:23 +0200
Subject: [PATCH] Feign install of dpkg in second stage

Using the `dpkg-deb` extractor, or more precise `dpkg-deb -f`, together
with busybox' `tar` results in failure: `dpkg-deb` passes additional
options to `tar` that are not understood by busybox' implementation such
as `--warning=no-timestamp`.

We can avoid this by feigning the installation of `dpkg` in the second
stage. Here it is possible to call the installed `dpkg-deb` together
with the installed (GNU) `tar`.
---
 scripts/sid | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/scripts/sid b/scripts/sid
index 428c676..ceedd66 100644
--- a/scripts/sid
+++ b/scripts/sid
@@ -59,11 +59,15 @@ first_stage_install () {
 	fi
 
 	setup_devices
+}
+
+second_stage_install () {
+	setup_dynamic_devices
 
 	x_feign_install () {
 		local pkg="$1"
 		local deb="$(debfor $pkg)"
-		local ver="$(extract_deb_field "$TARGET/$deb" Version)"
+		local ver="$(in_target dpkg-deb -f "$deb" Version)"
 
 		mkdir -p "$TARGET/var/lib/dpkg/info"
 
@@ -77,10 +81,6 @@ Status: install ok installed" >> "$TARGET/var/lib/dpkg/status"
 	}
 
 	x_feign_install dpkg
-}
-
-second_stage_install () {
-	setup_dynamic_devices
 
 	x_core_install () {
 		smallyes '' | in_target dpkg --force-depends --install $(debfor "$@")
-- 
2.9.3

Bug#837075: debootstrap: does not validate `suite` parameter against Release file

[Ansgar Burchardt]

On Thu, 2016-09-08 at 16:09 +0200, Ansgar Burchardt wrote:
> 
> debootstrap should validate that ${suite} is listed in the Release
> file in either the Suite: or Codename: fields.  Additionally storing
> the codename in a variable would also be useful for suite-specific
> workarounds, such as [1].
> 
>   [1] <https://bugs.debian.org/810301#69>
> 

I've attached a patch that implements this.

AnsgarFrom 81ebc7df61e8a80915126351e01e016f6a57a52a Mon Sep 17 00:00:00 2001
From: Ansgar Burchardt <ans...@debian.org>
Date: Thu, 8 Sep 2016 17:28:19 +0200
Subject: [PATCH 1/6] Validate SUITE against Release's Suite or Codename

Bug: https://bugs.debian.org/837075
---
 debian/changelog |  7 +++
 functions| 14 ++
 2 files changed, 21 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 9a6412b..96a1dc9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+debootstrap (1.0.83) UNRELEASED; urgency=medium
+
+  * functions: Validate that the requested suite is listed in the
+Release file's Suite or Codename field. (Closes: #837075)
+
+ -- Ansgar Burchardt <ans...@debian.org>  Thu, 08 Sep 2016 17:26:53 +0200
+
 debootstrap (1.0.82) unstable; urgency=medium
 
   [ Alex Bennée ]
diff --git a/functions b/functions
index 67701ee..336f220 100644
--- a/functions
+++ b/functions
@@ -512,6 +512,18 @@ extract_release_components () {
 	fi
 }
 
+CODENAME=""
+validate_suite () {
+	local reldest="$1"
+
+	CODENAME=$(sed -n "s/^Codename: *//p" "$reldest")
+	local suite=$(sed -n "s/^Suite: *//p" "$reldest")
+
+	if [ "$SUITE" != "$suite" ] && [ "$SUITE" != "$CODENAME" ]; then
+		error 1 WRONGSUITE "Asked to install suite %s, but got %s (codename: %s) from mirror" "$SUITE" "$suite" "$CODENAME"
+	fi
+}
+
 download_release_sig () {
 	local m1="$1"
 	local reldest="$2"
@@ -547,6 +559,8 @@ download_release_indices () {
 
 	download_release_sig "$m1" "$reldest" "$relsigdest"
 
+	validate_suite "$reldest"
+
 	extract_release_components $reldest
 
 	local totalpkgs=0
-- 
2.9.3

Bug#810301: merged /usr support for debootstrap

[Ansgar Burchardt]

On Thu, 2016-09-08 at 15:36 +0200, Ansgar Burchardt wrote:
> Could you use the "Codename" field from Release to normalize the
> suite name?  That should work even when the meaning of "stable"
> changes.

I've updated Marco's patch to include this change and prepared
everything as a Git series. The patches below should be applied after
the one I provided for #837075.

Additional testing is of course welcome.

Ansgar
From 55e2452198840684e64b7aad549c2cc92261a7be Mon Sep 17 00:00:00 2001
From: Marco d'Itri <m...@linux.it>
Date: Thu, 8 Sep 2016 17:34:14 +0200
Subject: [PATCH 2/6] Merged /usr support for debootstrap

---
 debootstrap   |  6 ++
 debootstrap.8 |  3 +++
 functions | 37 +
 scripts/sid   |  6 ++
 4 files changed, 52 insertions(+)

diff --git a/debootstrap b/debootstrap
index 4cea268..ea1d048 100755
--- a/debootstrap
+++ b/debootstrap
@@ -27,6 +27,7 @@ KEYRING=""
 DISABLE_KEYRING=""
 FORCE_KEYRING=""
 VARIANT=""
+MERGED_USR=""
 ARCH=""
 HOST_ARCH=""
 HOST_OS=""
@@ -100,6 +101,7 @@ usage()
   --variant=Xuse variant X of the bootstrap scripts
  (currently supported variants: buildd, fakechroot,
   scratchbox, minbase)
+  --no-merged-usrdo not make /{bin,sbin,lib}/ symlinks to /usr/
   --keyring=Kcheck Release files against keyring K
   --no-check-gpg avoid checking Release file signatures
   --force-check-gpg  force checking Release file signatures
@@ -302,6 +304,10 @@ if [ $# != 0 ] ; then
 			error 1 NEEDARG "option requires an argument %s" "$1"
 		fi
 		;;
+	--no-merged-usr)
+		MERGED_USR=no
+		shift
+		;;
 	--keyring|--keyring=?*)
 		if ! gpgv --version >/dev/null 2>&1; then
 			error 1 NEEDGPGV "gpgv not installed, but required for Release verification"
diff --git a/debootstrap.8 b/debootstrap.8
index 5864148..5eeaf04 100644
--- a/debootstrap.8
+++ b/debootstrap.8
@@ -84,6 +84,9 @@ The default, with no \fB\-\-variant=X\fP argument, is to create a base
 Debian installation in
 .IR TARGET .
 .IP
+.IP "\fB\-\-no-merged-usr\fP"
+Do not create /{bin,sbin,lib}/ symlinks pointing to their conterparts in /usr/.
+.IP
 .IP "\fB\-\-keyring=KEYRING\fP"
 Override the default keyring for the distribution being bootstrapped,
 and use
diff --git a/functions b/functions
index 336f220..f633f73 100644
--- a/functions
+++ b/functions
@@ -1136,6 +1136,43 @@ setup_dselect_method () {
 	esac
 }
 
+# Find out where the runtime dynamic linker and the shared libraries
+# can be installed on each architecture: native, multilib and multiarch.
+# This data can be verified by checking the files in the debian/sysdeps/
+# directory of the glibc package.
+#
+# This function must be updated to support any new architecture which
+# either installs the RTLD in a directory different from /lib or builds
+# multilib library packages.
+setup_merged_usr() {
+	if [ "$MERGED_USR" = "no" ]; then return 0; fi
+
+	local link_dir
+	case $ARCH in
+	hurd-*)	return 0 ;;
+	amd64)	link_dir="lib32 lib64 libx32" ;;
+	i386)	link_dir="lib64 libx32" ;;
+	mips|mipsel)
+			link_dir="lib32 lib64" ;;
+	mips64*|mipsn32*)
+			link_dir="lib32 lib64 libo32" ;;
+	powerpc)	link_dir="lib64" ;;
+	ppc64)	link_dir="lib32 lib64" ;;
+	ppc64el)	link_dir="lib64" ;;
+	s390x)	link_dir="lib32" ;;
+	sparc)	link_dir="lib64" ;;
+	sparc64)	link_dir="lib32 lib64" ;;
+	x32)	link_dir="lib32 lib64 libx32" ;;
+	esac
+	link_dir="bin sbin lib $link_dir"
+
+	local dir
+	for dir in $link_dir; do
+		ln -s usr/$dir $TARGET/$dir
+		mkdir -p $TARGET/usr/$dir
+	done
+}
+
  pkgdetails
 
 # NOTE
diff --git a/scripts/sid b/scripts/sid
index 7b32ac2..5866569 100644
--- a/scripts/sid
+++ b/scripts/sid
@@ -41,6 +41,12 @@ work_out_debs () {
 }
 
 first_stage_install () {
+	case $SUITE in
+		etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
+		oldstable|stable) ;;
+		*) setup_merged_usr ;;
+	esac
+
 	extract $required
 
 	mkdir -p "$TARGET/var/lib/dpkg"
-- 
2.9.3

From 6b79352a205a96cee441ae0c6247c4616097a517 Mon Sep 17 00:00:00 2001
From: Ansgar Burchardt <ans...@debian.org>
Date: Thu, 8 Sep 2016 17:30:17 +0200
Subject: [PATCH 3/6] Pass -k to tar when extracting packages

When installing with a merged /usr, the symlinks in / should not be
replaced with real directories when extracting the packages.
---
 functions | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/functions b/functions
index f633f73..60aea99 100644
--- a/functions
+++ b/functions
@@ -821,7 +821,7 @@ extra

Bug#810301: merged /usr support for debootstrap

[Ansgar Burchardt]

On Thu, 7 Jul 2016 14:46:36 +0200 Marco d'Itri  wrote:
> On Jul 05, Cyril Brulebois  wrote:
> 
> > For those wondering (and AFAICT) it seems the only issue here is
how to
> > handle multilib, since multiarch is “hidden” below usr/lib (in
> > usr/lib/ subdirectories).
> Indeed.
> 
> > Actually, this means an architecture which isn't listed doesn't get
> > extra paths, and /lib might be enough for some ports, e.g. arm64.
> I do not expect that we will get any other multilib ports.
> 
> > It would seem a better idea to list all ports explicitly though.
> Why? See above.
> 
> > > >  first_stage_install () {
> > > > +   case $SUITE in
> > > > +   etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > > > +   oldstable|stable) ;;
> > > > +   *) setup_merged_usr ;;
> > > 
> > > This means “debootstrap stable” on stretch once it's released
is going
> > > to lead to different results compared to “debootstrap
stretch”.
> > That part remains to be fixed.
> Yes, but how? The current stable cannot work with a merged /usr, so 
> I expected that this would be changed just before stretch is
released.

Could you use the "Codename" field from Release to normalize the suite
name?  That should work even when the meaning of "stable" changes.

(Which makes me wonder: does debootstrap check that the suite it is
asked to install is either in the Release file's Suite or Codename
field?)

Ansgar

Bug#837075: debootstrap: does not validate `suite` parameter against Release file

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.81
Severity: normal

Running
  debootstrap ${suite} ${suite} ${mirror}
will install whatever the mirror serves as dists/${suite}, even when that
is not the requested suite.  This can easily be checked with a few Redirect
statements in a .htaccess file:

  Redirect /debian-wrong/pool http://ftp.de.debian.org/debian/pool
  Redirect /debian-wrong/dists/stable 
http://ftp.de.debian.org/debian/dists/unstable

Then
  debootstrap stable stable http://[...]/debian-wrong
will install unstable instead of stable.

debootstrap should validate that ${suite} is listed in the Release
file in either the Suite: or Codename: fields.  Additionally storing
the codename in a variable would also be useful for suite-specific
workarounds, such as [1].

Ansgar

  [1] 


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'testing'), (500, 'stable'), (300, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages debootstrap depends on:
ii  wget  1.18-2+b1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   2.1.14-5

debootstrap suggests no packages.

-- no debconf information

Re: 8.6 planning

[Ansgar Burchardt]

On Sun, 2016-08-07 at 23:04 +0100, Adam D. Barratt wrote:
> It's time for another Jessie point release; as wheezy's EOL, we don't
> have to worry about trying to fit two in at the same time. Some
> possible
> dates:
> 
> August 20th/21st - doesn't work for me
> 
> August 27th/28th - public holiday weekend in the UK; doesn't work for
> me

These don't work for me either. (Also they are probably too close by
now.)

> September 3rd/4th 

Might work with some extra planning, but not that well.

> September 10th/11th
> 
> September 17th/18th

These should be okay for me.

Ansgar

Re: debootstrap InRelease file support

[Ansgar Burchardt]

Julien Cristau writes:
> On Thu, Mar  3, 2016 at 21:12:06 -0500, Mathieu Trudel-Lapierre wrote:
>> Looking into a bug in Ubuntu relating to an out of sync proxy, InRelease
>> file support in debootstrap came up.
>>
>> I found out that debootstrap had already had such support in the past
>> (specifically, in 1.0.47 and earlier) and that was removed by Julien
>> Cristau because it also pulled in a fuller gpg, which comes with its own
>> set of potential issues.
>>
>> Seems like we could well put it back in and just replace the bit that
>> extracts the signed data in InRelease (same as is in Release) with using
>> sed and grep to remove the signature text.
>>
>> I did the work and pushed it to git at
>> http://anonscm.debian.org/cgit/d-i/debootstrap.git/log/?h=people/cyphermox/inrelease.
>> As before, this would default to using the InRelease file from the
>> archive first, if available, and otherwise fallback to using the usual
>> Release + Release.gpg.
>>
>> Is there any interest for supporting this again? I would like some
>> feedback on the code branch, then I'd be happy to merge it to master
>> (but I would still need someone to sponsor the upload).
>>
> Hi Mathieu,
>
> I had a look at your branch.  As far as I can tell, that code will
> happily accept an InRelease file that starts with correct signed bits,
> with random unsigned data appended.  That seems wrong.

If you restore support for `InRelease` and want to use `gpgv`, please
split `InRelease` into two files, i.e. `Release` and `Release.gpg`, and
verify that the signature actually covers all of `Release`.

Calling `gpgv` on `InRelease` and then hoping to extract the right part
is quite error-prone. (As Julien notes and I agree.) Quite a lot of
tools in Debian got this wrong, see for example CVE-2013-1051.

As far as I understand, splitting `InRelease` into data and detached
signature is also what `apt` does these days.

Ansgar

Re: Bug#830894: override: initscripts:admin/optional

[Ansgar Burchardt]

tag 830894 + moreinfo
tag 830895 + moreinfo
tag 830901 + moreinfo
thanks

Michael Biebl writes:
> on a Debian stretch/unstable system using systemd as init system, the
> initscripts package is no longer required. We asked all packages with
> explicit dependencies to remove it and it is now possible to uninstall
> initscripts without any ill side-effects.
> update-rc.d has been updated to cope with the fact that the facilities
> defined by initscripts do not exist.
> It is therefor safe to no longer install the initscripts package by
> default.
>
> Please lower the priority of initscripts accordingly.

Let's ping -boot@ before the change.

Dear d-i maintainers, please ack the priority change to initscripts,
sysv-rc[1] and startpar[2] from "required" to "optional".

  [1] https://bugs.debian.org/830895
  [2] https://bugs.debian.org/830901

All three packages should get pulled in by "sysvinit-core" on systems
not using systemd.

Ansgar

Bug#828052: Sparc and "Invalid Release file, no entry for main/binary-sparc/Packages"

[Ansgar Burchardt]

reassign 828052 www.debian.org
retitle 828052 https://www.debian.org/ports: list of ports is outdated

Jeffrey Walton  writes:
> According to the Debian Ports page at https://www.debian.org/ports/,
> Sparc is an official and supported.

That list seems outdated: sparc is no longer supported. Neither is ia64
or s390.

kfreebsd-* is also not a part of the official Debian release, although
there is a jessie-kfreebsd suite.

alpha and hppa are listed as discontinued, but as far as I know they are
kept in a fairly good state[1] on ports.d.o even if they will properly
not be part of the official Debian releases in the future.

Ansgar

  [1] 

Bug#825034: debootstrap: fails if no base packages are to be installed

[Ansgar Burchardt]

Package: debootstrap
Version: 1.0.67
Severity: normal

Helmut Grohne reported in #-devel that `debootstrap --variant=minbase`
fails for unstable:

+---
| Setting up systemd-sysv (229-6) ...
| Setting up init (1.33) ...
| Processing triggers for libc-bin (2.22-9) ...
| dpkg: error: --unpack needs at least one package archive file argument
|
| Type dpkg --help for help about installing and deinstalling packages [*];
| Use 'apt' or 'aptitude' for user-friendly package management;
| Type dpkg -Dhelp for a list of dpkg debug flag values;
| Type dpkg --force-help for a list of forcing options;
| Type dpkg-deb --help for help about manipulating *.deb files;
|
| Options marked [*] produce a lot of output - pipe it through 'less' or 'more' 
!
+---

This is probably caused by "apt"'s priority getting increased from
"important" to "required".  The "minbase" variant then installs no
additional base packages (base="apt" is already installed).

Helmut confirmed that adding another packages ("ed") as an additional
base package to the "minbase" variant made `debootstrap` complete
successfully.

I've reverted the priority of "apt" back to "important" for now.

Ansgar

Bug#824991: override: init:metapackages/important

[Ansgar Burchardt]

Package: ftp.debian.org
Severity: normal

As discussed in [1] I would like to make it possible for minimal
systems (mostly buildd chroots and application containers like Docker)
to not have to install an init system.

For this the "Essential: yes" field is moved from "init" to
"init-system-helpers" (to provide invoke-rc.d/update-rc.d). I would
also like to downgrade the priority of "init" from required to
important. With the priority change, debootstrap should no longer
install a full init system in the "minbase" and "buildd" variants.

On the d-i side, I hope this doesn't break anything as debootstrap's
default variant should not be affected by these changes, unless d-i
can also install a "minbase" variant?

And just for the record: a system with no "init" should have a
"policy-rc.d" policy that rejects all actions, but this is already the
case for chroots.

Ansgar

  [1] 

Re: Please dak copy-installer 20160516

[Ansgar Burchardt]

Cyril Brulebois writes:
> Thanks, please rerun with the binNMU now so that we get the
> brltty/espeakup fixes for Stretch Alpha 6:
>
>   dak copy-installer 20160516+b1

Done.

Ansgar

Bug#824885: override: debconf-i18n:localization/important

[Ansgar Burchardt]

Package: ftp.debian.org
Severity: normal

[ For after the d-i alpha currently in preparation ]

Please consider demoting debconf-i18n from required to important.
debconf now only recommends it instead of having a strict dependency
and i18n support isn't required in minimal installations.

This should also allow demoting several perl modules:
libtext-iconv-perl, libtext-wrapi18n-perl, libtext-charwidth-perl (or
demoting those even to "optional" with the reasoning given in #758234)

Ansgar

Re: Please dak copy-installer 20160516

[Ansgar Burchardt]

Cyril Brulebois  writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20160516

Done.

Thanks for your work on d-i,
Ansgar

Bug#819719: override: apt:admin/required

[Ansgar Burchardt]

Package: ftp.debian.org
Severity: normal

apt is currently at Priority: important, but debootstrap treats it
like Priority: required by including it in every variant explicitly:

+---
| if doing_variant - || doing_variant fakechroot; then
| #required="$required $(get_debs Priority: important)"
| #  ^^ should be getting debconf here somehow maybe
| base="$(get_debs Priority: important)"
| elif doing_variant buildd || doing_variant scratchbox; then
| base="apt build-essential"
| elif doing_variant minbase; then
| base="apt"
| fi
+---[ file:///usr/share/debootstrap/scripts/sid ]

If apt was Priority: required, debootstrap wouldn't need to pretend it
was. It also seems more honest ;)

Ansgar

Re: Archive changes

[Ansgar Burchardt]

Hi,

Adam Conrad writes:
> On Tue, Mar 15, 2016 at 11:15:16PM +0100, Joerg Jaspert wrote:
>> Additionally I turned off generating gzip compressed versions of those
>> files, xz is there.
>
> This will break debootstrap.  If we think it's okay for debootstrap to
> depend on xzutils (is that ubiquitous enough on all Linux installations
> these days?) is a question for the maintainers, perhaps.

debootstrap already requires xz support: the binary packages are
compressed with xz (at least data.tar.xz).

Ansgar

Re: 8.4 and 7.10 planning

[Ansgar Burchardt]

"Adam D. Barratt" writes:
> We're due both Jessie and Wheezy point releases, and are proposing doing
> both on the same weekend again, as we did for 8.2 and 7.9, as the CD
> team seem happy to try it again.
>
> Some suggested dates:
>
> March 12th / 13th
> March 19th / 20th
> April 2nd / 3rd

These all look fine for me.

> March 26th / 27th - Easter, holiday weekend in at least the UK

Not good.

Ansgar

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

[Ansgar Burchardt]

On Tue, 2016-02-02 at 15:12 +0100, Johannes Schauer wrote:
> On Mon, 07 Dec 2015 10:20:32 +0100 Ansgar Burchardt
> <ans...@debian.org> wrote:
> > 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?

cross-gcc-4.9-armhf doesn't get built by the buildd network, see

  https://buildd.debian.org/status/package.php?p=cross-gcc-4.9-armhf
  https://buildd.debian.org/status/logs.php?pkg=cross-gcc-4.9-armhf
h=i386

The package also cannot migrate to testing as cross-arch binary
dependencies are not supported by britney, see [1].  If I recall
correctly, britney doesn't ensure that build-deps can be satisfied (a
missing feature).

Ansgar

  [1] https://release.debian.org/migration/testing.pl?package=cross-gcc
-4.9-armhf

Going ahead with non-free-firmware

[Ansgar Burchardt]

Hi,

I think there was consensus to introduce the non-free-firmware section
and move the non-free firmware blobs there.  I'm wondering what we need
to do next?

Besides the ftp team setting the new section up, I expect the installer
would need changes to enable it instead of non-free when non-free
firmware is required; maybe it still needs to ask for non-free as well
for other reasons?  Other teams might also need to add the new section,
e.g. the release team, packages.d.o, ...  I expect the list to be
hard-coded in quite a few places.

Then the release notes need to document that "non-free-firmware" might
have to be added to sources.list.

Finally we need to identify the packages that should move there.  I
guess all non-free packages named "firmware-*" would be a good match.

Ansgar

Re: 8.3 planning

[Ansgar Burchardt]

On Sun, 2015-12-13 at 17:22 +, Adam D. Barratt wrote:
> On Sun, 2015-12-06 at 16:10 -0500, Donald Norwood wrote:
> > On 12/04/2015 01:12 PM, Steve McIntyre wrote:
> > > On Fri, Dec 04, 2015 at 05:43:54PM +, Adam Barratt wrote:
> > > > On that basis, looking at January we have:
> > > > 
> > > > 2nd/3rd - depends how much people are still suffering. :-)
> > > No chance for me that weekend - I've got plans already.
> > > 
> > > > 9th/10th
> > > > 16th/17th
> > > > 23rd/24th - likely to be bad for me
> > > All of these look OK so far.
> > > 
> > Press can do 16/17 or 23/24.
> 
> Just missing ftp-master then - ping :-)

Both 16/17 or 23/24 should be fine for me. Not quite sure about 9/10th.

Ansgar

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

[Ansgar Burchardt]

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.

Alternatively building a subset of arch:all packages on every
architecture would also work, but that would require (at least) support
for the buildd network building arch:all packages on package-specific
architectures ("Build-Architecture-Indep" might find relevant threads).

Ansgar

Bug#804770: debootstrap: please don't install nfacct and related libs

[Ansgar Burchardt]

Hi,

On Wed, 2015-11-11 at 14:49 +0100, Cyril Brulebois wrote:
> Arturo Borrero Gonzalez  (2015-11-11):
> > Yesterday I noticed that debootstrap is installing nfacct and
> > related libs
> > by default.
[...]
> #758229 was apparently about fixing the package priority, which is
> exactly what triggers debootstrap's installing it. A priority change
> has
> to happen at the ftpmaster level in addition to the package level
> (through the overrides mechanism). I'm therefore adding ftpmaster@ to
> the loop (along with the NMUer and the maintainer).

For stretch, nfacct's priority was already reduced to optional[1] and
it should no longer be included in the default install.

If the priority should be changed for the stable release, that would be
something for the stable release team to decide. I personally don't
care enough to consider asking them myself.

Ansgar

  [1] 

Re: Please dak copy-installer 20151023

[Ansgar Burchardt]

Cyril Brulebois  writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20151023

Done.

Ansgar

Re: Please dak copy-installer 20150911

[Ansgar Burchardt]

Cyril Brulebois  writes:
> FTPmasters, please sync the installer from sid to testing:
>
>   dak copy-installer 20150911

Done.

Ansgar

Re: Please dak copy-installer 20150828 hint it into testing

[Ansgar Burchardt]

Cyril Brulebois k...@debian.org writes:
 FTPmasters, please sync the installer from sid to testing:

   dak copy-installer 20150828

Done.

Ansgar

Re: 8.2 and 7.9 planning

[Ansgar Burchardt]

Adam D. Barratt a...@adam-barratt.org.uk writes:
 We're somewhat overdue for both 8.2 and 7.9 now (in that order). Some
 potential September dates:

 5/6th - okay for me

Should be okay, provided I get internet on Aug 31st as planned.

 12/13th - the 12th doesn't work for me until at least mid-afternoon
 19th/20th - looks okay
 26th/27th - looks okay

Work might interfere with these a bit (might have a meeting on the day
before, though currently it looks like it might be in October). I would
only be available on Saturday afternoon and Sunday.

Ansgar

Re: Please dak copy-installer 20150813 hint it into testing

[Ansgar Burchardt]

Cyril Brulebois k...@debian.org writes:
 FTPmasters, please sync the installer from sid to testing:

   dak copy-installer 20150813

Done.

Thanks for your work on d-i,
Ansgar

Bug#793766: tasksel: standard system utilities pulls packages that listen on ports without firewall

[Ansgar Burchardt]

Hi,

Michael Rose mdr...@zoho.com writes:
 During installation, tasksel gives you the option of including standard 
 system
 utilities. This group includes nfs-common and rpcbind, which, post
 installation, automatically launch daemons that listen on ports. Debian's
 default iptables configuration after installation is to allow all connections.
 This is a security concern.

 There's no indication to the user that selecting standard system utilities 
 will
 do this. Having a permissive firewall policy by default is fine, provided that
 no open ports are running by default as well, but this is not the current
 situation.

 Possible solutions:
 1. Do not include these packages in the task

That is the current plan for Debian 9, see [1] and [2].

Ansgar

  [1] https://lists.debian.org/debian-devel/2015/05/msg00089.html
  [2] https://bugs.debian.org/788702


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87380a7y78@deep-thought.43-1.org

Re: Please dak copy-installer 20150718 hint it into testing

[Ansgar Burchardt]

Cyril Brulebois k...@debian.org writes:
 FTPmasters, please sync the installer from sid to testing:

   dak copy-installer 20150718

Done.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3o53ox4@deep-thought.43-1.org

Bug#788702: override: make default install a bit smaller

[Ansgar Burchardt]

Package: ftp.debian.org
X-Debbugs-Cc: debian-boot@lists.debian.org

Please change the following priorities as proposed earlier[1]:

  # From Priority: important:
  for p in \
  groff-base man-db manpages less netcat-traditional traceroute \
  ; do
dak override ${p} . standard
  done
  dak override nfacct . optional

  # From Priority: standard:
  for p in \
  aptitude aptitude-common at bc dc dnsutils bsd-mailx exim4 \
  exim4-base exim4-config exim4-daemon-light procmail mutt \
  ftp info texinfo install-info m4 mlocate nfs-common rpcbind \
  patch time w3m whois \
  ; do
dak override ${p} . optional
  done
  dak override host oldlibs extra

I suggested to demote a few more packages from Priority: important,
namely cron, ifupdown, isc-dhcp-client, isc-dhcp-common, logrotate,
rsyslog and wget. I still would like to see them demoted eventually, but
here is my reason to keep them for now:

  cron:
needed by logrotate

  ifupdown, isc-dhcp-{client,common}:
d-i should still configure this by default. Maybe demote once we
switch to a different default network configuration tool, cf. [2].

  logrotate:
should be kept as long as rsyslog is still important

  rsyslog:
needed for persistent logging by default; still tempted to
demote this (plus logrotate and maybe cron then)...
A standard install would still include rsyslog after all.

  wget:
useful to have a tool to grab files from a remote location; having
such a tool might be useful enough to keep it at important

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87twuav60u@deep-thought.43-1.org

Re: Bug#788702: override: make default install a bit smaller

[Ansgar Burchardt]

Control: tag -1 moreinfo

Cyril Brulebois k...@debian.org writes:
 I'd be happy to see a D-I Stretch Alpha 1 release before these changes
 are implemented so that we have a set of reference images. It would make
 it slightly easier to assess possible side effects once these changes
 are implemented. At the moment, we're waiting on a fix for the linux
 FTBFS on amd64 before we get a chance to upload debian-installer and go
 further for a release dance.

Sure, no need to hurry. Does the affect d-i (the images) directly? Or do
you just want to delay the changes in the Packages index to be able to
compare installations of Stretch before/after the changes?

I'll also wait with changes to init, but that needs further input from
systemd/sysvinit maintainers anyway[1].

And one more question: how does d-i make use of the tasksel{,-data}
and dmidecode? These are also installed in the target as important,
but I'm wonder if they are just used as part of the installation
process. I've refrained from changing their priority to avoid breakage.

Ansgar

  [1] 
https://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-June/007691.html


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/874mmaqb3i@deep-thought.43-1.org

Re: Please copy tools/win32-loader/unstable to .../testing

[Ansgar Burchardt]

Hi,

Adam D. Barratt a...@adam-barratt.org.uk writes:
 As discussed with OdyX, please copy the current version of
 tools/win32-loader from unstable/ to testing/.

 We'll then unblock the source package, so that we can get it migrated
 before the 8.1 point release (which includes a version of win32-loader
 that's newer than the current version in testing).

Just did so.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a8wjg9gm@deep-thought.43-1.org

Re: Packages to install be default for Stretch

[Ansgar Burchardt]

On 05/06/2015 11:34 AM, Martin Zobel-Helas wrote:
 On Tue May 05, 2015 at 20:45:09 +0200, Ansgar Burchardt wrote:
  * Packages currently at important:
 - cron:
   Not needed in chroot/container environments.
   - demote to standard
 
 RC.
 
 | important
 | Important programs, including those which one would expect to find on
 | any Unix-like system. If the expectation is that an experienced Unix
 | person who found it missing would say What on earth is going on, where
 | is foo?, it must be an important package.[6] Other packages without
 | which the system will not run well or be usable must also have priority
 | important. This does not include Emacs, the X Window System, TeX or any
 | other large applications. The important packages are just a bare minimum
 | of commonly-expected and necessary tools.
 
 cron is part of POSIX.

The problem here is what the expectations of an experienced UNIX person
are... I hopefully count as having some experience, but I don't expect
cron to be available everywhere (unlike say awk); I would still expect
it to be part of a reasonably small but not too limited character-mode
system (that is standard priority).

Note that I believe this has changed over time: with the advent of VMs
and containers the expectations what a system should minimally provide
have become smaller.

I'll not comment on where I see emacs and vim ;)

 http://www.unix.com/apropos-man/posix/1/cron/

Note that this also includes the following requirement:

| If standard output and standard error are not redirected by commands |
executed from the crontab entry, any generated output or errors shall |
be mailed, via an implementation-defined method, to the user.

That requires something to deliver mail. However I really don't think we
want a MTA to be at important priority.

 So either we fix the policy or cron needs to stay in 'important'.

at, m4, mailx, ... are also not at important, though required by
POSIX.

But as admitted earlier, I am not totally sure about cron. Maybe we
should keep it at important at least for stretch and revisit it in the
buster cycle; not sure yet.

Ansgar


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

Re: Packages to install be default for Stretch

[Ansgar Burchardt]

Paul Wise p...@debian.org writes:
 - cron:
   Not needed in chroot/container environments.
   - demote to standard

 A lot of packages ship cron jobs, I guess this means they will need to
 depend on cron?

They already have to depend on cron if it is required for proper
operation (or recommend it). But there are also alternatives like
anacron that might be more appropriate on common systems (say desktop
or laptop systems).

But I admit cron was very close on the maybe only demote in buster
list.

 - w3m:
   I think text-mode browsers are not worth including in the default
   install. It is *very* rare to not have another computer to use.
   Plus in the worst case the package is still just an apt-get away.
   - demote to optional

 I'd wager most use of w3m is for local-only web resources on servers.

But is this enough reason to keep w3m at priority standard? Personally I
would rather use ssh -D or such than bothering with a rather limited
text-mode browser.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq0m417o@deep-thought.43-1.org

Packages to install be default for Stretch

[Ansgar Burchardt]

Hi,

[ Please send replies only to boot@ ]

I would like to re-evaluate what we change by default for Stretch, that
is the list of packages with priorities required, important and
standard.  In general my plan involves installing less, taking into
consideration that requirements and expectations what should be
available in containers, chroots, on servers and desktop systems has
changed (at least IMHO).

Some ideas which might need further though:

 * I would really like to not list libraries at a priority greater than
   optional. This tends to accumulate cruft, cf. #758234

   Examples from today's unstable: gcc-4.7-base, gcc-4.8-base,
   gcc-4.9-base and gcc-5-base are at Priority: required.
   libboost-iostreams1.5{4,5}.0 are at Priority: important
   and so on.

   As far as I remember, debootstrap already ignores priorities for
   library packages (Section: libs).

 * It would be nice to have init demoted from required to
   important: it is not needed in environments like (buildd) chroots.
   This needs moving the essential bit to sysv-rc (which provides
   invoke-rc.d and update-rc.d) and possibly other changes.

 * I'm wondering if tasksel(-data) need to be important? I admit not
   having used it outside of d-i. Is the installed version used as part
   of the install process? Or could its priority be lowered to
   standard or optional?

 * Same for question for dmidecode: could the priority be lowered to
   standard?

Some priority changes which I believe could be implemented:

 * Packages currently at important:
- cron:
  Not needed in chroot/container environments.
  - demote to standard
- ifupdown, isc-dhcp-client, isc-dhcp-common:
  Not needed in chroot/container environments. Might no longer be
  needed on desktop systems (IIRC NetworkManager has a built-in DHCP
  client in the last release, though not yet used by default).
  - demote to standard
- groff-base, man-db, manpages:
  Not needed in chroot/container environments or many server
  environments.
  - demote to standard
- less:
  Not needed in chroot/container environments.
  - demote to standard
- logrotate, rsyslog:
  - tempted to demote to standard, but maybe only in buster
- nfacct:
  No idea why this is at Priority: important.
  - demote to optional
- netcat-traditional:
  No IPv6 support...
  - demote to standard, possibly to optional in buster
- traceroute, wget:
  Useful for debugging, but not needed in chroot/container
  environments.
  - demote to standard

 * Packages currently at standard:
- aptitude, aptitude-common:
  There's already apt.
  - demote to optional
- at:
  Rarely used (IMO).
  - demote to optional
- bc, dc:
  Rarely used (IMHO).
  - demote to optional
- dnsutils:
  bind9-host provides a (limited) DNS query interface. No need to
  install both bind9-host and dnsutils by default.
  - demote to optional
- bsd-mailx, exim4*, procmail, mutt:
  Often not useful on desktop systems, has popular alternatives,
  probably not needed in chroot/container environments either.
  - demote to optional
- ftp:
  Brr, ftp.
  - demote to optional
- info, texinfo, install-info:
  I admit having used info only in desperation. Most documentation
  comes in man page format.
  - demote to optional
- host:
  Transitional package.
  - demote to extra (+ Section: oldlibs)
- m4:
  Rarely used (AFAIK). Well, at least outside of auto* and sendmail.
  - demote to optional
- mlocate:
  Rarely used (AFAIK).
  - demote to optional
- nfs-common, rpcbind:
  NFS is not so common to include in every install. One less service
  listening to the network.
  - demote to optional
- patch:
  Does anyone use this w/o having build-essential installed?
  - demote to optional
- time:
  'time' is a builtin in at least bash and zsh.
  - demote to optional
- w3m:
  I think text-mode browsers are not worth including in the default
  install. It is *very* rare to not have another computer to use.
  Plus in the worst case the package is still just an apt-get away.
  - demote to optional
- whois:
  Too special to include in standard install.
  - demote to optional

Any comments and/or suggestion for other changes?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3qurhhm@deep-thought.43-1.org

Re: Please dak copy-installer 20150422 hint it into testing

[Ansgar Burchardt]

Cyril Brulebois k...@debian.org writes:
 FTPmasters, please sync the installer from sid to testing:

   dak copy-installer 20150422

Done.

Thanks for your work on d-i!
Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k2x3z4ci@deep-thought.43-1.org

Re: Please dak copy-installer 20150418 hint it into testing

[Ansgar Burchardt]

Hi,

Cyril Brulebois k...@debian.org writes:
 FTPmasters, please sync the installer from sid to testing:

   dak copy-installer 20150418

Just did that.

 I suppose we need to wait for a dinstall to actually install stuff from
 buildds, and another one after copy-installer is run? Or is it possible
 to have copy-installer now and 1352 to propagate changes right after
 that?

I don't think there is need to wait for dinstall: everything is
installed by the unchecked runs; dinstall just updates indices and does
housekeeping. Well, and mirror pushes of course.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq19blx0@deep-thought.43-1.org

Re: Bug#762361: override: make-guile:devel/extra

[Ansgar Burchardt]

Control: tag -1 + moreinfo d-i

Hi,

I'm going over the pending override changes and found another that
affects the standard installation:

  #762361: make-guile: change priority from standard to extra

There are no rdeps on make-guile, but it Provides: make; the make
binary package itself has optional priority.

Could the d-i team ack this change?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbh5wpbk.fsf...@deep-thought.43-1.org

Re: consistency check of sources of udebs

[Ansgar Burchardt]

Hi,

Cyril Brulebois k...@debian.org writes:
  2. https://ftp-master.debian.org/d-i

 The contents on the latter seems fishy to me, let's take this example:

The script had hard-coded suite ids and architectures which changed
meanwhile. I changed it to retrieve the current values from projectb:

  https://lists.debian.org/debian-dak/2015/04/msg1.html
  https://lists.debian.org/debian-dak/2015/04/msg2.html

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85384g3qyx@tsukuyomi.43-1.org

Re: Bug#780672: override: libsqlcipher0:libs/optional

[Ansgar Burchardt]

Control: tag -1 moreinfo d-i

Hi,

On 03/17/2015 05:44 PM, Alessandro Ghedini wrote:
 the libsqlcipher0 package had, erroneously, Priority: standard. It was 
 recently
 changed to optional in 3.2.0-1 (this is not mentioned in the changelog 
 AFAICT),
 but the ftp-master override still lists the package as standard.
 
 Just FYI, the package has an RC bug, but due to the wrong priority it is in 
 the
 key packages set, which means it is excluded from the autoremoval mechanism.

The installer team asked to ping them before changing priorities the
last time (at least for = standard), so I would like for them to ack
this, esp. given where we are in the release process.

libsqlcipher0 seems to have no rdepends besides sqlcipher and
libsqlcipher-dev, so lowering the priority to optional should not have
any negative impact.

Ansgar


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

Re: Please dak copy-installer 20150324 hint it into testing

[Ansgar Burchardt]

Cyril Brulebois k...@debian.org writes:
 FTPmasters, please sync the installer from sid to testing:

   dak copy-installer 20150324

Done.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnjg9q62@deep-thought.43-1.org

Re: Bug#781075: sbuild: Breaks d-i build by assuming it is a deb

[Ansgar Burchardt]

Hi,

On 03/24/2015 10:12 AM, Aurelien Jarno wrote:
 There have been other changes committed to this branch, so we should
 decide if they are jessie material or not. I have added Ansgar in Cc for
 that.

There are two other one-line changes:

- sbuild-createchroot: set profile=sbuild also for tar-based chroots
  https://bugs.debian.org/769289

  This makes tar-based chroots consistent with directory-based chroots.
  Reportedly not setting profile=sbuild means /dev/shm is not mounted,
  causing build failures.

  Should be included.

- sbuild-dumpconfig: sort keys of dumped hashes

  This just sorts options in the documentation (during build). Harmless
  to include, but makes the build reproducible. Has no effect at
  runtime.

  I don't think it's worth reverting this.

Ansgar


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

Re: Please dak copy-installer 20150107 hint it into testing

[Ansgar Burchardt]

Hi,

Cyril Brulebois k...@debian.org writes:
 dak copy-installer 20150107

Done.

Thanks for all your work on d-i,
Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oaqagu8k@deep-thought.43-1.org

Re: 7.8 dates

[Ansgar Burchardt]

Adam D. Barratt a...@adam-barratt.org.uk writes:
 On 2014-12-21 20:12, Steve McIntyre wrote:
 On Sun, Dec 21, 2014 at 04:20:16PM +, Adam Barratt wrote:
 On Sun, 2014-12-14 at 16:19 +0100, Ansgar Burchardt wrote:
 [...]
 I have no fixed plans yet, but would prefer to keep 3rd/4th free. The
 other days all look fine.

 Based on other responses, it looks like the 10th would work best (so
 with the p-u freeze being the weekend of 3rd/4th). Does that still
 work
 for everyone?

 I guess so, yes...

 press@ also confirmed on IRC that the 10th was okay, so we just need
 an ftp-master ack.

10th is okay with me.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d275jp92@deep-thought.43-1.org

Re: 7.8 dates

[Ansgar Burchardt]

Hi,

Adam D. Barratt a...@adam-barratt.org.uk writes:
 In theory the 7.8 point release should be in December, but that's often
 a pain to organise. So let's look at January instead:

 3rd / 4th - I'm busy on the Saturday
 10th / 11th - Fine for me
 17th / 18th - jmw's BSP
 24th / 25th - I can do Saturday morning, but will be afk from early
 afternoon to Sunday afternoon
 31st / 1st - Fine for me

I have no fixed plans yet, but would prefer to keep 3rd/4th free. The
other days all look fine.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhmajm28@deep-thought.43-1.org

Bug#761815: installation adds entries for USB media to /etc/fstab which confuse udisks

[Ansgar Burchardt]

Hi,

Gaudenz Steinlin gaud...@debian.org writes:
 Just to give some context: This bug is about adding entries for USB mass
 storage devices to /etc/fstab on installation.

 Olliver Schinagl oli...@schinagl.nl writes:
 I just got bitten by this bug myself.

 As a long time gentoo + ubuntu user, I was baffled after getting the 
 solution to this problem. I have worked through several different kind 
 of fstab files, but this was a serious wtf. Why wasn't removable storage 
 working for me? I just couldn't figure it out, everything 'looked' normal.

 I'd increase the severity of this report, as it is far far from
 obvious.

 I just had a look at the relevant code in partman-target
 finish.d/fstab_removable_media_entries. As far as I understand it (no
 testing done) these entries are added if a USB device is currently
 plugged in. The code is from 2004 (commit
 af81206d02f8d668dab382e5ec8483ccbc90a506) when this probably made sense.

 Does it make any sense anymore to keep this code? IMO the fstab entries
 should at least not be added when udisks is installed. I attached a
 patch (not yet tested) which does this.

My personal opinion is that the right thing is to not add entries to
/etc/fstab for removable devices at all (where removable means that
the device itself can be removed, not just devices with removable
media): I think there is no guarantee that the entry added to /etc/fstab
actually matches the right device later. Plus the problems with udisks.

 My patch currently only prohibits adding of USB device entries. Should
 this be extended to floppies and CD-ROMs? What about kfreebsd and hurd?

I'm not sure about CD-ROM/floppies or other devices with removable
media. I also don't know about kFreeBSD or Hurd.

 IMO this should be fixed before the release as it causes unexpected and
 inconsistent behavior.

Agreed. I've personally at least encountered 3 people having problems
with using USB media under desktop environments (KDE or GNOME) due to
these entries in /etc/fstab.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnnj5exe.fsf...@deep-thought.43-1.org

Re: Please dak copy-installer 20141002

[Ansgar Burchardt]

Cyril Brulebois k...@debian.org writes:
 please sync the installer from sid to testing:

   dak copy-installer 20141002

$ dak copy-installer 20141002

Will copy installer version 20141002 from suite unstable to
testing.
Architectures to copy: i386, arm64, powerpc, mipsel, amd64, armel, s390x, 
kfreebsd-i386, mips, armhf, kfreebsd-amd64, ppc64el
Architectures to skip: 
Installer has been copied successfully.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjddabp5@deep-thought.43-1.org

Re: 7.7 planning

[Ansgar Burchardt]

Hi,

Adam D. Barratt a...@adam-barratt.org.uk writes:
 We're (over)due another wheezy point release; this time, 7.7. I propose
 we go for one of:

 11/12 October
 18/19 October
 25/26 October

All of these are still good for me.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85d2amq1si@tsukuyomi.43-1.org

Bug#761815: installation adds entries for USB media to /etc/fstab which confuse udisks

[Ansgar Burchardt]

Package: partman-target
Version: 91
Severity: normal

d-i adds entries like

  /dev/sdb1 /media/usb0 auto rw,user,noauto 0 0

to /etc/fstab. These will then be used by udisks instead of the
default. This is problematic as they miss important options, such as
making vfat writable by the user.

I think they come from finish.d/fstab_removable_media_entries in
partman-target.

Some other user had this problem and asked me, we found the entry in
/etc/fstab and I was able to get those by a new installation in KVM
using the Jessie Beta 1 version of the installer.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140916085118.12989.14893.report...@marvin.43-1.org

Re: Summary from the d-i / debian-cd BoF at DC14

[Ansgar Burchardt]

Hi,

Steve McIntyre st...@einval.com writes:
 Debian-CD Plans
 ===

 * Which images do we want to make for Jessie? Currently we have, for
   every architecture:
   + netinst
   + CD set
   + alternate versions of CD#1 for each of the desktops (gnome/kde/xfce/lxde)
   + DVD
   + BD (x86 only)
[...]
   Discussion about trying to make desktops fit on 1 CD. XFCE and LXDE
   both fit on 1 CD, Gnome and KDE basically don't fit any more. We
   need to work out what to do there.

   Should we still build Gnome or KDE CDs at all? Not clear. Let's have
   the discussion.

I was wondering if it was possible to build installer images without a
specific size limit, i.e. include all packages for tasks x, y, z. Doing
so might result in nice images for GNOME, KDE, XFCE, * that are just as
large as they have to be.

 Discussion and questions
 

 * Question about the status of signed images.
   + All of the official images created and distributed via cdimage.d.o
 are signed:
[...]
   + Both of these keys are in the WoT, cross-signed by Steve and a few
 other folks.

Are both keys in debian-role-keys.gpg (in the debian-keyring package)?

Ansgar


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/85oauor6up@tsukuyomi.43-1.org