Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
On Thu, 2021-01-21 at 21:06 +0100, Sebastian Andrzej Siewior wrote:
> On 2021-01-16 19:14:53 [+0100], Kurt Roeckx wrote:
> > So I went over the open issues and pull requests, and currently
> > don't see a reason not to upload it to unstable with those 2
> > patches. I don't know about any other regressions in 1.1.1.
>
> The openssl package migrated to testing.
> I would prepare the pu package for Buster. Should I post here the
> complete diff or an incremental containing only the new patches?
Both would be good, please.
FWIW we're also fighting the clock (yet) again, as we're now a week
away from the freeze for the 10.8 point release. ("Yay"!)
> Once the openssl pu is acked I would open a pu for m2crypto. Or
> should it be done now? (just asking).
Assuming that a patched m2crypto will also build fine against openssl
1.1.1d, then there's no reason that the two shouldn't proceed in
parallel (i.e. feel free to file the m2crypto request already).
Regards,
Adam
Re: RFC: raising ca-certificates package Priority to standard or important
https://www.eff.org/https-everywhere https is getting everywhere. If you don't have ca's you cannot process them properly. I think https working is going to be important even for almost all embedded cases. Most iot deployments include something like calling the mothership, which ought to be https... apt is generally https. I guess priority-wise it should be considered part of TLS or libSSL so that whenever one of those is installed, the ca's are also installed. Again... omitting TLS makes something so crippled as to be next to useless... it's like omitting networking entirely at this point. On Fri, Jan 22, 2021 at 6:38 AM Steve McIntyre wrote: > Hey Julien, > > On Fri, Jan 22, 2021 at 12:00:56PM +0100, Julien Cristau wrote: > >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. > > Sounds like good logic to me. > > Thanks for looking into this! > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > Can't keep my eyes from the circling sky, > Tongue-tied & twisted, Just an earth-bound misfit, I... > >
Bug#980797: debian-installer: root fs very small when choosing a desktop environemnt
Package: debian-installer Version: 20201202 Severity: normal X-Debbugs-Cc: andreas.schla...@sbg.at I just had installed latest debian 11 testing (20210221) with default fs layout (see below). Additional to the default SW I choosed GNOME desktop environment. Now after the first start, I'm already getting a warning "low disk space on /" In my opinion, the question about installed software should be asked before running the partitioner, so it can calculate the size of the filesystems properly. Here the actual output of df -h: Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf udev 468M 0 468M0% /dev tmpfs 99M2,6M 96M3% /run /dev/mapper/rootvg-root 4,0G3,6G 164M 96% / tmpfs491M 0 491M0% /dev/shm tmpfs5,0M4,0K 5,0M1% /run/lock /dev/vda1472M 58M 391M 13% /boot /dev/mapper/rootvg-var 1,6G323M 1,2G 22% /var /dev/mapper/rootvg-home 13G 54M 12G1% /home /dev/mapper/rootvg-tmp 345M2,1M 321M1% /tmp tmpfs 99M 48K 99M1% /run/user/0 tmpfs 99M120K 99M1% /run/user/1000 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/2 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:de Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: [Attn Zinoviev] I'd like to adopt partman-btrfs
On Thu, Jan 21, 2021 at 11:24:35PM -0500, Nicholas D Steeves wrote: > > I noticed there's been no active development on partman-btrfs since > 2016, and I've had an MR open for over a year > > https://salsa.debian.org/installer-team/partman-btrfs/-/merge_requests/1 > > Does anyone have any objections to me adopting it? Anton? I believe partman-btrfs is maintained by the whole d-i team and my name there is for historical reasons. So, go ahead. Anton Zinoviev
Re: RFC: raising ca-certificates package Priority to standard or important
Hey Julien, On Fri, Jan 22, 2021 at 12:00:56PM +0100, Julien Cristau wrote: >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. Sounds like good logic to me. Thanks for looking into this! -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: RFC: raising ca-certificates package Priority to standard or important
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
