Processed: tagging 818595, tagging 818591
Processing commands for cont...@bugs.debian.org: > tags 818595 + pending Bug #818595 [s390-dasd] dasd-config: allow users to re-format DASDs in non-expert mode Added tag(s) pending. > tags 818591 + pending Bug #818591 [s390-dasd] control: split and improve dependency handling for disk detection Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 818591: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818591 818595: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818595 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 818592
Processing commands for cont...@bugs.debian.org: > tags 818592 + pending Bug #818592 [s390-zfcp] control: split and improve dependency handling for disk detection Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 818592: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processing of s390-dasd_0.0.36_s390x.changes
s390-dasd_0.0.36_s390x.changes uploaded successfully to localhost along with the files: s390-dasd_0.0.36.dsc s390-dasd_0.0.36.tar.xz s390-dasd_0.0.36_s390x.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org)
Processed: tagging 818586
Processing commands for cont...@bugs.debian.org: > tags 818586 + pending Bug #818586 [hw-detect] disk-detect/control: Improve harddrive detection dependency on s390x Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 818586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818586 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#819867: installation-report: USB-boot fails with Stretch, no GRUB-installation with BTRFS-partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: installation-reports Version: 2.62 Severity: minor Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** - -- Package-specific info: Boot method: local netinstall-image Image version: 2016-03-28, http://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso Date: 2016-04-02, about 12.00 h Machine: KVM with vm-manager Partitions: Filesystem Type 1K-blocks Used Available Use% Mounted on udev devtmpfs500856 0500856 0% /dev tmpfs tmpfs 102076 1732100344 2% /run /dev/vda1 btrfs 6835200 933704 5263640 16% / tmpfs tmpfs 510376 0510376 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 510376 0510376 0% /sys/fs/cgroup tmpfs tmpfs 102076 0102076 0% /run/user/0 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [o] Detect network card:[o] Configure network: [o] Detect CD: [o] Load installer modules: [o] Clock/timezone setup: [o] User/password setup:[o] Detect hard drives: [o] Partition hard drives: [o] Install base system:[o] Install tasks: [o] Install boot loader:[E] Overall install:[E] Comments/Problems: This problem was discussed already at the debian-boot mailing-list in this thread: https://lists.debian.org/debian-boot/2016/03/msg00340.html Today I told myself, it would be a good way of officially opening a ticket for this, to report the installation inside KVM/virt-manager, now here it is. Steve McIntire suggested, I debug this myself, but I think, that really the D-I team needs to do something to fix this for everyone, so I include the verbose output of lsinitramfs [initramfs.txt.gz] and dmesg [dmesg.txt.gz], more info to come, maybe. I did another Stretch installation on a different device on Compact-Flash card in the meantime, that also worked with BTRFS-root, it's actually for trying out LXC1.1 - -- 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="9 (stretch) - installer build 20160328-00:05" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux str-tst 4.4.0-1-amd64 #1 SMP Debian 4.4.6-1 (2016-03-17) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) lspci -knn:Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: Kernel driver in use: ata_piix lspci -knn: Kernel modules: ata_piix, ata_generic lspci -knn: 00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 03) lspci -knn:Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:02.0 VGA compatible controller [0300]: Red Hat, Inc. QXL paravirtual graphic card [1b36:0100] (rev 04) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:03.0 Ethernet controller [0200]: Red Hat, Inc Virtio network device [1af4:1000] lspci -knn: Subsystem: Red Hat, Inc Device [1af4:0001] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:04.0 Audio device [0403]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller [8086:2668] (rev 01) lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: 00:05.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 03) lspci - -knn: Subsystem: Red Hat, Inc Device [1af4:1100] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: Kernel modules: uhci_hcd lspci -knn: 00:05.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2
Processing of s390-zfcp_1.0.2_s390x.changes
s390-zfcp_1.0.2_s390x.changes uploaded successfully to localhost along with the files: s390-zfcp_1.0.2.dsc s390-zfcp_1.0.2.tar.xz s390-zfcp_1.0.2_s390x.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org)
Bug#818586: marked as done (disk-detect/control: Improve harddrive detection dependency on s390x)
Your message dated Sun, 03 Apr 2016 09:51:33 + with message-id and subject line Bug#818586: fixed in hw-detect 1.117 has caused the Debian Bug report #818586, regarding disk-detect/control: Improve harddrive detection dependency on s390x 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.) -- 818586: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818586 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: hw-detect Version: 1.116 Severity: important Tags: d-i On Linux on z Systems, there are two major disk storage environments, the direct-attached storage disk (DASD) and SCSI over Fibre-Channel. There are the s390-dasd and s390-zfcp d-i modules to configure and enable DASDs and FCP devices. Note that on s390x, disks are not available by default to Linux and must be enabled in advance. The s390-dasd and s390-zfcp both provide the harddrive-detection dependency and, thus, each could fulfill the dependency to silenty ignore the other. That behavior does not allow to mix DASDs and SCSI disk on single installation (except you call both manually, for example, in the expert mode). To improve and provide a "guided" flow, I have split the harddrive detection dependency for s390-dasd and s390-zfcp as follows: - s390-dasd provides harddrive-detection-dasd - s390-zfcp provides harddrive-detection-zfcp disk-detect depends on -> harddrive-detection-dasd -> harddrive-detection-zfcp and continues to provide the harddrive-detection. With this split, the guided installation will install disk-detect to solve the harddrive-detection dependency. In turn, disk-detect will then rely on the s390-dasd and s390-zfcp d-i modules to provide DASD and FC-attached SCSI disks. If both modules fail, the user perceives the default disk-detect behavior, for example, users might configure iSCSI. The other nice benefit of this dependency split is the seamlessly enablement of multipath with disk-detect (through preseeding). For s390, multipathing should be always considered when SCSI is used. I probably will extend the s390-zfcp module to set disk-detect's multipath debconf variable for usability. I will attach a patch with changelog when I have received the bug number for report. For s390-dasd and s390-zfcp, I will also open bug reports to implement the dependency chain. Feedback is welcome. Thanks and kind regards, Hendrik -- Hendrik Brueckner brueck...@linux.vnet.ibm.com | IBM Deutschland Research & Development GmbH Linux on z Systems Development| Schoenaicher Str. 220, 71032 Boeblingen --- End Message --- --- Begin Message --- Source: hw-detect Source-Version: 1.117 We believe that the bug you reported is fixed in the latest version of hw-detect, 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 818...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Philipp Kern (supplier of updated hw-detect 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: SHA256 Format: 1.8 Date: Sun, 03 Apr 2016 11:40:24 +0200 Source: hw-detect Binary: hw-detect ethdetect disk-detect driver-injection-disk-detect archdetect Architecture: source s390x all Version: 1.117 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Philipp Kern Description: archdetect - Hardware architecture detector (udeb) disk-detect - Detect disk drives (udeb) driver-injection-disk-detect - Detect OEM driver injection disks (udeb) ethdetect - Detect network hardware and load kernel drivers for it (udeb) hw-detect - Detect hardware and load kernel drivers for it (udeb) Closes: 818586 Changes: hw-detect (1.117) unstable; urgency=medium . * Team upload . [ Hendrik Brueckner ] * Improve and split harddrive detection into DASD and SCSI dependency on s390x (Closes: #818586) Checksums-Sha1: 3d81ab02a1b5263423192de65bf8355a10a38c35 1675 hw-detect_1.117.dsc 7e21821adabbfb94e7265f22c0e70d3d82be2941 181132 hw-detect_1.117.tar.xz 87df8c9d3dd871067653692d581c834b22f1de58 2458 archdetect_1.117_s390x.udeb 8df11234c105fb936ee4a27fc1f0a35d5c442e27 24316 disk-detect_1.117_s390x.udeb e37e76911fec8e73779900aac11aeb9026ab7c
Bug#818595: marked as done (dasd-config: allow users to re-format DASDs in non-expert mode)
Your message dated Sun, 03 Apr 2016 09:52:18 + with message-id and subject line Bug#818595: fixed in s390-dasd 0.0.36 has caused the Debian Bug report #818595, regarding dasd-config: allow users to re-format DASDs in non-expert mode 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.) -- 818595: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818595 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: s390-dasd Version: 0.0.35 Severity: normal Tags: d-i patch Recently, a change lowered the priority of the question to low-level format a DASD. The "low" priority caused the question to be displayed only in the expert mode (unless debconf priority has been manually changed). There are cases where users might want to low-level format a DASD even if it is already formatted. For example, if a DASD uses LDL and the user wants to reformat the DASD as CDL. Thus, increase the priority to "high" to be always displayed in non-expert mode again. Of course, depending on the format status a meaningful default is set. Thanks and kind regards, Hendrik >From 00784c5bbd3a88e2ba6a06a1375a214babbdf540 Mon Sep 17 00:00:00 2001 From: Hendrik Brueckner Date: Wed, 9 Mar 2016 17:35:20 +0100 Subject: [PATCH] dasd-config: allow users to re-format DASDs in non-expert mode Recently, a change lowered the priority of the question to low-level format a DASD. The "low" priority caused the question to be displayed only in the expert mode (unless debconf priority has been manually changed). There are cases where users might want to low-level format a DASD even if it is already formatted. For example, if a DASD uses LDL and the user wants to reformat the DASD as CDL. Thus, increase the priority to "high" to be always displayed in non-expert mode again. Of course, depending on the format status a meaningful default is set. Signed-off-by: Hendrik Brueckner --- dasd-config.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dasd-config.c b/dasd-config.c index 7ff57c7..9978fee 100644 --- a/dasd-config.c +++ b/dasd-config.c @@ -367,7 +367,7 @@ static enum state_wanted format (void) */ debconf_reset (client, template); debconf_subst (client, template, "device", channel_current->name); - ret = my_debconf_input (channel_current->formatted ? "low" : "critical", + ret = my_debconf_input (channel_current->formatted ? "high" : "critical", template, &ptr); if (ret == CMD_GOBACK) -- 2.7.0 --- End Message --- --- Begin Message --- Source: s390-dasd Source-Version: 0.0.36 We believe that the bug you reported is fixed in the latest version of s390-dasd, 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 818...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Philipp Kern (supplier of updated s390-dasd 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: SHA256 Format: 1.8 Date: Sun, 03 Apr 2016 11:19:58 +0200 Source: s390-dasd Binary: s390-dasd Architecture: source s390x Version: 0.0.36 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Philipp Kern Description: s390-dasd - Configure DASD (udeb) Closes: 818591 818595 Changes: s390-dasd (0.0.36) unstable; urgency=medium . [ Hendrik Brueckner ] * Split and improve dependency handling for disk detection and move the module before the disk-detect d-i module (Closes: #818591) * dasd-config: allow users to re-format DASDs in non-expert mode (Closes: #818595) Checksums-Sha1: 5a898948b4b22ada5bea8d258966928e006ddc68 1361 s390-dasd_0.0.36.dsc f54d2628f52716056f91577457f306733a85e269 58596 s390-dasd_0.0.36.tar.xz 3711e644890e9484b526de0005c29bfaf9b645f2 28724 s390-dasd_0.0.36_s390x.udeb Checksums-Sha256: ff6c69812a0ed307ad60f9b337e1f93b0f47cdf1efbd9d2b9ad932f7e5c6168f 1361 s390-dasd_0.0.36.dsc b82f9ae44aa5eb61a088a4a5a41e038a04056e717f81a15398d930fb2a532e40 58596 s390-dasd_0.0.36.tar.xz 4e35713948050bbed07b6d4b375034b30e833edee0dc52c52c5da5d421bf5b37 28724 s390-dasd_0.0.36_s390x.udeb Files: 52d0e0e13824c65e9fd63832a79fb38b 1361 debian-installer
Bug#818592: marked as done (control: split and improve dependency handling for disk detection)
Your message dated Sun, 03 Apr 2016 09:52:23 + with message-id and subject line Bug#818592: fixed in s390-zfcp 1.0.2 has caused the Debian Bug report #818592, regarding control: split and improve dependency handling for disk detection 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.) -- 818592: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818592 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: s390-zfcp Version: 1.0.1 Severity: important Tags: d-i To improve and provide a "guided" flow, split the harddrive detection dependency for s390-dasd and s390-zfcp as follows: - s390-dasd provides harddrive-detection-dasd - s390-zfcp provides harddrive-detection-zfcp The disk-detect package depends on -> harddrive-detection-dasd -> harddrive-detection-zfcp and continues to provide the harddrive-detection. With this split, installation on mixed DASD and SCSI disks are possible. Also move the module before the disk-detect module in the Debian installer menu. See also related Debian Bug #818586 for the disk-detect package. Patch for the control file will follow. Thanks and kind regards, Hendrik --- End Message --- --- Begin Message --- Source: s390-zfcp Source-Version: 1.0.2 We believe that the bug you reported is fixed in the latest version of s390-zfcp, 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 818...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Philipp Kern (supplier of updated s390-zfcp 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: SHA256 Format: 1.8 Date: Sun, 03 Apr 2016 11:34:08 +0200 Source: s390-zfcp Binary: s390-zfcp Architecture: source s390x Version: 1.0.2 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Philipp Kern Description: s390-zfcp - Activate and configure FCP devices for installation (udeb) Closes: 818592 Changes: s390-zfcp (1.0.2) unstable; urgency=medium . [ Hendrik Brueckner ] * Split and improve dependency handling for disk detection and move the module before the disk-detect d-i module (Closes: #818592) Checksums-Sha1: 9e8ea0c55099f7ab3b4300e5055aaff5e8c814b0 1374 s390-zfcp_1.0.2.dsc 9542ac5047334dd10a67aa019001e0d0c0ac78dc 24092 s390-zfcp_1.0.2.tar.xz 79034f2f64e2f76e25d9bae73820ad051c78983e 12340 s390-zfcp_1.0.2_s390x.udeb Checksums-Sha256: e7a7a861d83644e27147b4033a421e43c6b5c71e01ed24ac60a42289987b0a1b 1374 s390-zfcp_1.0.2.dsc 34324173d4f6933e14910622a41f96c2f155fb40cd8716d0ed6d93e3819d830c 24092 s390-zfcp_1.0.2.tar.xz 788a891a26b1b2c38b1a0dde99adcf8b4c9d95c9a7775129211e7f06112a1174 12340 s390-zfcp_1.0.2_s390x.udeb Files: fd3d8bc84f0fee940ee5a4465e51a2fc 1374 debian-installer standard s390-zfcp_1.0.2.dsc b538d3e0d535e2f3cb517ecf3476a4b4 24092 debian-installer standard s390-zfcp_1.0.2.tar.xz 5f1ca6ec924590b54673a29e07c93e62 12340 debian-installer standard s390-zfcp_1.0.2_s390x.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJXAOQlAAoJEERuJUU10FbsYIYH/As99QD0DJea+vNU2xRulBLC zr9DxOY1rJ9epQcYQvDMtnwg1VH94kycPLQh9sKGTVcrePIP+APwDh3TVLH4F5xW ZKJgU94IZT4NccBX2diT88cLfyjSVt/+r/3hYZNvkQK9SDdcVhwWBAuylkgABkHd o94HTnlSF4Xr0szuPXfAwUaxN9UD/2U7za3+yk4L09svHzVWg7aSO7Frj0+JOjnc Z+RJoGBF2fjs2bhJtH3wHyKO/gNaqq2etCJmAS+jryXdxeJCJVXzVC4m3Uo77usv yVDbRnaeW286aErIMz5RgLAImVOPphHZDS6UvjLhJ+PUnfYGewyDbgdZbuEaUmw= =NDhx -END PGP SIGNATURE End Message ---
Bug#818591: marked as done (control: split and improve dependency handling for disk detection)
Your message dated Sun, 03 Apr 2016 09:52:18 + with message-id and subject line Bug#818591: fixed in s390-dasd 0.0.36 has caused the Debian Bug report #818591, regarding control: split and improve dependency handling for disk detection 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.) -- 818591: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818591 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: s390-dasd Version: 0.0.35 Severity: important Tags: d-i To improve and provide a "guided" flow, split the harddrive detection dependency for s390-dasd and s390-zfcp as follows: - s390-dasd provides harddrive-detection-dasd - s390-zfcp provides harddrive-detection-zfcp The disk-detect package depends on -> harddrive-detection-dasd -> harddrive-detection-zfcp and continues to provide the harddrive-detection. With this split, installation on mixed DASD and SCSI disks are possible. Also move the module before the disk-detect module in the Debian installer menu. See also the related Debian bug report #818586 for the disk-detect package. As usual, I will attach a patch with changelog and bug information. Thanks and kind regards, Hendrik --- End Message --- --- Begin Message --- Source: s390-dasd Source-Version: 0.0.36 We believe that the bug you reported is fixed in the latest version of s390-dasd, 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 818...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Philipp Kern (supplier of updated s390-dasd 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: SHA256 Format: 1.8 Date: Sun, 03 Apr 2016 11:19:58 +0200 Source: s390-dasd Binary: s390-dasd Architecture: source s390x Version: 0.0.36 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Philipp Kern Description: s390-dasd - Configure DASD (udeb) Closes: 818591 818595 Changes: s390-dasd (0.0.36) unstable; urgency=medium . [ Hendrik Brueckner ] * Split and improve dependency handling for disk detection and move the module before the disk-detect d-i module (Closes: #818591) * dasd-config: allow users to re-format DASDs in non-expert mode (Closes: #818595) Checksums-Sha1: 5a898948b4b22ada5bea8d258966928e006ddc68 1361 s390-dasd_0.0.36.dsc f54d2628f52716056f91577457f306733a85e269 58596 s390-dasd_0.0.36.tar.xz 3711e644890e9484b526de0005c29bfaf9b645f2 28724 s390-dasd_0.0.36_s390x.udeb Checksums-Sha256: ff6c69812a0ed307ad60f9b337e1f93b0f47cdf1efbd9d2b9ad932f7e5c6168f 1361 s390-dasd_0.0.36.dsc b82f9ae44aa5eb61a088a4a5a41e038a04056e717f81a15398d930fb2a532e40 58596 s390-dasd_0.0.36.tar.xz 4e35713948050bbed07b6d4b375034b30e833edee0dc52c52c5da5d421bf5b37 28724 s390-dasd_0.0.36_s390x.udeb Files: 52d0e0e13824c65e9fd63832a79fb38b 1361 debian-installer standard s390-dasd_0.0.36.dsc c886f589cff65b258140c6713f0b2c17 58596 debian-installer standard s390-dasd_0.0.36.tar.xz ef5e3c33352d27650bebebf6785b86ea 28724 debian-installer standard s390-dasd_0.0.36_s390x.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJXAOMLAAoJEERuJUU10FbsCoUH/inimmj8vkjK9rRx34hibBC9 fBVUYJuyArRF6RaE4MZ8zL7KR581egsm8rRlR80WinaQx6VFLnLlVGhuY+xwxv5/ GotB0d7i2SJ5XQKywG81wxpMxhvS/BfNhYXvCVeeiAlNk0BcWoTmyhKgelH0/Pic Lnq/6QCk6RJyrX+SB5HC2GM3zHNR9iMV05fq2zrxnSJ1TP2MuokYeZ0cVJoor1Bf veFf1hAi+ckt2aSIVLmUtlmIpTV9ZmBZBj7SODZVnQl9+B6re+jAefwcdTrpuqT7 vGXrjQsDNq0LT9N+xUpdsrNnVtnRMXyT/OAxZjfaY48qlCCXZ194VtzIkkB79Hk= =Jlgz -END PGP SIGNATURE End Message ---
Re: Stretch/testing instllable, but not bootable upon installation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 2 Apr 2016 15:40:48 +0100 Steve McIntyre wrote: > On Sat, Apr 02, 2016 at 04:20:27PM +0200, Andreas Glaeser wrote: > > > >now I dd'ed the raw-image, made in vm-manager, onto my USB-stick and tried > >to boot my > >thin-client from it, here is what I saw. > > > >The yellow colour is real, I am not faking this, it's a defective monitor > >cable. > >It does not matter much, my experience so far tells me that because of too > >tight > > > >security-restrictions on Debian-Testing, the image would probably not > >be usable anyway, i.e. no packages or software-updates would be installable, > >but > >it normaly should boot up at least. > > OK, that suggests a missing/not loaded driver for /dev/vda1 - either > missing in the kernel image package (unlikely) or a buggy initramfs > which is missing the driver or hasn't yet loaded it. > > >From the initramfs prompt, you might be able to debug this. What does > lsmod say about loaded modules? Can you load the right module? etc... > To be honest I don't really feel like fiddling with this on Sunday, but I filed an installation-report on the issue (it's minor): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819867 Greetings Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlcA6UQACgkQ5+rBHyUt5wsUnQCgjo1Xl7W4hqZMsZ9yLkHdqAc9 LuwAniF8UCPOQzsPidPJc9MbsKApARsg =LgqJ -END PGP SIGNATURE-
Processing of hw-detect_1.117_s390x.changes
hw-detect_1.117_s390x.changes uploaded successfully to localhost along with the files: hw-detect_1.117.dsc hw-detect_1.117.tar.xz archdetect_1.117_s390x.udeb disk-detect_1.117_s390x.udeb driver-injection-disk-detect_1.117_all.udeb ethdetect_1.117_all.udeb hw-detect_1.117_s390x.udeb Greetings, Your Debian queue daemon (running on host franck.debian.org)
s390-dasd_0.0.36_s390x.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 03 Apr 2016 11:19:58 +0200 Source: s390-dasd Binary: s390-dasd Architecture: source s390x Version: 0.0.36 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Philipp Kern Description: s390-dasd - Configure DASD (udeb) Closes: 818591 818595 Changes: s390-dasd (0.0.36) unstable; urgency=medium . [ Hendrik Brueckner ] * Split and improve dependency handling for disk detection and move the module before the disk-detect d-i module (Closes: #818591) * dasd-config: allow users to re-format DASDs in non-expert mode (Closes: #818595) Checksums-Sha1: 5a898948b4b22ada5bea8d258966928e006ddc68 1361 s390-dasd_0.0.36.dsc f54d2628f52716056f91577457f306733a85e269 58596 s390-dasd_0.0.36.tar.xz 3711e644890e9484b526de0005c29bfaf9b645f2 28724 s390-dasd_0.0.36_s390x.udeb Checksums-Sha256: ff6c69812a0ed307ad60f9b337e1f93b0f47cdf1efbd9d2b9ad932f7e5c6168f 1361 s390-dasd_0.0.36.dsc b82f9ae44aa5eb61a088a4a5a41e038a04056e717f81a15398d930fb2a532e40 58596 s390-dasd_0.0.36.tar.xz 4e35713948050bbed07b6d4b375034b30e833edee0dc52c52c5da5d421bf5b37 28724 s390-dasd_0.0.36_s390x.udeb Files: 52d0e0e13824c65e9fd63832a79fb38b 1361 debian-installer standard s390-dasd_0.0.36.dsc c886f589cff65b258140c6713f0b2c17 58596 debian-installer standard s390-dasd_0.0.36.tar.xz ef5e3c33352d27650bebebf6785b86ea 28724 debian-installer standard s390-dasd_0.0.36_s390x.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJXAOMLAAoJEERuJUU10FbsCoUH/inimmj8vkjK9rRx34hibBC9 fBVUYJuyArRF6RaE4MZ8zL7KR581egsm8rRlR80WinaQx6VFLnLlVGhuY+xwxv5/ GotB0d7i2SJ5XQKywG81wxpMxhvS/BfNhYXvCVeeiAlNk0BcWoTmyhKgelH0/Pic Lnq/6QCk6RJyrX+SB5HC2GM3zHNR9iMV05fq2zrxnSJ1TP2MuokYeZ0cVJoor1Bf veFf1hAi+ckt2aSIVLmUtlmIpTV9ZmBZBj7SODZVnQl9+B6re+jAefwcdTrpuqT7 vGXrjQsDNq0LT9N+xUpdsrNnVtnRMXyT/OAxZjfaY48qlCCXZ194VtzIkkB79Hk= =Jlgz -END PGP SIGNATURE- Thank you for your contribution to Debian.
s390-zfcp_1.0.2_s390x.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 03 Apr 2016 11:34:08 +0200 Source: s390-zfcp Binary: s390-zfcp Architecture: source s390x Version: 1.0.2 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Philipp Kern Description: s390-zfcp - Activate and configure FCP devices for installation (udeb) Closes: 818592 Changes: s390-zfcp (1.0.2) unstable; urgency=medium . [ Hendrik Brueckner ] * Split and improve dependency handling for disk detection and move the module before the disk-detect d-i module (Closes: #818592) Checksums-Sha1: 9e8ea0c55099f7ab3b4300e5055aaff5e8c814b0 1374 s390-zfcp_1.0.2.dsc 9542ac5047334dd10a67aa019001e0d0c0ac78dc 24092 s390-zfcp_1.0.2.tar.xz 79034f2f64e2f76e25d9bae73820ad051c78983e 12340 s390-zfcp_1.0.2_s390x.udeb Checksums-Sha256: e7a7a861d83644e27147b4033a421e43c6b5c71e01ed24ac60a42289987b0a1b 1374 s390-zfcp_1.0.2.dsc 34324173d4f6933e14910622a41f96c2f155fb40cd8716d0ed6d93e3819d830c 24092 s390-zfcp_1.0.2.tar.xz 788a891a26b1b2c38b1a0dde99adcf8b4c9d95c9a7775129211e7f06112a1174 12340 s390-zfcp_1.0.2_s390x.udeb Files: fd3d8bc84f0fee940ee5a4465e51a2fc 1374 debian-installer standard s390-zfcp_1.0.2.dsc b538d3e0d535e2f3cb517ecf3476a4b4 24092 debian-installer standard s390-zfcp_1.0.2.tar.xz 5f1ca6ec924590b54673a29e07c93e62 12340 debian-installer standard s390-zfcp_1.0.2_s390x.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJXAOQlAAoJEERuJUU10FbsYIYH/As99QD0DJea+vNU2xRulBLC zr9DxOY1rJ9epQcYQvDMtnwg1VH94kycPLQh9sKGTVcrePIP+APwDh3TVLH4F5xW ZKJgU94IZT4NccBX2diT88cLfyjSVt/+r/3hYZNvkQK9SDdcVhwWBAuylkgABkHd o94HTnlSF4Xr0szuPXfAwUaxN9UD/2U7za3+yk4L09svHzVWg7aSO7Frj0+JOjnc Z+RJoGBF2fjs2bhJtH3wHyKO/gNaqq2etCJmAS+jryXdxeJCJVXzVC4m3Uo77usv yVDbRnaeW286aErIMz5RgLAImVOPphHZDS6UvjLhJ+PUnfYGewyDbgdZbuEaUmw= =NDhx -END PGP SIGNATURE- Thank you for your contribution to Debian.
hw-detect_1.117_s390x.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 03 Apr 2016 11:40:24 +0200 Source: hw-detect Binary: hw-detect ethdetect disk-detect driver-injection-disk-detect archdetect Architecture: source s390x all Version: 1.117 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Philipp Kern Description: archdetect - Hardware architecture detector (udeb) disk-detect - Detect disk drives (udeb) driver-injection-disk-detect - Detect OEM driver injection disks (udeb) ethdetect - Detect network hardware and load kernel drivers for it (udeb) hw-detect - Detect hardware and load kernel drivers for it (udeb) Closes: 818586 Changes: hw-detect (1.117) unstable; urgency=medium . * Team upload . [ Hendrik Brueckner ] * Improve and split harddrive detection into DASD and SCSI dependency on s390x (Closes: #818586) Checksums-Sha1: 3d81ab02a1b5263423192de65bf8355a10a38c35 1675 hw-detect_1.117.dsc 7e21821adabbfb94e7265f22c0e70d3d82be2941 181132 hw-detect_1.117.tar.xz 87df8c9d3dd871067653692d581c834b22f1de58 2458 archdetect_1.117_s390x.udeb 8df11234c105fb936ee4a27fc1f0a35d5c442e27 24316 disk-detect_1.117_s390x.udeb e37e76911fec8e73779900aac11aeb9026ab7c4f 13494 driver-injection-disk-detect_1.117_all.udeb 92ddc39d04f9202689bfef6cd6b4b0421e06bd21 30922 ethdetect_1.117_all.udeb 1e1da22d903a38f843d0f018604565e74db7cd66 115260 hw-detect_1.117_s390x.udeb Checksums-Sha256: 7101c0f3ea59c35ff5170fa3ff7e35aa45dd5de201450cb251c2fde1dbb5c7b7 1675 hw-detect_1.117.dsc 9f6f281e0eb621bfae7d97294abdb7ea5aedded5dd137104f5b882aaecf39831 181132 hw-detect_1.117.tar.xz 5534ef81b55ddd443e97f403a38ac93b4cf1ac8c3eea16ad9f950267a0da4098 2458 archdetect_1.117_s390x.udeb b617d8166b8b63671db08e6f0b29ab950bb5ec1b5c8fad538b1896ca4d133f77 24316 disk-detect_1.117_s390x.udeb acbd6459037930c46ef89078fa355c0a984495c95773bfe3c0ad88706b095569 13494 driver-injection-disk-detect_1.117_all.udeb 88388e6aa72e90b4af95ecb2a5e5dd5f49071ea891283a52b6709f8c294b8fee 30922 ethdetect_1.117_all.udeb b3170046db83a81c4325af58713c075cf9b6bcc216498c8e41b126eca06cee49 115260 hw-detect_1.117_s390x.udeb Files: 067ebc4726470f48838c477d9f362c59 1675 debian-installer standard hw-detect_1.117.dsc bac871a5ad23bb151ca3f51bd4a3 181132 debian-installer standard hw-detect_1.117.tar.xz 0f8c6d38dd17e965250b9161d533d716 2458 debian-installer standard archdetect_1.117_s390x.udeb 09c653fcaa80e7735875d777082177b5 24316 debian-installer optional disk-detect_1.117_s390x.udeb a8dd0a6abc29a2fbd3098a6f1a906743 13494 debian-installer optional driver-injection-disk-detect_1.117_all.udeb 8c0dbf9f928ebfa9fc2b344c853b32bd 30922 debian-installer optional ethdetect_1.117_all.udeb 9e61aaeaaa06991e938a29dad99f08fc 115260 debian-installer standard hw-detect_1.117_s390x.udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJXAOaDAAoJEERuJUU10FbsiuwH/A70sY+3IeDAiaBVnRQ0YiLg c52Brb5IMExw2vmyEu2dfyMvFcXA+Vn7jkB0n5Tf7aTdIVsJ8iv5kDj8JSHd4B2j d2tqxzWLkClzJOyQgBVBVtwtw4zsUjJ9LW/FU8LH2+asRt7NwuTNW2FqfZdFRmAJ oTju5B+zL7FB0UcjfoG1xBurzQhX090JEQuh6sQVLEVqMwYXDWMA9Dp2PvnQoyDg zVunodtedWQhjqifho42Wo/fn6XdTVZIP1GBRNdOt+/F2vP6rXEszCmdwRQt1plZ QAXJf3X9B5CGDYhKHcxAHYASdVUgmjchEDGCRkXWeufGydP/R4TmTV7AnVJaGOA= =SeKD -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#758116: Every second year we are talking about a proper installer
Andreas Tille writes: > I'd like to attract your attention onto bug #758116 which is requesting > a sensible selection of Blends tasks right from the installer. I have been looking into this a bit and think I have a (compromise) solution. The main problem with tasksel is that it is based on debconf that has a very limited user interface. Basically, it can just show a list where one can select one or more items. This makes it impossible to have a detailed selection of all available blends with all their tasks -- the list would just get far too long: we have currently ~270 tasks in our blends! So, I would propose the following: At installation time, we include for every blend (that wants to be there) one selectable item. Selecting this item will install * the "tasks" package of this blend * all available tasks (or a subset of them? to be discussed) When starting tasksel at run time, the list will then include a list of available tasks for the selected blend(s). To do this technically, we could create a new package with "Priority: important" that just contains the tasks list. This package would then get installed with the base system and available for tasksel at installation time (right?). This way, the blends team would keep control over the included blends and would not need to file a bug against tasksel every time we want to adjust this. Does anyone veto the creation of such a package? We would also need to create an additional metapackage for each blend, containing all its tasks (or a blends defined subset). Such a task would anyway be nice to enable a "one-stop install" with apt, f.e. with "apt install astro-all". This proposed way to present the blends in the Debian installer is very limited for sure - volunteers are definitely welcome here. I'd take it as "better-than-nothing" however. Following the bug, we should decide which blends should be presented there. For a few, it seems obivous to me: * Debian Astro * Debian Med * Debian GIS * Hamradio * Debian EzGo * DebiChem (?) * Debian Games (?) I'd rather not include Debian Science -- I would see no user base for it as a whole (and we can only use a single default install). What about Debian Junior? Debian Multimedia? And there are a few blends, that don't have tasks lists: Debian Design, FreedomBox, DebianParl. And, finally, there is NeuroDebian which I guess could be included, but this would require some input from them. Best regards Ole
Should apt-transport-https be Priority: Important ? (Asking to APT maintainers)
Dear APT maintainers, while discussing the package contents of Debian cloud instances, the question arose if it would make sense to install apt-https-transport on most Debian systems, by setting its priority to "Important". What do you think about this ? I pasted below a summary of the discussion that happened on the debian-cloud mailing list. If there are inacccuracies or if you know other pros or cons, I would be very glad to hear them in any case. Have a nice day, Charles > In brief: > > For a Debian system to use encrypted transport when downloading packages from > an APT mirror that has been appropriately set up, the packages > apt-transport-https and its dependancies must be installed. Would it be a > good > service for our users to install this by default by setting this package's > priority to "Important" ? > > The question can be rephrased as "are the gains high enough compared to the > costs ?" > > Here are the gains: > > - Using HTTPS partially hides information about what a user installs on his > machine. > > - Having HTTPS support by default means that users can switch directly to > HTTPS >anytime they wish: the system is ready, there is nothing to learn (which > package >to install) or to do (get the packages with either APT over HTTP or with >other tools and then install them with dpkg). Note that the use of plain > HTTP >may be mandatory in some environments. > > - We send a message to our users and the world, that we give a high > importance to >the defense of people's privacy. > > Here are limitations to these gains. > > - APT over HTTPS does not fully protect from surveillance, because by >analysing metadata such as the size of the transfers, one may deduce which >packages are being downloaded. Thus, it has been proposed that APT >over HTTPS is not good enough and that APT over TOR should be proposed > instead. > > - Most mirrors are not providing HTTPS yet, thus it is prematurate to enable >HTTPS support by default. (By the way, will the content delivery network >debs.debian.org provide HTTPS support ?) > > - Opinions may widely differ on the impact and appropriateness of driving > technical >choices (installing packages that most people will not use in the short > term) >with political views (defense of privacy). > > And here are the costs. > > - On a system freshly created with debootstrap, installing > apt-transport-https >eats roughly 10 Mo of space. > > - The following other packages are installed: ca-certificates krb5-locales > libcurl3-gnutls >libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 > libldap-2.4-2 libnghttp2-14 >librtmp1 libsasl2-2 libsasl2-modules libsasl2-modules-db libssh2-1 openssl. >This increases the system's complexity. > > Limitations to these costs: > > - Systems where disk space is crucial are or can be constructed by starting > from the >smaller subset of "Required" packages (supported in debootstrap by the > "minbase" option). > > - Systems where disk space costs (like cloud images) are not necessarly > billed at a >granularity where 10 Mo matters. For instance on the Amazon cloud, users > are billed >per Gigabyte, therefore installing apt-transport-https by default would >only cost in case it would cause images sizes to increase to the next > gigabyte. -- Charles Plessy Tsurumi, Kanagawa, Japan
Bug#819883: debootstrap: please make the build reproducible
Source: debootstrap Version: 1.0.80 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: fileordering X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Hi! While working on the "reproducible builds" effort [1], we have noticed that debootstrap could not be built reproducibly. The devices.tar.gz tarball contains devices in unsorted (readdir) order. The attached patch fixes this by telling tar to sort the archive members. Regards, Reiner [1]: https://wiki.debian.org/ReproducibleBuilds diff --git a/Makefile b/Makefile index 1020cbc..07682bc 100644 --- a/Makefile +++ b/Makefile @@ -36,7 +36,7 @@ devices.tar.gz: chown 0:0 dev chmod 755 dev (cd dev && $(MAKEDEV) std ptmx fd consoleonly) - tar --mtime="$(DATE)" -cf - dev | gzip -9n >devices.tar.gz + tar --sort=name --mtime="$(DATE)" -cf - dev | gzip -9n >devices.tar.gz @if [ "$$(tar tvf devices.tar.gz | wc -l)" -lt 2 ]; then \ echo " ** devices.tar.gz is empty!" >&2; \ exit 1; \ diff --git a/debian/control b/debian/control index 46e2b93..40cfbcd 100644 --- a/debian/control +++ b/debian/control @@ -3,7 +3,7 @@ Section: admin Priority: extra Maintainer: Debian Install System Team Uploaders: Junichi Uekawa , Colin Watson , Christian Perrier , Steve McIntyre <93...@debian.org> -Build-Depends: debhelper (>= 9), makedev (>= 2.3.1-69) [linux-any] +Build-Depends: debhelper (>= 9), makedev (>= 2.3.1-69) [linux-any], tar (>= 1.28) Standards-Version: 3.9.6 Vcs-Browser: https://anonscm.debian.org/cgit/d-i/debootstrap.git Vcs-Git: https://anonscm.debian.org/git/d-i/debootstrap.git signature.asc Description: PGP signature
Re: Should apt-transport-https be Priority: Important ? (Asking to APT maintainers)
On Sun, Apr 03, 2016 at 10:27:31PM +0900, Charles Plessy wrote: > Dear APT maintainers, > > while discussing the package contents of Debian cloud instances, the question > arose if it would make sense to install apt-https-transport on most Debian > systems, by setting its priority to "Important". > > What do you think about this ? It makes not much sense security wise and gives you a false sense of security. It actually sort of makes sense though, because people.d.o is only https and there are some repos there, and it's somewhat annyoing to have to install apt-transport-https first. Then again, maybe it should only be standard. In any case, we should first change APT to required (#819719) > > I pasted below a summary of the discussion that happened on the debian-cloud > mailing list. If there are inacccuracies or if you know other pros or cons, I > would be very glad to hear them in any case. > > Have a nice day, > > Charles > > > In brief: > > > > For a Debian system to use encrypted transport wxhen downloading packages > > from > > an APT mirror that has been appropriately set up, the packages > > apt-transport-https and its dependancies must be installed. Would it be a > > good > > service for our users to install this by default by setting this package's > > priority to "Important" ? > > > > The question can be rephrased as "are the gains high enough compared to the > > costs ?" > > > > Here are the gains: > > > > - Using HTTPS partially hides information about what a user installs on > > his machine. > > > > - Having HTTPS support by default means that users can switch directly to > > HTTPS > >anytime they wish: the system is ready, there is nothing to learn (which > > package > >to install) or to do (get the packages with either APT over HTTP or with > >other tools and then install them with dpkg). Note that the use of > > plain HTTP > >may be mandatory in some environments. > > > > - We send a message to our users and the world, that we give a high > > importance to > >the defense of people's privacy. > > > > Here are limitations to these gains. > > > > - APT over HTTPS does not fully protect from surveillance, because by > >analysing metadata such as the size of the transfers, one may deduce > > which > >packages are being downloaded. Thus, it has been proposed that APT > >over HTTPS is not good enough and that APT over TOR should be proposed > > instead. That's correct. It gives you a false sense of security unless you don't upgrade very often and pipelining works, in which case you have all downloads pipelined and the individual sizes cannot be determined. WRT Tor: I will get tor support merged at some point, because I think it is absolutely not acceptable to have a fork of APT's https method in the archive that just adds a few proxy settings. That makes no sense at all security wise. > > > > - Most mirrors are not providing HTTPS yet, thus it is prematurate to > > enable > >HTTPS support by default. (By the way, will the content delivery network > >debs.debian.org provide HTTPS support ?) Most mirrors won't anyway. (a) Almost nobody cares about that. (b) Encryption increases the load (c) You cannot easily distribute your repo using a CDN > > > > And here are the costs. > > > > - On a system freshly created with debootstrap, installing > > apt-transport-https > >eats roughly 10 Mo of space. > > > > - The following other packages are installed: ca-certificates krb5-locales > > libcurl3-gnutls > >libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 > > libldap-2.4-2 libnghttp2-14 > >librtmp1 libsasl2-2 libsasl2-modules libsasl2-modules-db libssh2-1 > > openssl. > >This increases the system's complexity. How does openssl get in there, -https uses libcurl3-gnutls. Is that a Recommends somewhere? I'd think debootstrap would not install those. -- Debian Developer - deb.li/jak | jak-linux.org - free software dev When replying, only quote what is necessary, and write each reply directly below the part(s) it pertains to (`inline'). Thank you.
Bug#803912: [PATCH] Follow partman-auto/disk to reuse the ESP. Closes: #803912
Hi Cyril and Steve,
Any update for this patch?
Regards,
$4
On Tue, Nov 3, 2015 at 3:26 PM, Cyril Brulebois wrote:
> Hi,
>
> Thanks for the report and the patch. I'm explicitly cc-ing Steve and
> debian-efi to get some feedback from them.
>
> Mraw,
> KiBi.
>
> Shih-Yuan Lee (FourDollars) (2015-11-03):
> > ---
> > debian/changelog | 7 +++
> > fstab.d/efi | 37 +
> > 2 files changed, 40 insertions(+), 4 deletions(-)
> >
> > diff --git a/debian/changelog b/debian/changelog
> > index 61b84aa..003cc3e 100644
> > --- a/debian/changelog
> > +++ b/debian/changelog
> > @@ -1,3 +1,10 @@
> > +partman-efi (72) UNRELEASED; urgency=medium
> > +
> > + [ Shih-Yuan Lee (FourDollars) ]
> > + * Follow partman-auto/disk to reuse the ESP. Closes: #803912
> > +
> > + -- Shih-Yuan Lee (FourDollars) Tue, 03 Nov
> 2015 14:00:26 +0800
> > +
> > partman-efi (71) unstable; urgency=medium
> >
> >[ Updated translations ]
> > diff --git a/fstab.d/efi b/fstab.d/efi
> > index 14b6696..9906f24 100755
> > --- a/fstab.d/efi
> > +++ b/fstab.d/efi
> > @@ -12,19 +12,48 @@ case $ARCH in
> > ;;
> > esac
> >
> > -seen_efi=
> > +paths=
> > for dev in $DEVICES/*; do
> > [ -d $dev ] || continue
> > cd $dev
> > open_dialog PARTITIONS
> > while { read_line num id size type fs path name; [ "$id" ]; }; do
> > - [ -z "$seen_efi" ] || continue
> > [ $fs != free ] || continue
> > [ -f "$id/method" ] || continue
> > method=$(cat $id/method)
> > [ "$method" = efi ] || continue
> > - echo "$path" /boot/efi vfat umask=0077 0 1
> > - seen_efi=1
> > + if [ -z "$paths" ]; then
> > + paths="$path"
> > + else
> > + paths="$paths $path"
> > + fi
> > done
> > close_dialog
> > done
> > +
> > +if [ -z "$paths" ]; then
> > + exit 0
> > +fi
> > +
> > +# Use any autopartition disk that has been set
> > +if db_get partman-auto/disk && [ "$RET" ]; then
> > + disks="$RET"
> > + seen_efi=
> > + for disk in $disks; do
> > + for path in $paths; do
> > + case "$path" in
> > + $disk*)
> > + echo "$path" /boot/efi vfat
> umask=0077 0 1
> > + seen_efi=1
> > + break
> > + ;;
> > + esac
> > + done
> > + [ -z "$seen_efi" ] || break
> > + done
> > +else
> > + for path in $paths; do
> > + echo "$path" /boot/efi vfat umask=0077 0 1
> > + break
> > + done
> > +fi
> > --
> > 1.9.1
> >
> >
> Mraw,
> KiBi.
>
Re: Should apt-transport-https be Priority: Important ? (Asking to APT maintainers)
* Julian Andres Klode , 2016-04-03, 18:00: The following other packages are installed: ca-certificates krb5-locales libcurl3-gnutls libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libldap-2.4-2 libnghttp2-14 librtmp1 libsasl2-2 libsasl2-modules libsasl2-modules-db libssh2-1 openssl. This increases the system's complexity. How does openssl get in there, -https uses libcurl3-gnutls. Is that a Recommends somewhere? libcurl3-gnutls recommends ca-certificates, which depends on openssl. See bug #407550. -- Jakub Wilk
Re: aptitude and apt-get to apt
Hi, Simon Quigley wrote: > Attached is a patch for the Installation Guide. > > Aptitude is not used a lot in the guide already, and apt comes > preinstalled in a Debian system. I also converted apt-get to apt in that > file. > > Let me know if you have any questions. Thanks for the patch! I found some more occurences of apt and aptitude. See patch. I will commit it shortly, if noone objects. Thanks Holger -- Created with Sylpheed 3.5.0 under D E B I A N L I N U X 8 . 0 " J E S S I E " . Registered Linux User #311290 - https://linuxcounter.net/ Index: en/appendix/chroot-install.xml === --- en/appendix/chroot-install.xml (Revision 70187) +++ en/appendix/chroot-install.xml (Arbeitskopie) @@ -238,7 +238,7 @@ install the makedev package, and create a default set of static device files using (after chrooting) -# apt-get install makedev +# apt install makedev # mount none /proc -t proc # cd /dev # MAKEDEV generic @@ -468,7 +468,7 @@ deb-src http://security.debian.org/ &releasename;/updates main -Make sure to run aptitude update after you have +Make sure to run apt update after you have made changes to the sources list. @@ -483,7 +483,7 @@ and configure it. Currently the use of UTF-8 locales is recommended. -# aptitude install locales +# apt install locales # dpkg-reconfigure locales @@ -490,7 +490,7 @@ To configure your keyboard (if needed): -# aptitude install console-setup +# apt install console-setup # dpkg-reconfigure keyboard-configuration @@ -511,7 +511,7 @@ and a boot loader. Identify available pre-packaged kernels with: -# apt-cache search &kernelpackage; +# apt search &kernelpackage; @@ -519,7 +519,7 @@ Then install the kernel package of your choice using its package name. -# aptitude install &kernelpackage;-arch-etc +# apt install &kernelpackage;-arch-etc @@ -531,8 +531,8 @@ To make your &debian-gnu; system bootable, set up your boot loader to load the installed kernel with your new root partition. Note that -debootstrap does not install a boot loader, though you -can use aptitude inside your &debian; chroot to do so. +debootstrap does not install a boot loader, but you +can use apt inside your &debian; chroot to do so. @@ -551,7 +551,7 @@ Installing and setting up grub2 is as easy as: -# aptitude install grub-pc +# apt install grub-pc # grub-install /dev/sda # update-grub @@ -621,7 +621,7 @@ SSH and set up access. -# aptitude install ssh +# apt install ssh @@ -669,7 +669,7 @@ # tasksel install standard -Of course, you can also just use aptitude to install +Of course, you can also just use apt to install packages individually. @@ -679,7 +679,7 @@ diskspace by running: -# aptitude clean +# apt clean Index: en/boot-installer/trouble.xml === --- en/boot-installer/trouble.xml (Revision 70187) +++ en/boot-installer/trouble.xml (Arbeitskopie) @@ -549,7 +549,7 @@ If you have a working &debian; system, the easiest way to send an installation report is to install the installation-report and reportbug packages -(aptitude install installation-report reportbug), +(apt install installation-report reportbug), configure reportbug as explained in , and run the command reportbug installation-reports. Index: en/howto/installation-howto.xml === --- en/howto/installation-howto.xml (Revision 70187) +++ en/howto/installation-howto.xml (Arbeitskopie) @@ -338,7 +338,7 @@ If you successfully managed an installation with &d-i;, please take time to provide us with a report. The simplest way to do so is to install the reportbug package -(aptitude install reportbug), configure +(apt install reportbug), configure reportbug as explained in , and run reportbug installation-reports. Index: en/post-install/orientation.xml === --- en/post-install/orientation.xml (Revision 70187) +++ en/post-install/orientation.xml (Arbeitskopie) @@ -59,7 +59,7 @@ One of the best installation methods is apt. You can use the command -line version apt-get or full-screen text version +line version of apt or full-screen text version aptitude. Note apt will also let you merge main, contrib, and non-free so you can have export-restricted packages as well as standard versions. Index: en/preparing/bios-setup/powerpc.xml === --- en/preparing/bios-setup/powerpc.xml (Revision 70187) +++ en/preparing/bios-setup/powerpc.xml (Arbeitskopie) @@ -170,11 +170,11 @@ The package qemu-slof is, in fact, a dependency of package qemu-system-ppc (which also provides the virtual package
Re: aptitude and apt-get to apt
> I found some more occurences of apt and aptitude. > See patch. Awesome! No objections from me! :) Simon Quigley tsimo...@ubuntu.com tsimonq2 on Freenode, OFTC
