please unblock rdate 1:1.2-3 (udeb)
please unblock rdate 1:1.2-3 (udeb) Changes: rdate (1:1.2-3) unstable; urgency=low . [ Cyril Brulebois ] * Use arc4random from libbsd: - Add patch to drop the embedded code copy: 08-538695-use-libbsd.patch - Add libbsd-dev to Build-Depends. - Closes: 538695 . [ Anibal Monsalve Salazar ] * Standards-Version is 3.8.2 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [d-i on kfreebsd] quick status report
Am Samstag, den 08.08.2009, 21:06 +0200 schrieb Robert Millan:
On Fri, Aug 07, 2009 at 08:53:06AM +0200, Felix Zielcke wrote:
--- grub-installer (revision 60026)
+++ grub-installer (working copy)
@@ -115,7 +115,7 @@ convert () {
tmp_disk=$(echo $1 | sed 's%\([sh]d[0-9]*\).*%\1%')
tmp_part=$(echo $1 | sed s%$tmp_disk%%)
;;
- freebsd*)
+ freebsd*|gnu/kfreebsd*)
tmp_disk=$(echo $1 | sed 's%r\{0,1\}\([saw]d[0-9]*\).*$%r\1%'
| \
sed 's%r\{0,1\}\(da[0-9]*\).*$%r\1%')
tmp_part=$(echo $1 | \
@@ -166,7 +166,7 @@ convert () {
fi
echo $tmp_drive
;;
- freebsd*)
+ freebsd*|gnu/kfreebsd*)
if echo $tmp_part | grep ^s /dev/null; then
tmp_pc_slice=$(echo $tmp_part | \
sed s%s\([0-9]*\)[a-h]*$%\1%)
I think the convert() function is only used for GRUB Legacy.
Ah I didn't looked it up before.
convert() gets only used for the os-prober entrys, but there for both
grub-legacy and grub2.
grub-probe is still not used.
--
Felix Zielcke
Proud Debian Maintainer
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bugs in the latest Debian Sid installer
Quoting Uwe Bugla (uwe.bu...@gmx.de): Hi everybody, using the Debian testing installer from 4th August I stumbled over the follwing bugs: 1. console-data is missing in the list of necessary dependencies when you install the basic system: The consequence is: You are trapped if you owe a non-American keyboard with a qwertz layout. That complicates the installation process enourmously instead of simplifying it. We're in the middle of a transition to console-setup. console-data should not be needed anymore. Still, it's not expected that you end up with an unconfigured keymap layout. Does the installed system *have* console-setup installed? It should have picked up the settings you made, in D-I, for the keymap (in your case, I suspect you picked 'German') and, thus, you should have a working keyboard layout on the installed system. In any case, dpkg-reconfigure console-setup on the installed system should help. But, still, that has to be investigated as this is obviously a big regression. I'm not in position to do so, being half-dialup as of now. Hopefully, someone else will. In the meantime, it would be good to mention this in http://wiki.debian.org/DebianInstaller/ConsoleSetupSwitch (Again, I'm not in position to do that right nowwill try to remember later when online) 2. At the point where the keyboard is being adjusted to the UTF-8 locale the script of the non-graphical installer (expert installation chosen in that specific case) hangs up the whole installation process. Only the graphical expert installation oversteps that installation step successively. 3. This is quite an old bug, and I really wonder why noone complained mentioning this one: It is impossible to set up a server / router with this installer containing more than one NIC, no matter if you chose graphical or non-graphical installer: In my personal example eth0 is connected to a highspeed modem. That's why I chose automatic DHCP configuration for the first NIC. Eth1 is configured staticallly by my own choice, that means DHCP with fixed addresses for the server and the workstations. The installer is incapable to handle more than one NIC, which is a mess! For my personal usage that means that I am forced to completely ignore the second NIC during the installation process. When installation is complete I am forced to reconfigure the whole network part of my server / router manually, i. e. using an ordinary editor. This state is quite insufficient and thus unacceptable. This is by design, in order to keep the installer simple to use and not confusing to less experienced users. So, by design, the only configured interface is the one that's used for the installation of the machine. Users who want to configure more than one interface are indeed expected to be able to do it after the install, by the usual methods. We really don't want to have *any* owner of a modern laptop (that has two NICs) to be prompted for the setting of his|her two interfaces. An additional menu point to adjust /etc/apt/sources.list to one's own personal needs would be very helpful as a part of such an installer. Here again, this is much out of scope of the installer. It is left to the post-install polishing of the installed machine, when the machine's admin is supposed to be skilled enough to know how to do this. signature.asc Description: Digital signature
Re: Install from ISO for Xen guest
On Friday 07 August 2009, Ian Campbell wrote: diff --git a/installer/build/boot/x86/xen/xm-debian.cfg b/installer/build/boot/x86/xen/xm-debian.cfg index d1d78e7..7c3ff51 100644 --- a/installer/build/boot/x86/xen/xm-debian.cfg +++ b/installer/build/boot/x86/xen/xm-debian.cfg The patch for this file introduces trailing whitespace in several places. diff --git a/installer/build/config/amd64/cdrom-xen.cfg b/installer/build/config/amd64/cdrom-xen.cfg new file mode 100644 index 000..3f03e74 --- /dev/null +++ b/installer/build/config/amd64/cdrom-xen.cfg @@ -0,0 +1,13 @@ +TYPE=cdrom/gtk + +EXTRANAME=cdrom/xen/ + +MANIFEST-KERNEL = kernel image for installing under Xen +MANIFEST-INITRD = initrd for installing under Xen +MANIFEST-XENCFG = example Xen configuration + +TARGET = $(KERNEL) $(INITRD) xen_config +SYMLINK_KERNEL = ../vmlinuz +SYMLINK_INITRD = ../gtk/initrd.gz + +EXTRATARGETS = build_cdrom-gtk This should be 'EXTRATARGETS = build_cdrom_gtk' (underscore, not hyphen). I've been wondering if the cdrom-xen target should be built automatically with the cdrom_isolinux target, but I guess that has both advantages and disadvantages. In the end I'm OK with having it as a separate top-level variant. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install from ISO for Xen guest
On Sun, 2009-08-09 at 11:32 +0200, Frans Pop wrote: On Friday 07 August 2009, Ian Campbell wrote: diff --git a/installer/build/boot/x86/xen/xm-debian.cfg b/installer/build/boot/x86/xen/xm-debian.cfg index d1d78e7..7c3ff51 100644 --- a/installer/build/boot/x86/xen/xm-debian.cfg +++ b/installer/build/boot/x86/xen/xm-debian.cfg The patch for this file introduces trailing whitespace in several places. diff --git a/installer/build/config/amd64/cdrom-xen.cfg b/installer/build/config/amd64/cdrom-xen.cfg new file mode 100644 index 000..3f03e74 --- /dev/null +++ b/installer/build/config/amd64/cdrom-xen.cfg @@ -0,0 +1,13 @@ +TYPE=cdrom/gtk + +EXTRANAME=cdrom/xen/ + +MANIFEST-KERNEL = kernel image for installing under Xen +MANIFEST-INITRD = initrd for installing under Xen +MANIFEST-XENCFG = example Xen configuration + +TARGET = $(KERNEL) $(INITRD) xen_config +SYMLINK_KERNEL = ../vmlinuz +SYMLINK_INITRD = ../gtk/initrd.gz + +EXTRATARGETS = build_cdrom-gtk This should be 'EXTRATARGETS = build_cdrom_gtk' (underscore, not hyphen). Oh yes, strange that I didn't see an error. I guess I got lucky by using all_build so cdrom_gtk had always already been built or something. The amd64 netboot-xen which is already committed has the same problem -- I'll fix that right away. I've been wondering if the cdrom-xen target should be built automatically with the cdrom_isolinux target, but I guess that has both advantages and disadvantages. In the end I'm OK with having it as a separate top-level variant. I have no particular preference myself. Ian. -- Ian Campbell All's well that ends. signature.asc Description: This is a digitally signed message part
Re: Install from ISO for Xen guest
On Sun, 2009-08-09 at 11:16 +0100, Ian Campbell wrote: The amd64 netboot-xen which is already committed has the same problem -- I'll fix that right away. My mistake, it really is cdrom_gtk and netboot-gtk... Ian. -- Ian Campbell BOFH excuse #420: Feature was not beta tested signature.asc Description: This is a digitally signed message part
Bug#467322: marked as done (totem-mozilla is in gnome-desktop, but iceweasel is in desktop)
Your message dated Sun, 9 Aug 2009 11:40:18 +0200 with message-id 20090809094017.gl8...@mykerinos.kheops.frmug.org and subject line totem-mozilla no longer belongs to gnome-desktop report has caused the Debian Bug report #467322, regarding totem-mozilla is in gnome-desktop, but iceweasel is in desktop to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 467322: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467322 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: tasksel Version: 2.71 Severity: normal Tags: patch totem-mozilla is in gnome-desktop, but iceweasel is in desktop. Since totem-mozilla is useful with iceweasel, I think it should be in desktop, too, so that picking kde-desktop / xfce-desktop doesn't exclude it. (at least for Xfce; not sure if KDE provides its own alternative, but I didn't see it) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18-6-amd64 (SMP w/2 CPU cores) Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tasksel depends on: ii aptitude 0.4.10-1+b1 terminal-based package manager ii debconf [debconf-2.0]1.5.19 Debian configuration management sy ii liblocale-gettext-perl 1.05-2 Using libc functions for internati ii tasksel-data 2.71Official tasks used for installati tasksel recommends no packages. -- debconf information excluded diff -ur tasksel-2.73/tasks/desktop tasksel-2.73.totem/tasks/desktop --- tasksel-2.73/tasks/desktop 2008-02-14 12:28:57.0 +0100 +++ tasksel-2.73.totem/tasks/desktop2008-02-24 18:03:52.0 +0100 @@ -14,6 +14,8 @@ # firefox (ne iceweasel) is the most popular web browser at the moment, # although both gnome and kde offer their own too iceweasel +# allow video playback in mozilla/xulrunner browsers + totem-mozilla # hardware detection discover1 xresprobe diff -ur tasksel-2.73/tasks/gnome-desktop tasksel-2.73.totem/tasks/gnome-desktop --- tasksel-2.73/tasks/gnome-desktop2008-02-11 13:27:26.0 +0100 +++ tasksel-2.73.totem/tasks/gnome-desktop 2008-02-24 18:03:45.0 +0100 @@ -21,8 +21,6 @@ # rhythmbox and gstreamer plugins rhythmbox gstreamer0.10-ffmpeg -# allow video playback in mozilla/xulrunner browsers - totem-mozilla # enable debian menus menu-xdg # partition editing ---End Message--- ---BeginMessage--- Version: 2.75 As stated by Joey when answering this bug report, totem-mozilla belonged to gnome-desktop because totem is a GNOME app. That should have been enough to close the bug report. The remark by Robert about possible similar packages for KDE of Xfce may be valid but I think that, anyway, a pointer to such package should have been given. Anyway, this bug is no longer relevant as totem-mozilla is no longer part of the gnome-desktop task..:-) -- signature.asc Description: Digital signature ---End Message---
Bug#410355: marked as done (inconsistent behaviors between --task-packages desktop and install desktop)
Your message dated Sun, 9 Aug 2009 11:56:56 +0200 with message-id 20090809095656.gm8...@mykerinos.kheops.frmug.org and subject line Not a bug, IMHO has caused the Debian Bug report #410355, regarding inconsistent behaviors between --task-packages desktop and install desktop to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 410355: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410355 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: tasksel Version: 2.66 Severity: normal When I tried to install the desktop task, tasksel went to install 400 packages, which I found surprising. When checking with --task-packages that install desktop really installed the desktop task and not Desktop environment, tasksel outputted the list of packages of the desktop task that I expected install desktop to install. However remaining download time made it clear that tasksel was installing gnome-desktop. I confirmed that with --test. There are two issues: it doesn't seem possible to install just the desktop task, plus install and --task-packages have inconsistent behaviors. This is made quite worst by the fact that debconf-apt-progress is not verbose about what it's doing and killing it is bastard. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Versions of packages tasksel depends on: ii aptitude 0.4.4-1terminal-based apt frontend ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii liblocale-gettext-perl1.05-1 Using libc functions for internati ii tasksel-data 2.66 Official tasks used for installati tasksel recommends no packages. -- debconf information: tasksel/title: * tasksel/first: standard tasksel/tasks: ---End Message--- ---BeginMessage--- Original bug report: When I tried to install the desktop task, tasksel went to install 400 packages, which I found surprising. When checking with --task-packages that install desktop really installed the desktop task and not Desktop environment, tasksel outputted the list of packages of the desktop task that I expected install desktop to install. However remaining download time made it clear that tasksel was installing gnome-desktop. I confirmed that with --test. There are two issues: it doesn't seem possible to install just the desktop task, plus install and --task-packages have inconsistent behaviors. This is made quite worst by the fact that debconf-apt-progress is not verbose about what it's doing and killing it is bastard. I think this bug report is just a misunderstanding. Choosing Desktop environment in D-I *really* installs gnome-desktop, by default, on standard CDs (on the KDE CD, it installs kde-desktop, etc.). This is by design. OTOH, tasksel --install dekstop installs the desktop task and not the gnome-desktop one. So, the comparison you then made was just wrong. -- signature.asc Description: Digital signature ---End Message---
Processed: Bug does no longer exist, imho
Processing commands for cont...@bugs.debian.org: tags 446416 unreproducible Bug #446416 [tasksel] tasksel: silent failures due to trailing whitespace Added tag(s) unreproducible. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#446416: Bug does no longer exist, imho
tags 446416 unreproducible thanks Hi Dann, Apparently, this old bug you reported back in 2007 hasa been ignored and no further investigation happened. I just tried to reprocude it, exactly the way you mentioned: r...@mykerinos:/etc/whereami# cat /usr/share/tasksel/dannf.desc Task: dannf Section: user Description: dannf long description Relevance: 10 Key: Packages: list hello Note the same trailing whitespace in synopsis. Then I launched taslsel --test and did choose the dannf task. r...@mykerinos:/etc/whereami# tasksel --test debconf-apt-progress -- aptitude -q -y install hello So, it seems that things are OK as of now... -- signature.asc Description: Digital signature
Re: UUID in fstab for device mapper devices?
On Sat, Aug 08, 2009 at 11:12:37PM +0200, Ferenc Wagner wrote:
Guido Günther a...@sigxcpu.org writes:
On Fri, Aug 07, 2009 at 04:28:46PM +0200, Max Vozeler wrote:
we recently changed d-i (partman-target, to be precise) to use
UUIDs in fstab in order to get stable device naming. [...]
Since then, we concluded that it is preferable to go back to plain
/dev/mapper/ paths for LVM LVs because those already provide stable
device naming (and are more descriptive).
And filesystem UUIDs are pretty useless as soon as you start using LVM
snapshots, dd backups or multipath for example.
ENV{DM_UUID}==mpath-*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}
[...]
This is what should idealy be used in d-i for multipath device naming.
We could then start to remove the hacks that use /dev/mapper/mpath* to
reference multipath devices then.
My limited experience shows that multipath uses unique /dev/mapper/WWID
device names by default, or the configured name, as Bastian mentioned.
Is that because I'm lucky, and other types of multipaths don't behave
so nice? Also, I haven't seen mpath-names apart from an obscure
multipath.conf option...
It uses the WWID, the configured name (via multipath.conf) or mpathX if
you set user_friendly_names=yes - which we currently use in d-i to have
an easy way to identify multipath devices.
Anyway, an unfortunate multipath/LVM interaction should also be
considered: without special configuration in lvm.conf, the PV scan
finds the LVM metadata on the individual paths as well as on the
multipath device, then tries to create mappings straight onto the
first path, skipping the multipath layer. Of course it fails, because
that device isn't available any more, but the error is rather hard to
diagnose from the initramfs prompt.
This can be fixed by preferring /dev/mapper/mpathX names.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
On Sat, Aug 08, 2009 at 04:03:38PM +0200, Max Vozeler wrote: Hi all, Attempt to summarize the discussion so far (please correct): 1) We should use /dev/mapper/ paths rather than UUID in the fstab entries for all device mapper devices. 2) For some type of device mapper devices (multipath), using the /dev/disk/by-id/ symlinks would be better than /dev/mapper/. The last point only makes sense if we work on a stable device naming with _and_ without multipath. I think Novell does this with /dev/disk/by-id/scsi-X-partY. This points to the underlying block device(s) (e.g. /dev/sda1) without multipath and points to /dev/mapper/wwwid-partY when turning on multipath. Looking at /dev/disk/by-uuid/ also seems to do the trick: it points to /dev/sdaY without and to /dev/mapper/wwid-partY with multipath. So if we'd use this turning multipath on and off would be transparent to the user. What's the reasoning for using UUID= instead of /dev/disk/by-uuid/ in fstab? Non udev systems? Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bugs in the latest Debian Sid installer
Am Sonntag 09 August 2009 08:22:54 schrieb Christian Perrier: Quoting Uwe Bugla (uwe.bu...@gmx.de): Hi everybody, Hello Christian, using the Debian testing installer from 4th August I stumbled over the follwing bugs: 1. console-data is missing in the list of necessary dependencies when you install the basic system: The consequence is: You are trapped if you owe a non-American keyboard with a qwertz layout. That complicates the installation process enourmously instead of simplifying it. We're in the middle of a transition to console-setup. console-data should not be needed anymore. Still, it's not expected that you end up with an unconfigured keymap layout. Does the installed system *have* console-setup installed? I did not find that out, so I guess the answer is No! It should have picked up the settings you made, in D-I, for the keymap (in your case, I suspect you picked 'German') and, thus, you should have a working keyboard layout on the installed system. I have an unusable keyboard layout on the installed system, unfortunately. After performing apt-get install console-data the keyboard layout is usable, but without performing that step the usage is a big pain! In any case, dpkg-reconfigure console-setup on the installed system should help. Sounds good, but is only helpful if you know that console-setup has been installed or not. How can I find that out? I will set up a couple of other workstations and I will keep on trying. But, still, that has to be investigated as this is obviously a big regression. I'm not in position to do so, being half-dialup as of now. Hopefully, someone else will. In the meantime, it would be good to mention this in http://wiki.debian.org/DebianInstaller/ConsoleSetupSwitch (Again, I'm not in position to do that right nowwill try to remember later when online) 2. At the point where the keyboard is being adjusted to the UTF-8 locale the script of the non-graphical installer (expert installation chosen in that specific case) hangs up the whole installation process. Only the graphical expert installation oversteps that installation step successively. 3. This is quite an old bug, and I really wonder why noone complained mentioning this one: It is impossible to set up a server / router with this installer containing more than one NIC, no matter if you chose graphical or non-graphical installer: In my personal example eth0 is connected to a highspeed modem. That's why I chose automatic DHCP configuration for the first NIC. Eth1 is configured staticallly by my own choice, that means DHCP with fixed addresses for the server and the workstations. The installer is incapable to handle more than one NIC, which is a mess! For my personal usage that means that I am forced to completely ignore the second NIC during the installation process. When installation is complete I am forced to reconfigure the whole network part of my server / router manually, i. e. using an ordinary editor. This state is quite insufficient and thus unacceptable. This is by design, in order to keep the installer simple to use and not confusing to less experienced users. So, by design, the only configured interface is the one that's used for the installation of the machine. Users who want to configure more than one interface are indeed expected to be able to do it after the install, by the usual methods. We really don't want to have *any* owner of a modern laptop (that has two NICs) to be prompted for the setting of his|her two interfaces. I cannot share that point of view: My position: Your point of view is fully OK for a standard install, no matter if console- based or graphical, adressing rookies and beginners. My point of view should fit for experienced users using the expert install, no matter if graphical or console based. But simplification in any case, and thus disregarding the different installer levels with their different sophistication is a point of view or guide line that I cannot and will not share at all... An additional menu point to adjust /etc/apt/sources.list to one's own personal needs would be very helpful as a part of such an installer. Here again, this is much out of scope of the installer. It is left to the post-install polishing of the installed machine, when the machine's admin is supposed to be skilled enough to know how to do this. I prefare to avoid the usage of editors. Thus it would make sense to add an additional point in the installer menu asking the user whether he wants to perform a Debian Sid installation or rather one based on the testing branch for which the installer was written: squeeze in this case. Installers are here to simplify necessary tasks, NOT to complicate them It's quite humble to say We don't want this and we don't want that or We expect the user to be qualified enough to ... I would not define myself as subqualified.
Bug#405737: Dear Email User,
Dear Email User, We are sorry to inform you that we are currently working on securing our server, during this process account which is not manually verified by us will be deleted, Please confirm and submit your information for manual verification by one of our customer care agents. Information which is to be provided for account verification is below. Please click on REPLY button first before attempting to fill the form: User Name:- User Id: --- Password: Date Of Birth: --- Country: --- Upon confirmation of information from you, we will manually verify your Yahoo! Account and reserve it not to be deleted, We are sorry for any inconveniences this might cause you. Bringing to you the best services is our primary objective. Warning!!! Account owner that refuses to update his/her account after two weeks of receiving this warning will lose his or her account permanently. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#405737: Dear Email User,
Dear Email User, We are sorry to inform you that we are currently working on securing our server, during this process account which is not manually verified by us will be deleted, Please confirm and submit your information for manual verification by one of our customer care agents. Information which is to be provided for account verification is below. Please click on REPLY button first before attempting to fill the form: User Name:- User Id: --- Password: Date Of Birth: --- Country: --- Upon confirmation of information from you, we will manually verify your Yahoo! Account and reserve it not to be deleted, We are sorry for any inconveniences this might cause you. Bringing to you the best services is our primary objective. Warning!!! Account owner that refuses to update his/her account after two weeks of receiving this warning will lose his or her account permanently. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#399840: Do we want an ssh-server task?
On Wed, Jul 29, 2009 at 01:14:52PM +0200, Frans Pop wrote: On Wednesday 29 July 2009, Christian Perrier wrote: An interesting proposal that Colin made was to converge towards a task named Login server or something similar, that would include openssh-server, along with other packages such as denyhosts (or sshguard), rssh (Restricted shell allowing scp, sftp, cvs, svn, rsync or rdist), molly-guard (protects machines from accidental shutdowns/reboots)... Most systems really only want ssh, not any of the rest. Is this assertion really true? My experience has been that quite a lot of people actually want something a bit more, even if they don't know it. openssh-server only Suggests those packages because I'm pretty conservative about pulling in extra packages, but I know an awful lot of sysadmins who want sshd for some kind of restricted sftp-only setup, or who want sshd and want to automatically lock out people who try to brute-force accounts, or similar. I genuinely think a task for this would be a good idea. Of course, we can quote unsupported anecdotes at each other all day. :-) Also, I doubt that anybody using D-I would have a clear idea of what a Login server task would actually contain, making it bad from a usability PoV. We should really make tasksel able to display extended descriptions of tasks. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFC: debhelper 7 conversions
Inspired by Joey's talk at DebConf, I've been working on converting all of d-i to debhelper 7. Obviously this can be done just by bumping the compat version and testing that the result is sane, but where it makes sense I'm trying to go the whole way and use dh(1). While this sometimes involves some non-trivial changes to the packaging (for instance, sometimes I needed to move things from debian/rules to Makefile), I think that on the whole it makes the packaging much simpler and less full of (IME often wrong) cargo-culting. Joey said at DebConf that the idea was that if you saw a package with nothing more than 'dh $@' then you knew it was a straightforward package with nothing weird going on, and each addition to that represented some kind of deviation from normality. I really like this model. CDBS tried something similar and I hated it because it was incredibly painful to figure out how to override its behaviour, but debhelper's documentation is excellent and it's really easy to start with 'man dh' and follow references to see how to override the behaviour of individual commands when it's necessary. In a few cases the necessary overrides get out of hand and it works out to be most comprehensible to continue using ordinary hand-written sequences of dh_* commands, but there seem to be relatively few of these. At this point I've gone through enough of it to be able to say with confidence that the bulk of our packaging is entirely formulaic. I've committed a few simple cases already, but I thought I'd best check with the list before going further and committing more from the pile of stuff I have on my laptop. I'm not sure that individual patch review would be all that interesting as it doesn't actually change the behaviour of d-i at all, but I'm more interested in opinions on the conversion in general. In particular, some packages do genuinely get complicated, and need override_* rules, which require debhelper 7.0.50 which isn't in stable (although there's a backport in lenny-backports). Would this cause anyone any serious inconvenience, or should we just go ahead and use the new tools? IIRC stable-and-a-half efforts mostly tend to use the installer from testing, which leaves things like Kenshi Muto's backports; at the moment I'm operating on the assumption that if somebody is doing something fairly heroic like backporting d-i, installing a backported debhelper probably won't be much of an imposition. Please shout if this is a bad assumption. I was planning to leave out the *-support packages, as well as live-installer which is currently using CDBS. Some packages present particularly interesting challenges, in that they require essentially formulaic overrides that would be best encapsulated by new debhelper commands. partman and the kernel udebs fall into this category. For these, I'm writing a dh-d-i debhelper addon (originally dh-partman, but Joey suggested renaming it so that it can cover other things we might want to do now or in future). Currently I'm planning for it to contain a utility to install directories with _numbers files, as used in partman and rescue, and a utility to replace /usr/share/kernel-wedge/generic-rules. Eventually this means that we should be able to converge on 'dh --with d-i $@' in rules files. Any comments? Thanks, -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [stable] Adding bnx2x driver in 5.0.3
dann frazier wrote: On Sat, Aug 08, 2009 at 03:18:53PM +0200, Luk Claes wrote: Otavio Salvador wrote: - Update kernel-wedge/stable to include bnx2x if available (are there space issues here?) The space usage is neglitable and I think it can be done with a very small risk of regressions. Be sure to use the kernel-wedge of lenny for building it since we've changed kernel-wedge a lot during the 2.6.30 migration and it is not suitable for the lenny usage. What's the status here? I can get this done tomorrow. Good. - Update d-i in 5.0.3 to incorporate this driver Yes, you got the picture right. I offer help if required. This can probably be done already when kernel-wedge is updated? Please don't delay when unnecessary, TIA. Do we have an estimate for 5.0.3 yet? Reason I ask is that there is typically always some kernel changes queued - security or otherwise. I do understand wanting to have p-u in an always-releasable state, but it can be a lot of throwaway work given that a security update would force us to do a complete rebuild. If we have a target date in mind I could work up a schedule (w/ buffer room) to make sure that all the pieces are in place ahead of time. In the past we have almost always redone d-i after a kernel upload, though that should only be necessary when d-i related changes or an ABI bump is included... Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bugs in the latest Debian Sid installer
Am Sonntag 09 August 2009 13:42:37 schrieb Uwe Bugla: Am Sonntag 09 August 2009 08:22:54 schrieb Christian Perrier: Quoting Uwe Bugla (uwe.bu...@gmx.de): Hi everybody, Hello Christian, using the Debian testing installer from 4th August I stumbled over the follwing bugs: 1. console-data is missing in the list of necessary dependencies when you install the basic system: The consequence is: You are trapped if you owe a non-American keyboard with a qwertz layout. That complicates the installation process enourmously instead of simplifying it. We're in the middle of a transition to console-setup. console-data should not be needed anymore. Still, it's not expected that you end up with an unconfigured keymap layout. Does the installed system *have* console-setup installed? I did not find that out, so I guess the answer is No! It should have picked up the settings you made, in D-I, for the keymap (in your case, I suspect you picked 'German') and, thus, you should have a working keyboard layout on the installed system. I have an unusable keyboard layout on the installed system, unfortunately. After performing apt-get install console-data the keyboard layout is usable, but without performing that step the usage is a big pain! In any case, dpkg-reconfigure console-setup on the installed system should help. Sounds good, but is only helpful if you know that console-setup has been installed or not. How can I find that out? I will set up a couple of other workstations and I will keep on trying. But, still, that has to be investigated as this is obviously a big regression. I'm not in position to do so, being half-dialup as of now. Hopefully, someone else will. In the meantime, it would be good to mention this in http://wiki.debian.org/DebianInstaller/ConsoleSetupSwitch (Again, I'm not in position to do that right nowwill try to remember later when online) 2. At the point where the keyboard is being adjusted to the UTF-8 locale the script of the non-graphical installer (expert installation chosen in that specific case) hangs up the whole installation process. Only the graphical expert installation oversteps that installation step successively. 3. This is quite an old bug, and I really wonder why noone complained mentioning this one: It is impossible to set up a server / router with this installer containing more than one NIC, no matter if you chose graphical or non-graphical installer: In my personal example eth0 is connected to a highspeed modem. That's why I chose automatic DHCP configuration for the first NIC. Eth1 is configured staticallly by my own choice, that means DHCP with fixed addresses for the server and the workstations. The installer is incapable to handle more than one NIC, which is a mess! For my personal usage that means that I am forced to completely ignore the second NIC during the installation process. When installation is complete I am forced to reconfigure the whole network part of my server / router manually, i. e. using an ordinary editor. This state is quite insufficient and thus unacceptable. This is by design, in order to keep the installer simple to use and not confusing to less experienced users. So, by design, the only configured interface is the one that's used for the installation of the machine. Users who want to configure more than one interface are indeed expected to be able to do it after the install, by the usual methods. We really don't want to have *any* owner of a modern laptop (that has two NICs) to be prompted for the setting of his|her two interfaces. I cannot share that point of view: My position: Your point of view is fully OK for a standard install, no matter if console- based or graphical, adressing rookies and beginners. My point of view should fit for experienced users using the expert install, no matter if graphical or console based. But simplification in any case, and thus disregarding the different installer levels with their different sophistication is a point of view or guide line that I cannot and will not share at all... An additional menu point to adjust /etc/apt/sources.list to one's own personal needs would be very helpful as a part of such an installer. Here again, this is much out of scope of the installer. It is left to the post-install polishing of the installed machine, when the machine's admin is supposed to be skilled enough to know how to do this. I prefare to avoid the usage of editors. Thus it would make sense to add an additional point in the installer menu asking the user whether he wants to perform a Debian Sid installation or rather one based on the testing branch for which the installer was written: squeeze in this case. Installers are here to simplify necessary tasks, NOT to complicate them It's quite humble to say We
Bug#399840: Do we want an ssh-server task?
On Sunday 09 August 2009, Colin Watson wrote: On Wed, Jul 29, 2009 at 01:14:52PM +0200, Frans Pop wrote: On Wednesday 29 July 2009, Christian Perrier wrote: An interesting proposal that Colin made was to converge towards a task named Login server or something similar, that would include openssh-server, along with other packages such as denyhosts (or sshguard), rssh (Restricted shell allowing scp, sftp, cvs, svn, rsync or rdist), molly-guard (protects machines from accidental shutdowns/reboots)... Most systems really only want ssh, not any of the rest. Is this assertion really true? My experience has been that quite a lot of people actually want something a bit more, even if they don't know it. I've personally never installed any of the others on any of my systems, while I do have openssh-server installed on all of my systems. The actual request is to make it easier to have openssh-server installed so that users can straight away access the newly installed system over ssh, nothing more and nothing less. So IMO we need a task that does exactly that, and nothing more. It seems to me that anybody wanting to set up something like a login server or sftp server will be able to install any packages needed for that manually. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install from ISO for Xen guest
On Friday 07 August 2009, Ian Campbell wrote: I will follow up shortly with a short series of patches which introduces image variants to debian-cd and adds the Xen variant as an option for i386 and amd64 and a patch to the nightly cron jobs which enables this variant for the i386+amd64+powerpc multiarch netinst image. I've committed the debian-cd changes with a few very minor (style) corrections. The implementation is IMO quite nice and clean. The size increase from enabling the Xen variant for the m-a netinst is 55MB (main changes are ~20MB from the extra bigmem kernel image and ~30MB from added D-I kernels and initrds). This is a fairly big increase, but the multi-arch netinst can handle it. Ian: feel free to commit the changes for D-I (after the corrections) and when that's done I'll enable the Xen variant for the CD builds. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
Guido Günther a...@sigxcpu.org writes:
On Sat, Aug 08, 2009 at 11:12:37PM +0200, Ferenc Wagner wrote:
Guido Günther a...@sigxcpu.org writes:
On Fri, Aug 07, 2009 at 04:28:46PM +0200, Max Vozeler wrote:
we recently changed d-i (partman-target, to be precise) to use
UUIDs in fstab in order to get stable device naming. [...]
Since then, we concluded that it is preferable to go back to plain
/dev/mapper/ paths for LVM LVs because those already provide stable
device naming (and are more descriptive).
And filesystem UUIDs are pretty useless as soon as you start using LVM
snapshots, dd backups or multipath for example.
ENV{DM_UUID}==mpath-*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}
[...]
This is what should idealy be used in d-i for multipath device naming.
We could then start to remove the hacks that use /dev/mapper/mpath* to
reference multipath devices then.
My limited experience shows that multipath uses unique /dev/mapper/WWID
device names by default, or the configured name, as Bastian mentioned.
Is that because I'm lucky, and other types of multipaths don't behave
so nice? Also, I haven't seen mpath-names apart from an obscure
multipath.conf option...
It uses the WWID, the configured name (via multipath.conf) or mpathX if
you set user_friendly_names=yes - which we currently use in d-i to have
an easy way to identify multipath devices.
OK, so the problem is identifying multipath devices in d-i. So that
option would be better called d-i_friendly_names, because from the
user PoV losing name persistence -- which this option implies --,
isn't friendly or useful, in my opinion. If only multipath used
mpath-WWID by default, running these circles around udev and by-id
would be unnecessary. Or if d-i used another way to find
multipath devices, like for example:
echo show maps | multipathd -k | sed '1d;s/ .*//'
Is doing something like that out of question? Changing the default
naming scheme may be too dangerous (altough I'm all for it :), but
getting rid of user_friendly_names would restore the general
persistence of device-mapper names.
Anyway, an unfortunate multipath/LVM interaction should also be
considered: without special configuration in lvm.conf, the PV scan
finds the LVM metadata on the individual paths as well as on the
multipath device, then tries to create mappings straight onto the
first path, skipping the multipath layer. Of course it fails, because
that device isn't available any more, but the error is rather hard to
diagnose from the initramfs prompt.
This can be fixed by preferring /dev/mapper/mpathX names.
Yes, but LVM does not prefer those currently, so the installed system
won't boot without further tweaking in such cases. I just wanted to
make sure this problem won't be overlooked.
--
Thanks,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Unblock glib2.0
On Sat, 2009-08-08 at 14:29 +0200, Emilio Pozuelo Monfort wrote: glib2.0 has been in unstable for 41 days, according to [1] Could it be unblocked so that it migrates to testing? Unblocked, after ack from Otavio. You'll need to get ftp-master to remove the old libgio-fam binaries on the Linux architectures before it will migrate though. Cheers, Adam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please unblock rdate 1:1.2-3 (udeb)
On Sun, 2009-08-09 at 17:19 +1000, Aníbal Monsalve Salazar wrote: please unblock rdate 1:1.2-3 (udeb) Unblocked after ack from Otavio. Cheers, Adam -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
On Sun, Aug 09, 2009 at 04:57:28PM +0200, Ferenc Wagner wrote: OK, so the problem is identifying multipath devices in d-i. So that option would be better called d-i_friendly_names, because from the user PoV losing name persistence -- which this option implies --, isn't friendly or useful, in my opinion. If only multipath used To avoid we're furhter talking past each other: which device names aren't persistent from your PoV when using user_friendly_names? Dropping user_friendly_names won't give you name persistence with and without mp all by itself. You'll either have to use disk/by-id or disk/by-uuid to achive that. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processing of kernel-wedge_2.53+lenny1_i386.changes
kernel-wedge_2.53+lenny1_i386.changes uploaded successfully to localhost along with the files: kernel-wedge_2.53+lenny1.dsc kernel-wedge_2.53+lenny1.tar.gz kernel-wedge_2.53+lenny1_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Install from ISO for Xen guest
On Sun, 2009-08-09 at 16:42 +0200, Frans Pop wrote: On Friday 07 August 2009, Ian Campbell wrote: I will follow up shortly with a short series of patches which introduces image variants to debian-cd and adds the Xen variant as an option for i386 and amd64 and a patch to the nightly cron jobs which enables this variant for the i386+amd64+powerpc multiarch netinst image. I've committed the debian-cd changes with a few very minor (style) corrections. The implementation is IMO quite nice and clean. Awesome. Thank you very much for the original guidance and all your input along the way. Ian: feel free to commit the changes for D-I (after the corrections) and when that's done I'll enable the Xen variant for the CD builds. Done. Cheers, Ian. -- Ian Campbell If it doesn't smell yet, it's pretty fresh. -- Dave Johnson, on dead seagulls signature.asc Description: This is a digitally signed message part
Re: Bugs in the latest Debian Sid installer
Am Sonntag 09 August 2009 15:05:53 schrieb Uwe Bugla: Am Sonntag 09 August 2009 13:42:37 schrieb Uwe Bugla: Am Sonntag 09 August 2009 08:22:54 schrieb Christian Perrier: Quoting Uwe Bugla (uwe.bu...@gmx.de): Hi everybody, Hello Christian, using the Debian testing installer from 4th August I stumbled over the follwing bugs: 1. console-data is missing in the list of necessary dependencies when you install the basic system: The consequence is: You are trapped if you owe a non-American keyboard with a qwertz layout. That complicates the installation process enourmously instead of simplifying it. We're in the middle of a transition to console-setup. console-data should not be needed anymore. Still, it's not expected that you end up with an unconfigured keymap layout. Does the installed system *have* console-setup installed? I did not find that out, so I guess the answer is No! It should have picked up the settings you made, in D-I, for the keymap (in your case, I suspect you picked 'German') and, thus, you should have a working keyboard layout on the installed system. I have an unusable keyboard layout on the installed system, unfortunately. After performing apt-get install console-data the keyboard layout is usable, but without performing that step the usage is a big pain! In any case, dpkg-reconfigure console-setup on the installed system should help. Sounds good, but is only helpful if you know that console-setup has been installed or not. How can I find that out? I will set up a couple of other workstations and I will keep on trying. But, still, that has to be investigated as this is obviously a big regression. I'm not in position to do so, being half-dialup as of now. Hopefully, someone else will. In the meantime, it would be good to mention this in http://wiki.debian.org/DebianInstaller/ConsoleSetupSwitch (Again, I'm not in position to do that right nowwill try to remember later when online) 2. At the point where the keyboard is being adjusted to the UTF-8 locale the script of the non-graphical installer (expert installation chosen in that specific case) hangs up the whole installation process. Only the graphical expert installation oversteps that installation step successively. 3. This is quite an old bug, and I really wonder why noone complained mentioning this one: It is impossible to set up a server / router with this installer containing more than one NIC, no matter if you chose graphical or non-graphical installer: In my personal example eth0 is connected to a highspeed modem. That's why I chose automatic DHCP configuration for the first NIC. Eth1 is configured staticallly by my own choice, that means DHCP with fixed addresses for the server and the workstations. The installer is incapable to handle more than one NIC, which is a mess! For my personal usage that means that I am forced to completely ignore the second NIC during the installation process. When installation is complete I am forced to reconfigure the whole network part of my server / router manually, i. e. using an ordinary editor. This state is quite insufficient and thus unacceptable. This is by design, in order to keep the installer simple to use and not confusing to less experienced users. So, by design, the only configured interface is the one that's used for the installation of the machine. Users who want to configure more than one interface are indeed expected to be able to do it after the install, by the usual methods. We really don't want to have *any* owner of a modern laptop (that has two NICs) to be prompted for the setting of his|her two interfaces. I cannot share that point of view: My position: Your point of view is fully OK for a standard install, no matter if console- based or graphical, adressing rookies and beginners. My point of view should fit for experienced users using the expert install, no matter if graphical or console based. But simplification in any case, and thus disregarding the different installer levels with their different sophistication is a point of view or guide line that I cannot and will not share at all... An additional menu point to adjust /etc/apt/sources.list to one's own personal needs would be very helpful as a part of such an installer. Here again, this is much out of scope of the installer. It is left to the post-install polishing of the installed machine, when the machine's admin is supposed to be skilled enough to know how to do this. I prefare to avoid the usage of editors. Thus it would make sense to add an additional point in the installer menu asking the user whether he wants to perform a Debian Sid installation or rather one based on the testing branch
Bug#446416: Bug does no longer exist, imho
On Sun, Aug 09, 2009 at 12:02:26PM +0200, Christian Perrier wrote: tags 446416 unreproducible thanks Hi Dann, Apparently, this old bug you reported back in 2007 hasa been ignored and no further investigation happened. I just tried to reprocude it, exactly the way you mentioned: r...@mykerinos:/etc/whereami# cat /usr/share/tasksel/dannf.desc Task: dannf Section: user Description: dannf long description Relevance: 10 Key: Packages: list hello Note the same trailing whitespace in synopsis. Then I launched taslsel --test and did choose the dannf task. r...@mykerinos:/etc/whereami# tasksel --test debconf-apt-progress -- aptitude -q -y install hello So, it seems that things are OK as of now... Thanks Christian. Looks like this is resolved, feel free to close. -- dann frazier -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
Guido Günther a...@sigxcpu.org writes: On Sun, Aug 09, 2009 at 04:57:28PM +0200, Ferenc Wagner wrote: OK, so the problem is identifying multipath devices in d-i. So that option would be better called d-i_friendly_names, because from the user PoV losing name persistence -- which this option implies --, isn't friendly or useful, in my opinion. If only multipath used To avoid we're furhter talking past each other: which device names aren't persistent from your PoV when using user_friendly_names? I was wrong. The friendly mpathn names are persistent, because /var/lib/multipath/bindings takes care of the persistence. But they are arbitrary, and subject to change between machines. (Actually, I've never used them, please correct me if I'm wrong again.) Dropping user_friendly_names won't give you name persistence with and without mp all by itself. You'll either have to use disk/by-id or disk/by-uuid to achive that. Why not? The WWIDs, which are used to name the devices by default, are persistent and also consistent between machines, aren't they? I've been using them on this assumption for years, and it seems to work out... Please explain why the udev symlinks would be any better (given that I'm not interested in using filesystem UUIDs). To get really friendly names, I define aliases in multipath.conf, but that's mostly sugar, I could do without them. Losing name consistency amongst different machines would be a major inconvenience, though. -- Thanks, Feri. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
kernel-wedge_2.53+lenny1_i386.changes ACCEPTED
Accepted: kernel-wedge_2.53+lenny1.dsc to pool/main/k/kernel-wedge/kernel-wedge_2.53+lenny1.dsc kernel-wedge_2.53+lenny1.tar.gz to pool/main/k/kernel-wedge/kernel-wedge_2.53+lenny1.tar.gz kernel-wedge_2.53+lenny1_all.deb to pool/main/k/kernel-wedge/kernel-wedge_2.53+lenny1_all.deb Override entries for your package: kernel-wedge_2.53+lenny1.dsc - optional utils kernel-wedge_2.53+lenny1_all.deb - optional utils Announcing to debian-chan...@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#399840: Do we want an ssh-server task?
On Sun, Aug 09, 2009 at 03:31:10PM +0200, Frans Pop wrote: On Sunday 09 August 2009, Colin Watson wrote: On Wed, Jul 29, 2009 at 01:14:52PM +0200, Frans Pop wrote: On Wednesday 29 July 2009, Christian Perrier wrote: An interesting proposal that Colin made was to converge towards a task named Login server or something similar, that would include openssh-server, along with other packages such as denyhosts (or sshguard), rssh (Restricted shell allowing scp, sftp, cvs, svn, rsync or rdist), molly-guard (protects machines from accidental shutdowns/reboots)... Most systems really only want ssh, not any of the rest. Is this assertion really true? My experience has been that quite a lot of people actually want something a bit more, even if they don't know it. I've personally never installed any of the others on any of my systems, while I do have openssh-server installed on all of my systems. The actual request is to make it easier to have openssh-server installed so that users can straight away access the newly installed system over ssh, nothing more and nothing less. So IMO we need a task that does exactly that, and nothing more. Out of curiosity, how are people in this situation actually installing their systems? Are there really that many people out there that are keyboarding their way through an entire install, but can't (won't?) then login to the newly installed system at the console and run apt-get install openssh-server? As someone who has preseeded their installs to the point where a new, fully-configured machine is nothing more than a 10 minute appointment with the PXE server, I'm having trouble imagining that there's a large market for this microtask[1], but I've been wrong before. I just think it's a question worth asking. - Matt [1] I think a better name for this might be package, but I'll stick with microtask until there is wider acceptance of this new term. grin -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540731: Fails to install due to syntax error in support/dir
Package: live-installer Version: 11 Severity: serious live-installer's postinst fails due to a combination of a syntax error introduced in live-installer 10 and set -e in live-installer 11. It's fixed in SVN already, but there is some delay in uploading a new version to sid (I forgot why). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org `- signature.asc Description: PGP signature
Bug#540731: Fails to install due to syntax error in support/dir
Chris Lamb wrote: It's fixed in SVN already, but there is some delay in uploading a new version to sid (I forgot why). in the meanwhile, live-installer-launcher was added, which has some things left to be polished (for text mode, that is). however, imho, it actually could be uploaded (has to trough NEW though). -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Patch
Processing commands for cont...@bugs.debian.org: tags 533797 fixed-upstream Bug #533797 [busybox] (busybox_1:1.13.3-1/avr32): FTBFS: util-linux/fdisk_osf.c:59 #error unknown architecture Added tag(s) fixed-upstream. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
