Bug#996934: install failure without /etc/flash-kernel/machine pre-existing
Package: flash-kernel Version: 3.104 Severity: normal I have some image building scripts that installed flash-kernel in a chroot (on unrelated hardware; user mode qemu), then configured /etc/flash-kernel/machine, then ran flash-kernel. That used to work (in 2018), and now fails: Creating config file /etc/default/flash-kernel with new version Setting up flash-kernel (3.104) ... Processing triggers for libc-bin (2.32-4) ... Processing triggers for initramfs-tools (0.140) ... Warning: root device does not exist Unsupported platform ''. run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1 dpkg: error processing package initramfs-tools (--configure): installed initramfs-tools package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: initramfs-tools This left initramfs-tools half-configured, and apt-get install flash-kernel exited nonzero. It seems unreasonable for installing the flash-kernel package to leave the system in this state when a file that is only documented in that package does not exist before the package is installed. Also "Unsupported platform ''" is not the best error message. -- see shy jo signature.asc Description: PGP signature
Bug#939071: 6.4 Load Missing Firmware should mention unpacking zip/tar
Source: installation-guide Severity: normal I recently had cause to re-read https://www.debian.org/releases/buster/amd64/ch06s04.en.html and tried to follow the instructions, and I ended up with a firmware.zip on a FAT filesystem, which d-i is not able to find firmware in. The instructions assume that the user will unpack the zip or tarball they download, but they don't say to do so. There's an implicit assumption that the user won't consider firmware.zip to be a firmware file. Also that the user knows how to extract zip files or tarballs or what any of these file types are. I guess if I got it wrong, plenty of other users will get it wrong. -- see shy jo signature.asc Description: PGP signature
Bug#939070: removing gnome desktop in tasksel has little or no effect
Package: tasksel Version: 3.54 Severity: normal I accidentially installed debian 10.0 with gnome rather than xfce, so after the installation, I re-ran tasksel, unselected gnome, and selected xfce. I then rebooted, and it still booted up to gdm3 and on login it defaulted to gnome shell. Tasksel probably removed task-gnome-desktop, but many of its dependencies appeared to still be installed. (I've since reinstalled the machine with xfce and so can't provide any more details about its state.) -- see shy jo signature.asc Description: PGP signature
Bug#889904: /etc/flash-kernel/dtbs versioning
Uwe Kleine-König wrote: > Right, in theory the dtbs are independant from the kernel, but real life > is different. That's why the linux image packages ship their matchin > device trees. I don't know your setup, but it would be easiest to use > these. If you don't provide your own dtb and just use > > DTB-Id: sun7i-a20-cubietruck.dtb > > everything should simply work. I'm using a custom device tree file to enable onewire temperature sensors. More generally, http://joeyh.name/blog/entry/easy-peasy-devicetree-squeezy/ currently puts its device tree file in /etc/flash-kernel/dtbs/ and thus is affected by the lack of kernel versioning. -- see shy jo signature.asc Description: PGP signature
Bug#889904: /etc/flash-kernel/dtbs versioning
Package: flash-kernel Version: 3.90 Severity: normal There's a good chance that the devicetree file for one version of the kernel will not work with another version. I suspect this was the case, and confirmed it today when my cubietruck failed to boot with mismatched versions. So, it would be good if /etc/flash-kernel/dtbs could prefer a filename with the kernel version in it, over the unversioned file. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- see shy jo signature.asc Description: PGP signature
Bug#885659: xserver-xorg-input-synaptics not installed
Package: tasksel Version: 3.42 Severity: normal An install from netinst of Debian 9.3 on a Lenovo Yoga 710 did not install xserver-xorg-input-synaptics, so it was not possible to configure some things like tap-to-click. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tasksel depends on: ii apt 1.6~alpha5 ii debconf [debconf-2.0] 1.5.65 ii liblocale-gettext-perl 1.07-3+b3 ii perl-base 5.26.1-3 ii tasksel-data3.42 tasksel recommends no packages. tasksel suggests no packages. -- debconf information excluded -- see shy jo signature.asc Description: PGP signature
Bug#881969: making bootable SD cards
Vagrant Cascadian wrote: > u-boot-install --board=Cubietruck --device=/dev/mmcblk0 > > u-boot is where the information such as > supported boot media and device offsets generally comes from, as it > sometimes changes changes between different versions of u-boot Verison specificity is another big reason to need this in one place and not scattered around. > Doing this would also make me want to split the flash-kernel database > out into a separate package from the boot script/kernel+initrd copying > parts of flash-kernel It would also be useful to be able to query the flash-kernel database for particular fields to avoid other duplication of info. If there were a way to query for the kernel image variant to use for a board, I could use that in propellor. -- see shy jo signature.asc Description: PGP signature
Bug#881969: making bootable SD cards
Karsten Merker wrote: > to use d-i/flash-kernel on the target device, one obviously needs > to already have put a u-boot onto the device in some form (such > as preinstalled in the d-i SD card images), otherwise one > couldn't have booted it Not necessarily, see for example /target in d-i when the machine has been booted from other media than the target disk. As noted in my initial message, d-i does not handle this in all cases, requiring clumsy warnings on wiki pages to warn the user about its deficiencies. If flash-kernel provided a way to do it, d-i could easily to it for at least cases where u-boot is installed on a safe media like a SD card. > As a result of these issues, it was deemed unsuitable for > flash-kernel to attempt installing u-boot. A separate program included in flash-kernel that looks at the machine database to determine how to install u-boot and installs it to a specified device would avoid all of those issues. That is what I am suggesting. -- see shy jo signature.asc Description: PGP signature
Bug#881969: making bootable SD cards
Package: flash-kernel Version: 3.87 Severity: normal Therefore you usually have to setup an SD card with the appropriate u-boot version for your particular device (see below) as a prerequisite for installing Debian. If you use the pre-made SD card images with the installer, this step is not necessary, as these images already contain u-boot. -- https://wiki.debian.org/InstallingDebianOn/Allwinner This seems to fall squarely in flash-kernel's wheelhouse, since it already handles the other parts of u-boot installation, and it knows the name of the board being installed. The d-i SD card images avoid the problem, but they are only one way to install; there are even other ways to use d-i to install that need this manual step first. The main difficulty in putting it in flash-kernel is that it might be installed in a chroot in a situation where it should not be altering the boot sector of the host's disk. So, something like grub-installer seems to be called for, so the user specifies the device to install to. A utility in flash-kernel would be much nicer than needing to puzzle out dd commands from README.Debian files and hope you got it right. I'm currently having to embed those dd commands inside propellor; they're also embedded inside debian-installer (build/boot/arm/u-boot-image-config). -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- see shy jo signature.asc Description: PGP signature
Bug#795231: fails on cubietruck with FAT /boot
Ian Campbell wrote: The cubietruck u-boot is more than capable of booting from an ext filesystem, so you should just do that, in fact everything should work in this mode out of the box, how did you end up with a FAT /boot? Haven't upgraded from default uboot yet, which does't even support ext2.. On platforms where u-boot is only capable of reading FAT the recommended approach is to use a dedicated FAT partition which is not normally mounted and use flash-kernel's Boot-Device option to cause the boot images to be copied to it. Ok, that's reasonable.. -- see shy jo signature.asc Description: Digital signature
Bug#795231: fails on cubietruck with FAT /boot
Package: flash-kernel Version: 3.36 Severity: normal A few places in flash-kernel try to ln -s, and this fails if /boot is a FAT filesystem. It should be possible to fall back to cp in this case. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- see shy jo signature.asc Description: Digital signature
Bug#770658: fails to debootstrap debian on fedora: Failure trying to run: chroot /debian mount -t proc proc /proc
Package: debootstrap Version: 1.0.64 Severity: normal W: Failure trying to run: chroot /debian mount -t proc proc /proc This is because mount is in a different location in fedora than in debian. On Debian, it's in /bin/mount, while on fedora, /usr/bin/mount. And, on fedora, root's default path does not contain /bin: [root@alien /]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin So, chroot tries each of those directories, does not find mount in them in the debian chroot, and fails. Suggested fix: Before chrooting into the debootstrapped chroot to run commands, debootstrap should ensure that the PATH includes all directories it does on a standard debian system. Eg: PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin This way, the host system's chroot etc will still be found whereever it's PATH has them, and the debian system's commands will likewise be found. -- see shy jo signature.asc Description: Digital signature
Bug#770214: source tarball should not be compressed with xz
Package: debootstrap Version: 1.0.64 Severity: normal xz is not a common format, and this makes it unncessarily difficult to install debootstrap from source on unfamiliar linux systems. The space savings are miniscule. Please switch to a tar.gz. -- see shy jo signature.asc Description: Digital signature
Bug#770217: cannot be run from source on !debian
Package: debootstrap Version: 1.0.64 Severity: normal make devices.tar.gz runs MAKEDEV, so the instructions to run debootstrap from source don't work on !debian. setup_devices contains old code to bind mount /dev when it's managed by devfs. Updating that code to check for /dev managed by udev and bind mounting then might be one approach to improve this. The resulting chroot would need to have /dev/ bind mounted into it in order to be used, which seems reasonable. Alternatively, a debootstrap tarball could be provided targeting this use case, including a prebuilt devices.tar.gz. Alternatively, the devices.tar.gz Makefile target could, if MAKEDEV is not in path, just tar up the system's /dev to make it. I suspect that some people in this situation download the .deb from debian and manually unpack it to get a prebuilt devices.tar.gz. Although this requires both ar and (for no good reason) xz, which are not universally available outside debian systems. -- see shy jo signature.asc Description: Digital signature
Re: d-i talk at Cambridge mini-DebConf
Cyril Brulebois wrote: Joey, I can't really convey this by email, but the last slide was received with warm applause. Thank you so much, for everything. I caught this email yesterday while having lunch with my Mom and Sis and was proud to show them the last slide. They kindly didn't mention the tears. Looking over the presentation again, it's really great to see how much work has gone into d-i this cycle. Well done all. -- see shy jo signature.asc Description: Digital signature
on my retirement from Debian
Since I'm leaving Debian, I won't be involved in d-i any longer. I haven't had time or bandwidth to do much for years, so no great loss. ;) I will remove myself from the couple of packages I'm still listed in Uploaders. https://lists.debian.org/debian-devel/2014/11/msg00174.html I look forward to sharing a drink at some time in the future with anyone and everyone who's made d-i what it is over the years. -- see shy jo signature.asc Description: Digital signature
Re: default DE requalification: quality of task
Adam Borowski wrote: However, I kind of fail to see the point of giving two whole points for something as minor as the tasksel task. These points are not added up to get some kind of an overall score. -- see shy jo signature.asc Description: Digital signature
Re: Installing Debian remotely in an unmanaged VPS
Mario Castelán Castro wrote: Otherwise, is it possible to cram a complete Debian installer into a initrd?. That's exactly what the d-i netboot image is. The https://wiki.debian.org/DebianInstaller/Remote page you linked to seems exactly right. The netboot image doesn't include network-console by default; that page builds an initrd that you can configure your VPS to boot from. -- see shy jo signature.asc Description: Digital signature
Re: Bug#766459: debootstrap: should not try to configure base-files before /etc/passwd has the usual users in a Debian system
Santiago Vila wrote:
Instead, the work of debootstrap is precisely to guess the right order
in which packages should be configured so that everything work.
In other words, essential packages should not get in the business of
breaking dependency cycles, because that's debootstrap job.
This way, maintainer scripts in essential packages are kept clean
and all the hacks required for bootstrap are accumulated (so to speak)
in debootstrap and similar tools.
As a debootstrap maintainer, I can't say I agree with this.
There are very few hacks and special cases of ordering in debootstrap today,
and for our sanity we'd like to keep it that way. I consider such
complications to be warts that need to be gotten rid of eventually.
Just compare /usr/share/debootstrap/scripts/{sid,sarge}. Which would
you rather maintain? And BTW that sid script works for 5 different
releases of debian, largely because it's not full of special cases and
hacks specific to particular releases.
You will find a more complete explanation of this in the logs for
Bug#760568 where I'm asked no less than to depend on base-passwd,
which is essential! IMHO, this is definitely not the way to go.
It's past time to be untangling the Essential hairball. Correct dependency
metadata is much more scalable than hacks in debootstrap.
Stop being part of the problem, and add the dependency already..
--
see shy jo
signature.asc
Description: Digital signature
Bug#765839: task-desktop: installs a non-working dekstop environment on all but 2 archs
Adam Borowski wrote: * powerpc in qemu (using an existing system on real metal, d-i on qemu) What specific real metal did you use to test gnome on powerpc? -- see shy jo signature.asc Description: Digital signature
Bug#765976: tzsetup: please don't offer time zone selection for Germany
Most countries have only one timezone, and for those the country-zone mapping is stored in the tzmap file (automatically generated from zone.tab), and no question is asked. Some countries have multiple timezones listed in zone.tab, but these are only of historical interest (ie, to get the correct time at some point in the past), and are thus not worth bothering the user about during install. For these the tzmap.override file can be used to force a whole country to one zone. -- tzsetup/README -- see shy jo signature.asc Description: Digital signature
Bug#765839: task-desktop: installs a non-working dekstop environment on all but 2 archs
Dude, if you thinkn that posting offtopic stuff to a bug report is the way to convince people of something, you might want to think again. -- see shy jo signature.asc Description: Digital signature
Bug#765839: task-desktop: installs a non-working dekstop environment on all but 2 archs
Adam Borowski wrote: I have tried Gnome3 on: * an armhf laptop, Omega OAN133, with: * framebuffer * proprietary Mali drivers * an armhf desktop, hardkernel Odroid U2 (also Mali) * powerpc in qemu (using an existing system on real metal, d-i on qemu) What was the result of all these tests? Proposed solutions: 1. revert to xfce by default :p 2. make task-desktop arch:any, with gnome first on amd64 and i386, and xfce (or mate...) elsewhere 3. remove the task-gnome-desktop package on !amd64 !i386 Set a better default on a per-arch basis in default_desktop -- see shy jo signature.asc Description: Digital signature
Re: Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Petter Reinholdtsen wrote: Here is another draft, this time also providing the module name. I dropped the code looking in /proc/modules, as three ways to find firmware seem a bit too much. Looking at dmesg might fail if something is spamming it and the message drops out of the ring buffer. Maybe it would be better to look in syslog? The modinfo check, which has been removed, avoids that problem, although it doesn't work for some modules that don't load at all when missing firmware. I don't know how many modules have that behavior, but if most of them don't, the modinfo check seems worth keeping as more robust for the modules it does work for. -- see shy jo signature.asc Description: Digital signature
Bug#764982: apt-setup-udeb: Backports via d-i, but not by default
Cyril Brulebois wrote: Ah, yes. I remember having wondered about that when installing jessie on a new machine. I'm not particularly happy about being able to pull packages from backports without any kind of manual action. apt won't install newer versions from backports unless the user explicitly specifies -t $suite-backports Or, IIRC, unless the currently installed version came from backports already and an upgrade is available in backports. I don't see a problem with making backports be available by default, as long as the user has to explicitly tell apt they want to use them. -- see shy jo signature.asc Description: Digital signature
Bug#764001: installation-reports: I cannot proceed from tasksel if I select all four desktop environments
Thomas Skardal wrote: If I select all four (Gnome, KDE, XFCE, MATE) desktop environments during tasksel I'm unable to continue without an error. Tasks should all be co-installable, so it would be useful to know what the error message is. -- see shy jo signature.asc Description: Digital signature
Bug#764277: Graphical DE task don't install any DE
Baptiste Jammet wrote: Testing debian-jessie-DI-b2-kfreebsd-amd64-netinst.iso under qemu-kvm, if I only choose Graphical desktop environment, d-i doesn't install any DE, just something like desktop-base. It seems that I have to choose explicitly. (Tested 2 times) Oct 6 17:03:32 in-target: Paquets recommandés : Oct 6 17:03:32 in-target: aspell-en aspell-dictionary aspell6a-dictionary debian-faq apt-howto-fr Oct 6 17:03:32 in-target: mailx libc6-dev libc-dev myspell-fr myspell-fr-gut iamerican Oct 6 17:03:32 in-target: ispell-dictionary xfonts-mathml hdparm ethtool kbd console-tools Oct 6 17:03:32 in-target: task-gnome-desktop task-xfce-desktop task-kde-desktop task-lxde-desktop Oct 6 17:03:32 in-target: task-cinnamon-desktop task-mate-desktop iw alsa-utils alsa-base These package which were not installed, are mostly direct Recommends of the task-desktop package. So it seems that Recommends were either not being installed, despite tasksel running apt-get -o APT::Install-Recommends=true or some dependency issue prevented installing those Recommends. Also, tasksel should default to selecting the xfce task on kfreebsd. This can be tested in an already installed system by running: sudo tasksel -t --new-install Hopefully that's enough to let someone who has the bandwidth to look at what's causing this problem on kfreebsd. -- see shy jo signature.asc Description: Digital signature
Bug#764505: kFreeBSD-amd64: Beta installer 2 seems to work
Steven Chamberlain wrote: I noticed there was an option to install GNOME, even though it is not available for kFreeBSD jessie. I think tasksel is already supposed to hide uninstallable tasks, and indeed, meta-gnome-desktop should be uninstallable in testing: Tasksel hides tasks that are not available. It assumes that if the archive contains a task package, it's usable. I do not want to complicate tasksel with a separate dependency resolution pass. -- see shy jo signature.asc Description: Digital signature
Bug#762342: task-cinnamon-desktop: Please turn on display of Cinnamon desktop task
Ben Armstrong wrote: Both Mate and Cinnamon feature the traditional panel and menu design that GNOME 2 did, so share more in common in design than they do with gnome-shell But then there's gnome 3 fallback mode. What perplexes me is why Mate, which is a throwback desktop based on an aging codebase with none of the niceties introduced by GNOME 3 is now visible whereas the (imho) saner, forwards-looking Cinnamon, which takes advantage of those improvements gets relegated to the sidelines due to having too many common characteristics with GNOME 3. Another way of looking at this is that cinnamon apparently includes only around 20 mb of different packages than gnome 3. (So, the gnome DVD will probably include cinnamon.) It's almost closer to an alternate theme than a separate desktop. Being on this boundary makes it hard to decide if tasksel should include it. Indeed, and seems doomed to remain less popular if users don't even know that it's an option because they can't see it when they install. If there is demand for cinnamon, then I'd expect to see an initial popcon curve for it that looks something like the curve for mate, at the time before mate was available in tasksel. So not adding cinnamon to tasksel immediately, does not preclude drawing useful inferences from popcon data. It's a bit too early to tell what kind of curve we're seeing for cinnamon. -- see shy jo signature.asc Description: Digital signature
Bug#762478: redundant desktop selection
Didier 'OdyX' Raboud wrote: Le lundi, 22 septembre 2014 14.31:19, vous avez écrit : tasksel allows selecting the desktop now, so the selection in win32-loader is unncessary (the list there is also incomplete). Thanks for the heads'up, patch in the pipes. I think that default_desktop=xfce might still be passed for kfreebsd installs, to override the current default of gnome. That can still be passed through. Although it might make more sense to move that logic to tasksel eventually. For now I've patched win32-loader to keep enforcing this; the resulting preseed configuration file is the following: tasksel tasksel/desktop multiselect gnome-desktop Should be just gnome. Template: tasksel/desktop Type: multiselect Choices: gnome, kde, xfce, lxde, cinnamon, mate Description: This can be preseeded to override the default desktop Then next release of tasksel will know about defaulting to xfce on hurd and freebsd, so it will be unncessary for win32-loader to do so at that point. -- see shy jo signature.asc Description: Digital signature
Bug#762342: task-cinnamon-desktop: Please turn on display of Cinnamon desktop task
Ben Armstrong wrote: Please turn on display of the Cinnamon desktop task. I have tested building Jessie live images with Cinnamon included and it seems to already provide a usable desktop. It would be useful for testers to be able to see Cinnamon so they can try it and help shake out any remaining bugs between now and the freeze. lxde is also not displayed. I have not figured out where the dividing line should be, or really what the criteria should be for a desktop task to be displayed. One way might be to decide if a given DE is fundamentally different than the others in some way, and if not, only include one of a set that share common characteristics. So, maybe only gnome and not cinnamon since it's a rather near cousin (AFIACS). Or only xfce and not lxde since both are fairly light desktops. Another way could be to look at popcon trends, although cinnamon is too recently packaged to be able to tell if it will have many users in debian. -- see shy jo signature.asc Description: Digital signature
Bug#762614: stop preseeding desktop
Package: debian-installer
Severity: normal
Tags: patch
Once tasksel 3.27 is in testing, but not before, d-i should stop
preseeding desktop=xfce for kfreebsd and hurd. This version of tasksel
defaults to xfce for those architectures and will handle any other
architecture variations in a single place.
--
see shy jo
From 742e335531a1ed27757db3b3ce95bc330e7d51f6 Mon Sep 17 00:00:00 2001
From: Joey Hess j...@kitenet.net
Date: Tue, 23 Sep 2014 14:59:10 -0400
Subject: [PATCH] remove desktop=xfce preseeding
Moved to tasksel 3.27.
---
build/boot/hurd/grub-hurd-cdrom.cfg | 2 +-
build/boot/hurd/grub-hurd-pxe.cfg | 2 +-
build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg | 4
build/boot/kfreebsd/grub-kfreebsd-pxe.cfg | 4
build/config/kfreebsd.cfg | 2 --
5 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/build/boot/hurd/grub-hurd-cdrom.cfg b/build/boot/hurd/grub-hurd-cdrom.cfg
index cf93789..b50ceb5 100644
--- a/build/boot/hurd/grub-hurd-cdrom.cfg
+++ b/build/boot/hurd/grub-hurd-cdrom.cfg
@@ -37,7 +37,7 @@ menuentry {
function boot_one {
echo Loading ...
set root=$cd
- multiboot /boot/kernel/gnumach.gz $options desktop=xfce
+ multiboot /boot/kernel/gnumach.gz $options
module --nounzip /boot/${gtk}initrd.gz initrd '$(ramdisk-create)'
module /boot/kernel/ext2fs.static ext2fs \
--multiboot-command-line='${kernel-command-line}' \
diff --git a/build/boot/hurd/grub-hurd-pxe.cfg b/build/boot/hurd/grub-hurd-pxe.cfg
index b45dee1..b5c9fc3 100644
--- a/build/boot/hurd/grub-hurd-pxe.cfg
+++ b/build/boot/hurd/grub-hurd-pxe.cfg
@@ -28,7 +28,7 @@ menuentry {
function boot_one {
echo Loading ...
set root=$cd
- multiboot $prefix/gnumach.gz $options desktop=xfce
+ multiboot $prefix/gnumach.gz $options
module --nounzip /boot/${gtk}initrd.gz initrd '$(ramdisk-create)'
module /boot/kernel/ext2fs.static ext2fs \
--multiboot-command-line='${kernel-command-line}' \
diff --git a/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg b/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg
index a12c622..c252410 100644
--- a/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg
+++ b/build/boot/kfreebsd/grub-kfreebsd-cdrom.cfg
@@ -26,10 +26,6 @@ else
set menu_color_highlight=white/blue
fi
-# See archived discussion:
-# http://lists.debian.org/debian-bsd/2011/09/msg00051.html
-set kFreeBSD.desktop=xfce
-
menuentry Debian GNU/kFreeBSD installer boot menu {
true
}
diff --git a/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg b/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
index 72a601e..03f242b 100644
--- a/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
+++ b/build/boot/kfreebsd/grub-kfreebsd-pxe.cfg
@@ -17,10 +17,6 @@ else
set menu_color_highlight=white/blue
fi
-# See archived discussion:
-# http://lists.debian.org/debian-bsd/2011/09/msg00051.html
-set kFreeBSD.desktop=xfce
-
menuentry Debian GNU/kFreeBSD installer boot menu {
true
}
diff --git a/build/config/kfreebsd.cfg b/build/config/kfreebsd.cfg
index fe3df2b..d4cd148 100644
--- a/build/config/kfreebsd.cfg
+++ b/build/config/kfreebsd.cfg
@@ -52,7 +52,6 @@ arch_cd_info_dir:
(printf [installer]\n; \
printf kernel=kfreebsd\n; \
printf arch=$(subst kfreebsd-,,$(ARCH))\n; \
- printf default_desktop=xfce\n; \
#if [ -n $(INITRD_GTK) ]; then \
# printf $(ARCH)/kfreebsd=boot/kernel/kfreebsd.gz\n$(ARCH)/kfreebsd_module=boot/mfsroot.gz\n; \
# printf $(ARCH)/gtk/kfreebsd=boot/kernel/kfreebsd.gz\n$(ARCH)/gtk/kfreebsd_module=boot/gtk/mfsroot.gz\n; \
@@ -95,7 +94,6 @@ arch_miniiso: $(TEMP_INITRD) $(TEMP_KERNEL) $(TREE)
(printf [installer]\n; \
printf kernel=kfreebsd\n; \
printf arch=$(subst kfreebsd-,,$(ARCH))\n; \
- printf default_desktop=xfce\n; \
if [ $(TYPE) = netboot/gtk ]; then \
printf user_interface=graphical\n; \
printf $(ARCH)/gtk/kfreebsd=boot/kernel/kfreebsd.gz\n$(ARCH)/gtk/kfreebsd_module=boot/mfsroot.gz\n; \
--
2.1.0
signature.asc
Description: Digital signature
Bug#762614: stop preseeding desktop
Steven Chamberlain wrote: Agreed, although we should try evaluate if XFCE is still the best default for these (and perhaps find something that caters to other situations where GNOME isn't viable) As far as I'm concerned, this decision is up to the porters for an architecture. If there is more than one candidate that works well on their architecture, we can use the Requalification/Jessie information to rank them. There is also the potential for tasksel to look at properties of the system and fall back to eg, a lighter desktop, or a configuration that works better on a tablet. My changes to tasksel support such things, but it would be up to interested developers to write such code. -- see shy jo signature.asc Description: Digital signature
Re: Bug#762614: stop preseeding desktop
Hendrik Boom wrote: After all this time (what is it? over a year now?) I thought the new Gnome might have improved and become viable. I tried it last weekend. It still isn't viable. I can't even figure out how to log out. Given that Debian has already shipped a stable release with Gnome 3, and that debian-user does not seem to be overflowing with posts from users who cannot figure out how to log out of their desktop, I think your experience may be an outlier. In any case, this thread is not about the default desktop selection. Please don't post offtopic things to bug report threads. -- see shy jo signature.asc Description: Digital signature
Bug#762614: stop preseeding desktop
Steven Chamberlain wrote: On 16:04, Joey Hess wrote: There is also the potential for tasksel to look at properties of the system and fall back to eg, a lighter desktop, or a configuration that works better on a tablet. My changes to tasksel support such things, but it would be up to interested developers to write such code. If installing offline from CD-1 for example, we can only install whatever is on the disc already. Does tasksel handle that situation at all? Or will it now (due to the change of default) suggest GNOME, but fail due to the missing packages? Tasksel has never presented tasks that are unavailable for installation. (This seems offtopic to what this bug report is about.) -- see shy jo signature.asc Description: Digital signature
Bug#762478: dedundant desktop selection
Package: win32-loader Version: 0.7.5 Severity: normal tasksel allows selecting the desktop now, so the selection in win32-loader is unncessary (the list there is also incomplete). I think that default_desktop=xfce might still be passed for kfreebsd installs, to override the current default of gnome. That can still be passed through. Although it might make more sense to move that logic to tasksel eventually. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash win32-loader depends on no packages. win32-loader recommends no packages. Versions of packages win32-loader suggests: pn wine none -- no debconf information -- see shy jo signature.asc Description: Digital signature
Re: new tasksel
Thomas Goirand wrote: Does OpenStack Proxy Node have a clear meaning to openstack users? If the purpose is for it to be the node that controls the other nodes and has a management interface, that does not seem clear from that description. Then maybe rename it as OpenStack controller node. That sound better to me. Is openstack fully usable after installing these packages and answering any = high priority debconf questions? Mostly. Networking wouldn't work out of the box for example. There's some more work that should be done so that it gets easier, it's still very complicated to deploy a fully working setup. If it's that hard to get it working, I wonder if it can be justified to put it in tasksel yet, where a casual user could stumble over it. I can think of a few reasons to include it: * To advertise that Debian is providing openstack packages. * Perhaps to aid deploying openstack. But if there's a long and complicated deployment process, eliminating an apt-get install from it, and using tasksel instead seems that it would not significantly improve it. -- see shy jo signature.asc Description: Digital signature
Re: default desktop: availability on all arches
Adam Borowski wrote: I think the DebianDesktop requalification table lacks an important row: the availability of the desktop environment in question on all Debian architectures. While that can be a minor consideration (it would be nicest to be consistent if possible), we've had different default desktops on different archictectures in past releases, and can do so again. I'd consider this at best a tie-breaker. -- see shy jo signature.asc Description: Digital signature
Re: new tasksel
Steven Chamberlain wrote: Init system? ... sysvinit ... upstart ... OpenRC Note that my email was meant to alert people who need to do work to do it, not to solicit way-down-the-slippery-slope suggestions that can be rejected out of hand by looking at the description of TASKsel. -- see shy jo signature.asc Description: Digital signature
Re: new tasksel
Thomas Goirand wrote: I've attached the diff for adding OpenStack tasks. As you can see, it's simply using the meta packages that we have already. Does OpenStack Proxy Node have a clear meaning to openstack users? If the purpose is for it to be the node that controls the other nodes and has a management interface, that does not seem clear from that description. Is openstack fully usable after installing these packages and answering any = high priority debconf questions? -- see shy jo signature.asc Description: Digital signature
Re: new tasksel
Andrew M.A. Cater wrote: Is there any scope/space for this: essentially only a tiny step up from what you'd get by installing using a netinst without a mirror? Un-select everything in tasksel. (Also, this thread is not about random suggestions or user support.) -- see shy jo signature.asc Description: Digital signature
Re: Using machine-readable copyright files in D-I packages
Christian PERRIER wrote: Fixing this should be easyas long as one *does* find copyrights in the files provided by a given package. For instance: bubulle@sesostris:~/src/debian/debian-installer/trunk/packages/partman-efi(master) $ licensecheck -r --copyright * bubulle@sesostris:~/src/debian/debian-installer/trunk/packages/partman-efi(master) $ What is the recommended practice in such case? This package is under the GNU GPL version 2, or any later version at your option. That's a clear statement of the license of every file in the package, unless some file overrides it with its own license statement. Just assign the copyright collectively (but to what entity)? There seems to be no problem with naming any obvious major contributors (the original author of the package for example) and then adding 2007-2012, many Debian contributors ... Which I found in the machine-readable copyright file of debian-policy. -- see shy jo signature.asc Description: Digital signature
new tasksel
I have made some significant changes to tasksel, that will need changes elsewhere. I plan to upload this to unstable pretty soon, feedback permitting. Some of the more popular desktop environments are individually selectable in tasksel, in a little sub-menu. (Of course that's displayed suboptimally due to debconf, wah.) (There is still, obviously, a default desktop.) Parts of the syslinux boot menus are obsoleted (though not actually broken) by the above change and should be removed. Which will also probably mean changing the installation manual too. debian-cd also has some isolinux menus for desktop selection that can be removed now. Note that I kept the tasksel/desktop preseed working, so debian-cd can continue to use it for non-default-desktop CDs. Most of the server tasks were not well enough defined or useful and so were removed. I kept ssh-server, print-server, and web-server. This may need documentation updates somewhere. No translatable strings were changed so far, but I would like to change Debian desktop environment to Desktop environment, because that would make the display look better: │[*] Desktop environment │ │[*] ... Xfce│ │[ ] ... GNOME │ │[ ] ... KDE │ There's room to add a limited number of blends type tasks, but this will be up to the blends people to put together patches for. The menu only has 8 out of 10 slots used now, and my feeling is that a modest amount of hierarchy here can allow adding slightly more choices to the menu without it descending into unusable chaos. So, perhaps something like this, although I am unsure of the names. │[ ] Debian pure blends │ │[ ] ... Debian Edu │ │[ ] ... Debian Med │ │[ ] ... DebiChem│ │[ ] Openstack │ │[ ] ... Compute Node│ │[ ] ... Proxy Node │ -- see shy jo, for fjp signature.asc Description: Digital signature
Bug#758116: popcon
There is going to be a limited amount of space in tasksel for blends, given current debconf UI constraints. I think that using popcon as a rough pass to select the blends makes rather a lot of sense. The Debian Pure Blends effort has been around for several releases and been publicised. The individual blends have had time to find users, or not. If there is some new and upcoming blend that makes sense to promote for a while, it might make sense to disregard the popcon numbers for a while. (Of course, you want to read the right column in the popcon output, in particular the number of installs, not number of metapackages in use, which tends to be 0.) -- see shy jo signature.asc Description: Digital signature
Re: accessibility of jessie desktops
MENGUAL Jean-Philippe wrote: - XFCE is not at all so far, mainly due to openbox and not link on GTK or Nt toolkits. I'm rather confused by this, since openbox is not the window manager of xfce (it's used by lxde actually), and since xfce uses gtk extensively. When I select Enable assitive technologies in xfce4-accessability-settings, it claims that it will start the required applications for screen readers and magnifiers. But if it does, I can't tell. -- see shy jo signature.asc Description: Digital signature
Re: [Pkg-xfce-devel] systemd/logind integration of desktop environments
Yves-Alexis Perez wrote: On ven., 2014-09-05 at 16:46 -0400, Joey Hess wrote: As part of the process described on this wiki page -- https://wiki.debian.org/DebianDesktop/Requalification/Jessie We're requesting some information from each desktop team, as well as the systemd maintainers: Hi, what kind of reply do you expect? Direct reply, group reply, or direct edit of the wiki page? Reply to task...@packages.debian.org (ccing your respective list) or edit the wiki page is ok. -- see shy jo signature.asc Description: Digital signature
Bug#712696: tasksel: Task for cinnamon
Some things that seem to be missing from the cinnamon task that are included in other desktop tasks: * package management (eg synaptic) * printer configuration? (system-config-printer) * network-manager I have not looked at cinnamon in detail, this is just looking at what's in the other tasks and trying to find equivilants in the cinnamon task. -- see shy jo signature.asc Description: Digital signature
accessibility of jessie desktops
Accessibility is probably the most important issue to consider when choosing the default desktop for jessie. So, the tasksel maintainers request a short report from the accessibility team: Please rank the degree of the accessibility of each desktop from -1 to +1. For more on the process we're using, see this wiki page: https://wiki.debian.org/DebianDesktop/Requalification/Jessie We're tight on time, so just ranking gnome and xfce would be useful. (But we are also curious about how accessible kde and lxde are.) -- see shy jo signature.asc Description: Digital signature
i18n and l10n of desktop environments
In the discussion about whether jessie should default to installing gnome or xfce (or whatever), the question was raised that some might be better translated than others. So, this has been included as a criteria on this wiki page: https://wiki.debian.org/DebianDesktop/Requalification/Jessie I invite either the i18n team as a whole or a motivated member to come up with some kind of answer to this question: How well is each desktop internationalized and translated? It would be great to get some hard numbers, perhaps of the form X% of world population can use $desktop in their native language. Please rank desktops from -1 to +1. -- see shy jo signature.asc Description: Digital signature
Re: kbd-chooser in the attic?
Steve McIntyre wrote: Hey folks, At KiBi's suggestion, I've been looking at kbd-chooser to add support for arm64 and ppc64el, but I've hit a weird issue - the git repo I'm working on isn't there. From discussion on #debian-boot, KiBi points out that it's been moved to the attic and marked as deleted in mrconfig. Looks like a mistake to me - can anybody explain? Joey? I thought it had been made unncessary by console-setup (see #610524), but if I'm in error it should be moved back. -- see shy jo signature.asc Description: Digital signature
Re: Bug#485586: debian-installer: Default to graphical install
Didier 'OdyX' Raboud wrote: Now, the ideal would be to use syslinux' ifcpu/ifcpu64 c32 modules to determine the menu order depending on the machine (see [0]): no 64 bit option on 32 bit machines, hidden or down the menu 32 bit option on 64 bit-capable machines. This used to be the case via the default64 option patched into syslinux, but then #505243 complicated it and #505496 saw the default64 option removed from syslinux. It would certainly be worth fixing this reversion in the multiarch CD. -- see shy jo signature.asc Description: Digital signature
Re: Re: the audio group
user-setup-apply is run in finish-install, so it can check if systemd is installed or not. The only downsides I see: * Still need to add the groups in non-systemd installations, eg freebsd, so this will be an point of difference that will need testing. * If a user chooses to remove systemd after the install, they would need to manually add the groups. -- see shy jo signature.asc Description: Digital signature
Bug#757819: qemu-debootstrap fails on systemd-sysv issue
Package: debootstrap Version: 1.0.60 Severity: normal After a foreign deboostrap, the second stage failed: dpkg: regarding .../systemd-sysv_208-7_armhf.deb containing systemd-sysv, pre-dependency problem: systemd-sysv pre-depends on systemd systemd is unpacked, but has never been configured. dpkg: error processing archive /var/cache/apt/archives/systemd-sysv_208-7_armhf.deb (--unpack): pre-dependency problem - not installing systemd-sysv dpkg --configure --pending succeeds, so I think debootstrap may just need to be adjusted now that systemd is default. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debootstrap depends on: ii wget 1.15-1+b1 Versions of packages debootstrap recommends: ii debian-archive-keyring 2012.4 ii gnupg 1.4.18-2 debootstrap suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Re: Reverting to GNOME for jessie's default desktop
Jordi Mallach wrote: Accessibility Hardware: GNOME 3.12 will be one of the few desktop environments to support HiDPI displays, now very common on some laptop models. Lack of support for HiDPI means non-technical users will get an unreadable desktop by default, and no hints on how to fix that. I think the above are fairly big points. It would be helpful to see a pointer to a bug report about how xfce fails when the DPI is higher than usual. (Also, perhaps worth noting that 3.12 is quite a few versions ahead of the gnome currently in unstable..) Another one I've become aware of, but not investigated is that xfce's compositor may not do as good a job at eliminating tearing (with eg, Intel graphics) as gnome's does. (Also, I think xfce doesn't enable compositing by default.) Further investigation of this would be appreciated. Popularity: One of the metrics discussed by the tasksel change proponents mentioned popcon numbers. 8 months after the desktop change, Xfce does not seem to have made a dent on install numbers. fwiw https://qa.debian.org/popcon-graph.php?packages=task-gnome-desktop+task-xfce-desktop+gnome+xfce4show_installed=onwant_legend=onwant_ticks=onfrom_date=to_date=hlght_date=2014-01-25date_fmt=%25Y-%25mbeenhere=1 systemd embracing: One of the reasons to switch to Xfce was that it didn’t depend on systemd. But now that systemd is the default, that shouldn’t be a problem. Also given ConsoleKit is deprecated and dead upstream, KDE and Xfce are switching or are planning to switch to systemd/logind. systemd did not much affect the switch to xfce. OTOH, double-suspend bugs still being open is a problem. #727605 Downstream health Upstream health Community Security Privacy Documentation I don't think these are very useful criteria, unless they lead to actual technical issues/benefits. Which can then be discussed on technical and/or quantified grounds rather than advocacy grounds. Localization I'm wary of comparing translation percentages since that hides a lot of relevant details. It's better to look at how well a given translation performs in regular usage. Another thing that makes comparing localization numbers work better is to scale them by native speaker populations. Perhaps bubulle could do a more detailed analysis? -- see shy jo signature.asc Description: Digital signature
Re: Bug#712696: debian-installer: Add Cinnamon and Mate as alternative DEs.
Steve McIntyre wrote: I'm not sure we want to support every desktop environment out there… but I guess tasks might not hurt, so punting that to tasksel. And adding debian-cd@ to the loop, to get some feelings about whether new images would sound like a vaguely sane idea (I'm really not sure). Adding new image options shouldn't be too difficult, but beware that we might even start to struggle for space on DVD#1 if we end up with lots of different desktops...! I'm glad to see these are packaged now, and will be happy to add tasks to tasksel. I don't have time to put the tasks together myself, but it should be easy to put something together using task-gnome-desktop as a starting place. -- see shy jo signature.asc Description: Digital signature
Re: Bug#734093: debian-installer: install plymouth by default
Josh Triplett wrote: I wasn't suggesting a requirement; I was suggesting that if systemd becomes the default, there will likely be advantages to switching d-i to use the same init that installed Debian systems do. It's possible I suppose, but since d-i doesn't currently use Debian's init system, and has other constraints, I am doubtful. Quietness on success has some significant advantages to justify not disabling it Is quietness of success actually intended to be a default property of systemd? If a lot of distributions default to adding the quiet kernel boot parameter then maybe, but I don't know if that is the case, and systemd does not do quiet on success without it, which argues that it may not be the intended upstream default behavior. Which in turn may be why systemd has not put much effort into handling debuggability in that configuration. -- see shy jo signature.asc Description: Digital signature
Re: Bug#734093: debian-installer: install plymouth by default
Josh Triplett wrote: If the goal here is to hide the boot messages by default, note that the default kernel command line includes quiet, which hides most kernel messages and systemd messages. Note that the hiding of systemd messages is unintentional, and can make debugging a system that fails to boot challanging. #718038 I asked the systemd maintainers to not make it overload quiet to do that, but they don't want to, so if systemd continues being used in Debian (even if not as default), d-i will need to start adding systemd.show_status=1 to the kernel command line. -- see shy jo signature.asc Description: Digital signature
Re: Bug#734093: debian-installer: install plymouth by default
Josh Triplett wrote: Do you mean the options used within d-i itself, or on the installed system? The latter; d-i does not run with systemd. If you mean the latter, that configuration is owned by the grub-common package, not by d-i. grub-installer configures the grub menu file to include quiet and other kernel options. And in any case, grub-common should not be abusing its configuration of the *kernel* command line to override the defaults of packages other than the kernel. d-i is not setting quiet with the intention of making systemd quiet, but with the intention of suppressing ugly kernel messages. And I really only wanted to do that for desktop installs. The difference is that verbose kernel messages as it enumerates all hardware and so on are unlikely to be useful if you're sitting at a system that has somehow deadlocked on boot, while seeing which daemons systemd is starting is, IME, quite useful when it's gotten into such a situation.. More generally, a quiet boot is a feature, not a bug. The bug you filed is absolutely legitimate, but making bootup noisier by default isn't the right way to fix it. To the best of my knowledge, with quiet, systemd is supposed to behave the same way the kernel does: shut up about commands that succeed, but still shout about failures, making them *easier* to notice. If that's not happening, that's a bug to be fixed. Well, I filed the bug I mentioned about just that. I have seen systemd boot to a black screen with no indication what it was waiting on. I've seen this more than once, in different installations. And in any case, step 1 in debugging a failure to boot should be try booting without quiet (or boot in recovery mode, which also omits quiet). No, step 1 in debugging should be look at the screen and see what went wrong. systemd has a great web page with extensive documentation about how to coax information out of systemd when it fails, but this web page is entirely useless when you were booting the computer you use to read web pages. And it's nearly as useless when you're debugging someone else's system remotely and can't get them to read off the last things that went on without first walking them through a crazy kernel command line edit process in the boot loader. -- see shy jo signature.asc Description: Digital signature
Re: Bug#734093: debian-installer: install plymouth by default
Josh Triplett wrote: The latter; d-i does not run with systemd. If Debian ends up adopting systemd as the default, that seems likely to change. Seems unlikely; I doubt that the Linux kernel will ever require systemd to boot an embedded system such as d-i. Given that the resulting installed system regenerates the grub menu file using the scripts in grub-common, I would hope that d-i matches whatever configuration file grub-common would generate; if it doesn't, that seems like a bug, since that configuration will vanish the next time update-grub runs. This is all done via preseeding the grub package's debconf settings, in a way that will persist unless the user changes it. Yes, it's quite useful *when it has gotten into such a situation*. Otherwise, it's noise. Thus, the right fix would be to have systemd become chattier about *problems* where it isn't already, rather than chattier in general. I don't know if systemd's design lets it detect such a problem. IIRC there is some sort of 5 minute timeout when things have gotten unavoidably deadlocked, after which it tries to break the deadlock. So let's fix *that* bug. systemd records all of the bootup messages, whether it shows them or not; it should be easy enough to emit them when something goes wrong, or even just if bootup takes more than a defined amount of time. (That much would be useful in general to detect slow services: Still launching $servicename: $time_elapsed, with the time ticking upward and the messages not showing up until after several seconds spent launching the same service.) Would that address your concern? I suppose it would, if the timeout was not of the 5 minute variety. Or Systemd could just display the buffered messages during boot if the user presses a key before getty. But it seems a lot more complicated than just flashing all messages up on the screen in the 2 seconds that it takes my laptop to boot to X once systemd has started. -- see shy jo signature.asc Description: Digital signature
Bug#733179: debootstrap should abort if the keyring is missing, not just warn
Making debootstrap fail by default on missing keyring is not going to
somehow make all the people who are using it insecurely learn about the
WoT and get a verified keyring.
The actual effect is it'll make a lot of documentation and probably
quite a lot of scripts obsolete/broken for a while, until everyone
learns to run deboostrap with --no-check-gpg to work around the change.
Which would be only a little annoying, but if everyone gets in the habit
of using debootstrap --no-check-gpg, they'll also use it when
debootstrapping Debian on Debian. We risk regressing to less
security by trying to shove complicated security down users' throats.
I actually think it would be more of a win to change the default mirror
url from the current http://ftp.us.debian.org/ to a https url. This
provides weak (CA) verification on systems without the Debian keyring,
which is considerably better than nothing.
A good candiate for such a mirror is https://mirrors.kernel.org/debian,
although it's not currently in the {ftp,http}.us.debian.org rotation for
some reason, and lacks IPv6. (None of the {ftp,http}.us.debian.org
mirrors currently support https.) Due to those limitations, and to avoid
overloading it, I've modified debootstrap to default to the https mirror only
when the gpg keyring is not available.
--
see shy jo
signature.asc
Description: Digital signature
Bug#732551: make --foreign / qemu-user-static easier
Ian Campbell wrote: That would get you the foreign binary of qemu-user-static, wouldn't it? What is needed is to copy /usr/bin/qemu-$ARCH-static from the host environment. Yes, but then nothing will upgrade it, which is important since user mode qemu often has missing syscalls that get added in newer versions. deboostrap could arrange for the package to be installed in the chroot, using multiarch. -- see shy jo signature.asc Description: Digital signature
Bug#732551: make --foreign / qemu-user-static easier
Package: debootstrap Version: 1.0.55 Severity: wishlist If debootstrap installed qemu-user-static into the chroot when --foreign was used, it could then immediately chroot in and run commands (assuming the host system has binfmt-support installed). This would allow debootstrap to go ahead and run the second stage itself, under qemu emulation, and leave the user with a foreign chroot that could be transparently chrooted into. https://wiki.debian.org/QemuUserEmulation for details -- see shy jo signature.asc Description: Digital signature
Bug#732551: make --foreign / qemu-user-static easier
Vagrant Cascadian wrote: On Wed, Dec 18, 2013 at 01:08:05PM -0400, Joey Hess wrote: If debootstrap installed qemu-user-static into the chroot when --foreign was used, it could then immediately chroot in and run commands (assuming the host system has binfmt-support installed). qemu-user-static includes qemu-debootstrap which does exactly this. You're thinking that should be merged into debootstrap directly? Ok.. No docs pointed that out. I think it would be a net loss of complexity to roll this into debootstrap. Unless there are a lot of other qemu-user-static like things that this might slippery slope debootstrap into being responsible for, but that seems unlikely. The existence of wrappers like this that use --foreign do argue that a new switch should be needed for this behavior. Something like --with-qemu -- see shy jo signature.asc Description: Digital signature
Bug#732255: sources.list not set up when doing --foreign and then second stage install
Package: debootstrap Version: 1.0.55 Severity: normal Normally debootstrap makes a sources.list with either the mirror used for intallation, or a default mirror. However, when --foreign is used and debootstrap is then started inside the bootstrapped system to handle the second stage install, this sources.list setup is skipped. -- see shy jo signature.asc Description: Digital signature
Bug#728359: debian-installer: Install bootloader earlier?
Christian PERRIER wrote: Hence CC'ing Joey in order to get his input here. Joey, do you remember why bootloaders are only installed after apt-setup and the like and not just after base-installer? I bet there is a reason..:-) The only reason I can think of is that it helps prevent accidentially rebooting the computer half way through the install and encountering a strange half-installed system. -- see shy jo signature.asc Description: Digital signature
Re: RFC: removing Mirrors.masterlist from .gitignore in choose-mirror
Cyril Brulebois wrote: [ Side notes: 1. It's a serious bug to depend on the network; 2. It's also not deterministic to allow failure in doing so. ] Have you ever looked at the debian-installer source package's network use? I'm just saying. If I were throwing arbitrary rules out there, I'd add: 3. Committing redundant data to version control is wrong. But I have another rule that superscedes all 3: 0. Ignore arbitrary rules when you have the time to think for yourself. Personally, I think that the way choose-mirror handled Mirrors.masterlist was fine. Note that it didn't fail if there was a network problem. -- see shy jo signature.asc Description: Digital signature
Bug#718855: [Pkg-xfce-devel] network-manager-gnome - full gnome recommends chain
Yves-Alexis Perez wrote: Or tasksel could stop installing recommends, like it was done before, and people involved in the various tasks can handle the list explicitly. This thread seems to have gone off on a tangent after the correct fix has already been indentified and committed by Emilio. -- see shy jo signature.asc Description: Digital signature
Bug#718855: network-manager-gnome - full gnome recommends chain
network-manager-gnome recommnds gnome-bluetooth recommends gnome-control-center recommends gnome-session Not sure what to do about this. gnome-bluetooth seems to have that recommends because its control panel was moved into gnome-control-center and is presumably used by its UI. Perhaps gnome-control-center does not need to recommend gnome-session? The only change we could make in tasksel is switch !gnome to wicd, but last I tried it, it was not as good a choice for the average desktop user. Threads on debian-user indicate this is highly confusing behavior to users who install XFCE and end up with a default login to gnome. (So much so that they seem to think it also affects stable, which I highly doubt, especially since alcohol was involved in some of the users' testing.) -- see shy jo signature.asc Description: Digital signature
Bug#721869: install appropriate linux-headers
Bjørn Mork wrote: Really? I seriously doubt that. It's about as good as making it easier for the users to replace the default libc or init system with a non- Debian package. I have never needed to replace libc in order to make my laptop's wifi work. -- see shy jo signature.asc Description: Digital signature
Re: Bug#721869: install appropriate linux-headers
Bjørn Mork wrote: Joey Hess jo...@debian.org writes: Bjørn Mork wrote: Really? I seriously doubt that. It's about as good as making it easier for the users to replace the default libc or init system with a non- Debian package. I have never needed to replace libc in order to make my laptop's wifi work. *I* have never needed to build an out-of-tree module to make my laptop's wifi work. We can continue like this if you want. Or maybe you'd like to define your problem instead of your solution? I think I will leave this subthread where it lies. I doubt that many other people will have difficulty understanding my point; perhaps one of them will even explain it to you. -- see shy jo signature.asc Description: Digital signature
Bug#721869: install appropriate linux-headers
Dmitrijs Ledkovs wrote: I managed to compiled because I joyfully discovered that default Ubuntu installations do install gcc and linux-headers unconditionally. Noticing a this laptop worked for me on Ubuntu page that treated installing necessary out of kernel modules as (rightly) no big deal, and comparing it to general experiences with it being a PITA in a similar situation with Debian was part of my reason for concluding this should be done. Note that if the user installed Debian from a USB stick with no network, they are left with an apt configuration that does not allow apt-get install to work after the installation even if the USB stick is plugged in. This would be nice to fix in general, but leaving the user with everything they are going to need to get a network connection pre-installed is a reasonable workaround for d-i to make. It may make sense to only do it if d-i detects there is no network. At least lack of networking is the most annoying case. This would also give it a rationalle for installing make and gcc. (IIRC discover already installs this stuff if it detects hardware that is supported by out of tree modules packaged in Debian, which it automatically builds from source.) -- see shy jo signature.asc Description: Digital signature
installation reports and wiki
Recently buying a laptop, I found https://wiki.debian.org/InstallingDebianOn a rather useful resource. Rather than filing a successful installation report, it seemed better to add a page there (and file individual bugs for minor issues encountered with the install). Seems that this would be a useful thing to point users at both pre and post install. One immediate easy idea I have is that, when closing a successful installation report, suggest that the user might create or add to the page in the wiki for their hardware. -- see shy jo signature.asc Description: Digital signature
Re: loop-mounted ISO images
ian_br...@fastmail.net wrote: Is there some boot parameter that can be given to the Debian installer initrd to make it understand that it's running from a loop-mounted ISO image file rather than a plain block device? This is a well established feature in some distributions; for example, in Ubuntu, the relevant parameter is iso-scan/filename=FILENAME. iso-scan is part of the Debian installer[1]. However, it is only included in the hd-media initrd. There is no reason to include it on the regular CD initrd, because isohybrid allows mounting the USB stick directly. (Not a loop-mount of an iso file included in some disk, which the hd-media initrd handles.) http://www.debian.org/releases/stable/amd64/ch04s03.html.en#usb-copy-easy http://http.us.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/hd-media/ -- see shy jo [1] I wrote it. Always nice to have my Debian work cited as another reason Ubuntu is better than Debian! signature.asc Description: Digital signature
Bug#721869: install appropriate linux-headers
Package: base-installer Severity: normal The CD images include linux-headers packages, but d-i does not install these by default. I think that it should, so that if the user needs to build out of tree kernel modules they don't need to jump through the additional hoops of learning that Debian has separated kernel headers and how to install them. If we begin installing it by default, users should come to just expect that they can build kernel modules from source without doing anything more than a make, which will be a good thing. -- see shy jo signature.asc Description: Digital signature
Re: status of d-i development -- call for help?
Christian PERRIER wrote: OK, let's throw out a few ideas in the wild. Bug triaging could be a good start. Holger did a lot of work recently with installation reports and confirmed me that he will continue after DebConf. Some progress could be made by looking at bugs already assigned to soem D-I components. I'd suggest focusing on components that are used in the standard installation process (localechooser, console-setup, choose-mirror, partman-base, partman-useful_filesystems (and forget about toy filesystems), partman-crypto, partman-auto, partman-auto-crypto, base-installer, apt-setup, finish-install, etc.) Localization can get mor ehelp. Some languages are more or less abandoned with nobody maintaining them anymore. I can provide a list of these. Nearly all non i386 and amd64 ports of D-I are in very loose shape. Maybe more attention could be drawn to the non-toy ports (arm|armel?). Processing installation manual bug reports is also interesting and can lead to better results. This is basically where the boot-floppies were when I started d-i. My origial design goal for d-i was that due to the modularity, individual maintainers or small teams would become maintainers for particular packages relevant to them. This has the benefit that we can use all the regular ways Debian uses to handle keeping important (or not so important) packages maintained by someone. This has not happened a whole lot, but it has happened enough that it still seems feasable. For example, we have the debian-live team handling most of live-installer (and debian-installer-launcher), and the glibc and tools etc maintainers handling providing udebs from their packages. Reasons it has not happened more: * We've built a fair amount of d-i infrastructure, like the l10n, that needs a central management like bubulle. * d-i was in svn and cvs for a long time, and all of it was in a single repo, which encouraged a centralized development model. Now mostly fixed, although most of the udeb packages are still in the d-i alioth group. * d-i has turned out to be not completely trivial for existing package maintainers to learn. They need to learn some special cdebconf stuff, some best practices (?) for monstrous shell scripts, and various other stuff. * It's a PITA to build and test changes to udebs in d-i. But much less than it used to be, with now kvm fast on every laptop except for mine. I still think we could move in the direction of individual d-i packages being maintained by more separate small teams, not all of whom would need to have a full knowledge of other parts of d-i. * busybox could easily be moved out of d-i. Many people would be interested in maintaining it, even if we just orphaned it! Our requirements for it are fairly small (and could be handled by filing bug reports when needed). * debootstrap likewise; many maintainers of other packages have reasons to want it to work, even if they are not interested in maintaining d-i. * bootloader installers could be maintained by the same maintainers of the bootloaders they install. This really makes sense; it's quite hard for general d-i developers to test something like colo-installer, but a bootloader maintainer should have a test rig. * The kfreebsd-kernel udebs could be handled by the kfreebsd kernel maintainers, as has already happened with the linux kernel udebs. * user-setup could be maintained by the shadow/passwd maintainers (not only bubulle..) * Packages like console-setup seem obscure, but produce debs as well as udebs, and are installed on hundreds of thousands to millions of systems. It should be possible to grow a separate team around them. * Similarly, os-prober has a user/developer base that includes not only Debian but other distributions! And many bootloader maintainers should be interested in keeping it working, since their bootloader configurators use it. * flash-kernel is used post-install on many embedded devices; the people interested in embedded debian have an incentive to maintain it. * laptop-detect does not produce udebs at all only debs, and some other debs rdepend on them.. Just the above already drops us from 108 to something like 80 packages. 30 of those are partman, which is its own problem. Forming a partman subteam (or generally, an installer partitioning team), might be a feasable idea. Partman has a learning curve, but once you're over it, it's not very hard to work on, as long as you can keep it in your head and not need to swap it out for other parts of d-i. (Happened to me.) The remaining packages after all the above pruning: debian-installer/ localechooser/ debian-installer-manual/lowmem/ anna/ lvmcfg/ apt-setup/ main-menu/ auto-install/ mdcfg/ base-installer/ media-retriever/ bterm-unifont/
Re: Plan of action for Secure Boot support
Cyril Brulebois wrote: (Sorry, I'm new to all this) do you mean (1) the regular linux image packages are getting a signature added, and we're using those like we do today, or (2) that we'll have additional linux image packages with the signatures to be used instead of the usual linux image packages when a Secure Boot environment is detected? (or (3) something else…) The secure boot shim is a small bootloader. It's the only part that absolutely needs to be signed by MS, AIUI. It was designed to facilitate distributions in our position. Signed versions are also already available, produced by DD Matthew Garret, though not as Debian packages (perhaps he could be convinced to maintain it?) http://mjg59.dreamwidth.org/20303.html http://www.codon.org.uk/~mjg59/shim-signed/ (Assuming the plan is to use Matthew's shim and not the other one created by IIRC, the Linux Foundation.) -- see shy jo signature.asc Description: Digital signature
Re: Move desktop type selection from kernel parameter to debconf question?
Petter Reinholdtsen wrote: At the moment one can choose which of kde, gnome, lxde,xfce (and others?) should be installed using the desktop= kernel option to d-i, or by preseeding the tasksel/desktop debconf value. But I've seen requests for a normal debconf question instead, and implemented a new udeb this evening to allow this to happen. It is in the d-i git repository, URL: ssh://git.debian.org/git/d-i/desktop-chooser.git . If this is part of d-i, the repository should be added to the top-level .mrconfig file in d-i, so it is checked out with the rest. The template text need more work That's the entire reason that tasksel does not prompt the user to choose between desktop environments. They are not describable in a few sentences, so the user who is not already familiar with them is left with a technical choice which they are not qualified to make. d-i's main UI goal is to avoid presenting the user with a long series of such choices. -- see shy jo signature.asc Description: Digital signature
Bug#432309: should check Release signature by default?
Christoph Anton Mitterer wrote: So I suggest that it should be changed the follwing way,... that if no --keyring is given, neither debian-archive-keyring is installed (and usable)... debootstrap should fail (unless --no-check-gpg is given). I don't think this will break a lot, as most systems will probably have debian-archive-keyring installed. debootstrap is used on a wide variety of non-debian systems, which do not have it installed, and probably have no trust path to securely install the debian keyring. Given that apt already depends on debian-archive-keyring, it's unlikely that a debian system does not have it installed. -- see shy jo signature.asc Description: Digital signature
Bug#432309: should check Release signature by default?
Christoph Anton Mitterer wrote: I don't see why this should cause a problem... AFAIU, right now it must have already hardcoded the default keyring for the distro it was built for, right? i.e. on Debian /usr/share/keyrings/debian-archive-keyring.gpg So if such keyring was specified during build... it should strictly require it as I've mentioned before... (unless another --keyring or --no-check-gpg is given) If it's built for *buntu it should strictly ... the same just perhaps with: I'm not talking about building debootstrap to bootstrap some other linux distribution. I'm talking about the common practice of using it to bootstrap debian from other linux distributions. -- see shy jo signature.asc Description: Digital signature
Bug#714107: deboostrap gpg fatal error 'Bad address' with wheezy and sid on QNAP
virtualdj wrote: gpg: fatal: can't disable core dumps: Bad address [/share/HDA_DATA/debootstrap] # uname -a Linux NAS 2.6.33.2 #1 SMP Fri Mar 2 04:25:15 CST 2012 i686 unknown This seems to be setrlimit(2) failing. Possibly an incompatability with the kernel version? There does not seem to be anything debootstrap can do here. It's not even running gpg; apt's postinst is. Reassigning to gnupg. -- see shy jo signature.asc Description: Digital signature
Re: Bug report on cdebconf: dpkg-preconfigure crashes with exit status 139
Alexandre Rebert wrote: We found a crash in dpkg-preconfigure contained in the cdebconf package. You are being contacted because your are listed as one of the maintainer of cdebconf. We are planning to submit the bug to the Debian bug tracking system in two weeks. We wanted to give you a heads-up, so that you some time to assess the seriousness of the bug before it is publicly disclosed. Well, this is a public mailing list. :) However, this is not an exploitable security hole. It relies on running dpkg-preconfigure with an empty (or mostly empty) environment. dpkg-preconfigure is only run by root on trusted packages. Here's a more minimal version: env -i /usr/lib/cdebconf/dpkg-preconfigure 1 I don't have time to investigate the code, but it's probably expecting something in environ that's cleared. -- see shy jo signature.asc Description: Digital signature
Bug#694886: debootstrap: Creates available file w/o Description fields
Petter Reinholdtsen wrote: Perhaps now, very early in the jessie release cycle, is a good time to fix it. I am not sure what is needed, otherwise I would provide a patch myself. My preferred fix would be to create an empty available file. However, I don't understand commit 9e7d96f50df440f1ce1432e44f774799d4e5c0c0, which seemed to add the file to make dpkg work when resolving pre-dependencies. Maybe Colin can shed some light on what's going on. -- see shy jo signature.asc Description: Digital signature
Re: ZFS support in partman-target
Cyril Brulebois wrote: In the absence of complaints, I've done that: - base-installer: branched zol from master, and reset master to where it was before the buggy merge. Thanks for your work. But, it is not necessary or a good idea to ever modify the history of published git repositories. Doing so requires every d-i developer who may have done a git pull at the wrong time, let alone those of us who run infrastructure that automatically periodically pulls (or worse, pushes), to manually investigate and fix up their repositories. Our time is valuable. The d-i history contains much uglier stuff than this, and its existance bothers us not at all in our day-to-day work. joey@wren:~/src/d-i/installergit log |grep revert| wc -l 89 joey@wren:~/src/d-i/packages/base-installergit log |grep -i revert |wc -l 25 The right thing to do is to produce a single commit reverting the changes $last_good_commit..HEAD I have done this in the base-installer repository. It's a little tricky to revert a merge, so here's how: joey@wren:~/src/d-i/packages/base-installergit revert -m 2 59ca4efdf61e32e54430f56cbeb84e8f54e4c9ec [master 5f5a01b] Revert Merge branch 'master' of git://git.debian.org/d-i/base-installer 2 files changed, 7 insertions(+), 39 deletions(-) joey@wren:~/src/d-i/packages/base-installergit diff HEAD..1.132 | wc -l 0 I have pushed this. - debian-installer: branched zol from master, and reset master to where it was. joey@wren:~/src/d-i/installergit revert d8ef3f7047a005aced83ce77d88fb9952b3fea7e [master 978ef6d] Revert Add spl and zfs modules, zfsutils-udeb and partman-zfs for AMD64 configs. 9 files changed, 25 deletions(-) Also pushed. -- see shy jo, observing that we cannot learn much from history that has had the bad parts airbrushed out of it signature.asc Description: Digital signature
Re: ZFS support in partman-target
Cyril Brulebois wrote: Thanks for those (and sorry for the IRC bit, that came out in the wrong way). grub-installer wants something similar (it was only seen / mentioned on IRC, not in any mail IIRC). Will do once I'm done with real life things, if you don't beat me to it. Done. -- see shy jo signature.asc Description: Digital signature
Bug#708771: debootstrap: pkgdetails.c is missing
Kurt Roeckx wrote: Trying to run debootstrap on a system without perl, I get the following error: E: No pkgdetails available; either install perl, or build pkgdetails.c from source But I can't find pkgdetails.c It's in the bootstrap-base udeb. Normally only used in d-i. -- see shy jo signature.asc Description: Digital signature
Bug#707137: pu: package tasksel/3.14.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Unfortunately, wheezy shipped with a tasksel that, on a desktop system, selects both the desktop and the ssh server tasks for installation by default. This was not intentional. The intent was to default to selecting the desktop task on desktop systems, and the ssh server task on all other systems. A typo in the code prevented this from working correctly, and apparently I was the only one who was aware of how it was intended to work, and I was not able to participate in testing wheezy installations prior to release. I only learned of this issue on wheezy release day when observing users mentioning that both tasks were selected. This is not a good behavior to have in stable, because a user who is not paying much attention can end up with a ssh server installed unintentionally, and be vulnerable to automated password probes. We can assume that users who are installing servers a) intend to run ssh (or will notice and de-select it if not) and b) can take responsibility for using it securely. But not so for all desktop users. I have uploaded tasksel to s-p-u with this patch. I recommend it be included in the next point release. diff --git a/debian/changelog b/debian/changelog index 5e17347..2d20341 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +tasksel (3.14.1) stable; urgency=low + + * Fix broken test for non-desktop systems which caused the ssh server task +to be selected by default on systems with a desktop. + + -- Joey Hess jo...@debian.org Tue, 07 May 2013 13:57:43 -0400 + tasksel (3.14+nmu2) unstable; urgency=low * Downgrade network-manager-gnome from Depends to Recommends. It's diff --git a/tests/server b/tests/server index e8ca610..3aeff7c 100755 --- a/tests/server +++ b/tests/server @@ -1,7 +1,12 @@ #!/bin/sh + +if ! [ $NEW_INSTALL ]; then + exit 3 +fi + /usr/lib/tasksel/tests/desktop ret=$? -case ret in +case $ret in 0|2) # is desktop exit 3 # not server ;; -- see shy jo signature.asc Description: Digital signature
Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda
Vincent McIntyre wrote: I found the string, in po/sublevel1, here's the templates.po #. Type: select #. Choices #: ../choose-mirror-bin.templates.http-in:2001 #: ../choose-mirror-bin.templates.ftp.sel-in:2001 msgid enter information manually msgstr Is it the case that I need to a) give a unique number to the new question in grub-installer/po/templates.pot A cron job should take care of this, as long as an identical string is used in the templates file. -- see shy jo signature.asc Description: Digital signature
Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda
Vincent McIntyre wrote: It's entirely possible this patch is not the full resolution of the various issues people have reported but I'm posting it to get feedback on the approach and get some help with correctly integrating it into d-i. This adds a new translatable template, which it is far too late in the release process to get translated. I think this problem could be finessed by copying the text of the short description and first paragraph of the grub-installer/bootdev template. (Ideally into a common template that is SUBSTED into both to avoid bloat.) There are also some hardcoded user-visible strings embedded in the code, which need to be a) moved to the template and b) somehow translated 3 months ago. I don't think that (An entry dialog will appear) adds anything to the $manual_entry string (Enter device manually). There is an enter information manually string in choose-mirror that could be copied, with full translations. device_list() builds a comma-delimited list; it could be that the description of a device contains a comma (eg, Foo Corp, Inc. mega super drive), and so it needs to be sanitized. +# make sure this question is displayed at least once +db_fset grub-installer/choose_bootdev seen false That is unncessary in d-i; d-i always re-asks seen questions. (And it's very bad style to ever mess with seen flags, in any use of debconf. You will cause bugs that are hard to find.) -- see shy jo signature.asc Description: Digital signature
Bug#706112: debian-installer: Wheezy installer always install bootloader in /dev/sda
Gaudenz Steinlin wrote: Do you know how the problem can be triggerd. As far as I remember only some installation from USB are affected and I don't know if the difference between those affected and those unaffected has ever been identified. If I know that I'm testing the right test case, I'm willing to try your patch. Well, the patch always prompts with a menu, so essentially you don't need to reproduce the problem case to test it. I'd be more concerned about testing it on different architectures. Particularly ones without a /dev/disk/by-id/ -- see shy jo signature.asc Description: Digital signature
tasksel arch any? (Re: Bug#697890: iwconfig not in /sbin)
My concerns with going arch any would be that it becomes slower to make a tasksel change for some pressing concern, and this magnifies any installation breakage, or blockage caused by task dependencies. The same reason we keep debootstrap arch all. Also every divergence between architectures makes it that much harder to test that tasks are working. The same reason we avoid them in debootstrap when we can. Also, if we are going to depend on something linux-specific in a task, we could | depend on the freebsd equivilant too, and that should work with the task being arch all. If there is not a freebsd equivilant, we could | depend on something that documents how to do it the freebsd way. :P However, we mostly don't depend on things in tasks; we Recommend them. And recommends don't care if it's not available on some architecture. I don't necessarily think these are showstopper converns, but they need to be considered, and any alternatives to the problem considered. Re #697890, if we need iw, d-i should install it on appropriate machines. netcfg already installs wireless-tools when the interface is wireless. Not all machines with wifi are laptops, or even desktops, as was noted several times in that bug. Re #697868, I would much rather leave it to the maintainers of desktop environments (and/or Tech Ctte :P) to ensure that they have eg, necessary network-manager dependencies on appropriate architectures, rather than making tasksel need to track that. Reading that bug, the only reason task-gnome is depending on network-manager is to ensure it gets on CD#1. There are other ways to do that, particularly debian-cd's generate_di+k_list is appropriate since netcfg arranges for network-manager to be installed. -- see shy jo signature.asc Description: Digital signature
Re: tasksel arch any? (Re: Bug#697890: iwconfig not in /sbin)
Christian PERRIER wrote: Indeed, when committing these changes, I thought that, because that arch-dependent packages are added to Recommends and not Depend, it would not be a problem. Apparently it is. This is what slightly puzzles me, indeed. network-manager is currently listed in Depends. Oh, I didn't think this this was, but, indeed, as we already add wireless-tools through netcfg, I see not reason to not use the same concept to add iw when the (installation) interface is wireless (of course, one might argue what if the installation interface is wired and the system has wireless). Not a new argument of course... Yes, it was my first reaction : why not deal with that in the D.E. instead of dealing with it in tasksel. The need to be on CD#1 was what drove me to commit. If there are alternative solutions, yes we should consider them. debian-cd's generate-di+k_list should arrange for everything d-i needs to go onto CD#1. It would be appropriate to put iw in there, if netcfg installed it. My only concern with this and network-manager would be that it also adds those packages to the netinst. So it would be better to list network-manager in a task file, if it's necessary to get debian-cd to include it. It could be listed in tasks/sid/Debian-gnome. Sledge can probably make better suggestions. -- see shy jo signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee wrote: Sure seems like d-i is something we should build using the components of the release it will be contained in and not unstable... but I haven't tried to think hard about what that might imply that's problematic. And I certainly don't think this is something we should even consider changing at this late date in for wheezy release cycle! This is not desirable outside the freeze because packages in unstable that are used to build d-i then don't get tested until they land in testing. It might be desirable during the freeze. wiggle the d-i build processing to fetch syslinux from testing This can be done easily, just upload d-i to t-p-u. d-i uploads are already built with udebs from testing, for similar reasons. There seems to be an unholy fear of using t-p-u for anything these days, which I don't really understand. Even when not using it causes massive and unnecessary logjams in unstable during the freeze. -- see shy jo signature.asc Description: Digital signature
Bug#699742: Bug#699808: Bug#699742: Bug#699808: tech-ctte: syslinux vs the wheezy release
Steve McIntyre wrote: On Thu, Feb 07, 2013 at 07:52:13AM +0100, Daniel Baumann wrote: consider such a misfeature to be in critical need of a fix (iirc steve puts a local copy of the 'to be used' syslinux version to be used by debian-cd for release images manually on the local fs; not sure about the same that ends up in the final release copy of debian-installer-images, will check later on)). Correcting - that used to be the case several years ago, but debian-cd now explicitly extracts files from the syslinux(-common) package in the main archive at CD build time, using the same suite as used in d-i for consistency. Howver, that is not the only image provided by Debian that uses syslinux. The d-i mini.iso is another one, which uses the syslinux provided by d-i's Build-Depedency, ie the one from unstable. -- see shy jo signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee wrote: patch d-i to build successfully against the syslinux in sid syslinux is GPL'd, so this would result in shipping d-i images in wheezy which contain a GPL'd binary for which there is no source in wheezy. -- see shy jo signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Cyril Brulebois wrote: Joey Hess jo...@debian.org (07/02/2013): This can be done easily, just upload d-i to t-p-u. d-i uploads are already built with udebs from testing, for similar reasons. There seems to be an unholy fear of using t-p-u for anything these days, which I don't really understand. Even when not using it causes massive and unnecessary logjams in unstable during the freeze. fdf81293a6165c5d51397bb855d29...@mail.adsl.funky-badger.org Yes, that's a good example of spreading FUD aboput using t-p-u, rather than just using it and dealing with any breakage. -- see shy jo signature.asc Description: Digital signature
Bug#700026: maybe should have a Build-Depends: syslinux
Ansgar Burchardt wrote: in [1] it was mentioned that d-i embeds syslinux on some architectures, but the current version does not include syslinux in its Build-Using field. It might be helpful to include it there to ensure we always keep the source for the embedded version around. d-i embeds a large number of its build dependencies in images. Around 20 packages, with complex arch specifiers. There needs to be a declarative way to flag a build dependency as such, and have it automatically put into build-using. Any attempt to script this is going to result in a mess, busywork, and inconsistency. -- see shy jo signature.asc Description: Digital signature
Re: [Debconf-devel] Bug#679327: debian-installer: misleading man-db title for grub prompts
Cyril Brulebois wrote: So, finally tracked it down, confirming my initial suspicion: the triggers are doing that. Basically, we have debconf in target setting titles through the frontend script, even when maintainer scripts are called with the “triggered” action. I'm suggesting the attached patch, avoiding setting the title in that specific case. That doesn't affect debconf-apt-progress feedback: one still sees triggers being processed (and that's good since they can take a while). Confirmed by partial-cloning an archive, hacking hashsums and keyrings in place, and installing with that… [*crazy evening*] Does that look fine enough? If so, a quick upload to get that fixed in testing before publishing d-i wheezy rc1 would be nice. (I'll be replying to the debconf 1.5.48 unblock request in the meanwhile.) This seems acceptable for now. If a package used debconf for interaction in a trigger, it would then have the wrong title .. but until someone finds a reason for a package to need to do that, we can live with this patch. -- see shy jo signature.asc Description: Digital signature
Bug#694310: debootstrap: test-exec function does not work on android
Shawn Landden wrote: Please accept this patch making the test-exec function work on Android. It is against current git HEAD. Does Android really not have a /bin/sh? This would seem to also make the debootstap script not executable since it starts with #!/bin/sh. -- see shy jo, whose Android phone is dead. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121126162444.ga27...@gnu.kitenet.net
Bug#694310: debootstrap: test-exec function does not work on android
Shawn Landden wrote: here is a lighter-weight patch I've applied this, but I still wonder how the debootstrap script itself runs if there's no /bin/sh. -- see shy jo -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121126162849.gb27...@gnu.kitenet.net
Re: building and testing d-i with jenkins
Holger Levsen wrote: as you might have seen, I'm running certain d-i jobs on http://jenkins.debian.net/ There are three views showing d-i related jobs, which are http://jenkins.debian.net/view/d-i_packages/ http://jenkins.debian.net/view/d-i_manual/ http://jenkins.debian.net/view/d-i_misc/ You forgot to mention http://jenkins.debian.net/view/chroot-tests/ which all test debootstrap and task installs. * svn/trunk/packages - I have no idea what to build here, but I see frequent commits. Can you help? Of traslations to packages/po, presumably. Since these are in turn exploded out to the translations of individual packages that you already test, I don't think additional tests are needed here. * notifications - while jenkins does nice email notifications by default (it sends mail on every failure and when a build succeeds, it informs once and then it shuts up til the next failure), I think it's better to start with IRC notifications in #debian-boot - what do you think? If IRC notifications tend to come shortly after commit notifications, I think using IRC makes sense. I'd like to see debootstrap failure notifications sent to debian-devel, or someplace like that. It can be caused by breakage in a great many packages, and getting Debian as a whole to own keeping debootstap and task installs working would take some load off of d-i. Thanks for your work. Very much appreciated. -- see shy jo signature.asc Description: Digital signature
