Re: Bug#67888: marked as done ([CVS-fixed] Netwinder/arm port shouldn't ask about maintaining 2.0 compatability)
On Thu 23 Nov, Adam Di Carlo wrote: > Wookey <[EMAIL PROTECTED]> writes: > > On Tue 21 Nov, Debian Bug Tracking System wrote: > > > >From [EMAIL PROTECTED] Sat Jul 29 01:11:08 2000 > > > Return-path: <[EMAIL PROTECTED]> > > > The debian installer for potato worked just fine on the netwinder, one > > > I convinced it to tftp boot the provided netwinder-rescue image. One > > > hitch though -- the question about maintaining 2.0 compatability for > > > the ext2 fs should be removed and forced to "yes". Answering "no" > > > causes the netwinder's firmware (which is just a stripped down linux > > > kernel) to be unable to read the filesystem -- so it is unable to boot > > > the system. Not that big a deal though. > Could you file this as a bug? erm, are you confused adam? The above para has already been filed as a bug and you replied saying it was fixed in bf2.2.17 (see below - it was this message that I replied to). That's all fine so far as I can tell. Or do you mean I should file the fact that this causes (may cause?) a different problem for RiscPC as a bug? > > > >From [EMAIL PROTECTED] Tue Nov 21 05:21:28 2000 > > > This bug was fixed in one of the last two versions of the > > > boot-floppies, either 2.2.17 or 2.2.18, both of which are in Potato > > > now. > > Erm, this is all fine for netwinders, but for a riscpc (the other main > > arm desktop platform) this option does not need to be forced to yes. This > > is just one of many things that vary between arm platforms (which are > > fairly hetrogenous). I don't know what the disadvantage is, but if it > > affects disk speed then as the riscps is 'very slow' in this dept it > > would be nice to have the choice. > > There are several things that need to be done differently for different > > arm sub-platforms. Is there an approved mechanism for this at the moment > > or not? > You'd have to ask the ARM porters. Other arches with subarches (such as > sparc) look in /proc/cpuinfo and such and automatically deal with this. I _am_ the ARM porters :-). Well, it's not quite that bad, but I'm one of a very few people working on bf for ARM. I take your point that it is better to check this at runtime if possible and take appropriate action than to make different boot-floppies sets, where possible. I was just wondering whether there was official bf policy on how to deal with subarches so that things remained consistent. I'll check out the code and get it to use /proc/cpuinfo if appropriate. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bf-utf - do I need it? where does it come from?
On Wed 22 Nov, Marcin Owsiany wrote: > On Wed, Nov 22, 2000 at 07:22:00PM +0100, Marcin Owsiany wrote: > > On Wed, Nov 22, 2000 at 05:36:12PM +, Wookey wrote: > > > Trying to compile boot-floppies for arm it compiles dbootstrap OK but then > > > tried to cd to ../bf-utf/newt adn run ./configure. > What exactly did you try to compile in 'utilities'? I was doing 'make release' at the top level. > It shouldn't try to use bf-utf unless USE_LANG_CHOOSER is set. Right I've found the problem: Even with USE_LANG_CHOOSER := false these rules in /utilities/dbootstrap/Makefile mean that the dir is needed $(UTF_LIBS_BASE)/newt/libnewt.a: cd $(UTF_LIBS_BASE)/newt; CFLAGS=-Os ./configure $(MAKE) -C $(UTF_LIBS_BASE)/newt $(UTF_LIBS_BASE)/slang/src/objs/libslang.a: cd $(UTF_LIBS_BASE)/slang; CFLAGS=-Os ./configure $(MAKE) -C $(UTF_LIBS_BASE)/slang > I think checkout should get it, but I'm not sure. OK. It does now (although it didn't ~10 days ago). I think that means that everything is in fact working OK; i.e. as the bf-utf dir is part of bootfloppies then it's OK for it to be required, although it would be nice if the above libraries weren't compiled when they aren't needed. I'm not quite sure how to modify the Makefile to make this happen - I'll let you decide if you want to do that. :-) Next I've hit some kind of python problem. More if this turns out to be something to do with bf... Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel (00 44) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bf-utf - do I need it? where does it come from?
On Thu, Nov 23, 2000 at 02:58:39PM +, Wookey wrote: > > OK. It does now (although it didn't ~10 days ago). I think that means that > everything is in fact working OK; i.e. as the bf-utf dir is part of > bootfloppies then it's OK for it to be required, although it would be nice if > the above libraries weren't compiled when they aren't needed I fixed that this night. > Next I've hit some kind of python problem. More if this turns out to be > something to do with bf... These should disappear as well if you get the newest dbootstrap Makefile. regards Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Installation to software RAID
Hi! Does the Debian currently support the installation into a software RAID? Is it possible during the installation to create a software RAID, install the system into it and make it bootable? I don't think that it is in the standard installation manual, but maybe it is possible to arrange with minimum amount of boot floppy hacking? Best regards, J. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Boot floppies 2.2.19
On Wed, Nov 22, 2000 at 12:11:57PM -0500, Daniel Jacobowitz wrote: > The build is going now; unless someone screams very loudly, I'll do > source and powerpc uploads as soon as it is done. AARGH, loud enough? Well, actually I am still trying to build 2.2.18 for m68k. Besides the missing python-dev Build-Depends (thats new, is that intentional?) I have this problem: gcc -s -Wall -Os -fomit-frame-pointer -fno-builtin -pipe -o dbootstrap-lc baseconfig.lc.o block_device.lc.o bootconfig.lc.o boxes.lc.o choose_lang.lc.o choose_medium.lc.o extract_base.lc.o extract_kernel.lc.o floppy_merge.lc.o floppy_modules.lc.o http-fetch.lc.o interactive_shell.lc.o kbdconfig.lc.o losetup.lc.o main.lc.o main_menu.lc.o net-fetch.lc.o netconfig.lc.o partition_config.lc.o pcmcia.lc.o powermac.lc.o reboot_system.lc.o release_notes.lc.o select_not_mounted.lc.o tzconfig.lc.o util.lc.o langs.o -lloadtrm ../libfdisk/libfdisk.a ../bf-utf/newt/libnewt.a ../bf-utf/slang/src/objs/libslang.a collect2: ld terminated with signal 11 [Segmentation fault], core dumped make[4]: *** [dbootstrap-lc] Error 1 make[4]: Leaving directory `/build/boot-floppies/boot-floppies/utilities/dbootstrap' make[3]: *** [dbootstrap] Error 2 Is this problem arch or machine specific or is it generic? Maybe fixed in 2.2.19? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Boot floppies 2.2.19
On Thu, Nov 23, 2000 at 09:15:14PM +0100, Christian T. Steigies wrote: > Besides the missing python-dev Build-Depends (thats new, is > that intentional?) I have this problem: [...] > select_not_mounted.lc.o tzconfig.lc.o util.lc.o langs.o -lloadtrm >../libfdisk/libfdisk.a > ../bf-utf/newt/libnewt.a ../bf-utf/slang/src/objs/libslang.a > collect2: ld terminated with signal 11 [Segmentation fault], core dumped > Is this problem arch or machine specific or is it generic? Maybe fixed in > 2.2.19? Again this is my fault :-( This is something I forgot about during integration of LANGUAGE_CHOOSER - the Makefile tries to build dbootstrap-lc even if USE_LANGUAGE_CHOOSER is set to false. I (hopefully) fixed this last night, in Makefile's revision 1.87 Once again, I apologize for the destruction I am causing :-\ regards Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 PGP signature
Bug#77455: i18n] sets wrong keyboard for i386
On Tue, Nov 21, 2000 at 06:35:12AM -0500, Adam Di Carlo wrote: > > I looked into it myself to see what the deal was and I couldn't figure > out why it was failing. Hmm... I wonder if it's a good idea to set keymap in a bterm. Isn't it a bit like setting a keymap in an xterm? Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.2.18 + LANG_CHOOSER has bad bugs
On Wed, Nov 22, 2000 at 08:48:11AM -0400, Gleydson Mazioli da Silva wrote: > I need to check again for that I checked with Adam's build today, and it really seems OK. I used a hex editor, that all the spaces that appear in language choose menu are really spaces (0x20) in the .src file. Please try the sets that Adam made. > > > Some others characters are translated to it normal (without > > > accentuation): > > This should never happen. > > They are really translated, for example, in sentence "Sistema de > instalaçao > Debian GNU/Linux", it's translated to "Sistema de instalaçao Debian > GNU/Linux" > and other messages happen that too. Hmm.. I may be missing something, but the two sentences you provided are really the same? Or do you mean the line breaks are inserted? regards Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
hardware detection + loading modules
If all the users hardware is supported by the kernel, then it doesnt need any drivers to support the hardware, hardware detection programs will still show what kernel modules are needed to support the hardware, information which is useless in this case. We could just try and fetch and load the module anyway, but its wasted effort if its not needed, can anyone think of a better way to determine the loaded kernels capabilities ? Glenn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#77455: i18n] sets wrong keyboard for i386
On Thu, Nov 23, 2000 at 10:05:36PM +0100, Marcin Owsiany wrote:
> On Tue, Nov 21, 2000 at 06:35:12AM -0500, Adam Di Carlo wrote:
> >
> > I looked into it myself to see what the deal was and I couldn't figure
> > out why it was failing.
Just an idea: am I right that the failing keymap load is called
in main_menu.c here?:
#ifdef USE_LANGUAGE_CHOOSER
/* assert (lang != NULL); */
if (lang->keymap != NULL && lang->keymap[0] != '\0')
{
/*
* MSS: I am not sure this is needed as we've already
* chosen the localized environment
*/
configure_keyboard (lang->keymap);
goto done_keyboard;
}
#endif
If so, then isn't lang->keymap in Unicode or something and that
causes the strcmp in configure_keymap() to fail? I know it's
supposed to be ASCII, but maybe I'm wrong?
Marcin
--
Marcin Owsiany <[EMAIL PROTECTED]>
http://student.uci.agh.edu.pl/~porridge/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#77455: i18n] sets wrong keyboard for i386 - kind of solved
On Thu, Nov 23, 2000 at 10:05:36PM +0100, Marcin Owsiany wrote: > On Tue, Nov 21, 2000 at 06:35:12AM -0500, Adam Di Carlo wrote: > > > > I looked into it myself to see what the deal was and I couldn't figure > > out why it was failing. No, this is simpler then I thought at first. LC code in main_menu passes "i386/qwerty/pl" to configure_keyboard, which then compares it against list of strings like "qwerty/pl" (no arch prefix). It doesn't find a match, and prints an error. Manual selection works later, because it uses strings without arch prefix. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#77455: i18n] sets wrong keyboard for i386 - kind of solved
On Thu, Nov 23, 2000 at 11:41:24PM +0100, Marcin Owsiany wrote: > No, this is simpler then I thought at first. LC code in > main_menu passes "i386/qwerty/pl" to configure_keyboard, which > then compares it against list of strings like "qwerty/pl" (no > arch prefix). It doesn't find a match, and prints an error. > Manual selection works later, because it uses strings without > arch prefix. So it looks like one should normalize the list of available keyboards in one of the places... -- Misha -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#77455: i18n] sets wrong keyboard for i386 - kind of solved
On Fri, Nov 24, 2000 at 02:46:09AM +0300, Michael Sobolev wrote: > On Thu, Nov 23, 2000 at 11:41:24PM +0100, Marcin Owsiany wrote: > > No, this is simpler then I thought at first. LC code in > > main_menu passes "i386/qwerty/pl" to configure_keyboard, which > > then compares it against list of strings like "qwerty/pl" (no > > arch prefix). It doesn't find a match, and prints an error. > > Manual selection works later, because it uses strings without > > arch prefix. > So it looks like one should normalize the list of available keyboards in one of > the places... Maybe the arch prefixes in langs/*.src should be cut off at build time? Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://student.uci.agh.edu.pl/~porridge/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
