Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
On Sun, 2023-07-16 at 12:54 +0100, Simon McVittie wrote: > On Sun, 16 Jul 2023 at 12:42:11 +0100, Luca Boccassi wrote: > > In the meanwhile, I'll immediately revert the sabotage. > > Both of you, please don't turn this into an NMU war in the archive: > that doesn't benefit anyone. I would have preferred it if Adam had not > immediately uploaded a 0-day revert, but preserving the status quo from > bookworm is not the worst state to be in while we discuss this. No, we should just have made a decision a long time ago and not go back and forth the entire time. That we do not do that shows lack of leadership in Debian. (And yes, you can reconsider stuff, but the barrier to stop a process and reconsider it again should not be zero and probably higher the later one does block progress.) > If Adam's concerns about this change are valid, then we should address > them, either by doing something different in debootstrap or by reporting > bugs against affected packages. I guess Adam could go ahead with the GR he wanted to bring up the last time he did NMUs this way (for reverting enabling usrmerge by default on upgrades). I would like to ask Adam to stop interfering with usrmerge until that long announced GR is there (and note that if we waited for that GR to happen as Adam demanded then we would still be waiting). > If Adam's concerns about this change turn out to be unfounded, then we > should reinstate my change (as NMU'd by Luca) in a calm and considered > way, and all we will have lost is a few days of progress and a few bytes > of changelog. That is false in so far as that only considers technical changes we get. However we also lose more and more energy/motivation/* even if we eventually go ahead as planned, i.e., social costs are not considered, but should be (IMHO). Ansgar
Re: 11.7 planning + bookworm planning
Hi, On Sun, 2023-04-23 at 18:02 +0200, Paul Gevers wrote: > Any FTP master for 10 or 17 June? So far it looks fine for me. > kibi - 10, 17, 24 d-i > Luna - 10, 17, 24 CD testing > elbrus - 10, 17, 24 release team > adsb - 10, 17, 24 release team > Sledge - 10, 17, 24 images team > donald - 10, 17 press Ansgar
Re: Please dak copy-installer 20230217
Hi, Cyril Brulebois writes: > FTP team, please sync the installer from sid to testing, as it seems to > be Installed for all release architectures (9 total, even if mipsel just > went in): > > dak copy-installer 20230217 Done: +--- | $ dak copy-installer 20230217 | | Will copy installer version 20230217 from suite unstable to | testing. | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el | Architectures to skip: | Installer has been copied successfully. +--- Thanks for your work on d-i! Ansgar
Re: 11.6 planning
On Thu, 2022-11-17 at 21:33 +, Adam D. Barratt wrote: > Please could you indicate your availability and preferences between: > > - December 3rd No time here. > - December 10th > - December 17th These are still free. Ansgar
Re: Bug#1020426: usrmerge fails configure: Can't locate autodie.pm in @INC [...] at /usr/lib/usrmerge/convert-etc-shells line 13
Control: reassign -1 base-installer 1.208 Control: retitle -1 base-installer: pkgdetails.c: GETDEPS: remove multi-arch qualifier from dependencies On Wed, 2022-09-21 at 16:47 +0200, Thomas Deutschmann wrote: > I was trying to install Debian bookworm using > firmware-testing-amd64-netinst.iso from 2022-09-21 14:22 > (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including- > firmware/daily-builds/sid_d-i/current/amd64/iso-cd/). > > However, debootstrap failed: [...] > > Sep 21 14:20:30 debootstrap: Can't locate autodie.pm in @INC (you > > may need to install the autodie module) (@INC contains: /etc/perl > > /usr/local/lib/x86_64-linux-gnu/perl/5.34.0 > > /usr/local/share/perl/5.34.0 /usr/lib/x86_64-linux-gnu/perl5/5.34 > > /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base > > /usr/lib/x86_64-linux-gnu/perl/5.34 /usr/share/perl/5.34 > > /usr/local/lib/site_perl) at /usr/lib/usrmerge/convert-etc-shells > > line 13. There are two bugs here: 1. We don't want to install usrmerge in this case; there is a merge request for debootstrap pending[1]. 2. debootstrap fails to resolve the dependency of usrmerge correctly. perl and perl-modules-* is not extracted, so autodie.pm is missing. I think this is a bug in base-installer's pkgdetails.c: running +--- | /usr/lib/debootstrap/pkgdetails GETDEPS ... usrmerge +--- in d-i gives "perl:any \n libfile-find-rule-perl", however debootstrap's internal Perl implementation of pkgdetails does remove such a suffix: +--- | $d =~ s/:.*//; +---[ functions ] Ansgar [1]: https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/76
Re: debian-installer 20220917 via tpu
Cyril Brulebois writes: > FTP Masters, please sync the installer from *tpu* to testing, once it's > available there. > > dak copy-installer 20220917 -s bookworm-proposed-updates Done: +--- | $ dak copy-installer 20220917 -s bookworm-proposed-updates | | Will copy installer version 20220917 from suite bookworm-proposed-updates to | testing. | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el | Architectures to skip: | Installer has been copied successfully. +--- Ansgar
Re: Possible clean-up: installer-* directories
Cyril Brulebois writes: > As you know, installer- directories accumulate d-i artifacts over > time. [...] > For unstable, we have… older things: > > 20190118/ > 20190410/ > 20190623/ > 20190702/ > 20191129/ > 20200314/ > 20201202/ > 20210415/ > 20210606/ > 20210731/ > current → 20210731 > > I don't think any of those makes any sense to keep around (even 20210731 > is what used to be in 11.0, that's not even 20210731+deb11u5 aka. what's > in 11.5; and both are available in bullseye anyway), so I suppose all of > them could go away. I moved them to the morgue to be archived (also snapshot.d.o should have them anyway). I removed 20210731 from testing as well. Testing now only contains the freshly copied 20220914 version. Ansgar
Re: Please dak copy-installer 20220914
Cyril Brulebois writes: > FTP Masters, please sync the installer from sid to testing, as it seems > to be Installed for all release architectures (9 total): > > dak copy-installer 20220914 Done: +--- | $ dak copy-installer 20220914 | | Will copy installer version 20220914 from suite unstable to | testing. | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el | Architectures to skip: | Installer has been copied successfully. +--- Ansgar
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
On Sat, 2022-09-03 at 21:06 -0400, Nicholas D Steeves wrote:
> First, the automated case: Currently DI statically sets the rootfs to be
> "subvolume=@rootfs", which is a value unique to Debian. The simple
> thing to do is to detect that a device has been formatted to btrfs
> before mounting, and then try to mount "-o subvol=@rootfs" as Ansgar
> suggested. One step more flexible is to have a Rescue policy of
> something like only supporting read-write subvolumes with a name that
> matches '.*\@rootfs.*', and that exist in the / of the volume. Ie:
> maxdepth=1.
Why not set the default subvolume to @rootfs then? (What `btrfs
subvolume set-default` does.)
That would also be useful for use with `systemd-gpt-auto-generator`.
It would not help with existing systems using @rootfs, but be
compatible with installations not using that.
> awk '{print $1}' < /MOUNTPOINT/etc/issue
> or perhaps
> grep 'ID\=debian' < /etc/os-release
It should also test for `/usr/lib/os-release` in case the symlink in
`/etc/` is not present.
Ansgar
Bug#1018894: rescue-mode: mounts wrong btrfs subvolume
Source: rescue Version: 1.85 Severity: important I've installed a system using btrfs for the root filesystem with d-i (with disk encryption as well). As grub wasn't properly installed (not registered with EFI), I tried to use the rescue mode to reinstall grub. However, mounting the root filesystem failed: /target contained only a "@rootfs" subdirectory. So running a shell in the target fs failed. Manually mounting the filesystem with `-o subvol=@rootfs` worked. This was with Debian 11.4. Ansgar
Re: Bug#1018788: override: rsyslog:admin/optional
On Tue, 2022-08-30 at 23:23 +0200, Cyril Brulebois wrote: > No objections from my side, but I'd like to check something: overrides > are per suite, and should only change for testing/unstable/experimental, > not for stable, when acting on such requests, right? Yes. Changing the Priority in unstable will automatically propagate to testing, but (old)stable will be unaffected. Ansgar
Re: buster EOL (10.13) and 11.5 planning
Hi, On Thu, 2022-07-28 at 17:09 +0100, Adam D. Barratt wrote: > - August 20 > - [August 27 doesn't work for at least me and the Images Team, so nope] > - September 3rd > - September 10th All dates should still work for me. > any opinions on whether we should do them at the same time or > separately. Either is fine with me. Ansgar
Bug#1016421: installation-reports: does not accept IPv6 link-local address for default route
Package: installation-reports Severity: normal Tags: ipv6 Boot method: DVD image Image version: Debian 11.3 (amd64/netinstall) Date: Machine: IPv6-only VM in Hetzner cloud (https://cloud.hetzner.de) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [E] Hetzner asks to specify a link-local address as the default route (fe80::1). This works with `ip route` with the `onlink` flag, but d-i says "Unrechable gateway: The gateway address you entered is unreachable." Ansgar
example-preseed.txt: please use CIDR notation isntead of netmask
Hi, example-preseed.txt[1] contains the following: +--- | #d-i netcfg/get_ipaddress string 192.168.1.42 | #d-i netcfg/get_netmask string 255.255.255.0 | [...] | #d-i netcfg/get_ipaddress string fc00::2 | #d-i netcfg/get_netmask string ::::: +--- At least in the interactive mode of the installer one can instead specify the address as 192.168.1.42/24 or fc00::2/64 instead and won't get asked about the netmask. I think the example should use this notation instead, especially for non-legacy IP. (I've not verified it works with preseeding though.) I've not found where example-preseed.txt comes from; a quick grep through webwml.git did not find it. So I just write to this list :-) Ansgar [1]: https://www.debian.org/releases/stable/example-preseed.txt
Bug#1015749: installation-reports: installation w/o locale results in non-working GNOME Terminal
Package: installation-reports Severity: normal Boot method: CD Image version: debian-11.3.0-amd64-netinst.iso Date: 2022-07-20 Machine: qemu VM (via libvirt) I installed Debian, choose "No localization" at the question and selected GNOME to be installed (or kept it selected). All other setting were left on the default. The relevant part of /var/log/installer/syslog is probably this: +--- | Jul 20 09:38:15 localechooser: info: Language = 'C' | Jul 20 09:38:15 localechooser: info: line=C;0;;C;en; | Jul 20 09:38:15 localechooser: info: Set debian-installer/language = 'en' | Jul 20 09:38:15 localechooser: info: Default locale = 'C' | Jul 20 09:38:15 localechooser: info: Set debian-installer/consoledisplay = '' | Jul 20 09:38:15 debconf: Setting debconf/language to en | Jul 20 09:38:15 gtk-set-font: Switching to font 'DejaVu Sans' for 'en' | Jul 20 09:38:21 localechooser: info: Set debian-installer/country = 'DE' | Jul 20 09:38:21 localechooser: info: Set debian-installer/locale = 'C' | Jul 20 09:38:21 localechooser: info: System locale (debian-installer/locale) = 'C' +--- In the installed system, I can't do much as gnome-terminal does not start. It just shows the app-is-starting animation and then stops. In the journal I find error messages like: +--- | Jul 20 11:58:53 [...] systemd[990]: Created slice app-org.gnome.Terminal.slice. | Jul 20 11:58:53 [...] systemd[990]: Starting GNOME Terminal Server... | Jul 20 11:58:53 [...] gnome-terminal-server[1915]: Non UTF-8 locale (ANSI_X3.4-1968) is not supported! | Jul 20 11:58:53 [...] systemd[990]: gnome-terminal-server.service: Main process exited, code=exited, status=8/n/a | Jul 20 11:58:53 [...] systemd[990]: gnome-terminal-server.service: Failed with result 'exit-code'. | Jul 20 11:58:53 [...] systemd[990]: Failed to start GNOME Terminal Server. +--- Running `localectl set-locale C.UTF-8` as root made the system work. It would be good if choosing "No localization" would use "C.UTF-8" instead of "C" or there was at least an option for "C-UTF-8". I think I tried setting "C.UTF-8" via preseeding recently and that was rejected as an invalid choice (not 100% sure). Ansgar
Bug#1014902: installation-reports: grub-efi-amd64-signed not installed with base-installer/install-recommends set to false
Package: installation-reports Severity: normal Boot method: CD Image version: debian-11.3.0-amd64-netinst.iso Date: 2022-07-08 Machine: qemu (via libvirt) I installed Debian with the following preseed option: d-i base-installer/install-recommends boolean false The VM uses UEFI and has secure boot enabled (the default). The installation correctly installed the "shim" loader, but it looks like "grub-efi-amd64-signed" is only pulled in via a Recommends from "grub-efi-amd64-bin". This results in only the unsigned version of grub getting installed (and shim not installed to /boot/efi) and a non-booting system. I think the logic selecting "shim" to be installed should also pull in the signed version of grub explicitly to have at least a bootable system even with install-recommends set to false. Ansgar
Bug#1014343: d-i live installer: /etc/mailname contains debian-BULLSEYE-live-builder-AMD64
Package: installation-reports Severity: normal Boot method: CD Image version: debian-live-11.3.0-amd64-standard.iso Date: 2022-07-04 Machine: qemu VM Comments/Problems: I installed Debian using d-i from the live image. The file /etc/mailname on the installed system says: +--- | debian-BULLSEYE-live-builder-AMD64 +---[ file:///etc/mailname ] Ansgar
Re: 11.4 planning
Hi, On Fri, 2022-06-17 at 20:31 +0100, Adam D. Barratt wrote: > - July 2nd (means freezing next weekend, but so be it) > - July 9th Both would work for me. Ansgar
Bug#1008489: reassing to correct package
Control: reassign -1 dpkg Control: found -1 1.21.2 On Tue, 29 Mar 2022 16:44:32 +0200 Adam Borowski wrote: > Control: reassign -1 deboostrap > Control: found -1 1.0.102 > Control: creates unsupported filesystem layout > > > I think the warning emitted by dpkg's postinst script about Debian's > > default filesystem layout is not appropriate and at least partially > > misleading. Several other people agreed with this sentiment. > > Aye, good idea. Let's fix the problem at the source. > No installation tools other than debootstrap have this problem: not > cdebootstrap, not multistrap, not mdebstrap. > > Thus, debootstrap should simply not create tainted installs by default. Please don't use my bug report for trolling. Thanks, Ansgar
Re: Finding a tentative bullseye release date
Hi, On Tue, 2021-07-20 at 22:35 +0200, Paul Gevers wrote: > We currently don't have any day yet with all involved > teams comfortably present, the one coming closest is 4 September. > Somebody from ftp available on 14 august? That should be doable. Ansgar
Re: Please dak copy-installer 20210606
Hi, Cyril Brulebois writes: > dak copy-installer 20210606 Done: +--- | Will copy installer version 20210606 from suite unstable to testing. | Architectures to copy: i386, amd64, mipsel, ppc64el, s390x, armel, armhf, arm64, mips64el | Architectures to skip: | Installer has been copied successfully. +--- Ansgar
Re: Finding a tentative bullseye release date
On Sun, 2021-05-30 at 09:09 +0200, Paul Gevers wrote: > 26 June > 3 July > 10 July > 17 July [Steve (CD), press] > 24 July [Steve (CD), press] > 31 July > 7 August > 14 August Currently all of these are fine for me. Ansgar
Re: Tentative summary of the AMD/ATI/NVidia issue
Lucas Nussbaum writes: > It looks like the three open paths for resolution are: > > A) understand and restore the behaviour from Debian 10, that is, get X > to work in a degraded mode after installation. How it worked with Debian > 10 (and why it doesn't with Debian 11) is unknown. > > B) In the installer, detect that firmware-amd-graphics or > firmware-misc-nonfree should be installed, and either install it (?), > or redirect the user to the unofficial installer that includes them. > > C) Do nothing and document this in the release notes There is at least also D) Install (non-free) firmware and include it in official install media. I don't think degraded operation (just vesa, no sound, no wifi, known issues in microcode, ...) will continue to be an attractive option. So maybe we should revisit whether we should just include firmware; I wanted to suggest so at least for Bookworm. Ansgar
Re: Finding a tentative bullseye release date
にゃあ！ On Wed, 2021-04-21 at 21:19 +0200, Paul Gevers wrote: > Can you please let us know if/when you're available? > May 1 CD, Press > May 8 CD, Press > May 15 CD > May 22 CD, Press > May 29 (CD) All should be fine for me. It's not like one can do much other interesting things currently. Ansgar
Re: Please dak copy-installer 20201202
Cyril Brulebois writes: > FTP Masters, please sync the installer from sid to testing, as it seems > to be Installed for all release architectures (9 total): > > dak copy-installer 20201202 Done. Ansgar
Re: Please dak copy-installer 20200314
Cyril Brulebois writes: > dak copy-installer 20200314 Done. Ansgar
Re: Please dak copy-installer 20191129
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing, as it seems > to be Installed for all release architectures (9 total): > > dak copy-installer 20191129 Done. > FWIW, unless somebody objects, it should be fine to get rid of all > previous versions in both testing and unstable. I'll try to remember to do so in the next days. Thanks for your tireless work on d-i. Ansgar
Re: Bug#944116: tasksel: Please make another source-only upload
Boyuan Yang writes: > What I understand so far is that something went *really* wrong with the 3.56 > upload made by nicoo: Yes, for some reason task-hebrew-desktop_3.56 and a few others were removed as cruft: +--- | Date: Tue, 29 Oct 2019 04:41:29 + | Ftpmaster: Scott Kitterman | Suite: unstable | Binaries: | task-chinese-s_3.56 [all] | task-cyrillic-kde-desktop_3.56 [all] | task-hebrew-desktop_3.56 [all] | task-macedonian_3.56 [all] | task-slovenian-kde-desktop_3.56 [all] | Reason: [auto-cruft] NBS (no longer built by tasksel) +---[ https://ftp-master.debian.org/removals.822 ] We had an issue where old arch:all packages were detected as cruft when buildds had not built the new version yet (which should no longer happen thanks to Ivo De Decker's patch[1]), but here these are maintainer-provided packages :/ Maybe a race between dak accepting the package from NEW (so it's only half-installed) and a parallel process generating the cruft report based on that half-installed state? (If this is the case, then the patch from above should also help.) [1]: https://salsa.debian.org/ftp-team/dak/merge_requests/163 I don't have resources to look into this in more detail currently though. So I suggest to do an extra upload to NEW for now. Ansgar
Bug#936050: please add systemctl daemon-reload hint to /etc/fstab
Harald Dunkel writes: > I am not sure, but isn't systemd supposed to figure this out on the > next run anyway? Yes, but the "next run" might be the next system restart (or something else running `systemctl daemon-reload`). One might get unexpected behavior until such a time. Ansgar
Re: Please dak copy-installer 20190702
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing, as it seems > to be Installed for all release architectures (10 total): > > dak copy-installer 20190702 Done. Ansgar
Re: Please dak copy-installer 20190623
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20190623 Done. Thanks for your work, Ansgar
Bug#930428: debootstrap should ensure matching _apt uid
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
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
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 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
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: Going ahead with non-free-firmware
Hi, Hideki Yamane writes: > Is there any progress about non-free-firmware section? Sadly no; I think some later discussion made me doubt that there was indeed consensus about having non-free-firmware (and only that and not non-free-doc, non-free-drivers, non-free-*). Nor about how it would work. I don't think we should add a new component without having that (component meaning main, contrib, non-free, non-free-firmware here). They are not nice to handle on the archive side. Ansgar >> 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: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?
Steve McIntyre writes: > There is a deeper worry about builds that may be done against the > "weak" background. Although buildd chroots are easily fixed up, > there's going to be a (small, but unknown) set of maintainers who > might be uploading binaries from merged systems. I think we're making > good progress on source-only uploads and building in clean chroots > etc., but... It's also likely not easy to pick up on "wrong" binary > packages built this way. That is not a new problem: maintainers can already upload packages that refer to binaries in /usr/local/bin when they have locally installed binaries and autodetection using $PATH is used? /usr/local/bin is usually before /usr/bin and /bin after all. dpkg could add a "not-built-in-a-clean-chroot" flag to detect those. Ansgar
Re: Bug#914876: override: libnss-systemd:admin/standard
On Wed, 2018-11-28 at 08:49 +0100, Michael Biebl wrote: > we want to have libnss-systemd installed by default if systemd is the > active PID 1, while still retaining the option to uninstall the package. > > For that, the systemd-sysv package gained a Recommends: libnss-systemd [1] > > Unfortunatly, Recommends are not considered during the initial bootstrap > installation, so newly installed systems will not have libnss-systemd. > > We were in a similar situation for libpam-systemd. The approach we took > back then was to bump the pio to standard. This seems to have worked out > ok, so I'd like to ask that the same be done with libnss-systemd. > > [1] > https://salsa.debian.org/systemd-team/systemd/commit/577df340cad51d5779d646d9aefa28c3c1b90d4c > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803184 Asking -boot@ for an ack. Ansgar
priority of packages added to the archive
Hi, FWIW I just changed the priority of both netplan.io and reportbug-gtk to "optional". I also think we should no longer use the Priority field from the package, but instead use "optional" by default when adding new overrides in the future (dak can still indicate that the package uses a different value, but it should choose "optional" if nothing is done to explicitly choose a different priority). Ansgar
Re: Please dak copy-installer 20190118
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
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
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 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
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
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
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
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
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
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
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
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
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
Hideki Yamane <henr...@iijmio-mail.jp> 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
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
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
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] <https://lists.debian.org/debian-devel/2016/09/msg00269.html> > > 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
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
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
Cyril Brulebois <k...@debian.org> 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
Emmanuel Kasper <m...@debian.org> 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
Dan Nicholson writes: > On Fri, Aug 18, 2017 at 2:48 PM, Henrique de Moraes Holschuh > <h...@debian.org> 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
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
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
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
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
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
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
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
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
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
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
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
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()
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
Cyril Brulebois writes: > FTPmasters, please sync the installer from sid to testing: > > dak copy-installer 20161031 Done. Ansgar
Re: Please dak copy-installer 20161027
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
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)
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
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] <https://lists.debian.org/debian-devel/2016/09/msg00269.html> [2] <https://bugs.debian.org/838388> [3] <https://github.com/aburch/debootstrap> [4] <https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=usrmerge;users=m...@linux.it>
Bug#837649: debootstrap: Add support for Packages.xz
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
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
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) > <ftpmas...@debian.org>" > gpgv: Signature made Sat Apr 25 13:05:42 2015 CEST > gpgv:using RSA key 64481591B98321F9 > gpgv: Good signature from "Squeeze Stable Release Key > <debian-rele...@lists.debian.org>" > 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?
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
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`
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
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
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
On Thu, 7 Jul 2016 14:46:36 +0200 Marco d'Itri <m...@linux.it> wrote:
> On Jul 05, Cyril Brulebois <k...@debian.org> 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
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] <https://bugs.debian.org/810301#69>
-- 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
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
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
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"
reassign 828052 www.debian.org retitle 828052 https://www.debian.org/ports: list of ports is outdated Jeffrey Walton <noloa...@gmail.com> 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] <https://buildd.debian.org/stats/graph-ports-week-big.png>
Bug#825034: debootstrap: fails if no base packages are to be installed
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
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] <https://bugs.debian.org/756023>
Re: Please dak copy-installer 20160516
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
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
Cyril Brulebois <k...@debian.org> 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
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
