Bug#568292: auto-install: pulls netcfg into images that should not have it
On Thursday 04 February 2010, Frans Pop wrote: On Thursday 04 February 2010, Martin Michlmayr wrote: * Frans Pop elen...@planet.nl [2010-02-04 13:13]: So how about including a 'common' file in network-console/armel/ with: auto-install - localechooser - ai-locale-chooser - kbd-chooser - ai-kbd-chooser - Yeah, that sounds good to me. I can make that change after alpha1, unless it's urgent in which case I can do it now. No need. I'll do it together with the other changes I've queued. OTOH, there's no reason not to do this for the alpha release (adjusted for the current auto-install udebs). It's risk free. I had to move the common file up one level, so the change is also effected for mipsel/cobalt, but that should be fine. I've committed it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question about having an always clean base system in Debian Sid
On Thursday 04 February 2010, Geek87 wrote: Independently of the policy change, what I'm proposing is to have *all* packages (not only libraries) of the base system being installed with the automatically installed flag by debootstrap along with a mechanism to keep them installed (the APT::NeverAutoRemove ~prequired, ~pimportant, ~pstandard directive in apt.conf). I very much doubt that that would gain much support. Count me against. Users are supposed to be able to do basic system admin for their systems. If they're not able to do that, well, that's their problem and certainly not a reason to mess around with basic aspects of the package management system. Your proposal, although it may work, falls in the category hack (I wrote ugly hack first, but that's maybe a bit strong). Feel free to document it as an option somewhere, but I suggest you stop promoting it as something to do by default. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568381: debconf segfauls with DEBIAN_FRONTEND=text
On Thursday 04 February 2010, Frans Pop wrote: But I can confirm as I'm also seeing a segfault during an installation on s390. During mirror selection (but not 100% reliably). And can also confirm for amd64 in Virtualbox, also during mirror selection. And it does not go away if I recompile cdebconf (tried for amd64). -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568381: debconf segfauls with DEBIAN_FRONTEND=text
On Thursday 04 February 2010, Martin Michlmayr wrote: Marko Jung reported that d-i segfaults when you use DEBIAN_FRONTEND=text. I can reproduce this. I've traced this to Colin's commit that adds the passthrough frontend (r59807). If I revert that the text frontend works fine again. It may possibly have something to do with the progress bar STEP increasing to a value higher than the specified maximum, but that's a guess. Someone more at home in C than I will have to look deeper than that. Colin, do you have time? Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568381: debconf segfauls with DEBIAN_FRONTEND=text
On Thursday 04 February 2010, Otavio Salvador wrote: On Thu, Feb 4, 2010 at 4:19 PM, Frans Pop elen...@planet.nl wrote: And it does not go away if I recompile cdebconf (tried for amd64). ^^^-- This is similar to what happened in powerpc to me. I have no glue why :-( Really? See above. Also, the crash happens in a totally different place than it did on ppc. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568292: auto-install: pulls netcfg into images that should not have it
Package: auto-install Version: 1.6 Severity: important auto-install is included in most types of images and for some reason depends on netcfg. But for example cdrom and hd-media images don't include any network driver kernel modules, so the network is completely unusable. In those cases netcfg (plus ethdetect) only serves to bloat the image. The package should be reworked so that it works together with netcfg if it is included in the initrd, but should also work correctly when netcfg gets installed later by anna. The dependency on netcfg should then be dropped. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568292: auto-install: pulls netcfg into images that should not have it
tag 568292 patch
thanks
On Wednesday 03 February 2010, Frans Pop wrote:
The package should be reworked so that it works together with netcfg if
it is included in the initrd, but should also work correctly when netcfg
gets installed later by anna.
The dependency on netcfg should then be dropped.
Or if the dependency is required for menu ordering, then there should be an
alternative udeb whose only function is to queue auto-install for images
that don't have netcfg.
The attached (untested) patch should do this. Unless there are comments
I'll commit this and make the necessary changes in the pkg-lists files.
diff --git a/packages/auto-install/debian-installer-startup.d/S60auto-install-nonet b/packages/auto-install/debian-installer-startup.d/S60auto-install-nonet
new file mode 100755
index 000..3545f2a
--- /dev/null
+++ b/packages/auto-install/debian-installer-startup.d/S60auto-install-nonet
@@ -0,0 +1,5 @@
+#! /bin/sh
+. /usr/share/debconf/confmodule
+if db_get auto-install/enable [ $RET = true ]; then
+ anna-install auto-install
+fi
diff --git a/packages/auto-install/debian/auto-install-nonet.install b/packages/auto-install/debian/auto-install-nonet.install
new file mode 100644
index 000..93b4ff2
--- /dev/null
+++ b/packages/auto-install/debian/auto-install-nonet.install
@@ -0,0 +1 @@
+debian-installer-startup.d lib
diff --git a/packages/auto-install/debian/control b/packages/auto-install/debian/control
index 280d53d..c93b3fa 100644
--- a/packages/auto-install/debian/control
+++ b/packages/auto-install/debian/control
@@ -19,3 +19,11 @@ Depends: ${misc:Depends}, netcfg, preseed-common (= 1.42)
XC-Package-Type: udeb
XB-Installer-Menu-Item: 1900
Description: Support for automatic installs
+ For inclusion in images that have netcfg.
+
+Package: auto-install-nonet
+Architecture: all
+Depends: ${misc:Depends}, preseed-common (= 1.42)
+XC-Package-Type: udeb
+Description: Support for automatic installs
+ For inclusion in images that don't have netcfg.
Bug#568292: auto-install: pulls netcfg into images that should not have it
On Wednesday 03 February 2010, Frans Pop wrote: Or if the dependency is required for menu ordering, then there should be an alternative udeb whose only function is to queue auto-install for images that don't have netcfg. Hmmm. I think it could even pull in both auto-install and ai-choosers and thus leave ai-choosers out of the images as well. I'll include that in the patch. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568292: auto-install: pulls netcfg into images that should not have it
On Wednesday 03 February 2010, Frans Pop wrote: On Wednesday 03 February 2010, Frans Pop wrote: Or if the dependency is required for menu ordering, then there should be an alternative udeb whose only function is to queue auto-install for images that don't have netcfg. Hmmm. I think it could even pull in both auto-install and ai-choosers and thus leave ai-choosers out of the images as well. Gah! It's even worse. ai-chooser just blindly assumes that all images include both localechooser and kbd-chooser while that is not guaranteed. In fact, in most pkg-lists definitions localechooser is included from common, while kbd-chooser is included from arch.cfg. In the current situation ai-chooser basically overrides any other choices made in the pkg-lists. Not Very Nice At All! IMO ai-chooser should be split into two separate udebs, one depending on localechooser and one on kbd-chooser and auto-install (which runs before it) should anna-install them *only* if the postinst of localechooser resp. kbd-chooser is present. That would also allow for a clean migration to console-setup-udeb when we're ready for that. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568292: auto-install: pulls netcfg into images that should not have it
On Wednesday 03 February 2010, Frans Pop wrote:
On Wednesday 03 February 2010, Frans Pop wrote:
On Wednesday 03 February 2010, Frans Pop wrote:
Or if the dependency is required for menu ordering, then there
should be an alternative udeb whose only function is to queue
auto-install for images that don't have netcfg.
Hmmm. I think it could even pull in both auto-install and ai-choosers
and thus leave ai-choosers out of the images as well.
Gah! It's even worse. ai-chooser just blindly assumes that all images
include both localechooser and kbd-chooser while that is not guaranteed.
Here's a final patch set that should address the current deficiencies (and
allows for console-setup too).
Phil: any comments?
From 9fb05b837a5a78ae4743c241e087df4568fb571c Mon Sep 17 00:00:00 2001
From: Frans Pop f...@debian.org
Date: Wed, 3 Feb 2010 18:37:41 +0100
Subject: [PATCH 1/3] Add auto-install-nonet udeb
Intended to be included in images that don't include netcfg.
The udeb will queue auto-install for installation during anna if
auto-install/enable is true.
---
.../S60auto-install-nonet |5 +
.../auto-install/debian/auto-install-nonet.install |1 +
packages/auto-install/debian/control |8
3 files changed, 14 insertions(+), 0 deletions(-)
create mode 100755 packages/auto-install/debian-installer-startup.d/S60auto-install-nonet
create mode 100644 packages/auto-install/debian/auto-install-nonet.install
diff --git a/packages/auto-install/debian-installer-startup.d/S60auto-install-nonet b/packages/auto-install/debian-installer-startup.d/S60auto-install-nonet
new file mode 100755
index 000..3545f2a
--- /dev/null
+++ b/packages/auto-install/debian-installer-startup.d/S60auto-install-nonet
@@ -0,0 +1,5 @@
+#! /bin/sh
+. /usr/share/debconf/confmodule
+if db_get auto-install/enable [ $RET = true ]; then
+ anna-install auto-install
+fi
diff --git a/packages/auto-install/debian/auto-install-nonet.install b/packages/auto-install/debian/auto-install-nonet.install
new file mode 100644
index 000..93b4ff2
--- /dev/null
+++ b/packages/auto-install/debian/auto-install-nonet.install
@@ -0,0 +1 @@
+debian-installer-startup.d lib
diff --git a/packages/auto-install/debian/control b/packages/auto-install/debian/control
index 280d53d..c93b3fa 100644
--- a/packages/auto-install/debian/control
+++ b/packages/auto-install/debian/control
@@ -19,3 +19,11 @@ Depends: ${misc:Depends}, netcfg, preseed-common (= 1.42)
XC-Package-Type: udeb
XB-Installer-Menu-Item: 1900
Description: Support for automatic installs
+ For inclusion in images that have netcfg.
+
+Package: auto-install-nonet
+Architecture: all
+Depends: ${misc:Depends}, preseed-common (= 1.42)
+XC-Package-Type: udeb
+Description: Support for automatic installs
+ For inclusion in images that don't have netcfg.
--
1.6.6.1
From ba0230635fc69a34d08fe4a30d8b422688f5040d Mon Sep 17 00:00:00 2001
From: Frans Pop f...@debian.org
Date: Wed, 3 Feb 2010 19:22:59 +0100
Subject: [PATCH 2/3] Split ai-choosers into separate udebs per chooser
The current system just blindly assumes that an image (or install)
will include both localechooser and kbd-chooser/console-setup, which
is not necessarily true.
So split the current udeb in three and make auto-install responsible
for installing a ai-chooser udeb only if the corresponding component
is actually used in the installation.
For images that include netcfg they should be included in the image
(together with the correcsponding component).
---
.../auto-install/debian/ai-choosers.isinstallable |4 ---
.../debian/ai-console-setup-udeb.isinstallable |4 +++
.../debian/ai-kbd-chooser.isinstallable|4 +++
.../debian/ai-localechooser.isinstallable |4 +++
packages/auto-install/debian/auto-install.postinst |9
packages/auto-install/debian/control | 22 +--
6 files changed, 40 insertions(+), 7 deletions(-)
delete mode 100755 packages/auto-install/debian/ai-choosers.isinstallable
create mode 100755 packages/auto-install/debian/ai-console-setup-udeb.isinstallable
create mode 100755 packages/auto-install/debian/ai-kbd-chooser.isinstallable
create mode 100755 packages/auto-install/debian/ai-localechooser.isinstallable
diff --git a/packages/auto-install/debian/ai-choosers.isinstallable b/packages/auto-install/debian/ai-choosers.isinstallable
deleted file mode 100755
index 84f6554..000
--- a/packages/auto-install/debian/ai-choosers.isinstallable
+++ /dev/null
@@ -1,4 +0,0 @@
-#!/bin/sh
-. /usr/share/debconf/confmodule
-db_get auto-install/enable [ true = $RET ] exit 0
-exit 1
diff --git a/packages/auto-install/debian/ai-console-setup-udeb.isinstallable b/packages/auto-install/debian/ai-console-setup-udeb.isinstallable
new file mode 100755
index 000..84f6554
--- /dev/null
+++ b/packages/auto-install/debian/ai-console-setup-udeb.isinstallable
@@ -0,0 +1,4 @@
+#!/bin/sh
Bug#564441: new version of the proposed patch
Hello Fred, It took a bit of time, but I think you'll see why. I do really like the new functionality. I think we'll need to discuss the details of the user interface a bit more, but the concept definitely works. My compliments for your work. Attached a patch series, mostly on top of your last patch. It looks like a lot, but you'll see that I've not actually changed your functionality that much. A lot of the changes are cleanups and coding style improvements. Also, some of the changes are improvements of existing code/functionality and don't really change your code. I did fix a few issues; more below. The most invasive change is the restructuring of the state engine, but even that changes your new functionality only in very minor ways. But I hope you'll agree that with my changes it's more structured and readable. Although my version of the script has more lines, it is actually roughly the same size as your version. I've not yet reviewed the template texts yet as that's better delayed until we have the user interface finalized. I've attached the patches as an incremental series because that way you can better see why I made individual changes. I've added a number of FIXMEs in the code. Some relate to your changes, but some are more general questions that should be considered now we're doing a major overhaul anyway. Before we discuss any changes to the user interface I want to give you a chance to read through my changes. Please let me know if you have questions or don't agree with something I've done. On Thursday 28 January 2010, Fred wrote: There are some areas where I'm not sure the proposed patch is fully ok : - the templates are definitely not best written texts See above. - about suggestions from F. Pop, I didn't know how to handle 'preseed', as I don't know how it works Actually, I think that will mostly just work. Users should even be able to preseed a specific device (or list of devices) to scan, and even using both normal and persistent device names. My patch 0013 addresses that a bit. Most important is to ensure that users will not end up in an endless loop, for example if no ISO can be found. - then looking at the second pass for ISOs in sub-directories, I wonder if I had to give also the top-directories' detected ISO ; I left them in the final list, but perhaps it isn't the best choice. There was a bug there. After the second pass images in a top level directory would be listed twice. My patch 0010 solved that, but with that other images would disappear after the second pass. So I came up with 0011 which is a pretty good implementation I think. See the commit comments for details. There were a few important issues with your patch. * It made some dialogs untranslatable You'd hardcoded a number of changes to dialogs in a way that could not be translated. I've fixed the device selection dialog (the Choices-C mechanism I've used there is really excellent), but not yet the ISO selection dialog. Essentially you cannot make *any* assumptions about how a translation will look. Because of that it's not possible to change parts of sentences on the fly. We can however quite easily use different paragraphs in different situations. Localechooser has a lot of examples of that. * Backing up to the main menu failed Instead you'd end up endlessly doing the first state. My patch 0012 fixes that. (The first state could even be moved out of the state engine, but I've left it in as that keeps the option open to implement a scan for new devices option. I don't think we'll need that though.) * The state engine was rather complex You had a number of state variables that needed complex testing and sometimes referred back to the result of earlier states. The restructuring I've done is very much based on the state engine in localechooser. A general rule is to have only one db_input in a state (at the end) and that the next state should start by testing the result of that. And it's perfectly OK to have states that don't ask questions. Have a look and feel free to ask questions. * Suite not set in final dialog (see patch 0008) This could possibly be solved by creating a dir under /var/lib/ and saving the suite (or codename) in a file that has as its name the full path of the iso with s:/:_:g (or some other character). I've already committed the first patch of the series in the D-I repo. That's why I've included your own patch: it's rebased on top of that (without any other changes). You can just apply the patches one-by-one on top of current SVN using 'patch -p1', but, especially if you already know git, you could also consider doing the following (done from memory, so may not completely work): * Save my patches somewhere; delete the first one. $ mkdir iso-scan $ git svn init svn+ssh://svn.debian.org/svn/d-i/trunk/packages/iso-scan $ git svn fetch -r HEAD $ git checkout -b from-frans $ git am path-to-my-patches00*.patch $ git checkout -b my-new
Re: [RFC] Allow to force or skip Recommends with apt-install
On Tuesday 08 December 2009, Frans Pop wrote:
D-I now always installs Recommends by default, except when
base-installer/install-recommends is preseeded to false.
However, there are a few specific cases where we want to force
installing or not installing Recommends with specific packages,
irrespective of what the default setting is.
[...]
Attached a patchseries that makes apt-install recognize two options,
--no-recommends and --with-recommends, which allow us to force the
correct behavior in such cases. The options are preserved in the queue
file [1] if installation of the package is delayed to base-installer.
That's now implemented.
Note that use of these options should remain the exception. Normally we
should just honor the general setting.
I've looked at the consequences of this and things are quite complex.
IMO our main goal must be to have installations be as consistent as
possible.
One complication is that if packages have already been installed by
debootstrap, any recommends they may have will never get installed.
Example is psmisc which is recommended by initscripts (required) and procps
(important). Both these rdepends get installed by debootstrap, but psmisc
is not installed.
For the same reason uuid-runtime will never get installed.
Installation order is also important.
Example: A depends C, B depends C, C recommends D
apt-install --with-recommends A; apt-install --without-recommends B
= D is installed
apt-install --without-recommends B; apt-install --with-recommends A
= D is not installed
This is particularly relevant for initramfs-tools and udev. Both have
various packages depending on them.
So far the introduction, now the actual issues and proposals.
*** popularity-contest (pkgsel; pre-pkgsel.d)
Because it gets installed before tasksel, it would pull in exim4
prematurely. Add --no-recommends to avoid that.
*** installation-report (save-logs; pre-pkgsel.d)
Because it gets installed before tasksel, it would pull in reportbug, which
means reportbug would be marked as automatically installed, which it
shouldn't be. Add --no-recommends to avoid that.
*** console-setup (kbd-chooser; post-base-installer.d)
Recommends kbd. IMO it's worthwhile ensuring that kbd always gets installed
for consistency. Add --with-recommends to achieve that.
*** grub-{legacy,pc,efi,ieee1275} (grub-installer)
All depend on grub-common which recommends os-prober.
- At least for grub-legacy os-prober should not be installed in the target
system. I've already added --no-recommends to avoid that in SVN.
- For grub-pc I think we can leave it up to the global setting for
installing recommends.
- For the other two I have no idea...
*** mdadm (base-installer)
Recommends default-mta and would thus pull in exim4 prematurely. Needs
--no-recommends to avoid that. But that means it could also install udev
without recommends, so...
*** udev and initramfstools
It's IMO essential that packages related to booting the system get
installed consistently, whatever the choices made by the user. Otherwise
we'll end up at some point with issues that are hard to trace.
As we already ensure that everything that's needed gets apt-installed, the
most consistent result will be guaranteed by installing all such packages
with --no-recommends.
This means adding --no-recommends for the following packages:
- udev, initramfs-tools (+ busybox), yaird
- sysconfig-hardware
- flash-kernel, mkvmlinuz
- cryptsetup, lvm2, mdadm, dmsetup, dmraid, multipath-tools-boot
- loop-aes-utils (means we miss sharutils, but we've never needed that)
- pcmciautils
If there are no comments in the next few days I'll commit the changes
proposed above.
The alternative would be to go back to always installing without
Recommends.
Cheers,
FJP
signature.asc
Description: This is a digitally signed message part.
Bug#562051: Partman hanging on 52%, Polish language on MD devices
reassign 562051 partman-md tag 562051 unreproducible moreinfo thanks I've tried to reproduce this with both a daily image and a Lenny image. I've not used the identical disk layout, but I did create 3 RAID devices over 2 disks. On Tuesday 22 December 2009, Marcin Owsiany wrote: This is the configuration before starting the installer. The partioning program showed all of them as expected. The steps to reproduce the problem: 1) select Polish language 2) in the partitioning tool select /dev/md2 3) choose ext3 as the filesystem 4) choose format 5) mount as the root filesystem 6) go back to the main menu of the partitioning program Tried that. Now, the behaviour differs slightly depending on what the user wanted to do next: The strange thing is that in neither of the cases below does a progress bar appear. And it should not either. There are some actions executed in the described situations, but those don't have a progress bar. 7a) select another partition - a progress bar appears, immediately goes to 52%, and hangs forever Here I simply get the configuration menu for the selected partition. 7b) select save changes and continue with the installation - a progress bar appears, proceeds up to 52%, at which point it hangs forever Here I get the confirmation dialog for finishing the partitioning. Only *after* I confirm that do we get a progress bar, but for ext3 that only ever goes up to 33%, and not 52%. AFAICT partman behaves correctly, even in Polish ;-) Without degugging info from someone who can reproduce the problem there's nothing more we can do here. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562051: Partman hanging on 52%, Polish language on MD devices
On Tuesday 02 February 2010, Marcin Owsiany wrote: It would be awesome if you could update the bug with short instructions on what to look for if someone can reproduce it. Just a couple of sentences or so. Simplest thing is to add a line 'set -x' in /lib/partman/lib/base.sh. That will give a shitload of shell debug output in /var/log/syslog. Copy the syslog *as soon as* the hang occurs (don't play around after it has occurred) and mail it to the BR. Note: because of its size the syslog *must* be gzipped. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] Degrading reiserfs to optional filesystem?
On Monday 01 February 2010, Christian PERRIER wrote: So, well, I answered Joss that, yes, ext4 will be available in D-I as an option so that might answer his concerns. But, still, I felt the duty to mention his concerns. And reiserfs will not be dropped. It's still available for selection for those who really want it. Either select it in anna (at medium/low prio), or boot with 'modules?=partman-reiserfs'. As the maintainer of reiserfsprogs has now acked the change I've committed the needed changes to SVN. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
On Monday 01 February 2010, Frans Pop wrote:
On Monday 01 February 2010, Otavio Salvador wrote:
I.e, multiple IP addresses should be comma-separated. This also goes
for ntp-servers, which probably should not have quotes as it's
similar to dns.
Fixed both issues; I can't test it now so if you have time do a last
check.
This is not going to work in busybox shell:
option domain-name-servers ${dns/ /,};
Suggest you use a function, something like:
comma_separate() {
echo $1 | sed s/ /,/g
}
and then use:
option domain-name-servers $(comma_separate $dns);
And the same substitution should be made for ntp servers, which can also
have multiple values.
I've committed this myself (for routers, dns and ntp).
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
On Sunday 31 January 2010, Otavio Salvador wrote: On Sun, Jan 31, 2010 at 4:32 PM, Frans Pop elen...@planet.nl wrote: Having all leases in the file would mostly be an aid for troubleshooting. It's not a huge issue for me though. To it to concatenate them is a simgle line change in the script so I can do it easily. I just didn't think it was useful but if you want just tell me and I do it. I've tested this a bit and the strange the strange thing is that I don't get any new entries for normal renews. I see new REQUEST+ACKs on my server, but nothing in D-I in either the syslog or the leases file. So apparently either the script does not get called on normal renews (maybe it will be called only if something changes), or there is some bug. After some thought I've decided to make the change anyway. IMO it can be useful for troubleshooting, especially as given the above it would only result in multiple entries in case of exceptions. Change has been committed. As far as I'm concerned all is OK now. We will need a new busybox upload before we can upload netcfg though. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
On Monday 01 February 2010, Otavio Salvador wrote: Your suggestion makes the code much nicer to read, indeed, however I did test it inside of busybox' shell and it worked. Has it failed for you? I tried the commands I showed in an earlier mail in D-I debug shell. Maybe the configs are different, or either you or I made some mistake. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFH] Errata and announcement help need
On Monday 01 February 2010, Otavio Salvador wrote: Current issues: - sparc images are broken It's not the images that are broken, but the installation of the silo bootloader to the target system. So the reboot fails. Should be fixed when D-I switches to .32. Details in #565639. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
On Sunday 31 January 2010, Luk Claes wrote: Otavio Salvador wrote: Also, if I run netcfg multiple times with dhcp3, I get multiple leases in the leases file. You seem to overwrite the existing file. Not sure if that needs fixing or not. I think it is not worth. syslog now has the gotten IP each time it runs so is easy to spot if it has been run twice. The same is true with dhcp3 isn't it? With dhcp3 not all the leases in the file are valid aka only the latest one for every IP is valid if it's not expired yet. Of course. I'm not sure if udhcp would cope with invalid leases in the leases file? It's only an output file. udhcp itself does not use it. Having all leases in the file would mostly be an aid for troubleshooting. It's not a huge issue for me though. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567590: Reproducable
reassign 567590 partman-partitioning 64 fixed 567590 71 tag 567590 pending thanks On Saturday 30 January 2010, Zachary Palmer wrote: I witnessed the same confusion myself; in retrospect, I should've mentioned it. I simply assumed that it was a graphical glitch of some kind. I was unable to set the bootable flag as well and had been setting the BIOS boot area flag (bios_grub) as well. I'm not clear as to the semantic of that flag, but that's what I have set at the moment and it seems to be booting my machine correctly. I'd be glad to provide more information at request, but I'm not terribly familiar with GPT, so I'm not sure what's relevant. :) OK. I'm not a gpt expert myself, but it does seem logical to me that a BIOS boot area cannot be used for RAID. AFAIK it's supposed to be a (small) separate partition reserved for use for booting the system. Possibly the bios_grub flag should have been implemented as a use as option instead of a toggle. This seems to be confirmed as the changelog for version 71 of the relevant component has: * Convert BIOS GRUB boot area support to a method, thereby making it impossible to accidentally put a filesystem on such a partition as well, and making it simpler to preseed. So it looks to be changed already for Squeeze. So for now I'm going to just fix the display issue and assume that the disappearing RAID flag is as it should be. Thanks for the additional info. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] Degrading reiserfs to optional filesystem?
(Please reply to the d-boot list.) Hello Felix, On Saturday 30 January 2010, Frans Pop wrote: What do people think of degrading reiserfs support to optional, i.e. only usable by specifically selecting partman-reiserfs in anna? The rationale would be that its popularity has decreased (AFAIK), upstream development is not very active and that more (and better?) alternatives are available now than there used to be when reiserfs was quite popular. IMO its relevance for new installs for Squeeze could be minor. We're considering to make support for reiserfs optional in Debian Installer for Squeeze. In the D-I team there seems to be consensus for that. Main reason is to reduce the memory footprint for standard installs which has increased amongst others because support for other filesystems (ext4, and possibly also btrfs) has been added. As mentioned above, reiserfs would still be supported, but only if the user explicitly selects it. The only change needed is lowering the priority of udebs, which I'd take care of. Comments? Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: [RFC] Degrading reiserfs to optional filesystem?
On Saturday 30 January 2010, Frans Pop wrote: What do people think of degrading reiserfs support to optional, i.e. only usable by specifically selecting partman-reiserfs in anna? I've also filed a BR (#567858) to request dropping the reiser4 udebs. I don't see support for that happening in Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
Another issue. The Depends: for netcfg in debian/control now has: dhcp3-client-udeb (= 3.1.0-2) [kfreebsd-i386 kfreebsd-amd64] According to policy this is only allowed for build dependencies, not for regular ones. Or am I missing something? If I'm right the dependency should be added dynamically at build time from the rules file. We have a few examples how to do that, for example clock-setup. Note that dhcp3-client-udeb is currently also included from the pkg-lists files. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
On Sunday 31 January 2010, Otavio Salvador wrote: Probably worth adding/fixing for udhcpc is: - missing option host-name I've added it but I can't test it right now. Please see if it works for you. - missing option domain-name-servers - missing option dhcp-server-identifier - strange leading slash for subnet-mask - typo option domain-nam (missing e) The other differences are probably not that relevant. I've fixed/added them all. Looks better now. There a few last minor issues. dhcp3 gives: option domain-name-servers 10.19.66.2,10.19.66.1; udhcpc gives: option domain-name-servers 10.19.66.2 10.19.66.1; I.e, multiple IP addresses should be comma-separated. This also goes for ntp-servers, which probably should not have quotes as it's similar to dns. I've also tested ntp-servers now. Works correctly. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
On Monday 01 February 2010, Otavio Salvador wrote:
I.e, multiple IP addresses should be comma-separated. This also goes
for ntp-servers, which probably should not have quotes as it's similar
to dns.
Fixed both issues; I can't test it now so if you have time do a last
check.
This is not going to work in busybox shell:
option domain-name-servers ${dns/ /,};
# test=a b c
# echo ${test/ /,}
/bin/sh: syntax error: bad substitution
Suggest you use a function, something like:
comma_separate() {
echo $1 | sed s/ /,/g
}
and then use:
option domain-name-servers $(comma_separate $dns);
And the same substitution should be made for ntp servers, which can also
have multiple values.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Update of D-I Internals
Yesterday I've committed a fairly large update to the D-I Internals document. It now reflects the current development version for Squeeze instead of lagging at Etch. I've also started its transformation towards a more general developers reference by integrating the menu-item-numbers and available-hooks files into the document as appendices. On my ToDo list are: - creating a chapter with tips and guidelines for D-I development - integrating the coding style document into an appendix - creating a separate chapter on testing and debugging the new version is available at: http://d-i.alioth.debian.org/doc/internals/ Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#567590: Reproducable
reassign 567590 partman-base 128lenny1 retitle 567590 Strange bootable flag behavior with gpt disk label; RAID fails thanks On Saturday 30 January 2010, Zachary Palmer wrote: Here's the interesting bit. I sped through the menus and discovered that the RAID system was quite happy to create a RAID1 for me. I went back, deleted the RAID, and started over. The second time, I was able to reproduce the bug. The only difference between these two runs was that I remembered to flag both drives as bootable the second time. It seems that a bootable GPT partition is the problem; the RAID menu system doesn't seem to see it. It looks as if there's something wrong with the bootable flag code for gpt partitions, even without RAID. When I create a new partition I get: │ Partition settings: │ │ │ │ Name:│ │ Use as: Ext3 journaling file system│ │ │ │ Mount point: / │ │ Mount options:defaults │ │ Label:none │ │ Reserved blocks: 5% │ │ Typical usage:standard │ │ Bootable flag:off│ │ off │ Note the extra line with 'off' below the 'Bootable flag' line. That could be caused by bootable flag, but possibly also a different flag. Toggling Bootable flag does not work (it remains 'off'), but toggling the line below changes it from 'off' to 'on'. I think we should look into this first and see if it also fixes the reported issue with RAID. Reassigning to partman-base for now as this is likely a more general issue than just in partman-md. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567590: Reproducable
On Saturday 30 January 2010, Frans Pop wrote:
│ Bootable flag: off │
│ off │
Note the extra line with 'off' below the 'Bootable flag' line. That
could be caused by bootable flag, but possibly also a different flag.
OK, that was possibly an unrelated issue. The second line was for the 'BIOS
boot area flag' for which the description is not correctly displayed.
I've committed a fix for that.
Toggling Bootable flag does not work (it remains 'off'), but toggling
the line below changes it from 'off' to 'on'.
Toggling the bootable flag still does not have any effect. It should be
supported: VALID_FLAGS in the partman log has: boot, hidden, raid, lvm,
hp-service, msftres, bios_grub.
I can see the flag is getting set correctly, but when libparted reads the
current flags again, it's not there.
Zacharay: is the problem really with the bootable flag, or rather with
that 'BIOS boot area' (bios_grub) flag?
It looks as if setting bios_grub may remove the raid flag. Could it be that
a 'BIOS boot area' partition simply cannot be a RAID partition? That seems
quite logical...
To test with that display issue corrected, you need to make the following
change in /lib/partman/active-partition/67toggle_biosgrub/choices before
you run partman:
-description=$(stralign -25 $RET)
+description=$RET
if [ $biosgrub = yes ]; then
db_metaget partman-partitioning/text/on description
- printf nobiosgrub\t%s%s\n $description ${RET}
+ printf nobiosgrub\t%s\${!TAB}%s\n $description ${RET}
else
db_metaget partman-partitioning/text/off description
- printf biosgrub\t%s%s\n $description ${RET}
+ printf biosgrub\t%s\${!TAB}%s\n $description ${RET}
fi
I'll test a bit more myself too.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567590: Reproducable
On Saturday 30 January 2010, Frans Pop wrote: On Saturday 30 January 2010, Frans Pop wrote: Toggling Bootable flag does not work (it remains 'off'), but toggling the line below changes it from 'off' to 'on'. Toggling the bootable flag still does not have any effect. It should be supported: VALID_FLAGS in the partman log has: boot, hidden, raid, lvm, hp-service, msftres, bios_grub. I can see the flag is getting set correctly, but when libparted reads the current flags again, it's not there. Just to be clear: toggling the bootable flag does not work, but also does not affect the raid flag. The raid flag remains set correctly. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564441: new version of the proposed patch
On Thursday 28 January 2010, Fred wrote: I've updated my patch to follow suggestions from F. Pop, and tested it at my level. Perhaps some enhancements could be added for a better usability. Thanks Fred. I've taken a first look at the patch and will review it more thoroughly over the next days. One issue is that you've hardcoded a few strings, which means not everything can be translated. I've already fixed it for the devices dialog, but for the ISO selection dialog it requires a bit more work. If you call the Debian Installer with default debconf level, it automatically scans all devices and select the first detected ISO (*but*, on the contrary of old iso-scan behaviour, it scans all available disks before to select first ISO). If we call Debian Installer with 'medium' level (debconf/priority=medium), we can choose which device to scan, then select an ISO among detected ones. I'll see how it works out in practice, but maybe at high priority we should scan all devices without asking but, if more than one ISO was found, ask which ISO to use. The devices should eventually probably be listed in a more user-friendly format, similar to what we do in partman. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: unused and removable partman templates
I've checked only by grepping, nothing fancy. On Wednesday 27 January 2010, Joey Hess wrote: AFAICS, the following templates are all not used anywhere: partman-jfs/check_failed partman-reiserfs/check_failed partman-ext3/check_failed partman-ext2r0/check_failed partman-xfs/check_failed (and p-btrfs...) Still looks to be used for partman-ext2r0 (check.d/check_ext2r0: 32-37), but maybe that could be converted to the generic one? Similarly, there are generic partman-basicfilesystems/progress_checking, create_failed, specify_mountpoint, no_mount_point, and these are unused: partman-jfs/progress_checking partman-reiserfs/progress_checking partman-ext3/progress_checking + partman-xfs/progress_checking AFAICT (and p-btrfs...) partman-ext3/create_failed Still used in commit.d/format_ext3: 107-110. While these are used but could be switched to use the generic templates easily: partman-ext2r0/progress_checking partman-jfs/create_failed partman-reiserfs/create_failed partman-ext2r0/create_failed partman-xfs/create_failed partman-*/no_mount_point partman-*/specify_mountpoint Have not checked these, but conversion sounds worthwhile. AFAIK they should all depend on p-basicfilesystems. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[RFC] Degrading reiserfs to optional filesystem?
What do people think of degrading reiserfs support to optional, i.e. only usable by specifically selecting partman-reiserfs in anna? The rationale would be that its popularity has decreased (AFAIK), upstream development is not very active and that more (and better?) alternatives are available now than there used to be when reiserfs was quite popular. IMO its relevance for new installs for Squeeze could be minor. OTOH, it's popcon stats are not yet decreasing [1], but recent usage is very low and popcon will lag anyway. Cheers, FJP [1] http://qa.debian.org/popcon.php?package=reiserfsprogs -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 32-bit install kernel sleeps off during installation
On Friday 29 January 2010, Rainer Koenig wrote: Frans Pop schrieb: - install build dependencies - build a netboot image using: make reallyclean; fakeroot make build_netboot At this point I fail. The build process wants to install packages like acpi-modules-2.6.26-2-686-di but they seem not to be in the scope of my Lenny based sources.list :-( Sorry, my mistake. The change in the config file should have been to 2.6.26-2-686-bigmem-di. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
On Saturday 30 January 2010, Otavio Salvador wrote: It was a long time since I last looked at it; I've looked again and I found that the script was not being set as executable. I've fixed it for next busybox' upload. Thanks for the fixes. I'll give it a go. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: netcfg: using udhcpc to get dhcp lease fails
On Saturday 30 January 2010, Otavio Salvador wrote:
I built a netboot image without dhcp3-udeb to test udhcpc, but it
failed miserably as it did not manage to get a lease during netcfg.
How well was this tested?
Works OK now. Nice.
Now it has one. /var/lib/udhcp/udhcpc.leases.
udhcpc given me:
lease {
interface eth0;
fixed-address 10.19.66.61;
filename http://www/preseed.cfg;;
subnet-mask /255.255.255.0;
option domain-nam fjphome.nl;
option routers 10.19.66.1;
option ntp-servers ;
}
While dhcp3 gives:
lease {
interface eth0;
fixed-address 10.19.66.61;
filename http://www/preseed.cfg;;
option subnet-mask 255.255.255.0;
option routers 10.19.66.1;
option dhcp-lease-time 7200;
option unknown-208 f1:0:74:7e;
option dhcp-message-type 5;
option unknown-209 debian-installer/pxelinux.cfg/default;
option domain-name-servers 10.19.66.2,10.19.66.1;
option dhcp-server-identifier 10.19.66.2;
option unknown-210 /;
option host-name vbox1;
option domain-name fjphome.nl;
renew 0 2010/01/31 01:23:15;
rebind 0 2010/01/31 02:19:33;
expire 0 2010/01/31 02:34:33;
}
Probably worth adding/fixing for udhcpc is:
- missing option host-name
- missing option domain-name-servers
- missing option dhcp-server-identifier
- strange leading slash for subnet-mask
- typo option domain-nam (missing e)
The other differences are probably not that relevant.
Oh, and we also need 'ntpservers' I think. I can't test that here now, but
netcfg does (in dhcp.c):
if ((d = fopen(NTP_SERVER_FILE, r)) != NULL) {
char ntpservers[DHCP_OPTION_LEN + 1] = { 0 };
fgets(ntpservers, DHCP_OPTION_LEN, d);
fclose(d);
unlink(NTP_SERVER_FILE);
if (!empty_str(ntpservers)) {
debconf_set(client, netcfg/dhcp_ntp_servers,
ntpservers);
}
}
and the clock-setup postinst has:
db_get netcfg/dhcp_ntp_servers
Also, if I run netcfg multiple times with dhcp3, I get multiple leases in
the leases file. You seem to overwrite the existing file. Not sure if that
needs fixing or not.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567431: Installation Report
reassign 567431 kernel-wedge 2.62 tags 567431 pending thanks On Friday 29 January 2010, boice...@msu.edu wrote: Comments/Problems: Using the text installer, USB Keyboard did not work even with BIOS legacy emulation enabled once I passed the Install menu choice and was on the language screen. Had to pull out an old PS/2 keyboard to finish. The USB keyboard works fine on the fully installed system. This is a known issue for some USB keyboards that has already been fixed for when we change over to the 2.6.32 kernel in the installer. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
On Wednesday 27 January 2010, Frans Pop wrote:
Please consider the attached patch which adds a udeb for libgcc1
containing only libgcc_s.so.1.
In case we do decide on inclusion in gcc, here is an updated patch for 4.4
and the additional patch for 4.5.
Changes:
- added libgcc[246] udebs for m68k/hppa
- the udeb should not be cross-built, so I removed the bits in the
control.m4 file that IIUC are to enable that
I've successfully tested the patches for standard builds:
- gcc-4.4 for amd64 and hppa;
- gcc-4.5 for amd64.
diff -u gcc-4.4-4.4.3/debian/control.m4 gcc-4.4-4.4.3/debian/control.m4
--- gcc-4.4-4.4.3/debian/control.m4
+++ gcc-4.4-4.4.3/debian/control.m4
@@ -188,6 +188,14 @@
environment.
')`'dnl
+Package: libgcc1-udeb
+XC-Package-Type: udeb
+Architecture: any
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library
+
Package: libgcc2`'LS
Architecture: ifdef(`TARGET',`all',`m68k')
Section: ifdef(`TARGET',`devel',`libs')
@@ -217,6 +225,14 @@
This package contains files for TARGET architecture, for use in cross-compile
environment.
')`'dnl
+
+Package: libgcc2-udeb
+XC-Package-Type: udeb
+Architecture: m68k
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library
')`'dnl libgcc
ifenabled(`lib4gcc',`
@@ -247,6 +263,14 @@
This package contains files for TARGET architecture, for use in cross-compile
environment.
')`'dnl
+
+Package: libgcc4-udeb
+XC-Package-Type: udeb
+Architecture: hppa
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library
')`'dnl lib4gcc
ifenabled(`lib64gcc',`
diff -u gcc-4.4-4.4.3/debian/control gcc-4.4-4.4.3/debian/control
--- gcc-4.4-4.4.3/debian/control
+++ gcc-4.4-4.4.3/debian/control
@@ -36,6 +36,14 @@
Description: GCC support library (debug symbols)
Debug symbols for the GCC support library.
+Package: libgcc1-udeb
+XC-Package-Type: udeb
+Architecture: any
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library
+
Package: libgcc2
Architecture: m68k
Section: libs
@@ -54,6 +62,14 @@
Description: GCC support library (debug symbols)
Debug symbols for the GCC support library.
+Package: libgcc2-udeb
+XC-Package-Type: udeb
+Architecture: m68k
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library
+
Package: libgcc4
Architecture: hppa
Section: libs
@@ -72,6 +88,14 @@
Description: GCC support library (debug symbols)
Debug symbols for the GCC support library.
+Package: libgcc4-udeb
+XC-Package-Type: udeb
+Architecture: hppa
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library
+
Package: lib64gcc1
Architecture: i386 powerpc sparc s390 mips mipsel
Section: libs
diff -u gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
--- gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
+++ gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
@@ -14,8 +14,10 @@
p_lgcc = libgcc$(GCC_SONAME)
p_lgccdbg = libgcc$(GCC_SONAME)-dbg
+p_lgccudeb = libgcc$(GCC_SONAME)-udeb
d_lgcc = debian/$(p_lgcc)
d_lgccdbg = debian/$(p_lgccdbg)
+d_lgccudeb = debian/$(p_lgccudeb)
p_l32gcc = lib32gcc$(GCC_SONAME)
p_l32gccdbg = lib32gcc$(GCC_SONAME)-dbg
@@ -42,7 +44,10 @@
dh_installdirs -p$(p_lgcc) \
$(docdir)/$(p_lgcc) \
$(libdir)
-
+ dh_installdirs -p$(p_lgccudeb) \
+ $(libdir)
+
+ cp $(d)/$(PF)/lib/libgcc_s.so.$(GCC_SONAME) $(d_lgccudeb)/$(libdir)/.
ifeq ($(with_shared_libgcc),yes)
mv $(d)/$(PF)/lib/libgcc_s.so.$(GCC_SONAME) $(d_lgcc)/$(libdir)/.
endif
@@ -57,8 +62,9 @@
debian/dh_rmemptydirs -p$(p_lgcc)
debian/dh_rmemptydirs -p$(p_lgccdbg)
dh_strip -v -p$(p_lgcc) --dbg-package=$(p_lgccdbg)
- dh_compress -p$(p_lgcc) -p$(p_lgccdbg)
- dh_fixperms -p$(p_lgcc) -p$(p_lgccdbg)
+ dh_strip -v -p$(p_lgccudeb)
+ dh_compress -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
+ dh_fixperms -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
ifeq ($(with_shared_libgcc),yes)
dh_makeshlibs -p$(p_lgcc) -V '$(p_lgcc) (= $(DEB_LIBGCC_SOVERSION))' \
-- -v$(DEB_LIBGCC_VERSION)
@@ -68,17 +74,17 @@
endif
cat debian/$(p_lgcc)/DEBIAN/shlibs debian/shlibs.local
endif
- dh_shlibdeps -p$(p_lgcc)
- dh_gencontrol -p$(p_lgcc) -p$(p_lgccdbg) \
+ dh_shlibdeps -p$(p_lgcc) -p$(p_lgccudeb)
+ dh_gencontrol -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb) \
-- -v$(DEB_LIBGCC_VERSION) $(common_substvars)
mkdir -p $(d_lgcc)/usr/share/lintian/overrides
echo '$(p_lgcc): package-name-doesnt-match-sonames' \
$(d_lgcc)/usr/share/lintian/overrides/$(p_lgcc)
- dh_installdeb -p$(p_lgcc) -p$(p_lgccdbg)
- dh_md5sums -p$(p_lgcc) -p$(p_lgccdbg)
- dh_builddeb -p$(p_lgcc) -p$(p_lgccdbg)
+ dh_installdeb -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
+ dh_md5sums -p$(p_lgcc
Re: Bug#433568: VLANs during install are important
On Friday 29 January 2010, Josef Wolf wrote: Since the interface name can be used to decide whether to activate vlan support, no new debconf questions (like netcfg/enable_vlan or something) are needed, IMHO. Doesn't that already answer your question about the user interface? :-) One request: please make vlan support optional so that netcfg still works when the bits needed for it are not available. It's probably not relevant for all architectures. For installs where netcfg is run after anna (CD-based installs), the loading of additional udebs should probably be done by the relevant part of hw-detect (ethdetect) and not by netcfg itself. And for e.g. netboot images the vlan udeb would need to be included in the initrd for relevant architectures. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#433568: VLANs during install are important
On Friday 29 January 2010, Bastian Blank wrote: On Sun, Jan 17, 2010 at 09:35:47PM +0100, Josef Wolf wrote: 2. Install vlan package into installer environment. Only the vconfig binary (9kb) is really needed. But it needs libc6. Is this an issue? Not needed: | config VCONFIG | bool vconfig | default n | help | Creates, removes, and configures VLAN interfaces Just to be clear: that's a busybox option that's currently disabled. You can simply build a custom version of busybox with it enabled (see debian/config/udeb) for your development and testing before requesting it to be enabled. It can then be enabled when we have a full (tested) set of patches. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#433568: VLANs during install are important
On Friday 29 January 2010, Josef Wolf wrote: But at that time the interface chosen interface is not known. So deducing from chosen interface name (as outlined above) is not possible and this method would only work with preseeding or if additional questions are asked. No. The sequence should be: - if the interfaces are there, hw-setup should install additional needed stuff - if additional needed stuff is not available, netcfg should not offer the interfaces for selection And for e.g. netboot images the vlan udeb would need to be included in the initrd for relevant architectures. Oh, I've completely forgotten about netboot. To be honest, I have no clue what this means exactly. Can you point me to some information about that? Just build the target and use the mini.iso for your development and testing. It's by far the easiest way to develop new functionality anyway. See further the document I pointed t earlier, especially the comments about localudebs and pkg-lists/local. BTW: Actually there are two udebs: - one udeb created from vlan.deb (only the XC-Package-Type line needs to be added to debian/control) Not needed according to Bastian. - the kernel modules would be created via kernel-wedge Correct. Only question is whether they should be in a separate udeb, or included in one of the existing network-drivers udebs. That depends on: - size - whether it is generally needed/useful or only for selected arches. I think a separate udeb is the best option to start with. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Daily Debian Installer builds
FYI I've taken over the daily builds of Debian Installer for s390 as lophos has been down for well over a month now. If the service on lophos is ever reinstated, or if someone wants to set up (and manage) the builds on a regular buildd I'll be happy to stop them again. The link on the D-I page [1] (after next website build) and the build overview page have been updated. Cheers, FJP [1] http://www.debian.org/devel/debian-installer/index.html signature.asc Description: This is a digitally signed message part.
Re: [RFT]: Debian Installer - Pre-Alpha1 images ready for testing
On Friday 29 January 2010, Holger Wansing wrote: - So, the first line is localized (german translation, correct) - The second chapter is NOT LOCALIZED (is in english !) - The third chapter is localized (german translation, correct) - The last line is NOT LOCALIZED (is in english !) You're right. I'd noticed it as well, but ignored it as just a result of incomplete translations :-/ I've uploaded a fixed version. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#433568: VLANs during install are important
On Saturday 30 January 2010, Josef Wolf wrote: This is why my original proposal was to decide from the value of netcfg/chosen_interface whether to load/configure all the vlan stuff. So you would *always* show vlan interfaces, even for regular users on normal systems? I don't think I like that idea very much. Note that during most installs the dialog to select an interface is not even displayed currently (if there's only one) and we certainly wouldn't want to change that. Somehow I managed to miss that, and google seems not to have it in its index (yet?). Can you give me some more pointer? It's also linked in the wiki, but: http://d-i.alioth.debian.org/doc/internals/ Would be just a change in a config option, right? So that's not really a big deal and could be done independently of the changes we are discussing in this thread, right? It would also mean a size increase of the initrd for all architectures... We usually don't do make such changes lightly. So, _PLEASE_ consider to activate this option independently from the results on this thread. Then, people would be able to configure vlans manually even if the efforts in this thread would fail for whatever reason... Please check that it works first and try to implement proper support. If that does not work out we can always discuss alternatives. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question about having an always clean base system in Debian Sid
On Thursday 28 January 2010, Geek87 wrote: Thanks! So it's impossible to have it work with tasksel. And for the base system? Does someone have an idea? That's a question that's probably better asked on the debian-user list. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565639: SunBlade 1000 installation report - boot fails after installation
reassign 565639 linux-2.6 2.6.30-8 severity 565639 serious affects 565639 debian-installer On Sunday 24 January 2010, Jurij Smakov wrote: Adding kernel team for comment: it looks like the value returned by uname -m has changed from 'sparc64' in kernel 2.6.26 to 'sparc' in 2.6.30 (and, probably, later ones). This breaks SILO, which uses this value to determine what first-stage bootloader to install, as a result the sparc machines installed with current daily installer builds turn unbootable by the end of installation. Thanks for tracing the cause to this. Reassigning to the kernel team for further investigation. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 32-bit install kernel sleeps off during installation
On Thursday 28 January 2010, Rainer Koenig wrote: Would be nice to figure out the why behind this problem. My guess at the moment is that it is related to a) the CPU which is a new AMD dual core athlon b) the 2.6.26-2-486 kernel that is used during the installation So I think there is a sort of incompatibilty on new Athlon processors and the -486 kernel from Debian. The problem you describe indeed sounds like a kernel problem. The first thing I would suggest to do is try if the Squeeze installer [1] (which currently uses a 2.6.30 kernel) still has the same problem. Question is: Is there a easy (means debian like and good documented) way to build a netboot image with a different kernel architecture. From my understanding this would mean replacing both the kernel image as well as all the modules that are provided from the initrd.gz image. You're in luck as the 686 kernel is already available as udebs. The steps are roughly as follows: - check out the lenny branch of the D-I source repository: svn co svn://svn.debian.org/svn/d-i/branches/d-i/lenny/installer - cd installer/build - edit config/i386.cfg and change -486 to -686 in KERNELVERSION - install build dependencies - build a netboot image using: make reallyclean; fakeroot make build_netboot - use either the netboot image itself, or the mini.iso Cheers, FJP [1] http://www.debian.org/devel/debian-installer/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
On Thursday 28 January 2010, Matthias Klose wrote: On 27.01.2010 23:26, Frans Pop wrote: On Wednesday 27 January 2010, Matthias Klose wrote: - did you consider building the udeb from a separate source package, build-depending on gcc-4.4-source? No, I had not considered that. It's an option that has both advantages and disadvantages. The main disadvantage IIUC would be that we'd have to upload or binNMU that separate package every time gcc gets uploaded (for source compliance), which means it needs special tracking. I think for that reason it's a solution the Release team is generally not all that happy with. no, that's wrong. this is only required if the upstream tarball changes, and this is easily discovered by looking at the build dependencies. Right. That reduces the problem a bit. It would mean that migrations of gcc could be blocked until a new gcc-udeb source package is uploaded. That would not be the case if the udebs are built from gcc. I'm still not convinced that the (IMO minor) disadvantages of having a udeb in gcc are sufficient to treat gcc different from all other packages that provide udebs. I would appreciate input from the Release team on this. Could someone please comment? See http://bugs.debian.org/567182#10 and later for most relevant info. Comments from others in the D-I team would also be welcome. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Build failures for hd-media
On Thursday 28 January 2010, Christian PERRIER wrote: Since 2 or 3 days, I'm having build failures on my local daily build for i386. The IA64 buildd has a similar error: mkfs.msdos -i deb1 -n Debian Inst -C ./tmp/cdrom/boot.img 32768 mkfs.msdos 3.0.8 (23 Jan 2010) mmd -i./tmp/cdrom/boot.img ::/efi Cannot initialize '::' make[2]: *** [arch_boot] Error 1 Can you check what packages you've upgraded recently (aptitude or dpkg logs) and try downgrading likely candidates? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Build failures for hd-media
On Thursday 28 January 2010, Frans Pop wrote: On Thursday 28 January 2010, Christian PERRIER wrote: Since 2 or 3 days, I'm having build failures on my local daily build for i386. The IA64 buildd has a similar error: mkfs.msdos -i deb1 -n Debian Inst -C ./tmp/cdrom/boot.img 32768 mkfs.msdos 3.0.8 (23 Jan 2010) mmd -i./tmp/cdrom/boot.img ::/efi Cannot initialize '::' make[2]: *** [arch_boot] Error 1 Can you check what packages you've upgraded recently (aptitude or dpkg logs) and try downgrading likely candidates? The aptitude log for my i386 chroot had: [UPGRADE] dosfstools 3.0.7-1 - 3.0.8-1 Downgrading that solved it. I'll file a BR. Cheers, FJP P.S. It really would be great if you could do such basic and simple checks yourself next time instead of always leaving it to others to solve problems. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of netcfg-static
On Thursday 28 January 2010, Josef Wolf wrote:
This can not be replaced by the generic netcfg with netcfg/use_dhcp set
to false or netcfg/disable_dhcp set to true?
In theory that could maybe be done (but see below). Also note that setting
an arch-dependent default while still fully supporting preseeding is not
trivial.
And won't generic netcfg fall back to static when dhcp fails? So even
the above settings should not be needed, IMHO.
But that does not give give the same functionality. For s390 static
configuration makes the most sense, *even* if there is a DHCP server on
the network.
What is so special about the s390 that it requires/deserves its own
netcfg? Why not introduce netcfg-thinkpad or netcfg-eeepc or something?
Because it is exclusively a server platform without any relevant
application in other environments.
Frans, I have not changed any wireless bits here.
Sorry, I misread the patch.
I don't really care about netcfg-static. I don't have a s390 and I don't
know anybody who have one. I just think duplicated code to be a bad
thing.
OTOH, it just works, so why worry too much about it?
I get the feeling that there's something wrong. You may argue that
wireless is not used by s390 anyway, but the bad feeling remains.
Maybe it is wrong, but nobody will ever hit it. IMO it would make sense to
strip all wireless support from -static (if possible).
-while (1) {
+/* Check to see if netcfg should be run at all */
[...]
On s390 network configuration is required.
But netcfg/enable is set to true by default. So I don't see a
functional change here.
Sure, there's no real functional change, but it's also not a necessary
change.
I did not know that netcfg-static is for s390 only and that
dhcp don't work on s390. But my original question remains: are there any
reasons _not_ to replace netcfg-static by generic netcfg?
One reason is to avoid needless inclusion of the dhcp3-client-udeb in the
s390 initrds. Another is to not complicate the code by needing different
defaults for static/dhcp.
I'm not saying that a cleanup of -static may not be useful, but it should
only be done with a proper appreciation of how its used. And dropping it
is more work than you might think.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Build failures for hd-media
On Thursday 28 January 2010, Joey Hess wrote: From 7:51 am timestamp, I assume Christian needed to get to work and didn't have time. It also said for the last few days. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: 32-bit install kernel sleeps off during installation
On Thursday 28 January 2010, you wrote: a) can I build a 32bit install image on a Debian amd64 system? Only if you create an i386 chroot (using debootstrap). b) is there a bit of documentation for those things? Websites, books or whatever. Wouldn't mind reading some stuff to get deeper into this. http://d-i.alioth.debian.org/doc/internals/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Question about having an always clean base system in Debian Sid
On Wednesday 27 January 2010, Geek87 wrote: I also would like to have it working similarly for the tasks: for example if I have a task Mail server installed depending on Sendmail and that the new version of this task now depends on Postfix, I would like Sendmail to be automatically removed and Postfix to be automatically installed. The technique above doesn't work for the tasks. I don't think that's possible as the package management system does not keep any state information about which tasks are installed. You have to see tasks and tasksel as an optional convenience feature, not as something that's a part of the core package management (unlike for example meta packages). Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of netcfg-static
On Wednesday 27 January 2010, Josef Wolf wrote:
I am wondering what netcfg-static is good for. Looks like it is an
(outdated) subset of the more generic netcfg.
No. It's used for s390:
installer/build/pkg-lists/netboot/s390.cfg:1:netcfg-static
installer/build/pkg-lists/generic/s390.cfg:3:netcfg-static
Unfortunately, even the
common code of the two programs seem to have diverged over time (no
wonder, duplicated code almost always suffers from this disease).
Given that the netcfg/disable_dhcp option exists, is netcfg-static
really needed?
Yes.
BTW: anybody sees how the GET_STATIC state in netcfg.c is supposed to
work:
I would need to look into that.
Here is a first attempt to bring those two programs in sync again. There
are more differences (especially in the GET_INTERFACE state), but I have
not done a closer look at them yet.
-enum { BACKUP, GET_INTERFACE, GET_HOSTNAME_ONLY, GET_STATIC,
WCONFIG, WCONFIG_ESSID, WCONFIG_WEP, QUIT} state = GET_INTERFACE; +
enum { BACKUP,
+ GET_INTERFACE,
+ GET_HOSTNAME_ONLY,
+ GET_STATIC,
+ WCONFIG,
+ WCONFIG_ESSID,
+ WCONFIG_WEP,
+ QUIT } state = GET_INTERFACE;
Wireless is useless for s390 (and static network config is almost per
definition not suitable for wireless), so the wireless bits should not be
synced.
-while (1) {
+/* Check to see if netcfg should be run at all */
[...]
On s390 network configuration is required.
netcfg.c - Configure a network via DHCP or manual configuration
- for debian-installer
+ for the debian-installer
This is incorrect.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of netcfg-static
On Wednesday 27 January 2010, Bastian Blank wrote: In the meantime this is correct. DHCP can be used on s390 with some constraints, but it needs to be disabled by default. Is it useful in practice though? I rather doubt anyone would want to set up an s390 box using DHCP. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
Source: gcc-4.4
Version: 1:4.4.3-1
Severity: wishlist
Tags: d-i patch
X-Debbugs-CC: debian-boot@lists.debian.org
Please consider the attached patch which adds a udeb for libgcc1 containing
only libgcc_s.so.1. That file is needed for the (directfb based) graphical
installer because of pthread_cancel(). See #373253 for background.
Until now we've been copying libgcc_s.so.1 from the host system at build
time, but it would be much cleaner to install it from a udeb.
I've tested the patch on amd64 and it creates the udeb correctly.
Please review the patch carefully as there may be aspects that I've missed
in the complexity of the build system or arch-specific considerations.
The file/udeb is currently only needed for amd64, i386 and powerpc, but it
seems most logical to just build the udeb for all architectures.
From my test build:
$ debc libgcc1-udeb_4.4.3-2~fjp_amd64.udeb
libgcc1-udeb_4.4.3-2~fjp_amd64.udeb
---
new debian package, version 2.0.
size 43198 bytes: control archive= 330 bytes.
277 bytes,10 lines control
Package: libgcc1-udeb
Source: gcc-4.4 (4.4.3-2~fjp)
Version: 1:4.4.3-2~fjp
Architecture: amd64
Maintainer: Debian GCC Maintainers debian-...@lists.debian.org
Installed-Size: 104
Depends: libc6-udeb (= 2.10)
Section: debian-installer
Priority: extra
Description: GCC support library
drwxr-xr-x root/root 0 2010-01-27 20:19 ./
drwxr-xr-x root/root 0 2010-01-27 20:19 ./lib/
-rw-r--r-- root/root 90040 2010-01-27 20:19 ./lib/libgcc_s.so.1
diff -u gcc-4.4-4.4.3/debian/control.m4 gcc-4.4-4.4.3/debian/control.m4
--- gcc-4.4-4.4.3/debian/control.m4
+++ gcc-4.4-4.4.3/debian/control.m4
@@ -188,6 +188,14 @@
environment.
')`'dnl
+Package: libgcc1-udeb`'LS
+XC-Package-Type: udeb
+Architecture: ifdef(`TARGET',`all',`any')
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library`'ifdef(`TARGET)',` (TARGET)', `')
+
Package: libgcc2`'LS
Architecture: ifdef(`TARGET',`all',`m68k')
Section: ifdef(`TARGET',`devel',`libs')
diff -u gcc-4.4-4.4.3/debian/control gcc-4.4-4.4.3/debian/control
--- gcc-4.4-4.4.3/debian/control
+++ gcc-4.4-4.4.3/debian/control
@@ -36,6 +36,14 @@
Description: GCC support library (debug symbols)
Debug symbols for the GCC support library.
+Package: libgcc1-udeb
+XC-Package-Type: udeb
+Architecture: any
+Section: debian-installer
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: GCC support library
+
Package: libgcc2
Architecture: m68k
Section: libs
diff -u gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
--- gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
+++ gcc-4.4-4.4.3/debian/rules.d/binary-libgcc.mk
@@ -14,8 +14,10 @@
p_lgcc = libgcc$(GCC_SONAME)
p_lgccdbg = libgcc$(GCC_SONAME)-dbg
+p_lgccudeb = libgcc$(GCC_SONAME)-udeb
d_lgcc = debian/$(p_lgcc)
d_lgccdbg = debian/$(p_lgccdbg)
+d_lgccudeb = debian/$(p_lgccudeb)
p_l32gcc = lib32gcc$(GCC_SONAME)
p_l32gccdbg = lib32gcc$(GCC_SONAME)-dbg
@@ -42,7 +44,10 @@
dh_installdirs -p$(p_lgcc) \
$(docdir)/$(p_lgcc) \
$(libdir)
-
+ dh_installdirs -p$(p_lgccudeb) \
+ $(libdir)
+
+ cp $(d)/$(PF)/lib/libgcc_s.so.$(GCC_SONAME) $(d_lgccudeb)/$(libdir)/.
ifeq ($(with_shared_libgcc),yes)
mv $(d)/$(PF)/lib/libgcc_s.so.$(GCC_SONAME) $(d_lgcc)/$(libdir)/.
endif
@@ -57,8 +62,9 @@
debian/dh_rmemptydirs -p$(p_lgcc)
debian/dh_rmemptydirs -p$(p_lgccdbg)
dh_strip -v -p$(p_lgcc) --dbg-package=$(p_lgccdbg)
- dh_compress -p$(p_lgcc) -p$(p_lgccdbg)
- dh_fixperms -p$(p_lgcc) -p$(p_lgccdbg)
+ dh_strip -v -p$(p_lgccudeb)
+ dh_compress -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
+ dh_fixperms -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
ifeq ($(with_shared_libgcc),yes)
dh_makeshlibs -p$(p_lgcc) -V '$(p_lgcc) (= $(DEB_LIBGCC_SOVERSION))' \
-- -v$(DEB_LIBGCC_VERSION)
@@ -68,17 +74,17 @@
endif
cat debian/$(p_lgcc)/DEBIAN/shlibs debian/shlibs.local
endif
- dh_shlibdeps -p$(p_lgcc)
- dh_gencontrol -p$(p_lgcc) -p$(p_lgccdbg) \
+ dh_shlibdeps -p$(p_lgcc) -p$(p_lgccudeb)
+ dh_gencontrol -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb) \
-- -v$(DEB_LIBGCC_VERSION) $(common_substvars)
mkdir -p $(d_lgcc)/usr/share/lintian/overrides
echo '$(p_lgcc): package-name-doesnt-match-sonames' \
$(d_lgcc)/usr/share/lintian/overrides/$(p_lgcc)
- dh_installdeb -p$(p_lgcc) -p$(p_lgccdbg)
- dh_md5sums -p$(p_lgcc) -p$(p_lgccdbg)
- dh_builddeb -p$(p_lgcc) -p$(p_lgccdbg)
+ dh_installdeb -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
+ dh_md5sums -p$(p_lgcc) -p$(p_lgccudeb)
+ dh_builddeb -p$(p_lgcc) -p$(p_lgccdbg) -p$(p_lgccudeb)
trap '' 1 2 3 15; touch $@; mv $(install_stamp)-tmp $(install_stamp)
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
-- Forwarded Message -- From: Matthias Klose d...@debian.org On 27.01.2010 21:03, Frans Pop wrote: Please consider the attached patch which adds a udeb for libgcc1 containing only libgcc_s.so.1. That file is needed for the (directfb based) graphical installer because of pthread_cancel(). The patch itself looks ok, some other questions: - did you consider building the udeb from a separate source package, build-depending on gcc-4.4-source? This way you don't need to copy the file, and you don't need to add additional constraints for freezes on the gcc-4.4 package. You could even copy the whole packaging and conditionalize on the source package name for this new source package to minimize the maintainance effort and get the updates/patches. With --enable-languages=c --disable-bootstrap, the additional build time penalty is the extra build of a one stage compiler for gcc. - you don't need the package for m68k/hppa yet, but if you do build for every architecture anyway, please don't build the package for these archs, but libgcc2, libgcc4, and libgcc6 udebs. - the patch should be prepared for gcc-4.5 as well. If there are additional constraints for uploads of the gcc-4.4 source package during freeze times, I would prefer the approach to build the udeb's from a separate source. Matthias --- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#567182: gcc: Please add libgcc1-udeb for Debian Installer
Thanks a lot for the quick reply. On Wednesday 27 January 2010, Matthias Klose wrote: The patch itself looks ok, some other questions: - did you consider building the udeb from a separate source package, build-depending on gcc-4.4-source? No, I had not considered that. It's an option that has both advantages and disadvantages. The main disadvantage IIUC would be that we'd have to upload or binNMU that separate package every time gcc gets uploaded (for source compliance), which means it needs special tracking. I think for that reason it's a solution the Release team is generally not all that happy with. - you don't need the package for m68k/hppa yet, but if you do build for every architecture anyway, please don't build the package for these archs, but libgcc2, libgcc4, and libgcc6 udebs. For my current patch that would mean also adding those udebs in the control.m4 file, correct? And to avoid needing to code exceptions in rules.d/binary-libgcc.mk it's probably simplest to just do that even if we don't use them. - the patch should be prepared for gcc-4.5 as well. Will do if we decide on keeping it in gcc. If there are additional constraints for uploads of the gcc-4.4 source package during freeze times, I would prefer the approach to build the udeb's from a separate source. No, given how the udeb will be used there are no additional restrictions. And now that migration to testing of udebs is supported in britney, there's also no longer any inconvenience there. (That was an important consideration why I've personally not pushed for this change in the past.) The only point for attention is that if gcc would get uploaded after the final upload of D-I for a release, FTP-masters will need to keep a copy of the version included in that D-I build [1]. But that's something that already also done for other packages and is an item for the D-I and Debian release managers, not for the gcc maintainers. Because of the above I think building the udeb from gcc is the most logical choice. Cheers, FJP [1] They create a special suite for that purpose. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Spam cleaning in list archives: one last effort needed
Christian Perrier wrote: The remaining months, that should be targeted by anybody but me, Frans Pop, Holger Wansing and Lee Winter, are: * March 1999 to May 2000 * October 2000 to July 2002 * May and June 2004 I just see that as of yesterday the whole archive has now been scanned by at least 5 persons. Yay! The honor of filling in the last bits goes to Nicolas Bertolissio for bringing 2001/04-09 to 5 scans. It's also nice to see that quite a few months have had 6 or even 7 scans, which reduces the risk of spams being left over because one person missed it. Because of that such additional scans are quite nice, but not a must. Of course, from now on scanning a month should be rather boring as you should encounter only very few spams. Maybe an opportunity pick a few threads and read up on the history of the project instead ;-) My thanks (as the person who kicked of this little - or not so little - project) to everybody who's contributed to the cleanup. Cheers, FJP signature.asc Description: This is a digitally signed message part.
netcfg: using udhcpc to get dhcp lease fails
I've just tried running the SVN version of netcfg which includes the following change: [ Otavio Salvador ] * Add support for udhcpc. This was based on Luk Claes but changed to avoid dropping support for dhclient, dhclient3 and pump for now. I built a netboot image without dhcp3-udeb to test udhcpc, but it failed miserably as it did not manage to get a lease during netcfg. How well was this tested? It did work when run from a debug shell: # ip link set up dev eth0 # udhcpd udhcpd (v1.14.2) started Sending discover... Sending select for 10.19.66.61 Lease of 10.19.66.61 obtained, lease time 7200 Another issue is that I could not find a lease file anywhere, which makes troubleshooting network issues more difficult. It also means that using udhcpd would break setting a preseed file from the DHCP server config [1]. And we have had bug reports in the past when that no longer worked. As there was no lease file I could not verify if the filename option was even included in the lease or not. Cheers, FJP [1] http://d-i.alioth.debian.org/manual/en.i386/apbs02.html#preseed-dhcp See also dhcp_preseed_url() in preseed.sh. signature.asc Description: This is a digitally signed message part.
Re: Spam cleaning in list archives: one last effort needed
Christian Perrier wrote: If you're interested in statistics, you can look [2] to learn that our list is by far the one that got most cleaning. Here's a little overview of the lists with the most removed posts, including the ratio of deleted spam over reviewed posts. As you can see we have a _very_ high ratio, so our scanning process has been very effective. Other lists have had much more ham reported, but that does show the importance of the review stage. There are a few other lists that have a similarly high ratio, but none that are anywhere near the volume that we've processed. debian-boot 4733 (96%) debian-www 4290 (84%) debian-devel 2907 (69%) debian-user 2217 (25%) debian-user-german 1744 (10%) debian-project 1028 (73%) debian-user-spanish 1024 (13%) debian-qa 766 (66%) debian-newmaint 680 (85%) debian-release 625 (75%) debian-x 501 (71%) debian-vote 470 (79%) debian-chinese-gb 470 (33%) debian-java 463 (69%) debian-mentors 442 (29%) debian-user-portuguese 424 (30%) debian-apache 412 (16%) debian-legal 362 (69%) debian-laptop 323 (57%) cdwrite 296 (27%) Our ratios of deleted spam over nominated posts and over considered posts are also quite high (resp. 50% and 86%) when compared to other lists. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Tuesday 19 January 2010, dann frazier wrote: I'm currently uploading refreshed linux-kernel-di packages built against 2.6.26-21. Once accepted, I can go ahead and refresh d-i. Please do. Please let me know if there's any other pending d-i changes for stable that I should wait for. None. Everything is already in place. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565938: debian-installer: provide option to skip step(s) in interactive interface
On Tuesday 19 January 2010, Michael Prokop wrote: Providing it just within the relevant dialogs isn't an option, nor? IMO not: 1) it is redundant as we can (and do, where needed) offer the same functionality using debconf questions 2) it would clutter the user interface 3) it goes against the design principles of D-I 4) it would require an extention to the debconf protocol 5) it would complicate scripts I'm well aware of preseeding options like d-i passwd/make-user boolean false but it would be nice to be able to skip e.g. the user account creation within its *interactive* interface during runtime as well. You can already do that when installing at lower priorities (expert mode). What I meant here is that there is be a question do you want to create a regular user account, not skipping the component in the menu. I'm aware of it, though IMHO it isn't the same experience from a user's POV. It has exactly the same end result. And it's a lot more structured. And most users *will* want to create a user account, so it is perfectly natural to only offer the option at lower debconf priorities. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#352758: -- installation: etch installer fails to detect/configure PC card NIC
On Monday 18 January 2010, Chris Jones wrote: Since I have the hardware available and you probably don't, would you need me to download and test an unstable or experimental install in this respect? There is no version of the installer based on the 2.6.32 kernel available yet. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#352758: -- installation: etch installer fails to detect/configure PC card NIC
On Monday 18 January 2010, Chris Jones wrote: First of all, why are you gentlmen replying to me directly instead of posting to the list? We are replying to the *bug report* and CCing you as the submitter of the bug report. Most submitters of bug reports are not subscribed to the mailing list, so we need CC them to make sure they see replies. Because the reply to the BR itself gets sent to the list, you also see it there. Please keep *all* replies to the bug report because that is where the history should be kept. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#352758: -- installation: etch installer fails to detect/configure PC card NIC
On Sunday 17 January 2010, Holger Wansing wrote: Could you try to find out if the firmware is non-free? Could it be included in the debian-archive? In unstable it looks to be included in the firmware-linux-free package, but with a changed extension: http://packages.debian.org/search?searchon=contentskeywords=3CCFEM556mode=filenamesuite=unstablearch=any Note that that file is based on the 2.6.32 kernel, not on the 2.6.30 kernel used in current versions of the installer for Squeeze. The fact that it does not exist in testing or stable could mean that the firmware is included in the module, but maybe not. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565639: SunBlade 1000 installation report - boot fails after installation
On Sunday 17 January 2010, Jurij Smakov wrote: Comments/Problems: Now that http://bugs.debian.org/562594 is fixed, I was able to continue the installation and it all went fine until the end. However, after finishing the installation machine fails to boot [...] As the installation itself works fine I would guess this is not an installer problem, but a kernel issue. Maybe it leaves the hardware in an incorrect state for the reboot. Have you tried a cold boot of the installed system? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] Blockers for Debian Installer - Alpha1 release
On Saturday 16 January 2010, Ian Campbell wrote: Possibly just an issue with the mirror the buildd is using? Since packages.debian.org seems to think that package is in both squeeze and sid and local builds Work For Me(tm). See the first lines of the log: WARNING: mirror 'http://hetzner:downl...@download.hetzner.de/debian/mirror' appears to be invalid; skipping Using generated sources.list.udeb: deb copy:/home/installer/build/ localudebs/ So it end up using only localudebs, which obviously isn't enough. No idea what's in the sources.list on that buildd, but it's fairly certain that it's so unconventional that D-I cannot parse/use it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] Blockers for Debian Installer - Alpha1 release
On Saturday 16 January 2010, Frans Pop wrote: On Saturday 16 January 2010, Ian Campbell wrote: Possibly just an issue with the mirror the buildd is using? Since packages.debian.org seems to think that package is in both squeeze and sid and local builds Work For Me(tm). See the first lines of the log: WARNING: mirror 'http://hetzner:downl...@download.hetzner.de/debian/mirror' appears to be invalid; skipping Using generated sources.list.udeb: deb copy:/home/installer/build/ localudebs/ So it end up using only localudebs, which obviously isn't enough. No idea what's in the sources.list on that buildd, but it's fairly certain that it's so unconventional that D-I cannot parse/use it. AFAICT wget should support an URL in that format, so my best guess is that the proxy that's being used does not respond correctly to 'wget --spider'. That command is used by gen-sources.list.udeb to test the validity of a source for D-I. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565511: ext4.ko module missing from initramfs
reassign 565511 initramfs-tools 0.93.4 retitle 565511 ext4.ko module missing from dep initramfs thanks On Saturday 16 January 2010, ael wrote: On further investigation, I find that /lib/modules/2.6.30-2-686/kernel/fs/ext4/ext4.ko is missing from the initramfs. I assume that this explains the failure. I do now seem to remember choosing a slim initrd during installation. That's the problem. The ext4 module *would* have been included if you'd selected the standard initrd. Going into rescue mode, I could not find any way to revert to a full initrd. Just edit the initramfs-tools configuration file in /etc for the installed system to use 'MODULES=most' and then regenerate the initrd (see 'man update-initramfs'). I could not see any bug about this against linux-image-2.6.30-2-686. I assume it generates initrd? No, the package is initramfs-tools. Not sure that it is a bug though. I'm reassigning your report because maybe initramfs-tools should be detecting that ext4 is needed in this case. We'll let its maintainer decide. So it seems that while the installer supports ext4, the installed target system initrd does not. Only because you used an expert option without knowing the consequences or knowing how to fix it. You really should have stuck to the default! So I guess that I will have to compile my own kernel on the target and then change to ext4 via the rescue mode (it's the root partition) later. That's absolutely not necessary. You only need to get ext4 included in the initrd. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565243: cdrom-retriever: No progress bar movement when fetching packages
reassign 565243 pkgsel 0.24 thanks On Thursday 14 January 2010, Petter Reinholdtsen wrote: Would it be possible to get the DVD installation to behave more like the network installation, where the progress bar move forward while packages are fetched. Even if all packages are local, it take a while to process 1300 packages and it would be nice if this caused some visible progress on the progress bar. I doubt that this is something that can be fixed in Debian Installer. The display of the progress bar at that stage is not determined by the retriever udebs (the retrievers are used for loading *udebs*, not for regular packages), but by APT. Probably the difference is that with DVD based installs there simply isn't a download phase and thus APT does not provide download progress info. So you'll need to look at APT instead of D-I if you want this improved. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Monday 11 January 2010, Frans Pop wrote: On Thursday 24 December 2009, Frans Pop wrote: For stable (20090123lenny5) all arches except mips were successful. I've already mailed the mips buildd maintainers. I've not heard anything back from the mips buildd maintainers, despite sending several mails. Please retry on a different buildd than ball. It's now built correctly. Problem (error in regexps) has been identified and fixed for future uploads. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: My warning about Lenny
(Moving this to the d-boot list. Please reply to that list only.) Martin Wuertele wrote: * Joey Hess jo...@debian.org [2010-01-10 23:23]: This is not the case in Debian 5.0. Nor was it the case with Debian 4.0. Debian 3.1 (2005) was the last one to do that. Interesting. Tasksel on my Squeeze box still does that. It really shouldn't, and it doesn't for me in sid. We've also had no other reports of that happening. How exactly did you determine that it does? The best way to check is to select both Graphical desktop environment and manual package selection and then check the list shown in aptitude of Packages to be installed (not the ones to be installed automatically as dependencies). There is only way it can do that: if at some point you preseeded a the debconf template 'tasksel/desktop' to install both. But that's unlikely. What's the output of 'debconf-show tasksel | grep /desktop'? Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564719: please provide way to lock console
On Monday 11 January 2010, Holger Levsen wrote: I'll clone this bug and reassign to vlock, requesting such a udeb and then make the vlock bug a blocker on this one. I do not agree with this way of doing it because now it has implicitly become a request for the maintainer of vlock to provide such a udeb, who is unlikely to have the skills to provide it. IMO a BR against vlock should only have been created *after* someone who has sufficient knowledge of D-I has created a proper patch for vlock and *after* such a patch has been tested and reviewed by the D-I team. vlock is also maybe only one possible way of implementing the feature. There could be others. I would prefer that the BR against vlock be closed for now. The maintainer of vlock should IMO not have this on his wishlist. The feature request is for D-I, not for vlock. It is sufficiently documented with this BR. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Thursday 24 December 2009, Frans Pop wrote: As all packages needed to build D-I were now available, I have uploaded for both stable and oldstable. An accept is not needed; apparently D-I gets an automatic accept due to by-hand processing of the image tarballs. For stable (20090123lenny5) all arches except mips were successful. I've already mailed the mips buildd maintainers. I've not heard anything back from the mips buildd maintainers, despite sending several mails. Please retry on a different buildd than ball. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Monday 11 January 2010, dann frazier wrote: On Mon, Jan 11, 2010 at 06:57:56PM +0100, Frans Pop wrote: On Thursday 24 December 2009, Frans Pop wrote: As all packages needed to build D-I were now available, I have uploaded for both stable and oldstable. An accept is not needed; apparently D-I gets an automatic accept due to by-hand processing of the image tarballs. For stable (20090123lenny5) all arches except mips were successful. I've already mailed the mips buildd maintainers. I've not heard anything back from the mips buildd maintainers, despite sending several mails. Please retry on a different buildd than ball. mayr had the same failure. The buildd admin is looking at it, but we're not sure what the problem is. Do you have a guess as to what is causing it? See the mail(s) I sent earlier to m...@buildd.debian.org. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: chose unrelated swap and no way to lock console
On Sunday 10 January 2010, Holger Levsen wrote: I'm installing lenny atm on a harddrive connected via usb to an laptop. I choose guided partitioning with encrypted lvm and this failed as the laptop has a harddrive with insecure swap. So I had to take out the harddrive to do the installation on the external harddrive. Please file a proper BR against partman-auto-crypto. Secondly I wonder if you would consider it a sensible wishlist feature to have a vlock.udeb, so one can lock the console, which is useful for locking the machine when the data on a big harddrive is erased for encrypted lvm, which can take several hours. Main issue is that we don't have a password for the root (?) account in the installer environment. And IMO users should not be asked to provide one *unless* they actually want to lock the console. The only acceptable implementation IMO would be to have it as an _optional_ component (i.e. only loaded if explicitly requested by the user during anna [1]), with a postinst that then takes care of setting the password. The existing network-console udeb could provide inspiration. Also, the udeb would have to be very minimal: no deps on pam, adduser. Feel free to file a wishlist BR. But unless you're willing to implement it yourself I doubt that will achieve much. Again: is this is a known+reported (and still existing in squeeze) bug? It's not a bug by definition. At most a missing feature. [1] Which means installing at mediumlow priority, or booting with 'modules?=vlock-udeb'. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: proposed patch to select an ISO among multiple ones
On Friday 08 January 2010, Fred wrote: I see 2 solutions for my problem : - either I parse all ISO files from all disks/partitions, and ask for choice if any : I thought it could be quite long to parse all partitions, and this way all installer' users have to wait for this. - either after each ISO file found, we ask if it's the right one. I followed this last track, and put the question with a 'medium' debconf level, so in 'normal' installations, the question shouldn't either appear and block the user (it would also be annoying to add a step to all people for a need of few ones). Your solution is reasonably acceptable, but not what I would prefer. My preferred solution would be: 1) display a dialog listing devices that are available for scanning (possible enhancement: offer option to add new devices) 2) let user select the device to be scanned 3) if more than one found: display dialog with images found on the device and let user select The Go Back option should of course allow the user to select a different device. Special care should be taken that everything also works with a preseeded hd-media installation. It's not totally obvious how the device to scan could be preseeded, so maybe there should still be a fall back to scan all and take the first. The first 2 steps should probably be coded generically because they would IMO also improve the selecting of a device to be used to load missing firmware from (we've had a few bug reports that could be fixed by that). Again, your solution *is* acceptable. Please make sure that the ask_second_pass option still works. And maybe avoid displaying both your dialog *and* the success dialog (there should be no need to have both!). I've patched the iso-scan source and tried to test the result, without success, because I didn't know how to rebuild a whole installer image. That's one way of doing it (and sometimes the only way), but in this case it can be done simpler. Here is what I've done, if you see some advices to let me achieve the tests, tell me ; if someone could also test the patch, it would be nice ! $ debconf-loadtemplate iso-scan /media/usbdisk/iso-scan.templates This fails because at that time the debconf database has already been loaded by the running debconf instance and is in use from memory instead of from the (RAM) disk, so updating the version on the disk by starting a separate *second* debconf process as you do here has no effect, which explains the error. There are two ways to do this so it works: - build the iso-scan udeb, copy that to the D-I environment and install it using 'dpkg --unpack udeb' (best/simplest method) - use your method but run the 'debconf-loadtemplate' command *from inside* a script in the running debconf instance; for example by adding the command to an existing postinst script (save-logs is usable for this) and then executing that postinst from the main menu Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: proposed patch to select an ISO among multiple ones
On Saturday 09 January 2010, you wrote: Again, your solution *is* acceptable. Oh, and please fix your indentation: the new function you added is a mess. Please use TABs only. And please don't use spaces in front of punctuation marks in your comments: you're writing English, not French. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#433568: VLANs during install are important
On Saturday 09 January 2010, Ferenc Wagner wrote: It would be less of a problem if d-i used the Busybox ip applet It does (and nothing else). *and* if that supported VLANs. That might be an issue. No idea. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: proposed patch to select an ISO among multiple ones
On Saturday 09 January 2010, Fred wrote: Ok, thanks for the advice. I sent back my e-mail to the reportbug tool, and created bug #564441. I hope to find more time next week to be able to learn how to rebuild a d-i image… Hi, I also sent two replies, but maybe you've missed them: - http://lists.debian.org/debian-boot/2010/01/msg00092.html - http://lists.debian.org/debian-boot/2010/01/msg00093.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564033: tasksel forces installation of many useless packages on hr locale setups even when you don't select anything
On Thursday 07 January 2010, Christian PERRIER wrote: Quoting Josip Rodin (j...@debbugs.entuzijast.net): IMHO the non-desktop installation for Croatian needs to lose all of: aspell, myspell, whatever-the-hell-spell, dict-*, doc-linux-*, texlive-* enca because none of these packages are *required* for a Croatian Debian system. OK, maybe doc-linux-hr is a good default, but the rest is not. The localization tasks are not about what is *required*, but about what an average Croation user might *expect* to have installed by default. IMO that includes basic localized documentation and spell checking. Well, most languages do include *spell packages in the default non desktop install. This is indeed most often the only thing that's listed in the relevant tasks. I also think those should be kept. They have been accepted as standard packages for any localized installation. If there is a demand to allow installation without using localization tasks then IMO tasksel should add a separate option for that, either triggered by a low level debconf question or by explicitly listing a special localization task that is selected by default but can be unselected. I've always considered it somewhat inconsistent that tasksel allows to unselect standard packages, but does not allow to unselect the localization tasks. Of course, what I say here doesn't apply to texlive-* packages which are not in other language tasks. Those are the main problem as they pull in a lot of texlive. They should never have been included as they are not an enhancement of a normal base system, but instead pull in totally new functionality. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563861: localechooser: Maybe ask preferred locale in more cases?
tag 563861 pending thanks I've just committed the change. At medium and low priority we do now have the situation which Colin warned against: effectively we display the shortlist dialog twice in a row. And I do agree that it's not the most beautiful design. However, I think that this commit does improve consistency and that in combination with all other recent changes it's still logical: - the first shortlist now clearly has the purpose of selecting the user's location, while the second one clearly selects the system locale; changing the dialog titles has helped a lot with that - even though the dialogs essentially have the same choices, they look rather different because of the addition of the second column with locales for the second one; - the choice from the first shortlist sets the correct default for the second, so normally the second can simply be entered through. On Thursday 07 January 2010, Ferenc Wagner wrote: But then it's maybe better to rewrite the whole para as: There are multiple locales defined for the language you have selected. You can now select your preference from those locales. The locale that will be used is listed in the second column. I agree. The rewrite was still only for the second case. I've kept two distinct texts as IMO the explanation of context is important. If you allow a general observation: it seems that problems arise if the texts depend on each other, since their individual presence depends on the priority relations. If you look at the committed change you'll see that the implementation is fairly straightforward. And note that which text gets displayed does not depend on the priority, but on the question is a locale defined for the combination of language and country. The same question also determines at which priority the dialog is displayed. While it's useful if the installer explains its steps (the dependent texts serve this very purpose), maybe we have to accept a compromise and relegate that into the logs. That is a choice we have made in other places, but it's not needed here. But I do admit that localechooser is now fairly extreme in building dialogs at runtime. The main reason for that is not because it is the only way to implement it, but rather to limit the size of the udeb as much as possible. Without building the dialogs at runtime, the template file would contain multiple repetitions (not just 2 or 3, but many more) of the same strings and their translations, and its size would explode. I expect that despite all the recent changes and even when fully translated again, the size of the localechooser udeb will be about equal to the current Lenny version. And that's exactly because I've reduced duplication of a number of strings. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
localechooser: One more proposed change
On Wednesday 06 January 2010, Frans Pop wrote:
With this patch the preferred locale question will be asked
- at high priority for the English/Germany case (default: en_US.UTF-8)
- at medium priority for the English/Australia case (default:
en_AU.UTF-8)
After testing this change I think we should consider a change to the final
two locale selection dialogs.
First of all we need a minor string change because the selected system
locale no longer depends only on selected language/country but can also
be the selected preferred locale.
So IMO we need:
_Description: Additional locales:
- Based on the selected language and country, the default locale selected
- for the installed system is '${LOCALE}'.
+ Based on your previous choices, the default locale for the installed
+ system is '${LOCALE}'.
I also think we should now change the option to select additional locales
(i.e. the last two dialogs) from medium to low priority:
- as Colin has argued, showing a raw list of locales really does require
the user to know exactly what locales are and is therefore a real
expert option
- it is less needed at medium priority because we still offer quite a lot
of flexibility at medium priority
- the need to offer legacy locales if less than it used to be
So that would mean:
- db_input medium $tpl_supportedlocales || [ $? -eq 30 ]
+ db_input low $tpl_supportedlocales || [ $? -eq 30 ]
[...]
- db_input medium $tpl_di_locale || [ $? -eq 30 ]
+ db_input low $tpl_di_locale || [ $? -eq 30 ]
Comments?
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: localechooser: One more proposed change
On Friday 08 January 2010, Frans Pop wrote:
First of all we need a minor string change because the selected system
locale no longer depends only on selected language/country but can also
be the selected preferred locale.
Sorry, I pasted an old version of this change. Here's what I propose:
_Description: Additional locales:
- Based on the selected language and country, the default locale selected
- for the installed system is '${LOCALE}'.
+ Based on your previous choices, the default locale currently selected for
+ the installed system is '${LOCALE}'.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563861: localechooser: Maybe ask preferred locale in more cases?
On Wednesday 06 January 2010, Christian PERRIER wrote: +1 for me. Nice catch, again. That specific example would have raised suggestions at some time so it's much better if we can anticipate them. OK. But I just see that this does require a string change :-/ Current text is: There is no locale defined for the combination of language and country you have selected. You can now select your preference from the locales available for the selected language. The locale that will be used is listed in the second column. And the first sentence is obviously not correct for this change. One solution could be to just drop the first sentence for this case. Another option could be to make the first sentence variable and change it as follows for this case: There are multiple locales defined for the language you have selected. But then it's maybe better to rewrite the whole para as: There are multiple locales defined for the language you have selected. You can now select your preference from those locales. The locale that will be used is listed in the second column. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563861: localechooser: Maybe ask preferred locale in more cases?
Package: localechooser Version: 2.21 Severity: wishlist There is one use case currently not covered by localechooser that arguably should be covered, though IMO only at medium priority. This use case is as follows. A user is from England, but working in Australia. So he selects English as language and Australia as country. Currently he will automatically get en_AU.UTF-8 as locale. Question is: should he have the option to select en_GB.UTF-8 as preferred locale? After all, a Brit working in Germany gets that option, so why not a Brit working in Australia. As I'm not sure whether this complication is really needed, I'm only attaching the simple (but untested) patch needed to implement it instead of committing it. With this patch the preferred locale question will be asked - at high priority for the English/Germany case (default: en_US.UTF-8) - at medium priority for the English/Australia case (default: en_AU.UTF-8) Showing the dialog at medium prio in the second case seems to me consistent with the rest of localechooser: we should not bother Australians living in Australia with this question during default installations. --- localechooser (revision 61935) +++ localechooser (working copy) @@ -759,12 +759,16 @@ db_settitle localechooser/title/locale askedpreflocale= - if [ -z $locale_preseeded ] [ $use_lang ] \ - ! has_choice $tpl_shortlist $COUNTRYCODE; then + if [ -z $locale_preseeded ] [ $use_lang ]; then build_preferredlocale_choices $LANGUAGE $LOCALE + preflocale_prio=high + if has_choice $tpl_shortlist $COUNTRYCODE; then + preflocale_prio=medium + fi + db_capb backup align - db_input high $tpl_preferredlocale || [ $? -eq 30 ] + db_input $preflocale_prio $tpl_preferredlocale || [ $? -eq 30 ] askedpreflocale=1 fi ;; -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558686: Partition manager fails to update kernel partition table
In particular: v1.9.0-137-g048602c http://git.debian.org/?p=parted/parted.git;a=commitdiff;h=048602c1d5df 93ddf4 ped_partition_busy: do not call the libparted exception handler Modify libparted/arch/linux.c _partition_get_part_dev() to not call _device_stat() but instead use stat directly, as _device_stat() calls the libparted exception handler, and we don't want this here, the only caller of _partition_get_part_dev() is _partition_is_mounted(), which in turn only gets called by linux_partition_is_busy(), and we don't want to throw exceptions from ped_partition_busy(). This issue was noticed in combination with pyparted as used by anaconda, see: http://bugzilla.redhat.com/527035#c10 I fear the changes that this specific one depends on will change our ABI and this will cause a soname bump. After removing the change to the NEWS file and including the patch in debian/patches, the patch applies without problem to current parted from unstable. I'll try to prepare the package for try it out. I've rebuilt the libparted udeb including this patch and installed that in my test system before starting partman and then repeated the test described in message #20 in the BR. The patch does *NOT* fix the issue. I can still reproduce. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Migration hint needed for wireless-tools
On Monday 04 January 2010, Luk Claes wrote: We need to do another upload of debian-installer to fix an issue with syslinux menus on x86, but it FTBFS on amd64 because: The following packages have unmet dependencies: netcfg: Depends: libiw30-udeb (= 30~pre1) but it is not installable Apparently britney has decided to migrate the binNMUs for netcfg without checking that their dependencies are met. It would be nice if that bug were fixed as well. It did not, though our tools failed to output that this was the culprit. Not sure what you mean by this was the culprit. The binNMUs should *never* have been allowed to migrate without wireless-tools migrating first or at the same time. The dependencies of the binNMU'ed udebs where clearly ignored, either by britney or by the release team. If this had happened after a D-I release, it would have broken all netboot images and weekly CDs. What went wrong? How will the same happening again be prevented for the future? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[RFC] Final (?) changes to localechooser templates
Here's a proposal for some final tuning to the country selection dialogs.
Partly as a result of the discussion with Florian Zumbiehl in #559795.
We have three dialogs:
1) country shortlist based on language
2) continent
3) country per continent.
Main reason for the change is that any of the three can be the first dialog
displayed after selection of a language:
1) if selected language has multiple locales/countries (e.g. English)
2) if selected language has no default country (e.g. C, Esperanto)
3) if selected language has only one locale/country (e.g. Finnish, Czech)
This means that all need a proper introduction what the purpose of the
selection is. And 3) was missing some indication of the current continent;
adding that makes the Go Back to select a different continent
instruction more logical.
Country has been replaced with location in a few places because it is
more generic and to better match the recently improved dialog title.
In this proposal all three dialogs start with the same text:
Select your location
The selected location will be used to set your time zone and also
for example to help select the system locale. Normally this should
be the country where you live.
Note that I've changed the first sentence to further de-emphasize the role
of the location in the selection of locale.
Below that intro you get one of the following.
The country shortlist dialog:
This is a shortlist of locations based on the language you selected.
Choose other if your location is not listed.
Country, territory or area:
The continent dialog:
Select the continent or region to which your location belongs.
Continent or region:
The country per continent dialog:
Listed are locations for: continent. Use the Go Back option to
select a different continent or region if your location is not listed.
Country, territory or area:
Cheers,
FJP
P.S. I've now also eliminated duplication of strings in the templates file
for the continents dialogs, so the size of the udeb should become smaller.
Index: localechooser
===
--- localechooser (revision 61818)
+++ localechooser (working copy)
@@ -13,6 +13,7 @@
tpl_shortlist=localechooser/shortlist
tpl_continentlist=localechooser/continentlist
tpl_countrylist=localechooser/countrylist
+tpl_countrytxt=localechooser/text/country
tpl_supportedlocales=localechooser/supported-locales
tpl_preferredlocale=localechooser/preferred-locale
@@ -280,6 +281,29 @@
echo $RET, | grep -q $value,
}
+# Get translation of current selection in select list
+# Assumes untranslated values don't contain commas
+choice_trans() {
+ local RET template value list list_trans
+ template=$1
+ value=$2
+
+ # Use Choices-C to get the untranslated values
+ db_metaget $template Choices-C
+ list=$(echo $RET | sed 's/, */,/g')
+ db_metaget $template Choices
+ list_trans=$(echo $RET | sed 's/\\,/#%#/g; s/, */,/g')
+
+ while :; do
+ if [ ${list%%,*} = $value ]; then
+ echo ${list_trans%%,*} | sed 's/#%#/\\,/g'
+ break
+ fi
+ list=${list#*,}
+ list_trans=${list_trans#*,}
+ done
+}
+
# Set defaults for continent based on country
set_default_continent() {
local IFS RET country continents c continent
@@ -290,9 +314,9 @@
return
fi
- # Use Choices-en.UTF-8 to avoid getting translated values
- db_metaget $tpl_continentlist Choices-en.UTF-8
- continents=$(echo $RET | sed s/, /,/g)
+ # Use Choices-C to get the untranslated values
+ db_metaget $tpl_continentlist Choices-C
+ continents=$(echo $RET | sed 's/, */,/g')
IFS=,
for continent in $continents; do
@@ -491,10 +515,10 @@
db_set $tpl_di_consoledisplay $CONSOLE
log Set $tpl_di_consoledisplay = '$CONSOLE'
- db_metaget localechooser/text/country1 description
- txt_country1=$RET
- db_metaget localechooser/text/country2 description
- txt_country2=$RET
+ db_metaget $tpl_countrytxt/1/country description
+ ctxt1=$RET
+ db_metaget $tpl_countrytxt/2 description
+ ctxt2=$RET
X_INSTALLATION_MEDIUM=$(lsb_extract X_INSTALLATION_MEDIUM)
if [ $sel_language ] [ $LANGUAGE != en ] \
@@ -571,9 +595,9 @@
db_fget $tpl_di_country seen
db_fset $tpl_shortlist seen $RET || true
- db_subst $tpl_shortlist TXT1 $txt_country1
- db_subst $tpl_shortlist TXT2 $txt_country2
- db_metaget localechooser/text/country3-short description
+ db_subst $tpl_shortlist TXT1 $ctxt1
+ db_subst $tpl_shortlist TXT2 $ctxt2
+ db_metaget $tpl_countrytxt/3/shortlist description
db_subst $tpl_shortlist TXT3 $RET
# Set default value
@@ -654,6 +678,11 @@
fi
fi
+ db_metaget $tpl_countrytxt/1/continent description
+ db_subst $tpl_continentlist TXT1 $RET
+ db_subst $tpl_continentlist TXT2 $ctxt2
+ db_metaget $tpl_countrytxt/3/continent description
+ db_subst $tpl_continentlist TXT3 $RET
db_input $continent_prio $tpl_continentlist || [ $? -eq 30 ]
;;
@@ -662,13 +691,15 @@
Bug#562594: Use modalias to detect modules when driver does not register
On Tuesday 29 December 2009, Jurij Smakov wrote: I see that modprobe has --resolve-alias flag which prints out the module(s) matching an alias, which renders the whole sed concoction unnecessary. I think we should keep Jérémy's solution. If --resolve-alias can return multiple modules that support the device, then we have no reliable way of knowing which one has actually been loaded and for which we're missing the firmware. AFAICT Jérémy's code should result in the exact module that was loaded [1]. Looks reasonable, thanks. Unfortunately, I'm on vacation for the next two weeks without access to my sparc, so I'll not be able to test it until the third week of January. OK. I'll upload the new version. Please test a daily build when you have a chance. [1] Except maybe if a user did a manual modprobe. I expect Jérémy's code will work correctly in combination with blacklisting. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: d-i from lenny not choosing local udebs
On Tuesday 29 December 2009, Lucas Brasilino wrote: My sources.list.udeb.local is: deb http://localhost/debian-mirror lenny main/debian-installer That's the problem. Because you have a .local file the normal sources.list.udeb is ignored. Either delete the .local file or add a correct line for localudebs to it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: d-i from lenny not choosing local udebs
On Tuesday 29 December 2009, Lucas Brasilino wrote: But, I'm just curious: Since sources.list.udeb is generated from sources.list.udeb.local No. It's not generated that way. s.l.u is generated from the host system's /etc/apt/sources.list. s.l.u.local is an override if you do *not* want to use s.l.u. Please see the documentation in the build directory. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: My keyboard isn't recognize by the last daily-build on amd64
On Monday 28 December 2009, Jeremy Guitton wrote: I've tried the last daily-build on amd64 system and my keyboard, a MX3200 by Logitech, isn't recognize by the debian-installer. My keyboard needs module hid-logitech. This module isn't build in the kernel but like a module, I think that is the mistake. What do you think about that? This is caused by a change in recent kernels where vendor-specific support required for some keyboards was split out of the general hid module. We had not yet added these modules for the installer. These additional modules are now scheduled to be included when we switch to the 2.6.32 kernel for the installer, but that will take some time. Unfortunately this means that until then keyboards that are not standards- compliant will not be supported in the installer. Thanks for reporting the problem. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562594: Use modalias to detect modules when driver does not register
On Monday 28 December 2009, Jérémy Bobbio wrote: This problem looks similar to the one I had while trying to use a daily build image on a PowerEdge R410. The network interfaces on these machines are supported by the bnx2 module, but when no firmware is available, the driver does not register itself for the device, and there is no `$devpath/driver` directory available. The attached patch adds to `check-missing-firmware` another way to determine the module by using `modprobe` and `$devpath/modalias`. Thanks Jérémy. Looks good. I think the patch needs an added test that modalias exists, something like: elif [ -e $devpath/modalias ]; then And that long line could do with a split to the next line after the pipe. The || true is probably not needed as the sed statement will absorb any errors from modprobe, but maybe there should be a redirect of errors: module=$(modprobe --show-depends $modalias 2/dev/null | \ sed -n -e '$s#^.*/\([^.]*\)\.ko.*$#\1#p') A comment that the module supporting the device is the last line returned by modprobe would be useful. It's not quite self-evident. Once this changes applied, it sucessfully prompted for the relevant firmware files. Jurij: does this patch also work for you? Patch available at: http://bugs.debian.org/562594#39 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562786: Bug-Report
On Sunday 27 December 2009, delphi...@gmx.de wrote: Comments/Problems: I startet the installer. Before the menu showed up there were two messages on the screen. I tried to read them but it was too fast, I only know that they ended with may be corrupt. You should be able to see them by switching to the debug shell on VT2 (using alt-f2) and examining the syslog (use 'nano /var/log/syslog'). The installer did not find the CD-drive (SATA) so it was not possible to install anything, I also was not able to get access to the internet. If you need additional help, please do the following: - from the main menu of the installer, run the option save debug logs - send us the files /var/log/syslog and /var/log/hardware-summary You should be able to for example copy those files to a USB stick. I burned the image with many programs (every program verified, the CD would be okay) but I got in the same trouble as mentioned before with every CD. Did you also try the option Check the CD-ROM(s) integrity that's in the main menu of the installer? That will really tell you if the CD is OK. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562594: More information
On Saturday 26 December 2009, Jurij Smakov wrote: The problem here is that empty $modules does not mean that there are no files in $MISSING which is set to /dev/.udev/firmware-missing (the log message is wrong as well). Nice analysis Jurij. A lot (most?) devices do have a driver directory under /sys/devices. Try 'ls -l /sys/devices/*/*/driver'. Or does the directory maybe only appear _after_ the firmware gets loaded? That would explain your earlier comment that you did get prompted after you loaded the firmware manually and ran disk-detect again. The fact that it is missing in your case may be a kernel bug. Maybe something specific to the 'root' class? Can you find an alternative method to determine the driver corresponding to your device? Either from sysfs directly or maybe using udevadm based on info that is in sysfs. If you need help, you could try contacting Marco d'Itri. Not sure whether this problem is caused by changes to check-missing-firmware or kernel, I can try to boot a lenny installer tomorrow to see how it worked there. check-missing-firmware was changed because of changes in udev. FYI, the link in /dev/.udev/firmware-missing is created by udev's /lib/udev/firmware.agent script. That is the correct starting point. I am blessed with having no hardware that needs firmware [1], so I cannot test this myself. Cheers, FJP [1] Though I expect that will change with .32 which has split out e100 firmware. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562594: More information
On Saturday 26 December 2009, Jurij Smakov wrote: The logic in check_missing() function appends the missing firmware file name to the $files list and the module to $modules list. However, if such mapping fails (as in this case), nothing is appended to $files or $modules, and the file is simply ignored as a result: Hmm, but it should at least be logging the failure to determine the module: if [ -z $module ]; then log failed to determine module from $devpath continue fi As it's probably not supposed to fail there, I think it's reasonable that this gets ignored later on. If there really is no way to handle this case (which I doubt), then that would have to be revised. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562594: More information
On Saturday 26 December 2009, Jurij Smakov wrote: It turns out that the installer does offer an option to load firmware from external drive, but only *after* I have loaded the firmware by hand and re-ran 'Detect disks' option from installer menu. There are calls to a script 'check missing firmware.sh' during all three stages of hardware detection. Please do an install in expert mode, before any hardware detection is performed, add a 'set -x' in: - /bin/hw-detect - /bin/disk-detect - /bin/check-missing-firmware Then, either check yourself where it's failing and/or send the resulting syslog (gzipped!). Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
