devil-linux-develop — developer discussions

Re: [Devil-linux-develop] [PATCH] boot

[Heiko Z. <he...@zu...>]

Roland Pabel wrote:
> On Thursday 04 March 2004 22:32, Roland Pabel wrote:
> 
>>On Thursday 04 March 2004 22:12, hzu...@ra... wrote:
>>
>>>On 03/04/2004 03:49:05 PM Roland Pabel wrote:
>>>
>>>>On Thursday 04 March 2004 20:09, Heiko Zuerker wrote:
>>>>
>>>>>>Hi,
>>
>>[...]
>>
>>
>>>I probably understood it wrong.
>>>My main concern is that insserv is able to order the scripts in boot.d,
>>>that's all.
>>
>>well, insserv is able to do that. But it ordered the 6 scripts in my vmware
>>session to the exact same sequence as they were in my (running) 1.0.4...
> 
> let me clarify this: The 6 scripts are
> S01checkfs -> ../checkfs
> S02mountfs -> ../mountfs
> S03setfileperm -> ../setfileperm
> S04localnet -> ../localnet
> S05setclock -> ../setclock
> S06loadkeys -> ../loadkeys
> and were linked by insserv in /etc/init.d/rcS.d/ because of their header entry
> # Default-Start:  S
> They were called from inittab by "/etc/init.d/rc S".
> All I did was move them over to /etc/init.d/boot.d/, which insserv does 
> conveniently when writing
> # Default-Start:  B
> instead. They are now called from /etc/init.d/boot at the end (which itself is 
> started by init), so we don't need to create a link for that file 
> in /etc/init.d/rcS.d/ explicitly. (insserv definitely can't mess 
> with/etc/init.d/boot, it got no INIT INFO header...)
> So whatever concerns you have with insserv and boot.d/ must have been present 
> with rcS.d, too...Or haven't they? 
> The only problem I could think of is: If a user adds a script to this mode, it 
> might be called before mountfs...but that shouldn't happen very often, most 
> people only need 'boot.local' and don't add scripts (especially scripts with 
> proper INIT INFO declarations)

It should be OK this way.
When somebody adds a script to B, then he has to do it via insserv 
anyway, which then again takes care of the correct order. So everything 
should be "cool".

Heiko

Re: [Devil-linux-develop] [PATCH] boot

[Roland P. <pa...@ta...>]

On Thursday 04 March 2004 22:32, Roland Pabel wrote:
> On Thursday 04 March 2004 22:12, hzu...@ra... wrote:
> > On 03/04/2004 03:49:05 PM Roland Pabel wrote:
> > >On Thursday 04 March 2004 20:09, Heiko Zuerker wrote:
[...]
> Do you want to duplicate all entries in isolinux.cfg to pass the runlevel
> to the kernel cmdline? I know that works with lilo, but the really handy
> part is that you can specify any parameters freely...is that possible with
> isolinux on CD?
It just came to me that Knoppix uses this feature heavily and even with Suse 
you can use the F-Keys at boot to switch resolution and stuff. I'll look into 
that tomorrow, now I really want to know how that works...
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] [PATCH] boot

[Roland P. <pa...@ta...>]

On Thursday 04 March 2004 22:32, Roland Pabel wrote:
> On Thursday 04 March 2004 22:12, hzu...@ra... wrote:
> > On 03/04/2004 03:49:05 PM Roland Pabel wrote:
> > >On Thursday 04 March 2004 20:09, Heiko Zuerker wrote:
> > >> > Hi,
>
> [...]
>
> > I probably understood it wrong.
> > My main concern is that insserv is able to order the scripts in boot.d,
> > that's all.
>
> well, insserv is able to do that. But it ordered the 6 scripts in my vmware
> session to the exact same sequence as they were in my (running) 1.0.4...
let me clarify this: The 6 scripts are
S01checkfs -> ../checkfs
S02mountfs -> ../mountfs
S03setfileperm -> ../setfileperm
S04localnet -> ../localnet
S05setclock -> ../setclock
S06loadkeys -> ../loadkeys
and were linked by insserv in /etc/init.d/rcS.d/ because of their header entry
# Default-Start:  S
They were called from inittab by "/etc/init.d/rc S".
All I did was move them over to /etc/init.d/boot.d/, which insserv does 
conveniently when writing
# Default-Start:  B
instead. They are now called from /etc/init.d/boot at the end (which itself is 
started by init), so we don't need to create a link for that file 
in /etc/init.d/rcS.d/ explicitly. (insserv definitely can't mess 
with/etc/init.d/boot, it got no INIT INFO header...)
So whatever concerns you have with insserv and boot.d/ must have been present 
with rcS.d, too...Or haven't they? 
The only problem I could think of is: If a user adds a script to this mode, it 
might be called before mountfs...but that shouldn't happen very often, most 
people only need 'boot.local' and don't add scripts (especially scripts with 
proper INIT INFO declarations)
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] [PATCH] boot

[Roland P. <pa...@ta...>]

On Thursday 04 March 2004 22:12, hzu...@ra... wrote:
> On 03/04/2004 03:49:05 PM Roland Pabel wrote:
> >On Thursday 04 March 2004 20:09, Heiko Zuerker wrote:
> >> > Hi,
> >
[...]
>
> I probably understood it wrong.
> My main concern is that insserv is able to order the scripts in boot.d,
> that's all.
well, insserv is able to do that. But it ordered the 6 scripts in my vmware 
session to the exact same sequence as they were in my (running) 1.0.4...
What is your concern there? I don't see a problem...

[...]
> >I thought about this at the gym, I think I can easily code that
> >in /sbin/pre_init, when I can manually change inittab (replacing the
> >default
> >runlevel with sed and grep) before starting init. That's under the
> >assumption, that once init runs, there is no point to doing that
> >(otherwise,
> >that could be done in a boot.d/ script before entering the runlevel)
>
> Do you need to code anything?
well, yes...
> Try just to add the "1" to the kernel boot parameters in the boot menu.
Do you want to duplicate all entries in isolinux.cfg to pass the runlevel to 
the kernel cmdline? I know that works with lilo, but the really handy part is 
that you can specify any parameters freely...is that possible with isolinux 
on CD?
> With a bit luck it's really that easy (should be at least)
well, an additional static runlevel config in isolinux.cfg is easy, but it's 
static...
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] [PATCH] boot

[<hzu...@ra...>]

On 03/04/2004 03:49:05 PM Roland Pabel wrote:
>On Thursday 04 March 2004 20:09, Heiko Zuerker wrote:
>> > Hi,
>[...]
>> > - insserv adds links in boot.d when you specify "B" as runlevel
>> > (but /etc/init.d/rc doesn't understand that specifier)
>>
>> But you could add the functionality, or ? ;-)
>> Unfortunately we need to use our system in a way, that insserv will
>work
>> with it.
>well, insserv works, it knows about boot.d. It's the legacy
>/etc/init.d/rc
>file that doesn't know about it. But that shouldn't be a problem,
>because
>'rc' is used to switch betweeen runlevels, but the boot.d/ scripts are
>not
>part of any specific runlevel (and you shouldn't be able to switch to a
>runlevel B).
>What is that functionality you need there?

I probably understood it wrong.
My main concern is that insserv is able to order the scripts in boot.d,
that's all.

>> > I'll try to make some more changes, i.e. choosing runlevel on
>startup
>> > (for maintenance, unless someone adds XFree ;-)...
>>
>> That's good!
>> I don't know how often I already needed a boot into runlevel 1. But I
>> always forgett to add it to the boot menu.
>I thought about this at the gym, I think I can easily code that
>in /sbin/pre_init, when I can manually change inittab (replacing the
>default
>runlevel with sed and grep) before starting init. That's under the
>assumption, that once init runs, there is no point to doing that
>(otherwise,
>that could be done in a boot.d/ script before entering the runlevel)

Do you need to code anything?
Try just to add the "1" to the kernel boot parameters in the boot menu.
With a bit luck it's really that easy (should be at least)

Heiko

Re: [Devil-linux-develop] [PATCH] boot

[Roland P. <pa...@ta...>]

On Thursday 04 March 2004 20:09, Heiko Zuerker wrote:
> > Hi,
[...]
> > - insserv adds links in boot.d when you specify "B" as runlevel
> > (but /etc/init.d/rc doesn't understand that specifier)
>
> But you could add the functionality, or ? ;-)
> Unfortunately we need to use our system in a way, that insserv will work
> with it.
well, insserv works, it knows about boot.d. It's the legacy /etc/init.d/rc 
file that doesn't know about it. But that shouldn't be a problem, because 
'rc' is used to switch betweeen runlevels, but the boot.d/ scripts are not 
part of any specific runlevel (and you shouldn't be able to switch to a 
runlevel B).
What is that functionality you need there?

> > I'll try to make some more changes, i.e. choosing runlevel on startup
> > (for maintenance, unless someone adds XFree ;-)...
>
> That's good!
> I don't know how often I already needed a boot into runlevel 1. But I
> always forgett to add it to the boot menu.
I thought about this at the gym, I think I can easily code that 
in /sbin/pre_init, when I can manually change inittab (replacing the default 
runlevel with sed and grep) before starting init. That's under the 
assumption, that once init runs, there is no point to doing that (otherwise, 
that could be done in a boot.d/ script before entering the runlevel)
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] [PATCH] boot

[Friedrich L. <fl...@fl...>]

Roland Pabel wrote on 04.03.2004 20:11 MET:
> On Thursday 04 March 2004 20:05, Friedrich Lobenstock wrote:
> 
>>Roland Pabel wrote on 04.03.2004 19:26 MET:
>>
>>>...
>>>which is the way most other distros do it (apart from changes in names)
>>
>>Shouldn't we keep the names similar? Keeps the "I know that" factor alive.
> 
> I haven't changed any names...redhat uses "rc.sysinit" instead of "boot", suse 
> uses "boot" (since insserv is a suse thing, I'd let it stay this way)...

Ok, then I somehow got you wrong here.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] [PATCH] boot

[Heiko Z. <he...@zu...>]

> Hi,
> this patch sets the new boot flow:
>
> /sbin/pre_init -> exec init
> /etc/init.d/boot
> /etc/init.d/boot.d/S*
> /etc/init.d/boot.local
> init goes into runlevel 3
>
> which is the way most other distros do it (apart from changes in names)
> Notes:
> - /etc/init.d/boot doesn't need to be called manually with the link in
> cfg_runlevel any longer (and doesn't need "start" - it should always run),
> because it's done by inittab
great!

> - boot.* can't be handled by insserv, because the author of insserv
> prohibits
> that (probably to enforce to run boot.local as the last script before
> going
> into the runlevel)
> - insserv adds links in boot.d when you specify "B" as runlevel
> (but /etc/init.d/rc doesn't understand that specifier)

But you could add the functionality, or ? ;-)
Unfortunately we need to use our system in a way, that insserv will work
with it.

> I'll try to make some more changes, i.e. choosing runlevel on startup (for
> maintenance, unless someone adds XFree ;-)...

That's good!
I don't know how often I already needed a boot into runlevel 1. But I
always forgett to add it to the boot menu.

> Roland
> PS: build-20040301.tar.bz2 contains empty config/etc/rc{1,3,S}.d
> (not /etc/init.d/) directories, some script gone wild?

Hmmm.....
No idea.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] [PATCH] boot

[Roland P. <pa...@ta...>]

On Thursday 04 March 2004 20:05, Friedrich Lobenstock wrote:
> Roland Pabel wrote on 04.03.2004 19:26 MET:
> > this patch sets the new boot flow:
> >
> > /sbin/pre_init -> exec init
> > /etc/init.d/boot
> > /etc/init.d/boot.d/S*
> > /etc/init.d/boot.local
> > init goes into runlevel 3
> >
> > which is the way most other distros do it (apart from changes in names)
>
> Shouldn't we keep the names similar? Keeps the "I know that" factor alive.
I haven't changed any names...redhat uses "rc.sysinit" instead of "boot", suse 
uses "boot" (since insserv is a suse thing, I'd let it stay this way)...
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] [PATCH] boot

[Friedrich L. <fl...@fl...>]

Roland Pabel wrote on 04.03.2004 19:26 MET:
> this patch sets the new boot flow: 
> 
> /sbin/pre_init -> exec init
> /etc/init.d/boot 
> /etc/init.d/boot.d/S*
> /etc/init.d/boot.local
> init goes into runlevel 3
> 
> which is the way most other distros do it (apart from changes in names)

Shouldn't we keep the names similar? Keeps the "I know that" factor alive.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

[Devil-linux-develop] [PATCH] boot

[Roland P. <pa...@ta...>]

Hi,
this patch sets the new boot flow: 

/sbin/pre_init -> exec init
/etc/init.d/boot 
/etc/init.d/boot.d/S*
/etc/init.d/boot.local
init goes into runlevel 3

which is the way most other distros do it (apart from changes in names)
Notes: 
- /etc/init.d/boot doesn't need to be called manually with the link in 
cfg_runlevel any longer (and doesn't need "start" - it should always run), 
because it's done by inittab
- boot.* can't be handled by insserv, because the author of insserv prohibits 
that (probably to enforce to run boot.local as the last script before going 
into the runlevel)
- insserv adds links in boot.d when you specify "B" as runlevel 
(but /etc/init.d/rc doesn't understand that specifier)

I'll try to make some more changes, i.e. choosing runlevel on startup (for 
maintenance, unless someone adds XFree ;-)...
Roland
PS: build-20040301.tar.bz2 contains empty config/etc/rc{1,3,S}.d 
(not /etc/init.d/) directories, some script gone wild?
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] init.d permissions problem.

[Heiko Z. <he...@zu...>]

>> > init.d/checkfs  and  init.d/mountfs  have 644 permissions on the build
>> > system, and are not being executed during DL bootup because of
>> > non-executable permissions.
>> >
>> > I deleted both files from my local HDD, and re-downloaded them from
>> with
>> > a CVS update, and they still come across as 644 permissions.
>> >
>> > I changed them to 755 permissions and did a cvs commit, but that
>> didn't
>> > do anything.  Is there any way to change the permissions of these
>> files
>> > on the SF CVS server, or should we do a chmod in the create_etc
>> script?
>>
>> Add the chmod 755 to the cfg_runlevel script.
>
> cfg_runlevel already has this line:
>
>   chmod -R 700 $ETCDIR/etc/init.d/* || exit 1
>
> How are those two files ending up with 644 in the etc.tar?

Did you take a look how it is after a "make clean install" ?
My guess is that you were testing something and cfg_runlevel didn't get
executed.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] init.d permissions problem.

[Bruce S. <bw...@ar...>]

> > Add the chmod 755 to the cfg_runlevel script.
> 
> cfg_runlevel already has this line:
> 
>   chmod -R 700 $ETCDIR/etc/init.d/* || exit 1
> 
> How are those two files ending up with 644 in the etc.tar?

Ah, never mind ....

I bet it's because I did a "rm tmp/.done_install_create_etc"
but didn't "rm tmp/.done_install_cfg_runlevel "
and a "make install iso" to recreate the etc tar.

Oops.  :-)

 - BS

Re: [Devil-linux-develop] init.d permissions problem.

[Bruce S. <bw...@ar...>]

> > init.d/checkfs  and  init.d/mountfs  have 644 permissions on the build
> > system, and are not being executed during DL bootup because of
> > non-executable permissions.
> >
> > I deleted both files from my local HDD, and re-downloaded them from with
> > a CVS update, and they still come across as 644 permissions.
> >
> > I changed them to 755 permissions and did a cvs commit, but that didn't
> > do anything.  Is there any way to change the permissions of these files
> > on the SF CVS server, or should we do a chmod in the create_etc script?
> 
> Add the chmod 755 to the cfg_runlevel script.

cfg_runlevel already has this line:

  chmod -R 700 $ETCDIR/etc/init.d/* || exit 1

How are those two files ending up with 644 in the etc.tar?

 - BS

Re: [Devil-linux-develop] init.d permissions problem.

[Heiko Z. <he...@zu...>]

> init.d/checkfs  and  init.d/mountfs  have 644 permissions on the build
> system, and are not being executed during DL bootup because of
> non-executable permissions.
>
> I deleted both files from my local HDD, and re-downloaded them from with
> a CVS update, and they still come across as 644 permissions.
>
> I changed them to 755 permissions and did a cvs commit, but that didn't
> do anything.  Is there any way to change the permissions of these files
> on the SF CVS server, or should we do a chmod in the create_etc script?

Add the chmod 755 to the cfg_runlevel script.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] Re: [Devil-linux-commit] build/config/etc/initrd linuxrc,1.63,1.64

[Bruce S. <bw...@ar...>]

> >> Index: linuxrc
> >
> >>  					mount -n -t auto $CFG_SRC /floppy >/dev/null 2>&1 || continue
> >>  					cp -i /cdrom/config/etc.tar.bz2 /floppy/ || continue
> >> +					umount /cdrom
> >>  					sync
> >>  					DL_CONFIG_SOURCE=$CFG_SRC
> >>  					continue 2
> >
> > Without the above umount of /cdrom , the following umount /floppy would
> > fail every time.  (the above code only gets run when a new config is
> > copied to a blank media)  It took me a half day of trial & error to get
> > this bug fixed!!!
> 
> Could it be a problem with busybox?

I guess.  Nothing else makes any sense.

> This means the system will now search 2 times for the CD-ROM. But since
> this is only the case during the initial setup of the box, I don't see a
> problem there.

That was my thinking.
Plus it beats having the floppy mounted after bootup.  :-)

> >>  # unmount config media
> >> -umount /floppy &> /dev/null
> >> +umount /floppy
> >
> > BTW, /dev/null removed so we can see if error if it occurs again.
> 
> OK

Not to mention it wasn't working in the first place.  ;-)
Which is how I noticed the problem to start with.
"2>" would have worked better.

 - BS

Re: [Devil-linux-develop] Re: [Devil-linux-commit] build/config/etc/initrd linuxrc,1.63,1.64

[Heiko Z. <he...@zu...>]

> This is the weirdest problem I've seen in a long time.
>
>> Log Message:
>> Fixed problem of /floppy not umount'ing when new config copied to media.
>>
>>
>> Index: linuxrc
>
>>  					mount -n -t auto $CFG_SRC /floppy >/dev/null 2>&1 || continue
>>  					cp -i /cdrom/config/etc.tar.bz2 /floppy/ || continue
>> +					umount /cdrom
>>  					sync
>>  					DL_CONFIG_SOURCE=$CFG_SRC
>>  					continue 2
>
> Without the above umount of /cdrom , the following umount /floppy would
> fail every time.  (the above code only gets run when a new config is
> copied to a blank media)  It took me a half day of trial & error to get
> this bug fixed!!!

Could it be a problem with busybox?
This means the system will now search 2 times for the CD-ROM. But since
this is only the case during the initial setup of the box, I don't see a
problem there.

>>  # unmount config media
>> -umount /floppy &> /dev/null
>> +umount /floppy
>
> BTW, /dev/null removed so we can see if error if it occurs again.

OK

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

[Devil-linux-develop] init.d permissions problem.

[Bruce S. <br...@ar...>]

init.d/checkfs  and  init.d/mountfs  have 644 permissions on the build
system, and are not being executed during DL bootup because of
non-executable permissions.

I deleted both files from my local HDD, and re-downloaded them from with
a CVS update, and they still come across as 644 permissions.

I changed them to 755 permissions and did a cvs commit, but that didn't
do anything.  Is there any way to change the permissions of these files
on the SF CVS server, or should we do a chmod in the create_etc script?

 - BS

[Devil-linux-develop] Re: [Devil-linux-commit] build/config/etc/initrd linuxrc,1.63,1.64

[Bruce S. <bw...@ar...>]

This is the weirdest problem I've seen in a long time.

> Log Message:
> Fixed problem of /floppy not umount'ing when new config copied to media.
> 
> 
> Index: linuxrc

>  					mount -n -t auto $CFG_SRC /floppy >/dev/null 2>&1 || continue
>  					cp -i /cdrom/config/etc.tar.bz2 /floppy/ || continue
> +					umount /cdrom
>  					sync
>  					DL_CONFIG_SOURCE=$CFG_SRC
>  					continue 2

Without the above umount of /cdrom , the following umount /floppy would
fail every time.  (the above code only gets run when a new config is
copied to a blank media)  It took me a half day of trial & error to get
this bug fixed!!!

>  
>  # unmount config media
> -umount /floppy &> /dev/null
> +umount /floppy

BTW, /dev/null removed so we can see if error if it occurs again.

 - BS

Re: [Devil-linux-develop] PATCH for config_linux_alsa for 2.6

[Oliver J. <oli...@mo...>]

> Committed.
>
>  - BS
>
> </top-post:>
>
>> add a missing driver... hangs in make prepare
>>
>> Index: scripts/config/linux-2.6/config_linux.alsa
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> RCS file:
>> /cvsroot/devil-linux/build/scripts/config/linux-2.6/config_linux.alsa,=
v
>> retrieving revision 1.1
>> diff -u -r1.1 config_linux.alsa
>> --- scripts/config/linux-2.6/config_linux.alsa  31 Jan 2004 01:02:02
>> -0000      1.1
>> +++ scripts/config/linux-2.6/config_linux.alsa  3 Mar 2004 06:16:56
>> -0000
>> @@ -64,6 +64,7 @@
>>  #
>>  CONFIG_SND_ALI5451=3Dm
>>  CONFIG_SND_AZT3328=3Dm
>> +CONFIG_SND_BT87X=3Dm
>>  CONFIG_SND_CS46XX=3Dm
>>  CONFIG_SND_CS46XX_NEW_DSP=3Dy
>>  CONFIG_SND_CS4281=3Dm
>

but don't make members of this mailinglist angry with top posting.. i try=
 to
not forget it every time i sent a mail to this mailing list :-))))

Re: [Devil-linux-develop] workaround patch for compiling problems with kernel 2.6

[Heiko Z. <he...@zu...>]

Oliver Jehle wrote:
> there is a problem with an undefined type in the includes of 
> 2.6.3 when accessing them from userspace.. 
> 
> 
> this patch elminiates the problem.. but hopefully will be fixed soon..
> 

Added.

Thanks
   Heiko

Re: [Devil-linux-develop] Re: Q: /etc/init.d/boot.d/

[Heiko Z. <he...@zu...>]

Roland Pabel wrote:
>  On 03/02/2004 05:48:35 PM Roland Pabel wrote:
>  >On Monday 01 March 2004 03:47, Heiko Zuerker wrote:
>  >> Roland Pabel wrote:
> [...]
> 
>>But it probably makes sense to do it the same way as the other distros, so
>>it's easier for our users.
> 
> Ok, you can expect my patch tomorrow

Cool, I'm looking forward to it.

Heiko

[Devil-linux-develop] Re: Q: /etc/init.d/boot.d/

[Roland P. <pa...@ta...>]

 On 03/02/2004 05:48:35 PM Roland Pabel wrote:
 >On Monday 01 March 2004 03:47, Heiko Zuerker wrote:
 >> Roland Pabel wrote:
[...]
>But it probably makes sense to do it the same way as the other distros, so
>it's easier for our users.
Ok, you can expect my patch tomorrow
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] PATCH for config_linux_alsa for 2.6

[Bruce S. <bw...@ar...>]

Committed.

 - BS

</top-post:>

> add a missing driver... hangs in make prepare 
> 
> Index: scripts/config/linux-2.6/config_linux.alsa
> ===================================================================
> RCS file:
> /cvsroot/devil-linux/build/scripts/config/linux-2.6/config_linux.alsa,v
> retrieving revision 1.1
> diff -u -r1.1 config_linux.alsa
> --- scripts/config/linux-2.6/config_linux.alsa  31 Jan 2004 01:02:02
> -0000      1.1
> +++ scripts/config/linux-2.6/config_linux.alsa  3 Mar 2004 06:16:56
> -0000
> @@ -64,6 +64,7 @@
>  #
>  CONFIG_SND_ALI5451=m
>  CONFIG_SND_AZT3328=m
> +CONFIG_SND_BT87X=m
>  CONFIG_SND_CS46XX=m
>  CONFIG_SND_CS46XX_NEW_DSP=y
>  CONFIG_SND_CS4281=m

[Devil-linux-develop] workaround patch for compiling problems with kernel 2.6

[Oliver J. <oli...@mo...>]

there is a problem with an undefined type in the includes of 
2.6.3 when accessing them from userspace.. 


this patch elminiates the problem.. but hopefully will be fixed soon..