On Thu, 2008-08-28 at 00:29 +0100, chgans wrote: > Hi all, > > OK, this is not a bug report, but it's time to go to bed now! I really would prefer bug reports simply because it helps me show that the changes Emdebian will need to make in Debian after the Lenny release are being made due to real user problems - i.e. things will be a lot easier for me with an "audit trail" of bug reports (which are far easier to track than mailing list posts). For this reason, individual problems need also to be separated into individual bug reports. Whilst we are waiting for the pseudo-package, those bugs need to be filed against emdebian-tools with a wishlist or minor severity - I'll organise the tags and re-assigns later. > I prefer > to send an email on the list to avoid to forget everything, as I'll be > out of the office until Monday (This follows discussion on IRC). OK, even if I fix most of these things by then, I'd still like bug reports that I can track whilst in Extremadura. Thanks. > * /etc/rc.d/udev-mtab use "grep --quiet --no-messages", which > busybox's grep doesn't understand, should use "grep -q -s" > TESTED: OK This is part of the reasoning - there may well be cases where we can either change the busybox config or make patches for inclusion into busybox upstream to enable the few extra bytes that allows busybox to understand that --quiet == -q. This is a much more sustainable fix than patching the Debian package or expecting every Debian package to switch to short options. Bug reports will help me optimise the busybox config so that the majority of users are happy whilst providing clear guidance on what options people need to retain in their customised builds of busybox for devices that need that. Mailing list posts just get lost in the archive, bug reports show up on all my tracking pages and can be reorganised quickly and repeatedly, as appropriate. > * mountoverflowtmp: df -kP | grep -v Filesystem => df -k | grep -v > Filesystem > Not sure about the impact of not using -P (posix compatibility) > The only difference with -P on a debian machine is the header of > the output, which is ignore by the script via the grep -v > TESTED: OK Another situation where there might be a need to fix the Debian package to not be so picky - then, in consultation with the maintainer, we can work out whether -P is used for some ports (maybe hurd-i386 or kfreebsd-amd64 etc.) or just out of habit. > * when installing ssh client and server > /var/lib/dpkg/info/openssh-server.postinst: line 453: perl: not found > /var/lib/dpkg/info/openssh-client.postinst: line 51: syntax error: "}" > unexpected That is a bug in emdebian-tools - lintian should have caught that. Please report it, including the full lintian report from using: $ lintian -iIC em /path/to/.changes > Then i tried to make some changes to update-rc.d, i've attached the > file, there are some comments in the header about why and how i did > that (it's just an idea, experimental stuff). update-rc.d can be replaced using machine-variant support during testing. There are five ways of modifying files in the root filesystem (in order of the point at which the change is actioned): modified suite script - if you want to drop / reorder certain components of the debootstrap process beyond simply changing the package selection. Requires some familiarity with debootstrap processes. packages.conf - to add packages, mirrors or proxies, rename the tarball, specify the kernel image/modules location, etc. $machine-config - bespoke package if the change needs to replace the default Emdebian files or simply to collate changes for similar devices. (Possibly using the PROXY or MIRROR settings of packages.conf). Certain default files may already exist but package files will be used instead of the default files as long as the files exist in the package (i.e. listed in dpkg -c foo.deb). Maintainer scripts in the -config package are processed as normal by ./emsecondstage. Files generated from -config maintainer scripts might need to replace the Emdebian default file. Overall, this is the easiest method. setup.sh - if the change is first needed before creating the rootfs tarball (i.e. before running ./emsecondstage) and can be done from the build machine (binaries within the rootfs cannot be executed). This is where you can replace any file that is called by the maintainer scripts, e.g. update-rc.d because packages have been unpacked but are not yet configured. config.sh - if the change is only needed before the first boot (after ./emsecondstage) or if the change needs to be made by running binaries within the rootfs. config.sh can assume that all packages are fully configured on the target device before it is called and it can assume that it is running on the target device (albeit within a chroot). config.sh is provided to support modifying the results of running the maintainer scripts, should things go wrong, or other tasks necessary prior to the first boot and is the only method that can execute binaries on the target device. > Actually i tried to rely as much as possible on the debian init > scripts, i would like to use only this in my inittab: > # /etc/inittab > # Note: BusyBox init doesn't support runlevels. > > # Start-up the system > ::sysinit:/etc/init.d/rcS start > # Put a getty on the console > ttyAM0::respawn:/sbin/getty -L ttyAM0 115200 vt100 > # Stuff to do before rebooting > ::shutdown:/etc/init.d/rcS stop You can do so either by writing this in setup.sh or (if you have a few changes to make) by packaging the file in a package - as we do with balloon3-config. If you use a local repository with emsandbox, put the package into that repository and add the name of that package to your packages.conf INCLUDE and the repository to PROXY or MIRROR. (MIRROR will be used as the default apt source for the device after installation, PROXY is temporary.) If you want the -config package to be included in Emdebian, it would need to be sufficiently generic (or have suitable maintainer scripts) to cope with most (if not all) variants of the machine in question and then be called $machine-config. As with any other package, it needs to be compliant with Debian Policy and the DFSG (and then built in Emdebian to comply with Emdebian Policy). This means making the source package (.dsc) available so that I can use 'apt-get source' to cross-build it. Most -config packages will be Architecture: all but will still be cross-built to remove docs etc. In reality, most -config packages will only be usable on one specific architecture or a few related architectures (like arm and armel). If anyone fancies integrating some of that into the Wiki . . . . -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part