Re: Please stop sending me emails
Tagedy of the commons. Bloody vigilante's are as bad as the spammers. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: D-I impressions
On Tue, 3 Aug 2004 00:07:16 -0500 Ryan Underwood [EMAIL PROTECTED] wrote: - Should ntpdate be included as part of the base install? pool.ntp.org is rather reliable, and it helps to have one's clock in a sane state so that tar does not complain about timestamps being in the future, and things like that. rdate would be simpler, busybox has an rdate which is very small. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#244589: busybox-cvs: 'cp -a' from cramfs breaks
I just fixed this a different way in busybox's cvs, by not preserving hard links to directories. But, perhaps your patch should be applied as well, to prevent unintentional hard linsk from being being created. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231994: extra blank line in ls
Hi, ive applied you patch upstream. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233294: installation report - tar: Unrecognised file type
On Tue, 24 Feb 2004 14:28:50 -0500 Barry Hawkins [EMAIL PROTECTED] wrote: What is the status on this bug? I tried to install again on 02/22 and still got the failure at perl-base, even using the 02/21 daily. I don't understand how people are still able to test the installer if this is happening. I can extract perl-base deb using upstream busybox and busybox-cvs-udeb_20040101-7 As far as i can see this bug is fixed. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#234130: choose-mirror: fails without proxy
Ive just fixed busybox wget upstream so that it ignores the proxy variable if its set to 0 Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tar and busybox
On Sat, 21 Feb 2004 03:30:18 +0100 Michael Banck [EMAIL PROTECTED] wrote: To my knowledge, the behaviour change was reverted in tar-1.13.92-5, so it does not seem necessary to change busybox tar: tar (1.13.92-5) unstable; urgency=low * patch from Paul Eggert to revert bogus behavior where POSIXLY_CORRECT set in the environment forced 'pax' format archives, closes: #230872 http://mail.nongnu.org/archive/html/bug-tar/2004-02/msg00014.html There are two issues. 1) when GNU tar creates archives using the posix tar format it uses pax extensions, the busybox-cvs package doesnt understand these headers at all, i have modified upstream busybox to spit out an obvious message when it enconters these. 2) when GNU tar creates archives using the ustar tar format (and also gnu format i think) it no longer sets the filetype in tar's mode field, it only sets it in the filetype field. The ustar mode field is specified to be 8 octal charcters stored in ascii, it only specifies what will be in 4 of these characters. The 12 least significant bits of a files mode as returned by stat (rwsrwsrwx) are specified as being stored in this field The spec doesnt say what should or shouldnt be in other 4 bytes, GNU tar used to store the files mode in the 5th charcter, it was very convenient as the full mode as seen by stat() was stored in one place. Previous version of busybox tar used to depend on this 5th byte being filled in, it would only set the files mode from the tar filetype field if OLDGNU compatability was enabled. The new version of tar is more strictly in compliance with the spec, but the old way was much more convenient, i guess it must be a portability issue. I have fixed busybox tar in upstream cvs so it should be able to extract ustar archives created with the current version of tar. A couple of handy references are ustar interchange format as described by the opengroup. http://www.opengroup.org/onlinepubs/007904975/utilities/pax.html#tag_04_100_13_06 S tar docuentation, man star(4) is also good. http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/man/star.4.html Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233627: CONFIG_FEATURE_TAR_OLDGNU_COMPATABILITY disabled
On Thu, 19 Feb 2004 02:00:32 -0800 Matt Kraai [EMAIL PROTECTED] wrote: If CONFIG_FEATURE_TAR_OLDGNU_COMPATABILITY is enabled, the type is displayed correctly and the directory is extracted correctly. This patch needs to be applied to the busybox-cvs package, a new package will be uploaded that brings it into sync with upstream busybox cvs. http://www.busybox.net/cgi-bin/cvsweb/busybox/archival/libunarchive/get_header_tar.c?r1=1.30r2=1.31 Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233627: CONFIG_FEATURE_TAR_OLDGNU_COMPATABILITY disabled
On Thu, 19 Feb 2004 11:37:42 +0100 Bastian Blank [EMAIL PROTECTED] wrote: tar produces oldgnu archives in gnu mode. From the tar Changelog i see you have to use --format=ustar to create normal tar archives. I dunno what the GNU tar maintainers are smoking. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233627: CONFIG_FEATURE_TAR_OLDGNU_COMPATABILITY disabled
On Thu, 19 Feb 2004 22:37:12 +1100 Glenn McGrath [EMAIL PROTECTED] wrote: On Thu, 19 Feb 2004 11:37:42 +0100 Bastian Blank [EMAIL PROTECTED] wrote: tar produces oldgnu archives in gnu mode. From the tar Changelog i see you have to use --format=ustar to create normal tar archives. But that doesnt help busybox tar. I tried specifying formats of gnu, oldgnu, posix, ustar and v7 with GNU tar 1.13.92 and busybox tar cannot extract any of them without oldgnu compatability mode enabled. So many people hell bent on destroying the tar standard, why cant they just leave it alone Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#233294: installation report - tar: Unrecognised file type
On Tue, 17 Feb 2004 16:51:59 -0500 George Kumengi [EMAIL PROTECTED] wrote: Everything works fine until I get a Base system installation error debootstrap program exited with an error (return value 1) Virtual Console 3 says: tar: Unrecognised file type The error means busybox doesnt know if the file being extracted is a regular file or directory or symlink etc, which is very strange, ive not seen the error triggered before (and i wrote the code). I would really like to know what triggered it. Any idea which debian package or tarfile it was trying to extract ? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer help wanted
On Sat, 31 Jan 2004 13:43:29 -0500 4. low memory support d-i barely supports installations on systems with 32 mb of memory. It's unlilkely to ever support lesser systems unless someone steps up to work on it. We have some ideas, that should work, but no time. What are the ideas ? I may be interested in working on them... Also as far as space on the root floppy goes, the lost+found directory entry in the current filesystem should be removed. If the root filesystem type up for negotiation then romfs is smaller than ext2. Is the only reason we need a writable filesystem so that the install reoprt can be stored there ? Is that a permanent feature ? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer help wanted
On Sat, 31 Jan 2004 18:54:46 -0500 Joey Hess [EMAIL PROTECTED] wrote: Glenn McGrath wrote: Is the only reason we need a writable filesystem so that the install reoprt can be stored there ? Is that a permanent feature ? There are dozens of places where the installer writes to its filesystem. A few: - /etc/ files written by netcfg - cdebconf databases - logs - apt-install's queue - register-module's queue - anna/udpkg I mean the filesystem type of the rootdisk image, before its moved to tmpfs. Obviously when booting from cd the filesystem isnt writtable, so for consistency it should be safe to assume the same for all boot media. romfs-tmpfs makes more sense to me than ext2-tmpfs Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#228915: ash bug fixed upstream
The ash bug which occured when alt-1 was pressed has been fixed in upstream cvs in shell/cmdedit.c rev 1.86 Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#227081: (no subject)
Woops, looks like i introduced that bug... ive commited your patch to busybox's cvs. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#216435: fixed upstream
A fix for this bug has been applied to upstreams cvs. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#215612: fixed upstream
This bug has been fixed in upstreams cvs. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#173390: terminal width broken
Im pretty sure this got fixed ages ago, there is no currently no problem with the serial console on arm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#224620: dhcp lvm problems, partconf GRUB wishlist
On Sat, 20 Dec 2003 18:33:56 +0100 Martin Michlmayr [EMAIL PROTECTED] wrote: Why do you ask for the debconf priority at the beginning? I think it should just be high by default and people who want something lower can pass DEBCONF_PRIORITY. I guess/hope this is currently only asked for testing, and that it will be disabled later. I chose high. Its only logical that setting the priority should happen after the user has choosen a language, that way they have a better chance of understanding the issue. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer beta 1
On 19 Nov 2003 01:51:51 +0100 Goswin von Brederlow [EMAIL PROTECTED] wrote: Glenn McGrath [EMAIL PROTECTED] writes: The reason i havent applied it is because i dont have a raid setup handy to test it, i only tested it on a few loop files. Someone was going to test it, but i never heard back, so i also question if it would get much use. If debian-installer wants to use it i will make another effort at testing it. Ok, great. What exactly is the support for? (moved from debian-devel) The raidtools patch still applies and compiles, its at http://people.debian.org/~bug1/busybox/raidtools.bb.patch.bz2 Most of the binaries as provided in the raidtools2 package are provided by the patch, mkraid, raidstart, raidstop, radi0run, and some of the fancy hotadd stuff. All up they compile to a 20kB busybox binary. D-I would need something to create the config, create the metadata (mdcreate was it?), mdrun and mdstop. Anything else? mkraid, raidstart, raidstop are 17kB Creating the config is the hard part, i feel D-I really needs a partition config that is seperate from the tools used to create the partitions. A frontend that allows users to specify how they want the partitions, and then a backend that calls the apropriate tools to do the job. Easier said than done though. Hlenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some ways to save space on the floppies
On Thu, 13 Nov 2003 15:13:44 +1100 Glenn McGrath [EMAIL PROTECTED] wrote: pipe-progress is the only non-busybox binary in bootfloppy-initrd, pipe-progress is very simple and could easily assimilated by busybox. Having only one binary in the first initrd would open the possibility of compiling it statically, this would eliminate the requirment for ld-linux.so.2 which is 89kB on i386. I think static binaries may be marginally smaller than a binary + dynamic library (after library reduction) due to some library overheads, it is a very marginal savings though i think. Comparing static glibc busybox against shared library reduced glibc. busybox.static 578456 (277656 compressed with gzip) busybox.shared 94668 (56116) ld-linux.so.2 90144 (46709) libc.so.6 542664 (240184) Total Shared727476 (343009) Total Static578456 (277656) Uncompressed saving 149 kB Compressed saving65 kB Comparing static uClibc busybox against shared library reduced glibc. busybox-static-uclibc 144276 (80525) Total Shared (glibc)727476 (343009) Total Static (uclibc) 144276 (80525) Uncompressed saving 583 kB Compressed saving 262 kB Moving to uclibc and a static binary will make a lot of difference, certainly give us a lot more flexibility in kernel features. uClibc can be a shared library, but i didnt consider that in this comparison. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dhcp clients
On Wed, 12 Nov 2003 23:39:02 -0500 Joey Hess [EMAIL PROTECTED] wrote: I noticed that while the cdrom install pulls in dhcp-client-udeb and uses it for dhcp, the floppy net install does not have a dhcp client listed, so it falls back to using udhcp, from busybox-cvs-udeb. This does not seem like a good idea, it puts us in the position of supporting more than one dhcp client. I have plenty of space on the floppy for dhcp-client-udeb, and this would also let udhcp be turned off in busybox-cvs-udeb, possibly saving some space. The situation is even more confused for the netboot image, which uses: - dhcp-client-udeb (hppa, ia64, mipsel) - pump (all other arches) So we're suppporting *3* dhcp clients on i386 alone! I think in the long term udhcpc is the best for our purposes and we should be moving away from other clients. dhcp-client has been around for a long time, its tried and tested, but i wouldnt expect udhcpc to cause problems either. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some ways to save space on the floppies
On Thu, 13 Nov 2003 12:37:45 -0500 Joey Hess [EMAIL PROTECTED] wrote: Glenn McGrath wrote: uClibc can be a shared library, but i didnt consider that in this comparison. Any reason why not? It would still be bigger than busybox compiled statically against uclibc. I just attempted to make reduced library uClibc and had some problems # mklibs -d ./tmp -L/usr/i386-linux-uclibc/lib/ ./busybox I: Using ld-uClibc.so.0 as dynamic linker. I: library reduction pass 1 139 symbols, 139 unresolved I: library reduction pass 2 141 symbols, 8 unresolved Traceback (most recent call last): File /usr/bin/mklibs, line 469, in ? raise No library provides non-weak + symbol No library provides non-weak main Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Install report
NSTALL REPORT Debian-installer-version: beta1 Date: 12-11-03 Method: net install from floppies, no proxied. Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [E] Config network: [O] Detect CD: [E] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[E] Mount partitions: [E] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: On boot it asked for my language, i chose English (Australian), it changed the keymap to something that isnt qwerty, it should be a normal US keymap. I had two network cards, one was an ISA card, which prevented dhcp from working, powered down pulled out the ISA card. Rebooted, selected English (Australian), dhcp worked configured the network, downloaded some stuff, detected hardware and dumped me in cfdisk. I had not had a chance to change the keymap back to the correct US keymap, so i pressed random keys till i worked out how to say 'Yes' to get out of cfdisk. Got back to menu fixed up keymap, went back and partitioned the disk, i had to reboot to for partition changes to take effect. Rebooted, selected English (Australian) (i should have learnt my leason by now) it took me all the way into configuring and mounting partitions, i selected cancel or abort (bottom left button) so i could go back change the keymap and look around. Loaded some installer modules for something to do, one of them kept asking me if i wanted to manually perform CD configuration, i dont have a CD, i kept saying no to try and get back to the menu, it kept ignoring me, i eventually said yes which took me to the next screen and then i had a chance to get back to the menu. When i was ready to configure and mount my partitions it wouldnt let me back in, i tried changing debconf levels, i couldnt continue the install any further as the next steps required a configured partition. I surrendered at this point. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
2nd question must ask debconf level
Im sure there are a lot of users who want things to work automatically, but not everyone does, and it makes problems more difficult to fix. Unless the 2nd question asks the level of questioning the only way the user effecting the installation, is from the console (i wasnt sure of what the command is), or inducing a fault by removing disks/network cables. I didnt see main menu until evetything was installed, just after installing the lilo bootloader, i tried installing grub after this and it failed. I would have liked to specify a proxy before downloading all the debs and udebs to save bandwidth for future tests, but i didnt get the chance. I keep thinking i can get around the keymap problem now that im aware of it, but this time due the automation i even typed in my password using some strange keymap, dont know what it translated to. It seems lots of menu items can only be run once. The only details i have regarding configuring and mounting partitions is that i was at the default debconf level for beta1, i changed it to low and i couldnt get in. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2nd question must ask debconf level
On Thu, 13 Nov 2003 00:43:57 +0100 Sebastian Ley [EMAIL PROTECTED] wrote: In fact it is easier: At the boot prompt enter: linux DEBCONF_PRIORITY=medium (or low if you wish) Ok, didnt know that, perhaps some help menus at the boot prompt would be usefull, like the old boot floppies had. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some ways to save space on the floppies
pipe-progress is the only non-busybox binary in bootfloppy-initrd, pipe-progress is very simple and could easily assimilated by busybox. Having only one binary in the first initrd would open the possibility of compiling it statically, this would eliminate the requirment for ld-linux.so.2 which is 89kB on i386. I think static binaries may be marginally smaller than a binary + dynamic library (after library reduction) due to some library overheads, it is a very marginal savings though i think. A static busybox could be a good way to begin to use uclibc which is a lot smaller than glibc. There is duplication of functionality in the busybox provided in bootfloppy-initrd and floppy-initrd, the busybox in floppy-initrd could be reduced in size by making the two versions of busybox co-exist, perhaps by renaming the first on busybox-bootfloppy. I havent tried this in practice but i cant think of any reason why it wouldnt work. If floppy-initrd is compressed with bzip2 instead of gzip it would save 85kB, adding bzip2 support to busybox-bootfloppy would add about 7kB to the binary size, less after compression. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Install report
On Thu, 16 Oct 2003 13:28:36 -0400 Joey Hess [EMAIL PROTECTED] wrote: Fraser Campbell wrote: Loading the second floppy, some dots or a spinning cursor would be useful here just to show meaningful progress. I agree, though it will take some shell magic, since all I have is POSIX shell, and the following command: zcat floppy/initrd.gz mnt/tmp-initrd To get a spinner, it would probably have to fork off a program that just spins, and then kill it when done. I'll get to it eventually. There was a progress indicator patch sent to the busybox mailing list recently Read from stdin, write to stdout, write a progress indicator to stderr. http://www.busybox.net/lists/busybox/2003-October/009498.html Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#212764: [BusyBox] [gemorin@debian.org: Bug#212764: 2 race conditions in init implementation]
I have found two races conditions in the run() function of busybox's init implementation (static pid_t run(const struct init_action *a)). Ive applied your patch as is to cvs. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#211675: [BusyBox] [sgunderson@bigfoot.com: Bug#211675: busybox-cvs-udeb: fails to use internal libpwdgrp; breaks 'id' and others]
- Forwarded message from Steinar H. Gunderson [EMAIL PROTECTED] -
coreutils/id.c (among others) uses a function called my_getgrnam from
libbb.a, which in turn calls getgrnam() which it expects to find in
libpwdgrp.a. However, since GNU ld only searches .a files coming
_later_ on the command line compared to the file it searches in, it
never searches libpwdgrp.a and thus searches for it in libc.so.6 instead
(where it finds it). Thus, it breaks at runtime since NSS is not
available, and glibc can only do a small amount of /etc/{passwd,group}
reading without libnss_files.so.2.
Ive applied the patch to busybox cvs.
Thanks
Glenn
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#181812: (no subject)
Hmm in my busybox chroot (upstream cvs) this works # ls /dev/*/disc0/disc /dev/discs/disc0/disc However in the busybox-0.60.99.cvs20030819 package it doesnt work, must be a configuration option, or the problem must have been fixed between the 19th and 22nd. I will look into it. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: building boot-floppies in a dchroot ?
On Tue, 26 Aug 2003 07:43:04 +0200 Sven Luther [EMAIL PROTECTED] wrote: but if i call the chroot /chroot/path /bin/busybox in the dchroot, i get the same error. If you are using the busybox ash shell in your chroot you should do 'chroot /chroot/path /bin/busybox ash' or 'chroot /chroot/path /bin/busybox sh' or chroot /chroot/path /bin/[a]sh if just have already setup the symlinks, or just chroot /chroot/path if you are changing to the same shell as you were previouly using. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: busybox FTBFS bugs
On 02 Aug 2003 08:18:47 +0100 Alastair McKinstry [EMAIL PROTECTED] wrote: Hi, I've just submitted another FTBFS bug against busybox-cvs for the Alpha; this is blocking d-i building on alpha, and I'd guess ia64. Now, looking at the sources, I can submit a patch easily enough; but whats the plan with busybox-cvs : are we going to patch it, or move to a newer version from CVS? That bugs isnt the oly problem on aloha, bug #186331 prevents the static package from building, its a bug in glibc. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2003-06-12 installation failure report
On 12 Jun 2003 12:52:47 +0200 Petter Reinholdtsen [EMAIL PROTECTED] wrote: [Gaudenz Steinlin] 1. mkfs.ext2 and mkfs.ext3 are files of size 0 instead of links to mke2fs. Deleting these files and creating links made partconf work Bug #196508. Probably a bug in busybox tar. I just checked in changes to busybox tar to convert hard links to symlinks. Not the same thing, but maybe good enough. I wasnt sure about waldi's patch as it adds non standard modes, but maybe in the long term something like that will be needed. Glenn I -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdeboostrap
On Mon, 9 Jun 2003 16:56:11 +0200 Bastian Blank [EMAIL PROTECTED] wrote: hi folks because we suffered some problems with our shell i made a rewrite of debootstrap in c. Nice, it might cut down the shell commands that are needed. It might be convenient to merge it into busybox. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#186927 acknowledged by developer (Re: Bug#186927: romfsbuiltin)
On Mon, Mar 31, 2003 at 01:00:35PM +1000, Glenn McGrath wrote: Package: kernel-image-2.4.20-1-i386 Version: 2.4.20-7 Severity: wishlist It would be useful to the debian-installer if romfs was built into the kernel rather than being a module. This would allow the debian installer initrd to use romfs instead of ext2 which would reduce the intird by 9047 Bytes for the current net image. 785625 net-initrd.ext2.gz 776578 net-initrd.romfs.gz romfs is supported by the debian installer build/Makefile, just set INITRD_FS=romfs Compiling romfs into the kernel will increase its size by 1953 bytes for i386 bzImage. Net savings of 7094 bytes on the boot floppy. That would imply the removal of ext2. Please come back after you've got an agreement on debian-boot. No. Both ext2 and romfs could be compiled into the kernel and as long as romfs is used for the initrd it will save space. If we use ext2 or cramfs on the initrd it will add 2kB. I cant think of any reason against using romfs for the initrd, if anyone can please speak up. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discover 1.5-2 pre-release available
On Mon, 24 Mar 2003 18:03:19 -0500 Branden Robinson [EMAIL PROTECTED] wrote: A pre-release (source code only) of Discover 1.5-2 is available: Why version 1.5, i see 2.0.1 is the latest version ? Glenn -- 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
main/debian-installer component in Release file
Extracted from the unstable Release file Architectures: alpha arm hppa hurd-i386 i386 ia64 m68k mips mipsel powerpc s390 sh sparc Components: main contrib non-free main/binary-alpha/Packages main/source/Sources main/debian-installer/binary-alpha/Packages In this context, what is debian-installer supposed to be, should main/debian-installer be considered the component, if so how about putting it in the Components field ? If debian-installer is a sub-component of the main component it would be good if that was mentioned somewhere. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status 2003-02-21
On 21 Feb 2003 16:30:02 +0100
Tollef Fog Heen [EMAIL PROTECTED] wrote:
optimally, what I'd like
is getting anna to support gpg and verify the full integrity of the
install. One would then only have to trust the integrity of the
initial boot media; a compromised mirror would be detected
immediately.
Attached is program that uses libopencdk to verify the
Release/Release.gpg file, its only experimental code though.
The code is small, but as it needs libgcrypt (which needs opencdk and
zlib) it makes it a 350kB binary, 171kB gzip'ed, which is pretty big for
our purposes.
Glenn
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
#include sys/types.h
#include errno.h
#include stdio.h
#include string.h
#include opencdk.h
extern int verify_gpg_file(const char *sign_file)
{
CDK_KEYDB_HD pub_db;
CDK_HD hd;
int rc;
const unsigned long ftpmaster2003[2] = { 0xB629A24C, 0x38C6029A };
const unsigned long ftpmaster2002[2] = { 0xAA7DEB7B, 0x722F1AED };
printf(Verifying gpg signature of %s\n, sign_file);
cdk_set_log_level(CDK_LOG_DEBUG);
rc = cdk_keydb_new(pub_db, CDK_DBTYPE_PK_KEYRING, /home/bug1/.gnupg/pubring.gpg, 29);
if (rc) {
fprintf(stderr, keydb new: `%s'\n, cdk_strerror(rc));
return 0;
}
cdk_handle_new(hd);
cdk_handle_set_keydb(hd, pub_db);
/* Check the signature */
rc = cdk_file_verify(hd, sign_file, NULL);
printf(cdk_file_verify result is %d\n, rc);
/* Process the results */
rc = cdk_sig_get_ulong_attr(hd, 0, CDK_ATTR_STATUS);
switch(rc) {
case CDK_SIGSTAT_GOOD: {
const unsigned long *keyid;
keyid = cdk_sig_get_data_attr(hd, 0, CDK_ATTR_KEYID);
/* TODO: should detect the key id using a seperate keyring ? */
printf( Good signature by %08lX%08lX\n, keyid[0], keyid[1]);
if ((keyid[0] == ftpmaster2002[0]) (keyid[1] != ftpmaster2002[1])) {
printf( Key signed with expired key\n);
}
else if ((keyid[0] != ftpmaster2003[0]) || (keyid[1] != ftpmaster2003[1])) {
printf( Danger Will Robinson, Danger!\n);
printf( Who the hell is %08lX %08lX ?, keyid[0], keyid[1]);
printf( It should be signed by B629A24C 38C6029A\n);
printf( This other guy might be trying sneak in a trojaned package!\n);
printf( Danger Will Robinson, Danger!\n);
exit(-1);
}
break;
}
case CDK_SIGSTAT_BAD:
printf( Verification failed, signature doesnt match file\n);
break;
case CDK_SIGSTAT_NOKEY:
printf( Verification failed, unknown keyid\n);
break;
}
/* Cleanup */
cdk_handle_free(hd);
return(rc);
}
int main(int argc, char **argv)
{
verify_gpg_file(argv[1]);
}
pgp0.pgp
Description: PGP signature
Re: debian-installer status 2003-02-21
On Sun, 23 Feb 2003 10:35:04 +1100 Glenn McGrath [EMAIL PROTECTED] wrote: The code is small, but as it needs libgcrypt (which needs opencdk and zlib) it makes it a 350kB binary, 171kB gzip'ed, which is pretty big for our purposes. To be more specific, compiling statically against libopencdk, libgcrypt and libz, but dynamically against glibc gives that result. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: squashfs compressed file system update?
The comparisons to cramfs does favour squashfs for lowmem installs. My only reservation is the fact that its not in the official kernel, but it sounds like you intend to stick it out and maintain it outside the offical tree, so that shouldnt be too much of a problem. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: squashfs compressed file system update?
On Tue, 18 Feb 2003 10:08:45 -0600 (CST) Drew Scott Daniels [EMAIL PROTECTED] wrote: Would squashfs work? I doubt this is an optimal compression, but it might be better than alternatives. Currently the best free solution might be based on PPMd which has been packaged into Debian. Im not confident about squashfs, i think the best solution is initrd.romfs.gz for normal installs, but squashfs or cramfs might be good for lowmem installs, i havent looked into squashfs yet, not sure when i will get time. I have looked at PPMd, ive read thats good but it took me a while to workout how to use it to get maximum ocmpression, here is a comparison. 8921088 Packages 2375680 Packages.gz 1814528 Packages.bz2 1335296 Packages.pmd That was done with PPMd e -o16 -m256 -r2 Packages, it surprised me that the -m option (amount of memory to use) effects the compression ratio. Thats a pretty improvement over bz2. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: squashfs compressed file system
On Tue, 4 Feb 2003 10:27:59 -0600 (CST) Drew Scott Daniels [EMAIL PROTECTED] wrote: It looks stable enough now, but I wonder why it hasn't been included in the Linux kernel (even 2.5?). I also have to question the value of zlib compression vs other types of compression, but then I suppose that zlib usually gives better compression than none. If I ever get to it I'll try writing a zlib replacement that uses a PPM variant, but it seems unlikely that I will. The reason gzip compression is used on intrd's is becasue the kernel and some bootloaders (grub at least) support it. It would be great is we could use better compression on the initrd. Ill have a look at squash fs for comparison, but if it isnt in the main kernel its hard to depend on it for the installer, it could be used in custom builds though i guess. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upx to compress bzimages?
On Wed, 29 Jan 2003 13:51:12 -0700 Erik Andersen [EMAIL PROTECTED] wrote: The kernel compresses itself using gzip, so upx isn't likely to be useful there. It would be much more useful when used on the rest of userspace. Though I suspect you would get better results by simply switching the initrd filesystem from ext2 to cramfs. Turns out that cramfs uses more space than ext2 which surprises me, but i think cramfs's advantage is that it could reduce memory requirements, a boot-root floppy not needing an ramfs at all. (bytes) 757889 net-initrd.romfs.gz 765815 net-initrd.ext2.gz 874360 net-initrd.cramfs.gz 880640 net-initrd.cramfs romfs is the winner as far as initrd size goes, its also the smallest of the three filesystem in terms of okernel size. So i still say romfs is a better choice, but cramfs is worth thinking about for lowmem installs if we need such a thing. Now if only we could have romfs built into the kernel. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Upx to compress bzimages?
On Wed, 29 Jan 2003 16:31:21 +0100
Petter Reinholdtsen [EMAIL PROTECTED] wrote:
# upx tmp/vmlinuz
Ultimate Packer for eXecutables
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002
UPX 1.24 Markus F.X.J. Oberhumer Laszlo Molnar Nov
7th 2002
File size Ratio Format Name
-- --- ---
upx: tmp/vmlinuz: UnknownExecutableFormatException
Packed 0 files.
#
I tried packing the programs in bin/ and usr/bin/, but this only made
the initrd.gz files larger.
Have anyone used upx successfully with d-i?
I had a go at it the other day.
I think vmlinuz is the compressed kernel, you should run it on an
uncompressed kernel, i.e. vmlinux
It didnt compress very well at all, maybe i was doing something wrong.
Glenn
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
romfs initrd and kernel config
I commited changes to build/Makefile to allow the filsystem on the initrd to be specified, it defaults to ext2 so it currently doesnt make any difference. 748 net-initrd.ext2.gz 736 net-initrd.romfs.gz So romfs saves us 12kB on the filesystem overheads of the initrd. It requires romfs be compiled into the kernel which will add 1.3kB to the kernels size (seems low buts thats what i get), so we are 10.7kB ahead. It also means we dont _need_ ext2 support compiled into the kernel, if that was made a module it would save us another 16kB. Cramfs is also compiled in, if removed would save 8.3kB. So we could save upto 35kB on the rescue disk, however we need to consider if we should have a kernel config specifically for the debian-installer, or should it be usable with the existing kernel package initrd system. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
di: initrd isnt free'd
Booting the net flavour. cat /proc/mounts shows /dev/root.old is mounted on /initrd devfs is mounted twice on /dev I think one of the devfs mount must be from the ext2 ramdisk prior to moving it to tmpfs, even though the path doesnt say so. I cant unmount dev it reports Device or resource busy, this i assume is preventing /initrd being unmounted and from freeramdisk /dev/rd/0 from working. Ive been strugling with it for a couple days now, ive even tried to redo the initrd system in c, but i still havent been able to free /dev/rd/0 Anyone know whats going wrong, or when it broke (if it ever worked) Is it safe to set rootfs as /dev/rd/0 in syslinux.cfg even though tmpfs is the real rootfs ? Thanks Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#172580: fixied in cvs
I had a play on merulo.debian.org and sorted it out, the fix has been commited to busybox cvs, will upload a new package in the next day or so. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#173390: busybox autowidth and ioctl TIOCGWINSZ
I googled this URL, looks like busybox has had this problem has happened before. http://www.busybox.net/lists/busybox/2001-March/002578.html We could set set some default values to handle this, or we could prompt for values if we know we are on a serial console. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#172580: (no subject)
This should be fixed in 0.60.99.cvs20021214. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: busybox ash, insmod and udhcpc
On 18 Nov 2002 03:01:37 +0100 Tollef Fog Heen [EMAIL PROTECTED] wrote: * Glenn McGrath | We can save some space in the rootfs by using busybox from cvs | | busybox-0.60.4 130856 | busybox-cvs 123628 | | busybox-0.60.4 + dash + dhclient + insmod 271160 | busybox-cvs with busybox ash, udhcpc and insmod also compiled in | 201804 | | I think busybox ash, udhcpc and insmod should be good enough to use. I've played about with busybox-cvs today and it seems to work fine, especially having a half-decent shell is good when trying to debug problems. However, it seems like udhcpc there is broken -- it completely fails to send out any requests for leases, or there is something eating them on the way. Also, getting the build system in busybox CVS updated to actually work with the new configuration system would be good.. I could provide you with patches tomorrow or so. I built this the other day, its at http://people.debian.org/~bug1/busybox/ 139k busybox-unstable-udeb_0.61-pre0-cvs20021126_i386.deb 70k busybox-udeb_0.60.5-2_i386.udeb The size has blown out, but extra stuff included in busybox is ash and ip (big applets) and also smaller applets logger, mkswap and swaponoff hmm, busybox-unstable.deb with the same feature as 0.60.5-2 appears to have increased in size by 20kB, maybe i translated the config incorrectly, ill look into that. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: busybox ash, insmod and udhcpc
On Thu, 28 Nov 2002 09:13:48 +1100 Glenn McGrath [EMAIL PROTECTED] wrote: hmm, busybox-unstable.deb with the same feature as 0.60.5-2 appears to have increased in size by 20kB, maybe i translated the config incorrectly, ill look into that. Ignore this, i was including the changelogs etc Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: socket-modules udeb
On Fri, 8 Nov 2002 18:11:07 -0800 Matt Kraai [EMAIL PROTECTED] wrote: There isn't enough space on the net image, however. Substituting pump-udeb or udhcpc-udeb for dhcp-client-udeb frees up enough space. Any other suggestions? Switch to busybox ash, and busybox insmod as well, that will save some more space. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: socket-modules udeb
On Sat, 9 Nov 2002 18:11:15 +1100 Glenn McGrath [EMAIL PROTECTED] wrote: Switch to busybox ash, and busybox insmod as well, that will save some more space. Erik tells me busybox insmod doesnt work on all supported platforms so thats not a good idea. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: codingstyle?
On 03 Nov 2002 20:38:43 +0100 Tollef Fog Heen [EMAIL PROTECTED] wrote: no tabs. spaces. four spaces. opening braces on opening line closing braces unindented to the correct level I use a tab but set tab to 4 spaces :) If you make an .indent.pro you can update you style. You might get some more ideas from http://www.busybox.net/cgi-bin/cvsweb/busybox/docs/style-guide.txt Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
busybox ash, insmod and udhcpc
We can save some space in the rootfs by using busybox from cvs busybox-0.60.4 130856 busybox-cvs 123628 busybox-0.60.4 + dash + dhclient + insmod 271160 busybox-cvs with busybox ash, udhcpc and insmod also compiled in 201804 I think busybox ash, udhcpc and insmod should be good enough to use. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where do i find configured-network
On Thu, 24 Oct 2002 23:41:08 +0200 Joakim Kolsjö [EMAIL PROTECTED] wrote: O well... i guess i have to edit all To: and Cc: to get it right, can't seem to find any setting in sylpheed that would fix this, i know that it's possible to change this on server level(SeLinux has changed this on their lists). Hi, i also use sylpheed, no way i would change to anything else. Sylpheed-claws understands the extra headers enough so that it does a reply-to-list by default when you press the reply button. (as im doing now) Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BusyBox] new unarchiving code snapshot
I made a Config option to support only the -x option in dpkg-deb, the overheads of dpkg-deb -x are less than the overheads of ar, so now maybe the debian installer will use dpkg-deb to unpack debs instead of the piped shell command, better to use dpgk-deb to unpack just incase udebs start using [data|control].tar.bz2 (hint hint) http://people.debian.org/~bug1/unarchive2.1.diff.bz2 NOTE: it is a snapshot of a work in progress, some stuff is still broken. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status -- 2002-08-26
On Tue, 27 Aug 2002 18:28:12 +0900 Junichi Uekawa [EMAIL PROTECTED] wrote: On Tue, 27 Aug 2002 02:36:33 +1000 Anthony Towns [EMAIL PROTECTED] wrote: What's going to go on the rootfs? Presumably something like: libc6, busybox-udeb, ash-udeb udpkg, cdebconf, anna *-retriever and any dependencies they have /lib/modules/kernel/** It could be something that reads multiple floppies, or takes things from CD-ROM, for NFS-root (it would be difficult to ask questions) The floppy is too small a place for putting in i18n locale info, and debian-installer, and I think this was the initial intention of d-i being modular. I think the golden rule for bootstraping the installer is that it must be automated and as idiot proof as possible, anything that could require user interaction should be done once the installer starts. Glenn msg21609/pgp0.pgp Description: PGP signature
Re: debian-installer status -- 2002-08-26
On Tue, 27 Aug 2002 02:36:33 +1000 Anthony Towns [EMAIL PROTECTED] wrote: Whether there's any point to all that's another matter. You're only buying yourself a smaller rootfs, and you're only doing it by giving yourself less ways of accessing the first set of udebs you want to install. If that means you can boot from a single floppy disk, rather than a boot-root pair, but only because you then need to insert another couple of floppies to get full versions of libc6 and wget-retriever, that's not a win. There could be a really small initrd that unpacks udebs from the boot medium into a ramdisk. It would make the boot disk simple, just a boot loader, kernel, small initrd and whichever udebs, any filesystem could be used, even fat, no need for rawrite. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please test this woody cd image
On Wed, 10 Apr 2002 10:45:35 -0400 Matt Zimmerman [EMAIL PROTECTED] wrote: On Wed, Apr 10, 2002 at 11:06:44AM +0200, Raphael Hertzog wrote: Hello everybody, release is coming soon ... and we need a bit of feedback about a new feature we plan to use on CD1 of Debian woody for i386. On CD *1*? Surely you don't plan to introduce new features in such a core component mere weeks before the scheduled release? There is no way that it could receive sufficient testing in that time. If we must have a new experimental boot feature, it should go on one of the other CDs in the set. (that said, I see no problem with making the first CD contain fewer packages so that it can fit on a 5cm CD; that sounds useful indeed) Its not the end of the world if a CD doesnt boot via the bios, the user can always boot from a rescue floppy. Glenn msg18796/pgp0.pgp Description: PGP signature
netselect busybox applet
Ive put together a busybox netselect applet, it adds just over 4kB to a standard busybox build, its at http://people.debian.org/~bug1/busybox/netselect.diff It should be able to be used with the netselect-apt shell script to locate a close debian mirror, but i havent tested it yet. I think it should be able to be trimmed down a bit more, but have only put a few hours into it to so far. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0.19-bf2.4 install report
On Sun, 17 Feb 2002 23:53:44 +1300 (NZDT) Philip Charles [EMAIL PROTECTED] wrote: Why not use fping to check the reply speed of all the mirrors, and choose the fastest as the suggested mirror? In my case the closest mirror is probably San Francisco, a mere 10,000 km (6,000 miles) away. My isp's satellite uplink is there. In other words, let people choose their mirrors. Have you tried netselect-apt, i would be interested to know if it doesnt find the best mirror. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
3.0.19-bf2.4 install report
I just installed the 2.4 kernel boot-floppies, went pretty well. The only hitch i encountered was the mbr, after i installed i changed the bios boot drive, then when it tried booting i got L 01 01 01 with 01 constantly repeating... i vagually remember seeing a warning about doing such a thing. I did a net install, i made the boot, root and 4 driver disks but happily discovered the 8139too driver built into kernel, so i only need 2 disks, retrieved everything via the network. I tested out a few things that have caused problems previous. When configuring the network i told it use dhcp even though i dont have a dhcp server, it timed out and went back ot manual configuration as it should. I deliberately typed in the wrong url to start the downloads, i got the Malformed release file that has caused problems in the past, i re-did it wiht the correct url and had no problems. I repartioned using cfdisk, it re-read the partition table and displayed the results in dbootstrap as it should. It would be nice if a more local defualt mirror was provided... there is a low severity bug requesting it, ill have a look at making a netselect busybox applet, a bit late to adding new features to bf, but it would make a handy addition to busybox anyway i think. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0.19-bf2.4 install report
On Sat, 16 Feb 2002 16:23:40 +0100 Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h Glenn McGrath wrote on Sun Feb 17, 2002 um 12:53:55AM: The only hitch i encountered was the mbr, after i installed i changed the bios boot drive, then when it tried booting i got L 01 01 01 with 01 constantly repeating... i vagually remember seeing a warning about doing such a thing. What is your first IDE device, how it is connected? My assumption: it is not /dev/hda but another one, and the real device is mapped by your bios to ide0. For such situation, there is a workaround in the current CVS tree. Yes, your right, i installed to hdb, installed mbr to hdb, rebooted and told the bios to boot from the second disk. It would be nice if a more local defualt mirror was provided... there is a low severity bug requesting it, ill have a look at making a netselect busybox applet, a bit late to adding new features to bf, but it would make a handy addition to busybox anyway i think. I think, the change is minimalistic. Assuming that the language names allways have 2 chars, this quick hack may work. If someone has some spare time, please test and commit: There may be some languages that dont nicely map to mirror names though. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: interesting busybox/udpkg developments
On Fri, 1 Feb 2002 16:50:41 -0500 Joey Hess [EMAIL PROTECTED] wrote: It looks like Sharp's Xarious(sp?) PDA (the one with the neat integrated keyboard) uses busybox dpkg and debian packages. It looks like the deb package format is perhaps winning in the PDA field between this and the use of debs by the two Iapq distros. Putting dpkg into busybox was a nice subversive touch. :-) Excellent, i didnt realise that it was used by them, its also used by another embeded app ive heard of. I dont think its practical to use rpm in these environments because of the database rpm uses to store the metadata. I havent done anything to busybox dpkg/apt-get for about a month, i was making a push towrds busybox apt-get. got something semi-functional, but didnt get dependency checking working properly (again) and memory requirements went up significantly. I started working on it again yesterday. If/when i do get a busybox based retreiver working then it will makes things much simpler for the installer. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problems that adam has got
On 05 Jan 2002 18:12:51 -0500 Adam Di Carlo [EMAIL PROTECTED] wrote: I've got some problems in that I no longer have an i386 build machine at home that works. The crappy laptop I was using for building doesn't seem to exist on the network anymore. I have a machine at work I can use but I can't seem to upload from there to klecker for some bizarre reason. Anyhow, I dunno, if someone else can do test builds for i386 that would be good. I could either put those up at http://people.d.o/~aph or else I can put a readme there on where to get i386 testing builds. Feh, life is just getting harder. I havent built boot-floppies for a fair while, but i have the i386 machine (1.4Gb athlon) to do it, and i have no problems with bandwidth for uploading, so if nobody else wants to do it i will. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch;debian-installer/anna] OBO in malloc computation, whitespace, typedef
* packages.h: typedef package_t
-struct package_t {
+typedef struct package_t {
char *package;
char *filename;
char *md5sum;
int installer_menu_item;
struct package_t *next;
-};
+} package_t;
Actually i think its best to do
typedef struct package_s {
char *package;
char *filename;
char *md5sum;
int installer_menu_item;
struct package_s *next;
} package_t;
in package_s; s is an abriviation for struct so whenever you see
(name)_s you know its a struct in package_t; t is an abreviation for
type so whenever you see (name)_t you know its a type
If _s and _t are mixed up (s used for a type or t used for a struct)
then then it looses all value in representing something.
Its required to define the struct (_s) because *next needs it, and
defining the type (_t) is usefull for refering to it later on instead of
always refering to it as struct package_s
I think one of the reasons people use struct (struct_name) instaed of
just (type_name) is because the difference between the two are sometimes
confused, however if _s and _t are used consistently (and people are
aware thats why its used) then it avoids confusion.
Glenn
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug #120407 : nparted: note for debian-installer
On Wed, 26 Dec 2001 18:29:30 -0700 Chris Tillman [EMAIL PROTECTED] wrote: I have made a package for a requested package : nparted (bug #12047)I am not advocate so I don't know exactly what to do. Do I send a mail [EMAIL PROTECTED] with the url of package ? That would be a good start The package is available at : http://www.speedblue.org/debian/nparted/ I gave it a quick try and got the error invalidate: busy buffer scrolling of the screeen, it makes it unusable for me. I assume its a problem upstream, im using devfs which may be the problem. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug #120407 : nparted: note for debian-installer
On Thu, 27 Dec 2001 12:12:25 +1100 Glenn McGrath [EMAIL PROTECTED] wrote: I gave it a quick try and got the error invalidate: busy buffer scrolling of the screeen, it makes it unusable for me. I assume its a problem upstream, im using devfs which may be the problem. Actually it works from a xterm, but not from console, so maybe its the matrox fb thats causing the problem. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] #118295: rootskel: linuxrc should use tmpfs instead of ramfs
On Tue, 25 Dec 2001 16:42:50 -0800 David Kimdon [EMAIL PROTECTED] wrote: Hi, Any seconds on this one? I definetly think tmpfs should be used isntead of ramfs. tmpfs works better with swap. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#123782: boot-floppies: dbootstrap's wget should use passive ftp
On Wed, 12 Dec 2001 23:09:30 -0600 Mike Coleman [EMAIL PROTECTED] wrote: If I'm reading net-fetch.c correctly, its call to 'wget' doesn't use passive ftp. This will fail for people behind many firewalls. Shouldn't it use --passive-ftp by default? AFAIK, turning it on should (virtually) never cause a problem, and will be a lot better on balance. busybox wget as used by the installer doesnt support the --passive-ftp option, but looking at the busybox wget code it does send the PASV command, so maybe it does it assumes this behaviour. (i didnt look into it very deeply though) Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0.18 plan
On Sat, 8 Dec 2001 19:27:59 -0700 Chris Tillman [EMAIL PROTECTED] wrote: On Sat, Dec 08, 2001 at 04:19:06PM -0500, Adam Di Carlo wrote: FYI, I have i18n powerpc boot-floppies also building if anyone wants to test that.. I fired those up that you put there, and got the flashing screen effect. The boot message just before that started was Freeing kernel memory, I think that's when the root disk gets loaded. Im trying them on i386, i get the first Release notes page by dbootstrap, i press enter to continue the left half of the page changes to what i think is some of the next screen and then goes back to the Release notes page. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: busybox/debootstrap inefficienties (was Re: #103302 ask permission before erasing /var/cache/apt/archives)
On Wed, 21 Nov 2001 01:48:16 -0700 Erik Andersen [EMAIL PROTECTED] wrote: Good work tracking this down. I'll work up a fix and upload a new version ASAP. I was thinking the same thing, looking at the code i found saved some space savings seperate to this stat issue, i checked it into CVS straight away so we duplicate our effort. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: busybox/debootstrap inefficienties (was Re: #103302 ask permission before erasing /var/cache/apt/archives)
On Wed, 21 Nov 2001 03:09:28 -0700 Erik Andersen [EMAIL PROTECTED] wrote: On Wed Nov 21, 2001 at 08:17:21PM +1100, Glenn McGrath wrote: On Wed, 21 Nov 2001 01:48:16 -0700 Erik Andersen [EMAIL PROTECTED] wrote: Good work tracking this down. I'll work up a fix and upload a new version ASAP. I was thinking the same thing, looking at the code i found saved some space savings seperate to this stat issue, i checked it into CVS straight away so we duplicate our effort. Hey, if you are already in there, carry on. I've got plenty to keep me busy if you wanna finish it off, Ok, no worries, nearly done anyway :) Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
teamwork (was Re: #103302 ask permission blah blah)
Lets all remember that we are all on the same team. To work efficiently as a team we have to be able to trust each other to perform our own tasks. If one thinks there own house is in perfect order then by all means help someone else with their workload, if you cant help them dont get in their way. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: teamwork (was Re: #103302 ask permission blah blah)
On Sun, 18 Nov 2001 14:06:27 +1000 Anthony Towns [EMAIL PROTECTED] wrote: On Sat, Nov 17, 2001 at 09:52:07PM -0600, Adam Heath wrote: On Sun, 18 Nov 2001, Glenn McGrath wrote: To work efficiently as a team we have to be able to trust each other to perform our own tasks. How can we trust someone who isn't one of us? Or, to put it in a way that doesn't sound quite so xenophobic, why should we trust someone who refuses to go through our fairly trivial identification process (and thus avoids the accountability it attempts to establish), and who refuses to go through the tasks and philosophy checks to make sure he can actually function as a part of the project? I dont think he would have much chance of getting through the NM process with the enemies hes made, do you ? Why does it matter where a bugfix comes from ? Generally speaking, as long as it fixes a bug and doesnt introduce others it should be accepted. (note i havent looked at this specific bug or patche) Ethan's quite a fan of bug terrorism (continually upgrading or reopening bugs the maintainer disagrees with) and, apparently, NMU terrorism (threatening to either NMU your package, or hacking into your package from another package). Especially the latter isn't something that helps Debian development. I dont agree with these actions, i think its his misguided attempts to improve the packages, if he cannot work with the maintainer/developer then i would encourage him to fork the package and distribute it by alternative means. But hey, politically inspired apoplectic fits is the reason everyone joins Debian, isn't it? I thought we all joined to get involved with endless flamewars (sarcasm) There are lots of good people at debian, however sometimes i cant here them for all the shouting. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: teamwork (was Re: #103302 ask permission blah blah)
On Sun, 18 Nov 2001 16:22:12 +1000 Anthony Towns [EMAIL PROTECTED] wrote: You might want to ask yourself why you're getting involved in this one rather than looking at the bug report and trying to fix the package. Because im trying to make people see that constant infighting isnt productive. I was trying not to get dragged into this particular argument, i would rather focus my efforts on busybox improvements possibly for the post woody installer. I thought it was worth the effort to try and give you some perspective. Ethan will probably disapear and contribute nothing more... he rubbed me the wrong way a couple of times (re: busybox bloat), but i respected him for his passion. If we had been able to get him to work with everyone else then it everyone would be better off, particularly for powerpc. What do you think of the constant infighting that happens here, do you thing its a neccesary evil ? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt behaviour with satellite
On Sat, 10 Nov 2001 19:32:16 -0500 John Davidson [EMAIL PROTECTED] wrote: Apt now behaves like wget when installing woody using the rieserfs 3.0.15 bootfloppies. This means that it no longer works with my one-way satellite connection. Prior to the releease of 3.0.14 bootfloppies this was not a problem and I would regularly get 40KB speeds. Now I get less than 2KB??! Things improve to about 3.5KB when I use my modem without satellite. This is the exact performance I get with wget. Has apt been changed since mid-Aug?? If so I will report a critical bug. Why would the speed vary per client ? If your uing the same protocol (be that http or ftp) then it shouldnt make any difference which client you use. debootstrap uses wget to install base, apt-get is a bit big for boot floppies Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status
On Tue, 23 Oct 2001 12:54:11 +0200 KORN Andras [EMAIL PROTECTED] wrote: On Sun, Oct 21, 2001 at 01:24:08AM +1000, Glenn McGrath wrote: It turns out that even if you compile with devfs, there are places where the old style device names are still used (/proc/partitions i think was what anoyed me), for me this ruined devfs's elegence. Ummm... I couldn't find anything under /proc that referenced old device names. This is a 2.4.10-ac7 kernel (but I don't think the stock kernel references old names either). I remember now its the file and directory names for ide devices. bug1@scooby:/root$ ls -l /proc/ide total 0 -r--r--r--1 root root0 Oct 24 01:04 drivers lrwxrwxrwx1 root root8 Oct 24 01:04 hda - ide0/hda lrwxrwxrwx1 root root8 Oct 24 01:04 hdc - ide1/hdc lrwxrwxrwx1 root root8 Oct 24 01:04 hdd - ide1/hdd dr-xr-xr-x3 root root0 Oct 24 01:04 ide0 dr-xr-xr-x4 root root0 Oct 24 01:04 ide1 Whats the point in refering to hda etc when device hda doesnt exist. It mightnt be much but its enough to require mapping in userland between the two drivername types if you want to analyse how linux detected storage devices Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Woody install report
On 21 Oct 2001 11:45:47 +0200 Falk Hueffner [EMAIL PROTECTED] wrote: Ethan Benson [EMAIL PROTECTED] writes: (3) in the post-boot configuration, why are MD5 passwords defaulted to No ie not enabled ? compatibility with crufty old unixes i suppose. if you were to make the box into an NIS server that would matter i think. Somebody who wants that will know to what to answer. People who don't know what this is all about will want MD5 passwords, so this should be the default. Yea i agree, MD5 is a lot more secure. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Malformed release file in woody 2.0.15
A friend is installing 2.0.15, trying to install woody gives an error Malformed release file in url, tried ftp.au.debian.org and the default mirror, gave the same error. Installing unstable got past this error. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status
On 20 Oct 2001 09:36:14 +0200 Stefan Nobis [EMAIL PROTECTED] wrote: Ethan Benson [EMAIL PROTECTED] writes: On Thu, Oct 18, 2001 at 06:50:42PM -0700, Rob Bos wrote: - /dev is 3k bigger How practical would it be to compile devfs and include devfsd in the bootfloppies? the real installed system should not use devfs nor require it. Why not? There are only advantages, so where do you see the problem? Everything that is possible to do with the old system is also possible with devfs, but devfs has some nice new features like only showing you those entries that really exists, no more need of that really braindead device-numering system etc. I like devfs because it _should_ be much cleaner, but IMHO it needs more time to mature (if time will help). A while back i experimented with a program that scanned various /proc files to get an idea of what storage devices are available. It turns out that even if you compile with devfs, there are places where the old style device names are still used (/proc/partitions i think was what anoyed me), for me this ruined devfs's elegence. I mentioned it on the linux kernel mailing list but nobody seemed to think it was an issue... i dont understand why they would want it like it is. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Malformed release file in woody 2.0.15
On Sat, 20 Oct 2001 18:32:21 +1000 Glenn McGrath [EMAIL PROTECTED] wrote: A friend is installing 2.0.15, trying to install woody gives an error Malformed release file in url, tried ftp.au.debian.org and the default mirror, gave the same error. Installing unstable got past this error. err.. 3.0.15 i meant, and it was debootstrap giving that error. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mount_partition() and filesystem types
On Thu, 18 Oct 2001 00:25:37 -0800 Ethan Benson [EMAIL PROTECTED] wrote: On Wed, Oct 17, 2001 at 09:32:07PM -0600, Erik Andersen wrote: On Wed Oct 17, 2001 at 02:55:11PM -0800, Ethan Benson wrote: but as i have stated, even if you fix busybox to be smarter you still have a giant stack of wildcards in all these random filesystems in the kernel, are they going to behave sanly when told to mount a partition not containing thier fstype? or will they fuckup and kill the kernel? If that happens, then it's Al Viro's problem, i don't care whose problem it is, when the problem breaks boot-floppies assigning blame is not something im concerned with, fixing the problem is. Problems should be reported upstream where apropriate, not to assign blame, but so the upstream author knows about it and can fix it for all users of that piece of software Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] busybox-udeb increased size
On Thu, 18 Oct 2001 21:06:30 -0400 Joey Hess [EMAIL PROTECTED] wrote: Between this spring and now, busybox-udeb has grown in size by some 52k. Since the d-i system is too big to fit on a floppy right now, we badly need to trim this back. There is some duplication of code with tar in the stable branch. The untar code used by the dpkg and dpkg-deb applets is different than the code used by the tar applet. This was necessary to move all the unarchive applets to a common codebase. It adds about 5kB to busybox, there is a new version of busybox tar in the unstable branch of cvs that remove the code duplication but its in unstable for a reason. The currrent ar applet is bigger than the old ar applet as it drags in all the common unarchive code which has more option than ar itself needs, but enough to handle tars needs. The good news is that that the combined the tar and ar from unstable should be smaller than any other busybox versions, and once the common unarchiving code is used everything else is cheap, e.g dpkg-deb adds 2.4kB Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status
On Fri, 19 Oct 2001 00:45:38 -0400 Joey Hess [EMAIL PROTECTED] wrote: 107548: /sbin/dhclient 18472: /sbin/udhcpc As much as i like dhclient, it is big. udhcp client is packaged as udhcpc its homepagepage is at http://opensource.lineo.com/udhcp/ Failing to obtain an IP is a showstopper, so its something that would require thorough testing, but udhcp looks l ike its actively being developed, something to keep an eye on at least. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: b-f 3.0.14 and the Hurd.
On 17 Oct 2001 20:10:29 -0400 Adam Di Carlo [EMAIL PROTECTED] wrote: I am trying to keep running parallel to b-f and debian-cd versions as they emerge so that the Hurd and Linux versions can be merged when the time comes. Since you guys aren't planning on releasing with Woody, might I suggest you put some effort towards working through the debian-installer? Hopefully it's flexible enough to do what you want. Probably the biggest problem at the moment for debian-installer on the Hurd is getting busybox to build nicely. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
install report 3.0.14-2001-09-23
Hi I successfully installed using the standard flavour of 3.0.14 on a k6-2, its looking good. I partitioned with cfdisk, installed the kernel modules then did a network install. A couple of minor points. 1. Just after the kernel boots screens of text flashed by, which i assume case the following message to apear twice in another window. runaway modprobe loop assumed and stopped 2. The extended partition created using cfdisk appears under view partition table as type System V, which is incorrect. 3. debootstrap failed three times, i restarted it and it continued downloading from where it stopped, i usually dont drop connections, so im not sure, but maybe its a problem with the down program debootsrap uses (is it busybox wget ?) 4. After debootstrap finished the background screen wasnt refreshed and seemed to contain bits of messages from an old screen. As i said these are all minor, and didnt cause me any problems. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: build failure on ia32
On Tue, 4 Sep 2001 18:48:13 -0600 Erik Andersen [EMAIL PROTECTED] wrote: Well, since we have to mount the target fs, we already have to pay most of the price for ext2 anyways (the size of mkfs.ext2 and the size of the kernel ext2 code). So switching to minixfs isn't going to save us all that much. If we are going to bother with changing filesystems, IMHO only cramfs really makes sense. Redhat switched their installer to using cramfs and apparently gained quite a lot of space that way... Cramfs compresses each fs block individually, if compressing a big image or tarfile due to the fact that it is bigger than a fs block it will get better compression. An alternative to cramfs is to use romfs for the initrd, compresses it with gzip -9 and uncompress to tmpfs (or ramfs), but its a tradeoff, you would save disk space due to better compression and smaller kernel, and it would be faster from memmory, but it would also use a lot more memory which could be a critical factor. Personally i think cramfs is the best solution for lowmem installs and romfs.gz/tmpfs is best for normal installs. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: busybox bloat
On Sun, 2 Sep 2001 00:04:22 -0800 Ethan Benson [EMAIL PROTECTED] wrote: The root disk is currently too bloated, on pmac and chrp its already too large to fit on a 1.44MB floppy. looking at busybox there is plenty of bloat that can be removed, i was able to bring /bin/busybox (current 0.61-1) down from 200792 bytes to 153088, a nearly 47k decrease. If we use busybox dpkg-deb instead of ar and tar it will reduce busybox by about 6.5kB (by my calculations), one of the reasons being that most of the busybox unarchiving applets have been reorganised, however tar hasnt been, currently busybox dpkg-deb uses seperate untar'ing code to the tar applet. I have a patch somewhere to integrate tar with the common code the unarchiving applets use, but it had still needed further testing and i got distracted and havent looked at it further. There are no known bugs with busybox dpkg-deb, it should be stable. Some space could be saved by using the busybox ash shell as well, its had the math routines put back in, and its been getting lots of attention from busybox developers. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: busybox bloat
On Mon, 3 Sep 2001 06:37:20 +1000 Glenn McGrath [EMAIL PROTECTED] wrote: If we use busybox dpkg-deb instead of ar and tar it will reduce busybox by about 6.5kB (by my calculations), My caclulations were wrong, it will only save 3.5kB, still i think its better to use dpkg-deb as it should make the scripts a fraction simpler as well. hmm, if base is coming from the big tarball and not debs that we will need tar around anyway :( Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
library optimiser
Motavista GPL'ed their library optimiser, looks like it doesnt the equivalent of mklibs.sh, i dont know how the results compare though. http://libraryopt.sourceforge.net/ Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 3.0.9-ide modconf debootstrap probs
On 23 Aug 2001 21:25:52 -0400 Adam Di Carlo [EMAIL PROTECTED] wrote: Glenn [EMAIL PROTECTED] writes: I installed the kernel and modules from floppy, things looked to be going ok, then i tried to configure the modules, it looked like it was trying to insert modules from the wrong directory, the top line had a list of dirs etc, var, usr, things got crazy for a while here, i couldnt get out of the modconf menus, i saw no space left on device a couple of times, after killing processes from the console i managed to regain control. You ran out of space during the install kernel and modules step? Or else something went nuts and used up all your disk space? I inserted my network card module from the console and continued at the configure the network device menu. Yes, if you can still reproduce this in 3.0.12, and it's not just disk full problems, then you should file a bug agianst boot-floppies. Please include the /var/log/messages file too. The _main_ Packages.gz file is a valid gzip file acording to gunzip -t, so im thinking that debootstrap.invalid_* isnt the intended filename. Thats the stage im currently at, ill send a follow up after i finish the install and setup fetchmail. Probably fixed in the more recent boot-floppies, there were wget problems. Sorry, i meant to look deeper into these problems post install, but i didnt get around to it, i will have a go at installing 3.0.12 Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
busybox dpkg rewrite
There are a few known bugs noted at the top of the file, so treat this with caution, but it should be starting to be useable. Its a drop in replacement to the existing dpkg.c in busybox cvs. http://people.debian.org/~bug1/busybox_patches/dpkg.c.0712a.bb If anyone is into hashtables and hashing algorithms id like some feedback on the way ive done it, i havent used them for a practicle purpose pefore. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [BusyBox] Shells
Vladimir N. Oleynik wrote: Erik Andersen wrote: On Tue Jul 03, 2001 at 02:17:06PM -0400, David Douthitt wrote: I've followed the discussion (somewhat) on different shells. I'm wondering what the difference is, and in particular, is ash going to absorbed into busybox or what? What are the differences between: * ash * hush * lash Any others I missed? (probably...) In cvs we currently have lash, hush, msh, ash. For all size comparisons below, I am leaving BB_FEATURE_COMMAND_EDITING disabled. Enabling it will add about 8k to the size of each shell. lash: very small (adds just 10k) and quite usable as a command prompt, but it is not suitable for any but the most trivial scripting since it does not understand Bourne shell grammer. It does handle pipes, redirects, and job control though. Adding in command editing makes it quite nice as a command prompt. hush: Also quite small (just 18k) and it has very complete Bourne shell grammer. It handles if/then/else/fi just fine, but doesn't handle loops like for/do/done or case/esac and such. It also currently has a problem with job control. msh: The minix shell (adds just 30k) is quite complete and handles things like for/do/done, case/esac and all the things you expect a Bourne shell to do. It is not always pedantically correct about Bourne shell grammer (try running the shell testscript, tests/sh.testcases, on it and compare vs bash), but for most things it works quite well. It also uses only vfork, so it can be used on uClinux systems. I just added this, so there is still room to shrink it further... ash: This adds about 60k in the default configuration (I need to review vodz' latest update, perhaps he has made it smaller again) and is the most complete and most correct shell included with busybox. This was also recently added, and both Vladimir and I have been working on it. There are a number of configurable things at the top of ash.c as well. The Posix math stuff is currently disabled, but I intend to fix it up when I get some time. Both msh and ash were very recently added to CVS, and so neither of these shells supports the STANDALONE_SHELL option yet. So if busybox ash had math support would it be a posix compatable shell, or would there be other issues as well ? The root disk of debian boot floppies has ash from the deb (which is 85kB) as opposed to ash from busybox, which from current CVS adds 67kB. boot floppies expects a posix compatable shell for various scripts, debootstrap being one of them. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
upgrading to a premade kernel after installing with 3.0.7
I installed testing yesterday. tasksel was a problem, but thats been discussed i think. The *major* problem i had was upgrading to pre-built 2.4.5 kernel post install, when i first installed 2.4.5 i was told to edit /etc/kernel-img.conf (that didnt exist yet) and add a line Do_initrd = Yes (is it case sensitive?), after the kernel package finished installing i found the file and edited it. When i rebooted the kernel couldnt find the root device i dunno what i wants as the root device, the real root device, or the initrd. Sure its not a boot-floppies thing, but it something that needs to be fixed, if i could work out what going on i would write a bug report. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: upgrading to a premade kernel after installing with 3.0.7
Matt Zimmerman wrote: On Wed, Jul 04, 2001 at 07:32:39PM +1000, Glenn McGrath wrote: I installed testing yesterday. tasksel was a problem, but thats been discussed i think. The *major* problem i had was upgrading to pre-built 2.4.5 kernel post install, when i first installed 2.4.5 i was told to edit /etc/kernel-img.conf (that didnt exist yet) and add a line Do_initrd = Yes (is it case sensitive?), after the kernel package finished installing i found the file and edited it. When i rebooted the kernel couldnt find the root device i dunno what i wants as the root device, the real root device, or the initrd. That's not exactly what you were told to do. The message said to fix your bootloader so that it would boot the initrd kernel, THEN change /etc/kernel-img.conf to get rid of the warning message. In the case of LILO, this means adding an initrd= line to the proper stanza in /etc/lilo.conf. This happened because the packaged 2.2 kernels don't use an initrd, while the packaged 2.4 kernels do. If you follow the instructions, everything works OK. Fair enough, i just added the initrd= line and its fine, but still, im sure lots of people will make the mistake i did. Maybe it should be in the documentation that comes with prebuilt kernels, i was looking through the package scripts for hints, but got sick of that pretty quick. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installer online help
David Whedon wrote: The nice things i see about this is that the messages have a chance of being maintained if put into busybox cvs. The problem is that they are separated from the people who actually want the messages to exist (Debian), though not too far, since busybox is pretty Debian friendly (already has a dpkg applet :-) ) b.t.w at people.debian.org/~bug1 i have a patch against the current cvs version of busybox that changes ar, untar, dpkg-deb and dpkg and their underlying function in libbb. I havent commited yet because im a bit unsure of a few things and havent had much feedback. The dpkg in the patch is pretty much a rewrite, all it can do is install a package that doesnt already exist, it doesnt have any dependency code in it yet which is really needed to do other stuff properly. The existing dpkg applet tries to do more but i think could break in a number of circumstances. So which is better ? I am pretty happy with dpkg-deb now in terms of its size and functionality. Also i have made an untar applet which is a cheaper alternative to the proper busybox tar applet which i am unsure about commiting. Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
