Bug#857345: jessie-pu: package debootstrap/1.0.72
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu The fix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757819 needs to be available in jessie to solve problems with using --foreign with any Stretch bootstrap operation. Would this be possible to do as an upload to proposed-updates and would this fix be acceptable for the next Jessie point release? -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#793119: Debian Installer doesn't let me configure locale en_US + time zone UTC
On Tue, 21 Jul 2015 21:17:55 +0800 Alexander List wrote: > Package: debian-installer > Version: 20150718 > Severity: normal > Tags: d-i > > I just tried to setup a dev VM using this netinst ISO: > > debian-testing-amd64-netinst.iso 2015-07-21 12:30 245M > > I *assume* it's version 20150718 as that predates the daily build by 3 > days and has been migrated to testing according to tracker.d.o. > > The problem: > > I am in a multinational, multi-language environment spread across the > globe, where by convention servers are configured to en_US, timezone > UTC. We use US keyboards no matter where on the planet we are. > > In earlier versions of d-i, there was a menu to select the time zone, > and hitting "End" would get me to Etc/Utc which was at the bottom of > the list. > > Now, in d-i, I select > > Language: English > Country: United States > Keymap: American English > > Then I enter the root password, user, username, password, and then > have to configure the clock. > > The only options I have are Eastern, Central, Mountain, ... Samoa. > > Does that seriously mean people who configure a locale other than C in > their system cannot set the clock to use UTC in d-i? > > Sounds like a rather severe limitation to me, and it's not obvious how > to work around it but to fix it post installation ... > > And yes, I invested 15min googling the problem and didn't find an > answer. > > FWIW, this difference also appears in Ubuntu 15.10 daily builds, > where I noticed it first (15.04 doesn't have the problem). Today I > reproduced it in Debian. > > Let me know if I can help. > > Alex > You need to change the debconf priority from the default of High to Medium or Low. Note: this will then cause other steps to ask questions you would not see in priority High. This can also be reached from the boot menu as Advanced Options -> Expert install. This setting may also be possible to access using a preseed file with something like: d-i time/zone choice UTC e.g. in configure clock, you'll see Set the clock using NTP? then Select your timezone. This will offer the default as the zone appropriate for your choice of language and locale, with the additional option of UTC. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp9SoSE1aVvG.pgp Description: OpenPGP digital signature
Bug#801392: debian-installer: xkb-keymap select us
retitle 801392 debian-installer: preseed failure with xkb-keymap select us thanks On Fri, 09 Oct 2015 10:46:01 -0300 Eliseu Passos wrote: > Package: debian-installer > Severity: normal > > Dear Maintainer, > > I tried this option too: d-i console-keymaps-at/keymap select us > In the preseed file I have this line: d-i > keyboard-configuraion/xkb-keymap select us, I've tried lots of others > options, but the debian installer always ask me to choose the keymap > to use even if I have it setted on the preseed file. I'm using Debian > Jessie. From my stand point its a bug, because I search a lot trying > to solve this problem whithout success. Excuse me if I'm doig > something wrong. This example preseed file may help: http://images.validation.linaro.org/kvm/debian-8.3.0-cd1-preseed.cfg It can also help to put debian-installer/locale=en_US on the kernel command line. For a full example, see https://staging.validation.linaro.org/scheduler/job/151426/complete_log?debug=on or https://staging.validation.linaro.org/scheduler/job/152407#bottom > > -- System Information: > Debian Release: 8.2 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: i386 (i686) > > Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) > Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpivLYSGZPuZ.pgp Description: OpenPGP digital signature
Bug#826189: debian-installer: unable to set up advanced network connections from installer
severity 826189 wishlist tag 826189 + moreinfo thanks On Fri, 03 Jun 2016 01:06:36 -0400 nick wrote: > Package: debian-installer > Version: 20160516+b1 > Severity: normal > > Dear Maintainer, > > I cannot find a way to do anything other than enter WEP/WPA2 > passwords and SSIDs. Specifically I would like to be able to connect > to networks with PEAP authentication from the installer, but this is > not currently possible as far as I can tell. I would like for us to > basically be able to do anything from the installer that we can do > from the network-manager application. > It is unlikely that the installer will ever have comparable levels of support to the final running system, if only due to the dependencies of an installed application and the lack of available support during the operation of the installer. It's a corner case that is unlikely to meet the needs of more than a handful of users. Are you trying to use this authentication to operate the installer or simply to configure in the installed image automatically? If you simply need to configure the system after install (e.g. you could use a DVD image to provide the packages to install and setup the network mirror later) then it should be easy to create a script/package which does this step once the system is fully/mostly installed. One other way to do this would be to do a secondary install - deploy the system with a ramdisk or NFS or similar which would be able to make the network connection and then do a manual install onto the media, e.g. using debootstrap. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpMFPQkoAECN.pgp Description: OpenPGP digital signature
Bug#782305: Merging
tag 782305 +wontfix thanks There is an existing bug on this topic: #550962: kbd-chooser: please let Bépo keyboard layout available when choosing kbd layout related to: https://wiki.debian.org/DebianInstaller/ConsoleLayout One of the problems with debian-installer is that it aggregates other components, so this bug can't be merged with 550962 without losing visibility of either in the respective components. Assigning the same tag as 550962. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpwTM3UT9q9p.pgp Description: OpenPGP digital signature
Bug#782305: Merging
forcemerge 550962 782305 thanks Merging with the existing bug on this topic: kbd-chooser: please let Bépo keyboard layout available when choosing kbd layout related to: https://wiki.debian.org/DebianInstaller/ConsoleLayout -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpuHAzYb7afb.pgp Description: OpenPGP digital signature
Bug#780118: Unable to install to Plain machine
tag 780118 + moreinfo
thanks
On Mon, 9 Mar 2015 13:31:05 + Robert de Bath
wrote:
> Package: debian-installer
>
>
> This changed over the weekend without any change to the
> 'debian-installer' code itself. It was working on Friday.
>
> I GUESS the problem will be related to packages that are downloaded
> during the early part of the install; probably partman-auto.
>
> Problem:
> I'm installing using the current AMD64 netboot installer.
> Sha1sum:
> 6c27efd31f462b0954ea7ca5983ca01f633b8afa netboot.tar.gz
>
> The disk is wiped and has no partitions. During install I selected
> "Guided disk" and "Everything in one partition".
>
> The installer creates the partitions and formats the ext4 root
> partition. But is unable to mount the partition for installation of
> the base system.
>
> Rebooting and trying again does not help. There is no option to "just
> use the existing ext4 partition as root" and redoing the partitions
> leaves me still unable to install.
>
> If I do an "sfdisk -R /dev/sda" on the "ALT-F2" console it claims
> that the Drive is in use and will not refresh the partition table.
>
> This looks pretty release critical to me :-(
>
Apologies for the delay in responding to this but there is a lack of
information in the report to be able to identify the problem.
Have you tried to reproduce this since filing the report?
How was the install run - netinst/CD/DVD, architecture, stable or
testing, version, what kind of machine? ('Plain' doesn't mean a lot.)
Numerous other tests and installs have successfully happened since the
bug report, so there is presumably something about how this test was
done which triggered the problem.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpnRuMxDbdOZ.pgp
Description: OpenPGP digital signature
Bug#780811: debian-installer: Netinst throws error when MATE is selected in "Software, selection"
retitle 780811 separate /home partition too small for MATE on small systems thanks On Sat, 21 Mar 2015 00:11:08 +0100 Christian MOMON wrote: > Le 19/03/2015 19:55, Cyril Brulebois a écrit : > > Hi, > > [...] > > It looks like 3.6GB is too small for both Gnome and MATE. If > > installing with Gnome then MATE once rebooted into the installed > > system works, I suspect that's because of the cache directory > > holding downloaded packages: holding both desktops' .deb and > > installing takes too much space compared to installing one after > > the other. > > Using the ctrl-alt-F4 shell when error occured: > > # df -h /target/. > FilesystemSizeUsedAvailable > Use% Mounted on /dev/sda13.3G > 3.3G 0 100%/target > > > # (lot of commands because "du" is not available in Busybox...): > > 724 092 158 bytes for /target/var/cache/apt/archives/* > 73 783 868 bytes for /target/var/cache/apt/archives/*mate* > > I used the default partition action with "home separated". As my disk > has 12GB, the default partition action create a target '/' partition > of only 3.3GB. > > Why 3.3GB? > Why not more? > What is the definition of default size for '/'? > What is the method of calculation for this value? > Is there technical constraints? > Where is the file of debian-installer with the calculation? > > > I restarted the same operations with a '/' partition of 10GB and no > issue occured. So, it confirms your diagnostic. > > > > I'm afraid there's little we can do in d-i for that. > > At first, I thought it affected everyone using MATE. But in fact, if > only small disks are concerned then this is less urgent. > > In a first step, a solution could be to expand the label message in > the "Software selection" input window. I suggest something like that > (better english is required): > > "If you select all the packages, pay attention to have a size greater > than xGB for the '/' partition. Set a value too small will cause an > error in next step installation." > > Perhaps a label change is runnable in d-i. The separate /home partition and other "recipes" for partitioning are generic for a whole range of different installations and there will always be corner cases and problems with particular combinations. There is no perfect answer. At the point where the partitioning is calculated, package selection has not been made and it is perfectly reasonable that 3.6G would be enough for a standard system (i.e. a system without a desktop). There is no way, during the install, to estimate the final installation size of a particular taskset with any degree of accuracy. The range of tasks available for install is too wide to anticipate what the limit should be and the MATE task is by no means "all" the packages available. Using Guided partitioning to use the entire disk instead of selecting a separate /home partition is the simplest option to ensure that the install works on small systems. Alternatively, you can manually tweaking the size but it is always a risk when choosing to use automatic partitioning recipes that the final system just doesn't work, especially for small systems. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgphOyi0zYDs3.pgp Description: OpenPGP digital signature
Bug#777526: debian-installer: when installing xfce system only, quodlibet installed and gstreamer pulse module not
reassign 777526 quodlibet retitle 777526 redundant dependency on gstreamer1.0-audiosink which is provided by gstreamer1.0-plugins-good found 777526 3.6.2-1 thanks On Mon, 09 Feb 2015 02:52:26 -0600 Joseph Lenox wrote: > Package: debian-installer > Version: 8.0 > Severity: important > > Dear Maintainer, > > After installing a fresh Jessie install, I tried to start quodlibet > and noticed that I was getting no sound. I traced this to the > gstreamer plugin for pulseaudio not being installed. While quodlibet > does not necessarily pull this package in (as it's only necessary > when pulseaudio is installed and that isn't always the case), I > suspect it should be added to the package install list for the xfce > desktop environment, as gstreamer and quod libet are included. > > I was able to resolve my problem by installing > gstreamer1.0-pulseaudio. > > I expected the necessary packages to be installed without having to > go hunting for it myself. quodlibet gets installed by task-xfce-desktop and quodlibet depends on gstreamer1.0-pulseaudio | gstreamer1.0-audiosink. quodlibet also depends on gstreamer1.0-plugins-good which Provides: gstreamer1.0-audiosink. Therefore, the | gstreamer1.0-audiosink part of the dependency duplicates the existing dependency on gstreamer1.0-plugins-good. Depends: python (>= 2.7.3-4+deb7u1), exfalso (= 3.2.2-1), gir1.2-gstreamer-1.0, gir1.2-gst-plugins-base-1.0, gstreamer1.0-plugins-base, gstreamer1.0-plugins-good, gstreamer1.0-plugins-ugly, gstreamer1.0-pulseaudio | gstreamer1.0-audiosink $ apt-cache show gstreamer1.0-plugins-good|grep Provides Provides: gstreamer1.0-audiosink, gstreamer1.0-audiosource, gstreamer1.0-videosink, gstreamer1.0-videosource, gstreamer1.0-visualization quodlibet should have: Depends: gstreamer1.0-plugins-good, gstreamer1.0-pulseaudio or Depends: gstreamer1.0-plugins-good Recommends: gstreamer1.0-pulseaudio or Depends: gstreamer1.0-plugins-good | gstreamer1.0-pulseaudio This bug is still present in unstable, quodlibet 3.6.2-1. > > > -- System Information: > Debian Release: 8.0 > APT prefers testing-updates > APT policy: (500, 'testing-updates'), (500, 'testing'), (1, > 'experimental') Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpFWok_7cGcl.pgp Description: OpenPGP digital signature
Re: Providing (armhf) u-boot images together with d-i images?
On Wed, 3 Dec 2014 23:09:17 +0100
Karsten Merker wrote:
> several armhf systems do not have u-boot (or another firmware) in
> non-volatile (i.e. ROM/Flash) memory, but instead store their
> system firmware on a removable medium such as an SD card. In
> many cases the user does not receive a suitable firmware medium
> when buying the hardware, because the vendors often expect these
> devices to be used with pre-built android images. This means
> that a user who has freshly bought such a system and wants to
> install Debian on it, has to first find and install an appropriate
> u-boot image to be able to start d-i.
vmdebootstrap can create a suitable image although it isn't actually
the installer. There is an example script for beaglebone-black and if
someone has the knowledge of the u-boot setup for particular boards,
that can be added to the examples.
This gets around the problem of needing armhf setup first, via qemu.
> Debian provides appropriate u-boot images for several supported
> systems in the u-boot-{exynos,imx,omap,sunxi} packages, but those
> are not easily accessible to somebody who does not already run a
> Debian/armhf system (or at least Debian on another architecture),
There's also a lack of documentation of exactly how to use the u-boot
files for some boards and get to a working uboot.
> so I am wondering whether we should offer these u-boot images
> (in unpacked form) together with the d-i images, similar to what
> we do with the device-tree files extracted from the linux-image
> package.
The modules.tgz would also be handy...
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpp1B9A5S0K6.pgp
Description: OpenPGP digital signature
Re: Wheezy release: CDs are not big enough any more...
On Wed, 16 May 2012 07:53:55 -0300 Ben Armstrong wrote: > On 05/16/2012 06:10 AM, Timo Juhani Lindfors wrote: > > Bjørn Mork writes: > >> No, you don't. On a default Debian system you need to be a member of > >> the "floppy" group. From /lib/udev/rules.d/91-permissions.rules : > > > > Yeah but you are not a member of that group by default surely? > > $ debconf-show user-setup ... that listing isn't available on Squeeze ... If we're to document this, it would need to be as-per Squeeze. > passwd/user-default-groups: audio cdrom dip floppy video plugdev > netdev powerdev scanner bluetooth floppy is in my `groups` on Squeeze (scanner is not but the rest on the list above are). dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth dialout and sudo explicitly added, rest are the defaults IIRC. > At least the initial user created by user-setup at install time will be > in this group. That would cover everyone with self-administrated > systems, which I would hazard a guess would be most of our audience. So > while we can't assume every user has access, we could at least recommend > in the doc that the command be executed as an ordinary user "where > possible" to avoid accidental harm. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpZ8LdChvbJN.pgp Description: PGP signature
Re: Wheezy release: CDs are not big enough any more...
On Sun, 13 May 2012 18:36:09 -0400 Michael Gilbert wrote: > On Sat, May 12, 2012 at 12:04 PM, Steve McIntyre wrote: > > Hey folks, > > > > Remembering the fun that we had during the Squeeze release with trying > > to make single-CD installations work well, it's time to consider what > > we're going to *claim* to support in Wheezy. We've had a history of > > supporting the following single-CD installations: > > > > * Gnome desktop from CD#1 > > * KDE desktop from "KDE CD#1" > > * XFCE desktop from "light CD#1" > > * LXDE desktop from "light CD#1" > > * base system only from netinst CD > > > > At this point, I'm skeptical that either of the first two are going to > > work acceptably with Wheezy. If that's the case, then we should warn > > people that they will need to use at least one of: > > > > * more CDs > > * a DVD > > * a network mirror > > > > to get a useful/useable installation. > > What about supporting only the smaller/lighter desktop environments > (maybe even making one of the the default environment)? Then there > wouldn't be the need for multiple CD #1's. Anyone that wants > gnome/kde after installation will need to grab those from the mirrors > (or use DVD or greater media). "supporting only the smaller/lighter desktop environments" is exactly what comes out of accepting that the first two options just won't be acceptable. Changing compression is only putting off the inevitable. There's *no* reason to think that GNOME or KDE are going to get back below the 1 CD limit at the next Debian stable release. I'd support XFCE4 as the default Graphical Desktop Environment and possibly putting GNOME (and KDE) as alternative options. That way, GNOME and KDE (as explicit options) should only show up in the list if using a medium which can provide that amount of packages. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpStDpe97dbs.pgp Description: PGP signature
Bug#654317: Needs creation of /usr/share/man/man1
On Tue, 13 Mar 2012 17:58:38 + Colin Watson wrote: > On Mon, Mar 12, 2012 at 01:08:26AM -0400, Joey Hess wrote: > > Neil Williams wrote: > > > Emdebian doesn't include manpages and some packages (and some udebs > > > apparently) don't expect this directory to not exist. > > > > I'd be very surprised if any udebs know anything at all about > > /usr/share/man. > > > > However, there are numerous postinsts, starting with bash, that run > > update-alternatives on files in /usr/share/man/, which is likely to > > not work well if the directory is missing. I was thinking of creating a new udeb, especially for Emdebian, which provides this support and possibly other side-effects. We already have 'grip-config' which currently only provides a tasksel list which is optimised for the limited package set provided in Emdebian Grip. grip-config could be introduced into Debian and gain a udeb at that point. > Maybe Emdebian should just exclude the files but not the containing > directories? It doesn't seem that this should require any particular > installer support. That would require reprocessing thousands of packages - it certainly isn't possible to reprocess them all (especially for the stable release). Overall, Debian Installer is not the typical way of installing Emdebian (or Debian) on embedded devices. (Even this bug report came from a test on amd64 which is not a typical embedded architecture.) There remain problems with using Debian Installer with Emdebian even when this directory is handled - the main one is picking which kernels to include in Emdebian. Kernels are a significant issue with D-I for embedded - vanilla Debian kernels (and desktop-kernel-package requirements) are really not appropriate for most embedded uses - the list of modules alone needs a lot of customisation to not use up all the space saved by using Emdebian Grip. I think a single purpose udeb could be the simplest way to ease the use of D-I for test installations based on Emdebian Grip. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpmB2049Fiw9.pgp Description: PGP signature
Bug#654317: Needs creation of /usr/share/man/man1
On Sun, 11 Mar 2012 14:25:20 -0300 Otavio Salvador wrote: > On Sun, Mar 11, 2012 at 10:22, Neil Williams wrote: > > Once it fails, get to the install menu and select "Execute a shell" > > then create a single directory: > > > > mkdir /target/usr/share/man/man1 > > > > Then exit the shell and continue the installation. > > Can you paste the syslog of the installation so we can try to figure > which one depends on it? It's an Emdebian-specific problem, commonly dash because it's one of the first preinst scripts run (if not the first). Normally, in Debian, this won't happen because dash contains files in /usr/share/man/man1 but these files are removed for Emdebian. What I'm considering is that the existing grip-config package used in Emdebian gets introduced into Debian and provides a udeb to create this directory. It does seem like overkill though. (Currently, grip-config just provides a few optimised tasksel tasks which take the reduced package set of Emdebian Grip into account). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpjnEqJdaLni.pgp Description: PGP signature
Bug#654317: Needs creation of /usr/share/man/man1
clone 654317 -1 reassign -1 buildd.emdebian.org retitle -1 Debian installer needs /usr/share/man/man1 created quit Once it fails, get to the install menu and select "Execute a shell" then create a single directory: mkdir /target/usr/share/man/man1 Then exit the shell and continue the installation. It might be possible for Debian installer to gain a bit of support for this. Emdebian doesn't include manpages and some packages (and some udebs apparently) don't expect this directory to not exist. The installer images are experimental, notably various kernel packages are missing because most Emdebian devices need specialised or customised kernels. The most useful place to discuss issues like this is the debian-embed...@lists.debian.org mailing list, so I've cloned this bug to buildd.emdebian.org which goes to that list. I was able to proceed without a kernel (virtual box test), then the network mirror needs to be specified manually as: mirror hostname: www.emdebian.org, Debian archive mirror directory: /grip HTH -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpmWUUaS4OiO.pgp Description: PGP signature
Re: differences in busybox configurations, part1 (longish)
On Wed, 16 Feb 2011 21:15:57 + Otavio Salvador wrote: > On Wed, Feb 16, 2011 at 21:06, Neil Williams > wrote: ... > > I cannot recommend any embedded system should use any version of > > busybox built by Debian for d-i without *also* installing and using > > coreutils, login, passwd, shadow, perl and all the rest. i.e. > > busybox from Debian is only suitable for what Debian normally does > > with busybox > > - which explicitly does *not* include handling passwords, shadow or > > otherwise. > > Please take a look on this thread: > http://lists.debian.org/debian-boot/2011/02/msg00471.html > > Basically we're going to revamp busybox and busybox-static > configuration (d-i one is not going to be changed too much) and then > we wish to try to be more "friendly" to this kind of use-cases. As I'm sure you're aware, busybox is not one package, it's 50 or more - and that's just counting the common variations in source configuration, not counting the variations of C library used. > Doing the proposed changes I guess we fit this gab. Only in the static model, which explains why the binary is so large. Emdebian Crush shipped with a binary of ~700kb but that was a much older version. Embedded users who want a static version are probably going to want a static version linked against uClibc and with no coreutils, login, passwd etc. installed and all symlinks enabled. I don't see how Debian can even test such a configuration, let alone recommend it for widespread usage. I think the best option is for d-i to simply keep up with busybox releases. (Current stable is 1.18.3, Debian has 1.17.1, even with bubulle's update since Squeeze.) That is, itself, a signficant challenge for a busy and overworked team like d-i and has proved to be an unreachable target before - especially once a release process starts up and the rest of d-i needs so much testing. Busybox needs to freeze early, that's entirely understandable. The "standard" build won't be (ever) able to install the symlinks which actually make busybox useful for embedded devices. (It can be hard to run something on device to create the symlinks when the device cannot boot because the symlinks don't exist.) The only real solution would be a fourth build with the symlinks enabled but which conflicts with dpkg, coreutils, login, passwd and numerous other utilities. I tried to make this fourth build available just for a single architecture via cross-building - it is a lot of work. This doesn't even start to handle the more common instance where the device needs a customised busybox configuration in the first place. It's a bigger problem than kernels because users who want busybox want busybox because there isn't room on the system for anything else and every 10kb less in /bin/busybox makes it worth reconfiguring and rebuilding it. Trying to be friendly is a good thing - adding work for the d-i team which still means that busybox needs to be reconfigured and rebuilt for actual embedded devices anyway isn't being friendly - either to the rest of the d-i team or the embedded users. > Most important: what's the usage for the static build? Umm, exactly - not much IMHO. In the opinion of the dpkg maintainers, around the time of the Lenny freeze, a system which replaces coreutils, dpkg and passwd is "not Debian any more". In the opinion of many embedded developers, a system with a full size busybox *and* coreutils, dpkg and the rest is simply wasting precious space. I don't want to be overly negative over this, I'm just trying to ensure that a commendable desire to be friendly does not actually result in wasting time within the d-i team and then turn out to not be useful to embedded users. IMHO, the best thing d-i can do is to ensure that Debian stays as close to the current busybox stable release as possible. Updating to current upstream stable as soon as possible after the release is done and ensuring it is again updated before the next freeze takes hold. That's a minimum of only two updates per release cycle, but updates which go directly to latest upstream stable. It will necessarily slip during all release freezes but that one commitment may well be enough. Rebuilding from a Debian source package with adjusted configuration is a lot more friendly than using wget on busybox.net. Keep the deb and udeb configuration exactly as d-i requires - maybe even drop the static version if d-i doesn't use it. Just keep the package up to date and it will make embedded use a lot simpler than trying to mangle together some incomplete, broken configuration which isn't directly usable. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgprrywdQGAKp.pgp Description: PGP signature
Re: differences in busybox configurations, part1 (longish)
On Wed, 16 Feb 2011 20:55:13 + Otavio Salvador wrote: > On Wed, Feb 16, 2011 at 20:44, Hector Oron > wrote: ... > > Crush development has been postponed until multiarch is ready but > > some of the bits for the proof of concept can be found at emdebian > > svn [0]. > ... > > What should we do? Just "sync" static with deb and later work on that? > Seems like a more logical way for now at least. Each embedded installation may benefit from a slightly tweaked busybox from the busybox upstream default. All embedded installations of busybox are likely to benefit from a busybox built against a configuration completely unlike anything useful in standard Debian. For Emdebian Crush, I stuck to a busybox config which was fairly close to the standard default busybox configuration and nothing like the Debian config. I don't think there is a way of providing a single configuration of busybox which is both ideal for d-i and friendly to embedded systems. I cannot recommend any embedded system should use any version of busybox built by Debian for d-i without *also* installing and using coreutils, login, passwd, shadow, perl and all the rest. i.e. busybox from Debian is only suitable for what Debian normally does with busybox - which explicitly does *not* include handling passwords, shadow or otherwise. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpasXOgQEtp9.pgp Description: PGP signature
Re: Bug#466857: udhcp: long term mass bug filing for cross build support
On Sun, 16 Jan 2011 19:34:39 +0100 Luca Capello wrote: > > In line with the other cross-building support bugs: > > http://lists.debian.org/debian-devel/2007/11/msg00116.html > > > > This patch is necessary to allow udhcp to cross-build in Debian. > > I guess this bug should be merged with #465290, but I leave the last > word to Neil ;-) Merged. Thanks for the reminder, Luca. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpMsCi6tcTlC.pgp Description: PGP signature
Bug#480899: reopen
reopen 480899
retitle 480899 incomplete split prevents installation of cdebconf-gtk
severity serious
thanks
> cdebconf needs a package split (or possibly more than one) so that the
> gtk+ frontend is optional, along with it's dependencies.
The package split has happened but the default package still depends on
GTK+ as it still contains the gtk frontend which needs to be optional
to allow use of cdebconf within a buildd chroot.
cdebconf_0.143_amd64.deb
new debian package, version 2.0.
size 173292 bytes: control archive= 1477 bytes.
19 bytes, 1 lines conffiles
797 bytes,15 lines control
1935 bytes,28 lines md5sums
Package: cdebconf
Version: 0.143
Architecture: amd64
Maintainer: Debian Install System Team
Installed-Size: 512
Depends: libatk1.0-0 (>= 1.20.0), libc6, libcairo2 (>= 1.6.4-6.1),
libdebian-installer4 (>= 0.63), libfontconfig1 (>= 2.4.0), libfreetype6
(>= 2.2.1), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 2.8.0),
libnewt0.52, libpango1.0-0 (>= 1.14.0), libslang2 (>= 2.0.7-1),
libtextwrap1, debconf
66992 2009-07-06 13:19 ./usr/lib/cdebconf/frontend/gtk.so
29424 2009-07-06 13:19 ./usr/lib/cdebconf/frontend/newt.so
19424 2009-07-06 13:19 ./usr/lib/cdebconf/frontend/text.so
libglib2.0-0, libcairo2, libfontconfig1, libfreetype6, libgtk2.0-0 and
libatk1.0-0 are all unwanted for a debconf replacement. Currently,
cdebconf-gtk cannot be installed alongside cdebconf anyway
because ./usr/lib/cdebconf/frontend/gtk.so exists in both and Replaces
is not used (hence the bump in severity). (libglib2.0-0 itself isn't
that bad though, overall, as pkg-config and gettext both use it.)
Version: 0.143+nmu1
Architecture: amd64
Maintainer: Debian Install System Team
Installed-Size: 428
Depends: libc6, libdebian-installer4 (>= 0.63), libnewt0.52, libslang2 (>=
2.0.7-1), libtextwrap1, debconf
Recommends: cdebconf-gtk
The replacement cdebconf.install file is:
deb/etc/* etc
deb/usr/lib/cdebconf/debconf-copydb usr/lib/cdebconf
deb/usr/lib/cdebconf/debconf-loadtemplate usr/lib/cdebconf
deb/usr/lib/cdebconf/dpkg-reconfigure usr/lib/cdebconf
deb/usr/lib/cdebconf/debconf-communicate usr/lib/cdebconf
deb/usr/lib/cdebconf/db/* usr/lib/cdebconf/db
deb/usr/lib/cdebconf/debconf usr/lib/cdebconf/
deb/usr/lib/cdebconf/frontend/newt.so usr/lib/cdebconf/frontend
deb/usr/lib/cdebconf/frontend/text.so usr/lib/cdebconf/frontend
deb/usr/lib/cdebconf/libdebconf.so usr/lib/cdebconf
deb/usr/lib/cdebconf/debconf-dumpdb usr/lib/cdebconf
deb/usr/share usr
$ debdiff ../cdebconf_0.143_amd64.deb ../cdebconf_0.143+nmu1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/lib/cdebconf/frontend/gtk.so
Control files: lines which differ (wdiff format)
Depends: [-libatk1.0-0 (>= 1.20.0),-] libc6, [-libcairo2 (>= 1.6.4-6.1),-]
libdebian-installer4 (>= 0.63), [-libfontconfig1 (>= 2.4.0), libfreetype6 (>=
2.2.1), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 2.8.0),-] libnewt0.52,
[-libpango1.0-0 (>= 1.14.0),-] libslang2 (>= 2.0.7-1), libtextwrap1, debconf
Installed-Size: [-512-] {+440+}
Version: [-0.143-] {+0.143+nmu1+}
Patch attached.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
diff -Nru cdebconf-0.143/debian/cdebconf.install cdebconf-0.143+nmu1/debian/cdebconf.install
--- cdebconf-0.143/debian/cdebconf.install 2006-01-27 01:59:05.0 +
+++ cdebconf-0.143+nmu1/debian/cdebconf.install 2009-07-06 13:40:51.0 +0100
@@ -1,3 +1,12 @@
deb/etc/* etc
-deb/usr/lib/cdebconf usr/lib
+deb/usr/lib/cdebconf/debconf-copydb usr/lib/cdebconf
+deb/usr/lib/cdebconf/debconf-loadtemplate usr/lib/cdebconf
+deb/usr/lib/cdebconf/dpkg-reconfigure usr/lib/cdebconf
+deb/usr/lib/cdebconf/debconf-communicate usr/lib/cdebconf
+deb/usr/lib/cdebconf/db/* usr/lib/cdebconf/db
+deb/usr/lib/cdebconf/debconf usr/lib/cdebconf/
+deb/usr/lib/cdebconf/frontend/newt.so usr/lib/cdebconf/frontend
+deb/usr/lib/cdebconf/frontend/text.so usr/lib/cdebconf/frontend
+deb/usr/lib/cdebconf/libdebconf.so usr/lib/cdebconf
+deb/usr/lib/cdebconf/debconf-dumpdb usr/lib/cdebconf
deb/usr/share usr
diff -Nru cdebconf-0.143/debian/changelog cdebconf-0.143+nmu1/debian/changelog
--- cdebconf-0.143/debian/changelog 2009-07-02 14:32:28.0 +0100
+++ cdebconf-0.143+nmu1/debian/changelog 2009-07-06 13:27:52.0 +0100
@@ -1,3 +1,10 @@
+cdebconf (0.143+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Drop gtk frontend from default cdebconf package (Closes: #480899)
+
+ -- Neil Williams Mon, 06 Jul 2009 13:27:27 +0100
+
cdebconf (0.143) unstable; urgency=low
[ Otavio Salvador ]
pgpJOHabJ6Yg9.pgp
Description: PGP signature
Re: strap1: an alternative to debootstrap
e useful - although it is imperative that emsandbox works with foreign packages. Whether multistrap is useful for -boot I have no idea - probably the reliance on a working apt setup would be problematic, however as that is only required on the build system, it could still be of some use. I'm not sure whether -boot actually need multiple repository support though - comments from -boot? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp1et8I4kqUI.pgp Description: PGP signature
Bug#517114: more info
retitle 517114 please enable the prompt to enter preseeding url severity 517114 normal thanks After more testing and a few chats on IRC, the aim of this bug report is actually to re-enable the prompt so that when Automatic Install is selected without editing the boot command line, the user is prompted for the url of the pre-seeding file. This is a far more convenient way to use pre-seeding, especially for distributions like Emdebian Grip where pre-seeding is essential to allow d-i to adapt to Emdebian modifications. It was present in the daily builds before rc2 but was, apparently, dropped from the final release code due to a regression related to DHCP. It would be a significant enhancement to Emdebian if the prompt could be reinstated for Debian 5.0.1. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpFm7cOTdtej.pgp Description: PGP signature
Emdebian and D-I keys
(Note: I'm not subscribed to debian-boot so please CC me.) Emdebian now has two flavours - Emdebian Crush is the very small distro that involves all the cross-building and other changes, that isn't the issue here. Emdebian Grip is a new flavour that is *binary compatible* with standard Debian but throws out all manpages, documentation and other "low hanging fruit" as well as converting all translation support in Debian packages into Emdebian TDebs. Emdebian Grip is about 25% smaller than standard Debian for the same package set. In Emdebian Grip, no compiled binary file is modified, the source package is not modified and the .dsc retains the original signature. However, the shrinkage of the .deb files themselves means that the Packages data changes. Emdebian Grip is available for 7 architectures (Crush only for one) and I will be making a synchronised release of Emdebian Crush and Emdebian Grip alongside Lenny. Emdebian 1.0 (in either flavour) is a developer-only release - think Debian buzz or Slackware 1.0. It'll mostly work but there are likely to be emdebian-specific bugs. Emdebian Grip is hosted in the Emdebian repository: http://www.emdebian.org/grip/index.html http://www.emdebian.org/grip/dists/ http://www.emdebian.org/grip/pool/ The repository uses edos-debcheck to ensure that all dependencies are met but only provides a limited number of packages (currently enough to run XFCE). I'll be adding testing fairly soon. It should be trivial to use the Emdebian Grip repository with any Lenny d-i image, merely by selecting the mirror. However, no-one in Emdebian has access to the secret key for the debian-archive-keyring keys, so we've created our own emdebian-archive-keyring, signed by Wookey and myself. d-i (via debootstrap) now complains that it cannot verify the repository and I'd like to explore ways that we can fix this *for Lenny*. AFAICT, everything else in d-i would either "just work" or be easily fixable. I do have a possible emdebian-archive-keyring-udeb package, based on debian-archive-keyring-udeb. What are the options here? I don't think it's possible to add the Emdebian key to debian-archive-keyring - buildd.emdebian.org is not maintained by DSA. Is it possible to add emdebian-archive-keyring-udeb to d-i? (I can arrange an upload to unstable to make that package available, albeit with a delay getting through NEW.) I'd rather not have to rebuild all d-i images for Emdebian merely to add a single public key. (I do have some preseeding config that will make the repository available by default.) Is there something I've missed that makes it easier to supply the key some other way? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgppbAHyXbPz8.pgp Description: PGP signature
Bug#502244: LANGUAGE=se:nb:no:nn:da:sv ?
This bug has been around for 2 weeks without comment, I'm just trying to understand what is going on. The mechanism in the title is certainly how fallback is meant to be activated and I can't see anything in the cdebconf C source code that would change that. I don't do much with D-I so I can only think that something is wrong with the environment: [EMAIL PROTECTED]:~# LANGUAGE=se:nb:no:nn:da:sv /usr/lib/cdebconf/dpkg-reconfigure dpkg-cross Obsolete command TITLE Default cross-build architecture selection called Default cross-build architecture selection -- Om den här maskinen typiskt används för att bygga för en huvudarkitektur, kan du välja den arkitekturen här för att slippa ange den igen när du kör dpkg-cross, apt-cross eller emdebian-tools. Välj 'Ingen' för att inte ha något standardval. Standardarkitektur för krossbyggnation: 1. Ingen [*] 3. amd64 5. armeb 7. hppa 9. ia64 11. mips 13. powerpc 15. sparc 2. alpha 4. arm6. armel 8. i386 10. m68k 12. mipsel 14. s390 Prompt: '?' for help, default=1> [EMAIL PROTECTED]:~# LANGUAGE=se:nb:no:nn:da /usr/lib/cdebconf/dpkg-reconfigure dpkg-cross Obsolete command TITLE Default cross-build architecture selection called Default cross-build architecture selection -- If this machine is typically cross-building for one main architecture, you can select that architecture here to save specifying it again when running dpkg-cross, apt-cross or emdebian-tools. Select 'None' to have no default. Default cross-building architecture: 1. None [*] 3. amd64 5. armeb 7. hppa 9. ia64 11. mips 13. powerpc 15. sparc 2. alpha 4. arm6. armel 8. i386 10. m68k 12. mipsel 14. s390 Prompt: '?' for help, default=1> So fallback does appear to work in this respect - sv gets chosen as the only language supported by this particular package. [EMAIL PROTECTED]:~# ls /opt/working/dpkg-cross/debian/po/ cs.po CVS de.po fr.po it.po ja.po ka.po nl.po POTFILES.in pt.po ru.po sv.po templates.pot uk.po Testing with those languages shows that the fallback mechanism does work - at least outside D-I. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpzU45eDBPjx.pgp Description: PGP signature
Bug#484700: New options in busybox 1.11.2
This is the list of options that require new configuration values in the config.deb from 1.10.2 to 1.11.2: Assume that 1:1 char/glyph correspondence is not true (FEATURE_ASSUME_UNICODE) [N/y/?] (NEW) exec prefers applets (FEATURE_PREFER_APPLETS) [N/y/?] (NEW) Cross Compiler prefix (CROSS_COMPILER_PREFIX) [] (NEW) Support infiniband HW (FEATURE_HWIB) [Y/n/?] (NEW) Support for archive creation (FEATURE_CPIO_O) [N/y/?] (NEW) Use internal DES and MD5 crypt functions (USE_BB_CRYPT) [Y/n/?] (NEW) depmod (DEPMOD) [N/y/?] (NEW) Support priority option -p (FEATURE_SWAPON_PRI) [N/y/?] (NEW) fbsplash (FBSPLASH) [N/y/?] (NEW) inotifyd (INOTIFYD) [N/y/?] (NEW) last (LAST) [Y/n/?] y Choose last implementation > 1. small (FEATURE_LAST_SMALL) (NEW) 2. huge (FEATURE_LAST_FANCY) (NEW) choice[1-2]: 1 man (MAN) [N/y/?] (NEW) bash-compatible extensions (ASH_BASH_COMPAT) [Y/n/?] (NEW) Builtin version of 'printf' (ASH_BUILTIN_PRINTF) [Y/n/?] (NEW) Build BusyBox as a position independent executable (PIE) [N/y/?] (NEW) So far, Emdebian is taking the defaults for these options but our testing is far from exhaustive. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#480899: cdebconf: Needs a package split for gtk frontend to allow installation without X
Package: cdebconf Version: 0.130 Severity: normal In order for cdebconf to replace debconf, cdebconf would need to be installable in a basic Debian environment where gtk+ would be unavailable. Installing cdebconf instead of debconf in such a situation brings in intolerable numbers of dependencies, even if the gtk+ frontend is not going to be used (e.g. on a buildd or chroot). cdebconf needs a package split (or possibly more than one) so that the gtk+ frontend is optional, along with it's dependencies. This would produce: Versions of packages cdebconf depends on: ii libc62.7-11 GNU C Library: Shared libraries ii libdebian-installer4 0.58Library of common debian-installer ii libnewt0.52 0.52.2-11.2 Not Erik's Windowing Toolkit - tex ii libtextwrap1 0.1-6 text-wrapping library with i18n - Much better for a genuine debconf replacement. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cdebconf depends on: ii libatk1.0-0 1.22.0-1The ATK accessibility toolkit ii libc62.7-11 GNU C Library: Shared libraries ii libcairo21.6.4-1+b1 The Cairo 2D vector graphics libra ii libdebian-installer4 0.58Library of common debian-installer pn libdirectfb-0.9-25 (no description available) ii libglib2.0-0 2.16.3-2The GLib library of C routines ii libgtk-directfb-2.0-02.12.9-4The GTK+ graphical user interface ii libgtk2.0-0 2.12.9-4The GTK+ graphical user interface ii libnewt0.52 0.52.2-11.2 Not Erik's Windowing Toolkit - tex ii libpango1.0-01.20.2-2Layout and rendering of internatio ii libtextwrap1 0.1-6 text-wrapping library with i18n - cdebconf recommends no packages. signature.asc Description: Digital signature
Bug#465290: busybox: long term mass bug filing for cross build support
Package: busybox Version: 1:1.1.3-5 Severity: wishlist Tags: patch User: [EMAIL PROTECTED] Usertags: crossbuilt In line with the other cross-building support bugs: http://lists.debian.org/debian-devel/2007/11/msg00116.html This patch is necessary to allow busybox to cross-build in Debian, following the recommendation in autotools-dev. *** ../crossbuild.diff --- busybox-1.1.3.debian/debian/rules +++ busybox-1.1.3.emdebian/debian/rules @@ -6,6 +6,15 @@ DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU) DEB_HOST_ARCH_OS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) + +DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +DEB_BUILD_GNU_TYPE=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) +CC=$(DEB_HOST_GNU_TYPE)-gcc +MAKE += -e +else +CC=gcc +endif VERSION = $(shell dpkg-parsechangelog | grep ^Version: | cut -d ' ' -f 2) EXTRA_VERSION = Debian $(VERSION) @@ -45,8 +54,8 @@ @rm -rf $(DIR) mkdir $(DIR) cp '$(CONFIG)' $(DIR)/.config - $(MAKE) O=$(CURDIR)/$(DIR) oldconfig - $(MAKE) -C $(CURDIR)/$(DIR) + CC=$(CC) $(MAKE) O=$(CURDIR)/$(DIR) oldconfig + CC=$(CC) $(MAKE) -C $(CURDIR)/$(DIR) cp $(DIR)/docs/BusyBox.1 $(DIR)/docs/busybox.1 touch $@ -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages busybox depends on: ii libc6 2.7-6 GNU C Library: Shared libraries busybox recommends no packages. -- no debconf information signature.asc Description: Digital signature
Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot
On Tue, 16 Oct 2007 14:21:37 -0400 Joey Hess <[EMAIL PROTECTED]> wrote: > Neil Williams wrote: > > OK. I've done the doclifter thing and updated the XML, generated a new > > manpage and compared it with the old. I'm assuming you don't want the > > build-dependency on docbook-xsl so I've included a patch to create a > > README that documents how to use xsltproc to generate the manpage. > > (Note that the man page *diff* is larger than the entire XML file!) > > Please don't ship files in the source that can be generated at build time. Normally, I'd agree. In this case, I feel it is up to the maintainer to decide whether to add a build dependency. Especially as it is my complete inability to edit groff that led to the use of XML in the first place. :-) > And finally, isn't just vi $manpage easier than all this? Umm, no. I cannot edit groff - it makes about as much sense to me as lisp or haskell. I stick to what I know, C, Perl, XML and autotools. I just can't see the point of learning groff, just as I'd never try to deal with bugs in python or C#. Plus, the use of doclifter and xsltproc (using a stylesheet from docbook-xsl) makes for a better looking manpage than I could ever hope to achieve with vi. YMMV. > Index: debootstrap.8 > === > --- debootstrap.8 (revision 49792) > +++ debootstrap.8 (working copy) > @@ -92,6 +92,10 @@ > Complete the bootstrapping process. Other arguments are generally not > needed. > .IP > +.IP "\fB\-\-second\-stage\-tarball DIR\fP" > +Run second stage in a subdirectory instead of root. (can be used to create > +a foreign chroot) (requires --second-stage) > +.IP > .IP "\fB\-\-keep\-debootstrap\-dir\fP" > Don't delete the /debootstrap directory in the target after completing the > installation. > -- > see shy jo Sorry, Joey, I know you understand groff but I don't. I have no idea where to start with all those \f commands. All my manpages are built from XML using docbook-xsl as a build-depends. Normally, I wouldn't have touched the manpage for this bug but Otavio asked me to provide a patch and the XML process was acceptable to him because it could make it easier for him to update the manpage too, so that's what I have done. Otavio: It's up to you if you want to dump README.diff and implement that xsltproc rule in the build, adding docbook-xsl to build-depends in the process. It's relatively painless and the best way overall, IMHO. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpT7lmaKTIth.pgp Description: PGP signature
Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot
On Tue, 16 Oct 2007 14:21:37 -0400 Joey Hess <[EMAIL PROTECTED]> wrote: > Neil Williams wrote: > > OK. I've done the doclifter thing and updated the XML, generated a new > > manpage and compared it with the old. I'm assuming you don't want the > > build-dependency on docbook-xsl so I've included a patch to create a > > README that documents how to use xsltproc to generate the manpage. > > (Note that the man page *diff* is larger than the entire XML file!) > > Please don't ship files in the source that can be generated at build time. Normally, I'd agree. In this case, I feel it is up to the maintainer to decide whether to add a build dependency. Especially as it is my complete inability to edit groff that led to the use of XML in the first place. :-) > And finally, isn't just vi $manpage easier than all this? Umm, no. I cannot edit groff - it makes about as much sense to me as lisp or haskell. I stick to what I know, C, Perl, XML and autotools. I just can't see the point of learning groff, just as I'd never try to deal with bugs in python or C#. Plus, the use of doclifter and xsltproc (using a stylesheet from docbook-xsl) makes for a better looking manpage than I could ever hope to achieve with vi. YMMV. > Index: debootstrap.8 > === > --- debootstrap.8 (revision 49792) > +++ debootstrap.8 (working copy) > @@ -92,6 +92,10 @@ > Complete the bootstrapping process. Other arguments are generally not > needed. > .IP > +.IP "\fB\-\-second\-stage\-tarball DIR\fP" > +Run second stage in a subdirectory instead of root. (can be used to create > +a foreign chroot) (requires --second-stage) > +.IP > .IP "\fB\-\-keep\-debootstrap\-dir\fP" > Don't delete the /debootstrap directory in the target after completing the > installation. > -- > see shy jo Sorry, Joey, I know you understand groff but I don't. I have no idea where to start with all those \f commands. All my manpages are built from XML using docbook-xsl as a build-depends. Normally, I wouldn't have touched the manpage for this bug but Otavio asked me to provide a patch and the XML process was acceptable to him because it could make it easier for him to update the manpage too, so that's what I have done. Otavio: It's up to you if you want to dump README.diff and implement that xsltproc rule in the build, adding docbook-xsl to build-depends in the process. It's relatively painless and the best way overall, IMHO. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgplzkRovAHsI.pgp Description: PGP signature
Bug#326243: Emdebian fix
Emdebian needs to use busybox in place of quite a few packages (Emdebian is ditching "Essential:" along the way) and this bug caused quite a few problems. I've attached the interdiff that shows how to avoid this problem by using the existing busybox install script. applets/install.sh needs one tweak (commenting out three lines) so I've copied it to debian/ and made the changes there. busybox.links is a generated file that needs to be packaged for install.sh to operate. e.g. in Emdebian, I'm working with running: cp ./usr/share/busybox/busybox.links . cp ./usr/share/busybox/install.sh . ./install.sh . --symlinks rm busybox.links rm install.sh (run in the top level directory of what will become the chroot) There are other changes necessary to allow the Debian busybox package to cross-compile. The full patches are in Emdebian SVN: http://buildd.emdebian.org/svn/browser/current/target/trunk/b/busybox/trunk In particular: http://buildd.emdebian.org/svn/browser/current/target/trunk/b/busybox/trunk/emdebian-rules.patch +DEB_HOST_GNU_TYPE=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +DEB_BUILD_GNU_TYPE=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE)) +CC=$(DEB_HOST_GNU_TYPE)-gcc +MAKE += -e +else +CC=gcc +endif + @rm -rf $(DIR) mkdir $(DIR) cp '$(CONFIG)' $(DIR)/.config - $(MAKE) O=$(CURDIR)/$(DIR) oldconfig - $(MAKE) -C $(CURDIR)/$(DIR) + CC=$(CC) $(MAKE) O=$(CURDIR)/$(DIR) oldconfig + CC=$(CC) $(MAKE) -C $(CURDIR)/$(DIR) cp $(DIR)/docs/BusyBox.1 $(DIR)/docs/busybox.1 touch $@ More testing needed but these changes are likely to be filed as a separate cross-build bug in due course. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgptG7A51eZgt.pgp Description: PGP signature
Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot
On Tue, 16 Oct 2007 14:36:04 -0200 Otavio Salvador <[EMAIL PROTECTED]> wrote: > >> Could you update the manpage? So we can commit it. > > > > Is the lack of a manpage update going to block the bug? > > I don't indent to commit it before someone does it or I find the time > to do that myself. If we start to accept those changes without > properly documenting them we'll end with a bunch of undocumented > options and personally I think we all wouldn't like to see it > happening ;-) Come to think of it, --second-stage isn't in the current debootstrap --help message at all, only the man page. > > I would normally use doclifter if this was a package that I was > > maintaining - storing the XML in the package source and using > > docbook-xsl to update it prior to building the package to prevent a > > build dependency. However, using doclifter means that the diff to the > > original manpage is quite large and is not limited to the new text, it > > can also change (for the better usually) the appearance of certain > > parts of the manpage (headers generally). > > Personally I do not object for a more "readable" source format for > manpage and I doubt someone else will do too so if you can provide the > patch for it, I'd commit it without problem :-) OK. I've done the doclifter thing and updated the XML, generated a new manpage and compared it with the old. I'm assuming you don't want the build-dependency on docbook-xsl so I've included a patch to create a README that documents how to use xsltproc to generate the manpage. (Note that the man page *diff* is larger than the entire XML file!) > Please, try to provide the patch and I'll try to handle it as soon as > possible. Four patches attached. debootstrap.diff - the actual change to close this bug. README.diff - create a small README that doesn't have to be packaged with the binaries, only included in the source. debootstrap.8.xml.diff - creates the XML, generated from doclifter and including changes to cover the new option related to this bug. debootstrap.8.diff - probably unnecessary but demonstrates the level of changes incurred through doclifter that made it impossible to submit those as a patch to the man page itself. You probably don't want to apply that. There shouldn't be any need to change the contents of debian/* as neither of the new files need to be part of the debootstrap installation, only the source. I'm not sure how you create the source for debootstrap - presumably some form of RCS-dependent foo-buildpackage. I'm assuming that any file present in RCS will be included in the debootstrap_1.0.4.tar.gz so that is where I would expect to find README and debootstrap.8.xml in case of future changes. Please review the manpage changes - I think it makes for a slightly better manpage due to the whitespace and bold improvements. YMMV. HTH. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ --- debootstrap.old/debootstrap +++ debootstrap-1.0.3/debootstrap @@ -87,7 +87,10 @@ --unpack-tarball T acquire .debs from a tarball instead of http --make-tarball T download .debs and create a tarball (tgz format) - + --second-stage-target DIR + Run second stage in a subdirectory instead of root + (can be used to create a foreign chroot) + (requires --second-stage) --boot-floppiesused for internal purposes by boot-floppies --debian-installer used for internal purposes by debian-installer EOF @@ -142,6 +145,18 @@ SECOND_STAGE_ONLY=true shift ;; +--second-stage-target) + if [ "$SECOND_STAGE_ONLY" = "true" ] ; then + if [ -n "$2" ] ; then +CHROOTDIR="$2" +shift 2 + else +error 1 NEEDARG "option requires an argument: %s" "$1" + fi +else +error 1 NEEDARG "%s only applies in the second stage" "$1" +fi + ;; --print-debs) WHAT_TO_DO="finddebs printdebs kill_target" shift @@ -242,7 +257,11 @@ VARIANT=$(cat $DEBOOTSTRAP_DIR/variant) SUPPORTED_VARIANTS="$VARIANT" fi - TARGET=/ + if [ "$CHROOTDIR" = "" ]; then +TARGET=/ + else +TARGET=$CHROOTDIR + fi SCRIPT=$DEBOOTSTRAP_DIR/suite-script else if [ "$1" = "" -o "$2" = "" ]; then --- /dev/null 2007-10-02 23:46:34.736041737 +0100 +++ debootstrap-1.0.3/README 2007-10-16 18:08:07.0 +0100 @@ -0,0 +1,9 @@ +DEBOOTSTRAP MAN PAGE GENERATION +===
Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot
On Sat, 06 Oct 2007 15:33:43 -0300 Otavio Salvador <[EMAIL PROTECTED]> wrote: > >> I wasn't sure what name to use for the command line option and I'm not > >> sure about how the patch results in: > > > > Maybe: --second-stage-target looks clearer. > > Could you update the manpage? So we can commit it. Is the lack of a manpage update going to block the bug? How is the debootstrap manpage normally updated? I would normally use doclifter if this was a package that I was maintaining - storing the XML in the package source and using docbook-xsl to update it prior to building the package to prevent a build dependency. However, using doclifter means that the diff to the original manpage is quite large and is not limited to the new text, it can also change (for the better usually) the appearance of certain parts of the manpage (headers generally). Currently, emdebian-tools is going to have to distribute a modified version of debootstrap in /usr/share/emdebian-tools/ in order to support this functionality in our root filesystem creation scripts. I'd rather have support within debootstrap itself and then emdebian-tools can just depend on debootstrap (>= 1.0.4). emdebian-tools 0.4.1 is due for upload to Emdebian tonight but I would like to have this fixed before the next round of debconf translations require an upload to Debian (at least two weeks). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpPQQEzzofmF.pgp Description: PGP signature
Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot
On Sat, 06 Oct 2007 15:33:43 -0300 Otavio Salvador <[EMAIL PROTECTED]> wrote: > >>> Can you prepare a patch for it? > >> > >> I wasn't sure what name to use for the command line option and I'm not > >> sure about how the patch results in: > > > > Maybe: --second-stage-target looks clearer. > > Could you update the manpage? So we can commit it. Unfortunately not - debootstrap contains no source for the manpage and I cannot even begin to edit groff/whatever. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpamGv1azkiQ.pgp Description: PGP signature
Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot
On Wed, 03 Oct 2007 14:41:10 -0300 Otavio Salvador <[EMAIL PROTECTED]> wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > > Is there a cleaner way of achieving the same result, maybe debootstrap > > could support / as a default and allow an override on the command line? > > Hello Neil, > > Yes, I think that a command line option might be the best way to > handle that. > > Can you prepare a patch for it? I wasn't sure what name to use for the command line option and I'm not sure about how the patch results in: --chroot-dir /home/test/ --second-stage being an error when --second-stage --chroot-dir /home/test/ is not. YMMV. All that matters for my purposes is that $TARGET can be overridden when calling second stage whilst retaining the default for others. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ --- debootstrap-0.3.3.2/debootstrap 2005-11-05 18:11:30.0 + +++ debootstrap-new/debootstrap 2007-10-03 21:32:41.0 +0100 @@ -85,6 +85,9 @@ --unpack-tarball T acquire .debs from a tarball instead of http --make-tarball T download .debs and create a tarball (tgz format) + --chroot-dir DIR Run second stage in a subdirectory instead of root + (can be used to create a foreign chroot) + (requires --second-stage) --boot-floppiesused for internal purposes by boot-floppies --debian-installer used for internal purposes by debian-installer EOF @@ -135,6 +138,18 @@ SECOND_STAGE_ONLY=true shift ;; + --chroot-dir) + if [ "$SECOND_STAGE_ONLY" = "true" ] ; then + if [ -n "$2" ] ; then +CHROOTDIR="$2" +shift 2 + else +error 1 NEEDARG "option requires an argument: %s" "$1" + fi +else +error 1 NEEDARG "%s only applies in the second stage" "$1" +fi + ;; --print-debs) WHAT_TO_DO="finddebs printdebs kill_target" shift @@ -235,7 +250,11 @@ VARIANT=$(cat $DEBOOTSTRAP_DIR/variant) SUPPORTED_VARIANTS="$VARIANT" fi - TARGET=/ + if [ "$CHROOTDIR" = "" ]; then +TARGET=/ + else +TARGET=$CHROOTDIR + fi MIRRORS=null: SCRIPT=$DEBOOTSTRAP_DIR/suite-script else pgpzIn5P5FTrI.pgp Description: PGP signature
Bug#445157: debootstrap - hardcoded value of TARGET in second-stage prevents creation of a foreign chroot
Package: debootstrap Version: 1.0.3 Severity: wishlist Emdebian is building a root filesystem that is created using debootstrap using the --foreign option. This is then copied to an embedded device for testing. Unfortunately, debootstrap --second-stage assumes that the TARGET is / which is awkward when what I actually want is to test the root filesystem (and the installation process itself) in a chroot first. So far, I've just tweaked debootstrap: - TARGET=/ + TARGET=$TARGET so that I can pass TARGET on the command line. Is there a cleaner way of achieving the same result, maybe debootstrap could support / as a default and allow an override on the command line? -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages debootstrap depends on: ii binutils 2.18-1 The GNU assembler, linker and bina ii wget 1.10.2-3 retrieves files from the web debootstrap recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
