Re: Firmware GR result - what happens next?
On Mon, Oct 03, 2022 at 01:18:55AM +0300, Dmitry Baryshkov wrote: > вс, 2 окт. 2022 г. в 22:36, Steve Langasek : > > > So this is the one bit that I don't think we currently have a good > > > answer for. We've never had a specific script to run on upgrades (like > > > Ubuntu do), so this kind of potentially breaking change doesn't really > > > have an obvious place to be fixed. > > > > > Obviously we'll need to mention this in the release notes for > > > bookworm. Should we maybe talk about adding an upgrade helper tool? > > > > I heartily endorse ubuntu-release-upgrader, it has been useful in addressing > > uncounted upgrade issues over the years and I think something like this > > would be a nice addition to Debian as well. Two caveats: > > I'd kindly ask against additional upgrade scripts. It is too easy to > miss them, especially if one has been using Debian for ages with bare > apt-get update && apt-get dist-upgrade. > Moreover such a script will not help people that are already using testing. > > For the past few decades, updating the setup was always a job of the > package scripts. This is getting OT in this thread, but I agree with the many that are against such upgrading script. I consider even the need for such thing a bug, as each package should take care of its own quirks. Besides, if something wants to mess with my system configuration, that's an even greater bug for me (something that IME ubuntu has been doing more and more over the last years). I can live with an APT hook warning me if I have non-free but not non-free-firmware, but I would prefer to even do without that. For stable→stable updates there are the release notes for this tiny change. For testing/unstable users, they should really read d-d-a, and this change be announced there (if it hasn't already). -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1012371: Updating the nobootloader Uploaders list
Source: nobootloader
Version: 1.63
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint
Stephen R. Marenka has retired, so can't work on
the nobootloader package anymore (at least with this address).
We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.
(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)
Thanks.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Bug#994532: Installer only gives internal hand drive install option not external USB drive
Control: reassign -1 installation-reports On Fri, Sep 17, 2021 at 06:47:00PM +0800, Ross Maloney wrote: > Package: debian-testing-amd64-netinst.iso Reassigning to a "real" package (BCCing the installer team). > Hello. > > I have tried to install Bullseye from both the standard 11.0.0 release and > also the daily builds of 16 and 17 of this month. I am installing on a > MacPro 2019 using a boot image which I dd from the netinst.iso posted > images. Everything functions normally in the non-graphical install until > the manual partitioning of the disk phase. At this stage, the USB drive I > have connected to the MacPro is not seen. This is the problem. > Installation on this external drive is the aim of the installation. > > I have previously installed Bullseye sid on this hardware configuration. > That image dated 12 October 2020 gives the identification 5.8.0-2-amd64. > This problem appears to be related to the installer. I have checked the > hardware configuration by installing the old October 2020 image successfully > today. > > Is there a reason the installer now in use only offers limitted drive > options, or is this a bug? > > Regards, > > Ross Maloney -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#959037: lintian: FPOS? for executable-in-usr-lib
On Tue, Apr 28, 2020 at 11:38:44PM +0100, Steve McIntyre wrote:
> ACK. d-i won't be looking in /usr/libexec. Please leave things where
> they are...
Good, then @lintian-maint: please exclude udebs from this check :)
(as I think used to be in the past, since I don't think I saw this tag
years ago in this package, but I know it has been there for a while…)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Bug#959037: lintian: FPOS? for executable-in-usr-lib
On Tue, Apr 28, 2020 at 02:39:49PM -0700, Felix Lechner wrote: > On Tue, Apr 28, 2020 at 4:27 AM Mattia Rizzolo wrote: > > I'm CCing d-boot@ for confirmation, since I'm not sure if maybe I'm > > doing something wrong. > > > > Today I notices these tags: > > > > P: eatmydata-udeb udeb: executable-in-usr-lib > > usr/lib/finish-install.d/13eatmydata-udeb > > N: > > I expanded that odd tag description with some text from the original > bug report. I also adjusted the references. Perhaps the remark > regarding /usr/libexec is helpful: > > The package ships an executable file in /usr/lib. > > Please move the file to /usr/libexec. Not quite, as I'm positive those directories is where d-i go look for hooks, and I doubt just moving them to libexec is useful. I'm re-instating the CC on d-boot@ to see if it sparks some comment... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#959037: lintian: FPOS? for executable-in-usr-lib
Package: lintian
Version: 2.68.0
X-Debbugs-Cc: debian-boot@lists.debian.org
Hi,
I'm CCing d-boot@ for confirmation, since I'm not sure if maybe I'm
doing something wrong.
Today I notices these tags:
P: eatmydata-udeb udeb: executable-in-usr-lib
usr/lib/finish-install.d/13eatmydata-udeb
N:
N:policy, 9.1.1,
N:https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
N:
N:Severity: pedantic
N:
N:Check: usr/lib
N:
P: eatmydata-udeb udeb: executable-in-usr-lib
usr/lib/post-base-installer.d/01eatmydata-udeb
P: eatmydata-udeb udeb: executable-in-usr-lib
usr/lib/pre-pkgsel.d/10eatmydata-udeb
That being an udeb I know many things don't apply to it, but I'm not
sure if maybe I hsould place those d-i hooks elsewhere.
If, as I think, they are in the right place, please teach lintian to
ignore that in udebs.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Bug#930684: pbuilder: creation of build env fails when run inside Docker container
ost-system1.67.0_1.67.0-13_amd64.deb' added > I: new cache content 'libsigc++-2.0-0v5_2.10.1-2_amd64.deb' added > mount: failed to read mtab: No such file or directory > mount: failed to read mtab: No such file or directory > I: unmounting dev/pts filesystem > I: unmounting dev/shm filesystem > I: unmounting proc filesystem > I: unmounting sys filesystem > I: creating base tarball [/var/cache/pbuilder/base.tgz] > mount: failed to read mtab: No such file or directory > I: cleaning the build env > I: removing directory /var/cache/pbuilder/build/489 and its subdirectories > rm: cannot remove '/var/cache/pbuilder/build/489/dev/ptmx': Device or > resource busy > mount: failed to read mtab: No such file or directory > I: cleaning the build env > I: removing directory /var/cache/pbuilder/build/489 and its subdirectories > rm: cannot remove '/var/cache/pbuilder/build/489/dev/ptmx': Device or > resource busy > rmdir: failed to remove '/var/cache/pbuilder/build/489/dev': Directory not > empty > rmdir: failed to remove '/var/cache/pbuilder/build/489': Directory not empty > > root@d81f634fe4a0:/# cat /proc/mounts > cat: /proc/mounts: No such file or directory > > root@d81f634fe4a0:/# mount proc /proc -t proc > root@d81f634fe4a0:/# cat /proc/mounts > overlay / overlay > rw,relatime,lowerdir=/var/lib/docker/overlay2/l/TPOD4JNRBNCTMXNHYCY5XVRBQ3:/var/lib/docker/overlay2/l/TSD62UVCIJQ2LJ4XTUHKTVEK77,upperdir=/var/lib/docker/overlay2/aa29cac2d0ebecfb12fdd71a9952845140052615f2bd746c4336daa8d7a4d533/diff,workdir=/var/lib/docker/overlay2/aa29cac2d0ebecfb12fdd71a9952845140052615f2bd746c4336daa8d7a4d533/work > 0 0 > tmpfs /dev tmpfs rw,nosuid,size=65536k,mode=755 0 0 > devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 > 0 0 > sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 > tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0 > cgroup /sys/fs/cgroup/systemd cgroup > rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd > 0 0 > cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices > 0 0 > cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer > 0 0 > cgroup /sys/fs/cgroup/net_cls,net_prio cgroup > rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 > cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0 > cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 > cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 > cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 > cgroup /sys/fs/cgroup/cpu,cpuacct cgroup > rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 > cgroup /sys/fs/cgroup/perf_event cgroup > rw,nosuid,nodev,noexec,relatime,perf_event 0 0 > mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0 > /dev/sdb /etc/resolv.conf ext4 rw,noatime,nodiratime,commit=300,data=ordered > 0 0 > /dev/sdb /etc/hostname ext4 rw,noatime,nodiratime,commit=300,data=ordered 0 0 > /dev/sdb /etc/hosts ext4 rw,noatime,nodiratime,commit=300,data=ordered 0 0 > shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0 > devpts /dev/console devpts > rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0 > devpts /var/cache/pbuilder/build/489/dev/ptmx devpts > rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0 > proc /proc proc rw,relatime 0 0 > > > debootstrap.log contains the following message regarding the proc mount > > mount: /proc: mount(2) system call failed: Too many levels of symbolic links. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images
On Wed, Apr 03, 2019 at 06:45:28AM -0400, Chris Lamb wrote: > My conception is that as we call diffoscope on the two .changes files > it will report they are reproducible as, well, the binary package will > (likely…) be identical. Yup. It would. > > The tricky part is that that "tarball" we have been talking about is not > > saved anywhere. > > Nod, I guess we would want that for true jenkins.debian.org "please > save the build artifacts" support but for now getting a red/green > light would be interesting in/of itself. I think it would work out of the box already. Now, regarding building d-i as a normal package, I hit a bit of a readblock because it fails while trying to download the files in the nodes running in the future. What d-i does it copying the url from the host's (or, well, the chroot's) /etc/apt/sources.list, but it seems it doesn't also pick up an eventual [check-valid-until=no] placed on the same line :\ -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images
On Wed, Apr 03, 2019 at 06:21:39AM -0400, Chris Lamb wrote: > Whilst it may build indeed these files they do not appear in the > binary package: > Thus, they cannot affect the reproducibility status of the debian- > installer source package. This prompted my paragraph regarding at > least including these files' hashes, etc. Yes they do! The tricky part is that that "tarball" we have been talking about is not saved anywhere. Once it is uploaded to ftp-master it's unpacked and then discarded, so you can't quite get your hands on it without doing a local build of debian-installer. Furthermore now d-i as released wouldn't build anyway because it tries to look up linux 4.19.0-1 instead of 4.19.0-4... And after changing that it tries to look for the non-existent hyperv-modules-4.19.0-4-amd64-di, and here I don't want to go digging in d-i… :( - so I can't show you that tarball I'm talking about right now... -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images
On Wed, Apr 03, 2019 at 05:50:26AM -0400, Chris Lamb wrote: > Hey Cyril & Samuel, > > > > It doesn't build the netinst/CD/DVD iso images indeed (debian-cd handles > > > that). But it builds the initrd used there (and the netboot mini.iso). > > > > Right. Check the tarball (!) produced by building src:debian-installer; > > that's what gets installed in installer-$arch directories in the > > archive; then consumed by debian-cd to produce “full-blown” installation > > images. > > TIL. However, as these generated files do not appear in the binary > debian-installer package it is likely that that our testing framework > will (after the mooted networking exception is made) entirely- > correctly report that the src:debian-installer package is reproducible > as its declared artifects contain only documentation. This will be > somewhat misleading about the true reproducibility status of our installer. It doesn't contain only documentation. src:debian-installer also builds a debian-installer-images_$(VERSION)_$(ARCH).tar.gz that does contain binary stuff, including the initrd, kernel image, mini.iso, etc etc. > However, as this would not incorporate anything that debian-cd does > with them to produce the "full-blown" images I suspect that this will > not be enough to cover everything. Just to underline this point in a > silly way we would not be aware of, for example, debian-cd running > "echo $RANDOM >> /target/ somefile.txt", even with the above hack. Right, to cover this we would need to do a full build of the cd image. I have no idea whatsoever how that's done (and, as others said, it's outside of the debian-boot office, it's within debian-cd). In the meantime I did what I mentioned, https://salsa.debian.org/qa/jenkins.debian.net/commit/e3117ca244b230c04e324814e20c02032026a5cf and the build for unstable/arm64 is running. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#926242: jenkins.debian.org: Please test reproducibility status of Debian Installer images
user jenkins.debian@packages.debian.org usertags 926242 reproducible thanks On Tue, Apr 02, 2019 at 09:30:58AM -0400, Chris Lamb wrote: > However, it would be great if we had some continuous testing of this, > with the usual bells-and-whistles of running/publishing diffoscope > reports, etc. > > Due to the d-i testing release cycle it would be great to find any > regressions so they can get merged in time for whatever the next > alpha/beta is particularly as we (completely correctly!) get more > conservative with any changes respect to the upcoming release of > "buster." Does the installer need anything special? I thought d-i was just like any other package when it came to regular building it. > Whilst I think of it, there is also the separate issue of ensuring we > generate a .buildinfo (or .buildinfo-like) build attestation document so > that others can reproduce the build at a later date and further ensure > this is published or otherwise available somewhere for official > releases… but I was hoping it would become more obvious what we needed > (without guessing) once we have testing. If d-i is like I assume it be, there should a regular buildinfo as well, see https://buildinfo.debian.net/sources/debian-installer for what I mean. > Mattia, is this something you could proof-of-concept…? So the reason src:debian-installer does not build at this moment, it's because it *is* a bit of a snowflake as it wants to access a debian archive while it builds. Currently pbuilder doesn't have a "whistlist" method to block all networking but to a particular site, which is what would be needed to solve this nicely. One way to workaround this problem of src:debian-installer, would be for our building script to instruct pbuilder to not block the network when it's building this special package. I think that's acceptable, given that d-i is not a random package... :) Am I missing some other detail? -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: debootstrap_1.0.67+deb8u1_amd64.changes ACCEPTED into oldstable-proposed-updates->oldstable-new
On Thu, Aug 17, 2017 at 01:36:30AM +0200, Cyril Brulebois wrote:
> I can't find a git tag for this, please push it?
Oh, right!
Actually, I also forgot to commit the stuff, not just the last tag, but
I had everything locally :)
Thank you for the reminder!
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: Bug#864986: jessie-pu: package debootstrap/1.0.67+deb8u1
On Tue, Jun 27, 2017 at 06:21:40AM +0200, Cyril Brulebois wrote:
> Feel free to go head.
Alright, uploaded and now accepted in oldstable-new.
Thanks.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Bug#864986: jessie-pu: package debootstrap/1.0.67+deb8u1
Package: release.debian.org
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-boot@lists.debian.org
I'd like to be able to bootstrap buster with a jessie's debootstrap.
A similar update also happend in wheezy to support stretch, soon after
the wheezy release.
Attached a source debdiff (very unhelpful as it doesn't seem to
understand the symlinks?), whilst this is the binary debdiff of
debootstrap.deb:
% debdiff debootstrap_1.0.67_all.deb debootstrap_1.0.67+deb8u1_all.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-
lrwxrwxrwx root/root /usr/share/debootstrap/scripts/bullseye -> sid
lrwxrwxrwx root/root /usr/share/debootstrap/scripts/buster -> sid
Control files: lines which differ (wdiff format)
Installed-Size: [-229-] {+187+}
Version: [-1.0.67-] {+1.0.67+deb8u1+}
%
Changelog:
debootstrap (1.0.67+deb8u1) jessie; urgency=medium
* Add support for buster and bullseye.
-- Mattia Rizzolo Sun, 18 Jun 2017 13:48:43 +0200
Thank you in advance.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
diffstat for debootstrap-1.0.67 debootstrap-1.0.67+deb8u1
debian/changelog |6 +
scripts/bullseye | 204 +++
scripts/buster | 204 +++
3 files changed, 414 insertions(+)
diff -Nru debootstrap-1.0.67/debian/changelog debootstrap-1.0.67+deb8u1/debian/changelog
--- debootstrap-1.0.67/debian/changelog 2015-01-14 07:03:21.0 +0100
+++ debootstrap-1.0.67+deb8u1/debian/changelog 2017-06-18 13:48:43.0 +0200
@@ -1,3 +1,9 @@
+debootstrap (1.0.67+deb8u1) jessie; urgency=medium
+
+ * Add support for buster and bullseye.
+
+ -- Mattia Rizzolo Sun, 18 Jun 2017 13:48:43 +0200
+
debootstrap (1.0.67) unstable; urgency=medium
[ Cyril Brulebois ]
diff -Nru debootstrap-1.0.67/scripts/bullseye debootstrap-1.0.67+deb8u1/scripts/bullseye
--- debootstrap-1.0.67/scripts/bullseye 1970-01-01 01:00:00.0 +0100
+++ debootstrap-1.0.67+deb8u1/scripts/bullseye 2017-06-18 13:47:55.0 +0200
@@ -0,0 +1,204 @@
+mirror_style release
+download_style apt
+finddebs_style from-indices
+variants - buildd fakechroot minbase scratchbox
+keyring /usr/share/keyrings/debian-archive-keyring.gpg
+
+if doing_variant fakechroot; then
+ test "$FAKECHROOT" = "true" || error 1 FAKECHROOTREQ "This variant requires fakechroot environment to be started"
+fi
+
+case $ARCH in
+ alpha|ia64) LIBC="libc6.1" ;;
+ kfreebsd-*) LIBC="libc0.1" ;;
+ hurd-*) LIBC="libc0.3" ;;
+ *) LIBC="libc6" ;;
+esac
+
+work_out_debs () {
+ required="$(get_debs Priority: required)"
+
+ 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
+
+ if doing_variant fakechroot; then
+ # ldd.fake needs binutils
+ required="$required binutils"
+ fi
+
+ case $MIRRORS in
+ https://*)
+ base="$base apt-transport-https ca-certificates"
+ ;;
+ esac
+}
+
+first_stage_install () {
+ extract $required
+
+ mkdir -p "$TARGET/var/lib/dpkg"
+ : >"$TARGET/var/lib/dpkg/status"
+ : >"$TARGET/var/lib/dpkg/available"
+
+ setup_etc
+ if [ ! -e "$TARGET/etc/fstab" ]; then
+ echo '# UNCONFIGURED FSTAB FOR BASE SYSTEM' > "$TARGET/etc/fstab"
+ chown 0:0 "$TARGET/etc/fstab"; chmod 644 "$TARGET/etc/fstab"
+ fi
+
+ x_feign_install () {
+ local pkg="$1"
+ local deb="$(debfor $pkg)"
+ local ver="$(extract_deb_field "$TARGET/$deb" Version)"
+
+ mkdir -p "$TARGET/var/lib/dpkg/info"
+
+ echo \
+"Package: $pkg
+Version: $ver
+Maintainer: unknown
+Status: install ok installed" >> "$TARGET/var/lib/dpkg/status"
+
+ touch "$TARGET/var/lib/dpkg/info/${pkg}.list"
+ }
+
+ x_feign_install dpkg
+}
+
+second_stage_install () {
+ setup_devices
+
+ x_core_install () {
+ smallyes '' | in_target dpkg --force-depends --install $(debfor "$@")
+ }
+
+ p () {
+ baseprog="$
Re: Bug#817236: schroot: no access to pseudo-terminals in new chroots
reassign 817236 debootstrap 1.0.85 reassign 841935 debootstrap forcemerge 817236 841935 affects 817236 pbuilder sbuild schroot stop On Sun, Nov 20, 2016 at 08:03:25AM +0100, Cyril Brulebois wrote: > Ben Hutchings (2016-11-07): > > On Wed, 09 Mar 2016 10:02:14 +0100 Ansgar Burchardt > > > debootstrap recently replaced the /dev/ptmx device node with a symlink > > > /dev/ptmx -> pts/ptmx[1]. This changed the default permissions from > > > world-writable (0666) for /dev/ptmx to no-access () in chroots[2]. > > > > This is not needed at all from Linux 4.7. The open operation on > > /dev/ptmx automatically looks up the sibling pts/ directory. (Also, > > every mount of devpts is a 'new instance'.) > > > > It seems to me that the change in debootstrap ought to be reverted, as > > it will not be needed in future and it is causing problems for existing > > configurations. > > Adding Marco to the loop. In the meantime, properly reassigning/merging these bugs. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#835062: debain-installer: Preseeding of ESSID is impossible, apparently
Control: reassign -1 debian-installer On Mon, Aug 22, 2016 at 12:04:50AM +0200, Łukasz Stelmach wrote: > Package: debain-installer typo :) > Severity: normal > > Dear Maintainer, > > This may be a bug in netcfg or debconf but because I encounter it during > installation I will file it here. > > I have tried preseeding the name of my WiFi network (ESSID) by providing > different combinations of values for netcfg/wireles_show_essids and > netcfg/wireles_essid. > > | case no. | w_s_e | w_e | > |--+-+-| > |0 | -unset- | -unset- | > |1 | my_net | -unset- | > |2 | -unset- | my_net | > |3 | manual | my_net | > > 0. The default case. I am presented with a list and able to choose > my_net on it. > > 1. I get the list of nets in the air with my_net highlighted. I still > need to press [Enter] to continue (BUG). > > 2. Looks like 0. > > 3. Looks like 1, except the "Manual" option is highlighted on the > list. (BUG) > > I expected that setting ESSID in preseed.cfg like > > d-i netcfg/wireless_essid string my_net > > would prevent presenting me a list of available networks and make the > installer connect to the one I had set. > > If I were to guess what is wrong I'd say netcfg_wireless_show_essids() > doesn't handle preseeding correctly like netcfg_get_interface() does. > > -- System Information: > Debian Release: 8.5 > APT prefers proposed-updates > APT policy: (500, 'proposed-updates'), (500, 'stable') > Architecture: i386 (i686) > > Kernel: Linux 3.16.0-4-586 > Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > -- > Było mi bardzo miło. --- Rurku. --- ... > >Łukasz<--- To dobrze, że mnie słuchasz. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#805321: [Reproducible-builds] Bug#805321: Bug#805321: debian-installer: builds unreproducible netboot images
On Sat, Nov 28, 2015 at 12:08:44AM +, Steven Chamberlain wrote: > > FWIW, I'm not exactly entirely convinced by the exporting of the > > SOURCE_DATE_EPOCH variable from debian/rules; all other variables have > > been passed without exporting so I'm wondering if we shouldn't adapt > > this to behave like other variables, reducing possible surprise for > > users. > > Just to explain that -- if it's defined in the environment, it requires > no special handling and doesn't need to be (re-)exported. I think this > is maybe the case now for dpkg-buildpackage in sid? it's not, dpkg hasn't merged that patch (tbh I'm not even sure we forwarded that). Though debhelper exports SOURCE_DATE_EPOCH when using the dh sequencer. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#762732: fixed in 0.97
On Fri, 9 Jan 2015 15:56:36 +0100 Mattia Rizzolo wrote: > Looks like you forgot to close this bug in the changelog well, sorry for the noise... I was hit by my cache. didn't realize I had already closed it until I saw the double email :) -- 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/cahkymeuyuvb2sdi4bf7ybguuexu1j1t7b1nsz3jykidtsve...@mail.gmail.com
