Bug#1053751: d-i.debian.org: security repo being set up with HTTP even if HTTPS is selected

[Julien Cristau]

Control: reassign -1 apt-setup
Control: forcemerge 860467 -1

On Tue, Oct 10, 2023 at 14:11:19 +0300, Viktor Voloshko wrote:

> debian-installer has a choice between HTTP/HTTPS/FTP while setting up package 
> manager in expert install mode.
> 
> If HTTPS is chosen and security repository enabled it will be added to 
> /etc/apt/sources.list with http:// as it's protocol instead of https:// (may 
> be same with FTP too, I didn't have a chance to check it).
> 
> Every other mirror was added with https:// as expected. This includes 
> bookworm, bookworm-updates and bookworm-backports.
> 
> This can be easily fixed later in installed system by editing 
> /etc/apt/sources.list without any consequences.
> 
> Thank you for attention.
> 
Hi,

As far as I can tell this was already reported in bug #860467.

Cheers,
Julien

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

[Julien Cristau]

On Thu, Sep 28, 2023 at 12:42:27PM +0200, Santiago Vila wrote:
> El 28/9/23 a las 11:50, Julien Cristau escribió:
> > I still think that is absolutely the wrong thing to do, and makes
> > debootstrap more fragile for no good reason.
> 
> Julien, I believe you are mixing two different things here.
> 
> (A) What this bug is really about.
> 
> (B) What the effect of the bug is.
> 
> The bug (A) is that debootstrap, being the tool used to create chroots
> to build packages, has the responsibility of ensuring that
> the chroot is composed by build-essential packages only, and it
> should try hard not to install packages which are not build-essential.
> 
I guess more than mixing two different things I disagree that that is
debootstrap's responsibility, and so I disagree that that is a valid
bug.  In my view it's more important for debootstrap to reliably be able
to create chroots than some sort of philosophical purity about what is
included in said chroot.  Package priorities are how the archive tells
debootstrap which packages to install, and so since I don't see your (A)
as a bug, I'm saying if there's a bug it's (B) and belongs with the
archive.

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

> In other words, the bug says that the algorithm followed by debootstrap
> to determine which packages should be installed is *flawed*.
> 
> Then there is the effect of the bug (B). The effect, obviously,
> is that we end up having non-build-essential packages in a chroot
> when using the buildd profile, which is definitely not ok.
> 
> Why do you suggest that we fix only the effects of the bug but not
> the bug itself? In other words: Why are you apparently mixing (A) and (B)
> as if they were the same thing?
> 
> True, the ftpmasters might change priorities so that debootstrap
> does the right thing by default, but this would be "by pure chance",
> as the algorithm would still be wrong.
> 

> Even if they change the priorities today, it would suffice that
> some day another essential package becomes non-essential but still required,
> and then we would have to wait another seven years for debootstrap
> to do the right thing again.
> 
There's no reason that would need to take seven years, so I don't know
what that point is about.

Cheers,
Julien

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

[Julien Cristau]

Hi,

I still think that is absolutely the wrong thing to do, and makes
debootstrap more fragile for no good reason.  If you think a particular
package shouldn't be priority:required then file a bug against
ftp.debian.org to change it.

Cheers,
Julien

On Sat, Sep 23, 2023 at 20:13:45 +0200, Johannes Schauer Marin Rodrigues wrote:

> Hi all,
> 
> On Sun, 25 Jun 2017 06:01:13 +0200 Johannes Schauer  wrote:
> > Quoting Cyril Brulebois (2017-06-24 20:23:25)
> > > Julien Cristau  (2016-09-12):
> > > > This is a transient situation because some Essential packages'
> > > > dependencies changed.  I'd consider this a bug in the archive, not in
> > > > debootstrap.
> > > Any reasons to keep this bug report open then? Seen no objections, so I'm
> > > tempted to close it.
> > 
> > But... the buildd variant still explicitly (and not only implicitly through
> > dependencies of essential:yes packages) installs Priority:required packages,
> > no?
> 
> as we are at the beginning of the trixie development cycle, I have opened a
> merge request against debootstrap which avoids installing priority:required
> packages with the buildd variant:
> 
> https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/106#note_430035
> 
> I've put Ansgar and Julien in CC as they were opposed to this change.
> 
> I'm putting Luca and Guillem in CC who wrote in favour of this change also in
> policy bug #1029831.
> 
> Santiago is in CC as the driver of the mass bug filing for source packages 
> that
> fail to build in a chroot environment with just Essential:yes and
> build-essential installed.
> 
> According to the last MBF from December 2022 and January 2023, there are 13
> source packages that would FTBFS after this change because they are missing an
> explicit build dependency on tzdata or mount.
> 
> As part of the thread starting at
> 9b40f6f2-4942-acfc-2f9c-4668f05d9...@debian.org a number of arguments were 
> made
> for and against this change. I still believe that the arguments for this 
> change
> weigh stronger than those against it and thus I filed that merge request 
> above.
> 
> Luca, as the debootstrap maintainer, what are your thoughts?
> 
> Thank you!
> 
> cheers, josch

Re: Firmware GR result - what happens next?

[Julien Cristau]

On Thu, Oct 13, 2022 at 05:17:59PM +0200, Tobias Frost wrote:
> On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote:
> > On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
> > > Maybe and idea would to do something like isa-support does for e.g 
> > > sseX-support
> > > on CPUs that does not have that feature: It fails on installation with an 
> > > debconf message, IIRC.
> > > So that would allow something like "new package" | 
> > > "you-need-to-enable-nonfree-firmware-reminder-package"
> > > 
> > Failing on installation is a terrible user experience, let's not, pretty
> > please.
> 
> I'd prefer failing loudly to failing silently.
>  
I'd prefer if we could make things work vs making things fail, however loudly.

Cheers,
Julien

Re: Firmware GR result - what happens next?

[Julien Cristau]

On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
> Maybe and idea would to do something like isa-support does for e.g 
> sseX-support
> on CPUs that does not have that feature: It fails on installation with an 
> debconf message, IIRC.
> So that would allow something like "new package" | 
> "you-need-to-enable-nonfree-firmware-reminder-package"
> 
Failing on installation is a terrible user experience, let's not, pretty
please.

Cheers,
Julien

Re: Firmware GR result - what happens next?

[Julien Cristau]

On Thu, Oct  6, 2022 at 15:45:25 +0100, Steve McIntyre wrote:

> On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote:
> >On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> >> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
> >> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> >> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> >> >> > What's the plan for upgraded systems with an existing 
> >> >> > /etc/apt/sources.list.
> >> >> > Will the new n-f-f section added on upgrades automatically(if 
> >> >> > non-free was
> >> >> > enabled before)?
> >> >> 
> >> >> 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.
> >> >
> >> >Is there a reason to not continue to make the packages available in 
> >> >non-free?
> >> >I don't see a reason to force any change on existing systems.
> >> 
> >> Two things:
> >> 
> >>  1. I'm worried what bugs we might expose by having packages be in two
> >> components at once.
> >>  2. I really don't like the idea of leaving two different
> >> configurations in the wild; it'll confuse people and is more
> >> likely to cause issues in the future IMHO.
> >> 
> >> Plus, as Shengjing Zhu points out: we already expect people to manage
> >> the sources.list anyway on upgrades.
> >> 
> >I think in the absence of a release upgrade script (which I very much
> >doubt will happen, and be tested, and we can rely will be used, for
> >bookworm), Michael's suggestion seems like a reasonable way forward.  I
> >imagine we'll need to patch dak to allow that, but it seems like it
> >should be tractable?
> 
> I'm also worried what effect this will have on other tools that have
> to grok the archive (mirror tools, debian-cd, etc.). I'm not going to
> try and veto having things in more than one component, but (ugh!) I
> really think it's ugly. Actually, I think I'd much prefer Santiago's
> idea:
> 
> > Couldn't we handle this via transitional firware* non-free packages,
> > that depend on bookworm non-free-firmware packages?
> 
> We'd need to add some transitional binary packages for the small
> number of n-f-f source packages. That way people would get errors from
> apt if they don't read our warnings and update. Maybe this is a way
> forward?
> 
I don't think that will work well, the packages will likely just be held
at the old version if the new ones are uninstallable because the new
component isn't enabled.

Cheers,
Julien

Re: Firmware GR result - what happens next?

[Julien Cristau]

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> >> > What's the plan for upgraded systems with an existing 
> >> > /etc/apt/sources.list.
> >> > Will the new n-f-f section added on upgrades automatically(if non-free 
> >> > was
> >> > enabled before)?
> >> 
> >> 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.
> >
> >Is there a reason to not continue to make the packages available in non-free?
> >I don't see a reason to force any change on existing systems.
> 
> Two things:
> 
>  1. I'm worried what bugs we might expose by having packages be in two
> components at once.
>  2. I really don't like the idea of leaving two different
> configurations in the wild; it'll confuse people and is more
> likely to cause issues in the future IMHO.
> 
> Plus, as Shengjing Zhu points out: we already expect people to manage
> the sources.list anyway on upgrades.
> 
I think in the absence of a release upgrade script (which I very much
doubt will happen, and be tested, and we can rely will be used, for
bookworm), Michael's suggestion seems like a reasonable way forward.  I
imagine we'll need to patch dak to allow that, but it seems like it
should be tractable?

Cheers,
Julien

Bug#1015887: debian-installer: Adding https repo doesn't work without manually installing ca-certificates

[Julien Cristau]

On Sat, Jul 23, 2022 at 03:49:55PM +1200, Richard Hector wrote:
> Package: debian-installer
> Severity: important
> 
> Dear Maintainer,
> 
> Using netinst bullseye 11.4 installer:
> 
> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.4.0-amd64-netinst.iso
> 
> I chose to add a network mirror, using https, and the default
> 'deb.debian.org'.
> 
> I used (non-graphical) Expert Mode.
> 
> The problem first showed up when tasksel only displayed 'standard system
> utilities'. When I went ahead with that, the next screen was a red
> 'Installation step failed' screen.
> 
> The log on tty4 showed various dependency problems.
> 
> I tried to 'chroot /target' and 'apt update', which showed certificate
> problems. I then ran 'apt install ca-certificates', which worked
> (installing from the cd image?), after which 'apt update' worked, and I
> was also able to continue successfully with the installer.
> 
> I was able to reproduce this in a (kvm/qemu) VM (which is where I
> confirmed my steps); the original problem was on an HP Thin Client
> (t520). In both cases only 8G of storage was available.
> 
> It all works fine using http for the mirror.
> 
> I'm happy to do further testing with the VM; the thin client is less
> convenient as it has a job to do.
> 
Please attach syslog from the installer.

Cheers,
Julien

Re: debian-installer FTBFS after openssl transition

[Julien Cristau]

On Tue, May 24, 2022 at 09:30:46AM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I have observed debian-installer on some architectures such m68k, powerpc and 
> sparc64
> after the openssl transition. The issue does not affect all architectures, 
> ia64, hppa
> and ppc64 are not affected, for example.
> 
> The failure looks like this:
> 
> Building dependency tree... Done
>   libcrypto3-udeb:powerpc Depends on libatomic1:powerpc < none @un H > can't 
> be satisfied!
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  libcrypto3-udeb : Depends: libatomic1 but it is not installable
> E: Unable to correct problems, you have held broken packages.
> 
> Anyone have any suggestion what could be the problem? Since another version 
> of the openssl
> package was just uploaded, I don't think we need another binNMU here.

Presumably libatomic needs to start building a udeb and openssl needs to
be rebuilt against that.

Cheers,
Julien

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

[Julien Cristau]

On Mon, Nov 15, 2021 at 01:54:36PM +, Dimitri John Ledkov wrote:
> > Also, build chroots must still be created without merged-usr for 
> > sid/bookworm, until something's been done to migrate user systems.
> 
> But Julien, you said that buildds run stable, meaning they are
> unaffected by this debootstrap change in sid/bookworm.
> 
This isn't just about buildds, it's about everything that builds Debian
packages.  (And even if it was just about buildds, we should still do
things in the right order.)

Cheers,
Julien

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

[Julien Cristau]

Control: severity -1 grave

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

Cheers,
Julien

Bug#982194: choose-mirror: Rename mirror.netcologne.de to debian.netcologne.de

[Julien Cristau]

Control: reassign -1 mirrors
Control: tag -1 moreinfo

On Sun, Feb 07, 2021 at 11:40:32AM +0100, Roland Rosenfeld wrote:
> I noticed the following change in Git commit d51997a5:
> 
> -Site: debian.netcologne.de
> +Site: mirror.netcologne.de
> +Alias: debian.netcologne.de
> 
> This wasn't a very good idea, since I'd like to train users to use
> debian.netcologne.de as their mirror name.  So I can change the CNAME
> debian.netcologne.de pointing somewhere else (for example to
> mirror3.netcologne.de or ftp.de.debian.org) on maintenance or
> emergency.
> 
> This said, mirror.netcologne.de shouldn't be used directly as a debian
> mirror.
> 
> It would be great if you could undo the above change at least for
> bullseye.
> 
That would need a change on the site, for monitoring we require the
mirror name to match its trace file, and currently that is
http://mirror.netcologne.de/debian/project/trace/mirror.netcologne.de

If you update MIRRORNAME in ftpsync.conf and let us know we can update
the mirror list to match.

Cheers,
Julien

Re: choose-mirror upload

[Julien Cristau]

On Fri, Apr 02, 2021 at 12:47:40PM +0200, Holger Wansing wrote:
> Hi Julien,
> 
> would it be ok to upload choose-mirror with the attached diff?
> There is a translation update pending, and I wonder if I should include a
> "make Mirrors.masterlist" ?
> 
Yes I think that should be fine.  I'll try to do another pass through
the mirror issues in the next weeks and make another upload then, but
an update in the mean time can't hurt (and helps if I don't actually get
to it).  Thanks!

Julien

Re: 10.9 planning

[Julien Cristau]

On Fri, Mar 19, 2021 at 04:14:31PM +, Steve McIntyre wrote:
> In fact, how about: we *could* go ahead with the 10.9 point release as
> already planned, and expect to do a 10.10 a couple of weeks later with
> basically *just* the shim/SB changes? I'm OK to go with that option if
> that's our preferred route as a group.
> 
Is there actually a rush to get 10.10 out?  Are people eager to push out
revocations?  Or can we do it on our normal cadence, some time in May or
thereabouts, without adverse consequences?

Thanks,
Julien

Bug#700633: Why this eatmydata patch still not applied to debootstrap? My USB storage devices are slow

[Julien Cristau]

Control: tag -1 wishlist

On Fri, Jan 29, 2021 at 03:16:51PM +0300, Askar Safin wrote:
> severity -1 normal
> thanks
> 
> Hi.
> 
> Why this bug ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700633 ) 
> still is not fixed?
> 
> I did some experiments and here are results: if I run debootstrap stage of 
> d-i under eatmydata, then its time decreases from 755 s to 370 - 405 s. (I 
> installed Debian 
> to USB storage device).
> 
> Please, fix this bug. Fix is simple, benefits for many users are big. (So I 
> change severity.)
> 
> I think eatmydata mode should be enabled by default in debootstrap. Both 
> inside of d-i and outside of it.
> 
Please drop the hyperboles and don't abuse the bts.

Cheers,
Julien

Bug#981196: override: ca-certificates:misc/standard

[Julien Cristau]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: debian-boot@lists.debian.org, jcris...@debian.org

See discussion starting at
https://lists.debian.org/debian-devel/2021/01/msg00305.html for the
rationale.

Thanks,
Julien

Re: RFC: raising ca-certificates package Priority to standard or important

[Julien Cristau]

Hi Antonio,

On Thu, Jan 21, 2021 at 02:47:25PM -0300, Antonio Terceiro wrote:
> On Thu, Jan 21, 2021 at 03:10:47PM +0100, Julien Cristau wrote:
> > And which of standard or important made most sense (AIUI, standard
> > means "installed by default in d-i" and important means "installed by
> > default in debootstrap").
> 
> wget is already Priority: standard and recommends ca-certificates, so it
> seems to me that making it standard would be a noop in practice for most
> of the systems installed by d-i.
> 
> On the other hand, all cases that I remember seeing a problem caused by
> missing ca-certificates was in systems not installed by d-i, such as
> containers, vm images, etc. Based on that, I would make it important.

Here's my thinking on this:
I would expect "standard" to get installed on "general purpose" VM
images, and "important" *not* to get installed on "minimal" container or
VM images.  Looking at the docker debian image build script just now[1],
it seems to pull in required packages + iproute2 and ping, so it has its
own selection that doesn't include "important" priority.  So changing
the severity, by itself, won't change anything unless we go all the way
to "required" which feels like it'd be going too far (but then I also
don't think apt should be "required").
If there are specific examples where you think "important" would help
I'd be interested; right now I'm sort of favouring "standard" as good
enough.

[1] 
https://github.com/debuerreotype/debuerreotype/blob/master/examples/debian.sh

Cheers,
Julien

RFC: raising ca-certificates package Priority to standard or important

[Julien Cristau]

[bcc: {openssl,ca-certificates}@packages.d.o]

Hi,

the ca-certificates package is currently "Priority: optional", like most
of the archive.  It's Recommended by a bunch of packages, Depended on by
an equivalent number, but I'm not sure if this is optimal.  I suspect
most packages can be configured to use a different trust store; and that
in many deployments you may want to use a private PKI, or limit trust to
a specific subset of the global public CAs, so in that sense `Depends'
on ca-certificates is not quite correct.  On the other hand it's less
likely to run into "user disabled Recommends, and run into unexpected TLS
server auth failures" kind of situations.

So I'd like to raise the priority of ca-certificates from optional to
at least standard, as a signal that it should be installed on
non-minimal Debian systems.  I'll note that ca-certificates depends on
the openssl binary package which would thus effectively also become
standard (or important, if we go that route), if it isn't already.

Before asking ftpmasters to make that change I wanted to ask this group
if there were downsides to it that I haven't considered.  And which of
standard or important made most sense (AIUI, standard means "installed
by default in d-i" and important means "installed by default in
debootstrap").

Thanks,
Julien

Re: Missing libgudev-1.0-0 udeb package?

[Julien Cristau]

On Thu, Dec 10, 2020 at 09:26:49PM +0800, Shawn Guo wrote:
> Hi,
> 
> I'm running a Sid graphical installer on my Lenovo Yoga C630 laptop
> (arm64).  For some reason, the cursor movement via touchpad doesn't
> work there.  It works in an installed Debian Sid system though.  One
> difference I suspect is that the installer runs Xorg evdev input
> driver, while Debian runs Xorg libinput driver.  So I'm trying to
> build xserver-xorg-input-libinput-udeb instead of
> xserver-xorg-input-evdev-udeb into the installer for testing.  But I'm
> getting the following dependency error.
> 
> Reading package lists... Done
> Building dependency tree... Done
>   libwacom2-udeb:arm64 Depends on libgudev-1.0-0:arm64 < none @un H >
> (>= 234) can't be satisfied!
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
>  libwacom2-udeb : Depends: libgudev-1.0-0 (>= 234) but it is not installable
> E: Unable to correct problems, you have held broken packages.
> 
> It seems that there is no libgudev-1.0-0 udeb at all, while it becomes
> a dependency of xserver-xorg-input-libinput-udeb like below.
> xserver-xorg-input-libinput-udeb
> libinput10-udeb
> libwacom2-udeb
> libgudev-1.0-0
> 
> Should we build libgudev-1.0-0 udeb to resolve this dependency problem?
> 
I guess one alternative would be to build libinput-udeb without libwacom
support?

Cheers,
Julien

Bug#968998: debian-installer: grub and shim are missing from built-using

[Julien Cristau]

On Tue, Aug 25, 2020 at 20:15:45 +0200, Philipp Kern wrote:

> On 25.08.20 18:18, Julien Cristau wrote:
> > Package: debian-installer
> > Version: 20150324
> > Severity: important
> > X-Debbugs-Cc: jcris...@debian.org
> > 
> > d-i EFI images include a copy of grub (and shim, on architectures with
> > secure boot).  Those should be listed in Built-Using so we don't end up
> > without the corresponding source in the archive.
> 
> grub2 for sure as it's GPL-3, but is it actually required for shim,
> which is BSD?
> 
Fair.  I've removed shim-signed from the list of packages considered by
the write-built-using script.

Cheers,
Julien

Bug#968998: debian-installer: grub and shim are missing from built-using

[Julien Cristau]

Package: debian-installer
Version: 20150324
Severity: important
X-Debbugs-Cc: jcris...@debian.org

d-i EFI images include a copy of grub (and shim, on architectures with
secure boot).  Those should be listed in Built-Using so we don't end up
without the corresponding source in the archive.

Cheers,
Julien

Re: Missing GnuPG signatures for checksums

[Julien Cristau]

On Mon, Apr 20, 2020 at 06:38:48PM +0200, Laurențiu Păncescu wrote:
> Hello,
> 
> I'm trying to put a preseed file on the same USB stick as the installation,
> using hd-media/boot.img.gz is easier than remastering the iso. It works, but
> there seems not to be any signed checksum file for these images and they are
> served only over http:
> 
> http://http.us.debian.org/debian/dists/buster/main/installer-amd64/current/images/
> 
> How can I check if these images are authentic? I guess I could mount a
> signed CD iso like netinst, copy vmlinuz and initrd from there and create my
> own USB stick with syslinux - is there a better way?
> 
Hi,

http://http.us.debian.org/debian/dists/buster/InRelease is signed and contains
checksums for the d-i SHA256SUMS file.  (I realize that still makes
verification awkward.)

Cheers,
Julien

Bug#951709: /boot should get a bigger share of disk in default installation

[Julien Cristau]

On Tue, Mar 10, 2020 at 09:50:07PM +0100, Holger Wansing wrote:
> Hi,
> 
> Ben Hutchings  wrote:
> > On Thu, 2020-02-20 at 18:50 +0530, Pirate Praveen wrote:
> > > Package: debian-installer
> > > Version: 20190702+deb10u3
> > > Severity: important
> > > 
> > > With initrd around 60+ MBs, 236 MB /boot in a 300 GB hard disk can hold 
> > > only 2 versions of the kernels at the same time. When installing a 3rd 
> > > kernel /boot gets filled up. I think it should be able to store at 
> > > least 3 kernels and ideally 4 or even more.
> > >
> > > The paritions were created automatically with just /home in a separate 
> > > partition with lvm by debian buster installer.
> > 
> > I agree; the default size of /boot is now too small.  I think we should
> > normally allocate at least 500 MB to it.
> 
> This has just been addressed; see
> https://salsa.debian.org/installer-team/partman-auto/-/commit/cf6b2d152b08b6c78da6a6f7ca26a99bdadfdfce
> 
Not quite.  If Ben says we need at least 500M, then we'll have to
adjust further, as that commit uses 512M as a maximum.  For comparison
Ubuntu's partman-auto sets the min at 512M and max at 768M.  Do people
feel that's where we should go?

Cheers,
Julien

Bug#949651: installation-reports: install on lenovo server fails guided partitioning

[Julien Cristau]

On Thu, Jan 23, 2020 at 12:48:57PM +, Steve McIntyre wrote:
> On Thu, Jan 23, 2020 at 01:33:15PM +0100, Julien Cristau wrote:
> >On Thu, Jan 23, 2020 at 12:04:22 +, Steve McIntyre wrote:
> >> 
> >> Hmmm, odd. Something is picking up on those M2 modules multiple times,
> >> it seems. You sure they're SATA?
> >> 
> >> $ grep /dev/nvme partman.log 
> >> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme0n1 /dev/nvme0n1
> >> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme1n1 /dev/nvme1n1
> >> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme2n1 /dev/nvme2n1
> >> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme3n1 /dev/nvme3n1
> >> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme4n1 /dev/nvme4n1
> >> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme5n1 /dev/nvme5n1
> >> Path: /dev/nvme0n1
> >> Path: /dev/nvme1n1
> >> Path: /dev/nvme2n1
> >> Path: /dev/nvme3n1
> >> Path: /dev/nvme4n1
> >> Path: /dev/nvme5n1
> >> 
> >> I don't know if that's the cause of the problem, but it looks suspect
> >> to me.
> >> 
> >No, these are separate (unused) devices.
> 
> Bah, OK. Red herring. :-(
> 
> Do you have the syslog as well as the partman log? I'm not seeing a
> lot of useful information from partman alone.
> 
Here it is:
https://people.debian.org/~jcristau/conova-node04-install-syslog

Looks even less useful to me, but hopefully I missed something.

Cheers,
Julien

Bug#949651: installation-reports: install on lenovo server fails guided partitioning

[Julien Cristau]

Hi Steve,

On Thu, Jan 23, 2020 at 12:04:22 +, Steve McIntyre wrote:

> Hey Julien!
> 
> On Thu, Jan 23, 2020 at 09:18:54AM +0100, Julien Cristau wrote:
> >Package: installation-reports
> >Severity: normal
> >
> >Boot method: CD
> >Image version: 
> >https://get.debian.org/cdimage/unofficial/non-free/cd-including-firmware/10.2.0+nonfree/amd64/iso-cd/firmware-10.2.0-amd64-netinst.iso
> >Date: January 22, 2020
> 
> ...
> 
> >Comments/Problems:
> >
> >I couldn't get guided partitioning to work.  It would fail every time
> >complaining that the drive was probably too small or something like
> >that (I didn't save the exact message).  This is a brand new machine,
> >sda is hw raid1 on 2x128G M.2 SATA modules.  (Same thing happened on
> >another identical system so this is apparently reproducible.)
> 
> Hmmm, odd. Something is picking up on those M2 modules multiple times,
> it seems. You sure they're SATA?
> 
> $ grep /dev/nvme partman.log 
> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme0n1 /dev/nvme0n1
> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme1n1 /dev/nvme1n1
> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme2n1 /dev/nvme2n1
> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme3n1 /dev/nvme3n1
> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme4n1 /dev/nvme4n1
> /lib/partman/init.d/30parted: IN: OPEN =dev=nvme5n1 /dev/nvme5n1
> Path: /dev/nvme0n1
> Path: /dev/nvme1n1
> Path: /dev/nvme2n1
> Path: /dev/nvme3n1
> Path: /dev/nvme4n1
> Path: /dev/nvme5n1
> 
> I don't know if that's the cause of the problem, but it looks suspect
> to me.
> 
No, these are separate (unused) devices.

Cheers,
Julien

Re: Planning 10.3 and 9.12

[Julien Cristau]

On Mon, Jan 06, 2020 at 09:42:29PM +, Adam D. Barratt wrote:
> Hi,
> 
> It's (really past) time to consider a date for the next point releases
> for buster and stretch.
> 
> I've listed some suggested dates below; please indicate which you would
> be available for.
> 
> - January 25th
> - February 1st
> - February 8th
> - February 15th
> 
The first 3 should work for me.  Feb 15 I'm not sure yet.

Cheers,
Julien

Re: Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Julien Cristau]

On Tue, Sep  3, 2019 at 10:32:11 +0200, Bjørn Mork wrote:

> But you can't really expect users to look at xserver-xorg-input-libinput
> at all.  Why should they?  There is no pointer to it from the "obsolete"
> package.  What kind of deprecation is that? Most users will probably
> read the first lines of the verbose xserver-xorg-input-synaptics
> description, see "enable advanced features of the Synaptics Touchpad",
> and think "YES! I want that!".
> 
Users shouldn't have to think about it.  It's our job to make our
install process do the right thing in the first place.

Cheers,
Julien

Bug#935589: cdimage.debian.org: xserver-xorg-input-synaptics package missing in xfce-CD-1 iso

[Julien Cristau]

On Mon, Sep  2, 2019 at 23:42:44 +0100, Steve McIntyre wrote:

> control: reassign -1 task-xfce-desktop
> 
> Hi Karthik,
> 
> On Sat, Aug 24, 2019 at 04:10:53PM +0530, karthik wrote:
> >Package: cdimage.debian.org
> >Severity: normal
> >
> >Dear Maintainer,
> >
> >*** Reporter, please consider answering these questions, where appropriate 
> >***
> >
> >   * What led up to the situation?
> > After a fresh install of xfce CD testing weekly iso on lenovo x230 
> > laptop, I have noticed that the touchpad options were missing in mouse & 
> > touchpad settings
> >   * What exactly did you do (or not do) that was effective (or
> > ineffective)?
> > installed xserver-xorg-input-synaptics package 
> >   * What was the outcome of this action?
> > touchpad options were visible back again!
> >   * What outcome did you expect instead?
> > same as above
> >
> >Please include this package in upcoming iso builds, It is an important one.
> 
> If it's important that it's available, then a better place for the bug
> would be against the task-xfce-desktop package. That way it will be
> pulled in automatically via dependencies for the CD build.
> 
The synaptics Xorg driver is obsolete and should not be installed by
default.

Cheers,
Julien

Bug#939266: debootstrap fails to create a sid chroot with Error executing gpgv to check Release signature

[Julien Cristau]

On Mon, Sep  2, 2019 at 21:27:46 +0500, Pirate Praveen wrote:

> How do I get this file? There is no such log in /var/log. There is no
> logfile option I can find in manpage.
> 
Look in /srv/chroot/debian-sid.

Cheers,
Julien

Bug#939266: debootstrap fails to create a sid chroot with Error executing gpgv to check Release signature

[Julien Cristau]

On Mon, Sep  2, 2019 at 21:13:13 +0500, Pirate Praveen wrote:

> 
> 
> On Mon, Sep 2, 2019 at 9:36 PM, Julien Cristau  wrote:
> > Control: tags -1 unreproducible moreinfo
> > 
> > On Mon, Sep  2, 2019 at 20:53:13 +0500, Pirate Praveen wrote:
> > 
> > >  Package: debootstrap
> > >  Version: 1.0.114, 1.0.115~bpo10+1
> > >  Severity: important
> > > 
> > >  I think debootstrap should be able to create a sid chroot but fails
> > > with
> > >  this error,
> > > 
> > >  $ sudo debootstrap sid /srv/chroot/debian-sid
> > >  I: Target architecture can be executed
> > >  I: Retrieving Release.gpg
> > >  I: Checking Release signature
> > >  E: Error executing gpgv to check Release signature
> > > 
> > Works for me.  Care to give more verbose info?
> > 
> 
> Even with --verbose there is no extra information, is there another way to
> get more information.
> 
Providing debootstrap.log maybe?

Cheers,
Julien

Bug#939266: debootstrap fails to create a sid chroot with Error executing gpgv to check Release signature

[Julien Cristau]

Control: tags -1 unreproducible moreinfo

On Mon, Sep  2, 2019 at 20:53:13 +0500, Pirate Praveen wrote:

> Package: debootstrap
> Version: 1.0.114, 1.0.115~bpo10+1
> Severity: important
> 
> I think debootstrap should be able to create a sid chroot but fails with
> this error,
> 
> $ sudo debootstrap sid /srv/chroot/debian-sid
> I: Target architecture can be executed
> I: Retrieving Release.gpg
> I: Checking Release signature
> E: Error executing gpgv to check Release signature
> 
Works for me.  Care to give more verbose info?

Cheers,
Julien

Bug#926036: net-retriever: missing support for Acquire-By-Hash

[Julien Cristau]

Package: net-retriever
Version: 1.51
Severity: minor
Tags: patch

olasd tried to install his new laptop.  He got hashsum mismatches.  That
made him sad.  We don't want a sad olasd.

Patch up at
https://salsa.debian.org/jcristau/net-retriever/commit/2653045287c502399c31495e1dfd502e03efbc08

Cheers,
Julien

Bug#926035: net-retriever: missing support for InRelease

[Julien Cristau]

Package: net-retriever
Version: 1.51
Severity: minor
Tags: patch

Hi,

net-retriever downloads Release and Release.gpg instead of trying InRelease 
first.

Patch up at 
https://salsa.debian.org/jcristau/net-retriever/commit/1237e465cc83a0832c365f8b9f67f98943229dd6

Cheers,
Julien

Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us

[Julien Cristau]

On Sun, Mar  3, 2019 at 23:35:45 +, Steve McIntyre wrote:

> So, we're looking at three hacky options options here to work our way
> out of this hole. In (probably?) descending order of hackitude:
> 
> 1. Ask the nice ftpmaster people to bodge the archive by hand:
[...]
> 
> OR
> 
> 2. Upload new bodged versions of shim and shim-signed to get us
>back to working with the previously-signed shimx64.efi.signed
>binary
[...]
> 
> OR
> 
> 3. Upload new version of the shim-signed source package and a
>(lightly) bodged binary package
[...]
> 
> So, please - what do you think?
> 
FWIW I also don't think 1 is reasonable, but whichever of 2 or 3 the
people doing the work want to run with will be fine.

Cheers,
Julien

Re: Scheduling 9.8 (was: Re: Scheduling 9.7)

[Julien Cristau]

On 1/28/19 8:45 PM, Adam D. Barratt wrote:
> On Fri, 2019-01-18 at 18:44 +, Jonathan Wiltshire wrote:
>> 9.7 is a bit overdue already (current events being a bit of a time-
>> sink).
>>
>> Please indicate your availablility out of:
>>
>>  - (Feb 2 unlikely, FOSDEM)
>>  - Feb 9
>>  - Feb 16
> 
> As we had a short-notice 9.7, this is now planning for 9.8.
> 
> Either the 9th or 16th looks like it should work for me, with a
> preference for the latter.
> 
9th or 16th should be ok for me.

Cheers,
Julien

Bug#918722: debootstrap: says InRelease file expired

[Julien Cristau]

On 1/8/19 7:46 PM, Michael Büsch wrote:
> Package: debootstrap
> Version: 1.0.113
> Severity: normal
> 
> When bootstrapping Raspbian with debootstrap it fails since version 1.0.113:
> 
>   debootstrap --arch=armhf --foreign --verbose 
> --keyring=raspbian.public.key.gpg stretch /my/directory 
> http://mirrordirector.raspbian.org/raspbian/
> 
> The error message is
>   E: InRelease file 
> http://mirrordirector.raspbian.org/raspbian/dists/stretch/InRelease is 
> expired since (Tue, 08 Jan 2019 00:00:00 +0100)
> 
> Yesterday (on 07 Jan) the error message told me it was expired since 07 Jan.
> 
> The problem does not occur with version 1.0.112 of debootstrap.
> 
> I am not sure at all, if this is a problem within Raspbian or in debootstrap.
> 
Hideki,

I reverted the 1.0.113 changes to unbreak this and uploaded 1.0.114.
I'm happy to review an updated version when you get that working.  Hope
that's ok.

Cheers,
Julien

Re: Bug#906016: transition: gjs built with mozjs60

[Julien Cristau]

On 12/17/18 4:08 PM, John Paul Adrian Glaubitz wrote:
> On 12/17/18 3:56 PM, Simon McVittie wrote:
>> gjs recently switched from mozjs52 to mozjs60, and mozjs60 doesn't work
>> on s390x (#909536; about 80% of its tests fail, which means I have no
>> confidence that the resulting binaries would be useful or usable if
>> we ignored the test failures).
> 
> This sounds suspicious and more like a single bug that breaks mozjs60 on
> s390x, maybe similar to the issues we have on SPARC due to the tagged pointers
> conflicting with the extended virtual address on SPARC.
> 
> We might have a patch for s390x in openSUSE/SLE, I'll have a look. There
> also might be one in Fedora we could pick for Debian.
> 
https://bugzilla.mozilla.org/show_bug.cgi?id=1488552 is what I was
hitting last time around.  That got resolved as fixed a few days ago,
although it depends on a refactoring that's not in 60.  Still, might be
worth trying to run SpiderMonkey tests on trunk on 64bit BE and see if
and how much better it is now.

Cheers,
Julien

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

[Julien Cristau]

On 11/28/18 4:14 PM, Ian Jackson wrote:
> Julien Cristau writes ("Re: Bug#914897: debootstrap, buster: Please disabled 
> merged /usr by default"):
>> On 11/28/18 2:49 PM, Ian Jackson wrote:
>>> This is a special case of a general problem: buster systems with
>>> merged-/usr sometimes build packages which are broken on
> ...
>> I'd suggest that this should be fixed by not shipping any packages that
>> aren't built on buildds.
> 
> It would be quite a radical departure for Debian to no longer support
> "I built this package for my mate to install on their computer".
> 
It'll be just as "supported" as it is today (which is to say, basically
not at all).  Likely to work in many cases, but also likely to explode
in a million pieces depending on the build environment.  I'd just like
to stop inflicting this risk on people downloading debs from *.debian.org.

Cheers,
Julien

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

[Julien Cristau]

On 11/28/18 2:49 PM, Ian Jackson wrote:
> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -> /usr/bin etc.
> 
> It was discovered that when this change took effect on the Debian
> buildds, the buildds started to build packages which do not work on
> non-merged-/usr systems.
> 
> This is a special case of a general problem: buster systems with
> merged-/usr sometimes build packages which are broken on
> non-merged-/usr systems.
> 
> Some people have suggested that this should be fixed by making
> merged-/usr mandatory for buster.  However, there is no transition
> plan for this as yet and I don't think Debian is ready to commit to do
> that.
> 
I'd suggest that this should be fixed by not shipping any packages that
aren't built on buildds.

Cheers,
Julien

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

[Julien Cristau]

On 11/28/18 1:07 PM, Ian Jackson wrote:
> Package: debootstrap
> Version: debootstrap/1.0.110
> Severity: serious
> 
> Merged /usr is now the default in buster.  As discussed on
> debian-devel, however, binary packages built on a merged-usr system
> are not installable on a non-merged-usr system.  I think we would like
> ad hoc builds of packages from one buster machine to be installable on
> other buster machines.  That is not compatible with the current
> approach.
> 
> This was an unanticipated problem.  The discussion on -devel has not
> reached a consensus on a way forward, and there is no transition plan.
> 
> Accordingly, please revert this change for buster.
> 
We already have a change queued to revert it for build chroots.  I don't
believe anything more is warranted at this stage.

> IMO this revert should be done quickly, to minimise the number of
> installs which will generate broken packages.  If you do not agree
> with my proposal, then I still think we should revert the change in
> sid/buster while the matter is discussed.
> 
> This affects stretch-backports too, but I think it will be most
> convenient to file a separate bug for that.
> 
Definitely not.

Cheers,
Julien

Bug#910560: [choose-mirror] fails to build when parallel build is activated

[Julien Cristau]

There's a bug in choose-mirror. It's just not serious. 

Julien 

On October 8, 2018 12:38:40 PM GMT+02:00, Holger Wansing  
wrote:
>Hi,
>
>Philipp Kern  wrote:
>> On 2018-10-08 09:08, John Paul Adrian Glaubitz wrote:
>> > On 10/8/18 7:51 AM, Holger Wansing wrote:
>> >> Since version 2.92, choose-mirror fails to build with
>> >> "dpkg-buildpackage -j", the debian/iso_3166.tab file seems to be 
>> >> removed by
>> >> error:
>> >> 
>> >> (can also be seen at jenkins:
>> >>
>https://jenkins.debian.net/view/d-i_packages/job/d-i_build_choose-mirror/
>> >> where I found it initially)
>> > It builds fine here on my machine using sbuild and also fine on the
>
>> > buildds
>> > which are building with sbuild and "parallel=N" with N >= 2 [1].
>> > 
>> > You are building in an unclean build environment unless you are 
>> > building with
>> > something like sbuild and pbuilder, so your build results can have 
>> > unexpected
>> > results.
>> > 
>> > Please create a local sbuild setup and try again.
>> > 
>> > Adrian
>> > 
>> >> [1] 
>> >>
>https://buildd.debian.org/status/package.php?p=choose-mirror=unstable
>> 
>> dpkg-buildpackage -j is like the worst option to ever have been 
>> introduced and not removed. Try -J instead. :(
>
>Ok, so we have no package problem at all?
>
>Should that bug be reassigned to jenkins.debian.org then, to make
>jenkins
>happy on that topic, too?
>jenkins seems to not having parallel builds activated?
>Should probably use similar settings as the buildds, to give comparable
>results?
>
>
>Holger
>
>
>-- 
>Holger Wansing 
>PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#910560: [choose-mirror] fails to build when parallel build is activated

[Julien Cristau]

Control: severity -1 wishlist

On 10/08/2018 07:51 AM, Holger Wansing wrote:
> Package: choose-mirror
> Severity: serious
> Version: 2.92
> 
> Since version 2.92, choose-mirror fails to build with
> "dpkg-buildpackage -j", the debian/iso_3166.tab file seems to be removed by 
> error:
> 
> (can also be seen at jenkins:
> https://jenkins.debian.net/view/d-i_packages/job/d-i_build_choose-mirror/ 
> where I found it initially)
> 
> 
Reducing severity, dpkg-buildpackage -j is broken.

Cheers,
Julien

Bug#908804: [task-desktop] Move xserver-xorg-video-all to recommends

[Julien Cristau]

On 09/14/2018 09:03 AM, Alexander Kernozhitsky wrote:
> Package: task-desktop
> Version: 3.45
> Severity: wishlist
> 
> Now task-desktop depends on xserver-xorg-video-all, which forces to have all 
> the video drivers in the system, even if they appear unused. I suggest to 
> move 
> xserver-xorg-video-all into Recommends and depend on xorg-driver-video (to 
> force the system to have at least one video driver installed).
> 
I don't think this makes sense.  There's little cost to having unused
drivers around (hell, installing the kernel package gets you loads more
that you can't opt out of), and installing a single random driver is
typically not going to get you anything.

Cheers,
Julien

Bug#907704: choose-mirror: default to deb.debian.org

[Julien Cristau]

On Wed, Sep 12, 2018 at 21:57:41 +0200, Philipp Kern wrote:

> On 10.09.2018 09:20, Philipp Kern wrote:
> > [+mirrors@]
> > 
> > On 07.09.2018 14:42, Julien Cristau wrote:
> >> Control: retitle -1 choose-mirror: hide mirror selection by default
> >>
> >> On 09/04/2018 11:07 AM, Julien Cristau wrote:
> >>> If switching the mirror question from high to medium priority proves
> >>> controversial I guess I could separate that to its own bug too, to at
> >>> least get the default changed.
> >> Since there still seems to be some discussion around that, I'm going to
> >> use bug#797340 to make deb.debian.org the default, and repurpose this
> >> bug to stop asking the mirror country + hostname questions by default.
> > 
> > What's mirroradm's take on this?
> 
> For the record, this change just landed in unstable.
> 
"This change" being "select deb.d.o as the default mirror".  The
country and mirror questions are still "high" priority so shown by
default, for now.

Cheers,
Julien

Bug#907704: choose-mirror: default to deb.debian.org

[Julien Cristau]

Control: retitle -1 choose-mirror: hide mirror selection by default

On 09/04/2018 11:07 AM, Julien Cristau wrote:
> If switching the mirror question from high to medium priority proves
> controversial I guess I could separate that to its own bug too, to at
> least get the default changed.
> 
Since there still seems to be some discussion around that, I'm going to
use bug#797340 to make deb.debian.org the default, and repurpose this
bug to stop asking the mirror country + hostname questions by default.

Cheers,
Julien

Bug#907704: choose-mirror: default to deb.debian.org

[Julien Cristau]

On 09/03/2018 10:44 PM, Nicholas D Steeves wrote:
> Like Karsten, my experience with deb.debian.org has been inconsistent.
> With a 50 Mb/s ADSL line in Montréal, most of the top candidates
> mirrors from netselect will consistently deliver ~6200 kB/s, but
> deb.debian.org often connects to an AWS instance where the download
> proceeds no more than 350 KB/s...
> 
http://deb.debian.org/debian, which is being proposed here, does not
point at AWS.  Only the https endpoint currently does, and that's not
what I'm switching to in this bug.

To Philipp's point, there are multiple CDNs we could use in the
(unlikely) event the current one(s) went away.  However, I believe the
consensus within DSA is that we explicitly do not want to maintain more
frontends for the sake of it, we'd rather have a single one that works
well, from a sponsor we're confident won't go away without enough notice
to let us move the service without affecting users.

Issues with deb.debian.org can be reported against the "mirrors"
pseudo-package in the BTS, or to the dsa@ or mirrors@ aliases.

If switching the mirror question from high to medium priority proves
controversial I guess I could separate that to its own bug too, to at
least get the default changed.

Cheers,
Julien

Bug#907704: choose-mirror: default to deb.debian.org

[Julien Cristau]

Control: tag -1 + patch

On 08/31/2018 06:27 PM, Julien Cristau wrote:
> Package: choose-mirror
> Severity: wishlist
> X-Debbugs-Cc: tfh...@debian.org
> 
> I think it's time for choose-mirror to stop asking by default.  AFAIK
> deb.debian.org works well enough now that we don't need users to
> manually select a mirror close to them.
> 
> PoC patch, completely untested:
> 
Updated patch, at least somewhat tested.  It downgrades the debconf
priority for mirror/http/countries and mirror/http/mirrors so they're
not asked by default (previous patch would still ask for a country).
Only the "proxy" question remains; I'd kind of want to skip it by
default unless we find out we can't get at the mirror directly, but
that's something for another bug/patch.

Cheers,
Julien
>From 5773506afb888b03d03b570bda4492c293d0d2f9 Mon Sep 17 00:00:00 2001
From: Julien Cristau 
Date: Mon, 3 Sep 2018 15:34:39 +0200
Subject: [PATCH] Default http mirror to deb.debian.org (closes: #907704).

---
 choose-mirror.c| 6 --
 debian/changelog   | 6 ++
 debian/choose-mirror-bin.templates.http-in | 3 ++-
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/choose-mirror.c b/choose-mirror.c
index 2662c5f..f44c7ad 100644
--- a/choose-mirror.c
+++ b/choose-mirror.c
@@ -617,8 +617,10 @@ static int choose_country(void) {
 		debconf_set(debconf, countries, country);
 		debconf_fget(debconf, DEBCONF_BASE "country", "seen");
 		debconf_fset(debconf, countries, "seen", debconf->value);
+		debconf_input(debconf, "medium", countries);
+	} else {
+		debconf_input(debconf, "high", countries);
 	}
-	debconf_input(debconf, "high", countries);
 
 	free (countries);
 	return 0;
@@ -665,7 +667,7 @@ static int choose_mirror(void) {
 		debconf_subst(debconf, mir, "mirrors", list);
 		free(list);
 
-		debconf_input(debconf, "high", mir);
+		debconf_input(debconf, "medium", mir);
 		free(mir);
 	} else {
 		char *host = add_protocol("hostname");
diff --git a/debian/changelog b/debian/changelog
index 762d821..e7fbf12 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+choose-mirror (2.92) UNRELEASED; urgency=medium
+
+  * Default http mirror to deb.debian.org (closes: #907704).
+
+ -- Julien Cristau   Mon, 03 Sep 2018 15:33:14 +0200
+
 choose-mirror (2.91) unstable; urgency=medium
 
   * Update Vcs-{Browser,Git} to point to salsa (alioth's replacement).
diff --git a/debian/choose-mirror-bin.templates.http-in b/debian/choose-mirror-bin.templates.http-in
index 785851e..2dc1f02 100644
--- a/debian/choose-mirror-bin.templates.http-in
+++ b/debian/choose-mirror-bin.templates.http-in
@@ -29,13 +29,14 @@ _Description: Debian archive mirror country:
 Template: mirror/http/mirror
 Type: select
 Choices: ${mirrors}
+Default: deb.debian.org
 # :sl1:
 _Description: Debian archive mirror:
  Please select a Debian archive mirror. You should use a mirror in
  your country or region if you do not know which mirror has the best
  Internet connection to you.
  .
- Usually, ftp..debian.org is a good choice.
+ Usually, deb.debian.org is a good choice.
 
 Template: mirror/http/hostname
 Type: string
-- 
2.18.0

Bug#907704: choose-mirror: default to deb.debian.org

[Julien Cristau]

Package: choose-mirror
Severity: wishlist
X-Debbugs-Cc: tfh...@debian.org

I think it's time for choose-mirror to stop asking by default.  AFAIK
deb.debian.org works well enough now that we don't need users to
manually select a mirror close to them.

PoC patch, completely untested:

diff --git a/choose-mirror.c b/choose-mirror.c
index 2662c5f..5463fa7 100644
--- a/choose-mirror.c
+++ b/choose-mirror.c
@@ -665,7 +665,7 @@ static int choose_mirror(void) {
debconf_subst(debconf, mir, "mirrors", list);
free(list);

-   debconf_input(debconf, "high", mir);
+   debconf_input(debconf, "medium", mir);
free(mir);
} else {
char *host = add_protocol("hostname");
diff --git a/debian/choose-mirror-bin.templates.http-in
b/debian/choose-mirror-bin.templates.http-in
index 785851e..2dc1f02 100644
--- a/debian/choose-mirror-bin.templates.http-in
+++ b/debian/choose-mirror-bin.templates.http-in
@@ -29,13 +29,14 @@ _Description: Debian archive mirror country:
 Template: mirror/http/mirror
 Type: select
 Choices: ${mirrors}
+Default: deb.debian.org
 # :sl1:
 _Description: Debian archive mirror:
  Please select a Debian archive mirror. You should use a mirror in
  your country or region if you do not know which mirror has the best
  Internet connection to you.
  .
- Usually, ftp..debian.org is a good choice.
+ Usually, deb.debian.org is a good choice.

 Template: mirror/http/hostname
 Type: string


Cheers,
Julien

Re: Status and open questions for debian-installer with backports support

[Julien Cristau]

On 08/13/2018 01:57 AM, Steve McIntyre wrote:
> On Thu, Aug 02, 2018 at 10:56:59AM +0200, Cyril Brulebois wrote:
>> => Question: should we restrict architectures we build images for?
> 
> Probably. I'm only thinking x86, arm64 and maybe armhf. Wait for
> people to ask for others and add on a case-by-case basis.
> 
I'd even suggest s/x86/amd64/

New 32-bit x86 hardware shouldn't be a huge use case nowadays.

Cheers,
Julien

Re: g++-8 and g++-7 installed, reproducing a FTBFS

[Julien Cristau]

On 07/24/2018 11:08 PM, Geert Stappers wrote:
> On Tue, Jul 24, 2018 at 05:51:08AM +0200, Cyril Brulebois wrote:
>> Geert Stappers  (2018-07-23):
>>> On Wed, Jul 18, 2018 at 02:09:45AM +0200, Cyril Brulebois wrote:
 FWIW the severity of this bug report just got upgraded to serious but it
 can be directly reproduced in an up-to-date sid system, as gcc-defaults
 doesn't seem to have been switched to gcc-8 yet.
>>>
>>> How to enforce that  g++  is g++-8 ?
>>
>> That's what gcc-defaults binaries are for:
>>   
>> https://tracker.debian.org/news/974131/accepted-gcc-defaults-1178-source-into-unstable/
> 
> | $ LANG=C sudo apt install gcc-defaults
> | Reading package lists... Done
> | Building dependency tree   
> | Reading state information... Done
> | E: Unable to locate package gcc-defaults
> 
> Meaning I have another challenge   :-)
> 
gcc-defaults is a source package name, not a binary package.  One of the
binary packages built from the gcc-defaults source is "g++".

Cheers,
Julien

Bug#897718: cdebconf: ftbfs with GCC-8

[Julien Cristau]

On 07/18/2018 02:09 AM, Cyril Brulebois wrote:
> Hi,
> 
> Matthias Klose  (2018-05-04):
>> The package fails to build in a test rebuild on at least amd64 with
>> gcc-8/g++-8, but succeeds to build with gcc-7/g++-7. The
>> severity of this report will be raised before the buster release.
>>
>> The full build log can be found at:
>> http://aws-logs.debian.net/2018/05/01/gcc8/cdebconf_0.243_unstable_gcc8.log.gz
>> The last lines of the build log are at the end of this report.
>>
>> To build with GCC 8, either set CC=gcc-8 CXX=g++-8 explicitly,
>> or install the gcc, g++, gfortran, ... packages from experimental.
>>
>>   apt-get -t=experimental install g++ 
>>
>> Common build failures are new warnings resulting in build failures with
>> -Werror turned on, or new/dropped symbols in Debian symbols files.
>> For other C/C++ related build failures see the porting guide at
>> http://gcc.gnu.org/gcc-8/porting_to.html
> 
> FWIW the severity of this bug report just got upgraded to serious but it
> can be directly reproduced in an up-to-date sid system, as gcc-defaults
> doesn't seem to have been switched to gcc-8 yet.
> 
> It'd be nice if someone could take a look and fix the bug though. :)
> 

https://salsa.debian.org/installer-team/cdebconf/merge_requests/2 fixes
the build failure for me.  There's a number of warnings in non-Werror
parts of the code base that might be worth looking at, too.

Cheers,
Julien

Bug#611250: Bug

[Julien Cristau]

Control: tag -1 - help wontfix
Control: tag -1 + patch

On 05/02/2018 07:09 PM, Michal Humpula wrote:
> Hi again,
> 
> so it's 2018 and I've already booted quite a few machines with this patch, so 
> it comes the time to ask, whether it could be included in netcfg now?
> 
> As posted above, if the switch is configured in 802.3ad active mode, the 
> machines has to reply to the config frames before the link can be used to 
> send 
> regular data.
> 
> Without it, the machine is unfortunately not auto bootable.
> 
Updating tags on this bug to maybe help get your patch on the radar.

Cheers,
Julien

Bug#886016: debootstrap: add support for Acquire-By-Hash for downloading indices

[Julien Cristau]

On 02/15/2018 11:31 AM, Philipp Kern wrote:
> Control: tag -1 - patch
> 
> On 2018-01-01 17:01, Julien Cristau wrote:
>> following patch looks at the Acquire-By-Hash field in (In)Release to get
>> Packages from the by-hash directory if available and avoid races.  I
>> thought we already had a bug about this, but can't find one now.
> 
> So as discussed on IRC this patch sadly does not work as-is. It fetches
> the Packages file from the by-hash location but then proceeds to fetch
> the packages themselves from a by-hash location as well and fails when
> those fetches all 404 (because pool doesn't have a by-hash subdirectory
> and that would also not work well on a traditional filesystem if not
> sharded by, say, hash prefix).
> 
> Instead it would need to restrict itself to only attempt metadata
> fetches by-hash by passing some sort of flag around.
> 
I have an updated patch at home that seems to work, will try and
remember to push/send it tonight.

Thanks,
Julien

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

[Julien Cristau]

On 02/13/2018 04:29 PM, Raphael Hertzog wrote:
> I believe that we have had quite some testing already last time and I
> would be surprised if we got many more RC bugs on dpkg that had to be fixed
> on a short timeframe. I guess nobody can give you any assurance but
> I'm sure that you can downgrade those bugs pointing to this discussion
> and showing that this was part of the deal.
> 
If we break user systems we don't get to downgrade bugs on the basis
that "we knew we were doing a half assed job with this transition".
That's not part of the deal we're making with our users.

Cheers,
Julien

Scheduling 9.4

[Julien Cristau]

Hi,

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
- March 17
- March 24
- March 31

Thanks,
Julien


signature.asc
Description: PGP signature

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

[Julien Cristau]

On Sat, Feb  3, 2018 at 09:16:40 +0100, Marco d'Itri wrote:

> On Dec 23, md wrote:
> 
> > On Dec 20, Julien Cristau <jcris...@debian.org> wrote:
> > 
> > > > This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> > > > properly with a merged-usr system. Thus reopening this bug report for
> > > > that version.
> > > > 
> > > > The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
> > > > be great if this bug report could be re-considered.
> > > That'll be after stretch now.
> > Stretch was been released long ago: please re-enable --merged-usr in 
> > debootstrap.
> There has not been any negative feedback, can we move on please?

Is there buy-in from the dpkg maintainer?

Cheers,
Julien

Bug#886016: debootstrap: add support for Acquire-By-Hash for downloading indices

[Julien Cristau]

Package: debootstrap
Version: 1.0.89
Severity: wishlist
Tags: patch

Hi,

following patch looks at the Acquire-By-Hash field in (In)Release to get
Packages from the by-hash directory if available and avoid races.  I
thought we already had a bug about this, but can't find one now.

Cheers,
Julien


>From 1555d75078a200bfadb05e7cd30942fd050934ca Mon Sep 17 00:00:00 2001
From: Julien Cristau <jcris...@debian.org>
Date: Tue, 1 Nov 2016 12:24:44 +0100
Subject: [PATCH] Add Acquire-By-Hash support.

---
 debian/changelog | 6 ++
 functions| 6 ++
 2 files changed, 12 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index b1ef82b..4d7531a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+debootstrap (1.0.94) UNRELEASED; urgency=medium
+
+  * Add Acquire-By-Hash support.
+
+ -- Julien Cristau <jcris...@debian.org>  Tue, 01 Nov 2016 12:08:54 +0100
+
 debootstrap (1.0.93) unstable; urgency=medium
 
   [ Mattia Rizzolo ]
diff --git a/functions b/functions
index 3cfa0d4..b9efce0 100644
--- a/functions
+++ b/functions
@@ -347,6 +347,10 @@ get () {
 
while [ "$iters" -lt 10 ]; do
info RETRIEVING "Retrieving %s %s" "$displayname" 
"$versionname"
+   if [ "$checksum" != "" ] && [ -n "$ACQUIREBYHASH" ]; 
then
+   # assume we don't mix acquire-by-hash and md5
+   from="$(dirname 
"$from")/by-hash/SHA${SHA_SIZE}/$checksum"
+   fi
if ! just_get "$from" "$dest2"; then continue 2; fi
if [ "$checksum" != "" ]; then
info VALIDATING "Validating %s %s" 
"$displayname" "$versionname"
@@ -616,6 +620,8 @@ download_release_indices () {
 
extract_release_components $reldest
 
+   ACQUIREBYHASH=$(grep "^Acquire-By-Hash: yes$" "$reldest" || true)
+
local totalpkgs=0
for c in $COMPONENTS; do
local subpath="$c/binary-$ARCH/Packages"
-- 
2.11.0

Re: Bug#872953: stretch-pu: package at-spi2-core/2.22.0-6

[Julien Cristau]

Control: tag -1 d-i

On Tue, Aug 22, 2017 at 22:43:25 +0200, Samuel Thibault wrote:

> Blind users have reported that their screen reader, Orca, would
> sometimes crash when switching from window to window (Bug#872912),
> affecting both stable and testing.  Upstream released a fix, which was
> confirmed by Bug#872912 tester to completely fix the issue in sid.  I
> would thus like to upload the fix to stable, as attached diff shows.
> 
Looks fine to me, though should get a kibi-ack due to building a udeb.

Cyril, please tag this either confirmed or moreinfo when you have a
chance.

Cheers,
Julien

> commit acbc35d8089e0ad597fd4f22b8c745d87ebe33e8
> Author: Samuel Thibault 
> Date:   Tue Aug 22 21:07:39 2017 +0200
> 
> Upstream fix for crash on switching between windows
> 
> patches/accessible_get_parent.diff (Closes: Bug#872912).
> 
> diff --git a/debian/changelog b/debian/changelog
> index 5e0b720..0252734 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +at-spi2-core (2.22.0-6+deb9u1) stretch; urgency=medium
> +
> +  * patches/accessible_get_parent.diff: Upstream fix for crash on switching
> +between windows (Closes: Bug#872912).
> +
> + -- Samuel Thibault   Thu, 10 Aug 2017 21:20:02 +0200
> +
>  at-spi2-core (2.22.0-6) unstable; urgency=medium
>  
>* patches/git-329ef2c4ebcb3aec6dcfcac15357fd583a60c969:
> diff --git a/debian/patches/accessible_get_parent.diff 
> b/debian/patches/accessible_get_parent.diff
> new file mode 100644
> index 000..5c1d035
> --- /dev/null
> +++ b/debian/patches/accessible_get_parent.diff
> @@ -0,0 +1,30 @@
> +commit 2347dad97cd903f6b7fed5a56b738e9ecdf80cac
> +Author: Mike Gorse 
> +Date:   Mon May 8 18:59:40 2017 -0500
> +
> +atspi_accessible_get_parent: move check for NULL AtspiApplication object
> +
> +Now, if we don't have a cached parent, then we always either return NULL
> +or make a D-Bus call. This might make the code more robust, and hoping
> +that it will fix https://bugzilla.gnome.org/show_bug.cgi?id=767074,
> +though in theory it should make no difference there.
> +
> +diff --git a/atspi/atspi-accessible.c b/atspi/atspi-accessible.c
> +index 4547ef7..b84317f 100644
> +--- a/atspi/atspi-accessible.c
>  b/atspi/atspi-accessible.c
> +@@ -268,11 +268,12 @@ atspi_accessible_get_parent (AtspiAccessible *obj, 
> GError **error)
> + {
> +   g_return_val_if_fail (obj != NULL, NULL);
> + 
> +-  if (obj->parent.app &&
> +-  !_atspi_accessible_test_cache (obj, ATSPI_CACHE_PARENT))
> ++  if (!_atspi_accessible_test_cache (obj, ATSPI_CACHE_PARENT))
> +   {
> + DBusMessage *message, *reply;
> + DBusMessageIter iter, iter_variant;
> ++if (!obj->parent.app)
> ++  return NULL;
> + message = dbus_message_new_method_call (obj->parent.app->bus_name,
> + obj->parent.path,
> + DBUS_INTERFACE_PROPERTIES, 
> "Get");
> diff --git a/debian/patches/series b/debian/patches/series
> index 266c41a..eb8e71a 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -3,3 +3,4 @@ revert-register-late
>  register-client-not-too-early
>  git-329ef2c4ebcb3aec6dcfcac15357fd583a60c969
>  git-eba079f3e72e61e6b55d81727ab50c85d505d296
> +accessible_get_parent.diff

Re: Bug#869667: stretch-pu: package xkeyboard-config/2.19-1

[Julien Cristau]

Control: tags -1 = stretch d-i confirmed

On Sat, Sep  9, 2017 at 14:12:38 +0200, Cyril Brulebois wrote:

> Adam D. Barratt  (2017-07-30):
> > Control: tags -1 + moreinfo d-i
> > 
> > On Tue, 2017-07-25 at 19:20 +0530, Pirate Praveen wrote:
> > > This fixes serious bug #865316 (all Indic language users were unable to
> > > select their keyboard layouts in stretch introducing a regression. This
> > > was caused by an earlier commit upstream which blacklisted Indic
> > > keyboard layouts, upstream was convinced it was a mistake and reverted
> > > the blacklist. This update applies that patch to debian package so
> > > stretch users can type using Indic language keyboards again).
> > 
> > This looks okay to me, other than this noise in the diff:
> > 
> > --- xkeyboard-config-2.19.orig/debian/files
> > +++ xkeyboard-config-2.19/debian/files
> > @@ -0,0 +1 @@
> > +xkeyboard-config_2.19-1.1_source.buildinfo x11 extra
> > 
> > As the package produces a udeb, this will need an ack from the d-i RM as
> > well; CCing appropriately.
> 
> No objections, thanks.
> 
Feel free to upload with the debian/files issue fixed.

Cheers,
Julien

Re: Kernel ABI bump in stretch

[Julien Cristau]

On Sun, Sep  3, 2017 at 01:45:48 +0100, Ben Hutchings wrote:

> There are several changes in the 4.9-stable branch which I don't think
> we can take without changes to the kernel module ABI that will affect
> out-of-tree modules.  This would mean an ABI bump, changing the names
> of all linux-image and linux-headers packages.
> 
> Since we install meta-packages (such as linux-image-amd64) by default,
> an 'apt full-upgrade' should result in installing the appropriate new
> packages.  However, we have been able to avoid such an ABI bump in the
> past 3 releases (so far) and this might come as a surprise to users.  I
> think the point release announcement would need to draw attention to
> this.
> 
> If this is totally unacceptable, I can revert the breaking changes, but
> some of them fix use-after-free bugs that probably have security
> impact.
> 
> Please let us know as soon as possible whether an ABI bump is OK, so
> that we can prepare the update in time for the next point release.
> 
This should be fine.  We don't ship any pre-built modules in stretch
outside the linux source package, so the only other thing we need to do
is update d-i at that point release.

Cheers,
Julien


signature.asc
Description: PGP signature

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

[Julien Cristau]

On Mon, Aug 28, 2017 at 20:09:54 +0200, Cyril Brulebois wrote:

> Hi,
> 
> FTPmasters, please sync the installer from sid to testing:
> 
>   dak copy-installer 20170828
> 
> (The mips64el build is missing because of gcc-7 fun: #873465)
> 
> 
> Release team, please force it into testing.
> 
Force hint added.

Cheers,
Julien

Re: Last chance for d-i changes in stretch

[Julien Cristau]

On Sat, May 27, 2017 at 17:17:10 +0200, Didier 'OdyX' Raboud wrote:

> 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.
> 
Yes please.

Cheers,
Julien

Bug#854801: Network Manager, Stretch and ipv6

[Julien Cristau]

+rdisc6 maintainer

On 05/26/2017 06:49 PM, Julien Cristau wrote:
> On 05/26/2017 06:33 PM, Cyril Brulebois wrote:
>> Hi,
>>
>> Michael Biebl <bi...@debian.org> (2017-05-23):
>>> Control: severity 854801 serious
>>> Control: reassign 854801 netcfg
>>>
>>> Hi
>>>
>>> This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854801
>>>
>>> Since this issue is now cropping up regularly, I'd say it's something
>>> which needs to be fixed for stretch, thus marking the bug as RC.
>>>
>>> Regards,
>>> Michael
>>
>> This issue is indeed (too) well known, but I need to grow a better
>> understanding of various IPv6 configurations to get this fixed properly
>> in stable suites. (I'm making progress on this front but I have a few
>> busy weeks in front of me before getting back to this.)
>>
>> In any case, this feels like something that might need to wait until
>> after r0 (can-defer in release team speak IIRC, cc'd).
>>
> IMO we should change d-i/netcfg to just never install rdnssd.  I guess
> that might negatively impact systems on ipv6-only networks that don't
> have any other means to pick up name servers, but that seems strictly
> better than installing a package which conflicts with NM.
> 
> Cheers,
> Julien
> 

Bug#854801: Network Manager, Stretch and ipv6

[Julien Cristau]

On 05/26/2017 06:33 PM, Cyril Brulebois wrote:
> Hi,
> 
> Michael Biebl  (2017-05-23):
>> Control: severity 854801 serious
>> Control: reassign 854801 netcfg
>>
>> Hi
>>
>> This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854801
>>
>> Since this issue is now cropping up regularly, I'd say it's something
>> which needs to be fixed for stretch, thus marking the bug as RC.
>>
>> Regards,
>> Michael
> 
> This issue is indeed (too) well known, but I need to grow a better
> understanding of various IPv6 configurations to get this fixed properly
> in stable suites. (I'm making progress on this front but I have a few
> busy weeks in front of me before getting back to this.)
> 
> In any case, this feels like something that might need to wait until
> after r0 (can-defer in release team speak IIRC, cc'd).
> 
IMO we should change d-i/netcfg to just never install rdnssd.  I guess
that might negatively impact systems on ipv6-only networks that don't
have any other means to pick up name servers, but that seems strictly
better than installing a package which conflicts with NM.

Cheers,
Julien

8.8 planning

[Julien Cristau]

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
* April 15-16
* April 22-23
* April 29-30
* May 6-7

I know at least Adam can't do 15-16 so that one is most likely out anyway.

Cheers,
Julien

Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

[Julien Cristau]

On 02/27/2017 04:40 PM, Steven Chamberlain wrote:
> Bastian Blank wrote:
>> This change breaks the existing ABI and therefor needs an ABI bump, but
>> it is missing from the patch.
> 
> The attached patch tries to bump the soname to 5.  This makes the diff
> much larger, but the code changes are the same.
> 
> I think libdebian-installer-extra nowadays gets a soname bump at the
> same time as libdebian-installer (whereas in the past it was possible to
> set a different soname for each).
> 
> (If we really wanted, we could maybe avoid the ABI bump:  no library
> functions are being added/removed, only the name and meaning of a struct
> member (a pointer, which remains the same length).  The
> dynamically-sized buffer it points to, would change from storing an MD5
> to a SHA256 hash, and would only cause a regression where something is
> still trying to validate MD5).
> 
Changing semantics of an existing struct member is classic ABI breakage.
 This does very much need a SONAME bump.

Cheers,
Julien

Bug#852215: FTBFS on non-release architectures

[Julien Cristau]

On Sun, Jan 22, 2017 at 16:03:20 +, James Clarke wrote:

> Package: debian-installer
> Version: 20170112
> Severity: wishlist
> Tags: patch
> X-Debbugs-Cc: debian-ports-de...@lists.alioth.debian.org
> 
> Hi,
> As you know, debian-installer does not build on non-release
> architectures, since it tries to build for stretch. Some architectures
> also have some of the needed udebs in the unreleased suite, such as
> sparc-utils on sparc64. The attached patch lets me build on sparc64 even
> after a `dch --release`, and I would assume on other ports architectures
> too. Is this something you would consider applying?
> 
Pulling packages from unreleased into main sounds like a bad idea, those
architectures would better have their own unreleased and
differently-versioned debian-installer IMO.

Cheers,
Julien

Bug#851539: Stretch RC1 netinst installer prompts for additional CDs

[Julien Cristau]

On 01/16/2017 07:56 PM, Josh Triplett wrote:
> On Mon, Jan 16, 2017 at 12:30:03PM +, Steve McIntyre wrote:
>> On Sun, Jan 15, 2017 at 11:51:43PM -0800, Josh Triplett wrote:
>>> On Mon, Jan 16, 2017 at 01:13:13AM +, Steve McIntyre wrote:
 On Sun, Jan 15, 2017 at 04:53:26PM -0800, Josh Triplett wrote:
> Package: installation-reports
> Severity: normal
>
> I tried doing an install with a Stretch RC1 netinst CD.  Worked fine,
> except that later in the install, right before asking about an apt
> mirror, the installer asked about scaning additional CDs.  Previous
> versions of the netinst installer haven't asked that question; normally
> only the full-CD installers ask that.

 This is a deliberate change, yes. It makes the firmware netinsts more
 useful now, for example...
>>>
>>> I thought that firmware had a separate prompting mechanism, triggered by
>>> the detection of missing firmware?  If the installer notices missing
>>> firmware, it prompts for separate firmware media.
>>
>> There's also some netinsts with firmware included [1], and those are
>> the ones this will help with. The previous settings in apt-setup were
>> not very consistent and *very* old, so I've tweaked which images will
>> ask about extra media.
> 
> How does it help for the firmware-included images?
> 
It makes it possible to use them to install from CD rather than from the
network.

Cheers,
Julien

Re: Please dak copy-installer 20170112

[Julien Cristau]

On 01/12/2017 01:37 PM, Cyril Brulebois wrote:
> Release team, please hint it into testing:
> 
>   urgent debian-installer/20170112
> 
> 
Done.

Cheers,
Julien

Re: dillon: additional build-depends for installation-guide

[Julien Cristau]

On Sat, Dec 31, 2016 at 12:39:41 +0100, Holger Wansing wrote:

> Hello,
> 
> we have recently switched the creation of PDFs for the debian-installer's
> manual (package "installation-guide") from jade to dblatex.
> Benefit is, that this way we can create PDFs for Chinese, Greek, Japanese,
> and Vietnamese languages, what was not possible before.
> 
> Because of this change, there are additional build-dependencies to be 
> installed
> on dillon to build the manual.
> The relevant change in the svn repo for installation-guide can be found here:
> 
> https://anonscm.debian.org/viewvc/d-i?view=revision=70430
> 
> 
> 
> 
> Attached is a patch for the debian.org control file for dillon:
> 
> https://anonscm.debian.org/cgit/mirror/debian.org.git/tree/debian/control#n974
> 
> which I would be happy to see applied.
> 
Applied, and extra packages installed.

Cheers,
Julien

Re: 8.7 planning

[Julien Cristau]

On Mon, Dec 19, 2016 at 14:19:26 +0100, Julien Cristau wrote:

> Hi,
> 
> we're overdue for the next jessie point release.  Here are some possible
> dates, please reply with availability.
> 
Thanks all for the quick replies.  Let's plan for 8.7 on Jan 14th/15th.

Cheers,
Julien

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

[Julien Cristau]

On 12/20/2016 01:35 AM, Michael Biebl wrote:
> Control: found -1 1.0.87
> 
> Hi there!
> 
> On Wed, 28 Sep 2016 08:47:21 +0200 Ansgar Burchardt 
> wrote:
>> Package: debootstrap
>> Version: 1.0.83
>>
>> As mentioned earlier, I would like to see --merged-usr enabled by
>> default for Debian Stretch.  The last discussion on -devel@[1] was quite
>> positive; I had some additional positive feedback on IRC.
>>
>> I'm not aware of any regressions so far, except for having forgotten to
>> add "jessie-kfreebsd" to the blacklist (a list of older releases that
>> don't support merged-/usr) and debootstrap 1.0.83 failing to bootstrap
>> squeeze[2].  Both are fixed in my changes targeted at 1.0.84[3].
>>
>> So I would like to switch the default in debootstrap sooner rather than
>> later to give time to find some more bugs.  With this change, the
>> currently known bugs[4] should also be raised to "serious", but I don't
>> think any of them should be a blocker.
>>
>> Ansgar
>>
>>   [1] 
>>   [2] 
>>   [3] 
>>   [4] 
>> 
> 
> 
> This change was reverted in 1.0.87 as dpkg-shlibdeps didn't cope
> properly with a merged-usr system. Thus reopening this bug report for
> that version.
> 
> The dpkg-shlibdeps bugs has been fixed [1] in the mean time. So it would
> be great if this bug report could be re-considered.
> 
That'll be after stretch now.

Cheers,
Julien

8.7 planning

[Julien Cristau]

Hi,

we're overdue for the next jessie point release.  Here are some possible
dates, please reply with availability.

Jan 7th/8th

Jan 14th/15th

Jan 21st/22nd

Jan 28th/29th - Cambridge BSP, probably not ideal

Feb 4th/5th - FOSDEM, probably not great either

Feb 11th/12th

Thanks,
Julien



signature.asc
Description: OpenPGP digital signature

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

[Julien Cristau]

Control: severity -1 normal

On 12/19/2016 10:58 AM, Sven Joachim wrote:
> Control: severity -1 serious
> 
> On 2016-11-12 20:32 +0100, Sven Joachim wrote:
> 
>> On 2016-09-04 19:28 +0200, Sven Joachim wrote:
>>
>>> Control: tags -1 + patch
>>>
>>> The attached patch should fix the problem with arch-qualifiers in
>>> debootstrap, tested with
>>> "debootstrap --variant=minbase --include=autoconf-dickey" which fails
>>> right now in unstable but succeeds with the patch (autoconf-dickey
>>> depends on perl:any).
>>
>> It should be noted that dpkg-dev in unstable now also depends on
>> perl:any.  This does not cause problems yet, but only because
>> libdpkg-perl depends on perl and debootstrap silently ignores any
>> dependencies it cannot resolve, which is a bug in itself.
>>
>> This bug is a ticking time bomb, would be nice to apply my patch before
>> it explodes.
> 
> The latest dpkg upload (1.18.17) changed the dependency of libdpkg-perl
> to perl:any as well, and now "debootstrap --variant=buildd" fails
> because it no longer downloads perl.
> 
I think that needs to be reverted in dpkg, we really want to be able to
create sid chroots with stable debootstrap.

Cheers,
Julien

Bug#842040: Please add https support

[Julien Cristau]

On 12/07/2016 10:18 PM, Philipp Kern wrote:
> choose-mirror does not ask for the protocol by default, as the question
> is priority medium. I did my installation by passing priority=medium on
> the command-line, but you could as well preseed the protocol to https I
> think. In that case it does not show a list of mirrors (because
> Mirrorlist does not list https capabilities), but works just fine with
> deb.debian.org, which points to Cloudfront for HTTPS support. d-i
> component load worked, debootstrap worked and the resulting chroot had
> apt-transport-https and a sources.list pointing to
> https://deb.debian.org. The security archive was added without https,
> but that's unavoidable at this point given that it does not actually
> support it.

We could use deb.debian.org as default security mirror, I guess.  Or add
a https vhost on our security mirrors.  Definitely not a blocker for
landing this though.

[...]
> So I suppose this should be ok to commit and push?
> 
No objection from me, at least.  Thanks for doing this work.

Cheers,
Julien

Bug#842040: Please add https support

[Julien Cristau]

On Sun, Nov 20, 2016 at 11:52:09 +0100, Philipp Kern wrote:

> On 20.11.2016 11:45, Cyril Brulebois wrote:
> >> But you are absolutely correct in for this to be universally useful,
> >> we'd also need a ca-certificates-udeb. I can take a look at that but I
> >> somewhat fear that it won't be that much smaller than the regular one
> >> (maybe ~150k udeb size).
> > 
> > If you're going to need another cpio archive with PEM files, can't you
> > just add the needed bits (wget & libraries) for https there?
> > 
> > Adding packages for every single image just so that Google people can
> > append a cpio archive with some CAs doesn't look too reasonable to me:
> > you need to do extra work on your end anyway, and everybody pays that
> > price without getting any advantage…
> 
> Well, I said why adding wget plus somehow determining the required
> libraries is harder than just adding some static content.[1] We also
> wouldn't need to do the PEM cpio dance if ca-certificates-udeb would be
> part of the image. We don't need to add an internal CA or something like
> that.
> 
I think until there's a ca-certificates-udeb, adding wget for https in
all images isn't reasonable, vs google rebuilding d-i with added wget
and the PEM bits you need.  I guess ca-certificates-udeb would need some
way to preseed a list of trusted CAs.

Cheers,
Julien

Bug#819300: should provide default HTTPS mirrors for non-Debian releases too

[Julien Cristau]

Control: tag -1 moreinfo

On Sat, Mar 26, 2016 at 10:51:21AM +0100, Evgeni Golov wrote:
> Package: debootstrap
> Version: 1.0.80
> Severity: wishlist
> 
> Hi,
> 
> currently debootstrap only knows about an HTTPS mirror for Debian, but not 
> e.g. for Ubuntu.

Does ubuntu even run https mirrors?  A pointer to official documentation
would be appreciated, I couldn't find it in a quick search.

Cheers,
Julien

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

[Julien Cristau]

On Tue, Sep 20, 2016 at 19:00:20 +, Stephan Suerken wrote:

> Package: debootstrap
> Version: 1.0.83
> Severity: normal
> 
> Dear Maintainers,
> 
> since 1.0.83 (1.0.82 tested successfully), deboostrap fails to
> strap (at least) squeeze. For example:
> 
> ---
> sudo /usr/sbin/debootstrap --variant buildd --arch amd64 squeeze 
> ./squeeze-amd64-83 http://archive.debian.org/debian
> (...)
> I: Extracting bash...
> I: Extracting libbz2-1.0...
> I: Extracting coreutils...
> I: Extracting dash...
> ---
> 
> 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.

Cheers,
Julien

Re: debootstrap InRelease file support

[Julien Cristau]

On Fri, Sep 16, 2016 at 14:56:00 -0400, Lennart Sorensen wrote:

> A bit of a hack but I believe posix compliant would be:
> 
> sed '1,/^$/d;/^-BEGIN PGP SIGNATURE-$/,$d' < "$inreldest" | tr '\n' 
> '\a' | sed 's/\a$//' | tr '\a' '\n' > "$reldest"
> 
> So simply replace all newlines with bells, then delete the last bell
> and then convert the bells back to newlines.  I sure can't imagine the
> Release file contains any bell characters.  Could use escape instead
> if prefered.
> 
> Pretty awful compared to the head -c -1 option, but maybe not that bad.
> 
Thanks, that looks like it should work :)

Cheers,
Julien

Re: debootstrap InRelease file support

[Julien Cristau]

On Fri, Sep 16, 2016 at 14:06:51 -0400, Lennart Sorensen wrote:

> On Fri, Sep 16, 2016 at 08:02:10PM +0200, Julien Cristau wrote:
> > On Fri, Sep 16, 2016 at 13:55:53 -0400, Lennart Sorensen wrote:
> > 
> > > On Fri, Sep 16, 2016 at 06:59:44PM +0200, Julien Cristau wrote:
> > > > On Fri, Sep  2, 2016 at 20:35:12 +0200, Julien Cristau wrote:
> > > > 
> > > > > On Mon, Aug 15, 2016 at 12:12:02 +0200, Ansgar Burchardt wrote:
> > > > > 
> > > > > > 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`.
> > > > > > 
> > > > > Here's an attempt at doing that.  Only lightly tested.
> > > > > 
> > > > Ansgar pointed out on IRC that so far nothing in debootstrap requires
> > > > awk on the host.  I haven't found a way to kill the last newline with
> > > > sed in a quick attempt, and I don't know how big of a deal requiring awk
> > > > would be, so help welcome.
> > > 
> > > How about instead of the awk bit using:
> > > 
> > > sed '1,/^$/d;/^-BEGIN PGP SIGNATURE-$/,$d' < "$inreldest" > 
> > > "$reldest"
> > > 
> > > At least that works for the InRelease in debian sid since it has a blank
> > > line at the end of the PGP header before the Release file data.
> > > 
> > My problem is getting something that I can feed to gpgv to verify the
> > signature, I don't think your command provides that.
> 
> Well it makes a Release file that is totally bit for bit identical to
> the Release file that goes with Release.gpg
> 
> diff verified that.
> 
> So if gpgv wants something different than the original Release file,
> then that's weird.
> 
As far as I remember, it does.  The final newline needs to be stripped.

Cheers,
Julien

Re: debootstrap InRelease file support

[Julien Cristau]

On Fri, Sep 16, 2016 at 13:55:53 -0400, Lennart Sorensen wrote:

> On Fri, Sep 16, 2016 at 06:59:44PM +0200, Julien Cristau wrote:
> > On Fri, Sep  2, 2016 at 20:35:12 +0200, Julien Cristau wrote:
> > 
> > > On Mon, Aug 15, 2016 at 12:12:02 +0200, Ansgar Burchardt wrote:
> > > 
> > > > 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`.
> > > > 
> > > Here's an attempt at doing that.  Only lightly tested.
> > > 
> > Ansgar pointed out on IRC that so far nothing in debootstrap requires
> > awk on the host.  I haven't found a way to kill the last newline with
> > sed in a quick attempt, and I don't know how big of a deal requiring awk
> > would be, so help welcome.
> 
> How about instead of the awk bit using:
> 
> sed '1,/^$/d;/^-BEGIN PGP SIGNATURE-$/,$d' < "$inreldest" > "$reldest"
> 
> At least that works for the InRelease in debian sid since it has a blank
> line at the end of the PGP header before the Release file data.
> 
My problem is getting something that I can feed to gpgv to verify the
signature, I don't think your command provides that.

Cheers,
Julien

Re: debootstrap InRelease file support

[Julien Cristau]

On Fri, Sep  2, 2016 at 20:35:12 +0200, Julien Cristau wrote:

> On Mon, Aug 15, 2016 at 12:12:02 +0200, Ansgar Burchardt wrote:
> 
> > 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`.
> > 
> Here's an attempt at doing that.  Only lightly tested.
> 
Ansgar pointed out on IRC that so far nothing in debootstrap requires
awk on the host.  I haven't found a way to kill the last newline with
sed in a quick attempt, and I don't know how big of a deal requiring awk
would be, so help welcome.

Cheers,
Julien

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

[Julien Cristau]

On Thu, Sep  8, 2016 at 14:07:04 +0200, Johannes Schauer wrote:

> Package: debootstrap
> Version: 1.0.81
> Severity: normal
> 
> Hi,
> 
> in Debian, every binary package implicitly depends on all binary
> packages marked as Essential:yes and every source package implicitly
> build-depends on the binary package build-essential. Policy §4.2 says:
> 
>  | it must be possible to build the package and produce working binaries
>  | on a system with only essential and build-essential packages installed
>  | and also those required to satisfy the build-time relationships
>  | (including any implied relationships).
> 
> Currently, programs in Debian that facilitate building source packages
> in "clean" environments like sbuild and pbuilder use debootstrap to
> create this "minimal" environment. Specifically, they use the buildd
> variant provided by debootstrap.
> 
> Unfortunately it seems that in addition to installing the minimum
> required packages (all Essential:yes, build-essential and (unfortunately
> necessarily) apt), debootstrap also installs all packages marked as
> Priority:required (and their transitive dependencies).
> 
This is a transient situation because some Essential packages'
dependencies changed.  I'd consider this a bug in the archive, not in
debootstrap.

Cheers,
Julien

Re: debootstrap InRelease file support

[Julien Cristau]

On Mon, Aug 15, 2016 at 12:12:02 +0200, Ansgar Burchardt wrote:

> 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`.
> 
Here's an attempt at doing that.  Only lightly tested.

Cheers,
Julien

diff --git a/debian/changelog b/debian/changelog
index 46b4974..3f0ef23 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+debootstrap (1.0.82) UNRELEASED; urgency=medium
+
+  * Add support for downloading and validating InRelease files, by splitting
+up detached signature from signed data.
+
+ -- Julien Cristau <jcris...@debian.org>  Fri, 02 Sep 2016 20:26:38 +0200
+
 debootstrap (1.0.81) unstable; urgency=medium
 
   [ Luca Falavigna ]
diff --git a/functions b/functions
index 031721f..407cc38 100644
--- a/functions
+++ b/functions
@@ -537,15 +537,30 @@ download_release_sig () {
 download_release_indices () {
local m1="${MIRRORS%% *}"
local reldest="$TARGET/$($DLDEST rel "$SUITE" "$m1" 
"dists/$SUITE/Release")"
-   local relsigdest
+   local inreldest="$TARGET/$($DLDEST rel "$SUITE" "$m1" 
"dists/$SUITE/InRelease")"
+   local relsigdest="$TARGET/$($DLDEST rel "$SUITE" "$m1" 
"dists/$SUITE/Release.gpg")"
progress 0 100 DOWNREL "Downloading Release file"
progress_next 100
-   get "$m1/dists/$SUITE/Release" "$reldest" nocache ||
-   error 1 NOGETREL "Failed getting release file %s" 
"$m1/dists/$SUITE/Release"
-   relsigdest="$TARGET/$($DLDEST rel "$SUITE" "$m1" 
"dists/$SUITE/Release.gpg")"
-   progress 100 100 DOWNREL "Downloading Release file"
+   if get "$m1/dists/$SUITE/InRelease" "$inreldest" nocache; then
+   sed -n '/^-BEGIN PGP SIGNATURE-$/,/^-END PGP 
SIGNATURE-$/p' < "$inreldest" > "$relsigdest"
+   awk 'BEGIN {ORS="" ; first=1}
+/^-BEGIN PGP SIGNED MESSAGE-$/,/^$/ { next }
+/^-BEGIN PGP SIGNATURE-$/,/^-END PGP 
SIGNATURE-$/ {next}
+{ if (first) { first=0 } else { printf "\n" } print }' \
+   < "$inreldest" > "$reldest"
+   progress 100 100 DOWNREL "Downloading Release file"
+   info RELEASESIG "Checking Release signature"
+   # Don't worry about the exit status from gpgv; parsing the 
output will
+   # take care of that.
+   (gpgv --status-fd 1 --keyring "$KEYRING" --ignore-time-conflict 
\
+"$relsigdest" "$reldest" || true) | read_gpg_status
+   else
+   get "$m1/dists/$SUITE/Release" "$reldest" nocache ||
+   error 1 NOGETREL "Failed getting release file %s" 
"$m1/dists/$SUITE/Release"
+   progress 100 100 DOWNREL "Downloading Release file"
 
-   download_release_sig "$m1" "$reldest" "$relsigdest"
+   download_release_sig "$m1" "$reldest" "$relsigdest"
+   fi
 
extract_release_components $reldest
 

Re: 8.6 planning

[Julien Cristau]

On Sun, Aug  7, 2016 at 23:04:44 +0100, Adam D. Barratt wrote:

> September 3rd/4th 
> 
Won't work for me.

> September 10th/11th
> 
> September 17th/18th
> 
Should be ok.

Cheers,
Julien

Re: debootstrap InRelease file support

[Julien Cristau]

On Thu, Mar  3, 2016 at 21:12:06 -0500, Mathieu Trudel-Lapierre wrote:

> Hi,
> 
> 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.

Cheers,
Julien

Re: [Pkg-openssl-devel] Bug#827951: libssl udeb inclusion in Jessie

[Julien Cristau]

On Thu, Jun 23, 2016 at 12:55:54 +0200, Yann Soubeyrand wrote:

> Le jeudi 23 juin 2016 à 11:20 +0200, k...@roeckx.be a écrit :
> > On Thu, Jun 23, 2016 at 10:58:54AM +0200, Yann Soubeyrand wrote:
> > > Package: openssl
> > > Severity: normal
> > > Version: 1.0.1t-1+deb8u2
> > > X-Debbugs-CC: debian-rele...@lists.debian.org
> > > X-Debbugs-CC: debian-boot@lists.debian.org
> > > 
> > > Hi,
> > > 
> > > Marga Manterola provided a patch to build a libssl udeb as well as the
> > > libcrypto udeb that was included in Sid (#802591). Could this patch be a
> > > candidate for Jessie inclusion? If so, you can find a patch attached to
> > > this mail.
> > 
> > Is there a reason why you would like it in jessie?  Will the
> > installer start to make use of it?
> > 
> > Kurt
> 
> At the company I work for, we customize the installer to fit our needs
> and we make use of wget udeb's https support. It would make our task
> simpler not to have to maintain a modified version of openssl and wget
> packages.
> 
That doesn't sound suitable for a stable update, sorry.

Cheers,
Julien

Upcoming stable point release (8.5)

[Julien Cristau]

Hi,

The next point release for "jessie" (8.5) is scheduled for Saturday,
June 4th. Processing of new uploads into jessie-proposed-updates
will be frozen during the preceding weekend.

Cheers,
Julien

Upcoming oldstable point release (7.11)

[Julien Cristau]

Hi,

The next (and last) point release for "wheezy" (7.11) is scheduled for
Saturday, June 4th. Processing of new uploads into
wheezy-proposed-updates will be frozen during the preceding weekend.

Cheers,
Julien

Re: 8.5 and 7.11 planning

[Julien Cristau]

On Sat, May 14, 2016 at 20:20:28 +0200, Julien Cristau wrote:

> Hi,
> 
> with wheezy EOL, we should get a final point release out.  In order to
> avoid version skew, it'd be good to have a jessie point release around
> the same time, so if that works for everyone let's do them both on the
> same Saturday again.
> 
> Some suggested dates:
> 
> June 4th/5th

It looks like that works for everyone, so let's go with that.  This
means we will be freezing (o)pu next week-end.

Cheers,
Julien

8.5 and 7.11 planning

[Julien Cristau]

Hi,

with wheezy EOL, we should get a final point release out.  In order to
avoid version skew, it'd be good to have a jessie point release around
the same time, so if that works for everyone let's do them both on the
same Saturday again.

Some suggested dates:

June 4th/5th
June 11th/12th
June 18th/19th
June 25th/26th

Cheers,
Julien

Re: 8.4 and 7.10 planning

[Julien Cristau]

On Sun, Feb 21, 2016 at 12:24:35 +, Adam D. Barratt wrote:

> Hi,
> 
> We're due both Jessie and Wheezy point releases, and are proposing doing
> both on the same weekend again, as we did for 8.2 and 7.9, as the CD
> team seem happy to try it again.
> 
> Some suggested dates:
> 
> March 12th / 13th
> March 19th / 20th
> March 26th / 27th - Easter, holiday weekend in at least the UK
> April 2nd / 3rd
> 
Should all work for me.

Cheers,
Julien


signature.asc
Description: PGP signature

Re: Bug#806164: installation-reports: jessie install on dell xps 13 9350 (grub-installer issues)

[Julien Cristau]

Control: reassign -1 grub-installer 1.117
Control: severity -1 important
Control: retitle -1 grub-installer: too much hardcoding of device names, fails 
with /dev/nvme*

On Wed, Nov 25, 2015 at 00:06:57 +0100, Julien Cristau wrote:

> Installation went fine (well, had to stay close to the screen because
> the text was quite small on this high-dpi display) until the
> grub-installer step.  Which failed horribly, I think because the
> /dev/nvme0n1 device name for the drive isn't expected.  See attached
> excerpt from syslog (contains a few invocations of grub-installer while
> I was trying to understand what was going on; the last one has
> DEBCONF_DEBUG and set -x enabled.
> 
Reassigning.

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#806164: installation-reports: jessie install on dell xps 13 9350 (grub-installer issues)

[Julien Cristau]

Package: installation-reports

Boot method: USB
Image version: 
http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/firmware-8.2.0-amd64-netinst.iso
Date: November 24, 2015

Machine: Dell XPS 13 9350
Partitions: fdisk -l

Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 121A6F68-CA63-4FB1-98BD-61F0971A674C

Device StartEnd   Sectors   Size Type
/dev/nvme0n1p1  20481026047   1024000   500M EFI System
/dev/nvme0n1p2   10260481288191262144   128M Microsoft reserved
/dev/nvme0n1p3   1288192  502419455 501131264   239G Microsoft basic data
/dev/nvme0n1p4 977592320  979337215   1744896   852M Windows recovery environmen
/dev/nvme0n1p5 979337216 1000214527  2087731210G Windows recovery environmen
/dev/nvme0n1p6 502419456  961990655 459571200 219.1G Linux filesystem
/dev/nvme0n1p7 961990656  977592319  15601664   7.5G Linux swap

Partition table entries are not in disk order.


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O] (had to use an usb wlan thing, the shipped one 
isn't supported until linux 4.4)
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [E] 
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[O]

Comments/Problems:

Initially, the disk was setup as "RAID" in the BIOS, and I couldn't get
linux to recognize it.  Googling suggested disabling that mode and using
"AHCI" instead.  That broke Windows, so I had to reinstall, but it
allowed d-i to see the disk.

Installation went fine (well, had to stay close to the screen because
the text was quite small on this high-dpi display) until the
grub-installer step.  Which failed horribly, I think because the
/dev/nvme0n1 device name for the drive isn't expected.  See attached
excerpt from syslog (contains a few invocations of grub-installer while
I was trying to understand what was going on; the last one has
DEBCONF_DEBUG and set -x enabled.

After reboot I'm on the fbdev X driver (on simplefb) and llvmpipe, and
gnome-shell works surprisingly well (if it wasn't for xrandr not listing
outputs I might not have noticed).

Cheers,
Julien
-- 

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="8 (jessie) - installer build 20150422+deb8u2"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux  3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 
(2015-08-04) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:1904] 
(rev 08)
lspci -knn: Subsystem: Dell Device [1028:0704]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:1916] (rev 07)
lspci -knn: Subsystem: Dell Device [1028:0704]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:1903] (rev 08)
lspci -knn: Subsystem: Dell Device [1028:0704]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:9d2f] 
(rev 21)
lspci -knn: Subsystem: Dell Device [1028:0704]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Device [8086:9d31] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:0704]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:9d60] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:0704]
lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation 
Device [8086:9d61] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:0704]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Device 
[8086:9d3a] (rev 21)
lspci -knn: Subsystem: Dell Device [1028:0704]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:9d10] 
(rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Device [8086:9d14] 
(rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation Device [8086:9d15] 
(rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:9d18] 
(rev f1)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:9d48] 
(rev 21)
lspci -knn: 

Re: download links for Jessie 404

[Julien Cristau]

On Sun, Sep  6, 2015 at 18:40:24 +0200, Holger Wansing wrote:

> The "8.2.0" directory in http://cdimage.debian.org/debian-cd/ is completely
> missing.
> 
> That makes me wonder if the "Dropping CDs entirely?!" story was also
> adopted to the stable and oldstable point releases??? 
> No installation media build for stable and oldstable?
> If that's intended, there are a lot of changes needed on the website...
> 
The website was switched to point to 8.2 images before they were even
built...

Cheers,
Julien


signature.asc
Description: Digital signature

Re: d-i/jessie upload (was: dinstall trigger problems?)

[Julien Cristau]

On Mon, Aug 31, 2015 at 01:13:56 +0200, Cyril Brulebois wrote:

> I plan to upload debian-installer from the jessie branch somewhen this
> monday (after I see grub-installer/jessie move to Installed to be on the
> safe side, even if it's usually pulled outside d-i build), if that's fine
> with you.
> 
Hi,

No choose-mirror update this time around?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Bug#702278: busybox upload

[Julien Cristau]

On Mon, Sep 30, 2013 at 00:09:15 +0200, Cyril Brulebois wrote:

 Control: tag -1 -confirmed
 
 Michael Tokarev m...@tls.msk.ru (2013-05-09):
  Control: reopen -1
  
  05.05.2013 12:00, Michael Tokarev wrote:
   Control: retitle -1 pu: busybox/1:1.20.0-8
  
  Hmm.  I didn't notice the bug has been closed...
  Reopening it (now re-titled as a pu), instead of
  submiting a new report, so that all the information
  is in one place.
  
  Thanks, and sorry for all the noize.
  
  /mjt
 
 For the record, I think I would like to see some automated d-i
 non-regression tests implemented before touching busybox in stable.
 
 Spending more time with -release@ stuff those days, but still spending
 some with -boot@, so hopefully we're getting those $some_day.
 
This wheezy update is probably not happening anymore, closing the bug.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: 8.2 and 7.9 planning

[Julien Cristau]

On Tue, Aug 18, 2015 at 19:52:49 +0100, Adam D. Barratt wrote:

 Hi,
 
 We're somewhat overdue for both 8.2 and 7.9 now (in that order). Some
 potential September dates:
 
 5/6th - okay for me
 12/13th - the 12th doesn't work for me until at least mid-afternoon
 19th/20th - looks okay
 26th/27th - looks okay
 
 From a quick chat, it appears that the CD team are okay with us doing
 the two releases back-to-back or on the same weekend, as long as we're
 okay with the media sets being produced at a slight delay, particularly
 for Wheezy; what are others thoughts on that?
 
I'll be away on the 19th/20th.  Doing both on the same day sounds good
to me fwiw.

Cheers,
Julien


signature.asc
Description: Digital signature

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

[Julien Cristau]

On Thu, Aug 13, 2015 at 17:43:59 +0200, Cyril Brulebois wrote:

 Release team, please hint it into testing:
 
   urgent debian-installer/20150813
 
Hint added.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: arch name of ppc64el

[Julien Cristau]

On Sun, Apr 26, 2015 at 20:36:34 +0200, Holger Wansing wrote:

 Hi,
 
 Ben Hutchings b...@decadent.org.uk wrote:
  On Sat, 2015-04-11 at 17:13 +0200, Holger Wansing wrote:
 in build/entities/common.ent there was the name of the architecture
 missing. So what's the exact pronunciation of that arch?
 (for powerpc we have PowerPC for example)
 Is there some special form, or simply ppc64el?
 In Supported hardware Breno has Power Systems as arch name. ???
 The ports page on https://www.debian.org/ports/ lists
 https://wiki.debian.org/ppc64el/ as basic info page for the
 ppc64el port, and there is no mention of Power Systems...
 Also, in Instructions for Netboot installation under preparing
 there is the term PowerLinux machine. 
 This all should be harmonized to one term.
  [...]
  
  Based on
  http://openpowerfoundation.org/technical/technical-resources/technical-specifications/
   I think it's 'PowerPC 64-bit little-endian', or 'PowerISA little-endian'.
  
  However, comparing with the way we've named other architectures, '64-bit
  PowerPC (little-endian)' would be more consistent.
 
 In the Jessie release announcement the name AArch64 was introduced.
 Would that be correct for the d-i manual too?
 Or is it wrong at all?
 
AArch64 is arm64, not ppc64el...

Cheers,
Julien


signature.asc
Description: Digital signature