Re: Bug#182041: PIC library has bad name
mklibs fails to find the PIC library for reduction since it's called libnewt-utf8_pic.a while mklibs expects it to simply be libnewt_pic.a We're using newt debian-installer so it'd be nice if this were fixed so we could save some bytes on the boot media. :-) I have a few questions: I've thought boot-floppies worked with the name libnewt-utf8_pic.a. Why doesn't debian-installer mklibs not work with it? Because libnewt.so.0.50 is a symlink to libnewt-utf8.so.0.50.17. $ ldd tmp/cdrom/tree/usr/lib/cdebconf/frontend/newt.so libnewt.so.0.50 = /usr/lib/libnewt.so.0.50 (0x40005000) libc.so.6 = /lib/libc.so.6 (0x40014000) libslang.so.1-UTF8 = /lib/libslang.so.1-UTF8 (0x40124000) libm.so.6 = /lib/libm.so.6 (0x40185000) libdl.so.2 = /lib/libdl.so.2 (0x401a6000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) so mklibs only sees libnewt.so.0.50 and strips off the suffix and gets libnewt_pic.a. I got your point, regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soname versions in library udebs
* Sebastian Ley wrote: As for now no udebs actually have their soname number as part of the package name. It is libc-udeb, discover-udeb... Hm, no one talking to me, so I just reply myself...: What actually happens if there is an ABI change in one of the library udebs? Let us say a new version of libc or libdirectfb enters sid, and udebs will be built accordingly. Since they do not have a SONAME version, all dependant udebs will be broken because anna will pull in the new version of the library via libc-udeb or libdirectfb-udeb but the programms are linked against the old ones. Correct? Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
udebs for more than just installation
[I have set Mail-Followup-To; please To/CC me on replies.] Hi guys, Over here at Progeny we're wondering about the feasibility of using udebs in resource-constrained environments for more than just installation. How feasible would it be to use udebs as real packages? I note that udpkg appears to support maintainer scripts, though I don't know it supports them as comprehensively as regular dpkg (see sections 6.4 and 6.5 of the Debian Policy Manual). Another approach we're thinking about is regular dpkg support for directory exclusion during package unpack, for things like documentation and localization files. Of course, that's more an issue for debian-dpkg... :) Anyway, I thought you guys might have the best insights into udebs since you use them the most. -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#182642: boot-floppies: boottime keymap makes 88 key adb keyboard unusable on oldworld powermac
#include hallo.h * Lee Adamson [Wed, Feb 26 2003, 06:47:31PM]: When the box reboots after initial base system install, a boottime keymap is loaded that seems to cause my old 88 key adb keyboard to be mapped wrong (using the qwerty/us keymap). The solution I have found is to use the shell on VT2 to remove the /target/etc/init.d/keymap.sh script (or just move it out of the way) so that the kernel keymap is kept on reboot. Once console-tools or console date (whichever it is that allows you to select a more specific keymap) is configured, a working keymap (that is KERNEL) can be chosen. This problem arose when manually editing the sources list at install time to point to unstable rather than stable. I do not know if the problem appears if stable or testing are installed instead. The system used is a power macintosh 8500/[EMAIL PROTECTED] (xlr8), though I doubt that has any bearing on the problem, as an apple extended 101 key adb keyboard does not exhibit the same problem. Could anyone prove this and tell the exact reason of the problem? Problem of console-tools? Anything that can or should be fixed in boot-floppies for Woody? Please keep Cc'ing to debian-boot or me. Gruss/Regards, Eduard. -- cat `locate .signature` -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udebs for more than just installation
tor 2003-02-27 klockan 17.34 skrev Branden Robinson: [I have set Mail-Followup-To; please To/CC me on replies. How feasible would it be to use udebs as real packages? I note that udpkg appears to support maintainer scripts, though I don't know it supports them as comprehensively as regular dpkg (see sections 6.4 and 6.5 of the Debian Policy Manual). I'm not quite sure what it is you are asking. Are you asking for how nifty things you can do with udpkg? Right now, udpkg only calls /.../package.config configure /.../package.postinst configure and that's it. I don't see how we would need any *rm scripts in the installer. :) This can, I guess, be expanded if dpkg being tiny is more important than dpkg being stellar at maintainer scripts. Another approach we're thinking about is regular dpkg support for directory exclusion during package unpack, for things like documentation and localization files. Of course, that's more an issue for debian-dpkg... :) Isn't that what has been discussed before, for handhelds and stuff? If you're willing to make udebs anyway, you won't need this though, as I don't see why dpkg wouldn't be able to handle udebs. There's nothing magic about udebs, they just happen to have different names and don't follow policy more than they like... /Martin signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signeradmeddelandedel
Re: Bug#182642: boot-floppies: boottime keymap makes 88 key adb keyboard unusable on oldworld powermac
On Thu, Feb 27, 2003 at 06:36:08PM +0100, Eduard Bloch wrote: When the box reboots after initial base system install, a boottime keymap is loaded that seems to cause my old 88 key adb keyboard to be mapped wrong (using the qwerty/us keymap). Could anyone prove this and tell the exact reason of the problem? Problem of console-tools? Anything that can or should be fixed in boot-floppies for Woody? Please keep Cc'ing to debian-boot or me. Hmm, well I'm not as well versed in console-tools (or anything for that matter) as I should be but... I think it is not a problem with console tools, as it can be configured to keep the kernel keymap later. Perhaps an option in boot-floppies to not touch the keymap for people like me who have very odd input devices (the keyboard is from an Apple //gs; I like it because it is very compact). It may not be worth fixing though; I don't imagine very many people use those particular keyboards. I believe the same model was also used on some 68k macs from maybe 1989?-1993? I can get you the model number when I get home if you need it. I wish I know more about these things so I could submit better information... If you would like me to obtain information using my box and send it to you, I'd be happy to, just let me know what you would like done. I can probably dig up another scsi device somewhere and install again if more details in that regard would help. Thanks for your time. -- Obligatory Plug: Mirima Tyalie - The OPL RPG http://www.mirimatyalie.org pgp0.pgp Description: PGP signature
Re: udebs for more than just installation
On Thu, Feb 27, 2003 at 06:56:09PM +0100, Martin Sj?gren wrote: I'm not quite sure what it is you are asking. Are you asking for how nifty things you can do with udpkg? Right now, udpkg only calls /.../package.config configure /.../package.postinst configure and that's it. I don't see how we would need any *rm scripts in the installer. :) You wouldn't. I see what you mean, though. This can, I guess, be expanded if dpkg being tiny is more important than dpkg being stellar at maintainer scripts. I guess that sort of depends. Isn't that what has been discussed before, for handhelds and stuff? If you're willing to make udebs anyway, you won't need this though, as I don't see why dpkg wouldn't be able to handle udebs. There's nothing magic about udebs, they just happen to have different names and don't follow policy more than they like... Yes. I was just wondering what udpkg's capabilities are. Thanks for the feedback! -- Branden Robinson | GPG signed/encrypted mail welcome [EMAIL PROTECTED] | 1024D/9C0BCBFB Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C | 72E8 0F42 191A 9C0B CBFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udebs for more than just installation
Has anyone looked at the ipkg (sp?) format used on Compaq iPaqs? Its an cut-down dpkg format for embedded use. (I've just heard of it, not investigated it. A comparison by someone who knows both, and the debate over dpkg v2, would be nice). Regards, Alastair On Thu, 2003-02-27 at 17:56, Martin Sjgren wrote: tor 2003-02-27 klockan 17.34 skrev Branden Robinson: [I have set Mail-Followup-To; please To/CC me on replies. How feasible would it be to use udebs as real packages? I note that udpkg appears to support maintainer scripts, though I don't know it supports them as comprehensively as regular dpkg (see sections 6.4 and 6.5 of the Debian Policy Manual). I'm not quite sure what it is you are asking. Are you asking for how nifty things you can do with udpkg? Right now, udpkg only calls /.../package.config configure /.../package.postinst configure and that's it. I don't see how we would need any *rm scripts in the installer. :) This can, I guess, be expanded if dpkg being tiny is more important than dpkg being stellar at maintainer scripts. Another approach we're thinking about is regular dpkg support for directory exclusion during package unpack, for things like documentation and localization files. Of course, that's more an issue for debian-dpkg... :) Isn't that what has been discussed before, for handhelds and stuff? If you're willing to make udebs anyway, you won't need this though, as I don't see why dpkg wouldn't be able to handle udebs. There's nothing magic about udebs, they just happen to have different names and don't follow policy more than they like... /Martin -- Alastair McKinstry [EMAIL PROTECTED] GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine signature.asc Description: This is a digitally signed message part
Sarge-i386-businesscard.iso
Hi! I was trying out the Sarge-i386-businesscard.iso (40MB iso image). http://gluck.debian.org/cdimage/testing/netinst/i386/sarge-i386-businesscard.iso What's the gluck stand for? Good Luck? I burned the iso image and booted into the install process with this CD, but did not succeed installing anything. A text console showed up with with about 5 steps for which I chose the defaults. I only got so far as installing modules from the CD. About 35 modules showed up. After a prompt I entered the module number and it showed up as being selected in the list. But then I was baffled about what to do next. The last option offered (#5) to go to a shell which I took and was told that I could use the nano editor and a few shell commands. However, once in the shell I noticed nano didn't work. It was not in any of the paths. I am guessing the installation left out the step of setting up partitions on the hard drve. And what's this about udeb? Some new package utility? I read through the install documents and found nothing anywhere near describing how to use this CD. Can anyone give any pointers. Has someone made a page to go along with this CD to explain how to use it? Thanks for any help! hank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
m68k, debian-installer, and DevFS
Hi As some of you are already aware, there's a problem wrt m68k in that there's no decent 2.4 kernel for m68k yet. As such, creating an m68k debian-installer image that actually works is a bit problematic right now, since debian-installer depends on DevFS quite a lot, while DevFS will only be found in 2.4-kernels. To work around this issue, I've been thinking of emulating DevFS in user space (with some tricks that involve /etc/modules.conf, for those interested). However, as I'm not going to implement every possible piece of hardware 'out there', I'd like to know what hardware debian-installer searches for, and only implement that. This will obviously include hard disks and their partitions, but what more? Is there a list available? If not, can one be created? Thanks, -- wouter at grep dot be An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udebs for more than just installation
On 27 Feb 2003 18:56:09 +0100 Martin Sjögren [EMAIL PROTECTED] wrote: Another approach we're thinking about is regular dpkg support for directory exclusion during package unpack, for things like documentation and localization files. Of course, that's more an issue for debian-dpkg... :) Isn't that what has been discussed before, for handhelds and stuff? If you're willing to make udebs anyway, you won't need this though, as I don't see why dpkg wouldn't be able to handle udebs. There's nothing magic about udebs, they just happen to have different names and don't follow policy more than they like... (sorry, this has tuned into a bit of a rant) The reason udeb's came about is that the debian-installer wanted to be modular, we wanted these modules to be distirubted via debian mirrors, and we didnt want any non-functional parts inside (docs, copyright notice etc). This last point means they arent valid debs according to policy and as such arent allowed into the archive, by renaming them to something other than debian package (they are installer _modules_) meant that the bureaucracy was avoided. The binaries of a .udeb are different to the .deb counterparts, they are usually compiled with -Os and other options to make the binaries smaller, so having an option to strip docs using dpkg would not avoid requiring another package (woops, debian installer module). udebs are a technical solution to a social problem, i hope that one day debian policy will reflect the needs of the installer. In the mean time they do serve as a convenient way of distributing packages (woops, modules). Technically i think the biggest problem with minimal debian systems is that debian packages dont declare dependencies on essential packages, installign Essential packages and their dependencies requires 62MB (dependencies pull in dselect, which pulls in c++ libs etc). As much as i like dselect, i shudder at the thought of running it, or even needing it to exist in my space constrained environment. If all the essential packages wernt installed then the dependency system breaks. Debian currently just isnt geared toward small environments, and the steps required to improve the situation dont seem to be a priority, i do hope the situation improves. Glenn pgp0.pgp Description: PGP signature
Re: udebs for more than just installation
Branden Robinson wrote: Another approach we're thinking about is regular dpkg support for directory exclusion during package unpack, for things like documentation and localization files. Of course, that's more an issue for debian-dpkg... :) Please Progeny guys, make everyone's day and do this. It shouldn't even be too hard to do; dpkg parses the tars itself to install files as .dpkg-new at first, so you just have to hook into the right places and make it do nothing for some files. (Famous last words.) And there is even dpkg.cfg already to put the exclude regexps in. -- see shy jo, who has a 30 mb (uncompressed) debian install, which was _not_ fun to do pgp0.pgp Description: PGP signature
patch to create slang1a-utf8-udeb
Hi.
I was sort of annoyed by nano not working in debian-installer.
The result is the attached patch, which changes this.
As I'm just a random user of nano in debian-installer initrd, you probably want
to wait what someone of the debian-installer team has to say about this.
Especially, I don't know about the hardcoded dependency on libc6 and whether bug
#182042 obsoletes this bug.
Cheers
Thomas
diff -urN x/slang-1.4.5/debian/control slang-1.4.5/debian/control
--- x/slang-1.4.5/debian/controlFri Feb 28 00:43:27 2003
+++ slang-1.4.5/debian/control Fri Feb 28 00:28:11 2003
@@ -112,3 +112,15 @@
on custom installation floppies and in embedded systems. Unless you're
making one of those, you won't need this package.
This packages has wide character support.
+
+Package: slang1a-utf8-udeb
+Section: debian-installer
+Priority: optional
+Architecture: any
+Depends: libc6-udeb
+Description: S-Lang library with utf8 support
+ This is a udeb, or a microdeb, of the S-Lang library with wide charater
+ support. As such it is the installer counterpart of slang1a-utf8.
+ You only need this package to support applications needing S-Lang during
+ the Debian installation process time and probably don't need to select it
+ manually for installation.
diff -urN x/slang-1.4.5/debian/rules slang-1.4.5/debian/rules
--- x/slang-1.4.5/debian/rules Fri Feb 28 00:43:27 2003
+++ slang-1.4.5/debian/rulesFri Feb 28 00:45:42 2003
@@ -1,4 +1,5 @@
#!/usr/bin/make -f
+# udeb adaptation by Thomas Viehmann
# Made with the aid of dh_make, by Craig Small
# Sample debian/rules that uses debhelper. GNU copyright 1997 by Joey Hess.
# This version is for a hypothetical package that builds an
@@ -19,6 +20,10 @@
LIBSLANG=slang1
LIBSLANG_UTF8=slang1a-utf8
+LIBSLANG_UTF8_UDEB=$(LIBSLANG_UTF8)-udeb
+
+DEBVERSION=$(shell dpkg-parsechangelog | grep '^Version: ' | sed -e 's/^Version: //')
+UDEBNAME=$(LIBSLANG_UTF8_UDEB)_$(DEBVERSION)_$(shell dpkg-architecture
-qDEB_BUILD_GNU_CPU).udeb
build:
true;
@@ -105,10 +110,12 @@
(sed 's/@DEBIANUTF8ERRORCHECK@/#ifndef/' debian/slang.h.extra.in; cat
src/slang.h ) `pwd`/debian/slang1-utf8-dev/usr/include/slang.h
chmod 644 `pwd`/debian/slang1-utf8-dev/usr/include/slang.h
+ cp debian/slang1-utf8-dev/usr/lib/libslang.so.*
debian/$(LIBSLANG_UTF8_UDEB)/lib/libslang.so.$(SOMAJOR)-UTF8.$(SOMINOR)
mv debian/slang1-utf8-dev/usr/lib/libslang.so.*
debian/slang1a-utf8/lib/libslang.so.$(SOMAJOR)-UTF8.$(SOMINOR)
# The ldconfig symlink to make the library work ASAP. This is not really
required.
cd debian/slang1a-utf8/lib ; ln -sf libslang.so.$(SOMAJOR)-UTF8.$(SOMINOR)
libslang.so.$(SOMAJOR)-UTF8
+ cd debian/slang1a-utf8-udeb/lib ; ln -sf
libslang.so.$(SOMAJOR)-UTF8.$(SOMINOR) libslang.so.$(SOMAJOR)-UTF8
# Correct the .so link for slang1-utf8-dev library
cd debian/slang1-utf8-dev/usr/lib ; ln -sf
/lib/libslang.so.$(SOMAJOR)-UTF8.$(SOMINOR) libslang.so
@@ -120,8 +127,8 @@
binary-arch: binary-nonutf8 binary-utf8
dh_testdir -a
dh_testroot -a
- dh_installdocs -a
- dh_installexamples -a
+ dh_installdocs -a -N$(LIBSLANG_UTF8_UDEB)
+ dh_installexamples -a -N$(LIBSLANG_UTF8_UDEB)
cd debian/slang1-dev/usr/share/doc/slang1-dev/examples/ ; \
mv demo/* . ; \
@@ -131,10 +138,10 @@
mv Makefile.simple Makefile ; \
rm -f config.status config.log configure configure.in
- dh_installmenu -a
- dh_installcron -a
- dh_installmanpages -a
- dh_installchangelogs -a changes.txt
+ dh_installmenu -a -N$(LIBSLANG_UTF8_UDEB)
+ dh_installcron -a -N$(LIBSLANG_UTF8_UDEB)
+ dh_installmanpages -a -N$(LIBSLANG_UTF8_UDEB)
+ dh_installchangelogs -a changes.txt -N$(LIBSLANG_UTF8_UDEB)
dh_strip -a
dh_compress -a
@@ -148,10 +155,15 @@
dh_makeshlibs -p$(LIBSLANG_UTF8) -V ${LIBSLANG_UTF8} ( 1.4.4-7.1)
dh_installdeb -a
dh_shlibdeps -a
- dh_gencontrol
-
- dh_md5sums -a
- dh_builddeb -a
+ dh_gencontrol -a -N$(LIBSLANG_UTF8_UDEB)
+ dh_md5sums -a -N$(LIBSLANG_UTF8_UDEB)
+ dh_builddeb -a -N$(LIBSLANG_UTF8_UDEB)
+
+ # don't know how to do shlibdeps
+ # dh_shlibdeps
+ dh_gencontrol -a -p$(LIBSLANG_UTF8_UDEB) -- -fdebian/files~
+ dpkg-distaddfile $(UDEBNAME) debian-installer optional
+ dh_builddeb -p$(LIBSLANG_UTF8_UDEB) --filename=$(UDEBNAME)
source diff:
@echo 2 'source and diff are obsolete - use dpkg-source -b'; false
diff -urN x/slang-1.4.5/debian/slang1a-utf8-udeb.dirs
slang-1.4.5/debian/slang1a-utf8-udeb.dirs
--- x/slang-1.4.5/debian/slang1a-utf8-udeb.dirs Thu Jan 1 01:00:00 1970
+++ slang-1.4.5/debian/slang1a-utf8-udeb.dirs Thu Feb 27 23:18:48 2003
@@ -0,0 +1 @@
+lib
pgp0.pgp
Description: PGP signature
Re: udebs for more than just installation
Glenn McGrath wrote: udebs are a technical solution to a social problem Not entirely. I avoided some picky policy stuff with udebs, but as much of the idea was to make sure that the stuff used by the installer did not bloat the main packages lists, and to make sure nobody would install it by accident on a real system. -- see shy jo pgp0.pgp Description: PGP signature
Bug#182436: marked as done (some small problems with debian-installer)
Your message dated Thu, 27 Feb 2003 15:44:13 -0800 with message-id [EMAIL PROTECTED] and subject line Bug#182436: some small problems with debian-installer has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 25 Feb 2003 12:39:32 + From [EMAIL PROTECTED] Tue Feb 25 06:39:31 2003 Return-path: [EMAIL PROTECTED] Received: from port5.ds1-sby.adsl.cybercity.dk (trider-g7.fabbione.net) [212.242.169.198] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18neMr-0004OW-00; Tue, 25 Feb 2003 06:39:29 -0600 Received: by trider-g7.fabbione.net (Postfix, from userid 1000) id 4FF4A1BF5; Tue, 25 Feb 2003 13:39:26 +0100 (CET) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Fabio Massimo Di Nitto [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: some small problems with debian-installer X-Mailer: reportbug 2.10 Date: Tue, 25 Feb 2003 13:39:26 +0100 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-0.5 required=4.0 tests=HAS_PACKAGE,SPAM_PHRASE_01_02 version=2.44 X-Spam-Level: Package: installation Version: CVS 25/02/2003 (not installed) Severity: normal Hi all, probably some of these small problems are known and sorry in case of duplicated information. I did built d-i from today CVS and noticed this: - hostname at reboot is localhost (Im sure this is an old problem) even if specified differently during the installation. /etc/hosts is indeed correct. - for kernel 2.4.19 are missing modules/userland utils. An example is evms. It is possible to install the userland but not load any module. That makes the userland useless. - on the console (busybox) a number of commands do not work. ex: ifconfig, modprobe. keep printing the enabled functions in busybox. - at d-i modules selection time number 18) is missing a description i hope to remember correctly that was 18 but anyway it just claim: 18) for debian-installer - lilo config should be regenarated after the first reboot with a more commented one. - mkswap is enabled in busybox but it is still not possible (if not by hand) to create a swap partition automatically. Then i made some experiments using kernel-2.4.20 to install changing of course the version in the Makefile and in order to make it fitting on the disk i dropped the isapnp card support (no need for my laptop). Well of course the first problem is the size. 1 floppy is not enough. It arises the same problem of kernel modules/userland utilities (this time for lvm as well). The installer anyway cannot go further the partition harddisk. It looks like it cannot find the partitions even if they are there. I was not able to force it to proceed even mounting the partitions by hand. Thanks to everyone. except from this small things I had a really good feeling using it. Congratulations for your great job guys! Fabio -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux trider-g7 2.4.19 #3 Tue Oct 8 19:33:41 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=C --- Received: (at 182436-done) by bugs.debian.org; 27 Feb 2003 23:43:33 + From [EMAIL PROTECTED] Thu Feb 27 17:43:32 2003 Return-path: [EMAIL PROTECTED] Received: from svfulraptor1.beckman.com (catalunya) [134.217.237.30] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 18oXga-0002NR-00; Thu, 27 Feb 2003 17:43:32 -0600 Received: from kraai by catalunya with local (Exim 3.35 #1 (Debian)) id 18oXhF-0008GD-00 for [EMAIL PROTECTED]; Thu, 27 Feb 2003 15:44:13 -0800 Date: Thu, 27 Feb 2003 15:44:13 -0800 From: Matt Kraai [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Bug#182436: some small problems with debian-installer Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.3.28i Sender: Matt Kraai [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Status: No, hits=-3.0 required=4.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SIGNATURE_SHORT_DENSE,SPAM_PHRASE_03_05,USER_AGENT, USER_AGENT_MUTT
