Re: [patch] Add cons25 terminfo file (used by kfreebsd-i386)
On 30/06/2009, Luca Favatella wrote: > On 30/06/2009, Colin Watson wrote: >> On Tue, Jun 30, 2009 at 08:43:08PM +0200, Luca Favatella wrote: >>> On 30/06/2009, Luca Favatella wrote: >>> > This little patch adds cons25 terminfo file. > [...] >> I think this is fine, but I suspect other people will object to the >> (small) size increase. We should probably make di-utils-terminfo >> architecture-specific and include this file conditionally, to avoid a >> size increase on other architectures. Could you look into doing this? > > Ok, tomorrow I hope to look into doing this. Done in the attached version 3 of the patch. I built this on kfreebsd-i386. The built packages are of the same size of those built from trunk (12 bytes more or less from a quick look)(obviously except di-utils-terminfo that is a lot smaller). In particular the di-utils-terminfo works in kfreebsd d-i (monolithic miniiso). Please carefully review this patch (because of my lack of experience). Cheers, Luca Favatella Index: packages/debian-installer-utils/debian/control === --- packages/debian-installer-utils/debian/control (.../trunk) (revision 59177) +++ packages/debian-installer-utils/debian/control (.../branches/d-i/kfreebsd) (revision 59189) @@ -41,6 +41,6 @@ XC-Package-Type: udeb Package: di-utils-terminfo -Architecture: all +Architecture: any Description: Terminfo entries needed by newt/slang in debian installer XC-Package-Type: udeb Index: packages/debian-installer-utils/debian/changelog === --- packages/debian-installer-utils/debian/changelog (.../trunk) (revision 59177) +++ packages/debian-installer-utils/debian/changelog (.../branches/d-i/kfreebsd) (revision 59189) @@ -1,3 +1,11 @@ +debian-installer-utils (1.70) UNRELEASED; urgency=low + + [ Luca Favatella ] + * Add 'cons25' terminfo file (used by kfreebsd-i386). + * Make di-utils-terminfo Architecture: any to avoid size increase. + + -- Colin Watson Tue, 30 Jun 2009 13:02:50 +0100 + debian-installer-utils (1.69) unstable; urgency=low * block-attr: The 'type' builtin doesn't seem to handle variable Index: packages/debian-installer-utils/debian/rules === --- packages/debian-installer-utils/debian/rules (.../trunk) (revision 59177) +++ packages/debian-installer-utils/debian/rules (.../branches/d-i/kfreebsd) (revision 59189) @@ -1,5 +1,12 @@ #!/usr/bin/make -f +ifeq ($(DEB_HOST_ARCH_OS),linux) + TERMS=/usr/share/terminfo/a/ansi /usr/share/terminfo/d/dumb \ + /usr/share/terminfo/l/linux /usr/share/terminfo/v/vt102 +else ifeq ($(DEB_HOST_ARCH_OS),kfreebsd) + TERMS=/usr/share/terminfo/c/cons25 +endif + build: build-stamp build-stamp: dh_testdir @@ -25,12 +32,6 @@ dh_installdebconf -i dh_compress -i dh_fixperms -i - for file in /usr/share/terminfo/a/ansi /usr/share/terminfo/d/dumb \ - /usr/share/terminfo/l/linux /usr/share/terminfo/v/vt102; do \ - mkdir -p debian/di-utils-terminfo/`dirname $$file`; \ - cp -pL $$file debian/di-utils-terminfo/$$file; \ - chmod 644 debian/di-utils-terminfo/$$file; \ - done dh_installdeb -i dh_gencontrol -i dh_builddeb -i @@ -51,6 +52,11 @@ dh_installdebconf -a dh_compress -a dh_fixperms -a + for file in $(TERMS); do \ + mkdir -p debian/di-utils-terminfo/`dirname $$file`; \ + cp -pL $$file debian/di-utils-terminfo/$$file; \ + chmod 644 debian/di-utils-terminfo/$$file; \ + done dh_strip -a dh_installdeb -a dh_shlibdeps -a
Re: [patch] netcfg wireless
On 01/07/2009, Otavio Salvador wrote:
[...]
> The patch itself looks good. I'd just inverse the logic.
>
> You've used NO_WIRELESS and I'd use WIRELESS and set it to 0 to
> disable or or similar.
Consider that NO_WIRELESS was already there.
However I modified it as you suggested in the attached version 2 of the patch.
Index: packages/netcfg/debian/changelog
===
--- packages/netcfg/debian/changelog (.../trunk) (revision 59177)
+++ packages/netcfg/debian/changelog (.../branches/d-i/kfreebsd) (revision 59190)
@@ -4,6 +4,11 @@
Thanks to Marco d'Itri for the proposed change
Closes: #533384
+ [ Luca Favatella ]
+ * If wireless is disabled, don't build and link wireless related stuff.
+ * Disable by default wireless on non-linux architectures.
+ * Inverse the logic about building without wireless support (WIRELESS=0).
+
-- Christian Perrier Thu, 18 Jun 2009 06:11:33 +0200
netcfg (1.49) unstable; urgency=low
Index: packages/netcfg/Makefile
===
--- packages/netcfg/Makefile (.../trunk) (revision 59177)
+++ packages/netcfg/Makefile (.../branches/d-i/kfreebsd) (revision 59190)
@@ -1,11 +1,16 @@
CC = gcc
TARGETS ?= netcfg-static netcfg
-LDOPTS = -ldebconfclient -ldebian-installer -liw
+LDOPTS = -ldebconfclient -ldebian-installer
CFLAGS = -W -Wall -DNDEBUG
COMMON_OBJS = netcfg-common.o wireless.o
-ifeq ($(NO_WIRELESS),)
+ifneq ($(DEB_HOST_ARCH_OS),linux)
+WIRELESS = 0
+endif
+
+ifneq ($(WIRELESS),0)
+LDOPTS += -liw
CFLAGS += -DWIRELESS
endif
Index: packages/netcfg/netcfg-common.c
===
--- packages/netcfg/netcfg-common.c (.../trunk) (revision 59177)
+++ packages/netcfg/netcfg-common.c (.../branches/d-i/kfreebsd) (revision 59190)
@@ -180,6 +184,7 @@
#undef SYSCLASSNET
+#if defined(WIRELESS)
int is_raw_80211(const char *iface)
{
struct ifreq ifr;
@@ -203,6 +208,7 @@
return 0;
}
}
+#endif
int is_interface_up(char *inter)
{
@@ -263,8 +269,10 @@
continue;
if (!strncmp(ibuf, "sit", 3))/* ignore tunnel devices */
continue;
+#if defined(WIRELESS)
if (is_raw_80211(ibuf))
continue;
+#endif
if (all || is_interface_up(ibuf) == 1) {
list = realloc(list, sizeof(char*) * (len + 1));
list[len] = strdup(ibuf);
Re: The question about which language we use in the first is good
On Tue, Jun 30, 2009 at 11:26:22PM -0300, Otavio Salvador wrote: > On Tue, Jun 30, 2009 at 6:07 PM, Colin Watson wrote: > > I implemented that in Ubuntu. It's not done at the level of d-i, and > > fundamentally can't be - it's done in gfxboot, which is a set of boot > > loader hooks developed by SuSE which attach to syslinux. (The boot > > loader is not really part of d-i, although we do configure it.) I filed > > a bug report for this on Debian's syslinux package some time ago, but > > this approach doesn't have a lot of favour upstream (it's fairly > > intrusive, and they prefer a different menu scheme) so I've more or less > > given up hope that it will happen in Debian. > > It has been included in latest release so we can have a new hope for ;-) > > syslinux upstream case ported it to a module so it's now properly > supported by it. :-) Really? Gosh. That's excellent. I shall have to have a look at that! If people would like to use gfxboot in Debian, perhaps the Ubuntu theme could be bodged into service for Debian (you really don't want to attempt to write one from scratch, trust me; when we say "theme" for gfxboot we really mean "complete implementation of menu structure by hand" - I derived ours from SuSE's and even that was a fair amount of effort). I'm not going to be at DebCamp for as long as I was hoping to be, for travel-with-family reasons, but perhaps we could have a look over it at the tail-end of DebCamp or at DebConf? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The question about which language we use in the first is good
Colin Watson wrote: > If people would like to use gfxboot in Debian, perhaps the Ubuntu theme > could be bodged into service for Debian (you really don't want to > attempt to write one from scratch, trust me; when we say "theme" for > gfxboot we really mean "complete implementation of menu structure by > hand" - I derived ours from SuSE's and even that was a fair amount of > effort). somewhen next week, i'll upload the gfxboot userland tools. i'll have a look into the theme stuff afterwards, we also would like to switch to using gfxboot for debian-live as soon as possible. > I'm not going to be at DebCamp for as long as I was hoping to be, for > travel-with-family reasons, but perhaps we could have a look over it at > the tail-end of DebCamp or at DebConf? i'd be interested in that. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [patch] netcfg wireless
Hello Luca, On Wed, Jul 1, 2009 at 6:29 AM, Luca Favatella wrote: > On 01/07/2009, Otavio Salvador wrote: > [...] >> The patch itself looks good. I'd just inverse the logic. >> >> You've used NO_WIRELESS and I'd use WIRELESS and set it to 0 to >> disable or or similar. > > Consider that NO_WIRELESS was already there. > However I modified it as you suggested in the attached version 2 of the patch. It looks fine from my POV. Wait a cuple of days to see if noone complains about something and then commit it. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [patch] netcfg wireless
On 01/07/2009, Otavio Salvador wrote: [...] > It looks fine from my POV. Wait a cuple of days to see if noone > complains about something and then commit it. Ok, thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [patch] Add cons25 terminfo file (used by kfreebsd-i386)
Hello Luca, On Wed, Jul 1, 2009 at 5:43 AM, Luca Favatella wrote: [...] > Please carefully review this patch (because of my lack of experience). It looks fine. Wait a bit for comments and commit. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The question about which language we use in the first is good
Hello, Just a reminder: these boot loader are not accessible, so it shouldn't be assumed that the user choosing the default value means he meant it, it can also mean he just couldn't read it, and so the question should be asked again after booting. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
console-setup 1.36 MIGRATED to testing
FYI: The status of the console-setup source package in Debian's testing distribution has changed. Previous version: 1.28 Current version: 1.36 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535339: Openmoko Neo Freerunner (GTA02) support
Package: flash-kernel
Version: 2.19
Severity: wishlist
I checked the flash-kernel script and it seems the Openmoko Neo Freerunner
(GTA02) isn't among the supported machines.
After taking a look i came to the conclusion that it's probably a better idea
to provide someone having the full-scope with the platform specific stuff
instead of trying hard but probably still breaking something or at least 'not
doing it properly' myself.
so:
grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//'
returns
GTA02
the mkimage calls i'm currently using manually are:
mkimage -A arm -O linux -T ramdisk -C none -a 0x3280 -n "Ramdisk Image" -d
"/boot/initrd-$version.cpio.gz" "/boot/initrd-$version.cpio.gz.ub"
mkimage -A arm -O linux -T kernel -C none -a 0x3200 -n "Kernel Image" -d
"/boot/kernel-$version.cpio.gz" "/boot/initrd-$version.cpio.gz.ub"
It might be best not to do anything else after creating the uboot-images in
/boot, but let the user do the rest, as there are plenty of different
possibilities regarding the bootloader used, the media and partition where the
images are located, and the general setup. E.g. i'm using a uboot bootloader
that supports sdhc and ext2, with a cryptroot setup with the boot-partition
being the first partition on the sdhc-card, so to set the default boot entry
the correct command would be (just in case you might have an idea on how to
implement this in a sane and safe way):
uboot-envedit -i /dev/mtd2 -o /dev/mtd2 bootcmd="setenv bootargs \${bootargs_base}
rootfstype=ext2 root=/dev/mapper/modi rootdelay=5 \${mtdparts} ro quiet; mmcinit; sleep
1; ext2load mmc 1 0x3200 /kernel.ub; ext2load mmc 1 0x3280 /initrd.ub; bootm
0x3200 0x3280"
(these are the (factory default) variables set in the uboot environment:
bootargs_base=rootfstype=jffs2 root=/dev/mtdblock6 console=ttySAC2,115200
console=tty0 loglevel=8 regular_boot
mtdparts=mtdparts=physmap-flash:-(nor);neo1973-nand:0x0004(u-boot),0x0004(u-boot_env),0x0080(kernel),0x000a(splash),0x0004(factory),0x0f6a(rootfs)
just to provide all info so you can be sure there's no pitfall hidden somewhere)
"bootcmd" is the variable in the uboot environment used by uboot for the
default boot procedure.
"mmcinit" is necessary to initialize sdhc. the "sleep 1" is necessary as there seems to be a bug somewhere (probably
mmcinit) that makes the loading from sdhc break if it's done immediately after mmcinit returns. "ext2load" is used to load the
image from an ext2 partition. for fat partitions, the command is called "fatload". for both, the first argument "mmc"
tells them that the image to load is located on the sdhc card. the next argument is the partition number (starting at 1), followed by the
memory address to load the image to, followed by the path (on the partition, hence /... and not /boot/...) of the image to load.
"bootm" is the command to start the kernel (at the first address given) with the initrd (at the second address given).
oh and i just checked:
for i in /dev/mtd?; do if uboot-envedit -p -i $i >/dev/null 2>&1; then echo
$i; break; fi; done
works to find the uboot environment device (uboot-envedit checks the
environment crc).
i guess if it can be found, it might be reasonably safe to write the "bootcmd"
to it... dunno...
finding the correct "root=" parameter should be solveable with
mount|grep ' on / type'|awk '{ print $1 }'
or something like that... finding out whether /boot is ext2/ext3 or fat, could
be done by something like
mount|grep ' on /boot type'|awk '{ print $5 }'
but that might not work for / (in cases where mount thinks the type is
'auto')...
and in case you wonder: there are flash-partitions named 'kernel' and 'rootfs'.
why ignore them as install targets? i think that's reasonable because:
- the NAND-flash is 256MB alltogether. so 'kernel' and 'rootfs' might probably
be enough for kernel+initrd. but a debian installation is probably not at all
possible, or if it is, it will hardly be useful... i.e. it's more or less
necessary to install debian on the sdhc card anyway.
- leaving the default openmoko-os on the NAND-flash, at least for
emergency-boot purposes, is certainly a very good idea. using the 'kernel'
and/or 'rootfs' NAND-flash partitions for an os installed on a sdhc card would
break this, without any need or real advantage. so i doubt there's anyone out
there who did such a thing. :)
kind regards,
Chris
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
