Clean method to include udebs from proposed-updates
I've committed a change that should make stable updates (and also uploads to testing) easier. From the SVN commit: snip For builds targeted at testing or stable, set USE_PROPOSED_UPDATES in debian/rules to include udebs from the corresponding proposed-updates suite. For details see build/README. This replaces the hack to include a sources.list.udeb.local in uploads for stable. Advantage of the new method is that the setting in the rules file can be safely committed to SVN without affecting manual builds from an SVN checkout. It also means the buildds will now use locally defined mirrors instead of the mirror hardcoded in sources.list.udeb.local. /snip I've backported the change to the lenny branch (and activated it there), but not for etch. I think it should apply without (m)any problems for etch as well. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552787: #552787 [i386][squeeze][20091026-21:55] unable to install lenny from daily
On Friday 06 November 2009, vincent.mcint...@csiro.au wrote: I want to install lenny with the 'squeeze' installer. Are you saying all I need to preseed is suite=lenny on the boot line? Yep. BUT I doubt anyone has tested that the squeeze installer really still is compatible with lenny. The risk is probably fairly small, but we did not have sarge-support and etch-support compatibility udebs for nothing for the etch resp. lenny installers. So, please check carefully for issues and report any that you find. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] localechooser: template changes
On Monday 02 November 2009, Frans Pop wrote:
The existing templates for the four main questions in localechooser all
have problems: they cause Lintian warnings and don't really help the
user with what he's doing.
Below a proposed patch to improve them. The patch also includes the
changes needed because of #552560 (locale selection incomplete).
Here's a new overview of the proposed changes.
One problem with the discussion so far has been that it's very hard to
reach consensus if only two people participate, so please have a look
and comment! These are some of our most essential dialogs.
Cheers,
FJP
Language selection
==
OLD
Please choose the language used for the installation process. This
language will be the default language for the final system.
Choose a language:
--
NEW
Choose the language to be used for the installation process. The selected
language will also be the default language for the installed system.
Language:
Country selection
=
OLD (shortlists)
Based on your language, you are probably located in one of these
countries or regions.
Choose a country, territory or area:
OLD (continent dialog)
The continent or region in which the desired country is located.
Choose a continent or region:
OLD (per-continent lists)
Choose a country, territory or area:
--
NEW (same for shortlists and per-continent lists)
The country selected here will be used for example to select a default
locale and time zone. Normally this should be the country where you live.
Choose other if your country is not listed. *)
Country, territory or area:
NEW (continent dialog)
Select the continent or region in which your country is located.
Continent or region:
*) Should we for shortlists maybe change this line to:
This is a shortlist based on the language you selected. Choose other
if your country is not listed.
Locale selection
Note: the order of the questions has changed because of #552560.
OLD (default locale)
Based on your language and country choices, the following locale
parameters are supported.
Choose a locale:
OLD (extra locales)
You may choose additional locales to be installed from this list.
Choose other locales to be supported:
--
NEW (extra locales; has help)
Based on the selected language and country, the default locale selected
for the installed system is '${LOCALE}'.
If you wish to use a different default or to also have other locales
available, you may choose additional locales to be installed. If you are
unsure it is best to just use the selected default.
Additional locales:
NEW (default locale; has help) *)
Select the default locale for the installed system.
System locale:
NEW (locale help dialog)
locale
A locale determines character encoding and contains information on for
example currency, date format and alphabetical sort order.
*) Only displayed if additional locales were selected.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: question re netcfg/dhcp_timeout
On Friday 06 November 2009, Vincent McIntyre wrote: I noticed a small discrepancy in the type for this question. packages/netcfg/debian/netcfg-dhcp.template says: Template: netcfg/dhcp_timeout Type: text Description: for internal use; can be preseeded Timeout for trying DHCP Default: 15 but the documentation[1] says: # If you have a slow dhcp server and the installer times out waiting for # it, this might be useful. #d-i netcfg/dhcp_timeout string 60 Is the difference between text and string significant to 'd-i'? I notice localechooser uses 'Type: string' in some places and 'text' in others. The template should be type string, but apparently cdebconf does not go crazy over it being incorrect. I've corrected it in SVN. Thanks. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518808: [PATCH] d-i manual: document booting from DOS
Hi Samuel and Holger,
Sorry for not looking at this BR earlier, but somehow I don't think booting
from DOS is the highest priority we have.
I've looked at the patch from Holger (as that's the most extensive of the
two), but have some problems with it. My comments below.
Cheers,
FJP
On Saturday 19 September 2009, Holger Wansing wrote:
I have tested booting testing/squeeze from MS-DOS and here are some
improvements/updates to the d-i manual documentation on this.
Please consider to use the patch attached here.
--- en/boot-installer/x86.xml 2009-09-18 22:29:22.0 +0200
+++ en/boot-installer/x86_workingcopy.xml 2009-09-18 22:19:39.0
+0200
[...]
Boot into DOS (not Windows) without any drivers being loaded. To do
this, you have to press keycapF8/keycap at exactly the right
moment (and optionally select the quotesafe mode command prompt only/quote
FJP:
AFAIK current versions of Windows (including XP!) don't have a safe
mode command prompt only option. This is ancient history. If you want
to revive this, we need to provide updated info in how to run DOS in the
first place.
-option). Enter the subdirectory for the flavor you chose, e.g.,
+option). Enter the subdirectory install.386:
FJP:
install.386 is only valid for i386, but for amd64 it should be
install.amd. As the section is for arch=x86, we should cover both
correctly. The best way to do this is probably to define an entity in
build/entities/common.ent, something like:
!ENTITY x86-install-dir
install.phrase arch=i386386/phrasephrase arch=amd64amd/phrase
And then use that whereever the patch now has 'install.386'.
--- en/install-methods/boot-drive-files.xml 2009-09-18 22:29:22.0
+0200
+++ en/install-methods/boot-drive-files_workingcopy.xml 2009-09-18
22:23:24.0 +0200
[...]
+Copy the following directories from a d-i; installation CD or DVD to your
+hard drive, let's say to filenamec:\/filename:
FJP:
This is too vague. The directories *must* be copied to c:\, or at
least to the root dir of a hard drive because otherwise the batchfile
will not work.
But wouldn't it be much simpler to completely forget about copying files
and just say:
- mount the CD drive
- change to the CD drive
- cd to \install.{386,amd}
- run install.bat
?
Then you can forget about this whole section (and thus remove the link to
boot-installer-intro-hd.xml; and maybe replace that with a more suitable
intro).
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532437: debian-installer: documentation 4.3.2.2: s/vmlinuz/linux/?
tag 532437 pending thanks On Tuesday 09 June 2009, Timo Juhani Lindfors wrote: http://debian.org/releases/stable/i386/ch04s03.html.en says under 4.3.2.2. Adding the installer image that the name of the kernel file is vmlinuz. However, http://ftp.nl.debian.org/debian/dists/lenny/main/installer-i386/current/ images/netboot/debian-installer/i386/ only has files named initrd.gz, linux and pxelinux.0. Problem here is that the section was originally written for using the hd-media images, and not the netboot images. And in the hd-media images the kernel *is* named vmlinuz: http://ftp.nl.debian.org/debian/dists/lenny/main/installer-i386/current/images/hd-media/ I've added a paragraph to explain this. Thanks, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532440: documentation: 4.3.3.: mention that bootable flag should be set?
tag 532440 pending thanks On Tuesday 09 June 2009, Timo Juhani Lindfors wrote: but when I tried to boot from the usb stick I got the error message no bootable partition found. I ran cfdisk and noticed that indeed bootable flag indeed is not set. Shouldn't the manual mention that? I've added a short footnote. Thanks, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548534: installation-guide: “Copying the files — the easy way” should explicitly exclude netboot
tag 548534 pending thanks On Saturday 26 September 2009, Samuel Thibault wrote: A colleague wanted to install Debian by starting the debian installer from a USB stick. Reading sections install-methods/boot-usb-files.xml and install-methods/downloading-files.xml, he went for the second method, he downloaded the hd-media boot.img.gz from debian/dists/lenny/main/installer-amd64/current/images/ but then as an ISO image, he took the only one there, mini.iso, and thus the debian installer told him it couldn't find a valid installation image. Maybe the text should explicitly exclude netboot from the images that can be used (see attached patch), and refer to section install-methods/official-cdrom.xml for downloading netinst/businesscard. I've added a footnote that does both. Thanks, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#331523: Link goes to non-related site
On Saturday 17 October 2009, Alex Brotman wrote: http://www.debian.org/releases/stable/amd64/ch01s02.html.en contains a link to Kernel Traffic which actually goes to a website having nothing to do with kernels. The installation guides for other architectures have the same 'broken' link. Dropped for the Squeeze version. Thanks, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553306: clarify use of mirror/udeb/suite
On Friday 30 October 2009, Vincent McIntyre wrote: In relation to #552787, I've attempted to improve the relevant text in the preseeding appendix of the manual. It's a bit wordier (sorry translators). The parameter classnamemirror/udeb/suite/classname determines the suite +for additional components for the emphasisinstaller/emphasis. +By default the value for classnamemirror/udeb/suite/classname is the +same as classnamemirror/suite/classname. +classnamemirror/udeb/suite/classname may be set to a different value, +but it is only useful to do this if installer components are going to be +downloaded over the network. The value should match the suite that was used to build the initrd for the installation method used for the installation. Problem is that this is not correct. For daily built images for example, mirror/udeb/suite gets set to sid, while mirror/suite is squeeze. And for the etch-and-a-half images mirror/udeb/suite is lenny, while mirror/suite is etch. And the fun part is that using a lenny mini.iso and booting that with suite=etch just works. So something is rotten in what you saw in #552787. I don't think I want to change the manual if the bug is 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
Bug#552787: #552787 [i386][squeeze][20091026-21:55] unable to install lenny from daily
On Friday 06 November 2009, Frans Pop wrote: Found the problem, which is documented but it's somewhat difficult to parse. This change in my preseed file fixed the issue: - d-i mirror/udeb/suite string lenny + d-i mirror/udeb/suite string testing This is not a bug. If you had not set this at all, then the installer would just have done the correct thing. By setting it to a value (and thus overriding the correct default set at build time) that does not match which suite the installer was built from, you broke things yourself. Actually, I suspect that you had an old daily image (which is based on *unstable*) that still used the 2.6.31-1 kernel while the udebs for that kernel no longer existed in unstable because they had been updated to 2.6.31-2. So, two options: - either you really did have an incorrect preseed file - or you had an outdated image That setting mirror/udeb/suite to testing worked, was merely a coincidence and not a correct fix (because the only technically correct setting for a daily built image would have been sid or unstable). Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511679: installation-guide-i386: Provide information on how to restore USB stick to its previous state
First of all, sorry for the late reply. On Tuesday 13 January 2009, M.-A. DARCHE wrote: The problem now is that I cannot recover/restore my USB stick to its previous state. Before me installing the Debian installer on it, the USB capacity (size) was 2Gb and now when I open the USB device with either fdisk or cfdisk it only shows a 1Gb capacity. That's why I think that the Debian GNU/Linux Installation Guide should feature a small section on Howto restore the USB stick to its previous state. So that people like me are not left with a crippled USB mass storage afterward. I would be happy to add something, but I really have no idea what. Did you ever find a procedure that restored the stick to its full capacity? Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552787: #552787 [i386][squeeze][20091026-21:55] unable to install lenny from daily
On Friday 06 November 2009, Frans Pop wrote: Actually, I suspect that you had an old daily image (which is based on *unstable*) that still used the 2.6.31-1 kernel while the udebs for that kernel no longer existed in unstable because they had been updated to 2.6.31-2. Eh, we don't have udebs for .31 yet, but the same thing for .30. Anyway, the problem was AFAICT completely unrelated to booting with suite=lenny. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] localechooser: template changes
On Wednesday 04 November 2009, Christian Perrier wrote: Well, OK, I'm not entirely convinced but I apparently can't propose a sufficiently correct alternative to makje you change your mind..:-) Here's an alternative I could live with: The country selected here will be used for example to select a default locale and time zone. Normally this should be the country where you live. Country, territory or area: This still covers my arguments for using country where you live, but leaves more open that there can be reasons to choose a different country. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554493: booting the stable installer via pxe leeds to a black screen
On Wednesday 04 November 2009, Maelvon HAWK wrote: Wanted to install a stable Debian version on a Vaio (PCG-GRT816S) with XPE and a netboot, I've been faced to a similar bug as #497212! The screen turn black! When exactly does it turn black? After you boot the installer from the syslinux menu, or does the syslinux menu not show? I'll assume the last. The problem could be version difference between different syslinux files. See the last comment in #497212: quote I ran into this one a while ago and forgot to post the solution, which is that you have to make sure that you are netbooting a 'pxelinux.0' which at least as new as the version of 'vesamenu.c32'. It seems that the changes to pxelinux.0 in syslinux are back-compatible with earlier copies of vesamenu.c32, but not the other way round. Simply upgrade to pxelinux.0 from the Lenny images as well and the problem is fixed :-) /quote 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] localechooser: template changes
On Tuesday 03 November 2009, Christian Perrier wrote: Quoting Frans Pop (elen...@planet.nl): I'd just recommend Please select which is the style we generally push in dle reviews (avoid imperative form). Using the imperative form is wrong in the *short* description (which was the problem in the old version), but IMO in a lot of cases it's fine for the *extended* description. I did not add the pleases on purpose, basically because they've started to annoy me. For the extended description we should distinguish between text that is a *request* and text that provides *instruction*. In the first case adding please is fine (even needed), in the second case it's IMO redundant. Matter of taste (and overall consistency). IMO it's not just a matter of taste and I'll have one more attempt to explain my reasoning to you. Especially because I do fully agree about consistency and because this also affects po-debconf templates. I've been uncomfortable with please for quite some time, but could never really say why, so I did not make a point of it. For the Dutch translation we mostly just drop them. Any attempt to preserve it makes the translation sound artificial. The problem is that when you read individual templates adding please seems completely logical. And that is how you have been working with them intensively over the past few years. But templates do not stand on their own, especially not in the installer. IMO the installer can be seen as a set of instructions to reach a certain goal, much like a cookery-book or an assembly instruction for an Ikea table. Cookery-books don't go Please melt the butter over a moderate flame. When the butter is melted, please add the flour and a table spoon of sugar. Please stir until you get smooth paste.. And that's exactly the effect you get if you add please in every D-I dialog. You have to consider the whole, not just the individual templates. As I've mentioned in my previous post, please is fine for requests (which we also have in D-I and po-debconf templates), but it's not needed in what's essentially a series of instructions. I'll use the polite form in the French translation... Of course you should do what's correct in French for your translation; different languages have different requirements. But it may be worth checking a few French cookery-books ;-) Also, it's *not* about using the polite form (at least not for English), but at using the most appropriate form for the nature of the product. Feel free to take this discussion to d-english. What about: (please) Select the country that will be used, for example, to select a default locale and time zone. IMO that's a lot less clear for users. An instruction does not have to be literally correct in 100% of cases. It has to convey the correct intention. We could turn this to Choose other to choos a country that is not listed here. Something like that would be possible but depends on what we do with the country questions. Apart from that, everything is fine, except maybe the length of the two paragrpahs, that takes a lot of spaces and leaves few romm for the list on 80x25 systems. It still leaves 10 lines for selection with vga=normal, so it's not that bad. But I've now moved the first sentence to a separate help template; this saves 2 lines, so now 12 lines are displayed. Yes. We should by the way make better use of these help templates, indeed. Agreed. Could be useful for our country selection detailed instructions. Maybe, but we should guard against: - moving essential or basic instructions into help dialogs; - being too verbose in help dialogs for udebs included in initrds (because of size considerations); localechooser already is relatively big because of all the error dialogs. In the case of country selection it is IMO essential to make users installing their own system (people not doing multiple installations, but using the installer only once) pick the correct choice on the first attempt in order to avoid incorrect locales (especially at default priority) or time zones (especially as that is not even displayed at default priority for countries that only have one). The country where you live is IMO by far the simplest, clearest and most intuitive description to achieve that. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534413: hw-detect: should not rely on testing for /proc/bus/usb
tag 534413 pending thanks On Wednesday 24 June 2009, Frans Pop wrote: In hw-detect.sh there are two locations where the script checks if /sys/bus/usb exists, but usbfs will no longer be available in kernel 2.6.31, so another method will need to be found. Actually, we use /proc/bus/usb in one location and /sys/bus/usb in another, so just use the latter for both. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553678: locales: Language soup in Nowegian locale
On Monday 02 November 2009, Frode Severin Hatlevik wrote: 2009/11/2 Clint Adams sch...@debian.org: On Sun, Nov 01, 2009 at 10:05:52PM +0100, Frode Severin Hatlevik wrote: The problem: When I install Debian and choose Norwegian locale I get a language soup of Norwegian, Sweedish, Danish and English in most programs. This issue pertains to messages in console programs as well as in several programs for X11. The soup is present in both versions of Norvegian (Bokmaal and Nynorsk). I think your problem is with localechooser in the installer, and I think it is related to this: nb_NO;Norwegian Bokmaal;Norsk bokmål;1;NO;nb_NO.UTF-8;nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en;console-se tup Seems likely that you are correct. The real problem is incomplete translations. The only thing the installer does is to set LANG in such a way that there are logical fallbacks for strings that are not translated into your preferred language. The fallbacks have been requested by the translators for Norwegian. If you wish less language soup, then the best way to help avoid it is to join the translation effort. If you think the fallbacks should be simplified, you should discuss that with the translation team for Norwegian. Should I file a separate bug against the Debian installer, then? No. The BR is already reassigned to localechooser, which is part of 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: [RFC] localechooser: template changes
On Monday 02 November 2009, Christian Perrier wrote:
--- a/packages/localechooser/debian/localechooser.templates-in
+++ b/packages/localechooser/debian/localechooser.templates-in
@@ -11,9 +11,8 @@ Template: debian-installer/locale
Type: select
Choices: ${LOCALELIST}
# :sl2:
-_Description: Choose a locale:
- Based on your language and country choices, the following locale
- parameters are supported.
+_Description: System locale:
+ Select the default locale for the installed system.
I'd just recommend Please select which is the style we generally
push in dle reviews (avoid imperative form).
Using the imperative form is wrong in the *short* description (which was
the problem in the old version), but IMO in a lot of cases it's fine for
the *extended* description. I did not add the pleases on purpose,
basically because they've started to annoy me.
For the extended description we should distinguish between text that is a
*request* and text that provides *instruction*. In the first case
adding please is fine (even needed), in the second case it's IMO
redundant.
Example of a a request is Please check that your CD is inserted
correctly. Without please there is a clear difference in the tone (it
becomes a command instead of a request).
Making it a request instead of a command is partly needed because it's far
from certain that the problem is in how the CD is inserted.
This template is an example of providing instruction, so we can do without.
Template: localechooser/translation/none-yet
Type: note
@@ -141,16 +140,25 @@ Type: select
# :sl1:
__Choices: ${SHORTLIST}, other
# :sl1:
-_Description: Choose a country, territory or area:
- Based on your language, you are probably located in one of these
countries - or regions.
+_Description: Country, territory or area:
+ Select the country where you live. The selection will be used for
example to + select a default locale and time zone.
+ .
+ Choose other if your country is not listed.
That one is more tricky. Using where you live implicitely assumes
that the user installing the system is the one owning the machine,
which is not well suited in all cases. Also, the user might be living
somewhere but installing the machine elsewhere. Of course, what
matters here is probably more the place where the machine is
living..:-)
The former template had the same problem of course.
Please select the country where the installed system is used.
This is a lot less clear.
My proposed text is fine for the general case where users install their own
systems. People installing systems for others will know how to translate
the request for their situation (and even then the selection will be the
country where they live in 95% of cases).
Saying the country where you live is IMO the simplest way to avoid the
reports from users that they did not get the correct time zone.
It is also more logical for the situation where a user installs a portable
system while on holiday. And remember that portable systems can and will
be used all over the world.
The selection will set the default locale and time zone.
The selected country does more than that, so the for example is IMO
necessary.
Choose other to get the full list of countries.
Problem is that you don't get a full list of countries, you get a list of
continents...
Template: localechooser/supported-locales
Type: multiselect
Choices: ${LOCALELIST}
# :sl2:
-_Description: Choose other locales to be supported:
- You may choose additional locales to be installed from this list.
+_Description: Additional locales:
+ A locale determines character encoding and contains information on
e.g. + currency, date format and alphabetical sort order. Based on the
selected + language and country, the default locale selected for the
installed system + is '${LOCALE}'.
+ .
+ If you wish to use a different default or to also have other locales
available, + you may choose additional locales to be installed. If you
are unsure it is + best to simply stick with the default.
After discussions in dle, we concluded (mostly others than me as I'm
of course polluted by Latin) that latin abbreviations such as e.g.
are not highly wished in English. such as would then be recommended.
Fixed.
Apart from that, everything is fine, except maybe the length of the
two paragrpahs, that takes a lot of spaces and leaves few romm for the
list on 80x25 systems.
It still leaves 10 lines for selection with vga=normal, so it's not that
bad. But I've now moved the first sentence to a separate help template;
this saves 2 lines, so now 12 lines are displayed.
@@ -111,8 +114,8 @@ print TOUT Template:
localechooser/continentlist\n; print TOUT Type: select\n;
print TOUT #flag:partial\n;
print TOUT __Choices: , join(, , @regions), \n;
-print TOUT _Description: , gettext(Choose a continent or
region:), \n; -print TOUT , gettext(The continent or
Re: Installation Guide: please commit pending changes
On Tuesday 27 October 2009, Frans Pop wrote: I'm currently preparing the patches to drop the arches alpha and m68k from the Installation Guide. The plan is to update both the English version and all translations. The changes are not huge, but they affect a fairly large number of files. These changes have now been committed. Translations (both XML-based and PO-based) have been updated and unfuzzied whereever possible. Changes for the removal of m68k and alpha have been committed separately. The range of relevant revisions is: r61133 to r61161. I have done a fair amount of review and testing for this, but feel free to verify the correctness of commits for your translation. Please wait with committing any changes until after the next successful automated build. Cheers, FJP signature.asc Description: This is a digitally signed message part.
[RFC] localechooser: template changes
The existing templates for the four main questions in localechooser all
have problems: they cause Lintian warnings and don't really help the
user with what he's doing.
Below a proposed patch to improve them. The patch also includes the changes
needed because of #552560 (locale selection incomplete).
Test images (i386) this time that use the new templates and include the
change for #552560 (use expert mode!) are available at:
http://people.debian.org/~fjp/tmp/d-i/madduck/
Cheers,
FJP
commit 330cff17ef17481bc98d8b80656f12984017e10a
Author: Frans Pop f...@debian.org
Date: Sun Nov 1 17:19:40 2009 +0100
Update templates
diff --git a/packages/localechooser/debian/localechooser.templates-in
b/packages/localechooser/debian/localechooser.templates-in
index c8203fb..75a8353 100644
--- a/packages/localechooser/debian/localechooser.templates-in
+++ b/packages/localechooser/debian/localechooser.templates-in
@@ -11,9 +11,8 @@ Template: debian-installer/locale
Type: select
Choices: ${LOCALELIST}
# :sl2:
-_Description: Choose a locale:
- Based on your language and country choices, the following locale
- parameters are supported.
+_Description: System locale:
+ Select the default locale for the installed system.
Template: debian-installer/fallbacklocale
Type: select
@@ -49,9 +48,9 @@ Choices-C: ${CODES}
Choices: ${NAMES_EN}
Choices-en.UTF-8: ${NAMES_BOTH}
Default: en
-Description: Choose a language:
- Please choose the language used for the installation process. This
- language will be the default language for the final system.
+Description: Language:
+ Choose the language to be used for the installation process. The selected
+ language will also be the default language for the installed system.
Template: localechooser/translation/none-yet
Type: note
@@ -141,16 +140,25 @@ Type: select
# :sl1:
__Choices: ${SHORTLIST}, other
# :sl1:
-_Description: Choose a country, territory or area:
- Based on your language, you are probably located in one of these countries
- or regions.
+_Description: Country, territory or area:
+ Select the country where you live. The selection will be used for example to
+ select a default locale and time zone.
+ .
+ Choose other if your country is not listed.
Template: localechooser/supported-locales
Type: multiselect
Choices: ${LOCALELIST}
# :sl2:
-_Description: Choose other locales to be supported:
- You may choose additional locales to be installed from this list.
+_Description: Additional locales:
+ A locale determines character encoding and contains information on e.g.
+ currency, date format and alphabetical sort order. Based on the selected
+ language and country, the default locale selected for the installed system
+ is '${LOCALE}'.
+ .
+ If you wish to use a different default or to also have other locales
available,
+ you may choose additional locales to be installed. If you are unsure it is
+ best to simply stick with the default.
# This template does not really belong in localechooser, but it is probably
# the best place for it. It is used to display the language currently being
diff --git a/packages/localechooser/mktemplates.continents
b/packages/localechooser/mktemplates.continents
index 4023f58..992b019 100755
--- a/packages/localechooser/mktemplates.continents
+++ b/packages/localechooser/mktemplates.continents
@@ -100,6 +100,9 @@ foreach my $region (@known_regions) {
print TOUT #flag:partial\n;
print TOUT __Choices: , join(, , @countries), \n;
print TOUT _Description: , gettext(Choose a country,
territory or area:), \n;
+ print TOUT , gettext(Select the country where you live. The
selection will be used for example to select a default locale and time zone.),
\n;
+ print TOUT .\n;
+ print TOUT , gettext(Choose \other\ if your country is
not listed.), \n;
print TOUT \n;
} else {
print STDERR I: skipping region $region: no associated
countries in $regionmap\n;
@@ -111,8 +114,8 @@ print TOUT Template: localechooser/continentlist\n;
print TOUT Type: select\n;
print TOUT #flag:partial\n;
print TOUT __Choices: , join(, , @regions), \n;
-print TOUT _Description: , gettext(Choose a continent or region:), \n;
-print TOUT , gettext(The continent or region in which the desired country
is located.), \n;
+print TOUT _Description: , gettext(Continent or region:), \n;
+print TOUT , gettext(Select the continent or region in which the country
where you live is located.), \n;
close(TOUT) || warn;
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FTBFS of netcfg on s390 after debhelper v7 conversion
On Wednesday 28 October 2009, Frans Pop wrote: I've just tried building netcfg on s390, but that fails with: dpkg-gencontrol: error: current host architecture 's390' does not appear in package's architecture list (i386 sparc alpha m68k arm armel armeb powerpc mips mipsel hppa ia64 amd64 lpia kfreebsd-i386 kfreebsd-amd64) dh_gencontrol: dpkg-gencontrol returned exit code 255 AFAICT the reason is that the binary netcfg is !s390 (while netcfg-static is arch any). Before the conversion to debhelper v7, we called most dh_command with the '-s' option. If I add an overrides in d/rules for dh_gencontrol *and* dh_builddeb to pass the -s option, netcfg builds correctly again. As there have not yet been any replies, I've committed this solution. I'm still unsure if it's the best solution. I wonder why this is needed? Shouldn't this just work? Is there a better solution than adding the overrides? Maybe 'dh -s $@', but I'd expect that will cause an error where we copy templates in override_dh_installdebconf... I also wonder if other converted packages could have the same issue. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#316006: localechooser: Should be enabled for s390
tag 316006 pending thanks This was indirectly implemented for Lenny (or maybe even earlier): tzsetup depends on localechooser, so users get asked to select a country before that point. However, I think it's time to just include localechooser in the s390 initrds so that the selected country can also be used as a default for choose-mirror. However, it would be best to run localechooser *after* network-console, so that users can select the country using the newt frontend (after connecting over ssh) instead of the text frontend. This means that for s390 the menu item number needs to be set to 2110 instead of 1000. I've prepared changes for both localechooser and d-i itself to implement this. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552584: file-in-usr-local /usr/local/etc
On Wednesday 28 October 2009, Manoj Srivastava wrote: The reason for adding a symlink /usr/local/etc/ - /etc/ can be found in this mail: http://lists.debian.org/debian-boot/2005/10/msg00111.html. I.e, it avoids noise that may confuse users. I don't see anything in that email tht details why /usr/loca/etc is needed. perhaps I am being dense and I missed it. Can you elaborate? In the mean time I've already removed the symlink as it's no longer needed. The reason it was originally added was that directfb would display an error on VT1 while the installer was booting that said it could not find its config file there. We were afraid that would confuse people and possibly result in a lot of BRs from users about it. Adding the symlink avoided the error. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552584: file-in-usr-local /usr/local/etc
No longer really relevant, but just for completeness. On Wednesday 28 October 2009, Manoj Srivastava wrote: I don't think so. A udeb can usually ignore bits about policy that talk about packaging details. However, when it comes to stuff on the disk that is going to outlast the installation, this is another matter altogether: Nothing in Debian should be in violation of the FHS, whether it is a regular package, or t is a part of the install. That's just it: the symlink exists *only* in the D-I environment and has no influence at all on the installed system. It only exists in RAM while the installation is running. It is not part of the install. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552278: reopen-console-linux: needs update for 2.6.32
On Sunday 25 October 2009, Frans Pop wrote: While testing 2.6.32-rc5 on my Sun Ultra 10 (sparc), I noticed the following change in the boot messages: Console: colour dummy device 80x25 -console handover: boot [earlyprom0] - real [tty0] +console [tty0] enabled, bootconsole disabled Just for reference, this is what I get on my hppa box. In early boot: -console [ttyB0] enabled +bootconsole [ttyB0] enabled Later, when serial drivers have been loaded: serial8250: ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A -console handover: boot [ttyB0] - real [ttyS0] +console [ttyS0] enabled, bootconsole disabled serial8250: ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552584: file-in-usr-local /usr/local/etc
On Wednesday 28 October 2009, Gaudenz Steinlin wrote: No part of a udeb ever ends up on the disk. Udebs only life in the installer intrds and in the ramdisk set up by the initrd. I don't think the FHS should apply to the ramdisk environment of the installer. Well, I think it's good to follow the FHS whenever possible, if only to keep the installer environment recognizable for developers and users. But if there are good reasons not to, then I agree violating it is not a major issue. We do try to follow the FHS, although we're not as strict as we could be in differentiating between (/usr)/(s)bin directories (as it makes zero effective difference for D-I), and also between /usr/lib, /usr/share and to a lesser extend /var. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: howto interact with HW-detection of installer
On Thursday 29 October 2009, Geronimo Ma. Hernandez wrote: There are several ways to get info about hardware: - files in /sys or /proc - utilities like lspci, lsusb, dmidecode (not all available in D-I) I see. So I have to do the detection on myself and add the tools I need for that to the installer? You should be able to get most of what you need using info that's already available. base-installer is in most cases not the best place to install extra packages. Doing that in pkgsel is preferred. Yes, I agree for extra packages. But I want to strip down the base-system (install a smaller image, use busybox with its targets, ...) Creating a smaller image is one of the most difficult things to do. It requires a very high level of understanding of how Debian works in general (things like package priorities), the installer and e.g. debootstrap. debootstrap can be tuned. To see how, read the bootstrap-base.postinst script and find the function install_base_system(). There you can see exactly how D-I calls debootstrap. Ok, let me explain what I want with a (quite senseless) sample: Problem with senseless examples is that they make no sense ;-) It's much easier to give concrete help when you give an actual example of what you want to do that _does_ make sense. Imagine, I would like to determine the type of desktop system based on the type of network-hardware found in the system This you should be able to get from lsmod, lspci or /sys. and the user-question, whether he likes to use dhcp. This can simply be tested in a script using a db_get of the relevant debconf template. So I need to check the hardware (i.e. lspci) and do a user-question. The result of both lead to a preseed-list and a path through the rest of the installation (pkgsel, ...) Well, you cannot really change the *path* through the installation (or rather, IMO you should not want to). What you can do is change defaults (by setting values for existing debconf questions) and adding functionality (by adding hook scripts that are executed by various components (see /usr/lib/*.d), or by adding custom udebs). But you probably need to start by spending some more time understanding the installer and reading existing scripts. Each installation step starts by executing a postinst script in /var/lib/dpkg/info. You can also learn a lot by adding a 'set -x' in such scripts before a step is executed and studying the debug output in the syslog, and then possibly adding additional 'set -x' in scripts called by those scripts. Did you already read the preseeding appendix in the installation guide? That has quite a lot of information on customization. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552560: locale selection incomplete
reopen 552560 thanks On Wednesday 28 October 2009, martin f krafft wrote: also sprach Frans Pop elen...@planet.nl [2009.10.27.2305 +0100]: You can choose en_GB if you install in expert mode (or with priority=medium). I don't think we want to set defaults for unofficial languages. The number of possible combinations would be insane, and its also more a matter of personal preference than any real rule. As what you want is already possible, I'm closing your report. No, I can *add* the en_GB locale later. I cannot chose it as system default, and I tried expert mode. Sorry, you are correct. Reopening. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552560: locale selection incomplete
On Thursday 29 October 2009, Frans Pop wrote: No, I can *add* the en_GB locale later. I cannot chose it as system default, and I tried expert mode. Sorry, you are correct. Reopening. A possible solution could be to invert the two expert questions: first ask which extra locales to install and then offer to select a default from the selected locales. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552560: locale selection incomplete
On Wednesday 28 October 2009, Christian Perrier wrote: - write an en_CH locale and convince glibc maintainers to include it in locales That is very much the least preferred solution, and, even if it were accepted in libc, I would be in favor of excluding it (at least from the shortlist for en) if it was available (just as we've done for en_DK). -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552560: locale selection incomplete
On Thursday 29 October 2009, Frans Pop wrote: That's actually quite simple to implement and even simplifies the code quite a bit. Martin, Christian: please give this image a try. http://people.debian.org/~fjp/tmp/d-i/madduck/ Eh, sorry. This is broken. Please ignore for now. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552560: locale selection incomplete
On Thursday 29 October 2009, Frans Pop wrote: On Thursday 29 October 2009, Frans Pop wrote: No, I can *add* the en_GB locale later. I cannot chose it as system default, and I tried expert mode. Sorry, you are correct. Reopening. A possible solution could be to invert the two expert questions: first ask which extra locales to install and then offer to select a default from the selected locales. That's actually quite simple to implement and even simplifies the code quite a bit. Martin, Christian: please give this image a try. http://people.debian.org/~fjp/tmp/d-i/madduck/ It's not completely polished, but it has the basic idea. Please test a full install as I've not yet done so. Note that the old default locale will still be used for the installation itself (i.e. en_US), but should set what you select for the installed system. Possibly we could change that, but then we would then need to limit the locales allowed as default to UTF-8 based locales. But maybe it's time to drop support for non-UTF-8 locales altogether? Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552560: locale selection incomplete
On Thursday 29 October 2009, Frans Pop wrote: On Thursday 29 October 2009, Frans Pop wrote: A possible solution could be to invert the two expert questions: first ask which extra locales to install and then offer to select a default from the selected locales. That's actually quite simple to implement and even simplifies the code quite a bit. Martin, Christian: please give this image a try. http://people.debian.org/~fjp/tmp/d-i/madduck/ New (and working) version uploaded. It's not completely polished, but it has the basic idea. Please test a full install as I've not yet done so. ToDo: change template texts in line with changes Note that the old default locale will still be used for the installation itself (i.e. en_US), but should set what you select for the installed system. Possibly we could change that, but then we would then need to limit the locales allowed as default to UTF-8 based locales. This is nonsense. The installer always uses C internally. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FTBFS of netcfg on s390 after debhelper v7 conversion
I've just tried building netcfg on s390, but that fails with: dpkg-gencontrol: error: current host architecture 's390' does not appear in package's architecture list (i386 sparc alpha m68k arm armel armeb powerpc mips mipsel hppa ia64 amd64 lpia kfreebsd-i386 kfreebsd-amd64) dh_gencontrol: dpkg-gencontrol returned exit code 255 AFAICT the reason is that the binary netcfg is !s390 (while netcfg-static is arch any). Before the conversion to debhelper v7, we called most dh_command with the '-s' option. If I add an overrides in d/rules for dh_gencontrol *and* dh_builddeb to pass the -s option, netcfg builds correctly again. I wonder why this is needed? Shouldn't this just work? Is there a better solution than adding the overrides? Maybe 'dh -s $@', but I'd expect that will cause an error where we copy templates in override_dh_installdebconf... I also wonder if other converted packages could have the same issue. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: howto interact with HW-detection of installer
The debian-boot list is more appropriate for this question. Please reply to that list and not to debian-cd. On Wednesday 28 October 2009, Geronimo Ma. Hernandez wrote: I read the wiki of DebianInstaller and DebianCustomCD, as well as debian installer internals, but I stil didn't get rid of how to interface with HW-detection part of the installer. I would like to have different package-lists installed, based on the detected hardware. So how can I determine the result of hw-detection? Does the installer use environment variables or the /proc filesystem, or ... ? With current kernels d-i does not actually do very much hardware detection. Most hardware is detected automatically by the kernel in combination with udev. udev decides which modules to load based on the modules.*map files in /lib/modules/kernel version/. There are several ways to get info about hardware: - files in /sys or /proc - utilities like lspci, lsusb, dmidecode (not all available in D-I) What to use depends on what you want... Or do I have to build my own udeb for the hw I like to detect? ... and if I do that, how can I switch the packagelist for the base installer? base-installer is in most cases not the best place to install extra packages. Doing that in pkgsel is preferred. There are quite a lot of methods you could use to make D-I install extra packages. What method is best depends. A lot can be done using preseeding (run a script in preseed-early and have that drop custom hook scripts in various places for example), but creating a custom udeb is also an option. If you need to ask questions from the user, a custom udeb is the only really good solution. There's a lot of information out there, but the installer is quite complex ... Yes, it is :-) Maybe we could help better if you gave more concrete examples of what you want. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[RFC] Changing localechooser to arch=any?
Damn, it looked like such a nice idea. Today I committed a change to set a different menu item number for localechooser for s390 so that it gets run after network-console instead of when we only have the text frontend available. This worked great, but only now do I realize that localechooser is an arch=all package. As the menu item number is set at build time, this obviously means all arches still get the same number. Any objections to making localechooser arch=any? I realize it's a bit out of line with the general character of the package, but changing the menu item number at run time is not possible (AFAIK). Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#552584: file-in-usr-local /usr/local/etc
On Tuesday 27 October 2009, Manoj Srivastava wrote: Justification: The package installs a file in /usr/local/... which is not allowed. As this is a udeb I think this can be ignored. The reason for adding a symlink /usr/local/etc/ - /etc/ can be found in this mail: http://lists.debian.org/debian-boot/2005/10/msg00111.html. I.e, it avoids noise that may confuse users. However, I will check if the symlink is still needed or not. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552700: installation-report: dfbinfo has changed location no longer available
Package: installation-report Version: 2.38 The utility dfbinfo used to be included in the libdirectfb udeb in /usr/lib/libdirectfb-*/bin/. In Lenny the utility has been split out into a separate package libdirectfb-bin and moved to /usr/bin, and as a result of that is no longer included in the udeb. Possibly we should request dfbinfo to be included in the libdirectfb udeb again. In that case its path needs to be updated in report-hw. If we don't, it should probably just be removed from report-hw. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552563: auto-create preseed.cfg file
On Tuesday 27 October 2009, martin f krafft wrote: Since debconf-get-selections is not the appropriate way to create preseed.cfg files, but d-i should know what keys to save (or not to save), why not extend d-i so that it automatically drops a preseed.cfg file into /root (next to the installation-report template), just in case the user is interested or would like to use that file? Nice idea, but it's not as simple as it may seem IMHO. Best procedure is still to take the example preseed file as starting point and modify that based using actual values from debconf-get-selections. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552576: live-installer: should have a Standards-Version field
On Tuesday 27 October 2009, Frans Pop wrote: The live-installer source package not only has a udeb, but also a deb. This means that it must also have a Standards-Version field in debian/control. Only source packages that have *only* udebs are allowed to omit that field. When this is fixed the current Lintian override should be removed as well. Severity was set to serious as this is a policy violation, and also because it means the package will likely get rejected by DAK on a next upload. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
Ian Campbell wrote: Is there a way to contact the build machine maintainers? Other than hoping they read this thread? The overview shows who they are. Ping on IRC, private mail, ... Note that the powerpc issue is not for the buildd admin (although it's possible that needs updating too). -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Installation Guide: please commit pending changes
Hi, I'm currently preparing the patches to drop the arches alpha and m68k from the Installation Guide. The plan is to update both the English version and all translations. The changes are not huge, but they affect a fairly large number of files. If you have pending changes, then please commit them ASAP to avoid conflicts after I commit my changes. If you do not have any pending changes, then I would suggest to postpone doing translation updates until after I have committed my changes. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Lintian based autorejects
On Tuesday 27 October 2009, Joerg Jaspert wrote: The second category is named error and the tags listed can not be Looks like it's named nowayout. overridden. Those are tags corresponding to packaging errors serious enough to mark a package unfit for the archive and should never happen. Please move no-standards-version-field to wayout. Because udebs don't follow loads of policy requirements (which is allowed because of their nature), and because that makes blindly updating the standards version with policy updates a rather meaningless job, the D-I team has removed the standards version fields from most source packages that produce only udebs; they include a lintian override for that. So having that tag in nowayout would mean that uploads of udebs will start failing massively. Thanks, FJP signature.asc Description: This is a digitally signed message part.
Re: Lintian based autorejects
On Tuesday 27 October 2009, Joerg Jaspert wrote: Now, in this case there is no need to move it, as looking at http://lintian.debian.org/tags/no-standards-version-field.html shows that we do not see any of the D-I packages, so I assume lintian is detecting it properly and we do not need to move it. Ah, it seems a test for this was indeed added in Lintian in the not too distant past. That also explains why [1] shows unused override for many of our packages for that tag. Note that both live-installer and userdevfs are listed on the page and *are* D-I packages. live-installer also has a deb, and thus _should_ have a standards version. I'll file a BR. userdevfs only has a udeb, so that looks like a bug somewhere. Ah, I see the reason. Current version in the archive uses XB-Package-Type instead of XC-Package-Type. But that has already been corrected in SVN, so should get resolved with the next upload. Thanks for the reply Joerg. Guess I'll also drop all the no longer needed overrides for our packages. Cheers, FJP [1] http://lintian.debian.org/full/debian-b...@lists.debian.org.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552576: live-installer: should have a Standards-Version field
Package: live-installer Version: 13 Severity: serious The live-installer source package not only has a udeb, but also a deb. This means that it must also have a Standards-Version field in debian/control. Only source packages that have *only* udebs are allowed to omit that field. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
Thanks for making an effort to look into this. On Monday 26 October 2009, Ian Campbell wrote: Thanks. I still cannot reproduce so I am somewhat clutching at straws. I compared the logs for a local (successful) i386 run of the daily-build script vs. the logs from http://people.debian.org/~joeyh/d-i/build-logs.html In the past I've always been able to reproduce mklibs errors. I've been concentrating on the netboot-gtk log and the differences are really rather small up until the failure point. The output from apt and/or dpkg differs a little -- I wonder if the build environment is not completely up to date and has a buggy (or just slightly differing in behaviour) version of one or the other? Seems unlikely to have effected so many build servers though (seemingly admin'd by several different people). FWIW I'm running apt 0.7.24 and dpkg 1.15.4.1. If you cannot reproduce it with an up-to-date sid build environment then it's quite possible that the buildds are simply outdated. apt and dpkg are not really relevant here. More relevant are versions of mklibs itself and packages like binutils. The symbol _nss_files_parse_sgent is provided by /lib/libc.so.6 and required by /lib/libnss_files.so.2. Both libraries are part of libc. Does libc.so.6 provide the exact symbol looked for (I'd expect it does)? In that case this looks like an mklibs/binutils issue. Comparing a manual make build_netboot-gtk with the daily-build logs (either my local ones or the build server ones), I see this which seems odd: [...] That is indeed strange and should be looked into, but I doubt it is related to the mklibs failure as neither libc6 nor libnss-files are extraudebs. Perhaps it would be useful if mklibs printed a bit more detail about where and why a symbol is thought to be required if an error occurs? It can do. The usual way to do that is this change in build/config/common to make it more verbose: -MKLIBS = mklibs +MKLIBS = mklibs -v -v But that is only really useful if you can reproduce it locally. The current version of http://people.debian.org/~joeyh/d-i/build-logs.html seems to suggest even bigger issues though, every arch failed to download summary log Probably just a temporary network problem somewhere. I'll see if I can do a test build myself today or tomorrow. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Monday 26 October 2009, Frans Pop wrote: If you cannot reproduce it with an up-to-date sid build environment then it's quite possible that the buildds are simply outdated. apt and dpkg are not really relevant here. More relevant are versions of mklibs itself and packages like binutils. There was an upload of binutils a bit more than a week ago. You could check if you can reproduce the failure after downgrading to binutils from testing. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Monday 26 October 2009, Ian Campbell wrote: I tried downgrading binutils, as you suggested in your next mail, to 2.19.91.20091006-1 from testing and still saw no issues. Hmmm. Another option is that it's due to a libc version skew. During a build libc6 is copied from the host system (because we need the corresponding -pic), while libnss-* is unpacked from udebs. So it could be that the buildds have a version of libc which really doesn't provide the symbol. /me tests this theory by firing up his armel box, which promptly reproduces the error After updating the system the problem disappears. So, that confirms the reason is outdated buildd environments after an API change in libc (2.9 - 2.10). The first 2.10 upload was 18 Okt, so the problem should be only about a week old. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Monday 26 October 2009, Frans Pop wrote: After updating the system the problem disappears. So, that confirms the reason is outdated buildd environments after an API change in libc (2.9 - 2.10). The first 2.10 upload was 18 Okt, so the problem should be only about a week old. s/API/ABI/ probably. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552497: hw-detect: file conflict with udev-udeb for /lib/udev/firmware.agent
Package: hw-detect Version: 1.73 Severity: serious During a D-I build on armel I noticed the following: Unpacking udev-udeb (from udebs/udev-udeb.udeb) ... dpkg: warning: overriding problem because --force enabled: trying to overwrite '/lib/udev/firmware.agent', which is also in package hw-detect 0:1.73 This should be resolved. I vaguely recall a discussion between Joey and Marco about this, but am not sure which package is now suppose to provide the file. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Sunday 25 October 2009, Ian Campbell wrote: I was unable to reproduce in an uptodate i386 sid chroot. I'm not sure which environment these builds occur, maybe it's a testing thing? No, daily images get build in a sid environment. powerpc is failing differently with E: Couldn't find package firewire-core-modules-2.6.30-1-powerpc-di or E: Couldn't find package floppy-modules-2.6.30-1-powerpc64-di depending on the flavour. Looks like someone forgot to update the kernel ABI. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
FYI: build overview graphs reset
I have just committed two changes to the daily-build-aggregator script [1]: 1) drop alpha and remove commented entry for m68k; 2) one-time rename old statistics file in order to reset them. Dropping alpha could possibly have been postponed for some time, but it made sense to do it now because of 2). 2) was very much needed because the generated graphs were rather useless as for most arches an incorrect history was being shown. The reason for this is that the build data is saved in a way that does not allow architectures to be added anywhere other than at the bottom, nor allows arches to be removed. And we have done both (removal of arm, addition of armel, addition of 2x kfreebsd) in the past. I already sent a mail about this a few months back [2] but without any response. With the changes since I sent that mail keeping it no longer made sense to keep any history, so therefore this action. I will revert the 2nd change when the rename of the statistics file has happened as the code is no longer needed after that. Cheers, FJP [1] perl script that generates http://people.debian.org/~joeyh/d-i/build-logs.html [2] http://lists.debian.org/debian-boot/2009/07/msg00577.html -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Sunday 25 October 2009, Ian Campbell wrote: I only checked the first failure for each arch but this same failure seems to have effected mips (build_r4k-ip22_cdrom), s390 (build_generic) and armel (uild_iop32x_netboot_glantank). For mips and mipsel there's a much bigger problem: there have not been any builds at all since early July. It looks as if some of the central D-I buildds are simply not being managed. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Sunday 25 October 2009, Luk Claes wrote: Frans Pop wrote: For mips and mipsel there's a much bigger problem: there have not been any builds at all since early July. It looks as if some of the central D-I buildds are simply not being managed. Wrong, ssh is/was broken on mips* so the results did not get uploaded, but the builds were not interrupted. Would have been nice to see something like that mentioned on this list. Avoids misunderstandings. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Sunday 25 October 2009, Frans Pop wrote: On Sunday 25 October 2009, Luk Claes wrote: Frans Pop wrote: For mips and mipsel there's a much bigger problem: there have not been any builds at all since early July. It looks as if some of the central D-I buildds are simply not being managed. Wrong, ssh is/was broken on mips* so the results did not get uploaded, but the builds were not interrupted. Would have been nice to see something like that mentioned on this list. Avoids misunderstandings. And documented on http://wiki.debian.org/DebianInstaller/Today for users (and team members). -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Sunday 25 October 2009, Luk Claes wrote: Wrong, ssh is/was broken on mips* so the results did not get uploaded, but the builds were not interrupted. I guess you're referring to #538313? That bug was fixed on Okt 5, but the current situation, 20 days later, is that we still don't have daily builds. From your use of the past tense I suspect you'll probably have updated the chroots now, after my message? Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible typo in Debian Installation Guide (C.1 section)
On Sunday 25 October 2009, Holger Wansing wrote: Frans Pop elen...@planet.nl wrote: Without additional information I see no reason to change the current text. In what circumstances would it be better to use a swap file over a swap partition and why? Maybe only change the text a bit, to add a short information, that in some situations it may be possible/sensefull to use swap file instead of swap partition? Detailled information, in which situations this may be the case, is not to be included in the d-i manual IMHO. That could be done by changing the second sentence to something like: It's possible to configure your system to use a swap file instead of a swap partition, but that is a rather unusual setup and not supported by the installer. I'd still like more information before I do that though. The linked mail only talks about performance issues, but there could be other reasons (like suspend) why it's not recommended. Not recommended in itself does not mean don't ever use it. It just means you'd better know what you're doing if you decide to use it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#551959: netboot: fails to set user and passwords on installation
On Saturday 24 October 2009, Christian Perrier wrote: CD team, this bug apparently confirms that weekly builds of Debian testing images are broken (maybe some of them only, I'm not sure). You guys probably know more than me about this, but isn't there something we could do to redirect our users to the D-I home page if they want to install testing? This was about a *netboot* image, which has *NOTHING* at all to do with CD images. It has been known for ages that the D-I testing images are broken. They got broken by all the ABI changes after the Lenny release that were (rightly) allowed to migrate to testing. They get more and more broken with every udeb migration to testing. The only way to fix them is by doing timely releases. And then ensuring that they stay working by tightly regulating what udebs migrate to testing. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552278: reopen-console-linux: needs update for 2.6.32
Package: rootskel Version: 1.81 Severity: important Currently reopen-console-linux has the following code: # If the kernel emitted a handover message, then it's the one console=$(dmesg -s 65535 | sed -n -e 's/.*\] console handover: boot \[.*\] - real \[\(.*\)\]$/\1/p') While testing 2.6.32-rc5 on my Sun Ultra 10 (sparc), I noticed the following change in the boot messages: Console: colour dummy device 80x25 -console handover: boot [earlyprom0] - real [tty0] +console [tty0] enabled, bootconsole disabled The reopen-console-linux script will need to be adapted to deal with that change. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
On Sunday 25 October 2009, Rick Thomas wrote: On Oct 24, 2009, at 10:03 PM, Frans Pop wrote: Links to current images are available from: http://www.debian.org/devel/debian-installer/ Cheers, FJP Hmmm... If I follow that link, then click on • netinst ... and businesscard ... CD images ... [powerpc] I get taken to a directory that claims This build finished at Thu Oct 1 23:28:01 UTC 2009. Is it possible that PowerPC CD builds have been down for over three weeks and nobody noticed? That's very likely the case. Looks to me that the general state of builds is rather pathetic ATM: http://people.debian.org/~joeyh/d-i/build-logs.html Hard to see how people expect to be able to do a D-I release (as mentioned in the logs from the last team meeting) given that fact (amongst others). -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible typo in Debian Installation Guide (C.1 section)
On Monday 19 October 2009, Maximiliano Curia wrote: El 19/10/2009 a las 13:57 escribiste: Hi, in lenny installation guide C.1 [1] we can read : By putting swap on a separate partition, Linux can make much more efficient use of it. It is possible to force Linux to use a regular file as swap, but it is not recommended. But it is like not true anymore [2] (in some circunstances at least). Maybe this text could be change in the future squeeze installation guide? You'll still need a swap partition for hibernation. Anyway, I think it's better not to overwhelm the user with information. I tend to agree. AFAIK the statement is still valid in general. At least, I've never seen anyone recommending to use swap files over swap partitions (although I'll immediately admit that I've never really looked for such information). Without additional information I see no reason to change the current text. In what circumstances would it be better to use a swap file over a swap partition and why? I also think the title of this mail is rather misleading: we're not talking about a typo here, but about a request for a significant change in content. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552067: Install process forgets the CD if left alone for long time
On Friday 23 October 2009, Alex Andryushkin wrote: If install goes quickly, then it appears to be OK. However, if there is large file system is being created (e.g. took 1/2 hour to create encrypted one), or I just leave install unattended for some time, then install process forgets that CD is in the drive. Error message can be cannot figure out how to install base system or That error is from the base-installer stage of the installation when debootstrap is called. please insert the disk labeled - asking for the very same disk that is IN THE CDdrive at the moment. That error is from a later stage of the installation (any stage after apt-setup). One more detail is that CDdrive is external, connected via USB. I cannot really see what could be going wrong here. The installer itself does nothing if it's left alone for a long time, so it must be something from to do with the kernel, or maybe how the USB device behaves if left unused for a longer period. The most likely explanation looks to me that the system (temporarily?) loses connection with the device and has some problem identifying it again when you resume the installation and the connection to the device is reactivated. The fact that the problem occurs at 2 totally different stages of the installation (or rather: 2 stages that use the device in rather different ways) supports the theory that this is not really a problem in the installer itself, but in the kernel. When I got those messages, I switched consoles and made sure that /cdrom/ is still readable and mounted properly. How exactly did you check that? It could be that you were merely seeing information that was buffered and that there was no actual access to the device. The only way to really test this is by trying to read the contents of a file that has not been accessed before. Do you happen to have the /var/log/syslog from a failed installation? If not, could you reproduce the problem and send the syslog (gzipped!)? I very much doubt I will be able to reproduce this myself, especially since I don't have a USB CD drive. That means that to solve this we will definitely need your help as you can reproduce it. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: di-netboot-assistant update for experimental
On Friday 16 October 2009, Frank Lin PIAT wrote: I have finally resolved and merged a bunch of patch I had for di-netboot-assistant. Please mark the changelog as UNRELEASED when you start on a new version to make it clear to others using the SVN repo that there are changes that have not been uploaded and that additional changes should be added to the current changelog entry instead of creating a new one. I've now done so for this version. If you add the following in ~/.devscripts and use dch, this will be done correctly automatically: DEBCHANGE_RELEASE_HEURISTIC=changelog (Frans, could you have a look at it and upload it to experimental please). I don't think experimental is the right choice here. I doubt you would get anybody to actually test it from experimental. If you are happy with it, I think you should just upload to unstable and deal with bug reports ASAP when they come in. I have tested the new version using a local build. IMO the ::/ prefix that looks to be required now should be documented, either in the pxelinux.HEAD file itself, or in a README.Debian file. I see you've already mentioned it in NEWS.Debian, but that's for upgrades, not to document something. There is also an upgrade problem. It looks like when I upgrade that the default configs do get changed, but not the actual existing configs in /var/lib/di-netboot-assistant/, nor the generated ones under the tftpboot directory. So after I changed my DHCP server config to drop option 210, nothing works anymore. Please provide clear instructions how to move from an old setup to a new one. I tried making the changes manually, but ended up with a broken setup. Not sure if that means the ::/ prefix does not work for me or if I missed something... Could you also fix the fact that the generated debian-installer/pxelinux.cfg/default file gets double newlines between items? Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: PowerPC daily install CDs? [Was: Re: Netinst for testing?]
Looks to me that the general state of builds is rather pathetic ATM: Sorry. I should have just written Looks like there are quite a few problems with builds ATM. Does not change the facts or the likelyhood of a successful upload/release any time soon though. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian-installer for GNU/kFreeBSD
On Thursday 15 October 2009, Aurelien Jarno wrote: I have just given a try, and during the installation, there is an error message about security.debian.org not having support for kfreebsd. The installation continues anyway, but it may confuse our users. Any opinion on that? Simple. Get the security team to add security support. It will be needed as you're going to be an official architecture anyway. The RMs should be able to help arrange it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530909: Wrong message about device being busy
On Thursday 15 October 2009, Martin Michlmayr wrote: [1] #345251, #377391, #382689, #470374 I'm surprised these bug reports are so old. Obviously this is not a new issue, but I'm pretty sure that it occurs much more often now than it did in the past. I cannot remember running into the warning too often with lenny, but it shows up really quite often with current daily images. Well, 3 of the 4 are closed because the issue was fixed; and probably the 4th should be closed as well (which I'm doing now). IMO what you are running into is a *different* issue. The error message is a rather generic error that can happen in a variety of scenarios. It's also possible that it's a regression that was introduced fairly shortly before the Lenny release with the changes Jérémy committed for RAID and LVM, but that's just a guess. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] Dropping architectures alpha and m68k from the Installation Guide
On Wednesday 14 October 2009, Brian Szymanski wrote: Maybe I'm just sad that alpha is being dropped for squeeze, but... It strikes me that not having install docs will be a major hindrance to any revival of the alpha port, as it will discourage potential new developers from ever trying debian on their boxes and seeing what needs to be fixed. The answer to that is that the installation guide for alpha for earlier Debian releases (up to Lenny) will remain available and should mostly remain valid for the next few releases, especially for architecture- specific topics. And for general installer functionality the installation guide for any other architecture can be consulted. I estimate that over 90% of the installation guide is identical for all architectures. So, even though not having an alpha installation guide for Squeeze and later may be inconvenient, it's not the end of the world IMO. I also can't help but wonder how realistic a revival is. After all, the main reason it's being dropped is lack of community interest. As far as the burden on translators goes, is there a priority ranking system for what needs to be done? Seems like that could help here... You can see the status of various translations here: http://d-i.alioth.debian.org/manual/ That page also contains various links to information for translators. Somehow I doubt you're such a super linguist that you could help with all the translations we have :-) But if you're interested in helping out with an existing translation, or starting one for your language, that's always welcome. For existing translations, please contact the current translators (on the appropriate d-l10n-lang list); to start a new translation, please mail the debian-boot list. But be warned that a new translation is a lot of work and only really worth starting if you're willing to commit to it for a long time. Or if you can gather a good team that can guarantee continuity. 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] Dropping architectures alpha and m68k from the Installation Guide
On Wednesday 14 October 2009, Frans Pop wrote: On Wednesday 14 October 2009, Brian Szymanski wrote: As far as the burden on translators goes, is there a priority ranking system for what needs to be done? Seems like that could help here... Sorry, I misread that comment. Yes, there is a priority system when it comes to translating. And I have used that in the past for new translations. I've suggested a few times to start with certain chapters and also to postpone parts that are not relevant for x86. And it would in theory be acceptable to leave specific text for non-release arches untranslated. The main problem is that, except for the few cases where arch-specific stuff is in completely separate files, there is no way to tell whether it is arch-specific text that is not up-to-date, or general text. And that only goes for XML-based translations; for PO-based translations it is practically impossible. Partly because of that I'm (as release manager for the manual) not willing to accept that translators treat the less popular architectures as second-class citizens. As long as we have one source for the manual that includes all architectures and as long as we sell Debian as the universal OS, the you can either translate the whole manual, or not at all. I simply don't want to have to wade through translations to check exactly what bits are and are not up-to-date every time I prepare a release [1]. IMO an outdated or incomplete translation can be worse that having no translation at all. [1] Although I am always willing to make exceptions on a case-by-case basis. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian-installer for GNU/kFreeBSD
On Wednesday 14 October 2009, Rick Thomas wrote: Let me see if I've got this right... The installer being based on (e.g.) Sid/unstable means that the active components of the installer CDs (the parts that do the installing, not the parts that will be installed) come from the current Sid/unstable toolset. It is possible (even, sometimes, done) for an installer to be based on testing/Squeeze, or even stable/Lenny. Daily builds, both D-I and CD, are always based on D-I components from unstable, but install testing. Weekly CD builds *normally* use D-I components from testing and install testing. But as long as there is no D-I release for squeeze, the weekly builds also use D-I components from unstable (as using the images that are currently in testing would only result in garbage). Regardless of what the installer is based on, it should be able to install components from any of the current distributions: stable/ Lenny, testing/Squeeze, unstable/Sid. Is this correct? We try to keep the installer compatible with the previous release. So, the installer for Squeeze (whether based on unstable or testing), should also be able to install Lenny, but may not install Etch correctly. There has been very little attention to this aspect recently though, so whether Lenny still installs correctly is not certain. The installer for an older release is never guaranteed to install a newer release correctly, even if in practise it may do so. However, you're quite likely not to benefit from all improvements in the new release. If so, there remains the question of were the passive components (i.e. things being installed) of the installer CDs/DVDs/etc... are drawn from. That's fairly simple (or not). - Passive components (debs) and are always taken from the target release. - Active components are D-I images and udebs, and there is a distinction between those: - if the installer is based on unstable: - D-I images are taken from daily builds (which are built from unstable) [1] - udebs are taken from unstable [2] - if the installer is based on testing: - D-I images are taken from testing on the mirrors [3] - udebs are taken from testing [4] Note that we don't really use the D-I images for unstable on the mirrors. (With one exception: the sid_d-i daily built CD images; but those are only used during a *very* short window for pre-release testing, and recently that has just been skipped as an effect of suboptimal release management.) Is there an established policy on any of this? Yes. It is all coded in the D-I build system and in debian-cd. Cheers, FJP For i386 this is: [1]http://people.debian.org/~joeyh/d-i/images/daily/ [2]http://ftp.nl.debian.org/debian/dists/unstable/main/debian-installer/binary-i386/ [3]http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/current/ [4]http://ftp.nl.debian.org/debian/dists/testing/main/debian-installer/binary-i386/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian-installer for GNU/kFreeBSD
On Wednesday 14 October 2009, Frans Pop wrote: Note that we don't really use the D-I images for unstable on the mirrors. (With one exception: the sid_d-i daily built CD images; but those are only used during a *very* short window for pre-release testing, and recently that has just been skipped as an effect of suboptimal release management.) Sorry, this is totally incorrect. We really do not use the D-I images for unstable on the mirrors. And the sid_d-i daily built CD images (using daily built D-I images, and udebs from unstable) are the normal daily CD images, while the squeeze_d-i daily built CD images (using D-I images and udebs from testing, just like weekly build CDs normally do) are the ones that are only used for pre-release testing. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[RFC] Dropping architectures alpha and m68k from the Installation Guide
Now that we have two architectures that are no longer official release architectures I've been wondering if we should remove any architecture- specific text for them from the Installation Guide. m68k was dropped as a release architecture for Etch, and alpha is being dropped for Squeeze. For m68k the intention was to bring it back as a release architecture, but now, over 2 years later, I think we can say that's unlikely to happen. The current situation is that both alpha and m68k are still included in the source for the manual, but are not included in official builds and also not in the daily builds on Alioth. So effectively it is dead text. I know that the installer still supports m68k (and is even being maintained to some extend by Steven Marenka) and that the same may or may not happen for alpha, but IMO that's a separate issue. A fact is that there have been no updates for the manual for either architecture for a very long time and that for example any links to images in them are incorrect. The main benefit of removing the architectures is for translators, especially for new translations. It would remove 2000+ lines of text which would no longer need to be translated (and which probably nobody will ever read anyway). If we do decide on the removal I would try to do it as four separate commits for each architecture: - remove the arch from the English original - remove the arch from all XML based translations [1] - remove the arch from the build system - PO files update, including removal of arch conditions embedded in strings (if any) Doing it this way would still keep open the option of re-including an arch later by reverting the first three of those commits. Of course, there would be some conflicts that would need to be handled and a general review and update would be needed, but I expect most text could be recovered without too many problems. For PO-based translations a PO-file merge could be done of the then current version with the version just before removal. Opinions, comments and suggestions welcome. Cheers, FJP [1] I expect I can do all changes myself, both for the English original and for translations; mostly using a script plus minor manual work for remaining bits. So there should be no work needed by translators. signature.asc Description: This is a digitally signed message part.
Bug#530909: Wrong message about device being busy
On Monday 12 October 2009, Martin Michlmayr wrote: I reported this issue in May and it's still there. Other people have seen it too. It doesn't matter whether you install to SATA, USB or MMC. This error doesn't show up all the time, but it shows up quite regularly. This is definitely a regression from lenny. I've solved at least one bug in the past that showed the same error, especially RAID related IIRC [1]. These errors frequently depend on a specific starting position and/or a specific way of setting up the disk. If you get that right, then in my experience the error is reproducible. What's not great about this error: - It's probably bogus. At least I cannot see any errors in the logs. I doubt that. It may be *harmless* in some (or maybe even most) cases, but that's not the same as bogus. - The ERROR!!! string that doesn't really say anything at all. - The choice Ignore and Cancel. I guess Ignore is go ahead and Cancel is go back, but there's a go back already. - When I press Go Back, it actually goes ahead to format the partition (which worked fine). In fact, all of the choices do the same (go ahead). Totally agreed that the presentation is sub-optimal. These are hard issues to fix. In general they require full debug logging of partman and extensive analysis of the debug log. And after that you probably also have to dive into parted_server and libparted. The real problem here is that nobody is currently making much effort to look into these issues (including me). Don't hold your breath waiting for the libparted maintainers to fix this... The debugging has to be done in D-I. [1] #345251, #377391, #382689, #470374 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471505: vga16fb framebuffer doesn't work on HP Compaq 2510p notebook
tag 471505 pending thanks On Friday 09 October 2009, Przemysław Kulczycki wrote: Any news on this bug? Lenny has been released long time ago, and squeeze is not frozen yet so fixing it now won't be risky. Also see the related Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/147250 Alternate install CD (both x86, AMD64) not booting on HP NX6325, HP 6510b and HP 2510p. As you can see, this bug affects more models than just the 2510p. I've committed a change that changes the default video mode for normal installs (using the newt frontend) to vga=788, which forces the VESA framebuffer. Tested on my own HP 2510p. The change should take effect in the next daily and weekly builds. Here's the commit log for the change: r60979 | fjp | 2009-10-10 14:01:55 +0200 (Sat, 10 Oct 2009) | 15 lines Change default video mode for i386/amd64 to vga=788 for the newt frontend This forces the framebuffer to VESA and will thereby solve problems reported on various HP notebooks with the vga16fb driver (#471505). It also increases the screen size (to 600x800, which is still quite conservative) and thus allows more information to be displayed. Note that dialogs should continue to be designed to work with 480x640 as other architectures may still use that as a default, and for network-console. vga=788 is the same video mode we use for the gtk frontend and as we've seen very few reports of that failing the change should be safe, but it is still somewhat experimental. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Create new dialogs/packages for the D-I using the new GUI-Interface
On Saturday 10 October 2009, Tatsu wrote: i'am searching for a HowTo or a reference manual which describe the way to create a new installer package (udeb?) with support for the new GUI-Interface included. That question does not really make sense. The graphical installer is supported by default in cdebconf, so you don't need to do anything special in new udebs to have that supported. Just use the debconf protocol. You just need to make sure that you include rootskel-gtk and cdebconf-gtk-udeb (and use the correct boot parameters) in the D-I initrd when you build an image, which is all done by default when you use one of the build_*-gtk targets available for building an image from installer/build. The best general instructions for creating udebs and building D-I are in: http://d-i.alioth.debian.org/doc/internals/ Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550509: Squeeze installation fails - no kernel modules found
Please reply to the BR, even if it is closed. On Saturday 10 October 2009, you wrote: One question: where can i find actual versions of vmlinuz and initrd.gz? From the daily build D-I images on [1]. The raw installer images for all installation methods can be found under other images. Do I understand correctly you're building a custom CD using debian-cd? If yes, then see the README for easybuild.sh for how to mix D-I from unstable with regular packages from testing. The version at /debian/dists/unstable/main/installer-i386/current/images/cdrom is from january 2009. Correct. That is the last D-I release. See the news items on [1]. [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: Problem with Debian 503
On Monday 05 October 2009, fserra...@gmail.com wrote: I have tried to install with Debian-503-amd64-DVD-1, and during console-data instalation, it tried to use busybox; but busybox is not in the 1º DVD. Can any help me, please? According to this search [1] the package _is_ included on DVD 1, as expected. It would have been a huge bug if it wasn't, and would certainly have been reported by others too. If you can reproduce the error, then please send us the /var/log/syslog (gzipped!) for the installation. Cheers, FJP [1] http://atterer.net/jigdo/jigdo-search.php?q=busybox_+_amd64 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Log from the October 5th 2009 D-I team meeting
On Wednesday 07 October 2009, Christian Perrier wrote: The meeting still happened (thanks to Luk and Otavio) and as usual, the logs are available from http://wiki.debian.org/DebianInstaller/Meetings Not Found The requested URL /debian-boot.2009-10-05-20.07.log.html was not found on this server. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[!!!] D-I SVN repository available - update
On Saturday 26 September 2009, Frans Pop wrote: It still means that the cleanup will take quite a bit longer than the planned 4 hours. I'm leaving the current dump+load stage running while I catch some sleep (after more than an hour it's now at revision 12875 out of 55900). alioth is still slowly but steadily making progress on this main part of the dump+load. It's now at 53900, so 2000 more to go. The speed at which revisions are processed varies a lot. During the last 2 hours 2800 revisions have been processed, but the hour before that I got only 300 revisions in an hour. For comparison: when I first tested the cleanup all 55900 revisions got processed in about an hour; now it looks to be something like 16 hours. After these first 55900 revisions there are three more stages: - load the cleaned up part of the history (55901 - 57350) - dump+load the rest of the history (57351 - HEAD) - updating revision comments to explain the cleanup and checking that all has gone well So my best estimate ATM is that we'll get there today, but expect commits to remain blocked for most of today. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: [!!!] D-I SVN repository available again - cleanup successful
On Friday 25 September 2009, Frans Pop wrote: I'm going to have another try at the cleanup [1] of the D-I SVN repository tonight. This means that starting 22:00 UTC committing changes to the Debian Installer subversion repository will not be possible. I expect the repository to be available again about 4 hours later, but please wait for the announcement. During most of the time reading from the repository should be possible, but if possible it is best to avoid using it completely. Attempts to commit changes during the cleanup will result in an error message. The cleanup has been successfully completed. I have documented the cleanup in the commit log for a number of affected revisions [1]. The repository is now again available for commits. I've done some checks and everything looks perfect, but please be alert for unexpected problems. I have made backups of the repository at two points and will keep those until we are confident there are no hidden issues. I would recommend everybody to do an 'svn up' before doing any new work or before committing changes. !! If you do notice anything odd, please mail the debian-boot list ASAP !! !! * People with a git-svn checkout with history should be aware that their history no longer 100% matches the cleaned up subversion repository. * People who have backups of the repository may want to check that their backup is still valid and/or make a new one. !! My thanks one final time to Bastian for his comments and suggestions during the development of the cleanup procedure. Sorry for any inconvenience due to the unavailability of the repository, but I think the end result was worth it. Cheers, FJP [1] Examples: - http://svn.debian.org/wsvn/d-i/?rev=55901sc=1 (where it all started) - http://svn.debian.org/wsvn/d-i/?rev=55934sc=1 (now empty l10n-sync) - http://svn.debian.org/wsvn/d-i/?rev=55973sc=1 (release tag) signature.asc Description: This is a digitally signed message part.
[!!!] D-I SVN repository not available starting 22:00 UTC today
Hi,
I'm going to have another try at the cleanup [1] of the D-I SVN repository
tonight.
This means that starting 22:00 UTC committing changes to the Debian
Installer subversion repository will not be possible.
I expect the repository to be available again about 4 hours later, but
please wait for the announcement.
During most of the time reading from the repository should be possible,
but if possible it is best to avoid using it completely. Attempts to
commit changes during the cleanup will result in an error message.
How does the cleanup affect users?
--
If you have done an 'svn update' for your local checkout any time since
the release of Lenny, the cleanup operation will not affect you.
If you did not update your local checkout for a long time, it is
recommended that you do an 'svn update' *before* the cleanup starts.
Otherwise you run a small risk that you will get errors the first time you
do an 'svn update' after the cleanup (see below).
The critical period is between revisions 55934 and 57134. If the output of
the following command is between those numbers, you should update.
$ svn info | grep Revision:
Revision: 59102
In this example there is no problem because 59102 is greater than 57134.
I was unable to update before the cleanup and now I get errors. Help!
-
If your last update was between the revisions mentioned above, you are
likely to get errors during your first update after the cleanup, for
example:
$ svn update
[...]
Upackages/cdebconf/debian/po/fr.po
Upackages/cdebconf/debian/po/mr.po
svn: Checksum mismatch for 'packages/cdebconf/debian/po/da.po';
expected: 'b774b328e96a031b617834e7337bba04',
actual: 'dbab32472d7433ab89da52f88245f24d'
Don't panic. You don't need to do a completely new checkout.
What you need to do is remove the directory that contains the broken file:
$ rm -rf packages/cdebconf/debian/po
If you then run 'svn update' again, it should continue.
In total 16 components are affected, so you will need to repeat that.
Alternatively, you can execute the following commands to remove all of
them in advance:
$ cd packages
$ rm -rf {cdebconf,nobootloader,flash-kernel}/debian/po
$ rm -rf arch/*/{silo,prep,quik,yaboot}-installer/debian/po
$ rm -rf arch/*/{sibyl,arcboot,vmelilo}-installer/debian/po
$ rm -rf partman/partman-{prep,newworld,target,ext2r0,efi,palo}/debian/po
$ cd ..
There is one last file that is affected: packages/po/sublevel4/da.po.
*** Make sure you don't have any local changes in that directory
*** before you remove it!
You can check if there are any local changes using 'svn status':
$ svn status packages/po/sublevel4
! packages/po/sublevel4
M packages/po/sublevel4/nl.po local changes!!
If there are no local changes, you can again safely remove the directory:
$ rm -rf packages/po/sublevel4
Cheers,
FJP
[1] http://lists.debian.org/debian-boot/2009/06/msg00081.html
signature.asc
Description: This is a digitally signed message part.
Re: d-i git repo: sample conversion
On Friday 25 September 2009, Christian Perrier wrote: Quoting Frans Pop (elen...@planet.nl): - partman components are very tightly coupled Very frequently changes, such as adding ext4 support, requires making related changes to multiple components. Being able to do so in a single branch in a single repository is of huge practical benefit. Isn't there room for a compromise here: make partman a single component? I don't think splitting the repository is an objective in itself, so keeping any components together should in principle be possible. I think the main reason for splitting the repository into individual components is tagging releases. Normally in git releases get tagged using only the version number of the component, so having multiple components in a single repository means you'd get very mixed up and conflicting tags. OTOH, I don't see why we could not tag releases using package/version, basically the same we do now in SVN. This could even be supported fairly simply in debcommit by adding a dotfile in the root dir of the git repository with a setting for that [1]. As I've indicated in my previous mail, I would not mind _some_ components getting split out of the D-I repository (e.g. win32-loader, mklibs, cdebconf [2], netboot-assistant). I can also see all kernel-wedge and kernel udebs split out, especially as they don't have But I still feel it would be a mistake to split out any components with installer-specific functionality, or to split out the 'installer' dir, 'scripts'. With regard to the PO master files, there are a few arguments for having that in a separate repository (note: not to leave it behind in the current SVN repository, but to split it out officially): - it would remain possible for translators to check it out separately - the commit history would get slightly less obscured by l10n sync commits (although you'd still keep the sync commits into individual components) Not sure if those outweigh *If* master PO files would get split out officially, I could also see having all partman components together in a separate repository as an option, maybe together with bootloaders and os-prober. Although I think I'd prefer to just keep them with the rest. As a compromise I could live with the manual being split out, although I think it would get even less commits from others than currently. [1] It should not be in a user config file as the setting will never be valid for *all* projects a DD works on. [2] Note that this IMO implies cdebconf also gets dropped from the master PO files and thus gets translation handling like any regular Debian package. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548369: eth0: ERROR while getting interface flags: No such device
reassign 548369 upgrade-reports thanks Please keep me in CC when replying! On Friday 25 September 2009, Hodge, Robert L wrote: Description: eth0: ERROR while getting interface flags: No such device Upgraded lenny on s390 to squeeze on s390, and upon rebooted received the following messages. Setting up networking Configuring network interfaces... SIOCSIFADDR: No such device eth0: ERROR while getting interface flags: No such device SIOCSIFNETMASK: No such device SIOCSIFBRDADDR: No such device eth0: ERROR while getting interface flags: No such device eth0: ERROR while getting interface flags: No such device Failed to bring up eth0. A backup was made of the squeeze install, and lenny was restored to the disk. I'm reassigning this report to upgrade-reports for now as this is certainly not an installation issue. First thing that needs to be done here is to find out the actual issue. Possible candidates are the kernel, udev or sysconfig-hardware. I suspect the last. Robert: please see the following bug report [1] and check if changing '#!/bin/sh' to '#!/bin/bash' in /sbin/hwup and /sbin/hwdown fixes the issue. You'll probably have to reboot after making the change for it to take effect. Did you change the default shell from bash to dash during the upgrade? Bastian: any chance of an upload of sysconfig-hardware to fix this? I reported the issue 2 months ago... Cheers, FJP [1] http://bugs.debian.org/538354 (Thanks to tbm for bouncing the BR to me.) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [!!!] D-I SVN repository not available starting 22:00 UTC today
On Friday 25 September 2009, Frans Pop wrote: I'm going to have another try at the cleanup [1] of the D-I SVN repository tonight. This means that starting 22:00 UTC committing changes to the Debian Installer subversion repository will not be possible. I expect the repository to be available again about 4 hours later, but please wait for the announcement. During most of the time reading from the repository should be possible, but if possible it is best to avoid using it completely. Attempts to commit changes during the cleanup will result in an error message. Although the speed of alioth is better than it was during my first attempt, it is still a lot slower than during the tests when I was developing the cleanup. However, the speed looks good enough that the total cleanup can be completed within a reasonable time. It still means that the cleanup will take quite a bit longer than the planned 4 hours. I'm leaving the current dump+load stage running while I catch some sleep (after more than an hour it's now at revision 12875 out of 55900). I expect to finish the cleanup some time tomorrow afternoon. The repository will have to remain locked for commits in the mean time. Sorry for any inconvenience. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: d-i git repo: sample conversion
Let me start with a request to other team members: PLEASE join this discussion. Think about how *you* use the repository; consider whether you are confortable with git or not; think about the issues raised both by Joey and me; and *give your opinion*. I hate the fact that this looks to be turning into an fjp against joeyh discussion. Does nobody else care? On Tuesday 22 September 2009, Joey Hess wrote: Debian Installer is *one* (upstream!) project with components that are sometimes tightly related, which should have a *single* (either central or decentral) repository It's more complex than that. We have important d-i components that are stored in other VCSs (ie, linux, libc). I strongly disagree with that. I think linux and libc (and other libraries and other udebs from general packages, such as fdisk, beep, etc.) are totally irrelevant to this discussion. Sure, we compile udebs against them and changes in them may affect us, but that's not other than any other package that compiles against a library or uses general utilities. Other things are uncomfortably grafted into the svn repository, despite having broader applications to Debian as a whole (busybox in /people, live-installer being shared with Debian Live, cdebconf being planned to be part of Debian base, os-prober being used by grub2, flash-kernel producing a deb as well as a udeb, etc). busybox and mklibs and even debootstrap probably don't really belong in the D-I repo at all. They were only added there because it was convenient. They could just as easily be moved to for example collab-maint. For cdebconf the reason it is in the D-I repo is mostly historic: it was started because of D-I and has been most actively developed for D-I. It was great having it tied in close, but maybe the time is ripe to split it out of the D-I repo and let it be maintained on its own, just like debconf is. d-i is generally loosely coupled, and melts into Debian around the edges. The components that I'm talking about and that are relevant here are those that provide D-I specific functionality, i.e. those that have postinsts or D-I specific scripts. Almost all of those live in the D-I repository. Sure, some things are more tightly coupled than others. But for those that are fairly tightly coupled there is IMO a huge benefit to having them in the same repository. I have already given some examples, but let me elaborate on them a bit more. - partman components are very tightly coupled Very frequently changes, such as adding ext4 support, requires making related changes to multiple components. Being able to do so in a single branch in a single repository is of huge practical benefit. - My partman cleanup in 2007 would have been a pain if components had all been in different repositories; I did major reshuffling across components by rebasing in my git-svn checkout while working on that. - For multi-CD support feature I required strongly related changes in di-utils, apt-setup and pkgsel. - My recent recommends change required related changes in di-utils, base-installer, pkgsel and preseed. The way D-I is managed as a project and most work on D-I does IMO not require distributed SCM We're using distributed SCM every day between git-svn and people posting patches to this list for review. What we lack is a unified distributed SCM platform, and I think we're suffering because of that in ways that may not be obvious. I'd like to see more concrete examples before I accept that. and for the situations where either distributed or offline work is desired, git-svn is IMO a more than adequate solution. Let me also make clear that I have very little against git, except that it has a *lot* steeper learning curve than subversion. git-svn is harder to learn than either svn or git. I disagree. git-svn is very straightforward as long as you only use it to track trunk, which is all that should be needed for distributed or off-line development. IMO much could be gained by simply documenting how to use a git-svn checkout for distributed development. In the proposal a few things besides the manual and master PO files are now weirdly kept in a master SVN repo: - scripts - kernel/massbuild* So for example when there is a kernel update, we'll now have to do an svn commit to update the massbuild.versions file, followed by separate git commits to update the various kernel-versions files. Of course these could be put into some git repo, but it's not clear to me what such a repo should be called. (It didn't help that kernel/massbuild is not located in scripts or kernel-wedge.) *shrug* It is in the most logical place for ease of use. Sure, the script could be moved to a tools package and installed on developer's systems, but that would still leave the massbuild.versions file, which IMO should be under version control and very simply is common to all kernel udebs. Sure, 'mr' is being
Re: d-i git repo: sample conversion
Given the team meeting this evening I guess this is my last chance to comment. The main reason I haven't so far is that I find myself simply caring less and less, but well. I really have only one argument against the switch to git: the splitting of the repository into multiple separate repositories. IMO that split is a huge loss. If there were really huge advantages *for D-I as a Debian project*, I could imagine accepting that loss, but IMO there are no significant advantages. Debian Installer is *one* (upstream!) project with components that are sometimes tightly related, which should have a *single* (either central or decentral) repository; splitting components into separate repositories will cause inefficiencies and a large number of annoyances in day-to-day development work. The way D-I is managed as a project and most work on D-I does IMO not require distributed SCM, and for the situations where either distributed or offline work is desired, git-svn is IMO a more than adequate solution. Let me also make clear that I have very little against git, except that it has a *lot* steeper learning curve than subversion. I use git a lot myself and it's a great environment to work in. If git offered a good solution for keeping D-I as a _single_ repository, I'd probably be in favor of a switch. In the proposal a few things besides the manual and master PO files are now weirdly kept in a master SVN repo: - scripts - kernel/massbuild* So for example when there is a kernel update, we'll now have to do an svn commit to update the massbuild.versions file, followed by separate git commits to update the various kernel-versions files. This exactly shows *why* D-I should live in a single repository: D-I is a single *upstream* project, and not a loose collection of unrelated components. Sure, 'mr' is being proposed as the solution to keep it all hanging together. I somewhat remember the announcement of 'mr' as a useful tool to keep repos for *unrelated* projects up-to-date. It's fine for that purpose, but promoting it as the glue for the proposed D-I setup is just crazy. It means that developers will now have to choose between *three* sets of commands (mr, git and svn) to do stuff as NONE of them will be appropriate in all situations. Doesn't that just sound crazy by definition? Is that an environment to which you can easily invite new contributors? IMO it's simply butt ugly. Here's a few things that currently are possible using git-svn (or with any solution that keeps D-I as a *single* source repository) that will no longer be possible with the new setup. - git grep across repo (mr is no option) - git gc across repo (mr probably is an option for this) - using gitk across repo (mr is no option) - branching across repo - committing related changes in multiple components in one commit The last two are actually the most important. I've had *many* occasions where a change required interdependent changes in multiple components, for example in multiple partman components, or in pkgsel and di-utils, or in a component and in the D-I build system. If D-I is a single repository I can simply create a new branch and work there. If the components are split up, I will continually need to create branches, make sure that I'm in the correct branch for the current component when changing directories, etc. And I will no longer be able to commit related changes in different components as a single commit. And even if I could use 'mr' (which probably is possible) to create branches for all separate git repos at the same time, and switch all those branches at the same time, that will only show the craziness of using 'mr' for that purpose: - it is horribly inefficient as git will need to load all individual repositories; - for most components those branches will remain unused - 'mr' can never *guarantee* that all components are on the same branch: that is 100% dependent on the user remembering to use 'mr' and not git - 'mr' would probably also (try to?) create branches for the SVN parts of the repo, which will cause its own problems I've also objected before to the incomplete switch. The current demo repos don't even include branches for all the release-specific updates we've done! Why would you want to do a migration where you don't include all the stable and security updates? When the migration from CVS to SVN was done at least nothing was lost. This migration simply drops a lot of work that was done in the past (such as obsoleted components), which means that the SVN repo will need to be kept forever if we think history is important. As conclusion: if the rest of the team really wants to switch to the proposed setup, then please go ahead. But to me the whole scheme sounds insane. The whole plan reeks of we want to be able to work in git, but we can't be bothered to do a proper migration. And in the proposals I have seen no mention of concrete examples of things that will
Bug#546834: debootstrap fails when invoked from lh_build
reassign 546834 util-linux 2.16-3 severity 546834 serious affects 546834 debootstrap tags 546834 d-i thanks On Wednesday 16 September 2009, Tak Auyeung wrote: lh_build failed and stopped in debootstrap phase. lh_build is set up to use sid for both bootstrap and chroot. Attached please find a log of lh_build (build.log) and a log of debootstrap (debootstrap.log) when it was invoked from lh_build. Thanks! Thanks for including the logs. As you can see in the debootstrap log, the real problem is in either util-linux or insserv. Setting up util-linux (2.16-3) ... install-info: warning: maintainer scripts should not call install-info anymore, install-info: warning: this is handled now by a dpkg trigger provided by the install-info: warning: install-info package; package util-linux should be updated. update-alternatives: using /bin/more to provide /usr/bin/pager (pager) in auto mode. insserv: Service checkroot has to be enabled to start service hwclock insserv: exiting now! dpkg: error processing util-linux (--configure): subprocess installed post-installation script returned error exit status 1 The install-info message is just a warning. The real problem looks to be a boot dependency error. Reassigning to util-linux. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian-installer use of initrd (was Re: CONFIG_BLK_DEV_RAM=y)
On Wednesday 16 September 2009, Ben Hutchings wrote: Is installation from floppies still supported? If so, can they be converted to using initramfs? Actually, I don't see how this can work today since ext2 is a module... Has anyone tested that these work in lenny? There are no floppy images in Lenny. We stopped building them because the kernel would no longer fit on the boot floppy. There was some discussion on having a separate kernel for D-I floppy installs (it would still fit with a number of unneeded optionsdisabled), but that was blocked by the kernel team as they did not want to build a separate flavor for that purpose. The infrastructure for building floppy images is still present and it could be in theory be enabled again. I see that INITRD_FS = ext2 is set for the _driver_ floppies, but not for the _boot_ floppy, so a modular ext2 should be OK in principle. We also have: ./config/armel/ads.cfg:11:INITRD_FS = ext2 No idea about this, although I think I saw a reply from Martin about it (specifically enabled in the armel config IIRC). ./config/powerpc/apus.cfg:9:INITRD_FS = ext2 Wouldn't worry about that. It's a dead configuration. Please go ahead with any changes you have planned. If we wish to enable floppy builds again at some point we can always revisit the issue. And if we'd be able to get a separate flavor for that purpose I guess it won't be an issue. Apologies for not replying sooner, but I had hoped that finally someone else would make the effort to respond to such questions. An idle hope apparently. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Debian-installer use of initrd (was Re: CONFIG_BLK_DEV_RAM=y)
On Wednesday 16 September 2009, Lee Winter wrote: So why can't all of the the lenny/squeeze installations be done with the kernel from etch or even sarge? This would seem to be completely within the jurisdiction of the installer team. Am I missing something? 1) Because it still needs to be able to boot on the same (modern) hardware as the installed system, and work with current versions of udev, and ... 2) Because using completely different kernel versions in installer builds is asking for problems. 3) Because of source compliance rules: the source for that older kernel would still have to be included in the current release. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian-installer use of initrd (was Re: CONFIG_BLK_DEV_RAM=y)
(No need to CC me on replies.) On Wednesday 16 September 2009, Lee Winter wrote: Nah. The whole point is to support legacy systems that are capable of _running_ the newest software, but whose peripheral suite is not adequte to _bootstrap_ the larger images. is it your belief that the existing 2.4+backports would not work? No. The floppy method is NOT targeted only at legacy systems. If it cannot exist as a full-featured installation method on the same level as other installation methods, then there is no point in maintaining it. Real legacy systems can always install Sarge and upgrade too. I'm sorry, but this is the last post from me in this thread. I appreciate your idea, but it's just not an approach that I at least would ever want to follow. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541831: installation-reports: Sunfire T2000 success (one minor issue)
user debian-boot@lists.debian.org usertags 541831 sparc tags 541831 moreinfo thanks Hi Stephen, On Wednesday 26 August 2009, Frans Pop wrote: On Monday 17 August 2009, Stephen Gran wrote: It sounds like the rsc console is something different, which could explain what you saw. Maybe we need special handling for this case. The rsc is much like an iLo or alom. It's just another management interface that offers a 'console' interface to manage the OS. I did the install using this interface, obtained by running 'break -c'. [...] Can you find out what /var/run/console-device contains at that point? I'd expect /dev/ttyS0, but it would be good to know for sure. You can probably find out by booting with BOOT_DEBUG=3 and then in /sbin/reopen-console add a 'set -x' plus near the end a 'sleep 30' so you have time to read the output. [...] We have solved similar problems in that past. The only thing that's needed is *some* way of identifying this case. Possibly there's something in /proc from openprom? We could then do something similar as was done for powerpc (see the code after # Set up virtualized... in [3]). The final option would be to add a dialog that's displayed if we are uncertain and that just asks what to use. Might be useful for other cases too. Main question is if you're willing and able to do a bit more digging :-) Are you interested in persuing this further? In case you're not, I'm tagging the BR for posterity. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541831: installation-reports: Sunfire T2000 success (one minor issue)
On Wednesday 16 September 2009, Frans Pop wrote: Yep, I know about that post, but I'm not sure whether that's related or not. AFAIK that issue was about having no console output at all, not about incorrect configuration of the installed system. Well, the second part of the mail is this issue. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541831: installation-reports: Sunfire T2000 success (one minor issue)
On Wednesday 16 September 2009, Stephen Gran wrote: FWIW, I've been pointed at http://lists.debian.org/debian-sparc/2009/04/msg00024.html . The follow up suggests it may already have some fixes in? It's possible I may not have gotten the r1 image, although I thought I was using the latest image. Yep, I know about that post, but I'm not sure whether that's related or not. AFAIK that issue was about having no console output at all, not about incorrect configuration of the installed system. However, both that and this issue really need some quality time from someone with access to a box to help us make any needed changes in the installer. And we simple have no sparc users or porters providing any quality input. I'm pretty sure that any tweaks will turn out to be fairly minor, but they'll never happen if nobody provides the needed info and testing. Frans -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Spam cleaning for August 2004
On Tuesday 15 September 2009, Giacomo A. Catenazzi wrote: I contacted the listmasters on IRC, and they removed the messages. Excellent! Thanks a lot. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debmirror (was: d-i git repo: sample conversion)
On Tuesday 08 September 2009, Ian Campbell wrote: One issue I had with debmirror in the past (with nobody to complain to ;-)) Hmmm? Never heard of the BTS? ;-) was that I wanted a partial mirror of main+contrib of testing but just main/debian-installer of sid. I wanted this so that I can build squeeze install CDs with the sid d-i without the bandwidth cost of mirroring all of both distributions. A valid use case. I have something similar myself: mirror testing/unstable for six arches + stable for only two of those. There's a couple of open wishlist bugs for that. It comes under the heading of improved flexibility (see my reply to Lee Winter). There are some suggested approaches and I have some ideas, but not yet decided on the best approach. It is somewhere on my ToDo list, but not the highest priority. Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545584: installation-guide: Typo in command name, kbdconfig should be kbd-config.
tags 545584 pending thanks On Tuesday 08 September 2009, Tapio Lehtonen wrote: Chapter 6.3.1.3. Choosing a Keyboard (run kbdconfig as root after you have completed the installation). Fixed for original and translations. Thanks Tapio! -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: problem retrieving packages with debootstrap.
On Tuesday 08 September 2009, Guillaume Yziquel wrote: The command I use is pbuilder create --debootstrapopts --variant=buildd --basetgz base.tgz I do not know how it translats in term of debootstrap. That's not even very relevant. Just try creating a standard chroot: # debootstrap sid target dir http://ftp.nl.debian.org/debian The log will be in target dir/debootstrap/. The most likely causes are: - temporary broken dependencies in unstable: wait until they get resolved That's probably not the issue: 'broken' packages would take turns way too fast. Checking the log file will tell... - unreliable mirror: try using a different one I: Checking component main on http://ftp.jp.debian.org/debian... Eh, if you're using the default Japanese mirror I'm not surprised you see download issues. How do you change the mirror you're using? Don't we have man pages to answer such questions? Or even plain 'pbuilder --help' answers this': --mirror [mirror location] You can also set it in $HOME/.pbuilderrc, e.g: MIRRORSITE=http://ftp.nl.debian.org/debian - unreliable network connection This is most probably the issue. However, is there any way to make use debootstrap reliable on unreliable connections? Like increasing timeouts, retrying, etc...? I don't think so, but it really should not be needed. But start by using a decent close mirror. And if it still fails: check the logs!!! You should be able to do so even with pbuilder by using the option that tells it not to delete the chroot on errors or after completion. And please do spend some quality time with the documentation. Cheers, FJP P.S. I think you should consider posting your next questions on the debian-user mailing list. This basic level of support is not really appropriate for a development list. Based on the info you've given so far it looks to me as if there is absolutely nothing wrong with either pbuilder or debootstrap. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: d-i git repo: sample conversion
On Monday 07 September 2009, Christian Perrier wrote: Have you made some progress here? During the team meeting today, there is a rough consensus that we should move on but all of us agreed that you could have interesting comments and, even if they aren't as polished as you would like to, it would be interesting to have your first comments. Sorry, for not yet replying as I promised and thanks for the reminder. Main excuse is that I've gotten lost in debmirror [1] and debtree. I'll move it higher on my ToDo list. Cheers, FJP [1] Which now supports mirroring everything needed to to create CD images using debian-cd, including (released) D-I images and the docs and tools directories :-) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debmirror (was: d-i git repo: sample conversion)
On Tuesday 08 September 2009, Lee Winter wrote: [1] Which now supports mirroring everything needed to to create CD images using debian-cd, including (released) D-I images and the docs and tools directories :-) Would you please describe what is left that the new version of debmirror will _not_ mirror? Below are the remaining restrictions, at least those that I'm aware of. - Does not mirror translations of descriptions (dists/*/*/i18n/*). This is really the main open feature request. - Does not mirror and use diff files for Contents files. Mainly a performance issue. Not very important for most users. Both of the above items needed a change on the mirrors themselves, and as it happens both were implemented today (thanks Joerg!). - Does not mirror Contents files for udebs. Not sure if that will be easy to add now. Again, not all that important. - The special directories (doc, tools, indices) can only be mirrored using rsync. My position on that is that it's more a feature than a bug. Note that most users should not need indices (which is huge). - Only mirrors _current_ D-I images; the official mirrors can also contain one or more previous releases. - Does not mirror daily built D-I images, but as those are not on the mirrors, that's logical. Would also cause HUGE amounts of traffic. - Some types of mirror layout are not supported; only a problem for mirroring unofficial mirrors. Other requests/ideas concern improved performance and flexibility. See also my recent blog posts on debmirror: - http://alioth.debian.org/~fjp/log/posts/debmirror.html - http://alioth.debian.org/~fjp/log/posts/debmirror_I.html If you want to follow development, follow my blog :-P Cheers, FJP -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545047: tasksel: iamerican and ibritish are no longer standard, readjust language tasks as needed.
On Saturday 05 September 2009, Christian Perrier wrote: A compromise seems to be adding an english task with iamerican so that *all* en_* installs have iamerican, ispell and d-c (en_GB would then have ibritish and iamerican). Another option would be dropping the british task and use iamerican and ibritish in a general english task (after all, is it correct to only have iamerican for en_IN, en_AU or en_ZA?) Or keeping the en_GB task and adding an en task alongside that that is used as default for any en_* locale that does not have a country-specific task. That seems to me to be most in line with the general localization rules: use a language task, unless a more specific language_country task is available. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
