Bug#980782: Info received (Bug#980782: Acknowledgement (os-prober: linux-boot-prober returning "root=/dev/dm-X" line instead of expected "root=UUID=[UUID128]))
Mirko Vogt writes: > Looking at /usr/share/initramfs-tools/scripts/local-top/lvm2 more > closely, passing a UUID also wouldn't trigger a `vgchange -ay` here. > But a path like /dev/mapper/X would. > So maybe the question is rather: how to make os-prober return a > "root=/dev/mapper/X" line instead of one containing a UUID(?) The first thing that comes to mind is: For a given UUID run blkid, and exclude all lines that do not match the UUID count lines and error if there are duplicates (it probably already does this, and I think the risk of collisions most significant for short UUIDs like FAT has) as part of that regex, check for ^/dev/mapper, with that anchor use /dev/mapper/X for the truly unique UUID Cheers, Nicholas signature.asc Description: PGP signature
partman-btrfs_53_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 22 Jan 2021 05:35:51 +0100 Source: partman-btrfs Architecture: source Version: 53 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Cyril Brulebois Closes: 964818 Changes: partman-btrfs (53) unstable; urgency=medium . [ Nicholas D Steeves ] * Add minimal subvolume support for /. The btrfs volume designated as the device used for "/" is now configured to use the "@rootfs" subvolume. This subvolume name was chosen as a compromise between the two primary conventions in btrfs default subvolume naming. Installing the rootfs to a subvolume allows update-grub to correctly generate the "rootflags=subvol=@rootfs" needed to boot from a subvolume, and other subvolumes may be created as needed. The creation of other commonly used subvolumes such as "@home" has not been hard-coded, because a user may choose to locate /home on another device--possibly even on another file system. This change unblocks development of btrfs boot environments, which most other major operating systems have supported for quite some time (Closes: #964818). * Migrate to debhelper-compat 13. * Assert Rules-Requires-Root: no. * Add myself to Uploaders. Checksums-Sha1: b244e3604374e88b488b29bc02efc96789b5ae9d 1682 partman-btrfs_53.dsc 1e4a25f39ad6ef126d1279cd30496addd99d6adc 47260 partman-btrfs_53.tar.xz 95672a6f7c03d4524a451bcf3cbdaf4dc9e9e3b2 5479 partman-btrfs_53_source.buildinfo Checksums-Sha256: df6c3f5af927595dd09e206c3a4a78aa3f4f2a0557bb68e956011e6bf515b6d5 1682 partman-btrfs_53.dsc 010b81a5f6cb2ac51e261b4f924f6adb5a6a4daae09621cb777d8e5d6d85e3fc 47260 partman-btrfs_53.tar.xz 74f4af72e15928b2c283b0088a46997d043b30e067c2d092e47f9368dffe8e2f 5479 partman-btrfs_53_source.buildinfo Files: dec3d4b785cfe364d3d347a67fb45f8d 1682 debian-installer standard partman-btrfs_53.dsc 02b370b2e7cb05594335cc0ce16e4e78 47260 debian-installer standard partman-btrfs_53.tar.xz 14749f8fa20d6109dd8d090581c44da8 5479 debian-installer standard partman-btrfs_53_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmAKVm8ACgkQ/5FK8MKz VSCI1A/9EMNLJkjODy7MwFduxR4SMuMjo3C4x6yYt5usQRM/xWAbAN0z9ESWYOJd Dn14z3ZRit0MMrKfPH5bqs3xcoy1QFFK/9/KcgHoKaax26TanIUsK5n/frZNfAPg ECqPwsynBdBTqgrhPIS90ueLQ8Hv89bzzH9CrSpOTlQy1ajAtEyGyJ5flzQo1vC7 l8yGPrFOIs9flBCwdYXmli4t+LHaCU42Qk/5cRGUwbyfxtaGA0s8lYVOGeO8UikJ 7IdB4bI7irvh7aGyLDu2gsWTkcshgXFxAeuSUkLcHwamatrRe04AjoRqrGyEQQZZ tGC/7Ghu/llwkuR8BDB05embBKa50BfT6HNb1QSHFPXoxNuDmHOcY7yUrczz nl2dYNx6dpMXFvzrOnoRskZzBiHcmFg1i3ETXWOObUzuE/lJJDXaI2drpq7cR/7O 8Kh1CBsZXt/aLWnK4LpOnZQJWj0I2IpNJjPtHAR8O8vpusWaqFl4XiJbV6T8p/pR Q6ifQxYPs3hnI7mrSn+XkoLP9RxVF458pG2FXR7x3LZPU8+GIxGpaNAfHZ3etPWt Xmd1L+nL8PbkxyGHPmAVF/2R3n+OzEsjgNAxOYzD34w3CVaO5IBJNtA7eyi7Qoi4 pd5YiEckWoqJqpfbH8kdPgl5jvkYeNNcFeqXdluqTXJtasun8ME= =L0Em -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of partman-btrfs_53_source.changes
partman-btrfs_53_source.changes uploaded successfully to localhost along with the files: partman-btrfs_53.dsc partman-btrfs_53.tar.xz partman-btrfs_53_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#964818: marked as done (Enable basic subvolume management for rootfs)
Your message dated Fri, 22 Jan 2021 04:48:43 + with message-id and subject line Bug#964818: fixed in partman-btrfs 53 has caused the Debian Bug report #964818, regarding Enable basic subvolume management for rootfs to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 964818: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964818 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: partman-btrfs Version: 50 Severity: normal Control: patch -1 Control: block 840248 by -1 https://salsa.debian.org/installer-team/partman-btrfs/-/merge_requests/1 I have tested the proposed changes and confirmed that they produce the desired change. Briefly, the problem: Installing Debian directly to subvolid 5 rather than to a "rootfs" (like Fedora) or "@" (like SUSE and Ubuntu) subvolume causes the following problems: 1. It makes it unreasonably difficult to move to a flat subvolume structure 2. It means that any snapshots of the rootfs creates a nested subvolume rather than flat subvolume structure. 3. It blocks development of "Boot Environments" (consult the web for how these are used in Solaris and FreeBSD and how these would be useful in Debian). 4. It blocks the ability to stage a system upgrade in a @rootfs-sid or @rootfs-stable+1 subvolume and then pivot into this during a reboot; this is an example of how "boot environments" are useful. There is precedent in Ubuntu for using a non-configurable method (they additionally add a "@home" subvolume), and the Ubuntu installer does not offer user configurability of subvolumes during installation. My plan is thus: 1. After we have installation to subvolumes, add subvolume listing support to the rescue cd. This has the side-effect of being able to test "boot environments" from the rescue cd. 2. Activate boot environment support via grub-btrfs (#941627). 3. Long-term: add debian-installer support for user-configurable subvolume layout like Fedora and OpenSUSE have. Ideally I'd like to work on this as part of a btrfs-enablement team Thanks, Nicholas CCing Cyril for Kibi ACK :-) --- End Message --- --- Begin Message --- Source: partman-btrfs Source-Version: 53 Done: Cyril Brulebois We believe that the bug you reported is fixed in the latest version of partman-btrfs, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 964...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Cyril Brulebois (supplier of updated partman-btrfs package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 22 Jan 2021 05:35:51 +0100 Source: partman-btrfs Architecture: source Version: 53 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Cyril Brulebois Closes: 964818 Changes: partman-btrfs (53) unstable; urgency=medium . [ Nicholas D Steeves ] * Add minimal subvolume support for /. The btrfs volume designated as the device used for "/" is now configured to use the "@rootfs" subvolume. This subvolume name was chosen as a compromise between the two primary conventions in btrfs default subvolume naming. Installing the rootfs to a subvolume allows update-grub to correctly generate the "rootflags=subvol=@rootfs" needed to boot from a subvolume, and other subvolumes may be created as needed. The creation of other commonly used subvolumes such as "@home" has not been hard-coded, because a user may choose to locate /home on another device--possibly even on another file system. This change unblocks development of btrfs boot environments, which most other major operating systems have supported for quite some time (Closes: #964818). * Migrate to debhelper-compat 13. * Assert Rules-Requires-Root: no. * Add myself to Uploaders. Checksums-Sha1: b244e3604374e88b488b29bc02efc96789b5ae9d 1682 partman-btrfs_53.dsc 1e4a25f39ad6ef126d1279cd30496addd99d6adc 47260 partman-btrfs_53.tar.xz 95672a6f7c03d4524a451bcf3cbdaf4dc9e9e3b2 5479 partman-btrfs_53_source.buildinfo Checksums-Sha256: df6c3f5af927595dd09e206c3a4a78aa3f4f2a0557bb68e956011e6bf515b6d5 1682 partman-btrfs_53.dsc
Bug#980782: Info received (Bug#980782: Acknowledgement (os-prober: linux-boot-prober returning "root=/dev/dm-X" line instead of expected "root=UUID=[UUID128]))
Looking at /usr/share/initramfs-tools/scripts/local-top/lvm2 more closely, passing a UUID also wouldn't trigger a `vgchange -ay` here. But a path like /dev/mapper/X would. So maybe the question is rather: how to make os-prober return a "root=/dev/mapper/X" line instead of one containing a UUID(?)
Bug#980782: Acknowledgement (os-prober: linux-boot-prober returning "root=/dev/dm-X" line instead of expected "root=UUID=[UUID128])
Just adding, this isn't only a feature request but results in
non-bootable systems.
If one of the os-probe'd systems e.g. is also a Debian, it will drop
into an initramfs due to not finding the root device.
This is due to - within the initramfs - the VGs as part of the the LVM
system only get activated by certain naming schemes
("/usr/share/initramfs-tools/scripts/local-top/lvm2").
It tries ti figure out whether the rootfs resides on a LVM and if it
thinks it doesn't, the respective VG won't be activated, resulting in
the passed /dev/dm-X block device not being available.
[Attn Zinoviev] I'd like to adopt partman-btrfs
Hi, 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? Regards, Nicholas signature.asc Description: PGP signature
Bug#980782: os-prober: linux-boot-prober returning "root=/dev/dm-X" line instead of expected "root=UUID=[UUID128]
Package: os-prober Version: 1.77 Severity: important I noticed when running update-grub on Debian stable and testing, that the resulting grub.cfg has lines as part of menuentres like: "linux [..] root=/dev/dm-X" for found linux installations on other block devices - in my case residing on LVs - ,instead of "root=UUID=[XXX]", which I'd have expected (and would favour). This is due to `linux-boot-prober` calling `mapdevfs` defined in "/usr/share/os-prober/common.sh". `mapdevfs` does a simple `readlink` on the path given. The other lines within the menuentry look fine, e.g.: "set root='lvmid/XX/YY'" or "search [..] --set=root [UUID]" GRUB_DISABLE_LINUX_UUID is undefined. Is this intentional and if so, why? -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages os-prober depends on: ii grub-common 2.04-12 ii libc62.31-9 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information
Bug#980777: FIT-PC: Fails to find driver for Ethernet, Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI
Package: installation-reports Severity: normal X-Debbugs-Cc: charlescur...@charlescurley.com Dear Maintainer, Please see Comments/Problems below. -- Package-specific info: Boot method: DVD Image version: debian-bullseye-DI-alpha3-i386-DVD-1.iso Date: Jan 20 2021 16:36 MST Machine: FIT-PC 1 https://en.wikipedia.org/wiki/Fit-PC#fit-PC_1.0 Partitions: root@white:~# df -Tl Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 108M 0 108M 0% /dev tmpfs tmpfs 23M 560K 22M 3% /run /dev/sda6 ext2 55G 1.1G 51G 3% / tmpfs tmpfs 111M 0 111M 0% /dev/shm tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs tmpfs 4.0M 0 4.0M 0% /sys/fs/cgroup /dev/sda1 ext2 236M 20M 204M 9% /boot tmpfs tmpfs 23M 0 23M 0% /run/user/0 /dev/sdb vfat 1.4M 209K 1.2M 15% /media/disk /dev/sdc1 vfat 2.0G 1.2G 748M 62% /mnt root@white:~# fdisk -l /dev/sda Disk /dev/sda: 55.89 GiB, 60011642880 bytes, 117210240 sectors Disk model: Hitachi HTS54166 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: dos Disk identifier: 0x0005c92c Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048499711497664 243M 83 Linux /dev/sda2501758 117209087 116707330 55.7G 5 Extended /dev/sda5501760 1445887944128 461M 82 Linux swap / Solaris /dev/sda6 1447936 117209087 115761152 55.2G 83 Linux root@white:~# Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [ ] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [ ] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Install tasks: [ ] Install boot loader:[O] Overall install:[ ] Comments/Problems: I own three FIT-PC 1s, two of which provide network services. https://en.wikipedia.org/wiki/Fit-PC#fit-PC_1.0 I'd like to keep them running for a few more years yet. So I tried the alpha 3 installer. In the process, I hit several problems. * The NIC finding software failed to detect the two NICs. This has worked in the past. * When I tried to select the driver manually, I was given a list of two NICs, neither one of them appropriate. On other hardware, a much longer list, including the ones I need (8139.*), appears. * When I tried to read the drivers from a USB floppy device, the software did not find the floppy. This, in spite of the fact that I could mount the floppy manually and read the preseed file from it. The floppy drive should be /dev/sdb or sdc, depending on what else I have on the USB bus. * When putting file systems on the hard drive, ext4 and ext3 were absent from the menu of possible file systems. ext2 was there, and that's what I selected and got. Is something eating my menus? The first two problems are not new. I got the same with a Buster 10.4 netinst CD. I then fell back to a Debian 8.6 netinst CD. That correctly found and set up the two NICs. Just in case I had hardware issues, I have tried this on two machines, one of which has been in continuous service since I bought them. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20201202" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux (none) 5.9.0-4-686 #1 SMP Debian 5.9.11-1 (2020-11-27) i586 GNU/Linux lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] (rev 33) lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] lspci -knn: 00:01.1 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD] Geode LX Video [1022:2081] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Geode LX Video [1022:2081] lspci -knn: 00:01.2 Entertainment encryption device [1010]: Advanced Micro Devices, Inc. [AMD] Geode LX AES Security Block [1022:2082] lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Geode LX AES Security Block [1022:2082] lspci -knn: Kernel modules: geode_rng lspci -knn: 00:0d.0 Ethernet controller [0200]:
rootskel-gtk uploads
Hi Jonathan, I just noticed that the latest 2 uploads of rootskel-gtk - done by you - are lacking commits resp. tags in git (?). That's https://tracker.debian.org/news/1022142/accepted-rootskel-gtk-141-source-amd64-into-unstable/ from 01-2019 - no tag set and https://tracker.debian.org/news/1203158/accepted-rootskel-gtk-142-source-into-unstable/ from 12-2020 - no commits for performed changes and no tag Or am I missing something here? Regards, stay save Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#980271: #980271 installation-reports: Toshiba Tecra 8000 Installation report Bullseye
Control: reassign -1 pcmciautils Control: tags -1 + patch Charles Curley wrote: > I tried a Xircom CreditCard Ethernet adapter, CE38-100BTX, which uses > the xirc2ps_cs driver. It runs, if slowly, on an installed system. But > on installation, the software fails to detect it also. > > I noticed in the log on console F4 a message: > > pcmcia-socket-startup: chdir to /etc/pcmcia failed: no such file or > directory. > > Possibly this is because the directory actually is /etc/pcmciautils on > the installer. It is /etc/pcmcia on the installed system. > > I then made a symlink, rmmod yenta_socket, modprobe yenta_socket. > Messages indicate that yenta_socket picked up the configuration file. > > I then inserted the card. Messages indicate that the card was detected > and set up. I then went back to the installatio software, had it detect > the network. It detected it correctly, and auto-configuration worked > correctly. I have verified that on a current testing installation system, there is still /etc/pcmciautils/ existing, and no /etc/pcmcia/. So re-assigning to pcmciautils package. Also, I attached a patch, which should hopefully fix this for the udeb. Thanks Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 diff --git a/debian/changelog b/debian/changelog index 44560d6..0c86fc6 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +pcmciautils (018-13) UNRELEASED; urgency=medium + + * Update /etc/pcmciautils/ dir to /etc/pcmcia/ in udeb. + + -- Holger Wansing Thu, 21 Jan 2021 18:17:41 +0100 + pcmciautils (018-12) unstable; urgency=medium [ Bor GroÅ¡elj SimiÄ ] diff --git a/debian/pcmciautils-udeb.install b/debian/pcmciautils-udeb.install index 6e4bf21..2010958 100644 --- a/debian/pcmciautils-udeb.install +++ b/debian/pcmciautils-udeb.install @@ -1,2 +1,2 @@ lib/udev lib/ -usr/lib/pcmciautils/config.opts etc/pcmciautils/ +usr/lib/pcmciautils/config.opts etc/pcmcia/
Re: Bug#959469: buster-pu: package openssl/1.1.1g-1
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? Once the openssl pu is acked I would open a pu for m2crypto. Or should it be done now? (just asking). > Kurt Sebastian
Bug#980528: debian-installer: net-install impossible because link is always reset
Not noticing humor, is no proof for the absence of humor. On Thu, Jan 21, 2021 at 04:40:14PM +, etkaar wrote: > Good evening, > > after some testing it seems that I am just a very stupid person. Mmm, one of my motivators for working on libre software projects is collaborating with smart people. I'm willing to lower the bar to "people who can think for themselfs" After all is the idea of "I could be stupid" just brilant. > The reason, why the interface is always down is - after I had a look > into the source code of netcfg - that is simply fails *and*, before > it fails, netcfg would always reset the link, remove any routes and > ip addresses. At least that is what I assume. > > But why can I manually configure the network? Because I used the onlink flag: > > # ip link set ens1 up > # ip addr add 255.255.8.243/29 dev ens1 > # ip route add default via 255.255.8.1 dev ens1 >>>onlink<<< > > "onlink: pretend that the nexthop is directly attached to this link, > even if it does not match any interface prefix." > https://linux.die.net/man/8/ip > > The /29 subnet actually does not exist on the host; in reality, > it is a /24 subnet. While /etc/network/interfaces in the installed > Debian system itself would be aware of whatever it is aware of - I > just don't know - and automatically will configure the route using the > onlink tag, in the debian installer that is not possible. It seems the > only correct way would have been to configure the network with the /24 > notation and the according 255.255.255.0 netmask, which makes sense, > because working with a /29 notation using MacVTap and VEPA does not > make much sense for me if the subnet is configured as /24 on the host. "netmask" is a layer 3 thingy. My gutfeeling says the problem is at layer 2, where "link" happens. > However, I am not well-educated when it comes to networking at all. I > think my assumptions are right, but if the debian installer should > be aware of that (like the final Debian installation is), we should > leave that issue open. Message for those who encounter simular problem: Please express your observations. My observation: An address like _._.8.1 is never in same network as _._.8.243/29 Regards Geert Stappers -- Silence is hard to parse
Re: RFC: raising ca-certificates package Priority to standard or important
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. signature.asc Description: PGP signature
Processed: Re: #980271 installation-reports: Toshiba Tecra 8000 Installation report Bullseye
Processing control commands: > reassign -1 pcmciautils Bug #980271 [installation-reports] installation-reports: Toshiba Tecra 8000 Installation report Bullseye Bug reassigned from package 'installation-reports' to 'pcmciautils'. Ignoring request to alter found versions of bug #980271 to the same values previously set Ignoring request to alter fixed versions of bug #980271 to the same values previously set > tags -1 + patch Bug #980271 [pcmciautils] installation-reports: Toshiba Tecra 8000 Installation report Bullseye Added tag(s) patch. -- 980271: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980271 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: RFC: raising ca-certificates package Priority to standard or important
On Jan 21, Julien Cristau wrote: > 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 Good idea: I think that "standard" is appropriate. -- ciao, Marco signature.asc Description: PGP signature
RFC: raising ca-certificates package Priority to standard or important
[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
